đź“… Original date posted:2017-07-06
đź“ť Original message:I'm all for using height instead of time. That was my preference for
bip9 all along, but my arguments at the time apparently weren't
convincing.
Regarding luke's proposal, the only advantage I see is that it would
allow nodes that don't know a deployment that gets activated to issue
a warning, like bip9 always does when an unknown deployment is locked
in.
But there's a simpler way to do that which doesn't require to add
consensus rules as to what versionbits should be.
I'm honestly not worried about it being "coersive" and I don't think
it's inherently reckless (although used with short deployment times
like bip148 it can be IMO). But it adds more complexity to the
consensus rules, with something that could merely be "warning code".
You can just use a special bit in versionbits for nodes to get the warning.
My proposal doesn't guarantee that the warning will be signaled, for
example, if the miner that mines the block right after lock in doesn't
know about the deployment, he can't possibly know that he was supposed
to signal the warning bit, even if he has the best intentions. Miners
can also intentionally not signal it out of pure malice. But that's no
worse than the current form, when deployments activated by final date
instead of miner signaling never get a warning.
Shaolinfry had more concerns with my proposed modification, but I
think I answered all of them here:
https://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218
The implementation of the proposal is there too. I'm happy to reopen
and rebase to simplify (#10464 was merged and there's at least 1
commit to squash).
> It also enables deploying softforks as a MASF, and only upgrading them to UASF
on an as-needed basis.
You can also do
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight = 500000;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight = 510000;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout = false;
and "if needed", simply add the following at any time (before the new
nStartHeight, obviously):
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight = 510000;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight = 515000;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout = true;
On Wed, Jul 5, 2017 at 9:44 PM, Hampus Sjöberg via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> From the PR change:
>
>> Miners must continue setting the bit in LOCKED_IN phase so uptake is
>> visible and acknowledged. Blocks without the applicable bit set are invalid
>> during this period
>
> Luke, it seems like the amendments to BIP8 make it drastically different to
> how it first was designed to work.
> It now looks more akin to BIP148, which was AFAICT not how BIP8 was
> originally intended to work.
> Perhaps this should be made into its own BIP instead, or make it so it's
> possible to decide how the LOCKED_IN state should work when designing the
> softfork.
>
> Hampus
>
> 2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org>:
>>
>> It's not pointless: it's a wake-up call for miners asleep "at the wheel",
>> to
>> ensure they upgrade in time. Not having a mandatory signal turned out to
>> be a
>> serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a
>> problem
>> for BIP 149 as-is). Additionally, it makes the activation decisive and
>> unambiguous: once the lock-in period is complete, there remains no
>> question as
>> to what the correct protocol rules are.
>>
>> It also enables deploying softforks as a MASF, and only upgrading them to
>> UASF
>> on an as-needed basis.
>>
>> Luke
>>
>>
>> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:
>> > 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.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Jorge TimĂłn [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 18:03:58
in reply to nevent1q…cu4g
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 18:03:58Event JSON
{
"id": "a307ace86b6d2b666b9d92ca8fbe7f0305100912bdec8bcbf54f4dd8e74f3411",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686161038,
"kind": 1,
"tags": [
[
"e",
"6dca4ce5a4efa74cb7ed37e5b09a18be6e9c403d445123c985869b2153e645a9",
"",
"root"
],
[
"e",
"c924ca061ac0706852bfbfafba381e93fd5ed0d900980e98586d8b9fa12ada15",
"",
"reply"
],
[
"p",
"7f05c6d469aea3aebb69433a3de1336e36d9b0e34b54488cca80118b30a2e0ea"
]
],
"content": "📅 Original date posted:2017-07-06\n📝 Original message:I'm all for using height instead of time. That was my preference for\nbip9 all along, but my arguments at the time apparently weren't\nconvincing.\n\nRegarding luke's proposal, the only advantage I see is that it would\nallow nodes that don't know a deployment that gets activated to issue\na warning, like bip9 always does when an unknown deployment is locked\nin.\n\nBut there's a simpler way to do that which doesn't require to add\nconsensus rules as to what versionbits should be.\nI'm honestly not worried about it being \"coersive\" and I don't think\nit's inherently reckless (although used with short deployment times\nlike bip148 it can be IMO). But it adds more complexity to the\nconsensus rules, with something that could merely be \"warning code\".\n\nYou can just use a special bit in versionbits for nodes to get the warning.\nMy proposal doesn't guarantee that the warning will be signaled, for\nexample, if the miner that mines the block right after lock in doesn't\nknow about the deployment, he can't possibly know that he was supposed\nto signal the warning bit, even if he has the best intentions. Miners\ncan also intentionally not signal it out of pure malice. But that's no\nworse than the current form, when deployments activated by final date\ninstead of miner signaling never get a warning.\n\nShaolinfry had more concerns with my proposed modification, but I\nthink I answered all of them here:\n\nhttps://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218\n\nThe implementation of the proposal is there too. I'm happy to reopen\nand rebase to simplify (#10464 was merged and there's at least 1\ncommit to squash).\n\n\u003e It also enables deploying softforks as a MASF, and only upgrading them to UASF\non an as-needed basis.\n\nYou can also do\n\nconsensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit = 0;\nconsensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight = 500000;\nconsensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight = 510000;\nconsensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout = false;\n\nand \"if needed\", simply add the following at any time (before the new\nnStartHeight, obviously):\n\n\nconsensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit = 0;\nconsensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight = 510000;\nconsensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight = 515000;\nconsensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout = true;\n\n\nOn Wed, Jul 5, 2017 at 9:44 PM, Hampus Sjöberg via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e From the PR change:\n\u003e\n\u003e\u003e Miners must continue setting the bit in LOCKED_IN phase so uptake is\n\u003e\u003e visible and acknowledged. Blocks without the applicable bit set are invalid\n\u003e\u003e during this period\n\u003e\n\u003e Luke, it seems like the amendments to BIP8 make it drastically different to\n\u003e how it first was designed to work.\n\u003e It now looks more akin to BIP148, which was AFAICT not how BIP8 was\n\u003e originally intended to work.\n\u003e Perhaps this should be made into its own BIP instead, or make it so it's\n\u003e possible to decide how the LOCKED_IN state should work when designing the\n\u003e softfork.\n\u003e\n\u003e Hampus\n\u003e\n\u003e 2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e:\n\u003e\u003e\n\u003e\u003e It's not pointless: it's a wake-up call for miners asleep \"at the wheel\",\n\u003e\u003e to\n\u003e\u003e ensure they upgrade in time. Not having a mandatory signal turned out to\n\u003e\u003e be a\n\u003e\u003e serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a\n\u003e\u003e problem\n\u003e\u003e for BIP 149 as-is). Additionally, it makes the activation decisive and\n\u003e\u003e unambiguous: once the lock-in period is complete, there remains no\n\u003e\u003e question as\n\u003e\u003e to what the correct protocol rules are.\n\u003e\u003e\n\u003e\u003e It also enables deploying softforks as a MASF, and only upgrading them to\n\u003e\u003e UASF\n\u003e\u003e on an as-needed basis.\n\u003e\u003e\n\u003e\u003e Luke\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:\n\u003e\u003e \u003e Luke,\n\u003e\u003e \u003e I previously explored an extra state to require signalling before\n\u003e\u003e \u003e activation in an earlier draft of BIP8, but the overall impression I got\n\u003e\u003e \u003e was that gratuitous orphaning was undesirable, so I dropped it. I\n\u003e\u003e \u003e understand the motivation behind it (to ensure miners are upgraded), but\n\u003e\u003e \u003e it's also rather pointless when miners can just fake signal. A properly\n\u003e\u003e \u003e constructed soft fork is generally such that miners have to deliberately\n\u003e\u003e \u003e do something invalid - they cannot be tricked into it... and miners can\n\u003e\u003e \u003e always chose to do something invalid anyway.\n\u003e\u003e \u003e\n\u003e\u003e \u003e \u003e -------- Original Message --------\n\u003e\u003e \u003e \u003e From: luke at dashjr.org\n\u003e\u003e \u003e \u003e To: bitcoin-dev at lists.linuxfoundation.org, shaolinfry\n\u003e\u003e \u003e \u003e \u003cshaolinfry at protonmail.ch\u003e I\"ve already opened a PR almost 2 weeks ago\n\u003e\u003e \u003e \u003e to do this and fix the other issues BIP 9 has.\n\u003e\u003e \u003e \u003e https://github.com/bitcoin/bips/pull/550\n\u003e\u003e \u003e \u003e It just needs your ACK to merge.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:\n\u003e\u003e \u003e \u003e\u003e Some people have criticized BIP9\"s blocktime based thresholds arguing\n\u003e\u003e \u003e \u003e\u003e they are confusing (the first retarget after threshold). It is also\n\u003e\u003e \u003e \u003e\u003e vulnerable to miners fiddling with timestamps in a way that could\n\u003e\u003e \u003e \u003e\u003e prevent or delay activation - for example by only advancing the block\n\u003e\u003e \u003e \u003e\u003e timestamp by 1 second you would never meet the threshold (although\n\u003e\u003e \u003e \u003e\u003e this\n\u003e\u003e \u003e \u003e\u003e would come a the penalty of hiking the difficulty dramatically). On\n\u003e\u003e \u003e \u003e\u003e the\n\u003e\u003e \u003e \u003e\u003e other hand, the exact date of a height based thresholds is hard to\n\u003e\u003e \u003e \u003e\u003e predict a long time in advance due to difficulty fluctuations.\n\u003e\u003e \u003e \u003e\u003e However,\n\u003e\u003e \u003e \u003e\u003e there is certainty at a given block height and it\"s easy to monitor.\n\u003e\u003e \u003e \u003e\u003e If\n\u003e\u003e \u003e \u003e\u003e there is sufficient interest, I would be happy to amend BIP8 to be\n\u003e\u003e \u003e \u003e\u003e height based. I originally omitted height based thresholds in the\n\u003e\u003e \u003e \u003e\u003e interests of simplicity of review - but now that the proposal has\n\u003e\u003e \u003e \u003e\u003e been\n\u003e\u003e \u003e \u003e\u003e widely reviewed it would be a trivial amendment.\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e\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\n\u003e",
"sig": "2feec2f179de2b7254454c7626a470de40c4db29d8df77afc3547e1c626a046d7d65838b21316cad1a421d640dd17e68e8ffb1533e94f1832dc745d0f0ef86c3"
}