From: "Russell O'Connor" <roconnor@blockstream.com>
To: Anthony Towns <aj@erisian.com.au>
Cc: jonasd.nick@gmail.com,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message
Date: Sat, 2 May 2020 10:43:13 -0400 [thread overview]
Message-ID: <CAMZUoK=g-mtoxSpTc5BmhxFaoJK9n7-Q28o9LUzx4prVgd3WZA@mail.gmail.com> (raw)
In-Reply-To: <20200502142602.rj7q2m32ew6trh6u@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 991 bytes --]
> If you didn't verify the output scriptPubKeys, you would *only* be able
> to care about fees since you couldn't verify where any of the funds went?
> And you'd only be able to say fees are "at least x", since they could be
> more if one of the scriptPubKeys turned out to be OP_TRUE eg. That might
> almost make sense for a transaction accelerator that's trying to increase
> the fees; but only if you were doing it for someone else's transaction
> (since otherwise you'd care about the output addresses) and only if you
> were happy to not receive any change? Seems like a pretty weird use case?
>
You are right of course. I was thinking of cases where you only care about
where some of the outputs go but not all. But of course, even in that case
you will need to wade through all of the output ScriptPubKeys anyways.
The current design shares the hashOuputs value with the one computed with
BIP-143, and that is a somewhat valuable property to keep.
Thanks for setting me straight.
[-- Attachment #2: Type: text/html, Size: 1299 bytes --]
next prev parent reply other threads:[~2020-05-02 14:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 14:57 [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message Andrew Kozlik
2020-05-01 6:57 ` Jeremy
2020-05-01 8:48 ` Andrew Kozlik
2020-05-01 12:23 ` Russell O'Connor
2020-05-01 12:25 ` Greg Sanders
2020-05-02 4:35 ` Jeremy
2020-05-02 14:26 ` Anthony Towns
2020-05-02 14:43 ` Russell O'Connor [this message]
2020-05-02 21:15 ` Russell O'Connor
2020-05-04 15:48 ` Andrew Kozlik
2020-05-02 12:53 ` David A. Harding
2020-05-05 10:20 ` Jonas Nick
2020-05-11 22:12 ` Pieter Wuille
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='CAMZUoK=g-mtoxSpTc5BmhxFaoJK9n7-Q28o9LUzx4prVgd3WZA@mail.gmail.com' \
--to=roconnor@blockstream.com \
--cc=aj@erisian.com.au \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jonasd.nick@gmail.com \
--cc=pieter.wuille@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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