From: darosior <darosior@protonmail•com>
To: Richard Myers <remyers@yakshaver•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
Date: Mon, 25 Apr 2022 13:35:48 +0000 [thread overview]
Message-ID: <vUv4gRXGegam5vWJosPS7rCNBOnH-B2hCok5QYXfwdpLme_cg7tAXoKvH3AU3lKE-BZ-IIq4hvtGnqytZitdS43kgAFwSQJvLPaO2tRwqEA=@protonmail.com> (raw)
In-Reply-To: <edZpe6R4qRm7fk8l49O6QkNBI-ViHKR3IozFUt6IuHxujshBRWoitjaOJJy_fk9njEG4woUdOPeKY8Vy87G22KSrOr2A7XHkYh-YSbzQiNs=@yakshaver.org>
Hi Richard,
> Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do
compete for scarce reviewer time
Yes, of course. Let's say i was more interested in knowing if people who oppose CTV would oppose
SIGHASH_ANYPREVOUT too. I think talking about activation of anything at this point is premature.
> For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there
a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
I'm not aware of any specific to CTV. It's just that the fields covered in the CTV hash are very close to what
ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV commits to that APO_AS does not are
the number of inputs and the hash of the inputs' sequences [1].
Not committing to the number of inputs and other inputs' data is today's behaviour of ANYONECANPAY that can
be combined with other signature hash types [1]. Thus APO_AS makes ACP mandatory, and to emulate CTV
completely it should be optional.
Antoine
[0] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed_Specification
[1] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
[2] https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1327, https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1517-L1522
------- Original Message -------
Le dimanche 24 avril 2022 à 10:41 PM, Richard Myers <remyers@yakshaver•org> a écrit :
> Hi darosior,
>
> Thanks for sharing your thoughts on this.
>
> > I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of
> > (or before doing) BIP119.
>
>
> Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do compete for scarce reviewer time so their ordering will necessarily be driven by reviewer's priorities. My priority is eltoo which is why I focus on BIP-118.
>
> > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], can emulate CTV just fine.
>
>
> For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
>
> In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to late-bind fees; that means ANYONECANPAY will always be paired with APO-AS for eltoo. Settlement txs in eltoo use just APO and do not necessarily need to be paired with ANYONECANPAY.
>
> I would guess making ANYONECANPAY the default for APO-AS was a way to squeeze in one more sighash flag. Perhaps there's another way to do it?
>
> Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically so the counter-party who commits a settlement tx can use for fees their settled to_self balance. How to rejigger the sighash flags to accommodate both APO and GROUP may be worth some discussion.
>
> The BIP-118 proposal will certainly benefit from having input from reviewers looking at other protocols than eltoo.
>
> -- Richard
next prev parent reply other threads:[~2022-04-25 13:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-22 11:11 darosior
2022-04-22 11:44 ` rot13maxi
2022-04-22 11:54 ` darosior
2022-04-22 17:01 ` Luke Dashjr
2022-04-24 20:41 ` Richard Myers
2022-04-25 13:35 ` darosior [this message]
2022-04-25 16:35 ` darosior
2022-04-25 1:46 ` Erik Aronesty
2022-04-25 16:35 ` Nadav Ivgi
2022-04-25 16:57 ` Nadav Ivgi
2022-04-26 20:13 ` Jeremy Rubin
2022-04-29 5:08 ` Nadav Ivgi
2022-04-29 8:30 ` darosior
2022-04-29 10:21 ` Nadav Ivgi
2022-04-29 11:40 ` Nadav Ivgi
2022-05-01 23:35 ` Billy Tetrud
2022-04-30 8:09 ` Nadav Ivgi
2022-04-30 11:15 ` Greg Sanders
2022-05-01 14:25 ` Nadav Ivgi
2022-05-03 15:51 ` Jeremy Rubin
2022-04-22 13:35 pushd
2022-04-25 13:34 ` Hampus Sjöberg
2022-04-22 17:14 pushd
2022-04-29 13:22 Swambo, Jacob
2022-05-03 10:38 ` darosior
2022-05-03 16:40 Swambo, Jacob
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='vUv4gRXGegam5vWJosPS7rCNBOnH-B2hCok5QYXfwdpLme_cg7tAXoKvH3AU3lKE-BZ-IIq4hvtGnqytZitdS43kgAFwSQJvLPaO2tRwqEA=@protonmail.com' \
--to=darosior@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=remyers@yakshaver$(echo .)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