On Thu, Jul 31, 2014 at 6:06 PM, Peter Todd <p...@petertodd.org> wrote: > 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.
I think this would be compatible with most uses of nLockTime -- e.g., at the time a refund transaction becomes broadcastable, its beneficiary would usually have no reason to wait for a long time before broadcasting it; if they did so (probably because they weren't online to redeem the refund), they'd need to use the submit-directly-to-miner option, but they wouldn't lose their refund. > 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. Perpetuating transactions that have been in mempools for a long time and are not being confirmed has been cited as a reason for nodes not to exchange mempools (#3721, #1833, #3722); it's been implied that it would be desirable for wallets to wait until a transaction had had a chance to be accepted before double-spending with a higher fee (#3722); and an unconfirmed transaction-age-based policy for preventing mempool accumulation has been advocated (#3753, #3722) [I hope my summarization is not misrepresenting anyone's opinions here; please see the arguments made in the actual comments on the bugs]. These discussions are mostly fairly old, but I don't know of any changes that have been made that provide alternative answers to these concerns mentioned by at least three different developers. > In any case, lifetimes will never be deterministic as not everyone runs > the same software. That's true, but none of the benefits of these changes require the policy to be unanimous; most of the effect could be provided by most of the network following these rules. >> 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. Yes, that is a feature. None of the benefits of transaction expiration rely on expiration being final, and any possible downsides of expiration are largely mitigated by the option still being available to get expired transactions mined. ------------------------------------------------------------------------------ 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
