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 > reorg-friendliness) 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: unintentional resurrection. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
