📅 Original date posted:2015-12-26
📝 Original message:I should have stated that we're assuming the actual total hashrate remains constant. Obviously this is not what would actually happen - the rest of the post discusses ways to counter the economic forces at play pushing total hashrate down using only soft forks. The increased variance is still unaccounted for (pool operators would have to deal with this somehow)...and we still have larger block intervals even with compensation. And the practicality of deployment and usability are clearly problematic, to understate things.
It's merely an exercise seeking the theoretical limit of what's actually possible to do with a soft fork.
On December 26, 2015 8:09:18 AM PST, Tier Nolan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev <
>bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Unfortunately, this also means longer confirmation times, lower
>> throughput, and lower miner revenue. Note, however, that
>confirmations
>> would (on average) represent more PoW, so fewer confirmations would
>be
>> required to achieve the same level of security.
>>
>
>
>No, the re-target compensates so that the number of blocks in the last
>two
>weeks is 2016. If a soft fork forces miners to throw away 25% of their
>blocks, then the difficulty will drop by 75% to keep things balanced.
>Throwing away 75% of blocks has the same effect on difficulty as
>destroying
>75% of mining hardware.
>
>The block interval will only increase until the next re-target.
>
>Slowly increasing the fraction of blocks which are thrown away gives
>the
>re-target algorithm time to adjust, so it is another advantage.
>
>If the rule was instantly changed so that 95% of blocks were thrown
>away,
>then there could be up to 40 weeks until the next retarget and that
>would
>give 200 minute block times until the adjustment.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/c7075802/attachment.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:47:09
in reply to nevent1q…uvrk
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:47:09Event JSON
{
"id": "2883fc41e26be6bf9135cb3fdac2c3429a0c3e6b40388b162af32139ee5bf5ee",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686160029,
"kind": 1,
"tags": [
[
"e",
"29b7621364af8f1f611558ed33ab90fd2b7daff5f620fc02b9ca3019fe1123e5",
"",
"root"
],
[
"e",
"357cc706988a0b9aae4d936dfbbbeab160ce979e2fc264c184b4680bf624f71a",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 Original date posted:2015-12-26\n📝 Original message:I should have stated that we're assuming the actual total hashrate remains constant. Obviously this is not what would actually happen - the rest of the post discusses ways to counter the economic forces at play pushing total hashrate down using only soft forks. The increased variance is still unaccounted for (pool operators would have to deal with this somehow)...and we still have larger block intervals even with compensation. And the practicality of deployment and usability are clearly problematic, to understate things.\n\nIt's merely an exercise seeking the theoretical limit of what's actually possible to do with a soft fork.\n\nOn December 26, 2015 8:09:18 AM PST, Tier Nolan via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eOn Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev \u003c\n\u003ebitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Unfortunately, this also means longer confirmation times, lower\n\u003e\u003e throughput, and lower miner revenue. Note, however, that\n\u003econfirmations\n\u003e\u003e would (on average) represent more PoW, so fewer confirmations would\n\u003ebe\n\u003e\u003e required to achieve the same level of security.\n\u003e\u003e\n\u003e\n\u003e\n\u003eNo, the re-target compensates so that the number of blocks in the last\n\u003etwo\n\u003eweeks is 2016. If a soft fork forces miners to throw away 25% of their\n\u003eblocks, then the difficulty will drop by 75% to keep things balanced.\n\u003eThrowing away 75% of blocks has the same effect on difficulty as\n\u003edestroying\n\u003e75% of mining hardware.\n\u003e\n\u003eThe block interval will only increase until the next re-target.\n\u003e\n\u003eSlowly increasing the fraction of blocks which are thrown away gives\n\u003ethe\n\u003ere-target algorithm time to adjust, so it is another advantage.\n\u003e\n\u003eIf the rule was instantly changed so that 95% of blocks were thrown\n\u003eaway,\n\u003ethen there could be up to 40 weeks until the next retarget and that\n\u003ewould\n\u003egive 200 minute block times until the adjustment.\n\u003e\n\u003e\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/c7075802/attachment.html\u003e",
"sig": "1037b7288921669c33f5c485c3089e2b99de752e40677a90b71cdb684633238bdb6b26c770965833892f6596c5e84fe4cc36557eaaabc445d3419ed50534ca40"
}