Topic: The consensus dead end. - page 5. (Read 1433 times)

I agree with you, don't get me wrong. I am very sure that it's nearly impossible to reverse a public key to private, I'm talking theoretically, what would happen in that case. It may be in 2040, or in 2140, but there will be sooner or later a year in which quantum computers or any other advanced technological creation constitutes a threat to the current hashing algorithms.

RIPEMD-160 is the one we should hope for. It's 2⁹⁶ times "weaker" than SHA-256.

True, it's ambiguous. But I don't blame that they'll change the "real bitcoin", neither that they'll increase the 21 million limit. I'm in favor of the bitcoin's principles, I'm just wondering how can they make such change. A bitcoin node should be running forever if possible. But any node that'd do that since 2009, would not follow the correct chain at the moment. The current chain would be considered invalid due to SegWit.

My conclusion is that the developers won't force you directly. But they will.

Possible doesn't mean it's probable.

1. Pollards kangoroo already exist, but it's not enough to brute-force private key generated with good RNG. You might able to solve private key which is part of puzzle or generated with weak RNG.
2. Quantum competing are decades away.


Let's hope SHA-256 is still strong enough in the next 20-30 years.


The term "real bitcoin" is ambiguous, what defines it? Some people might refer to Principles of Bitcoin, but few people going further such as for/against big block size limit and off-chain/side-chain network.

that's true but SegWit is still a lot of change in consensus rules not just simple expansions.

OP's concerns are mostly because he is comparing an upgrade like SegWit with a mandatory change that would for example remove RIPEMD160 from the protocol. if it is proven that RIPEMD is indeed weak then the change won't be as hard as any others before.

The sole fact of backward compatibility is enough to refute any claim about "consensus change". For the muliltisig opcode,  current Bitcoin supports old UTXOs with legacy format but doesn't allow new txns with such a format to be included in the blockchain anymore.

The point is what OP is worried about,  his assets being subject to uncertainty due to events like Segwit UASF, is absolutely void.

since SegWit did change some of the old consensus rules it is also a consensus change too. but since all the changes are backward compatible, that made the fork a soft fork.
one consensus rule that it changed for example was the dummy stack element for OP_CHECKMULTISIG that can no longer be anything except OP_0.

Satoshi chose 1MB as the block size limit (before there wasn't any limits) but look, it is obviously not feasible if we need to scale up. If you only consider the original consensus rules to be the only version of Bitcoin, then you would probably not be using the Bitcoin that you have today. Satoshi did lay the groundwork but it is obvious that not all of the choices that he made has actually made any sense at all.
Would it have made sense to be following the original Bitcoin with no block limits, an overflow bug, no segwit, no p2sh, etc? It was obvious that Satoshi didn't mean to leave Bitcoin as it is, there is a set of rules which probably won't garner any support or would redefine Bitcoin but it doesn't mean you can't improve Bitcoin.

---

I don't think this is really up for discussion, I don't think Bitcoin would've survived if it didn't evolve.

It seems that it's just my opinion, but I don't believe that users should have the freedom to choose what is defined as Bitcoin. They have the freedom to experiment with it, to use it, to create new things on top of it, but not to change it. Satoshi chose these consensus rules and every person who refuses to accept them is free to follow a different chain.

As for Satoshi:  It's not the fact that a "guy" decided what rules should be followed. That doesn't sound good. It's just the way the chain started. Every consensus change would be against the philosophy.

Percentage of blocks, Miners Activated Soft Fork.

I disagree. I think users should have the freedom to choose what is defined as Bitcoin. You don't use Bitcoin just because Satoshi said so; you use Bitcoin because you stand with the rules that governs it (21mil coins, non-reversibility, etc). Having a fork such as the one that you have described would definitely not be unpopular but people can just continue on the fork that doesn't implement the fix like how Bitcoin Cash is formed.

You don't have to. If you don't want to implement the fix or to not burn the old coins, then an altcoin would be forked from that, just like how ETH and ETC came about.

Threshold of what? Of nodes? How can you know the percent of nodes that agree with the new rule?

There are nodes. Bitcoin miners are bitcoin users. Every person that runs his own node, is a user. Indirectly, a person that runs an SPV node is also a user that trusts other nodes' information. The users are those who follow the consensus rules, the ones Satoshi had chosen. A change on a consensus rule confuses the people of what is the real bitcoin.

But this is not a majority decision. It's a consensus rule. Everyone is free to change any consensus rule they wish to, but they won't have Bitcoin. They'll have their own coin. If the majority wants 42 million coins, they're free to re-create bitcoin. They're free to leave it, but they can't announce it as the new "Bitcoin".

Actually ECDSA is indeed reversible. It's just currently infeasible. Hash functions such as "SHA-256" and "RIPEMD-160" are irreversible/one-way.

There will be ways to prevent attacks from quantum computers. The question is how they'll force every node to accept them.

FYI: Segwit was not a consensus change, rather it was a consensus expansion, legacy pre-Segwit full nodes could continue confirming and not forking off the legacy chain, nobody is able to touch one Satoshi of legacy wallets ever.

It was enforced by a User Activated Soft Fork, UASF i.e. forced by a majority of user wallets that adopted the soft fork, miners followed this majurity. It is called soft fork because its backward compatibility helped not to mandate a simultaneous global upgrade, letting nodes to adopt the feature whenever they wish to use it; it is user-activated because in the special circumstance that the upgrade was going to take place the community was undergoing a scaling debate which ended to bch hard fork and some mining pools were acting suspiciously.

I do agree that UASFs are not a perfect solution and shouldn't be weaponized by devs to do whatever they wish, but because of the centralized situation in the Bitcoin mining scene, we need such a measure to keep large pools inline.

Segwit makes use of weight to reduce transaction fee.

I do not know much about consensus, experienced members about it will answer that. But what I know is that segwit transaction begins with miners supporting it activation, while majority supported it and makes the activation successful.

Private key can not be reversed as it is a one way function. But you meant can it be brute forced through the use of quantum computing. According to what I learned, it is not early days quantum computers that can brute force the ECDSA, it will take time before this can happen, and before it will happen, there would have being layers of protection against quantum computing to brute-force bitcoin private key from public key.

Double hash/hash160 is used in a one-way-function to generate addresses from public key, it will be much harder for quantum computing to brute force private key from addresses. And know if this wants to become possible, before it becomes possible, there will be another layer added that will be impossible for quantum computing not to brute force the private key.

Segwit actually had a bunch of activation periods where miners are supposed to signal for the acceptance of Segwit and if the threshold of 95% is reached, then the rule would be activated 2 periods down. It was started after one of the difficulty periods and its support was implemented after 0.13.1.

See UASF (BIP148) and BIP91 with the reduced threshold. Bitcoin users are as important as miners; if you don't follow the users, then you're just mining on your own fork and the users are using another version which gives you zero economical benefits.
Segwit was a controversial change with differing opinions from different camps and that's why you have BCH. If it's something that puts the network (both users and miners alike) at risk, I can't see how they would oppose such a change.

Since 2009, some consensus rules have been added, for example SegWit. It surely does good, it's a solution for the block size limit, but I want to know how did that occur. In wikipedia it says that SegWit was activated on block 477120, but who begun that? Changes on consensus rules, as good as they are, are changes. If the majority of its users, change a consensus rule, they immediately stop being the majority. The follow their "Bitcoin".

The forum itself says on a quote that miners don't vote on changing consensus rules, only the order of the transactions. Seeing a change like that makes me wonder what else can the developers change. Should they have an impact on bitcoin? Whether if it's for good reason or not.

How did miners accept that change? They were not forced to update their bitcoin client.

-But why did you enter that title?
Well, I'm a little afraid of bitcoin's future and thus, my funds'. On the long term, one of these may occur:

• Public key to private key reversal. (I've heard that it may be possible to do that with quantum computing and pollards kangaroo method)
• Finding collisions for RIPEMD-160 hashes. Are we sure that 2¹⁶⁰ is strong enough? What if it becomes weak in the next 20-30 years?

Even if the first one can be faced pretty easily by simply creating outputs on addresses that have never spent, the second one requires consensus change. I don't know what they can change in that case, probably use of stronger cryptography, but they will have to change something! Otherwise, bitcoin will be useless. Changing a consensus rule, that important, would sour lots of people. And that's because that moment, the developers would have to "touch" people's money. It'd be a consensus dead end.