📅 Original date posted:2015-11-02
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 17:44:04
in reply to nevent1q…5844
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 17:44:04Event JSON
{
"id": "bb6f4a6060b31b2edc9660e2aa02252b5d42f604eb98c2f89cc8a7774cf7d84a",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686159844,
"kind": 1,
"tags": [
[
"e",
"8839c6c6b25b23f9436dca7926877e284222492f235e591c4a49ee8874ee9a52",
"",
"root"
],
[
"e",
"04fdfe1aada936c4fc74391ddd0b4eec9087132cf4413c623a3f83783f369381",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2015-11-02\n📝 Original message:Currently, a tx maybe included in a block only if its locktime (x) is \nsmaller than the timestamp of a block (y)\n\nBIP113 says that a tx maybe included in a block only if x is smaller \nthan the median-time-past (z)\n\nIt is already a consensus rule that y \u003e z. Therefore, if x \u003c z, x \u003c y\n\nThe new rule is absolutely stricter than the old rule, so it is a \nsoftfork. Anything wrong with my interpretation?\n\nLuke Dashjr via bitcoin-dev 於 2015-11-01 14:06 寫到:\n\u003e BIP 113 makes things valid which currently are not (any transaction \n\u003e with a\n\u003e locktime between the median time past, and the block nTime). Therefore \n\u003e it is a\n\u003e hardfork. Yet the current BIP describes and deploys it as a softfork.\n\u003e \n\u003e Furthermore, Bitcoin Core one week ago merged #6566 adding BIP 113 \n\u003e logic to\n\u003e the mempool and block creation. This will probably produce invalid \n\u003e blocks\n\u003e (which CNB's safety TestBlockValidity call should catch), and should be\n\u003e reverted until an appropriate solution is determined.\n\u003e \n\u003e Rusty suggested something like adding N hours to the median time past \n\u003e for\n\u003e comparison, and to be a proper hardfork, this must be max()'d with the \n\u003e block\n\u003e nTime. On the other hand, if we will have a hardfork in the next year \n\u003e or so,\n\u003e it may be best to just hold off and deploy as part of that.\n\u003e \n\u003e Further thoughts/input?\n\u003e \n\u003e Luke\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "e52590397f9e9f024a5be53b4bfa0418bbf624046bd6a5eb5fe05205fb6ae99348c58aa377fbd2ff80a727cbd30de8013da49c59bbd0ec1184e77ea74f5f23a5"
}