Topic: Question about soft and hard fork (Read 1182 times)

Here are some of them.

@aantonop ‏
@WorldCryptoNet ‏
@jimmysong ‏
@ToneVays ‏
@theonevortex ‏
@WhalePanda ‏
@jfnewbery ‏
@brian_armstrong ‏
@eric_lombrozo ‏
@LukeDashjr ‏
@SatoshiLite ‏
@VitalikButerin ‏
@petertoddbtc ‏
@jgarzik ‏
@barrysilbert ‏
@gavinandresen ‏
@rogerkver ‏
@ErikVoorhees ‏
@coinbase ‏
@BitcoinMagazine ‏
@coindesk ‏

Awesome! Thanks, I have the book. And I will take your advice to follow some people as you advise (if you dont mind me asking, who do you follow?). Subscribing to the mail lists, and github - I'd really like that too. Thanks again for sharing generously!

There is a reason why pow and pos will run parallel on Ethereum blockchain. It is to minimal the risk for two fork happening on both chain as Pow mining rewards will decreases over time.

There's plenty of documentation on the internet about this. There's something you have to sit and slowly read for yourself you are never going to understand it with people from this for I'm trying to explain it to you. You have to sit and read it. You have to sit there and take as much time as it needs to get into your head. Also this forum contains lots of good information about this hard / soft fork.

Regarding the technical part of Bitcoin, I can recommend the book "Mastering Bitcoin" from Andreas Antonopoulos. It gives a great insight view of Bitcoin.

On social media I used to check the r/Bitcoin Reddit, but I think it does take too much time to filter good from bad topics.
In my opinion twitter is the better source to get news if you find some people to follow who have good knowledge in this space.
I'm also subscribed to the Bitcoin Dev Mailinglist and some Bitcoin github projects to learn about new stuff happening with Bitoin.

Thanks for answering! Learned a lot from you guys! Question: what is your favorite source of information/learning? I am keen to learn more, and gain some insights like you have.

Just want to add something I haven't thought before.

The nLocktime way does work, as long as you transfer your coins to one of your own addresses (what you actually do, when you want to split them).

So even if the nLocktime does not work correctly the first time, and the transaction got replayed, you can try again and again until it worked, just from the new address.
In this case you would not risk to lose your coins, but it might take long and could be expensive depending on how many transactions you need to finally split your coins on the networks.

But that's only needed in case of no replay protection. I still hope they work on something like this.
Some people claim, that the Segwit2X developers are working on the client - just not on github, but internally. Hopefully this is true and they also think about a replay protection.
Nevertheless, hiding what you are doing in an open source project is not something that generates trust...

It is not even about the stable hashrate. These rapid increases in the mempool come out of nowhere. If they all of a sudden come out on the logger chain, you are stuck and the other chain will catch up by the time your transaction is confirmed in the longer chain. So this problem isn't just going to go away in few weeks, it is there forever. These two chains can't safely coexist. Using one means that you completely ignore the other as it doesn't exist.

You are right. This is something what could be a real problem. If the same chain hopping happens like with Bitcoin Cash, you can run in exactly your described situation.
I guess the only secure way would be just to wait until both chains have a stable hash rate to minimize this risk.

Nevertheless I also would prefere that the Segwit2x devs implement a replay protection. Even if the timelock trick would work 100%, with the current clients it is too complicated to do for the average user.

Well, the article makes some assumptions, but ok. Either way it still rests on the race. There are quite real risks, you can't deny that.
Transactions get stuck really often, sometimes for days. You do this and the other chain could very well catch up at that point.
For example, even tho Bitcoin Cash had a smaller block height it also had emptier blocks (kinda goes together as a consequence of lower support, but doesn't have to be as in this one user and mining support could differ a lot more, also Bitcoin Cash had 8 times the capacity of Bitcoin and S2x will have only 2 times).
Either way, the transactions got accepted in Bitcoin Cash in the next block while Bitcoin had a huge problem with too many transactions of which some have to be stuck for days, just because there were to many of them for what Bitcoin could handle. So this article didn't talk about the average block times after the fork which will change rapidly and the transaction increase that might follow and clog the network. It is a lot more complicated that that.

The point is that if your transaction is stuck for long enough on the bigger chain, the shorter one will catch up. That is a risk. A quite real risk.
10 blocks given here as an example is nothing for the time your transactions can get stuck for more then you expected. No fee estimation will give you such a precise approximation due to transaction acceleration and the possible rapid increase in new transactions.
People had their transaction stuck for weeks during the last fork. Those are thousands of blocks, not 10. 10 blocks is like an hour and 40 minutes.
You need to be very precise in your estimation for this to work, which we saw is a very very difficult job, which is far from the "safe" option.

There is a safe way to prevent a replay attack with the nLocktime feature of bitcoin.

Checkout the link which explains how it works.
https://freedomnode.com/blog/79/how-to-prevent-replay-attack-by-splitting-coins-in-the-event-of-a-bitcoin-chain-split#h-locktime

What is the big difference in this hard fork from Bitcoin Cash is the amount of miner support. Currently around 90% of hashpower (few big mining pools) support it. But not many users or Core developers do. This makes the outcome a lot more uncertain then with Bitcoin Cash.
The lack of replay protection is a huge problem as well, I don't think there is a way to safely transact your coins only on one chain. It would be a race in the best case scenario and one chain will almost always win and put the coins in danger on the other chain.

The just means that the it is unlikely that these chains will coexist. As they won't be able to safely so a compromise might be necessary.
This puts everything on bigger stakes as well. I think this could be a very big deal. It is basically miners vs developers. And users might be on the Core side, but no one can be sure. So anything ca happen.

Very insightful reply.
I myself have been thinking about moving my BTC funds to other cryptocurrency such as Bitcoin Cash or Ethereum. Most people say BTC price will drop before Segwit2x activation and I tend to agree with that, as people will be fearful about this event. So, I think we can expect price rise after Segwit2x is done.

Good question. From the sources I receive my information from I get the feeling, that the majority of interested bitcoin users (people who follow bitcoin news, are somehow active on twitter/reddit or here in this forum) have closed the case Bitcoin Cash. This topic is not that hot anymore as both sides have their preferred solution now and are more or less happy with it.

The segwit2x topic is much more a topic at the moment as it will produce another hardfork in November. None of the sides really want to split Bitcoin again, but the positions on both sides are cemented. No one want to move towards the other side. So I think a split will definitely happen. The big fight until this split will be, who can convince the majority of miners, nodes, users, eco system etc. for their side.

The segwit2x fork will definitely create more chaos as the 2x supporter don't plan to implement a replay protection. Experienced Bitcoin users might not have a problem with it, because there are ways to safely split their coins in case of the fork, but the average user might not have the knowledge to do it. And people who never heard before about that fork may lose some money because of missing replay protection. Also people who don't control their own private keys, might not get access to their new "free" coins.

So, my biggest concern is the missing replay protection. The real support for one of the two sides we will only see after the fork happened. Hard to predict the future.
Also I'm concerned that in future this kind of forks could become common practice. I think this could weaken the Bitcoin brand in the worst case.

In terms of Bitcoin, I think the Bitcoin Core developers and their supporters have done more "proof of work" for their side, than the segwit2x developers/community.

Interesting! In your opinion, how has the btc fork affected the bitcoin community so far? any concerns in the future? Thanks in advance for your opinion

If the Ethereum developers don't reach the majority of people when they plan to do a hardfork, there is a big chance, that the network will fork.

But even if the chain forks, this does not mean, that the old chain can survive.
If you don't have a developer team which continues to work on the old version or people who are willing to keep the old chain alive, this old chain will become obsolete after some time.

The biggest problem with a fork is, if you have 2 or more parties who disagree with the changes. Even when everyone is OK with the new version, you might get a fork because some people are not aware of the new version. But after some time they will identify them self on a more or less dead chain and will switch.

I think a real fork, where both sides survive is more a political problem than a technical one. Bitcoin is the best example for this.

I will use the recent ethereum metropolis hard fork as an example.

Because of some radical changes to the protocol a hard fork was introduced resulting in 2 different blockchains.

My question is if in the future Ethereum developers need to have radical changes to the protocol again will there be another hard fork and resulting in 4 different parallel blockchains?