From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Mike Brooks <m@ib•tc>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
"pieter.wuille@gmail•com" <pieter.wuille@gmail•com>
Subject: Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
Date: Mon, 29 Jul 2019 01:46:40 +0000 [thread overview]
Message-ID: <dW426iyRLdy0-CbpWL9pG7dG8qvmyQizPrwuBVHpblJBCBDSMjeIuFMiTjNHOaMfUzjaW2btTiFD9PiozOt9Cv5DQUZG0o22hYndr2wk3SI=@protonmail.com> (raw)
In-Reply-To: <CALFqKjQoA+4XKGePHEK9OAZv2+qg=Q669v=f=MpDtg4F3Fx4kQ@mail.gmail.com>
Good morning Mike,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, July 28, 2019 4:03 AM, Mike Brooks <m@ib•tc> wrote:
> Hey ZmnSCPxj,
>
> As to your first point. I wasn't aware there was so much volatility at the tip, also 100 blocks is quite the difference! I agree no one could references a transaction in a newly formed blocks, but I'm curious how this number was chosen. Do you have any documentation or code that you can share related to how re-orgs are handled? Do we have a kind of 'consensus checkpoint' when a re-org is no longer possible? This is a very interesting topic.
>
Miner coinbases need 100 blocks for maturity, which is the basis of my suggestion to use 100 blocks.
It might be too high, but I doubt there will be good reason to be less than 100.
There is a potential for a targeted attack where a large payout going to a `scriptPubKey` that uses `OP_PUBREF` on a recently-confirmed transaction finds that recently-confirmed transaction is replaced with one that pays to a different public key, via a history-rewrite attack.
Such an attack is doable by miners, and if we consider that we accept 100 blocks for miner coinbase maturity as "acceptably low risk" against miner shenanigans, then we might consider that 100 blocks might be acceptable for this also.
Whether 100 is too high or not largely depends on your risk appetite.
> A validator only needs an array of PUSHDATA elements and can then validate any given SCRIPT at O(1).
Data derived from > 220Gb of perpetually-growing blockchain is hardly, to my mind, "only needs an array".
Such an array would not fit in memory for many devices that today are practical for running fullnodes.
It is keeping that array and indexing it which is the problem, i.e. the devil in the details.
Reiterating also, current pruned nodes did not retain that data and would be forced to re-download the entire blockchain.
Unless you propose that we can refer only to `OP_PUSHDATA` after activation of `OP_PUSHREF`.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-07-29 1:46 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
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 [this message]
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='dW426iyRLdy0-CbpWL9pG7dG8qvmyQizPrwuBVHpblJBCBDSMjeIuFMiTjNHOaMfUzjaW2btTiFD9PiozOt9Cv5DQUZG0o22hYndr2wk3SI=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=m@ib$(echo .)tc \
--cc=pieter.wuille@gmail$(echo .)com \
/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