[Lightning-dev] Eltoo, anyprevout and chaperone signatures

Christian Decker decker.christian at gmail.com
Wed May 15 20:36:32 UTC 2019


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


More information about the Lightning-dev mailing list