Hi Bastien, thanks for investigating.
> I have been digging into Anthony Towns' anyprevout BIP > <https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki> > proposal > to verify that it has everything we need for Eltoo > <https://blockstream.com/eltoo.pdf>. > > The separation between anyprevout and anyprevoutanyscript is very handy > (compared to the previous noinput proposal). > Unless I'm missing something, it would simplify the funding tx (to a simple > multisig without cltv/csv) and remove the need for the trigger tx. 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). This was an oversight of mine, which may have contributed more confusion than necessary :-) The `funding_tx` itself doesn't need any form of timeout, in fact collaborative spending/closing without a timeout should always be possible. The `settlement_tx`s can have a BIP68-style relative timelock, which also saves us a few bytes. > The more tricky part to integrate is the chaperone signature. > If I understand it correctly (which I'm not guaranteeing), we would need to > modify the update transactions to something like: > > OP_IF > > 10 OP_CSV > > 1 A(s,i) B(s,i) 2 OP_CHECKMULTISIGVERIFY <- public keys' first >> byte in this line is 0x02 or 0x03 > > 2 A(s,i) B(s,i) 2 OP_CHECKMULTISIGVERIFY <- public keys' first >> byte in this line is 0x00 or 0x01 > > OP_ELSE > > <S(i) + 1> OP_CLTV > > 1 A(u) B(u) 2 OP_CHECKMULTISIGVERIFY <- public keys' first >> byte in this line is 0x02 or 0x03 > > 2 A(u) B(u) 2 OP_CHECKMULTISIGVERIFY <- public keys' first >> byte in this line is 0x00 or 0x01 > > OP_END 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. Something that I notived talking to Jonas Nick is that we might have some interaction between the taproot and noinput (or any of its aliases :D). 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. > (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. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
