From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1US44J-0001yn-MM for bitcoin-development@lists.sourceforge.net; Tue, 16 Apr 2013 11:28:59 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.102 as permitted sender) client-ip=62.13.148.102; envelope-from=pete@petertodd.org; helo=outmail148102.authsmtp.net; Received: from outmail148102.authsmtp.net ([62.13.148.102]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1US44H-0007io-Il for bitcoin-development@lists.sourceforge.net; Tue, 16 Apr 2013 11:28:59 +0000 Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r3GBSoTq037468 for ; Tue, 16 Apr 2013 12:28:50 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r3GBSi46053407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 16 Apr 2013 12:28:47 +0100 (BST) Date: Tue, 16 Apr 2013 07:28:14 -0400 From: Peter Todd To: Bitcoin Dev Message-ID: <20130416112814.GA22859@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: cdf9c0eb-a688-11e2-b10b-0025903375e2 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgN1 IQgLXVBSFQZ4AB4L BBYUVh48cANYeX5u ZEFqQHFbVVt/fUFi QwAWFhp0Bj5kbmAa U0RYcE1VcQNKelEW PgZ2B3NYM3hWYHJo WlZqMmp0N2wHImEN GltQfApJGhlWE2Qq fR1QVQYlHFEOQCQ1 GlQLLFcWGEtZLlV6 K1Y5XVsTPhofDBEW GEcFHCJCO18MW2xj TUgAABdAUVUA X-Authentic-SMTP: 61633532353630.1019:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/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: 1US44H-0007io-Il Subject: Re: [Bitcoin-development] [bitcoin] Enable tx replacement on testnet. (#2516) 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: Tue, 16 Apr 2013 11:28:59 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2013 at 04:59:33PM -0700, Pieter Wuille wrote: > How about: keep a counter in the mempool, remembering the sum of the size= s of all replacements a transaction has had. When deciding whether to accep= t a transaction as a replacement, increase this number and then check wheth= er its fee is enough for that size. That's certainly overkill, as it will c= orrectly count network and processing overhead, but not blockchain or UTXO = burdening (as those only happen after finalizing). In any case, it's easy t= o implement, seems safe to me, and would at least allow experimenting with = this on testnet. Thoughts: 1) IsNewerThan() returns false if vin.size() !=3D old.vin.size(), or if any= of the prevouts (txhash/vout #) don't match. In other words the inputs to a transaction can't be changed by the current transaction replacement mechanism. 2) If not for transaction replacement, nSequence could have been a boolean = flag called fIgnoreLockTime. 3) The nSequence part of IsNewerThan() is essentially just another type of zero-conf transaction where you trust miners and relaying nodes to do wh= at you tell them too. We shouldn't encourage zero-conf transactions. 4) Testnet may be for testing, but we know tx-replacement is trivially DoS-= able right now. Those who want to experiment with attacks and counter measures should do so in a way that doesn't disrupt testnet for everyone - settin= g up their own tx-replacement enabled nodes is easy to do. 5) Zero-conf transactions, replacement or otherwise, have issues with conse= nsus failure when network bandwidth is limited. In particular even if we requ= ire each re-broadcast of a transation to be accompanied by an increase in the fees it pays, fees +=3D new tx size * MIN_RELAY_FEE has been proposed by= a few people for instance, the cost to different nodes for that bandwidth is d= ifferent. While less of an issue with 1MB blocks, with large blocks, especially bl= ocksizes only limited by what miners think is reasonable considering available network bandwidth, lots of nodes and miners will be bandwidth starved and transaction fees will fall to the marginal cost of the network bandwidth and processing power to handle them. That cost is different for different parties - you definitely won't get consensus and thus zero-conf security in that scenario. 6) Finally zero-conf transactions have issues with consensus failures caused by limited mempool sizes. In any case, the more pressing issue re: replacement is changing fees attached to transactions after they have been broadcast. Lots of users are getting their transactions stuck with few options to fix them. The more I think about the issue the more I think we should nip this zero-conf madness in the bud: change the relay rules so that transactions are replaced based on fees regardless of how that changes transaction outputs. Of course, this does make double-spending an unconfirmed transaction trivial. On the other hand, this makes changing fees after the fact trivial, and it lets us implement a limited 'undo' button for when people screw up. It also allows for many of the applications transaction replacement was meant for in the first place anyway, and all the applications where it's actually secure. We keep saying over and over again to stop accepting zero-conf transactions, but people do it anyway because it seems secure. It's a very dangerous situation because the security of zero-conf transactions can change overnight simply by some fraction of the hashing power implementing that exact change. Some thought is required as to exactly what "replace by fees" looks like, economically optimal is a bit complex due to it's dependency on overall mempool backlog, but a rough first version should be easy to hammer out. Funny enough though: I'm working on a trusted-third-party ledger design, intentially made to be close to 100% compatible with standard Bitcoin, and in that system tx-replacement by nSequence will be a perfectly reasonable thing to do. --=20 'peter'[:-1]@petertodd.org --T4sUOijqQbZv57TR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRbTXNAAoJEH+rEUJn5PoE3cQH/jjQT3Vhsi10xRjGWUhHpxEB gt88tdAavSylriB7hM4VZcWV70s0d9bhhl/+X9yGZcYTZTFfE7f8hDTT6TzZCvRT AEJG0kGlkzT79iCtDibSa/ZTa1+xsRtcVo8C8BWaEO2rQRZMlPndcYRID+7SVXlx eVg3JPrTZMdsDLxkE5Ebj1cwT46/Uup3y/H9H0az9jvpMb/qcne5mvQW9hNYJnsk Y84ThX0o+pA9pRsfXs+r87tbXyiNVhQrxCg3W8cc85H3ZzMLHlf0GtQqBfb0U72r QtWWagCcDCaDFwcgeO1D9i5w0eDwat2CeGA5U+qrW4+e0S95o8GGxR4WbY+rOeo= =u4Yc -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR--