📅 Original date posted:2017-03-28
📝 Original message:On Tuesday, March 28, 2017 5:34:23 PM Johnson Lau via bitcoin-dev wrote:
> You are probably not the first one nor last one with such idea. Actually,
> Luke wrote up a BIP with similar idea in mind:
>
> https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki
> <https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki>;
>
> Instead of just lifting the block size limit, he also suggested to remove
> many other rules. I think he has given up this idea because it’s just too
> complicated.
> ...
> So if we really want to get prepared for a potential HF with unknown
> parameters, I’d suggest to set a time bomb in the client, which will stop
> processing of transactions with big warning in GUI. The user may still
> have an option to continue with old rules at their own risks.
Indeed, actually implementing hfprep proved to be overly complicated.
I like the idea of a time bomb that just shuts down the client after it
determine it's stale and refuses to start without an explicit override.
That should work no matter what the hardfork is, and gives us a good
expectation for hardfork timeframes.
> Or, instead of increasing the block size, we make a softfork to decrease
> the block size to 1kB and block reward to 0, activating far in the future.
> This is similar to the difficulty bomb in ETH, which will freeze the
> network.
I don't like this idea. It leaves the node open to attack from blocks actually
meeting the criteria. Maybe the absolute minimum as Jeremy suggested.
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 19:58:04
in reply to nevent1q…d39c
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 19:58:04Event JSON
{
"id": "62fbc5832ff3ac9fa1ea02a5b30acbb7545febea56b5969f1753a1245e31bd62",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160684,
"kind": 1,
"tags": [
[
"e",
"f66fb8ea0b053d3b896ce377aea38775ffc7975376c3ee96291861cf920b456b",
"",
"root"
],
[
"e",
"d762c3496980406bf20b2314dd578222e0fd5566d4d73bd5c4a6c126f340def5",
"",
"reply"
],
[
"p",
"492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7"
]
],
"content": "📅 Original date posted:2017-03-28\n📝 Original message:On Tuesday, March 28, 2017 5:34:23 PM Johnson Lau via bitcoin-dev wrote:\n\u003e You are probably not the first one nor last one with such idea. Actually,\n\u003e Luke wrote up a BIP with similar idea in mind:\n\u003e \n\u003e https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki\n\u003e \u003chttps://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki\u003e\n\u003e \n\u003e Instead of just lifting the block size limit, he also suggested to remove\n\u003e many other rules. I think he has given up this idea because it’s just too\n\u003e complicated.\n\u003e ...\n\u003e So if we really want to get prepared for a potential HF with unknown\n\u003e parameters, I’d suggest to set a time bomb in the client, which will stop\n\u003e processing of transactions with big warning in GUI. The user may still\n\u003e have an option to continue with old rules at their own risks.\n\nIndeed, actually implementing hfprep proved to be overly complicated.\n\nI like the idea of a time bomb that just shuts down the client after it \ndetermine it's stale and refuses to start without an explicit override.\nThat should work no matter what the hardfork is, and gives us a good \nexpectation for hardfork timeframes.\n\n\u003e Or, instead of increasing the block size, we make a softfork to decrease\n\u003e the block size to 1kB and block reward to 0, activating far in the future.\n\u003e This is similar to the difficulty bomb in ETH, which will freeze the\n\u003e network.\n\nI don't like this idea. It leaves the node open to attack from blocks actually \nmeeting the criteria. Maybe the absolute minimum as Jeremy suggested.\n\nLuke",
"sig": "7e41f4486fb272b12d1ebf22040b4fbbcc8a9782f34148a525b8274da8866ad791a85ac35385d90a2b55347a8ad5fbe515778341ae22d662c8eeafa0047e719c"
}