joe2015 at openmailbox.org [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-21 📝 Original message:On 2015-12-21 11:39, Jeff ...
📅 Original date posted:2015-12-21
📝 Original message:On 2015-12-21 11:39, Jeff Garzik wrote:
> On Sun, Dec 20, 2015 at 12:21 PM, joe2015--- via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Current hard fork implementations include / will include miner
> lock-in, just like any soft fork. They will not activate if global
> consensus is not reached.
That's not true at all. They activate with a miner majority (e.g. 75%,
95%, etc.), not global consensus. Here global really means global, i.e.
miner, economic, all clients, etc. In the case of a hardfork there is
nothing stopping the miner minority from continuing the old chain. With
a softfork the miner minority is forced to upgrade otherwise their
blocks will be eventually orphaned.
My proposal achieves a hardfork-like blocksize limit increase but, like
a softfork, also forces the miner minority to upgrade.
--joe.
📝 Original message:On 2015-12-21 11:39, Jeff Garzik wrote:
> On Sun, Dec 20, 2015 at 12:21 PM, joe2015--- via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Current hard fork implementations include / will include miner
> lock-in, just like any soft fork. They will not activate if global
> consensus is not reached.
That's not true at all. They activate with a miner majority (e.g. 75%,
95%, etc.), not global consensus. Here global really means global, i.e.
miner, economic, all clients, etc. In the case of a hardfork there is
nothing stopping the miner minority from continuing the old chain. With
a softfork the miner minority is forced to upgrade otherwise their
blocks will be eventually orphaned.
My proposal achieves a hardfork-like blocksize limit increase but, like
a softfork, also forces the miner minority to upgrade.
--joe.