Topic: Moving towards user activated soft fork activation - page 2. (Read 24442 times)

You're advancing a false dichotomy. There is at least a "third side", which says "do nothing". The third side has no nuclear button, but is the most likely to "win". Furthermore, there could very well be a sane fork of the current code that uses none of the BU changes and also no Segwit. In both of these cases, the Core dev team becomes irrelevant, unless they decide their egos can handle rolling back Segfault.

The UASF nuclear button is wired to a dead circuit - UASF is a complete non-starter, as many technical experts have stated in this thread. Changing the POW or hashing algo is even worse - an absolute insult to anyone who believes in the implementation of Satoshi's concept. The BU nuclear button seems to be somewhat dangerous, but I do not predict they will try to force the fork without sufficient support. If BU does have sufficient support, the chain will fork in their favor, and BU will become what we all call bitcoin.

I think what I bolded from your words, is what will occur now.

The only thing that gives me some comfort is that during the historical cold war,
it was a standoff between the communist and capitalist, and ultimately due to the
capitalistic system and all of its secondary effects on it's subsystems, the
communists were unable to compete both technologically and financially.

To determine who could win this "Bitcoin coldwar", it should follow somewhat
along those lines. In this case, the technological aspect would be developers and
the financial aspect would be the economic supporting structures like exchanges,
businesses, validators, and etc. If those parts are strong, you can outlast your
enemy over long time periods. Historically, the communist lost the coldwar
because their only assets were their large numbers of troops and massive
amounts of, yet cheaply made weaponry.

From a historical coldwar perspective, either side will not ever "blink first",
but one will eventually collapse and fall apart due to being unable to compete
against every other aspect of the enemy, and other aspects they lack. Sheer
force and numbers are worthless within a standoff.

So, I think there are some interesting real world parallels that could be used to
almost always determine the outcome in any "Bitcoin coldwar". According to our
current "coldwar status" and the "assets on both sides" it is not likely that BU would
be able to overtake Core in a safe and consensus compliant manner. So, the only
results will either be BU collapsing over time or BU causing an intentional
non-consensus hardfork (preemptive nuclear strike with hopes of non-retaliation).

So, we shouldn't fear a coldwar, since that is safely determined over time, but we
should fear whether BU is willing to nuke at low consensus levels. If they are not
afraid and think they can beat the radiation fallout and other devastation to the
ecosystem, we should make our positions plain and clear, we will be forced to enact
MAD like measures to preserve the balance and future liberty to any survivors.

So if both "sides" now have a nuclear button they can push, do we escalate from the proverbial civil war up to cold war status?  Clearly all attempts at diplomacy have failed, so it's pretty much a case of seeing who blinks first.  Or, more likely, no one actually does anything and we carry on in stagnant mediocrity while the service deteriorates and the war of words carries on.

There seems to be no better choice.

You start using exact same arguments as people that want HF and are willing to risk even more.

I wish you good luck but running into that big risk open eyed looks very desparate little boy.

No pain no gain.
It will increase.
If economic majority supports UASF, even first UASF blocks are reasonably safe. Non-UASF blocks aren't safe at all, even if mining majority doesn't support UASF in the beginning.

Sorry.

When I used to work the managers always hated me for killing their 'great' ideas. And they could also never realize that I was actually doing them a favor, trying to advance  the  project by the months they'd have lost.  

I also want to see UASF failing, but considering that no bitcoin celebrity is willing to put his reputation behind this idea, it has no chance to turn into any kind of exciting failure. So all we can do now is take a piss out of some kids.

Mehh, you again. Should not answer all stuff that clear.

I wanna see some UASF coins falling...

 

Well, maybe a better description would be as a hybrid soft & hard fork. Miners are essentially hardforked, and regular non-mining nodes are soft-forked.

I'm pretty sure shaolinfry added the legacy-block version orphaning since the initial draft, I read it carefully when I did.


If this got the users' support, then it's no less radical than my previous thoughts on getting Segwit activated by direct user action, I'm willing to promote the idea of orphaning blocks indicating BU strings (although that's perhaps becoming less necessary now that users have come out against it, I still consider it a risk that BU could hardfork as an attack without user support)

So maybe this is not so bad. With BU pools and miners falling, perhaps BIP148 could work to galvanise support for Segwit activation by the miners before users start using a BIP148 client to force the miners' hands. I'd probably use a BIP148 client if shaolinfry released it, but any released binary needs gitian signatures, and that involves such an endorsement from known developers. achow101 stated that Core devs are majority opposed to BIP148, and I guess I can see why in a way. We'll have to wait as everyone thinks it over some more, it would be constructive if actual comments from the devs were forthcoming on this (as it seems they are short on ideas as to what to do, other than "nothing")

No, we are not fine with these things.
We just try to not waste any more energy on repeating things that are obvious.

UASF is not going to work.
When the kids "activate" it by tweaking their nodes' software, the bitcoin network isn't even going to shrug on it - it's going to be that meaningless.

Is everybody fine here with the reduced hashpower == security?

If major miners dont follow this what happens to the block time at beginning?

How safe are the first blocks after the activation?

At first sight it seemed to me indistinguishable from a hardfork. But it isn't a hardfork. Unupgraded nodes remain compatible, they don't need to upgrade. As soon as economic majority forces miners to upgrade, unupgraded regular users have nothing to worry about.

Hmmmm, not what I thought it was (BIP148). If that's the case, it won't work as a soft-fork, it's a Segwit hard-fork, UAHF not UASF.

Did the specification not change recently? I got a different impression from the draft I read, if this is a new change. Simply allowing Segwit-ready miners to begin mining Segwit blocks is sufficient.

So, can someone finally confirm what's gonna happen when bip148 activates? Is blockchain fork possible or not?

Unless I completely misunderstand something, all upgraded nodes, including upgraded miners will be rejecting unupgraded blocks:

There is no blockchain fork possible, regardless of the majority hashpower or the order in which Segwit or legacy blocks are found. Either type of block is equally valid to either type of miner, it wouldn't be a soft-fork if that were the case.

I make this assumption only in the second scenario. In the first scenario this isn't the default unupgraded miner behaviour, but it can accidentally arise if unupgraded hashpower is more than 50%.

Let A be a valid segwit block accepted by both types of miners. On top of A two blocks (both of the same height) are mined: another segwit block B and a non-segwit block C. Now let's assume that half of total hashpower (including all segwit hashpower) mines on top B and another half mines on top of C, the latter group happens to be luckier and they mine another non-segwit block D. Now non-segwit fork is 1 block longer than the segwit fork and all unupgraded hashpower switches to the unupgraded fork. Upgraded hashpower however sees this fork as invalid and doesn't switch. Unless upgraded miners immediately experience an influx of luck, we have a permanent (at first sight) chain split.

@stdset

You're making and invalid assumption: that miners using non-Segwit clients will reject blocks with Segwit transactions. They won't, the Segwit soft-fork was desgined in a way to prevent that happening.

What would happen as a result of a large proportion of the hashrate mining old style blocks only? The more users that use Segwit addresses, the more old-blocks miners won't be able to pick up fees from confirming the Segwit user's transactions. Segwit miners will be more profitable, but fewer Segwit transactions would be possible. Segwit miners will have more than double the blocksize to fill, so it's not as serious as it sounds, but users will also have to compete more to get their P2PKH/P2SH coins into P2WPKH and P2WSH addresses, because of the reduced amount of Segwit blocks available.

I'm trying to understand how UASF is supposed to work. Let's consider 2 scenarios:

1) Unupgraded miners are disorganised. Each of them mines on it's own.
Upgraded nodes see unupgraded blocks as invalid, don't relay them, that creates friction in unupgaded blocks propagation. Upgraded miners see unupgraded blocks as invalid, don't mine on top of them. But unupgraded miners see upgraded blocks as valid, mine on top them.

Say we have only 10% of hashpower upgraded, 90% of total hashpower mines on top of unupgraded blocks and 100% of total hashpower mines on top of upgraded blocks. Doesn't matter how long unupgraded chain grows, upgraded nodes see it as invalid. But it does matter when upgraded chain becomes longer than unupgraded, the latter gets orphaned by all nodes, even those who mined it. Nonetheless, permanent (at first sight) divergence is likely to happen. Once unupgraded chain outruns the upgraded (because of variance), unupgraded miners will be locked on it, because it has more accumulated PoW. Situation starts to look like a hardfork.

The greater upgraded hashpower part, the less likely permanent divergence to happen, but still it can happen, unless upgraded hashpower is more than 50%.

2) Unupgraded miners are organised, they detect upgraded blocks, don't mine on top of them. For example, they can create an unupgraded block with a tx conflicting with new rules, and mine only the chain, which contains that block, effectively setting a checkpoint. Essentially it's a hardfork.

In both cases we will likely have a hardfork-like situation, unless more than half of total hashpower is upgraded and unupgraded miners don't decide to fork off. What raises a question: does UASF have any advantages over an explicit hardfork? Well, there are some. I suppose economic majority supports UASF. BTC from the unupgraded fork are of much less utility than from the upgraded. Unupgraded miners will experience difficulties spending their rewards, what will incentivize them to upgrade. Once enough miners upgrade, the unupgraded fork will be naturally orphaned, without involving a real hardfork. In the case unupgraded miners decide to hardfork off, the onus of the fork is on them.

Well, if a node is already synced, then I think there won't be problems to follow the newly created blocks. If you run out of space on your current disk then you just add a new one and continue. If you run out of computation power, then you change the specs and use your synced blockchain.

The main problem is to sync it from scratch and in few years, with bigger blocks (be it Segwit, EC or something else), it may be a problem for any home user.
Having it synced now and keeping updated may be a valuable asset :-)