ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-15 📝 Original message: Good morning, > > We ...
📅 Original date posted:2019-05-15
📝 Original message:
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
📝 Original message:
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