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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 34E808D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 09:16:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 99B11166
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 09:16:16 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id C1B6538ABEDA;
Wed, 29 Mar 2017 09:15:59 +0000 (UTC)
X-Hashcash: 1:25:170329:bitcoin-dev@lists.linuxfoundation.org::G4R/OD+ad=mAZeAH:5pNr
X-Hashcash: 1:25:170329:da2ce7@gmail.com::8yxUdR5ac7=EdsJo:aQ356
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Cameron Garnham <da2ce7@gmail.com>
Date: Wed, 29 Mar 2017 09:15:57 +0000
User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; )
References: <07F54C7C-5F26-446D-A479-7F81BD131151@gmail.com>
In-Reply-To: <07F54C7C-5F26-446D-A479-7F81BD131151@gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201703290915.58724.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Strong Anti-Replay via Coinbase Transactions
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: Wed, 29 Mar 2017 09:16:17 -0000
On Saturday, March 25, 2017 3:30:22 AM Cameron Garnham via bitcoin-dev wrot=
e:
> =3D=3DDefinitions=3D=3D
It's blank?
> =3D=3DSpecification=3D=3D
>=20
> Upon activation of the soft-fork (activation methodology undefined in this
> proposal), the following new rules become activated on the Bitcoin
> Network.
The activation methodology should be defined. It can be a TODO for now.
> New =E2=80=98anti-replay=E2=80=99 OpCode. Take an unused NoOp and redefi=
ne it as
> =E2=80=98OP_ANTI_REPLAY=E2=80=99.
Need to be specific about which NOP.
> The script must only have the form:
>=20
> scriptPubKey: (empty)
> scriptSig: OP_ANTI_REPLAY
>=20
> OP_ANTI_REPLAY has the following specification:
>=20
> =E2=80=A2 OP_ANTI_REPLAY outputs must only be created in a coinbase tran=
saction.
This is contradicting. scriptSig is not part of an output. Did you get the =
two=20
scripts inverted?
> =E2=80=A2 OP_ANTI_REPLAY coinbase outputs must only have the value of 1 =
Satoshi.
Why burn a satoshi?
> =E2=80=A2 Transaction must not included more than 1 OP_ANTI_REPLAY input.
include*
> =E2=80=A2 If a OP_ANTI_REPLAY input is included in a transaction, the tr=
ansaction
> must also be marked as Opt-In-RBF (BIP 125).
This is a layering violation. BIP 125 does not affect the consensus rules.
> In the case of an chain split after this BIP has activated, miners should
> =E2=80=98recycle=E2=80=99 all the OP_ANTI_REPLAY outputs via spending and=
recreating them
> in new blocks. Renewing the protection to the new chain.
*a* chain split
This recycling is going to be pretty spammy... especially if transactions a=
re=20
limited to one each.
Chain splits also happen regularly (probably at least once or twice every f=
ew =20
hundred blocks). Since generated UTXOs cannot be spent for 100 blocks, it i=
s=20
likely anything using this would require constant updating.
It also requires active awareness from the miner that a split is occurring.=
=20
Usually, this is not known until the block is solved, and it is too late to=
=20
make these recycling transactions.
> =3D=3D=3D Reference implementation =3D=3D=3D
>=20
> To-Be-Implemented
I don't think it's possible to implement for the reasons mentioned above.
> =3D=3DRationale=3D=3D
>=20
> The only know way of guaranteeing that a transaction cannot be replayed is
> to include an input that cannot exist, by-definition, on the alternative
> chain.
known*
Another way is to commit to a specific chain explicitly, as with my propose=
d=20
OP_CHECKBLOCKATHEIGHT.
> This BIP makes it convenient for wallets to automate the inclusion of new
> coinbase inputs into transactions that spend potentially repayable
> transactions. Everything in this BIP could be done manually by close
> cooperation between the users and miners, however the author thinks that
> it is preferable to have it well-defined and enforced.
>=20
> On Opt-In-RBF enforcement: In the case of conflicting spends of
> OP_ANTI_REPLAY outputs, the higher-fee transaction should take priority.=
=20
> Wallets may select a random OP_ANTI_REPLAY, then check if the competing
> transaction has a sufficiently low fee to be replaced.
This isn't convenient. Most wallets have no reasonable way to check if ther=
e=20
are any competing transactions, much less what the fee for them is.
Why not just use a single reserved output, and have it recycle as part of t=
he=20
transactions? This can be done so long as the signature doesn't commit to t=
he=20
recycle input. So for each transaction, there would be an input with the la=
st-
recycle-txid (tracked by the miner as it builds the block), and an output=20
generating the next-recycle-txid. Wallets could just indicate this input to=
be=20
used by providing a special hash as the input which is not covered under th=
e=20
signature.
> It is expected that every OP_ANTI_REPLAY output will be in the memory poo=
ls
> waiting to be spend; users must compete for this resource.
UTXO set, not memory pool?
Luke
|
