📅 Original date posted:2016-03-02
📝 Original message:I think the biggest question here would be how would the difficulty retargeting be changed? Without seeing the algorithm proposal it's difficult to assess the impact that it would have, but my intuition is that this is likely to be problematic.
Probabilistically the network sees surprisingly frequent swings of +/-20% in terms of the block finding rate on any given day, while the statistical noise over a 2016 block period can be more than +/-5%. Any change would still have to require a fairly significant period of time before there would be a reasonable level of confidence that the hash rate really had fallen as opposed to just seeing statistical noise (http://hashingit.com/analysis/29-lies-damned-lies-and-bitcoin-difficulties and http://hashingit.com/analysis/28-reach-for-the-ear-defenders).
How long would be required to deem that the hash rate had dramatically fallen? Would such a change be a one-time event or would it be ever-present?
If we were to say that if the hash rate dropped 50% in one day (which could, of course be a 30% real drop and 20% variance) and the difficulty was retargeted to 50% lower then that would have to be matched with a similar rapid retarget if it were to increase by a similar amount. Failing to do this both ways this would introduce an economic incentive for large miners to suppress the difficulty and gain dramatically larger numbers of block rewards. The current fixed block count per difficulty change prevents this because the daily losses while suppressing hashing outweigh the potential gains when it's re-added.
Cheers,
Dave
> On 2 Mar 2016, at 14:56, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> We are coming up on the subsidy halving this July, and there have been some
> concerns raised that a non-trivial number of miners could potentially drop off
> the network. This would result in a significantly longer block interval, which
> also means a higher per-block transaction volume, which could cause the block
> size limit to legitimately be hit much sooner than expected. Furthermore, due
> to difficulty adjustment being measured exclusively in blocks, the time until
> it adjusts to compensate would be prolonged.
>
> For example, if 50% of miners dropped off the network, blocks would be every
> 20 minutes on average and contain double the transactions they presently do.
> Even double would be approximately 850-900k, which potentially bumps up
> against the hard limit when empty blocks are taken into consideration. This
> situation would continue for a full month if no changes are made. If more
> miners drop off the network, most of this becomes linearly worse, but due to
> hitting the block size limit, the backlog would grow indefinitely until the
> adjustment occurs.
>
> To alleviate this risk, it seems reasonable to propose a hardfork to the
> difficulty adjustment algorithm so it can adapt quicker to such a significant
> drop in mining rate. BtcDrak tells me he has well-tested code for this in his
> altcoin, which has seen some roller-coaster hashrates, so it may even be
> possible to have such a proposal ready in time to be deployed alongside SegWit
> to take effect in time for the upcoming subsidy halving. If this slips, I
> think it may be reasonable to push for at least code-readiness before July,
> and possibly roll it into any other hardfork proposed before or around that
> time.
>
> I am unaware of any reason this would be controversial, so if anyone has a
> problem with such a change, please speak up sooner rather than later. Other
> ideas or concerns are of course welcome as well.
>
> Thanks,
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Dave Hudson [ARCHIVE] /
npub1re…679nu
2023-06-07 17:49:32
in reply to nevent1q…7306
Author Public Key
npub1re22dhneg8azw7z3979njqn2sp4gxzp4703g62tsrvmsvnj76heqj679nuPublished at
2023-06-07 17:49:32Event JSON
{
"id": "fb5223be182d791921b1ebbb1cfcf8d897ff1c130e67c4beb389c9d14376469f",
"pubkey": "1e54a6de7941fa2778512f8b39026a806a830835f3e28d29701b37064e5ed5f2",
"created_at": 1686160172,
"kind": 1,
"tags": [
[
"e",
"c19c64d0621f34bc049688bdbd88cd48f1e91c193354087b0b32d42fce855169",
"",
"root"
],
[
"e",
"1b4dc6c2a059459a0ee52a178aeafbcb5eb5aa401a9ff108e884642f5de623b7",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 Original date posted:2016-03-02\n📝 Original message:I think the biggest question here would be how would the difficulty retargeting be changed? Without seeing the algorithm proposal it's difficult to assess the impact that it would have, but my intuition is that this is likely to be problematic.\n\nProbabilistically the network sees surprisingly frequent swings of +/-20% in terms of the block finding rate on any given day, while the statistical noise over a 2016 block period can be more than +/-5%. Any change would still have to require a fairly significant period of time before there would be a reasonable level of confidence that the hash rate really had fallen as opposed to just seeing statistical noise (http://hashingit.com/analysis/29-lies-damned-lies-and-bitcoin-difficulties and http://hashingit.com/analysis/28-reach-for-the-ear-defenders).\n\nHow long would be required to deem that the hash rate had dramatically fallen? Would such a change be a one-time event or would it be ever-present?\n\nIf we were to say that if the hash rate dropped 50% in one day (which could, of course be a 30% real drop and 20% variance) and the difficulty was retargeted to 50% lower then that would have to be matched with a similar rapid retarget if it were to increase by a similar amount. Failing to do this both ways this would introduce an economic incentive for large miners to suppress the difficulty and gain dramatically larger numbers of block rewards. The current fixed block count per difficulty change prevents this because the daily losses while suppressing hashing outweigh the potential gains when it's re-added.\n\n\nCheers,\nDave\n\n\n\u003e On 2 Mar 2016, at 14:56, Luke Dashjr via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e We are coming up on the subsidy halving this July, and there have been some \n\u003e concerns raised that a non-trivial number of miners could potentially drop off \n\u003e the network. This would result in a significantly longer block interval, which \n\u003e also means a higher per-block transaction volume, which could cause the block \n\u003e size limit to legitimately be hit much sooner than expected. Furthermore, due \n\u003e to difficulty adjustment being measured exclusively in blocks, the time until \n\u003e it adjusts to compensate would be prolonged.\n\u003e \n\u003e For example, if 50% of miners dropped off the network, blocks would be every \n\u003e 20 minutes on average and contain double the transactions they presently do. \n\u003e Even double would be approximately 850-900k, which potentially bumps up \n\u003e against the hard limit when empty blocks are taken into consideration. This \n\u003e situation would continue for a full month if no changes are made. If more \n\u003e miners drop off the network, most of this becomes linearly worse, but due to \n\u003e hitting the block size limit, the backlog would grow indefinitely until the \n\u003e adjustment occurs.\n\u003e \n\u003e To alleviate this risk, it seems reasonable to propose a hardfork to the \n\u003e difficulty adjustment algorithm so it can adapt quicker to such a significant \n\u003e drop in mining rate. BtcDrak tells me he has well-tested code for this in his \n\u003e altcoin, which has seen some roller-coaster hashrates, so it may even be \n\u003e possible to have such a proposal ready in time to be deployed alongside SegWit \n\u003e to take effect in time for the upcoming subsidy halving. If this slips, I \n\u003e think it may be reasonable to push for at least code-readiness before July, \n\u003e and possibly roll it into any other hardfork proposed before or around that \n\u003e time.\n\u003e \n\u003e I am unaware of any reason this would be controversial, so if anyone has a \n\u003e problem with such a change, please speak up sooner rather than later. Other \n\u003e ideas or concerns are of course welcome as well.\n\u003e \n\u003e Thanks,\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": "e1b9be7f0f790a35bfdaa51997bfb5b358824580d1d2b3b6cfe6075830b416b8ee4ee1bc15891404bbf79098be2b551b73ddbefb64cf1172d439162ac92cb1cf"
}