Re: [Lightning-dev] Eltoo, anyprevout and chaperone signatures

[ZmnSCPxj via Lightning-dev]

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:

 OP_CHECKLOCKTIMEVERIFY OP_DROP
 OP_CHECKSIG  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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Eltoo, anyprevout and chaperone signatures

[Christian Decker]

Hi Bastien,

thanks for investigating.

> I have been digging into Anthony Towns' anyprevout BIP
> 
> proposal
> to verify that it has everything we need for Eltoo
> .
>
> 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
>
>  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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Eltoo, anyprevout and chaperone signatures

[Bastien TEINTURIER]

Good morning list,

I have been digging into Anthony Towns' anyprevout BIP

proposal
to verify that it has everything we need for Eltoo
.

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

 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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev