1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6CA23E9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jul 2019 02:49:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BAAD5E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jul 2019 02:49:11 +0000 (UTC)
Date: Mon, 29 Jul 2019 02:49:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1564368548;
bh=ti7O3uSuJnTJSz9H1EZF1zlbjRK0iQdfPEQCd+EnO30=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=PZL5D+zytKZqOq8zGZByPmokqDvHpRXzmxtbBbizY14d7+dnnK/dy8j5rqBrV2mKw
CKrrlM9f3WRhRb0tSLukTvlDcm5a8BYnaiarMp/HPzM5UlRntZH2PJhhC8TVtRAPRo
g5B22nsHfQ815WFWsOMPl8Wn8tQx2C8xdNTPMbdM=
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
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 29 Jul 2019 02:53:15 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2019 02:49:12 -0000
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
|
