LE GUILLY THIBAUT [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-04-28 to 2020-04-29
💬 Posted a total of 2 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:59:58

- reply

📅 Original date posted:2020-04-29
📝 Original message:
Hi Lloyd,
Thanks for taking the time to read!
What we were trying to describe in this section is the failure to construct
a DLC channel by using only a fund transaction (on-chain), CETs and a
refund transaction (same as the on-chain version), but adding revocation
secrets to the CETs and the refund transaction. So the signed transactions
that Alice holds are the CETs and the refund transaction for the second
DLC, but she cannot use them since the CETs require the oracle signature to
be published and the refund transaction is timed lock to after the contract
maturity. So Alice is stuck in the second DLC, but Bob still has the
possibility to close the channel on the previous state (using a CET from
the first DLC since he has not revealed the revocation secret).
That's why we add the update and buffer transactions in the construction
(the buffer transaction is required to prevent the parties from closing the
channel with the update transaction before the maturity of the contract).
Hope that clarifies a bit.
Cheers,
Thibaut
On Wed, Apr 29, 2020 at 7:24 PM Lloyd Fournier <lloyd.fourn at gmail.com>
wrote:
> Hi Thibaut,
>
> Thanks for carrying out this research. I have not finished reading the
> paper but have a question about what you call the "straw man" proposal
> early on:
>
> "At the end of this protocol, both Alice and Bob have the set of signed
> transactions for the second DLC, and the transactions for the previous one
> are revoked. However, there is an issue at step 6. After sending her
> revocation secret to Bob, Alice cannot anymore enforce the result from the
> first contract. However, as Bob has not yet revealed his secret, he still
> has the ability to do so, in addition to having the ability to enforce the
> second one. If Bob is dishonest, he could thus choose not to reveal his
> revocation key, and wait until just before the maturity of the second
> contract to execute the one that is most favorable to him (he could also
> potentially use the previous refund transaction if the time lock expired)."
>
> Since Alice has the signed transactions for the new state, if Bob refuses
> to revoke the old state why can't she just post the new state on chain
> immediately? This limits Bob's "option" and I thought is the optimal
> solution whenever this problem occurs.
>
> Cheers,
>
> LL
>
> On Tue, Apr 28, 2020 at 5:43 PM LE GUILLY THIBAUT <
> thibaut at cryptogarage.co.jp> wrote:
>
>> 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
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200429/821b2f29/attachment-0001.html>

2023-06-09 12:59:57

- reply

📅 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>

2023-06-09 12:59:57

- reply