From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Richard Myers <rich@gotenna•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
Date: Tue, 04 Aug 2020 01:38:55 +0000 [thread overview]
Message-ID: <E0LvOEKdi7T-mG9yh9bnDXtsZGX1Ui269zQ5ydg4ws-HZtZ65stYLCc5G0tBjj3XnmCS0uEAxGcGweEoF5KllGClMpuKC8uQiIHfd6MYNQE=@protonmail.com> (raw)
In-Reply-To: <CACJVCgL+Ap9VBsDQp+KEuwhAkPZ1c0ACBRjHnB_qk-hi8_Uq7Q@mail.gmail.com>
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
next prev parent reply other threads:[~2020-08-04 1:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 21:40 Anthony Towns
2020-07-09 22:30 ` Anthony Towns
2020-07-10 7:46 ` Christian Decker
2020-07-10 3:29 ` ZmnSCPxj
2020-08-03 19:27 ` Richard Myers
2020-08-04 1:38 ` ZmnSCPxj [this message]
2020-08-04 4:02 ` lf-lists
2020-08-04 4:23 ` ZmnSCPxj
2020-08-04 10:38 ` Christian Decker
2020-08-04 13:10 ` Matt Corallo
2020-08-04 14:59 ` ZmnSCPxj
2020-08-06 15:58 ` Matt Corallo
2020-08-07 15:34 ` Richard Myers
2020-08-11 0:14 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='E0LvOEKdi7T-mG9yh9bnDXtsZGX1Ui269zQ5ydg4ws-HZtZ65stYLCc5G0tBjj3XnmCS0uEAxGcGweEoF5KllGClMpuKC8uQiIHfd6MYNQE=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rich@gotenna$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox