Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-15 📝 Original message: Good morning list, I have ...
📅 Original date posted:2019-05-15
📝 Original message:
Good morning list,
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.
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
(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.
Cheers,
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190515/ce50601f/attachment.html>;
📝 Original message:
Good morning list,
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.
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
(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.
Cheers,
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190515/ce50601f/attachment.html>;