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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1UzoV5-00052p-UO
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jul 2013 13:44:07 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.58 as permitted sender)
client-ip=62.13.149.58; envelope-from=pete@petertodd.org;
helo=outmail149058.authsmtp.co.uk;
Received: from outmail149058.authsmtp.co.uk ([62.13.149.58])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UzoV1-0002kH-96 for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jul 2013 13:44:07 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt14.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6IDhtnF025562;
Thu, 18 Jul 2013 13:43:55 GMT
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6IDhmS4054331
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 18 Jul 2013 14:43:50 +0100 (BST)
Date: Thu, 18 Jul 2013 09:43:47 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeff Garzik <jgarzik@bitpay.com>
Message-ID: <20130718134347.GB28234@petertodd.org>
References: <CA+CODZEQX_xiaJE7WtFZC2qfVfDqZAgg-ydU5Q73O-QTkXJpPw@mail.gmail.com>
<20130718111353.GA11385@savin>
<CAJHLa0M+LNuEa6j3RN-e1JLA2Q35-mjCo+AhOSJdoxBA6Vm1ow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm"
Content-Disposition: inline
In-Reply-To: <CAJHLa0M+LNuEa6j3RN-e1JLA2Q35-mjCo+AhOSJdoxBA6Vm1ow@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 146724da-efb0-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwoUEkAYAgsB AmUbWlBeVF57XGI7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQxp4 ckZDMR1ycgFFe38+ ZEViXXYVXUB8ckR5
Fh9JQDtUZXphaTUd TRJZd1FJcANIexZF aVN4USYPLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNzgg RlguGg5nE0ofDzkj
ZwYrMloVF0sUP0Mu WQAA
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1UzoV1-0002kH-96
Cc: bitcoin-development@lists.sourceforge.net,
Jeremy Spilman <jeremy.spilman@gmail.com>
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2013 13:44:08 -0000
--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jul 18, 2013 at 08:53:55AM -0400, Jeff Garzik wrote:
> On Thu, Jul 18, 2013 at 7:13 AM, Peter Todd <pete@petertodd.org> wrote:
> > Note that with OP_DEPTH we can remove the small chance of the payee
> > vanishing and putting the funds in limbo:
>=20
> What are the costs, benefits, and risks associated with scripts no
> longer being stateless, as OP_DEPTH would seem to introduce?
Satoshi was worried that in the event of a re-org long chains of
transactions could become invalid and thus impossible to include in the
blockchain again, however that's equally possibly through tx mutability
or double-spends;(1) I don't think it's a valid concern in general. When
accepting any payment you need to take the chance of a re-org into
account, and if the payment is large enough it'll call for more confirms
on that basis. It does increase that (small) risk however and a client
may want to trace the transaction chain back a few steps when accepting
a very large payment in leu of just waiting for more confirms.
1) Also via non-standard transactions as SetBestChain() calls
mempool.accept() which still applies IsStandard(). We also recently
broke re-acceptance of transactions with dependencies as they are
currently added in reverse order, broken when Matt removed the
fIgnoreMissingInputs flag.
Not a problem limited to OP_DEPTH either: consider the following
probabalistic payment:
PREVBLOCKHASH HASH n LESSTHAN VERIFY <pubkey> CHECKSIG
Obviously in a re-org the chance of it being succesfully included is
slim. (this example is simplistic and is vulnerable to double-spends in
a number of ways)
Mempool and relay code will have to take into account that a transaction
that can be included in the next block may not be possible to include in
the block after that for the purposes of protecting against tx-flood DoS
attacks - not an important issue unless we loosen IsStandard()
--=20
'peter'[:-1]@petertodd.org
0000000000000090344430e3956a709039288ceeb473fff6c1b68e70ee7169c4
--V0207lvV8h4k8FAm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlHn8RMACgkQpEFN739thozcYwCcCLWwKyj92UyY/4b9k4fnVIw9
PO8An3tT/hp32Bb6ehd1E7+h/H/5c9RT
=k7DX
-----END PGP SIGNATURE-----
--V0207lvV8h4k8FAm--
|
