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 02:49:04 +0000 [thread overview]
Message-ID: <dNlv6xp0FTd29mczIiw3uOIoDYcTMV44Az0UZ53XQs_8PGzmnMIBhses0kU_SpOZGUcNzWRlerJEZm-p3YQ8USNIxPBouVZdWYCa7HcxDG0=@protonmail.com> (raw)
In-Reply-To: <CALFqKjTfFJATAELn4F0vBGsjorH3a8nzwwtKfXNz_vgWC5XPTg@mail.gmail.com>
Good morning Mike,
> I think that this implication affects other applications built on the blockchain, not just the PubRef proposal:
>
I believe not?
Current applications use txids to refer to previous transactions, so even a short-ranged history rewrite will mostly not affect them --- they can just rebroadcast the transactions they are spending and get those reconfirmed again.
There is admittedly a risk of double-spending, but each individual application can just spend deeply-confirmed transactions, and tune what it considers "deeply-confirmed" depending on how large the value being spent is.
The point is that history rewrites are costly, but if the value being put in a `scriptPubKey` that uses `OP_PUBREF` is large enough, it may justify the cost of history rewrites --- but if the value is small, the individual application (which refers to transactions by their txid anyway) can generally assume miners will not bother to history-rewrite.
Since `OP_PUBREF` would be a consensus rule, we need to select a "deeply-confirmed" point that is deep enough for *all* cases, unlike applications **on top of the blockchain** which can tune their rule of "deeply-confirmed" based on value.
Thus my suggestion to use 100, which we consider "deep enough" to risk allowing miners to sell their coins.
Lightning uses a "short channel ID" which is basically an index of block number + index of transaction + index of output to refer to channels.
This is not a problem, however, even in case of short-ranged history rewrites.
The short channel ID is only used for public routing.
Between the channel counterparties, no security is based on short channel ID being stable; it just loses you potential routing fees from the channel (and can be fixed by increasing your "deeply-confirmed" enough level before you announce the channel for public routing).
> > 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.
>
> I agree 100% this attack is unexpected and very interesting.
It is precisely because of this possibility that we tend to avoid making SCRIPT validity dependent on anything that is not in the transaction.
We would have to re-evaluate the SCRIPT every time there is a chain tip reorganization (increasing validation CPU load), unless we do something like "only allow `OP_PUBREF` to data that is more than 100 blocks confirmed".
> However, I find the arbitrary '100' to be unsatisfying - I'll have to do some more digging. It would be interesting to trigger this on the testnet to see what happens. Do you know if anyone has pushed these limits? I am so taken by this attack I might attempt it.
>
> > Data derived from > 220Gb of perpetually-growing blockchain is hardly, to my mind, "only needs an array".
>
> There are other open source projects that have to deal with larger data sets and have accounted for the real-world limits on computability. Apache HTTPD's Bucket-Brigade comes to mind, which has been well tested and can account for limited RAM when accessing linear data structures. For a more general purpose utility leveldb (bsd-license) provides random access to arbitrary data collections.
Which is the point: we need to use something, the details need to be considered during implementation, implementation details may leak in the effective spec (e.g. DER-encoding), etc.
> Pruning can also be a real asset for PubRef. If all transactions for a wallet have been pruned, then there is no need to index this PubRef - a validator can safely skip over it.
What?
The problem with transaction being pruned is that the data in them might now be used in a *future* `OP_PUBREF`.
Further, pruned nodes are still full validators --- transactions may be pruned, but the pruned node will ***still*** validate any `OP_PUBREF` it uses, because it is still a full validator, it just does not archive old blocks in local storage.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-07-29 2:49 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
2019-07-29 2:19 ` Mike Brooks
2019-07-29 2:49 ` ZmnSCPxj [this message]
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='dNlv6xp0FTd29mczIiw3uOIoDYcTMV44Az0UZ53XQs_8PGzmnMIBhses0kU_SpOZGUcNzWRlerJEZm-p3YQ8USNIxPBouVZdWYCa7HcxDG0=@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