From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
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 18:07:56 +0000 [thread overview]
Message-ID: <nk8ihWbf71QT6w-wVbnunppF_DjS8ywDoDAugBj5mYM_LCpSzec0j6lkaTKBK4t3CsXwRSXWmzbWiW7nmqT4y0W2fn8X-3oXv-TAYXwP1R4=@protonmail.com> (raw)
In-Reply-To: <CALFqKjQkQwuxjeYkGWO_Y_HhNQmJgrjqF3m04hbORV7FSbsi3Q@mail.gmail.com>
Good morning Mike,
> PubRef is not susceptible to malleability attacks because the blockchain is immutable.
This is not quite accurate.
While very old blocks are indeed immutable-in-practice, chain tips are not, and are often replaced.
At least specify that such data can only be referred to if buried under 100 blocks.
--
There are a number of other issues:
* It strongly encourages pubkey reuse, reducing privacy.
* There is a design-decision wherein a SCRIPT can only access data in the transaction that triggers its execution.
In particular, it cannot access data in the block the transaction is in, or in past blocks.
For example, `OP_CHECKLOCKTIMEVERIFY` does not check the blockheight of the block that the transaction is confirmed in, but instead checks only `nLockTime`, a field in the transaction.
* This lets us run SCRIPT in isolation on a transaction, exactly one time, when the transaction is about to be put into our mempool.
When a new block arrives, transactions in our mempool that are in the block do not need to have their SCRIPTs re-executed or re-validated.
> In order for a client to make use of the PUBREF operations they’ll need access to a database that look up public-keys and resolve their PUBREF index. A value can be resolved to an index with a hash-table lookup in O(1) constant time. Additionally, all instances of PUSHDATA can be indexed as an ordered list, resolution of a PUBREF index to the intended value would be an O(1) array lookup. Although the data needed to build and resolve public references is already included with every full node, additional computational effort is needed to build and maintain these indices - a tradeoff which provides smaller transaction sizes and relieving the need to store repetitive data on the blockchain.
This is not only necessary at the creator of the transaction --- it is also necessary at every validator.
In particular, consider existing pruning nodes, which cannot refer to previous block data.
We would need to have another new database containing every `PUSHDATA` in existence.
And existing pruning nodes would need to restart from genesis, as this database would not exist yet.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-07-19 18:08 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 [this message]
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='nk8ihWbf71QT6w-wVbnunppF_DjS8ywDoDAugBj5mYM_LCpSzec0j6lkaTKBK4t3CsXwRSXWmzbWiW7nmqT4y0W2fn8X-3oXv-TAYXwP1R4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--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