š
Original date posted:2017-07-05
š Original message:Luke,
I previously explored an extra state to require signalling before activation in an earlier draft of BIP8, but the overall impression I got was that gratuitous orphaning was undesirable, so I dropped it. I understand the motivation behind it (to ensure miners are upgraded), but it's also rather pointless when miners can just fake signal. A properly constructed soft fork is generally such that miners have to deliberately do something invalid - they cannot be tricked into it... and miners can always chose to do something invalid anyway.
> -------- Original Message --------
> From: luke at dashjr.org
> To: bitcoin-dev at lists.linuxfoundation.org, shaolinfry <shaolinfry at protonmail.ch>
> I"ve already opened a PR almost 2 weeks ago to do this and fix the other
> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
> It just needs your ACK to merge.
> On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
>> Some people have criticized BIP9"s blocktime based thresholds arguing they
>> are confusing (the first retarget after threshold). It is also vulnerable
>> to miners fiddling with timestamps in a way that could prevent or delay
>> activation - for example by only advancing the block timestamp by 1 second
>> you would never meet the threshold (although this would come a the penalty
>> of hiking the difficulty dramatically). On the other hand, the exact date
>> of a height based thresholds is hard to predict a long time in advance due
>> to difficulty fluctuations. However, there is certainty at a given block
>> height and it"s easy to monitor. If there is sufficient interest, I would
>> be happy to amend BIP8 to be height based. I originally omitted height
>> based thresholds in the interests of simplicity of review - but now that
>> the proposal has been widely reviewed it would be a trivial amendment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170705/06457a6c/attachment-0001.html>;
shaolinfry [ARCHIVE] /
npub12yā¦vwd8g
2023-06-07 18:03:56
in reply to nevent1qā¦7063
Author Public Key
npub12ykxgdg6sh5ny0p54ufmfh70xgrptwktpyfj4ek6nnn8rdu59qjscvwd8gPublished at
2023-06-07 18:03:56Event JSON
{
"id": "ce34f94e77c9393e26d2c4831c7d1c2d86ef74a374c64e9a5ecd31a6a4bc4f21",
"pubkey": "512c64351a85e9323c34af13b4dfcf320615bacb09132ae6da9ce671b7942825",
"created_at": 1686161036,
"kind": 1,
"tags": [
[
"e",
"6dca4ce5a4efa74cb7ed37e5b09a18be6e9c403d445123c985869b2153e645a9",
"",
"root"
],
[
"e",
"abb5776acfa382ae132c96d7f8badfb5be8664044de139309da25a19ad818f31",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "š
Original date posted:2017-07-05\nš Original message:Luke,\nI previously explored an extra state to require signalling before activation in an earlier draft of BIP8, but the overall impression I got was that gratuitous orphaning was undesirable, so I dropped it. I understand the motivation behind it (to ensure miners are upgraded), but it's also rather pointless when miners can just fake signal. A properly constructed soft fork is generally such that miners have to deliberately do something invalid - they cannot be tricked into it... and miners can always chose to do something invalid anyway.\n\n\u003e -------- Original Message --------\n\u003e From: luke at dashjr.org\n\u003e To: bitcoin-dev at lists.linuxfoundation.org, shaolinfry \u003cshaolinfry at protonmail.ch\u003e\n\u003e I\"ve already opened a PR almost 2 weeks ago to do this and fix the other\n\u003e issues BIP 9 has. https://github.com/bitcoin/bips/pull/550\n\u003e It just needs your ACK to merge.\n\u003e On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:\n\u003e\u003e Some people have criticized BIP9\"s blocktime based thresholds arguing they\n\u003e\u003e are confusing (the first retarget after threshold). It is also vulnerable\n\u003e\u003e to miners fiddling with timestamps in a way that could prevent or delay\n\u003e\u003e activation - for example by only advancing the block timestamp by 1 second\n\u003e\u003e you would never meet the threshold (although this would come a the penalty\n\u003e\u003e of hiking the difficulty dramatically). On the other hand, the exact date\n\u003e\u003e of a height based thresholds is hard to predict a long time in advance due\n\u003e\u003e to difficulty fluctuations. However, there is certainty at a given block\n\u003e\u003e height and it\"s easy to monitor. If there is sufficient interest, I would\n\u003e\u003e be happy to amend BIP8 to be height based. I originally omitted height\n\u003e\u003e based thresholds in the interests of simplicity of review - but now that\n\u003e\u003e the proposal has been widely reviewed it would be a trivial amendment.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170705/06457a6c/attachment-0001.html\u003e",
"sig": "36f12bc018f47a996d9cc946a8ac9b73103cef59a9303302d9c7d9f32c55d37fe26df80604300c93b4e4b27f5a5555f2910d4e2503ef664c7433e03ddc813cb6"
}