ZmnSCPxj [ARCHIVE] on Nostr: đź“… Original date posted:2020-08-03 đź“ť Original message:Good morning Richard, > ...
đź“… Original date posted:2020-08-03
đź“ť Original message:Good morning Richard,
> Thanks AJ for the updated BIP - very exciting!
>
> I'm also interested in this in the context of a Taproot version of Decker-Russell-Osuntokun (eltoo). Thanks ZmnSCPxj for summarizing your thoughts on how this would work. I have had some difficulty understanding when someone might want to use ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and this is a clever demonstration of how the differences can be exploited.
>
> I sketched out the protocol you described to help my understand it (below) and some questions came to mind:
>
> 1) If you do a collaborative close, would you need to use script-path spending, or could you use key-path spending instead to improve privacy?
It can (and should) use key-path, yes.
>
> 2) You mention 1.5 round trips for the (two party) MuSig signing session. Must there be separate 1.5 round trips for each of the two signatures produced (update, settlement) for each state update?
I believe we can amortize this slightly by providing the `R` commitments for the *next* signing session with the `s` for the *current* signing session, reducing to 1.0 round trips.
However, I believe a provably-safe 2-round MuSig (with composable MuSig even!) is being worked on and should be released in a week or two, and if it is safe to provide the first round of the *next* session with the final round of the *current* session then we could reduce it to just one (large) message send per update.
>
> 3) A related question: can the 1.5 round trips for signing be combined with the 1.5 round trips required to update the channel (ie. A signs settlement tx, B signs settlement & update txs, A signs update tx)?Â
>
> Perhaps something like this:
> Â -> A provides partial signature for settlement tx
> Â <- B provides complete signature for settlement tx and partial signature for update tx
> Â -> A provides complete signature for update tx
My understanding (which might be incorrect!) is that it should be safe to perform the signing sessions for the settlement and update txes simultaneously, i.e.
* round 1: send `R` commitments for both update and settlement tx (can be sent with round 3 of previous signing session).
* round 2: send `R` for both update and settlement tx.
* round 3: send `s` for both update and settlement tx.
Depending on how we do the HTLCs / PTLCs, we might also need to send signatures for all HTLCs, in parallel with the update+settlement tx signatures, as well.
> 4) I'm not sure why AJ's formulation included an addition sig(X), but otherwise is it similar to what you're suggesting?
> Â Â https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html
This might have been the "chaperone signatures" proposed for `SIGHASH_NOINPUT` / `SIGHASH_ANYPREVOUT` back then.
This was supposed to protect against replaying a `SIGHASH_ANYPREVOUT` signature in case of address reuse.
I pointed out that it would be much simpler for a Lightning spec to provide a privkey for a common `X` used by all Lightning nodes, and thus would not really provide much better security in practice.
I believe what we intend now is a form of hidden output tagging to protect against signature replay.
An output has to have a special taproot version in order to be spent with `SIGHASH_ANYPREVOUT` or `SIGHASH_ANYPREVOUTANYSCRIPT` in the script path, and `SIGHASH_ANYPREVOUT`/`SIGHASH_ANYPREVOUTANYSCRIPT` is not usable with key path spends.
Regards,
ZmnSCPxj
đź“ť Original message:Good morning Richard,
> Thanks AJ for the updated BIP - very exciting!
>
> I'm also interested in this in the context of a Taproot version of Decker-Russell-Osuntokun (eltoo). Thanks ZmnSCPxj for summarizing your thoughts on how this would work. I have had some difficulty understanding when someone might want to use ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and this is a clever demonstration of how the differences can be exploited.
>
> I sketched out the protocol you described to help my understand it (below) and some questions came to mind:
>
> 1) If you do a collaborative close, would you need to use script-path spending, or could you use key-path spending instead to improve privacy?
It can (and should) use key-path, yes.
>
> 2) You mention 1.5 round trips for the (two party) MuSig signing session. Must there be separate 1.5 round trips for each of the two signatures produced (update, settlement) for each state update?
I believe we can amortize this slightly by providing the `R` commitments for the *next* signing session with the `s` for the *current* signing session, reducing to 1.0 round trips.
However, I believe a provably-safe 2-round MuSig (with composable MuSig even!) is being worked on and should be released in a week or two, and if it is safe to provide the first round of the *next* session with the final round of the *current* session then we could reduce it to just one (large) message send per update.
>
> 3) A related question: can the 1.5 round trips for signing be combined with the 1.5 round trips required to update the channel (ie. A signs settlement tx, B signs settlement & update txs, A signs update tx)?Â
>
> Perhaps something like this:
> Â -> A provides partial signature for settlement tx
> Â <- B provides complete signature for settlement tx and partial signature for update tx
> Â -> A provides complete signature for update tx
My understanding (which might be incorrect!) is that it should be safe to perform the signing sessions for the settlement and update txes simultaneously, i.e.
* round 1: send `R` commitments for both update and settlement tx (can be sent with round 3 of previous signing session).
* round 2: send `R` for both update and settlement tx.
* round 3: send `s` for both update and settlement tx.
Depending on how we do the HTLCs / PTLCs, we might also need to send signatures for all HTLCs, in parallel with the update+settlement tx signatures, as well.
> 4) I'm not sure why AJ's formulation included an addition sig(X), but otherwise is it similar to what you're suggesting?
> Â Â https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html
This might have been the "chaperone signatures" proposed for `SIGHASH_NOINPUT` / `SIGHASH_ANYPREVOUT` back then.
This was supposed to protect against replaying a `SIGHASH_ANYPREVOUT` signature in case of address reuse.
I pointed out that it would be much simpler for a Lightning spec to provide a privkey for a common `X` used by all Lightning nodes, and thus would not really provide much better security in practice.
I believe what we intend now is a form of hidden output tagging to protect against signature replay.
An output has to have a special taproot version in order to be spent with `SIGHASH_ANYPREVOUT` or `SIGHASH_ANYPREVOUTANYSCRIPT` in the script path, and `SIGHASH_ANYPREVOUT`/`SIGHASH_ANYPREVOUTANYSCRIPT` is not usable with key path spends.
Regards,
ZmnSCPxj