From: Yuval Kogman <nothingmuch@woobling•org>
To: Mike Brooks <m@ib•tc>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
Date: Fri, 19 Jul 2019 17:45:17 +0000 [thread overview]
Message-ID: <CAAQdECAyQB0E0PxwBOxXoEtQO_HU5b3JGQpsqp_OfB8dOKqiUQ@mail.gmail.com> (raw)
In-Reply-To: <CALFqKjQkQwuxjeYkGWO_Y_HhNQmJgrjqF3m04hbORV7FSbsi3Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]
Hi,
On Fri, 19 Jul 2019 at 14:00, Mike Brooks via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
Giving scripts the ability to refer to data on the blockchain will reduce
> transaction sizes because key material does not have to be repeated in
> every Script.
>
Given that address reuse is discouraged, and as far as I know is
predominantly utilized for customer deposit addresses by exchanges, many of
which have not invested resources in batching withdrawals or consolidating
small UTXOs, I am skeptical that such a feature would actually be utilized
by users for whom a potential use exists, especially as mining fees are
usually pushed onto customers anyway.
Unless extensively utilized such that costs outweigh benefits, this change
would impose an externality on validating nodes:
With this list a newly created script can refer to a specific PUSHDATA that
> was used in any previously confirmed block.
>
This would make pruning impossible, and also relaxes the bounds on
validation costs since it would allow random reads on all historical data
as opposed to just the UTXO set.
Although it would do nothing for block capacity, perhaps this redundancy
might be better addressed as opt-in functionality in the p2p layer? It
might help with IBD, though at least in my experience peer latency (as
opposed to throughput) is the limiting factor, and as far as I can tell
this would increase it. Somewhat relatedly, transaction IDs are another
type of pointer which might benefit from being encoded as a (block height,
offset). However, here too it seems to me like the complexity is
substantial, potentially introducing new DoS vectors, while saving several
bytes per input at most.
Regards,
Yuval
[-- Attachment #2: Type: text/html, Size: 3061 bytes --]
next prev parent reply other threads:[~2019-07-19 17:45 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 [this message]
[not found] ` <CALFqKjTHT7XaREK7ewwKKBjrZcty7ueNBMtSLEW7B-o9uwXgmw@mail.gmail.com>
2019-07-19 22:48 ` Yuval Kogman
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=CAAQdECAyQB0E0PxwBOxXoEtQO_HU5b3JGQpsqp_OfB8dOKqiUQ@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