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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
Return-Path: <da2ce7@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 07BE241C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Mar 2017 03:30:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com
[209.85.128.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 065191D6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Mar 2017 03:30:26 +0000 (UTC)
Received: by mail-wr0-f194.google.com with SMTP id u1so992727wra.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Mar 2017 20:30:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:content-transfer-encoding:mime-version:subject:message-id:date
:to; bh=Ha7ZxdQYQsG2z3jCp8hdncIlcxLmPXbR/tyYApchE/g=;
b=KWnybV+KfNeJKxFbW1llNLzHhdjvGuEijPPWeCAm/69xupKBSeK1zLJSFOH1jzGjro
bEjfzSrkixoKsIYlzanf7e0zkSTIkheeydoSE+JdkIdALUrHgxUGkhLTB6QLlUt3ugle
baiDecSji+4tuVVjTJOkq66iNv+WaPzXBZ0RAztAy3M+k1Vk8UQ0txTSvRRlomvi/8Rs
5vN5qUBYey+rUoPf7DlaKzjSDK1Nbb7GPb9EmD8nLiGglv2A74Jh9ka5G8TALdssQ2uG
wWjLnp6AlxyQnTgjQCPsBUCZyXDxFMT1rMpBtoZRA35U3W7X8NBZeBBdGC/cgv4RjmUk
d0Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:content-transfer-encoding:mime-version
:subject:message-id:date:to;
bh=Ha7ZxdQYQsG2z3jCp8hdncIlcxLmPXbR/tyYApchE/g=;
b=TvinVZxJ5FOu/9beCWbYNZY9lBtgk8UNOvJYLov3hmLDg62Z8OfH00GVEBuvmB/QwY
3i2Hk+vEwLatjVqoqZ3GL+KeZKVJ0ohaop6Dzho0l892ksp8o5GdQRjH1f8KXJ1FOpIT
5ojOXt7iRI8IZ2qshrVbXxImSjJRQ49LsertA6c3VOiuBP3sQUXr0OcnyADhTGSCZ1/e
d5sHP2Y1FgaQeteLYTDlxJ8lU8rU+RM4eel9Pa85h8uxHjPVIcfB/paRh1aMAqXEWiHy
B5foW7QMd3w/aZulKUMAU5aqT/Jj8EQ19xiMiD9f1zbD/v7KNaIwUiMG58pYWGKQHG4g
gQsA==
X-Gm-Message-State: AFeK/H0unszJE967gMpQS4//0XLVCvKPeyzf0R5ts2OqG5wVgB+O4c1Bb1pG9d/viE4mbQ==
X-Received: by 10.223.136.125 with SMTP id e58mr8668198wre.14.1490412625311;
Fri, 24 Mar 2017 20:30:25 -0700 (PDT)
Received: from camerons-mbp.odessa.tv ([78.26.162.5])
by smtp.gmail.com with ESMTPSA id
n80sm2522645wrb.24.2017.03.24.20.30.23
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 24 Mar 2017 20:30:24 -0700 (PDT)
From: Cameron Garnham <da2ce7@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Message-Id: <07F54C7C-5F26-446D-A479-7F81BD131151@gmail.com>
Date: Sat, 25 Mar 2017 05:30:22 +0200
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3259)
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [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: Sat, 25 Mar 2017 03:30:28 -0000
<pre>
BIP: ???
Layer: Consensus (soft fork)
Title: Strong Anti-Replay via Coinbase Transactions
Author: Cameron Garnham <da2ce7@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???
Status: Draft
Type: Standards Track
Created: 2017-03-25
License: BSD-3-Clause
CC0-1.0
</pre>
=3D=3DAbstract=3D=3D
This document specifies a soft fork that enables users to make =
transactions with a strong expectation that such transactions cannot be =
replayed on a different chain.
Important Note: In the case that an adversary hard-fork, the strong =
guarantee of non-replayabilty via this BIP may not be supported.
=3D=3DDefinitions=3D=3D
=3D=3DMotivation=3D=3D
In the case of a chain split, it is important to protect users from, =
potentially significant, loss of funds from transaction replay attacks.
=3D=3DSpecification=3D=3D
Upon activation of the soft-fork (activation methodology undefined in =
this proposal), the following new rules become activated on the Bitcoin =
Network.
New =E2=80=98anti-replay=E2=80=99 OpCode. Take an unused NoOp and =
redefine it as =E2=80=98OP_ANTI_REPLAY=E2=80=99.
The script must only have the form:
scriptPubKey: (empty)
scriptSig: OP_ANTI_REPLAY
OP_ANTI_REPLAY has the following specification:
=E2=80=A2 OP_ANTI_REPLAY outputs must only be created in a =
coinbase transaction.
=E2=80=A2 OP_ANTI_REPLAY coinbase outputs must only have the =
value of 1 Satoshi.
=E2=80=A2 Transaction must not included more than 1 =
OP_ANTI_REPLAY input.
=E2=80=A2 If a OP_ANTI_REPLAY input is included in a =
transaction, the transaction must also be marked as Opt-In-RBF (BIP =
125).
The Bitcoin Network should maintain a total of exactly 100 000 =
OP_ANTI_REPLAY outputs, with the exception of the the first 99 blocks =
after activation of this soft fork.
Upon activation of this soft fork. Every blocks coinbase transaction =
will be required to create exactly 1000 new OP_ANTI_REPLAY outputs, up =
to the total of 100 000.
If a OP_ANTI_REPLAY is spent in a block, a corresponding new =
OP_ANTI_REPLAY must be included in the same block.
It is recommend the miners account the size of a OP_ANTI_REPLAY =
transaction as: transactions size + size of a OP_ANTI_REPLAY output in =
coinbase.
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.
=3D=3D=3D Reference implementation =3D=3D=3D
To-Be-Implemented
=3D=3DBackwards Compatibility=3D=3D
This deployment is compatible with all existing bitcoin software.
Upon activation, all deployed Bitcoin Full Nodes will enforce the =
anti-replay projections for Bitcoin Users. (Only upgraded nodes will =
enforce the other OP_ANTI_REPLAY requirements).
=3D=3DRationale=3D=3D
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. Coinbase transactions are the only transaction type =
that is know to exhibit this property strongly.
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.
On Opt-In-RBF enforcement: In the case of conflicting spends of =
OP_ANTI_REPLAY outputs, the higher-fee transaction should take priority. =
Wallets may select a random OP_ANTI_REPLAY, then check if the competing =
transaction has a sufficiently low fee to be replaced.
It is expected that every OP_ANTI_REPLAY output will be in the memory =
pools waiting to be spend; users must compete for this resource.
=3D=3DFuture Questions=3D=3D
SegWit Compatibility?
=3D=3DReferences=3D=3D
Opt-In-RBF: =
https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
=3D=3DCopyright=3D=3D
This document is dual licensed as BSD 3-clause, and Creative Commons CC0 =
1.0 Universal.
|
