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; 
Date: Fri, 1 Aug 2014 01:06:57 +0000
From: Peter Todd <pete@petertodd.org>
To: Kaz Wesley <keziahw@gmail.com>
Message-ID: <20140801010657.GA15436@localhost.localdomain>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq"
Content-Disposition: inline
In-Reply-To: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
Precedence: list


--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--