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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
