From: Richard Myers <rich@gotenna•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
Date: Mon, 3 Aug 2020 21:27:13 +0200 [thread overview]
Message-ID: <CACJVCgL+Ap9VBsDQp+KEuwhAkPZ1c0ACBRjHnB_qk-hi8_Uq7Q@mail.gmail.com> (raw)
In-Reply-To: <O_Zr7tM2TYwJdFS0o9RraXrtRPI4ZcVU65qcBpg-tvTPOqnGWkEUDQY5XqcihbUyAHF31L4isFWsD_u2SsSb8YzfjYDWiVXQsr6oAd9YXBY=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 4255 bytes --]
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?
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?
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
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
All the best,
-- Richard
------- my interpretation of your scheme ----
[Fund Channel]
|
|
|
v
P=Musig(A,B)+scripts (Taproot internal key, aka script path key?)
Q=Musig(A,B) (Taproot output key, aka root key?)
OR ----------- [Cooperative Close]
||| Sig(Q) -----+
||| |----> Sig(A)...
||| |
||| |----> Sig(B)...
|||
|||
||+-->[Update(n)]
|| nlocktime/state > n
|| Sig(P)+ANYPREVOUTANYSCRIPT
||
|| OR ---------->[Settle(n)] [Uncooperative Close @
state n]
|| | Sig(P)+ANYPREVOUT
|| | csv [delay] --------+---> Sig(A)... [HTLCs
& Settled
|| | |
Outputs ]
|| | |---> Sig(B)...
|| v
|+---->[Update(n+1)]
| nlocktime/state > n+1
| Sig(P)+ANYPREVOUTANYSCRIPT
|
| OR ----------->[Settle(n+1)] [Uncooperative Close @
state n+1]
| | Sig(P)+ANYPREVOUT
| | csv [delay] -------+---> Sig(A)... [HTLCs
& Settled
| | |
Outputs ]
v v |---> Sig(B)...
On Fri, Jul 10, 2020 at 5:30 AM ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
...
> Slightly off-topic, but I suppose a Decker-Russell-Osuntokun construction
> could, in theory, have only a single internal taproot pubkey, `P = MuSig(A,
> B)` for a channel between A and B.
>
> So the funding outpoint would be spent with a taprooted P + a single
> tapscript `<1> OP_CHECKSIG`.
>
> Update transactions would be signed with the internal taproot pubkey using
> `SIGHASH_ANYPREVOUTANYSCRIPT`.
> The update transaction output would be spendable with a taprooted P + a
> single tapscript `<index + 1> OP_CHECKLOCKTIMEVERIFY OP_DROP <1>
> OP_CHECKSIG`.
> Each update transaction would have a monotonically-increasing `nLockTime`,
> i.e. the above `index`.
>
> Then a state transaction would be signed with the internal taproot pubkey
> using `SIGHASH_ANYPREVOUT`, which commits to the exact script including
> `<index + 1>`, which is unique for each update transaction.
> Thus a state transaction can only spend the specific update transaction,
> but the update transaction can spend the funding outpoint or any update
> transaction outpoint.
> State transaction input would have an `nSequence` requiring a relative
> locktime of the agreed-upon unilateral close delay.
>
> The above assumes MuSig signing, which requires 1.5 round trips for a
> channel, or three broadcast rounds for a multiparticipant (n >= 3)
> construction.
>
>
> Regards,
> ZmnSCPxj
>
>
[-- Attachment #2: Type: text/html, Size: 8137 bytes --]
next prev parent reply other threads:[~2020-08-03 21:16 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 [this message]
2020-08-04 1:38 ` ZmnSCPxj
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=CACJVCgL+Ap9VBsDQp+KEuwhAkPZ1c0ACBRjHnB_qk-hi8_Uq7Q@mail.gmail.com \
--to=rich@gotenna$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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