Dave Scotese [ARCHIVE] on Nostr: ๐ Original date posted:2020-03-22 ๐ Original message:The software currently ...
๐
Original date posted:2020-03-22
๐ Original message:The software currently allows up to a two hour difference between the
system clock and the time implied by a fresh block's timestamp (if I
remember correctly). This reliance on realtime system clocks can be used
in a much weaker form to justify a plan for a difficulty adjustment to be
built into the software for when the expected block production rate is far
enough behind its expected value.
We would have to agree on how far behind mining should be to justify
expediting the adjustment. The sooner we decide on and implement this
second difficulty adjustment trigger, the better. It cuts off a nightmare
scenario made possible by collusion between states through regulation and
fiat, as well as any other external factors. I propose that miners
detecting that the expected 2016 blocks have not been mined after twice the
expected wait time (4032 * 10 minutes = 28 days) ought to signal their
recognition in any block they produce, to be rejected by any miner whose
clock disagrees (after taking into account the 2-hour leeway), and that any
block produced on top of one with such a signal should reflect an expedited
difficulty adjustment (and also include the signal), which is then in
effect for the rest of the 2016 blocks and the entire following difficulty
period. Every block from there until the modulo 2016 block should have the
same signal, which not only indicates that a difficulty adjustment was
expedited, but also that the next modulo 2016 block should not make one,
but rather turn off the signal.
If anyone thinks it's a good enough idea for a BIP, I will consider writing
one unless someone else wants to.
Dave.
On Sun, Mar 22, 2020 at 9:54 AM Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Mining is a lottery.
>
> e
>
> On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> ๏ปฟ
> There seems to be the real possibility that miners are simply trying to
> optimise mining profit by limiting the average hash rate during the
> retargeting, saving some electricity but poorly considering the overall
> situation where they give opportunity to other miners probably raising the
> hashrate for the next period. It is far more profitable for the ecosystem
> considering the whole to hold a lottery for minig as has been discussed
> elsewhere some time ago.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> ------------------------------
> *From:* bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on
> behalf of David A. Harding via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Sunday, 22 March 2020 6:54 PM
> *To:* Dave Scotese <dscotese at litmocracy.com>; Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Block solving slowdown question/poll
>
> On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev
> wrote:
> > [Imagine] we also see mining power dropping off at a rate that
> > suggests the few days [until retarget] might become a few weeks, and
> > then, possibly, a few months or even the unthinkable, a few eons. I'm
> > curious to know if anyone has ideas on how this might be handled
>
> There are only two practical solutions I'm aware of:
>
> 1. Do nothing
> 2. Hard fork a difficulty reduction
>
> If bitcoins retain even a small fraction of their value compared to the
> previous retarget period and if most mining equipment is still available
> for operation, then doing nothing is probably the best choice---as block
> space becomes scarcer, transaction feerates will increase and miners
> will be incentivized to increase their block production rate.
>
> If the bitcoin price has plummeted more than, say, 99% in two weeks
> with no hope of short-term recovery or if a large fraction of mining
> equipment has become unusable (again, say, 99% in two weeks with no
> hope of short-term recovery), then it's probably worth Bitcoin users
> discussing a hard fork to reduce difficulty to a currently sustainable
> level.
>
> -Dave
> _______________________________________________
> 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
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com>; and Meme Racing
<http://www.memeracing.net>; (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>; which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>;.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200322/dde91e34/attachment-0001.html>;
๐ Original message:The software currently allows up to a two hour difference between the
system clock and the time implied by a fresh block's timestamp (if I
remember correctly). This reliance on realtime system clocks can be used
in a much weaker form to justify a plan for a difficulty adjustment to be
built into the software for when the expected block production rate is far
enough behind its expected value.
We would have to agree on how far behind mining should be to justify
expediting the adjustment. The sooner we decide on and implement this
second difficulty adjustment trigger, the better. It cuts off a nightmare
scenario made possible by collusion between states through regulation and
fiat, as well as any other external factors. I propose that miners
detecting that the expected 2016 blocks have not been mined after twice the
expected wait time (4032 * 10 minutes = 28 days) ought to signal their
recognition in any block they produce, to be rejected by any miner whose
clock disagrees (after taking into account the 2-hour leeway), and that any
block produced on top of one with such a signal should reflect an expedited
difficulty adjustment (and also include the signal), which is then in
effect for the rest of the 2016 blocks and the entire following difficulty
period. Every block from there until the modulo 2016 block should have the
same signal, which not only indicates that a difficulty adjustment was
expedited, but also that the next modulo 2016 block should not make one,
but rather turn off the signal.
If anyone thinks it's a good enough idea for a BIP, I will consider writing
one unless someone else wants to.
Dave.
On Sun, Mar 22, 2020 at 9:54 AM Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Mining is a lottery.
>
> e
>
> On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> ๏ปฟ
> There seems to be the real possibility that miners are simply trying to
> optimise mining profit by limiting the average hash rate during the
> retargeting, saving some electricity but poorly considering the overall
> situation where they give opportunity to other miners probably raising the
> hashrate for the next period. It is far more profitable for the ecosystem
> considering the whole to hold a lottery for minig as has been discussed
> elsewhere some time ago.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> ------------------------------
> *From:* bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on
> behalf of David A. Harding via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Sunday, 22 March 2020 6:54 PM
> *To:* Dave Scotese <dscotese at litmocracy.com>; Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Block solving slowdown question/poll
>
> On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev
> wrote:
> > [Imagine] we also see mining power dropping off at a rate that
> > suggests the few days [until retarget] might become a few weeks, and
> > then, possibly, a few months or even the unthinkable, a few eons. I'm
> > curious to know if anyone has ideas on how this might be handled
>
> There are only two practical solutions I'm aware of:
>
> 1. Do nothing
> 2. Hard fork a difficulty reduction
>
> If bitcoins retain even a small fraction of their value compared to the
> previous retarget period and if most mining equipment is still available
> for operation, then doing nothing is probably the best choice---as block
> space becomes scarcer, transaction feerates will increase and miners
> will be incentivized to increase their block production rate.
>
> If the bitcoin price has plummeted more than, say, 99% in two weeks
> with no hope of short-term recovery or if a large fraction of mining
> equipment has become unusable (again, say, 99% in two weeks with no
> hope of short-term recovery), then it's probably worth Bitcoin users
> discussing a hard fork to reduce difficulty to a currently sustainable
> level.
>
> -Dave
> _______________________________________________
> 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
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com>; and Meme Racing
<http://www.memeracing.net>; (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>; which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>;.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200322/dde91e34/attachment-0001.html>;