[Lightning-dev] Eltoo, anyprevout and chaperone signatures

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu May 16 01:48:51 UTC 2019

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:


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.


More information about the Lightning-dev mailing list