Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-15 📝 Original message: Hi Bastien, thanks for ...
📅 Original date posted:2019-05-15
📝 Original message:
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
📝 Original message:
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