Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-16 📝 Original message: Thanks for your answers ...
📅 Original date posted:2019-05-16
📝 Original message:
Thanks for your answers and links, the previous discussions probably
happened before I joined this list so I'll go dig into the archive ;)
> I think it makes sense for us to consider both variants, one committing
> to the script and the other not committing to the script, but I think it
> applies rather to the `update_tx` <-> `settlement_tx` link and less to
> the `funding_tx` <-> `update_tx` link and `update_tx` <-> `update_tx`
> link. The reason is that the `settlement_tx` needs to be limited to be
> bindable only to the matching `update_tx` (`anyprevout`), while
> `update_tx` need to be bindable to the `funding_tx` as well as any prior
> `update_tx` which differ in the script by at least the state number
> (hence `anyprevoutanyscript`).
> Like AJ pointed out in another thread, the use of an explicit trigger
> transaction is not really needed since any `update_tx` can act as a
> trigger transaction (i.e., start the relative timeouts to tick).
Thanks for confirming, that was how I understood it too.
> Specifically we can't make make use of the collaborative path where
> we override an `update_tx` with a newer one in taproot as far as I can
> see, since the `update_tx` needs to be signed with noinput (for
> rebindability) but there is no way for us to specify the chaperone key
> since we're not revealing the committed script.
Can you expand on that? Why do we need to "make use of the collaborative
path" (maybe it's unclear to me what you mean by collaborative path here)?
When we override an `update_tx` we use a new state number and we derive the
new keys for that state independently of the keys of the previous state
right?
So we would derive new settlement keys and potentially chaperone keys, and
re-create a merkle tree and taproot from scratch.
I don't see where taproot interacts in a negative way with noinput there...
> For that matter the `OP_CHECKMULTISIG`/`OP_CHECKSIGADD` could be reduced
by using MuSig on the two participants.
> Further, there is no need for an explicit `OP_CHECKSEQUENCEVERIFY` or
even separate keys for state and update paths.
Thanks for the suggestions, these are good optimizations.
I feel like there will be a few other optimizations that are unlocked by
taproot/tapscript, it will be interesting to dig into that.
Thanks,
Bastien
Le jeu. 16 mai 2019 à 03:48, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning,
>
>
> >
> > We could collapse those 1-of-2 multisigs into a single-sig if we just
> > collaboratively create a shared private key that is specific to the
> > instance of the protocol upon setup. That minimizes the extra space
> > needed.
>
> For that matter the `OP_CHECKMULTISIG`/`OP_CHECKSIGADD` could be reduced
> by using MuSig on the two participants.
> Further, there is no need for an explicit `OP_CHECKSEQUENCEVERIFY` or even
> separate keys for state and update paths.
> xref.
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001933.html
>
> The proposal that does not include `OP_CODESEPARATOR` is:
>
> <index> OP_CHECKLOCKTIMEVERIFY OP_DROP
> <MuSig(A_u, B_u)> OP_CHECKSIG <C> OP_CHECKSIG
>
> Where `C` is the common key that Christian described above, and `index` is
> the update number index.
>
> For update transactions, `nSequence` is 0.
> For state transactions, `nSequence` is non-0.
> Both of them will have `nLockTime` equal to the required index.
> The `nSequence` is enforced by the participants refusing to sign invalid
> `nSequence`.
>
> The above seems quite optimized.
>
> > > (I ommitted the tapscript changes, ie moving to OP_CHECKSIGADD, to
> > > highlight only the chaperone changes)
> > > When updating the channel, Alice and Bob would exchange their
> > > anyprevoutanyscript signatures (for the 2-of-2 multisig).
> > > The chaperone signature can be provided by either Alice or Bob at
> > > transaction broadcast time (so that it commits to a specific input
> > > transaction).
> > > It seems to me that using the same key for both signatures (the
> chaperone
> > > one and the anyprevoutanyscript one) is safe here, but if someone knows
> > > better I'm interested.
> > > If that's unsafe, we simply need to introduce another key-pair
> (chaperone
> > > key).
> > > Is that how you guys understand it too? Do you have other ideas on how
> to
> > > comply with the need for a chaperone signature?
> > > Note that as Anthony said himself, the BIP isn't final and we don't
> know
> > > yet if chaperone signatures will eventually be needed, but I think it's
> > > useful to make sure that Eltoo could support it.
> >
> > I quite like the chaperone idea, however it doesn't really play nice
> > with taproot collaborative spends that require anyprevout /
> > anyprevoutanyscript / noinput, which would make our transactions stand
> > out quite a bit. Then again this is only the case for the unhappy,
> > unilateral close, path of the protocol, which (hopfully) should happen
> > rarely.
>
> The mere use of any `SIGHASH` that is not `SIGHASH_ALL` already stands out.
> So I think this is not a significant objection.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190516/babb713d/attachment-0001.html>;
📝 Original message:
Thanks for your answers and links, the previous discussions probably
happened before I joined this list so I'll go dig into the archive ;)
> I think it makes sense for us to consider both variants, one committing
> to the script and the other not committing to the script, but I think it
> applies rather to the `update_tx` <-> `settlement_tx` link and less to
> the `funding_tx` <-> `update_tx` link and `update_tx` <-> `update_tx`
> link. The reason is that the `settlement_tx` needs to be limited to be
> bindable only to the matching `update_tx` (`anyprevout`), while
> `update_tx` need to be bindable to the `funding_tx` as well as any prior
> `update_tx` which differ in the script by at least the state number
> (hence `anyprevoutanyscript`).
> Like AJ pointed out in another thread, the use of an explicit trigger
> transaction is not really needed since any `update_tx` can act as a
> trigger transaction (i.e., start the relative timeouts to tick).
Thanks for confirming, that was how I understood it too.
> Specifically we can't make make use of the collaborative path where
> we override an `update_tx` with a newer one in taproot as far as I can
> see, since the `update_tx` needs to be signed with noinput (for
> rebindability) but there is no way for us to specify the chaperone key
> since we're not revealing the committed script.
Can you expand on that? Why do we need to "make use of the collaborative
path" (maybe it's unclear to me what you mean by collaborative path here)?
When we override an `update_tx` we use a new state number and we derive the
new keys for that state independently of the keys of the previous state
right?
So we would derive new settlement keys and potentially chaperone keys, and
re-create a merkle tree and taproot from scratch.
I don't see where taproot interacts in a negative way with noinput there...
> For that matter the `OP_CHECKMULTISIG`/`OP_CHECKSIGADD` could be reduced
by using MuSig on the two participants.
> Further, there is no need for an explicit `OP_CHECKSEQUENCEVERIFY` or
even separate keys for state and update paths.
Thanks for the suggestions, these are good optimizations.
I feel like there will be a few other optimizations that are unlocked by
taproot/tapscript, it will be interesting to dig into that.
Thanks,
Bastien
Le jeu. 16 mai 2019 à 03:48, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning,
>
>
> >
> > We could collapse those 1-of-2 multisigs into a single-sig if we just
> > collaboratively create a shared private key that is specific to the
> > instance of the protocol upon setup. That minimizes the extra space
> > needed.
>
> For that matter the `OP_CHECKMULTISIG`/`OP_CHECKSIGADD` could be reduced
> by using MuSig on the two participants.
> Further, there is no need for an explicit `OP_CHECKSEQUENCEVERIFY` or even
> separate keys for state and update paths.
> xref.
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001933.html
>
> The proposal that does not include `OP_CODESEPARATOR` is:
>
> <index> OP_CHECKLOCKTIMEVERIFY OP_DROP
> <MuSig(A_u, B_u)> OP_CHECKSIG <C> OP_CHECKSIG
>
> Where `C` is the common key that Christian described above, and `index` is
> the update number index.
>
> For update transactions, `nSequence` is 0.
> For state transactions, `nSequence` is non-0.
> Both of them will have `nLockTime` equal to the required index.
> The `nSequence` is enforced by the participants refusing to sign invalid
> `nSequence`.
>
> The above seems quite optimized.
>
> > > (I ommitted the tapscript changes, ie moving to OP_CHECKSIGADD, to
> > > highlight only the chaperone changes)
> > > When updating the channel, Alice and Bob would exchange their
> > > anyprevoutanyscript signatures (for the 2-of-2 multisig).
> > > The chaperone signature can be provided by either Alice or Bob at
> > > transaction broadcast time (so that it commits to a specific input
> > > transaction).
> > > It seems to me that using the same key for both signatures (the
> chaperone
> > > one and the anyprevoutanyscript one) is safe here, but if someone knows
> > > better I'm interested.
> > > If that's unsafe, we simply need to introduce another key-pair
> (chaperone
> > > key).
> > > Is that how you guys understand it too? Do you have other ideas on how
> to
> > > comply with the need for a chaperone signature?
> > > Note that as Anthony said himself, the BIP isn't final and we don't
> know
> > > yet if chaperone signatures will eventually be needed, but I think it's
> > > useful to make sure that Eltoo could support it.
> >
> > I quite like the chaperone idea, however it doesn't really play nice
> > with taproot collaborative spends that require anyprevout /
> > anyprevoutanyscript / noinput, which would make our transactions stand
> > out quite a bit. Then again this is only the case for the unhappy,
> > unilateral close, path of the protocol, which (hopfully) should happen
> > rarely.
>
> The mere use of any `SIGHASH` that is not `SIGHASH_ALL` already stands out.
> So I think this is not a significant objection.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190516/babb713d/attachment-0001.html>;