...and existing users and uses of nLockTime suddenly become worthless, breaking payment channel refunds and other active uses of nLockTime.
You cannot assume the user is around to rewrite their nLockTime, if it fails to be confirmed before some arbitrary deadline being set.
On Wed, Aug 6, 2014 at 12:01 AM, Tom Harding <tomh@thinlink.com> wrote:
On 8/5/2014 12:10 PM, Kaz Wesley wrote:It's hard to argue with that logic.
> Any approach based on beginning a transaction expiry countdown when a
> transaction is received (as in mempool janitor) seems unviable to me:
> once a node has forgotten a transaction, it must be susceptible to
> reaccepting it;
If nLockTime is used for expiration, transaction creator can't lie to
help tx live longer without pushing initial confirmation eligibility
into the future. Very pretty. It would also enable "fill or kill"
transactions with a backdated nLockTime, which must be confirmed in a
few blocks, or start vanishing from mempools.
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development