Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-07 📝 Original message:On Sun, Feb 07, 2016 at ...
📅 Original date posted:2016-02-07
📝 Original message:On Sun, Feb 07, 2016 at 10:06:06AM -0500, Alex Morcos via bitcoin-dev wrote:
> And the back and forth discussion over your BIP has been in large part a
> charade. People asking why you aren't picking 95% know very well why you
> aren't, but lets have an honest discussion of what the risks and in your
Eh, lets not put words into people's mouths. I personally don't
understand why Gavin is using 75% in the manner that he is, given there
are many better alternatives, even if you don't think you can get ~100%
hashing power support.
> mind potential benefits of 75% are. Important debate about parameters of
> your BIP get lost because we're sniping at each other about known
> disagreements. For instance, I strongly believe 28 days is far too short.
Note that the grace period adds a significant amount of complexity to
the implementation; a much simpler alternative is to just use a hashing
power activated change with a very high threshold - 99% or so - with a
minimum activation date some point reasonably far into the future.
Also the way the grace period is implemented means that if support
*drops* after 75% is reached, the hardfork still activates (I haven't
actually tested this, so I may be misunderstanding the code). Obviously,
this is a dangerous situation, and an easy way for miners to "poison the
well" and disruptively force the fork to be rescheduled without actually
attacking the coin (nothing wrong with changing your mind! and pool
distribution may change anyway).
Again, a simple high % miner consensus fork with a reasonable minimum
activation time avoids all these problems, with far less code
complexity.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
00000000000000000711a9829e87ba8ea548f1793950893043a5dc56893dc1dc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/2fbb3c34/attachment.sig>;
📝 Original message:On Sun, Feb 07, 2016 at 10:06:06AM -0500, Alex Morcos via bitcoin-dev wrote:
> And the back and forth discussion over your BIP has been in large part a
> charade. People asking why you aren't picking 95% know very well why you
> aren't, but lets have an honest discussion of what the risks and in your
Eh, lets not put words into people's mouths. I personally don't
understand why Gavin is using 75% in the manner that he is, given there
are many better alternatives, even if you don't think you can get ~100%
hashing power support.
> mind potential benefits of 75% are. Important debate about parameters of
> your BIP get lost because we're sniping at each other about known
> disagreements. For instance, I strongly believe 28 days is far too short.
Note that the grace period adds a significant amount of complexity to
the implementation; a much simpler alternative is to just use a hashing
power activated change with a very high threshold - 99% or so - with a
minimum activation date some point reasonably far into the future.
Also the way the grace period is implemented means that if support
*drops* after 75% is reached, the hardfork still activates (I haven't
actually tested this, so I may be misunderstanding the code). Obviously,
this is a dangerous situation, and an easy way for miners to "poison the
well" and disruptively force the fork to be rescheduled without actually
attacking the coin (nothing wrong with changing your mind! and pool
distribution may change anyway).
Again, a simple high % miner consensus fork with a reasonable minimum
activation time avoids all these problems, with far less code
complexity.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
00000000000000000711a9829e87ba8ea548f1793950893043a5dc56893dc1dc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/2fbb3c34/attachment.sig>;