From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Jeff Garzik Message-ID: <20130718134347.GB28234@petertodd.org> References: <20130718111353.GA11385@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline In-Reply-To: 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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--