Re: [Bitcoin-development] deterministic transaction expiration

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

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̶e̶s̶t̶r̶o̶y̶ ̶t̶h̶e̶
> ̶r̶e̶s̶u̶r̶r̶e̶c̶t̶i̶o̶n̶ ̶h̶u̶b̶ use nLockTime and a new standardness
> 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.

...in which case someone will circumvent this IsStandard() rule by
submitting "expired" transactions directly to miners with suitable
policies.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]