LE GUILLY THIBAUT [ARCHIVE] on Nostr: đź“… Original date posted:2020-04-28 đź“ť Original message: Hi list, First let me ...
đź“… Original date posted:2020-04-28
đź“ť Original message:
Hi list,
First let me introduce myself as this is my first time posting. My name is
Thibaut and I’ve been working at Crypto Garage for some time, mainly
focusing on DLC. With my colleagues Ichiro Kuwahara and Takatoshi Nakagawa, we
have been researching on how to construct DLC channels, and how such
channels could be integrated in the Lightning network. As there are
currently quite some discussions around DLC, we thought that it was a good
time to share the result of this research. You can find the paper on github
(
https://github.com/p2pderivatives/offchain-dlc-paper/blob/master/offchaindlc.pdf
) , and I’ll try to summarize it here (if you’re not familiar with DLC I
recommend going for the paper as I’ll assume some knowledge in the following
, also it has nice figures and everything so nice to skim through as a
support for the description here). We’d be happy to hear feedback from the
community on the feasibility of the approach we propose, both theoretically
and practically.
Motivation
==================================
At the moment, once a DLC expires, both parties need to close and open a
new one in order to re-enter in a contract. This is wasteful as it requires
at the minimum two extra on-chain transactions (one for mutual closing, and
a new funding tx). So one would like to have a way to have actual DLC
channels, where two parties can keep establishing contracts between
themselves as long as the balance in the channel allows it. Creating such
channels is less trivial than it may seem at first glance, as one tricky
part is to ensure that no party can ever have the possibility of both
enforcing the outcome of a previous contract or that of the latest contract
(so they could pick the most favorable to them). I’ll refer to this issue
as the “free option” problem hereafter, but it shouldn’t be confused with
the free option problem of atomic swaps.
In addition, if we are to implement such DLC channels, we would like to
avoid having to re-do all the work and instead take advantage of the
existing Lightning Network infrastructure. Note that the integration
solution we propose is generic and would work to integrate other types of
layer 2 protocol in LN. It also permits the existence of multiple
concurrent channels, so two parties could have multiple DLC at the same
time using a single fund transaction.
Note that one of our motivation was also to come up with something that
doesn’t require any changes to the Bitcoin transaction structure or SIGHASH
or any new cryptographic operation, as it is rather trivial to implement in
an eltoo context for example.
Related Work
==================================
Juraj Bednár and René Pickhardt previously proposed Lightning DLC channels [
1]. Their construction works by adding an output to a LN commitment
transaction, from which the regular set of DLC transactions can be
attached. Our approach differs in two ways:
1. Our DLC channel construction can be made standalone, meaning they
could be deployed outside (or alongside) of the LN
2. The integration with LN that we propose allow for more separation of
concerns between the channels, as they can be updated separately without
influencing each others (their construction requires re-building all
transactions for any update, we only require this for opening/closing
and re-balancing).
Bednár and Pickhardt approach is similar to the one briefly described by
Ben Carman of Suredbit in the first section of [2]. He then proposes routed
DLC that require PTLC and barrier escrow. While our proposal only works for
direct channels (so no routing), it also doesn’t require any intermediary, and
only basic ECDSA.
As already mentioned, both DLC channels and their integration in LN could
be made much more easily in an eltoo world, as eltoo can be used as a
generic framework for building off-chain contracts [3].
DLC Channels
==================================
I’ll skip the part about the broken naive construction (that has the free
option problem), and go directly for the one that actually works. The main
trick revolves around adding two types of transaction to the regular DLC
construction:
1. The first type of transaction is the update transaction. It’s pretty
much the same as an LN commitment transaction, and serves a similar
purpose, that is keeping the balance of the channel. It is also revokable
, meaning that each party holds a different version.
2. The second type is the buffer transaction, which spends both outputs
of the update transactions to produce one output that will be consumed by
the Contract Execution Transactions (CETs). The main point of the buffer
transaction is to solve the free option problem in the protocol.
Using these two new transaction types we can now describe the update
protocol (please refer to figure 2 of the paper for some illustration). I
skip the establishment protocol here as the update protocol is the crispy
part, but the establishment is described in the paper as well.
1. Alice and Bob generate the set of transactions (update, buffer, CETs
and refund) for the new contract, with the update transactions having
output values equal to the outcome of the previous contract,
2. Alice sends her signatures for Bob’s update transaction, all CETs and
the refund transactions,
3. Bob sends his signatures for Alice’s update transaction, all CETs, the
refund transactions, as well as the revocation key for his previous
update transaction,
4. Alice sends the revocation key for her previous update transaction, as
well as the signature for her buffer transaction,
5. Bob sends his signatures for both buffer transactions.
6. Alice sends her signature for Bob’s buffer transaction.
An informal analysis of the protocol is provided in the paper (Section 3.2.4
), but the main point is that it’s always the case that for both
parties, either
they can enforce the outcome of the previous contract (and so close the
channel in case of an uncooperative counter party), either they can force
their counter party into the new contract, but there is no point at which a
party can pick which one to enforce (the free option problem).
In the non-cooperative case, a DLC channel requires 5 on-chain
transaction (from
opening to close), while in the cooperative case it’s still only two. That
means two more transactions in the worst case compared to the on-chain
version, but we believe this is offset by the ability to establish
consecutive contracts (even with two consecutive contracts, the number of
transaction is reduced).
Integration to the Lightning Network
==================================
Our proposed solution to integrate the DLC channels in LN is quite simple, but
to the best of our knowledge has not been proposed before (apologies if that
’s wrong, and happy to be corrected). The idea is to use a “split”
transaction, which spends the output of the fund transaction, and contains
a single output for every channel to be created (a basic example would be
one LN channel and one DLC channel), which works as the new funding for
these channel. In the paper, we made this split transaction revokable so
that it’s possible to reallocate funds between the channels, and close/open
channels as desired. Writing this I realized it might also be possible to
not make it revokable, which would make it less flexible but would remove
the drawback of doubling the number of transactions to be created and
monitored.
The advantage of this construction is that you can support as many
sub-channels as you want for a single fund transaction, and have the
ability to rebalance between the channels. The disadvantage is that you
need to create and keep track of twice as many transactions due to the
revocation mechanism in the split transaction (though as just mentioned if
you don’t want to rebalance and/or add/remove channels this issue is removed
).
Conclusion and Questions
==================================
We proposed a way to create DLC channels, and to integrate them in the
Lightning Network. Both can be done with existing cryptographic constructs
and Bitcoin transactions. We’d be happy to hear what people think of this
approach, whether it is worth pursuing considering the recent development
of ECDSA adaptor signatures which would enable simpler constructions, and
how complex it would be to implement in practice.
Regards,
Thibaut
[1] https://hackmd.io/@lpQxZaCeTG6OJZI3awxQPQ/LN-DLC
[2] https://suredbits.com/discreet-log-contracts-on-lightning-network/
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002136.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200428/2ef726cc/attachment-0001.html>;
đź“ť Original message:
Hi list,
First let me introduce myself as this is my first time posting. My name is
Thibaut and I’ve been working at Crypto Garage for some time, mainly
focusing on DLC. With my colleagues Ichiro Kuwahara and Takatoshi Nakagawa, we
have been researching on how to construct DLC channels, and how such
channels could be integrated in the Lightning network. As there are
currently quite some discussions around DLC, we thought that it was a good
time to share the result of this research. You can find the paper on github
(
https://github.com/p2pderivatives/offchain-dlc-paper/blob/master/offchaindlc.pdf
) , and I’ll try to summarize it here (if you’re not familiar with DLC I
recommend going for the paper as I’ll assume some knowledge in the following
, also it has nice figures and everything so nice to skim through as a
support for the description here). We’d be happy to hear feedback from the
community on the feasibility of the approach we propose, both theoretically
and practically.
Motivation
==================================
At the moment, once a DLC expires, both parties need to close and open a
new one in order to re-enter in a contract. This is wasteful as it requires
at the minimum two extra on-chain transactions (one for mutual closing, and
a new funding tx). So one would like to have a way to have actual DLC
channels, where two parties can keep establishing contracts between
themselves as long as the balance in the channel allows it. Creating such
channels is less trivial than it may seem at first glance, as one tricky
part is to ensure that no party can ever have the possibility of both
enforcing the outcome of a previous contract or that of the latest contract
(so they could pick the most favorable to them). I’ll refer to this issue
as the “free option” problem hereafter, but it shouldn’t be confused with
the free option problem of atomic swaps.
In addition, if we are to implement such DLC channels, we would like to
avoid having to re-do all the work and instead take advantage of the
existing Lightning Network infrastructure. Note that the integration
solution we propose is generic and would work to integrate other types of
layer 2 protocol in LN. It also permits the existence of multiple
concurrent channels, so two parties could have multiple DLC at the same
time using a single fund transaction.
Note that one of our motivation was also to come up with something that
doesn’t require any changes to the Bitcoin transaction structure or SIGHASH
or any new cryptographic operation, as it is rather trivial to implement in
an eltoo context for example.
Related Work
==================================
Juraj Bednár and René Pickhardt previously proposed Lightning DLC channels [
1]. Their construction works by adding an output to a LN commitment
transaction, from which the regular set of DLC transactions can be
attached. Our approach differs in two ways:
1. Our DLC channel construction can be made standalone, meaning they
could be deployed outside (or alongside) of the LN
2. The integration with LN that we propose allow for more separation of
concerns between the channels, as they can be updated separately without
influencing each others (their construction requires re-building all
transactions for any update, we only require this for opening/closing
and re-balancing).
Bednár and Pickhardt approach is similar to the one briefly described by
Ben Carman of Suredbit in the first section of [2]. He then proposes routed
DLC that require PTLC and barrier escrow. While our proposal only works for
direct channels (so no routing), it also doesn’t require any intermediary, and
only basic ECDSA.
As already mentioned, both DLC channels and their integration in LN could
be made much more easily in an eltoo world, as eltoo can be used as a
generic framework for building off-chain contracts [3].
DLC Channels
==================================
I’ll skip the part about the broken naive construction (that has the free
option problem), and go directly for the one that actually works. The main
trick revolves around adding two types of transaction to the regular DLC
construction:
1. The first type of transaction is the update transaction. It’s pretty
much the same as an LN commitment transaction, and serves a similar
purpose, that is keeping the balance of the channel. It is also revokable
, meaning that each party holds a different version.
2. The second type is the buffer transaction, which spends both outputs
of the update transactions to produce one output that will be consumed by
the Contract Execution Transactions (CETs). The main point of the buffer
transaction is to solve the free option problem in the protocol.
Using these two new transaction types we can now describe the update
protocol (please refer to figure 2 of the paper for some illustration). I
skip the establishment protocol here as the update protocol is the crispy
part, but the establishment is described in the paper as well.
1. Alice and Bob generate the set of transactions (update, buffer, CETs
and refund) for the new contract, with the update transactions having
output values equal to the outcome of the previous contract,
2. Alice sends her signatures for Bob’s update transaction, all CETs and
the refund transactions,
3. Bob sends his signatures for Alice’s update transaction, all CETs, the
refund transactions, as well as the revocation key for his previous
update transaction,
4. Alice sends the revocation key for her previous update transaction, as
well as the signature for her buffer transaction,
5. Bob sends his signatures for both buffer transactions.
6. Alice sends her signature for Bob’s buffer transaction.
An informal analysis of the protocol is provided in the paper (Section 3.2.4
), but the main point is that it’s always the case that for both
parties, either
they can enforce the outcome of the previous contract (and so close the
channel in case of an uncooperative counter party), either they can force
their counter party into the new contract, but there is no point at which a
party can pick which one to enforce (the free option problem).
In the non-cooperative case, a DLC channel requires 5 on-chain
transaction (from
opening to close), while in the cooperative case it’s still only two. That
means two more transactions in the worst case compared to the on-chain
version, but we believe this is offset by the ability to establish
consecutive contracts (even with two consecutive contracts, the number of
transaction is reduced).
Integration to the Lightning Network
==================================
Our proposed solution to integrate the DLC channels in LN is quite simple, but
to the best of our knowledge has not been proposed before (apologies if that
’s wrong, and happy to be corrected). The idea is to use a “split”
transaction, which spends the output of the fund transaction, and contains
a single output for every channel to be created (a basic example would be
one LN channel and one DLC channel), which works as the new funding for
these channel. In the paper, we made this split transaction revokable so
that it’s possible to reallocate funds between the channels, and close/open
channels as desired. Writing this I realized it might also be possible to
not make it revokable, which would make it less flexible but would remove
the drawback of doubling the number of transactions to be created and
monitored.
The advantage of this construction is that you can support as many
sub-channels as you want for a single fund transaction, and have the
ability to rebalance between the channels. The disadvantage is that you
need to create and keep track of twice as many transactions due to the
revocation mechanism in the split transaction (though as just mentioned if
you don’t want to rebalance and/or add/remove channels this issue is removed
).
Conclusion and Questions
==================================
We proposed a way to create DLC channels, and to integrate them in the
Lightning Network. Both can be done with existing cryptographic constructs
and Bitcoin transactions. We’d be happy to hear what people think of this
approach, whether it is worth pursuing considering the recent development
of ECDSA adaptor signatures which would enable simpler constructions, and
how complex it would be to implement in practice.
Regards,
Thibaut
[1] https://hackmd.io/@lpQxZaCeTG6OJZI3awxQPQ/LN-DLC
[2] https://suredbits.com/discreet-log-contracts-on-lightning-network/
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002136.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200428/2ef726cc/attachment-0001.html>;