[Bitcoin-development] deterministic transaction expiration
tomh at thinlink.com
Fri Aug 8 17:38:08 UTC 2014
Having explored more drastic approaches, it looks like Kaz' basic idea
stands well. His #1...
> 1. start setting nLockTime to the current height by default in newly
> created transactions (or slightly below the current height, for
is already implemented in bitcoin-qt #2340, and a "final call" on
merging it was already sent to this list. After some thought I agree
with its policy of eventually setting nLockTime at current-height + 1 by
default. This is the "best reasonably expected height" of any tx
created right now. It discourages fee-sniping, and if a reorg happens
anyway, it won't actually delay inclusion of tx beyond the reasonable
expectation sans reorg.
However right now, #2340 takes a very cautious approach and sets to
current-height - 10 by default, with randomness to mitigate worries
about loss of privacy.
Kaz' #2, #3 and #4 are future actions. #4 only goes most of the way ...
> 4. add a new IsStandard rule rejecting transactions with an nLockTime
> more than N blocks behind the current tip (for some fixed value N, to
> be determined)
... a janitor mechanism is desirable to purge mempool of txes more than
N behind current-height.
Nodes dropping a tx N blocks after they became eligible to be mined (the
meaning of nLockTime) makes sense. It is not an overloading or new use
for nLockTime, but a logical extension of it. As Kaz pointed out, this
solves a big problem with expiring by locally measured age:
More information about the bitcoin-dev