From: Yuval Kogman <nothingmuch@woobling•org>
To: Mike Brooks <m@ib•tc>,
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
Date: Fri, 19 Jul 2019 22:48:43 +0000 [thread overview]
Message-ID: <CAAQdECAxdUvwSo2byukgevZF56gadMN1+P9cvH2wQMCVPrA38Q@mail.gmail.com> (raw)
In-Reply-To: <CALFqKjTHT7XaREK7ewwKKBjrZcty7ueNBMtSLEW7B-o9uwXgmw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]
Hi,
On Fri, 19 Jul 2019 at 17:49, Mike Brooks <m@ib•tc> wrote:
> Users will adopt whatever the client accepts - this feature would be
> transparent.
>
My skepticism was based in an assumption on my part that most such data is
produced by actors with a track record of neglecting transaction
efficiency. I'd be happy to be proven wrong, but considering say usage
rates of native witness outputs, or the fraction of transactions with more
than 2 outputs so far I see little evidence in support of widespread
adoption of cost saving measures. Assuming this is intended as a new script
version, all fully validating nodes need to commit to keeping all data
indefinitely before they can enforce the rules that make transactions
benefiting from this opcode safe to broadcast.
That said, if successful, the main concern is still that of address reuse -
currently there is no incentive in the protocol to do that, and with BIP32
wallets fewer reasons to do it as well, but this proposal introduces such
an incentive for users which would otherwise generate new addresses
(disregarding the ones that already reuse addresses anyway), and this is
problematic for privacy and fungibility.
Since address reuse has privacy concerns, I think it's important to draw a
distinction between clients accepting and producing such transactions, if
the latter were done transparently that would be very concerning IMO, and
even the former would not be transparent for users who run currently
pruning nodes.
I'm not sure how an O(1) time complexity leads to DoS, that seems like a
> very creative jump.
>
For what it's worth, that was in reference to hypothetical deduplication
only at the p2p layer, similar to compact blocks, but on further reflection
I'd like to retract that, as since both scenarios which I had in mind seem
easily mitigated.
Based on this response, it makes me want to calculate the savings, what
> if it was a staggering reduction in the tree size?
>
Assuming past address reuse rates are predictive this only places an upper
bound on the potential size savings, so personally I would not find that
very compelling. Even if the realized size savings would be substantial,
I'm not convinced the benefits outweigh the downsides (increased validation
costs, monotonically growing unprunable data, and direct incentive for
address reuse), especially when compared to other methods/proposals that
can reduce on chain footprint generally improve privacy while reducing
validation costs for others (e.g. batching, lightning, MAST for
sufficiently large scripts, Schnorr signatures (musig, adaptor signatures),
{tap,graft}root, ).
Regards,
Yuval
[-- Attachment #2: Type: text/html, Size: 3789 bytes --]
next prev parent reply other threads:[~2019-07-19 22:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 6:05 Mike Brooks
2019-07-19 15:17 ` William Casarin
2019-07-19 19:17 ` Pieter Wuille
2019-07-19 17:45 ` Yuval Kogman
[not found] ` <CALFqKjTHT7XaREK7ewwKKBjrZcty7ueNBMtSLEW7B-o9uwXgmw@mail.gmail.com>
2019-07-19 22:48 ` Yuval Kogman [this message]
2019-07-24 19:49 ` Mike Brooks
2019-07-19 18:07 ` ZmnSCPxj
2019-07-27 20:03 ` Mike Brooks
2019-07-29 1:46 ` ZmnSCPxj
2019-07-29 2:19 ` Mike Brooks
2019-07-29 2:49 ` ZmnSCPxj
2019-07-29 3:07 ` Mike Brooks
2019-07-29 3:39 ` ZmnSCPxj
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=CAAQdECAxdUvwSo2byukgevZF56gadMN1+P9cvH2wQMCVPrA38Q@mail.gmail.com \
--to=nothingmuch@woobling$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=m@ib$(echo .)tc \
/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