Date: Mon, 29 Jul 2019 02:49:04 +0000
To: Mike Brooks <m@ib.tc>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <dNlv6xp0FTd29mczIiw3uOIoDYcTMV44Az0UZ53XQs_8PGzmnMIBhses0kU_SpOZGUcNzWRlerJEZm-p3YQ8USNIxPBouVZdWYCa7HcxDG0=@protonmail.com>
In-Reply-To: <CALFqKjTfFJATAELn4F0vBGsjorH3a8nzwwtKfXNz_vgWC5XPTg@mail.gmail.com>
References: <CALFqKjQkQwuxjeYkGWO_Y_HhNQmJgrjqF3m04hbORV7FSbsi3Q@mail.gmail.com>
	<nk8ihWbf71QT6w-wVbnunppF_DjS8ywDoDAugBj5mYM_LCpSzec0j6lkaTKBK4t3CsXwRSXWmzbWiW7nmqT4y0W2fn8X-3oXv-TAYXwP1R4=@protonmail.com>
	<CALFqKjQoA+4XKGePHEK9OAZv2+qg=Q669v=f=MpDtg4F3Fx4kQ@mail.gmail.com>
	<dW426iyRLdy0-CbpWL9pG7dG8qvmyQizPrwuBVHpblJBCBDSMjeIuFMiTjNHOaMfUzjaW2btTiFD9PiozOt9Cv5DQUZG0o22hYndr2wk3SI=@protonmail.com>
	<CALFqKjTfFJATAELn4F0vBGsjorH3a8nzwwtKfXNz_vgWC5XPTg@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
Precedence: list

Good morning Mike,

> =C2=A0I think that this implication affects other applications built on t=
he 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 a=
gain.
There is admittedly a risk of double-spending, but each individual applicat=
ion can just spend deeply-confirmed transactions, and tune what it consider=
s "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 i=
n a `scriptPubKey` that uses `OP_PUBREF` is large enough, it may justify th=
e cost of history rewrites --- but if the value is small, the individual ap=
plication (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-co=
nfirmed" point that is deep enough for *all* cases, unlike applications **o=
n top of the blockchain** which can tune their rule of "deeply-confirmed" b=
ased on value.
Thus my suggestion to use 100, which we consider "deep enough" to risk allo=
wing miners to sell their coins.

Lightning uses a "short channel ID" which is basically an index of block nu=
mber + index of transaction + index of output to refer to channels.
This is not a problem, however, even in case of short-ranged history rewrit=
es.
The short channel ID is only used for public routing.
Between the channel counterparties, no security is based on short channel I=
D 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).

> =C2=A0> There is a potential for a targeted attack where a large payout g=
oing to a `scriptPubKey` that uses `OP_PUBREF` on a recently-confirmed tran=
saction finds that recently-confirmed transaction is replaced with one that=
 pays to a different public key, via a history-rewrite attack.
> =C2=A0> Such an attack is doable by miners, and if we consider that we ac=
cept 100 blocks for miner coinbase maturity as "acceptably low risk" agains=
t miner shenanigans, then we might consider that 100 blocks might be accept=
able for this also.
> =C2=A0> Whether 100 is too high or not largely depends on your risk appet=
ite.
>
> I agree 100% this attack is unexpected and very interesting.

It is precisely because of this possibility that we tend to avoid making SC=
RIPT 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 reo=
rganization (increasing validation CPU load), unless we do something like "=
only allow `OP_PUBREF` to data that is more than 100 blocks confirmed".

>=C2=A0 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 tes=
tnet to see what happens.=C2=A0 Do you know if anyone has pushed these limi=
ts?=C2=A0 I am so taken by this attack I might attempt it.
>
> =C2=A0> Data derived from > 220Gb of perpetually-growing blockchain is ha=
rdly, to my mind, "only needs an array".
>
> There are other open source projects that have to deal with larger data s=
ets and have accounted for the real-world limits on computability. Apache H=
TTPD's Bucket-Brigade comes to mind, which has been well tested and can acc=
ount for limited RAM when accessing linear data structures. For a more gene=
ral purpose utility leveldb (bsd-license) provides random access to arbitra=
ry data collections.

Which is the point: we need to use something, the details need to be consid=
ered during implementation, implementation details may leak in the effectiv=
e spec (e.g. DER-encoding), etc.

>=C2=A0 Pruning can also be a real asset for PubRef.  If all transactions f=
or 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 no=
w be used in a *future* `OP_PUBREF`.

Further, pruned nodes are still full validators --- transactions may be pru=
ned, 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