BIP 113: Median time-past is a HARDfork, not a softfork!

BIP 113: Median time-past is a HARDfork, not a softfork!
2015-11-02  4:27 ` jl2012
  
From: Luke Dashjr @ 2015-11-01 19:06 UTC (permalink / raw)
  To: bitcoin-dev

BIP 113 makes things valid which currently are not (any transaction with a 
locktime between the median time past, and the block nTime). Therefore it is a 
hardfork. Yet the current BIP describes and deploys it as a softfork.

Furthermore, Bitcoin Core one week ago merged #6566 adding BIP 113 logic to 
the mempool and block creation. This will probably produce invalid blocks 
(which CNB's safety TestBlockValidity call should catch), and should be 
reverted until an appropriate solution is determined.

Rusty suggested something like adding N hours to the median time past for 
comparison, and to be a proper hardfork, this must be max()'d with the block 
nTime. On the other hand, if we will have a hardfork in the next year or so, 
it may be best to just hold off and deploy as part of that.

Further thoughts/input?

Luke


 permalink raw reply	[|nested]
2015-11-01 19:06 [bitcoin-dev] BIP 113: Median time-past is a HARDfork, not a softfork! Luke Dashjr

  2015-11-02  5:06   ` Luke Dashjr
  
From: jl2012 @ 2015-11-02  4:27 UTC (permalink / raw)
  To: Luke Dashjr;  bitcoin-dev

Currently, a tx maybe included in a block only if its locktime (x) is 
smaller than the timestamp of a block (y)

BIP113 says that a tx maybe included in a block only if x is smaller 
than the median-time-past (z)

It is already a consensus rule that y > z. Therefore, if x < z, x < y

The new rule is absolutely stricter than the old rule, so it is a 
softfork. Anything wrong with my interpretation?

Luke Dashjr via bitcoin-dev 於 2015-11-01 14:06 寫到:
> BIP 113 makes things valid which currently are not (any transaction 
> with a
> locktime between the median time past, and the block nTime). Therefore 
> it is a
> hardfork. Yet the current BIP describes and deploys it as a softfork.
> 
> Furthermore, Bitcoin Core one week ago merged #6566 adding BIP 113 
> logic to
> the mempool and block creation. This will probably produce invalid 
> blocks
> (which CNB's safety TestBlockValidity call should catch), and should be
> reverted until an appropriate solution is determined.
> 
> Rusty suggested something like adding N hours to the median time past 
> for
> comparison, and to be a proper hardfork, this must be max()'d with the 
> block
> nTime. On the other hand, if we will have a hardfork in the next year 
> or so,
> it may be best to just hold off and deploy as part of that.
> 
> Further thoughts/input?
> 
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



 permalink raw reply	[|nested]
2015-11-02  4:27 ` jl2012

  
From: Luke Dashjr @ 2015-11-02  5:06 UTC ( / )
  To: jl2012;  bitcoin-dev

On Monday, November 02, 2015 4:27:50 AM jl2012@xbt•hk wrote:
> Currently, a tx maybe included in a block only if its locktime (x) is
> smaller than the timestamp of a block (y)
> 
> BIP113 says that a tx maybe included in a block only if x is smaller
> than the median-time-past (z)
> 
> It is already a consensus rule that y > z. Therefore, if x < z, x < y
> 
> The new rule is absolutely stricter than the old rule, so it is a
> softfork. Anything wrong with my interpretation?

I agree, false alarm. Somehow I had confused the comparison of locktimes this 
morning. :(

Sorry about that,

Luke