From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UaPIn-0005oL-EI for bitcoin-development@lists.sourceforge.net; Thu, 09 May 2013 11:46:25 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.113 as permitted sender) client-ip=62.13.148.113; envelope-from=pete@petertodd.org; helo=outmail148113.authsmtp.com; Received: from outmail148113.authsmtp.com ([62.13.148.113]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UaPIm-0004ym-1S for bitcoin-development@lists.sourceforge.net; Thu, 09 May 2013 11:46:25 +0000 Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233]) by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r49BkBW5045052; Thu, 9 May 2013 12:46:11 +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 r49Bk6Es016390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 9 May 2013 12:46:09 +0100 (BST) Date: Thu, 9 May 2013 07:46:05 -0400 From: Peter Todd To: Adam Back Message-ID: <20130509114605.GA28133@savin> References: <20130509111913.GA15870@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20130509111913.GA15870@netbook.cypherspace.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 0acb9d2c-b89e-11e2-a49c-0025907707a1 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgsUFVQNAgsB AmUbWlZeVFt7WWo7 bAxPbAVDY01GQQRq WVdMSlVNFUsqBRVz XRhrERlzcQZPeDBx YUdiWj5bDRcofBJ/ EVMGHWRTeGZhPWIC AURRJB5UcAFPdx9C bVB4BXJDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4iGHY9 QREeHDwrVVcIXyE6 JBFjIE9ZEkscekQ3 KV8sXF8eLxYOCwpY fQlMG2dfIEZJTjQi DAdTV0oTeAAA X-Authentic-SMTP: 61633532353630.1021: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: 1UaPIm-0004ym-1S Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] An initial replace-by-fee implementation is now available 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, 09 May 2013 11:46:25 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 09, 2013 at 01:19:13PM +0200, Adam Back wrote: > In this thread discussing this idea >=20 > https://bitcointalk.org/index.php?topic=3D179612.0=20 >=20 > it is suggested that the approach risks making 0-confirm double-spends > easier. The patch makes the concept of a 0-confirm double-spend obsolete basically. The model is rather than having some vague, insecure, easily broken, de-facto no-replacement rule it replaces it with something very easy to reason about: you are bidding for blockchain space, and you can adjust your bid after the fact. The reality is zero-conf double-spends aren't that big of a problem because the vast majority of payments have other mechanisms they can use instead of relying on the defacto behavior of dozens of major miners and nodes. Long story short, we're better off if we don't give people a false sense of security. > I dont see why this should be. Cant part of the validation of accepting a > fee revision be that every aspct of the revision except the reward must be > unchanged, otherwise the revision is considered invalid and discarded? A node has no idea which transaction output is change and which one isn't; if nodes could distinguish change from payment your privacy would be badly violated. By allowing simple replacement without further rules the fee adjustment process can go on as long as required, without you running out of additional transaction inputs and without causing the transaction to get bigger and bigger each time. It also allows more interesting use cases, like adding additional outputs to a transaction after the fact as more payees become known, or if two unrelated parties decide to combine their transactions to save on blockchain space and preserve their privacy. Eventually the P2P protocol can have delta compression support, so the network bandwidth required to merge two transactions into one will be minimal. --=20 'peter'[:-1]@petertodd.org 000000000000014c26728a13e351b4dd7a32e99e28d43a960b5ac5f98696ae5b --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRi4x9AAoJECSBQD2l8JH7BWEH/iyuqSinA8b+BnxXhKMqK2rD KtU+jONQt0Z+P8b442hY+nWOkbs1DZaa/mZeDwT4kzuSRfNg0d9aTc1xUCccACuD vCGtRyCx/68XMv/zq06TD2Hx6IF4hEmzUN7Vx3C/mbafCnuavB/UmGp6IlpeN9uD 7FVw1vORh/RfHhR0CvPy3cW0AjnjooQ4YyyrlcLJwVOokGjM9jObcETIE4/PjMDl Ky/e37vTy3kJKRkqnqLeOLl8dj4emfkmI9sDIApJzh0dhtNrvh+3az2h/aqi37tW dhYIQqfS4QSdIvOnxXggyVEou2UC00WAZR5wpvzvEmdkY8fvtc3MKo4w1JQK7vs= =XzPs -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO--