Tom Harding [ARCHIVE] on Nostr: 📅 Original date posted:2014-08-01 📝 Original message:On 7/31/2014 5:58 PM, Kaz ...
📅 Original date posted:2014-08-01
📝 Original message:On 7/31/2014 5:58 PM, Kaz Wesley wrote:
> 1. start setting nLockTime to the current height by default in newly
> created transactions (or slightly below the current height, for
> reorg-friendliness)
Reorg-frendliness is the opposite of the rationale behind #2340, which
proposes setting nLockTime at current-height + 1 to prevent
"fee-sniping" reorgs...
> 2. once users have had some time to upgrade to clients that set
> nLockTime, start discouraging transactions without nLockTime --
> possibly with a slightly higher fee required for relay
> 3. start rate-limiting relay of transactions without an nLockTime
> (maybe this alone could be used to achieve [2])
> 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)
>
One way to proceed is implement #3753 (mempool janitor) in such a way
that transactions with nLockTime are allowed to live a bit longer in the
mempool (say 500 blocks) than those without (72 hours). In other words,
as a first step, just actually start expiring things from the mempool in
bitcoin core, and leave any relay fee adjustments or rate limiting for
later. The isStandard change would be a good complement to #3753, to
avoid relaying a tx that will soon expire by the nLockTime rule anyway.
📝 Original message:On 7/31/2014 5:58 PM, Kaz Wesley wrote:
> 1. start setting nLockTime to the current height by default in newly
> created transactions (or slightly below the current height, for
> reorg-friendliness)
Reorg-frendliness is the opposite of the rationale behind #2340, which
proposes setting nLockTime at current-height + 1 to prevent
"fee-sniping" reorgs...
> 2. once users have had some time to upgrade to clients that set
> nLockTime, start discouraging transactions without nLockTime --
> possibly with a slightly higher fee required for relay
> 3. start rate-limiting relay of transactions without an nLockTime
> (maybe this alone could be used to achieve [2])
> 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)
>
One way to proceed is implement #3753 (mempool janitor) in such a way
that transactions with nLockTime are allowed to live a bit longer in the
mempool (say 500 blocks) than those without (72 hours). In other words,
as a first step, just actually start expiring things from the mempool in
bitcoin core, and leave any relay fee adjustments or rate limiting for
later. The isStandard change would be a good complement to #3753, to
avoid relaying a tx that will soon expire by the nLockTime rule anyway.