Moving towards user activated soft fork activation

[AgentofCoin]

...
This solution would be much more resistant to 51% attacks and the nodes would be needing far less resources    

+1 And so, the future of bitcoin was written.

 

Was that a proposed solution that relies upon a centralized system, controlled by a handful
of people, who are subject to laws and agencies of the countries in which they reside?
Sounds like we get rid of one attack vector to take on an easier one.

I'm I missing something here?

[1713971024]

1713971024

[1713971024]

1713971024

[1713971024]

1713971024

[coblee]

FYI, I'm fine with one blocksize increase up to a maximum of 8MB if segwit (or another linear transaction verification time method) is available and most of the community is supporting this change as well.

FYI, Bitcoin doesn't care about what most of the 'community' wants.
It's only what most of the miners want that matters.

That's wrong. It's what users want that matters. Miners may want to keep mining 12.5 BTC blocks during the next block having, but if users are not OK with that, miners will just fork themselves off the "Bitcoin" network.

The point of UASF is that users collectively have more control than miners. But because there's no easy way to gouge user desires, it's much harder to pull off a UASF. BIP9 miner softfork is used because mining solved the Byzantine General's problem and we can use it to measure exact support.

I think it's good that this UASF got people thinking about who is actually in control. But it's not for sure that UASF can be pulled off safely.

[piotr_n]

...
This solution would be much more resistant to 51% attacks and the nodes would be needing far less resources    

+1 And so, the future of bitcoin was written.

 

Was that a proposed solution that relies upon a centralized system, controlled by a handful
of people, who are subject to laws and agencies of the countries in which they reside?
Sounds like we get rid of one attack vector to take on an easier one.

I'm I missing something here?

Obviously you don't even get it that we are taking a piss out of your ideas to "fix bitcoin" by removing miners out of the system.

[AgentofCoin]

...
This solution would be much more resistant to 51% attacks and the nodes would be needing far less resources    

+1 And so, the future of bitcoin was written.

 

Was that a proposed solution that relies upon a centralized system, controlled by a handful
of people, who are subject to laws and agencies of the countries in which they reside?
Sounds like we get rid of one attack vector to take on an easier one.

I'm I missing something here?

Obviously you don't even get it that we are taking a piss out of your ideas to "fix bitcoin" by removing miners out of the system.

I guess not. I'm used to sarcasm being more obvious.
Your statement fell in line with some BU supporters ideas.
So I thought it was genuine.

If you read my post above, you'll see I don't support UASF.

[piotr_n]

I guess not.
I'm used to sarcasm being more obvious.
Your statement fell in line with some BU supporters ideas.

If you read my post above, you'll see I don't support UASF.

Nobody who understands what bitcoin is and how it really works supports it.
It won't work.

[classicsucks]

Nobody who understands what bitcoin is and how it really works supports it.
It won't work.

We can only hope that it won't work... This proposal is by far the WORST I've heard in recent history. Absolutely throwing gasoline on a fire to put it out. After all of Core's FUD and screeching about hard forks, this proposal makes a hard fork look like Sunday brunch in the Hamptons. There are so many different ways this UASF could fail catastrophically... Not to mention, excluding miners from consensus is revolting, and completely against the founding principles of bitcoin. As others have said, they're the ones with the most skin in the game.

If Core actually tries this, their reign as the custodians of the bitcoin code and the de facto creators of the bitcoin roadmap will end. At least we will get some lulz if Core writes another ten thousand lines of code that nobody ever uses...

[classicsucks]

the strange to me is why three days after this proposal not a single bitcoin developer except from Jameson Lopp bitgo eng has not tell us his opinion about this.
It seems that all of them keep mysterious silent...

Hmm, and the proposal is posted from a new forum account with no posting history... Seems Legit...

Perhaps they're floating the idea to see just how much rage they'll face.  Or possibly, they're trolling Ver. In this case, they want to appear adversial, but quietly they know full well that this proposal could never work.

EDIT: the troll theory makes sense given the double-whammy of Ver announcing 110% mining bounty for Unlimited clients and Antpool switching to BU.

Theymos has already weighed in.

inb4 GMaxwell urges caution and says Segwit is a "much better compromise".

[mezzomix]

There are so many different ways this UASF could fail catastrophically...

I'm waiting for the detailed analysis (minus the usual ad hominem) ...

[classicsucks]

There are so many different ways this UASF could fail catastrophically...

I'm waiting for the detailed analysis (minus the usual ad hominem) ...

I don't think a detailed analysis is worth my time (and may be beyond my expertise)... it's a stupid idea and it won't get off the ground.

Not an ad hom guy - you must be thinking of someone else.

[classicsucks]

There are so many different ways this UASF could fail catastrophically...

I'm waiting for the detailed analysis (minus the usual ad hominem) ...

You could've googled it yourself, but here you go:
https://www.cryptocoinsnews.com/antpool-now-mining-bitcoin-unlimited/

However, in a flag day soft-fork, the miner’s role becomes far more complicated. Assuming the entire network is mining with one client, non-upgraded miners are accepted by non-upgraded nodes, upgraded miners are accepted by upgraded nodes and non-upgraded nodes, upgraded nodes reject non-upgraded miners.

This is a mess in itself, but add other clients, such as Bitcoin Unlimited, and we have utter chaos. Alternatively, if non-upgraded miners are forced by easily sybilable upgraded nodes to upgrade, then we have a dangerous centralized point of failure as developers – who are just volunteers with no real stake – are given all the power.

[mezzomix]

There are so many different ways this UASF could fail catastrophically...

I'm waiting for the detailed analysis (minus the usual ad hominem) ...

I don't think a detailed analysis is worth my time (and may be beyond my expertise)... it's a stupid idea ...

I see, the "no one should ever have left the oceans" argument. q.e.d.

[Manfred Macx]

Here is a question. Suppose that something like BIP65 (CHECKLOCKTIMEVERIFY) never went through and that only 10 users wanted it an not the majority of the network. Could those 10 users still make the changes to their software necessary to get their clients to work with CLTV? The rest of the network would still verify those transactions since they redefine OP_NOP2 and find them valid (like old clients do for BIP65). Would this make any sense? Is it UASF?

[chek2fire]

Here is a question. Suppose that something like BIP65 (CHECKLOCKTIMEVERIFY) never went through and that only 10 users wanted it an not the majority of the network. Could those 10 users still make the changes to their software necessary to get their clients to work with CLTV? The rest of the network would still verify those transactions since they redefine OP_NOP2 and find them valid (like old clients do for BIP65). Would this make any sense? Is it UASF?

you need and a miner to support it so it can add your segwit transactions to blockchain. of course if this miners has very low hashrate you will need very long until your segwit transaction to add to blockchain until this miner find a block.

[mezzomix]

In this case the hash rate will adapt within a short amount of time to usual hash rate target.

[chek2fire]

In this case the hash rate will adapt within a short amount of time to usual hash rate target.

but we talk here for a soft fork and not a hard fork. nothing will happen. the not upgrade nodes or miners will still works as ti nothing happens to the network.

[mezzomix]

In this case the hash rate will adapt within a short amount of time to usual hash rate target.

but we talk here for a soft fork and not a hard fork. nothing will happen. the not upgrade nodes or miners will still works as ti nothing happens to the network.

When the non-mining nodes an some of the miner nodes accept a soft-fork block, the miner nodes blocking the change will stay in the current network and mine their own chain.

[classicsucks]

There are so many different ways this UASF could fail catastrophically...

I'm waiting for the detailed analysis (minus the usual ad hominem) ...

I don't think a detailed analysis is worth my time (and may be beyond my expertise)... it's a stupid idea ...

I see, the "no one should ever have left the oceans" argument. q.e.d.

Well, first off I did post a copy/paste of some obvious major issues that could arise.

Secondly, when you want to do something, the onus is on YOU to do a detailed analysis and determine that it would be safe. It's not like you do it unless someone raises an objection, that's madness!

[forzendiablo]

this idea is awesome. is OP one of LTC devs ?

[BTCLuke]

Alright, I've been giving this a ton of thought and and both for and against UASF.

No offense meant to the OP, but it absolutely is dogshit, conceptually. Devs on this thread could instantly see that. It took me -slightly- longer.

The worst part, I'm convinced, is what the BU community can do in response. Since UASF tells everyone to pick a side by X date or be left behind in a hostile manner, the BU team has NOTHING TO LOSE by Hard forking on that date. It would be extremely dumb of them not to.

So basically, UASF forces a hard fork, the most horrible outcome for bitcoin's price. Hopefully no one wants that here.

There is something to be gained by it's existence though.  Remember your Nuclear cold war tactics? Nuclear Proliferation and Mutually Assured Destruction? UASF can act as a threat to counter BU. I say it should be developed if for no other reason than if they're going to HF anyway, we can scare them back in line with UASF.


Like with the cold war, we really should be thinking about hiring a UN-certified Negotiator though. Is protecting $20 Billion not worth their price? 

[classicsucks]

Alright, I've been giving this a ton of thought and and both for and against UASF.

No offense meant to the OP, but it absolutely is dogshit, conceptually. Devs on this thread could instantly see that. It took me -slightly- longer.

The worst part, I'm convinced, is what the BU community can do in response. Since UASF tells everyone to pick a side by X date or be left behind in a hostile manner, the BU team has NOTHING TO LOSE by Hard forking on that date. It would be extremely dumb of them not to.

So basically, UASF forces a hard fork, the most horrible outcome for bitcoin's price. Hopefully no one wants that here.

There is something to be gained by it's existence though.  Remember your Nuclear cold war tactics? Nuclear Proliferation and Mutually Assured Destruction? UASF can act as a threat to counter BU. I say it should be developed if for no other reason than if they're going to HF anyway, we can scare them back in line with UASF.


Like with the cold war, we really should be thinking about hiring a UN-certified Negotiator though. Is protecting $20 Billion not worth their price?  

Thank you for that sanity check - I was beginning to think I was alone in my horror about UASF. Everything I've read indicates it would be a disaster technically, and it's also a violation of fundamental bitcoin concepts and consensus. So bad that it's literally an anonymous proposal.

Funny, I was just wading through a thread about John Nash - game theory etc. I almost came to the conclusion that bitcoin is in a Nash Equilibrium. This could mean that bitcoin development is DONE. 0.12 from now to eternity! I guess I could live with it...