Miner activated hard fork (MAHF)

[BlackHatCoiner]

Miners: "We have the most hasrate, join us or you will be transacting upon a less secure blockchain."

They have the most hashrate, but they better use it wisely to the chain with the most demand, otherwise they're going to mine useless coins.

The UASF was where every belief/assumptions in the politics and incentives in protocol changed. It was also "discovered" that it's the full nodes that create the demand for what the miners produce. Blocks.

The full nodes or the users? As said, anyone can spin up a thousand full nodes. I think what defines votes is purchasing power. If you own billions worth of bitcoin, you do have an opinion, because you can move a big part of the fork back to Bitcoin. (or oppositely, if you support the fork)

[pooya87]

if the favoured CEX nodes are going to reject blocks

In reality CEXes are never going to do something like that. It's pretty simple, a CEX only exists to make money and they make the most amount of money if they list more coins on their platform. In case of a split (where they have to reject certain blocks) they make the most amount of money if they accept both chains!

Look back to what many exchanges did back in 2017 by listing chains that never even existed like "bitcoin unlimited" and sold virtual coins at virtual prices to people, coins that never existed and were never supposed to even exist!

[Wind_FURY]

ۤThe UASF was where every belief/assumptions in the politics and incentives in protocol changed. It was also "discovered" that it's the full nodes that create the demand for what the miners produce. Blocks.

The problems start when you start separating different parts of Bitcoin network. You can't have miners without nodes and you can't have nodes without miners. If one group or a sub-group of a group starts forcing something on others, everything will start falling apart.

I believe it's part of the experiment, and I don't think everything will fall apart especially in this part of Bitcoin's evolution when the self-interest of each participant must find some balance with the interests of the group. Eventually, the participants will come into consensus to find the balance where everyone is incentivized to keep everything running, and to keep everyone participating.

The UASF was where every belief/assumptions in the politics and incentives in protocol changed. It was also "discovered" that it's the full nodes that create the demand for what the miners produce. Blocks.

The full nodes or the users? As said, anyone can spin up a thousand full nodes. I think what defines votes is purchasing power. If you own billions worth of bitcoin, you do have an opinion, because you can move a big part of the fork back to Bitcoin. (or oppositely, if you support the fork)

In the context of the scaling debate and the proposal of BIP-148 by Shaolinfry, full nodes = users.

Anyone can spin up a thousand nodes, BUT what matters is the economic majority which includes Bitcoin users, merchants, exchanges, services = REAL USERS that can influence Bitcoin. That's different from a mere troll who spun a thousand nodes and went to fork "his network" alone.

[BlackHatCoiner]

It's pretty simple, a CEX only exists to make money and they make the most amount of money if they list more coins on their platform.

Or if someone bribes them to deny one fork.

In the context of the scaling debate and the proposal of BIP-148 by Shaolinfry, full nodes = users.

BIP-148 isn't relevant with scaling, though. Did you mean another?

Anyone can spin up a thousand nodes, BUT what matters is the economic majority which includes Bitcoin users, merchants, exchanges, services = REAL USERS that can influence Bitcoin. That's different from a mere troll who spun a thousand nodes and went to fork "his network" alone.

And I insist: is there any rational developer who ever suggested that voting with full nodes is wise? UASF rather sounds like it's backed by marketing.

[Wind_FURY]

In the context of the scaling debate and the proposal of BIP-148 by Shaolinfry, full nodes = users.

BIP-148 isn't relevant with scaling, though. Did you mean another?

I don't know what you're trying to argue, but the scaling debate was between the Core Developers who were debating for Segwit/Soft Fork, and the Big Blockers who were debating for a block size increase/Hard Fork.

Anyone can spin up a thousand nodes, BUT what matters is the economic majority which includes Bitcoin users, merchants, exchanges, services = REAL USERS that can influence Bitcoin. That's different from a mere troll who spun a thousand nodes and went to fork "his network" alone.

And I insist: is there any rational developer who ever suggested that voting with full nodes is wise?

Core Developers Eric Lombrozo and Luke Dashjr supported the UASF, and thought it was a necessary move to pressure the miners to activate Segwit.

UASF rather sounds like it's backed by marketing.

If that's what you believe, OK. I personally believe that it was an educating, and eye-opening event in Bitcoin.

Shaolinfry's proposal for BIP-148/UASF, https://bitcointalk.org/index.php?topic=1805060.0

[pooya87]

I believe it's part of the experiment, and I don't think everything will fall apart especially in this part of Bitcoin's evolution when the self-interest of each participant must find some balance with the interests of the group. Eventually, the participants will come into consensus to find the balance where everyone is incentivized to keep everything running, and to keep everyone participating.

There are certain principles that Bitcoin was built upon like pillars. You can't say if these principles (consensus) are changed things won't fall apart because the result will no longer be Bitcoin as we know it.

and the Big Blockers who were debating for a block size increase/Hard Fork.

Lest we forget, The problem wasn't just that they were arguing for bigger block size, the problem was that they were arguing that block size increase should be the only solution to scaling bitcoin.
Their proposals were also crazy like saying block size should be "unlimited" (eg. 2 TB blocks which later on turned into shitcoins like BSV) or they argued that the miners should have full control over the future of block size and decide whether they want to increase it and how much.

This is why their proposals never got anywhere, otherwise I personally believe that the block size itself should be increased by a hard fork at some point in the future but the main scaling solution should still be a second layer not the block size.

[BlackHatCoiner]

I don't know what you're trying to argue, but the scaling debate was between the Core Developers who were debating for Segwit/Soft Fork, and the Big Blockers who were debating for a block size increase/Hard Fork.

Yeah, I just mean that the BIP 148 wasn't primarily for scaling purposes. The author proposed it mainly for the transaction malleability issue. The big blockers wanting block size increase was in spite of this problem.

Core Developers Eric Lombrozo and Luke Dashjr supported the UASF, and thought it was a necessary move to pressure the miners to activate Segwit.

They supported the soft fork, but I don't think they've ever stated that the soft fork is wise to be activated according to what most full nodes follow.

the problem was that they were arguing that block size increase should be the only solution to scaling bitcoin.

Which ironically isn't a scaling solution at all, let alone the only. Rising the limit doesn't scale. Scaling comes with compression, as it's happening with SegWit (slightly), Lightning, and now Taproot.

[Wind_FURY]

I don't know what you're trying to argue, but the scaling debate was between the Core Developers who were debating for Segwit/Soft Fork, and the Big Blockers who were debating for a block size increase/Hard Fork.

Yeah, I just mean that the BIP 148 wasn't primarily for scaling purposes. The author proposed it mainly for the transaction malleability issue. The big blockers wanting block size increase was in spite of this problem.

Part of the Core Developers' argument was that it was a compromise for the block size increase, because Segwit did increase the network's capacity a little.

Core Developers Eric Lombrozo and Luke Dashjr supported the UASF, and thought it was a necessary move to pressure the miners to activate Segwit.

They supported the soft fork, but I don't think they've ever stated that the soft fork is wise to be activated according to what most full nodes follow.

No, defintely Luke Dashjr was an ardent supporter of BIP-148/UASF, and Eric Lombrozo later showing support by wearing a UASF hat that was given by Francis Pouliot during a talk in a conference.

List of Core Developers and important people that supported Segwit and different activation methods, https://en.bitcoin.it/wiki/Segwit_support

[BlackHatCoiner]

Part of the Core Developers' argument was that it was a compromise for the block size increase, because Segwit did increase the network's capacity a little.

Sure, but the main argument for SegWit's support, was to fix the transaction malleability. This little increase in block size was rather an incident.

List of Core Developers and important people that supported Segwit and different activation methods, https://en.bitcoin.it/wiki/Segwit_support

I get it, almost all Core developers supported SegWit. What I'm saying is: I don't believe many of those consider voting with full nodes a wise option.

[Wind_FURY]

Part of the Core Developers' argument was that it was a compromise for the block size increase, because Segwit did increase the network's capacity a little.

Sure, but the main argument for SegWit's support, was to fix the transaction malleability. This little increase in block size was rather an incident.

I was merely giving you some context when you said that Segwit wasn't relevant in scaling, https://bitcointalk.org/index.php?topic=5433973.msg61614604#msg61614604

In fact, it was during the Scaling Debate. It was the compromise, the trade-off.

List of Core Developers and important people that supported Segwit and different activation methods, https://en.bitcoin.it/wiki/Segwit_support

I get it, almost all Core developers supported SegWit. What I'm saying is: I don't believe many of those consider voting with full nodes a wise option.

It could be debated that it wasn't wise option, but history showed the community that it was a necessary option. It was the "Ace in their sleeve", although risky.

Did you read the list? There are ten Core Developers who preferred BIP-148/UASF, found it acceptable, or wanting it.