From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XD1Jh-0001Ox-No for bitcoin-development@lists.sourceforge.net; Fri, 01 Aug 2014 01:07:29 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.112 as permitted sender) client-ip=62.13.148.112; envelope-from=pete@petertodd.org; helo=outmail148112.authsmtp.co.uk; Received: from outmail148112.authsmtp.co.uk ([62.13.148.112]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XD1Jg-00089j-Ao for bitcoin-development@lists.sourceforge.net; Fri, 01 Aug 2014 01:07:29 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s7117KkT081939; Fri, 1 Aug 2014 02:07:20 +0100 (BST) Received: from localhost.localdomain (freeciv.nmte.ch [195.154.251.25]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s711775K059336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 1 Aug 2014 02:07:14 +0100 (BST) Date: Fri, 1 Aug 2014 01:06:57 +0000 From: Peter Todd To: Kaz Wesley Message-ID: <20140801010657.GA15436@localhost.localdomain> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 2dd241bb-1918-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgMUGUATAgsB AmIbW1ZeUFp7WGU7 agNUcwRYZlRMWgR0 Uk1WR1pVCwQmQhsA BxkZV2JycgxFe3g+ bERiXz5ZCBB4cUcv EFNVHGwOeGZhPWQC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4HEyIx XRUDGzQ0AUwODzkp Jho9I1UAHUEXekgi KVo7UE4ZNBl6 X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 195.154.251.25/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: 1XD1Jg-00089j-Ao Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] deterministic transaction expiration 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: Fri, 01 Aug 2014 01:07:29 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 31, 2014 at 05:58:23PM -0700, Kaz Wesley wrote: > I have a proposal for a way to add finite and predictable lifespans to > transactions in mempools: we d=CC=B6e=CC=B6s=CC=B6t=CC=B6r=CC=B6o=CC=B6y= =CC=B6 =CC=B6t=CC=B6h=CC=B6e=CC=B6 > =CC=B6r=CC=B6e=CC=B6s=CC=B6u=CC=B6r=CC=B6r=CC=B6e=CC=B6c=CC=B6t=CC=B6i=CC= =B6o=CC=B6n=CC=B6 =CC=B6h=CC=B6u=CC=B6b=CC=B6 use nLockTime and a new stand= ardness > rule. It could be done in stages, would not necessarily require even a > soft fork, and does not cause problems with reorgs like the proposal > in #3509: Anything that changes the semantics of nLockTime will do harm to existing and future applications that make use of nLockTime for things like refund transactions. In any case, why do transactions need finite lifespans in mempools? If you want to double-spend them with higher fees, then implement replace-by-fee. In any case, lifetimes will never be deterministic as not everyone runs the same software. > Transactions would stop being relayed and drop out of mempools a fixed > number of blocks from their creation; once that window had passed, the > sender's wallet could begin to expect the transaction would not be > confirmed. In case a reorg displaces a transaction until after its > expiry height, a miner can still put it back in the blockchain; the > expiry height is just a relay rule. Also, a user who needed to get > their original "expired" transaction confirmed could still do so by > submitting it directly to a miner with suitable policies. =2E..in which case someone will circumvent this IsStandard() rule by submitting "expired" transactions directly to miners with suitable policies. --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJT2ugpAAoJEH+rEUJn5PoEZuAH/RPEfJK9qv1XZOaVNtF52JF2 6Oe+qewpyXIDOgx8ChwkWLs4OvvZrebUOY4jbyTzwZeEMWHMJJYnYnfxiFVddz59 kj2oZn2S62UJwKu2tV0jWk8zOZ4wsadZ7Yysb0PUfpQqwmuxvDFiUawl2ceAXKZ1 h8UU0wqF1KCBoEpCD8erwnu1oFVFgP1lAC6XHUej7fn960SvGySZvmPVEbZlx0fe /+w8c2tikdcwq2wje3snSTFXPMmmKcPgkxkp0R1+jufMT7fpyva6jnJBiLipSKrL qPXkLYUw46q44kTc5tMei16m9sULShrxAsA1mqJiHpCIHZehB6dOdV64yrPz8rE= =63mB -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq--