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: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E91A0CA6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Sep 2016 20:02:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149095.authsmtp.com (outmail149095.authsmtp.com
[62.13.149.95])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 4318928E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Sep 2016 20:02:29 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt24.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u8NK2S9r012857;
Fri, 23 Sep 2016 21:02:28 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u8NK2P4N039664
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Fri, 23 Sep 2016 21:02:26 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 63A8F40192;
Fri, 23 Sep 2016 19:58:39 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 936E42051F; Fri, 23 Sep 2016 16:02:23 -0400 (EDT)
Date: Fri, 23 Sep 2016 16:02:23 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20160923200223.GA24227@fedora-21-dvm>
References: <201609230957.03138.luke@dashjr.org>
<CAMZUoKnY7s1b75Z_0QCb2hh-Q_hCE4-9dZ9tY58HaUQy6=aCbw@mail.gmail.com>
<CAAS2fgQGC695mkyze+mVTZZoQN1mh+1y32u-D6Yv1R7nXWPDcg@mail.gmail.com>
<CAAS2fgTJ9iPoE6fvMBhFB8ruwy-6aTo4Ka5agK+LHjSqGa2-rw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4"
Content-Disposition: inline
In-Reply-To: <CAAS2fgTJ9iPoE6fvMBhFB8ruwy-6aTo4Ka5agK+LHjSqGa2-rw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: a675b47a-81c8-11e6-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAEUC1AEAgsB AmAbWVVeUF97W2U7 bghPaBtcak9QXgdq
T0pMXVMcUQ0Weh5h AmAeURB0cQEIcH1z bQgzWHdeDkB9JFt1
Qx1cCGwHMGF9YGIW BV1YdwJRcQRDe0tA b1YxNiYHcQ5VPz4z
GA41ejw8IwAXAgVt Cg0XJFwOEw4sJgkX Zz0pPh8LOmYmbhkT Aj0JCmJ0
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
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: Fri, 23 Sep 2016 20:02:32 -0000
--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Sep 23, 2016 at 06:57:57PM +0000, Gregory Maxwell via bitcoin-dev w=
rote:
> On Fri, Sep 23, 2016 at 1:43 PM, Russell O'Connor via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I believe Bitcoin currently enjoys the property that during an "innocen=
t"
> > re-org, i.e. a reorg in which no affected transactions are being double
> > spent, all affected transactions can always eventually get replayed, so=
long
> > as the re-org depth is less than 100.
>=20
> > My concern with this proposed operation is that it would destroy this
> > property.
>=20
> The reorg safety impact of this proposal could be eliminated and the
> mempool handling complexity greatly reduced if the transaction was
> required to be locktimed at least 100 blocks after the block its
> referencing.
However, by doing that we'd also make the functionality not all that useful=
for
this application; by the time you waited 100 blocks for the tx to be minabl=
e,
the chance of a reorg happening is low enough that I can't imagine many - if
any - wallets would bother using the opcode in the first place, and would
instead just rely on the fact that a reorg that deep which resulted in the
double-spent transaction ending up back in the chain is very unlikely.
Specifically I'm referring to the following scenario:
1) Alice pays Bob with tx1a
2) tx1a gets N confirmations, where N is some small number of confirmations.
2) Bob pays Charlie from tx1a's output in tx2a
3) A reorg eliminates the block that tx1a existed, and a conflicting tx1b is
mined instead, making tx1a and tx2a invalid.
4) Bob pays Charlie again with tx2b, whose inputs do not conflict with tx2a
5) Another reorg eliminates tx1b, allowing tx1a, tx2a, and tx2b to all be
mined.
6) Charlie has now been paid twice.
Since you need _two_ reorgs for this scenario to be applicable, it's much
easier to just wait for tx1b to be confirmed suffiently deeply in the chain
that a reorg undoing it - thus allowing tx1a and tx2a to exist - is
sufficiently unlikely; 100 blocks is a lot more than most wallets are goin=
g to
consider "sufficiently unlikely", so the featureu just won't get used (assu=
ming
wallets even bother to handle this case of course!).
Unfortunately I think this is an inherent catch-22 of the idea.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--YiEDa0DAkWCtVeE4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJX5YpMAAoJEGOZARBE6K+yVjIH/iywSzjGCl4aFuTd6w4UqUfL
CRnmhwdlH5GEpxKePJinC0kom1eY4Fo2uzK/J7LK9k1ALKbBBEfy88lKiLfj3BIE
Ic7nDAdAayVAZSok86K/C5RqGDx/YSzJHgnfSHwH7LHajrPYWXqPg54fCVHYWQWa
SggNLmrDzzBhdL6Z2bNp/eeYNcGbySI0UZv9SLTo64NvTd7g79HAJPe/bTy3t+bR
FmZRadkMq5VSIhA5/Ttz9m4rNPE09eGI8fhhVovu3hDDDG8+jvkfDIYLyMDn6L15
tkA4cV2Idmal5f7dNfEjLckh1AgV52AQlC/1npVCRETHoHY5ySgpL5ucx/rJB5c=
=mxwq
-----END PGP SIGNATURE-----
--YiEDa0DAkWCtVeE4--
|
