What is Nostr?
ZmnSCPxj [ARCHIVE] /
npub1g5z…ms3l
2023-06-07 18:07:06
in reply to nevent1q…8k7m

ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2017-10-12 📝 Original message:Good morning, >ZmnSCPxj ...

📅 Original date posted:2017-10-12
📝 Original message:Good morning,

>ZmnSCPxj wrote:
>> Hodlers have much greater power in hardfork situations than miners
>
>Not when hodlers are more evenly split between coins. Miners will prefer
>the coin with higher transaction fees which will erode hodler confidence
>via longer delays. This means transaction fees will evolve to the highest
>that common marketplace users can accepet (they are not intereseted in
>hodler security), not the lowest technologically feasible fee that provides
>the greatest security. Large blocks reduce network security while giving
>the higher total transaction fees to miners even as it can reduce fees per
>coin for users. The mining "lobby" will always describe this as "best for
>users". Non-hodling users and miners logically prefer SegWit2x.

Hodlers still have greater power than non-hodling users, whether miners or day-traders.

Hodlers holding millions in coin, total, can greatly drop price of any undesired hardfork.

Miners will prefer the coin with higher transaction fees as measured in real-world value. Thus even if the unwanted chain provides 2 tokens as fee per block, whereas the wanted chain provides 1 token as fee per block, if the unwanted chain tokens are valued at 1/4 the wanted chain tokens, miners will still prefer the wanted chain regardless. What the chains will compete in is the real-world value of the total mining reward.

Hodlers hodl all the cards here.

>ZmnSCPxj wrote:
>> BCH changed its difficulty algorithm, and it is often considered to be to
>its detriment due to sudden hashpower oscillations
>
>BCH has survived this long because they did NOT use the bitcoin difficulty
<snip>

All this speculation seems to suggest to me simply that a difficulty change leads to keeping a chain alive unnecessarily, when by rights, it should be dead and laid to rest.

If Bitcoin needs some sudden change in difficulty algorithm to survive, then it has failed. Feel free to do your own hardfork into yet another derivative altcoin.

>Bitcoin has developers!
>
>And those developers can publish a contingency plan!
>
>And that contingency plan can be an emergency hard fork to a different retarget algorithm.
>
>And that emergency hard fork can gain consensus if it is broadly preferred over the status quo.

Every hardfork is an invitation to shatter the community even further than it already is. There is no need for further shattering.

The idea that an emergency hardfork to a different difficulty algorithm is necessary arises from a lack of understanding of just how much power hodlers have over the destiny of a coin.

Every hodler who rejects a hardfork, will sell the hardfork coin, increasing its supply and reducing its price.

Every miner who mines a rejected hardfork, creates new tokens in the hardfork, increasing its supply and reducing its price.

Coins that are hedl will remain hedl, and are not part of the supply. Thus coins on the desired chain will remain high in price, regardless of available transaction rate. The lack of freshly-minted coins also contracts the supply.

In the end, this will result in the same behavior as in BCH, where hodlers sodl the unwanted hardfork as quickly as they could. Indeed, due exactly to miner support, 2X is much more likely to quickly drop in price than BCH did. I am sure you have seen the images pointing out how easy it was to determine when BCH blocks arrived: they arrived a little before each dip in BCH price. Fast 2X block rate will lead to faster 2X death, with its miners becoming bagholders.

As most Core developers hodl vast amounts, it is far more likely that any hardfork that goes against what Core wishes will collapse, simply by Core developers acting in their capacity as hodlers of Bitcoin, without needing to do any special action in their capacity as developers.

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171012/003fc7c4/attachment.html>;
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l