Topic: Why soft fork is a very bad idea and should be avoided at all costs - page 2. (Read 6768 times)

Not how it works.  You cannot create an altcoin based on bitcoin, and convince everyone to switch to the altcoin by telling them they are stupid.  Especially when the altcoin is a retardation compared to the real coin, and has alsmost no developers behind it.  I don't think the users will care much about what the majority of the miners are doing at that point.  They will just keep using their superior coin.

Obviously..  For a given hashrate, the chance of finding a new block, and therefore the reward, will be the exactly same in both forks.  After difficulty readjustment the success rate will increase.  So miners don't have any economic reasons to switch.

Any hard fork would be disastrous, yes, if it has followers.  Fortunately none of the suggested hard forks have gained a significant number of followers so far.

I think you may base this assumption on your flawed theory about profitability above.  As long as most merchants still use the real bitcoin, and indeed almost 90% of all nodes run real Bitcoin now, Bitcoin is the safest choice.  The success of a hard fork, and therefore the value of it's coins, does not depend on the miners.  It depends on the users.

This will work for one block maximum.  The first sport of a fork is doubling your coins by getting one transaction confirmed in one chain, and a different version in the other chain.  Coins spent as normal bitcoins won't exist in the "classic" chain and vice versa.  People will split their coins to make sure they can spend every coin they have in both chains separately, with no risk of getting the transaction confirmed in the other chain.  Eventually this will happen by itself when coins are mixed by coinbase coins which doesn't exist in the other chain.

Again, this is based on your mining profit fallacy above.  The profit in terms of coins per day for a given hashrate, will be exactly the same after a fork as before, until a difficulty adjustment.  After the adjustment the chain with the lowest hashrate will pay the most.

You mean by running Bitcoin Core and pretend to be "Classic" or vice versa?  Sure, but why would anyone do that?  It has so far only been done for mining.  Some blocks are mined as "BitcoinXT" blocks, but those have been shown to be created with Bitcoin Core with a small change to the coinbase transaction.  Since "Classic" has based their fork on an old version of Bitcoin Core, without many of the improvements for block generation, I think miners will do the same in the future as well, unless "Classic" get developers who are capable of rebasing their patches against 0.12.

I don't see any majority for raising the blocksize via a hard fork.  Quite the opposite.  It seems the majority is very clear on maintaining backwards compability, and increase the capacity by moving the signatures outside the 1 MB blocks.  Especially among the developers of Bitcoin and various bitcoin wallets.  Most of them have implemented segregated witness already.  It is very simple, and will be faster to deploy.

Not a chance any serious exchange would close. On the contrary, it could be like an early xmass gift for them as they could support both forks after the split, just name them ie 'BTC A' and 'BTC B' and let users engage in buying/selling war. Likely the exchanges themselves could sell their minority fork holdings. Obviously they would announce in advance that they intend to migrate to majority fork.

I think too that it's risky. And it should be avoided. Unfortunately it seems the network has not included real decision making besides forks. And i think it's relatively sure that, when one client starts at 0% of the network and reaches 75% that this client has an advantage that is recognized. It would be unlikely that those supporting it would suddenly turn back supporting the other chain then. At least not as long as serious problems show up with the fork once activated.

It looks to me like everyone staying in the old chain would simply be stupid, regardless of which fork it is. The chance to lose everything mined after that is very high. Or does he might be able to create a valueable altcoin out of the losing chain then?

Anyway, mining in the losing fork means blocks being found every 25 minutes?, which lowers potential reward even more. And this mining can take weeks. Deadly for a mining business. On the winning chain instead the blocks will be found every 13 minutes or so. (Obviously i'm no mathematician. )

It would be economical disastrous i think.

But i don't know a way to handle things differently. Especially when in such situation. Regardless which thing someone prefers now, the situation is so that some developers control the setup of the client. If someone disagrees and there are a big support like 50% of users and miners then there is simply no other way determined to handle things. Ok, the threshold for switching could be set higher, like 95%. This would do less harm of course. But in a situation where the community is divided that hard it's practically ensured that such a threshold can't be reached.

It's really a mess in my eyes. And i think a real crisis to bitcoin. Nothing like that happened before i think.


This is a possibility, especially with the collection of hashpower in single identities hands. Though it would be a pretty sneaky behaviour since those mining at those pools probably would support their attempt to mine on the fork too. They would be gone for good and mine in the new forks pools. Which would hurt the other pool alot.

Might be that miners can do it that own the miners. Ok, i don't know if there are such miners that would have a huge impact at all or only 10% or so.

It would stilly be risky. The most safe outcome for miners would be to trust that the other miners don't lie and follow them. The masse will win the game.


Man, i really hope nothing like that would happen. It would be like a war in the community and it would bring a deep deep canyon between user groups.

But i think exchanges have ways to protect themselves. They don't have to set on one chain alone. I mean they can own the same bitcoin addresses on both chains. They can run both chains. The only risk they would have would be to chose one chain only, then receive bitcoins that were not sent to them on the other chain. When the chain that they chose is dying then they are screwed and left with no bitcoins. But this risk can be completely eliminated by only accepting bitcoin deposits whose coins show up on the same deposit address on BOTH chains. Then they are completely safe. They would not even have to care which chain wins. They would always hold the right bitcoins.

Right?


Though that would be correct for the standard bitcoin chain too. If a fork reaches 75% and miners would still mine on the standard chain and the fork becomes the new real bitcoin then all mining on the standard chain after the fork will be gone to waste since the standard bitcoin chain blocks found after the fork happened would be invalidated. Additionally blocks would be found way way less often. Mining there would be economical suicide because the difficulty only would change each 2 weeks.


I think the Number of nodes can be completely forgotten. It can be faked easily and it most probably is faked since there are obviously fanatics who would do such things. There are not only cool headed discutants on each side.

Anyway, what matters is how the hashpower decides. And it really would be interesting to see what happens. In my opinion there is a majority for segway and for a raise of blocksize for 2mb at least for now. Stopping the delays in peak transaction amount times. I think the lightning network is not really loved by most. I mean it is a different system to use again. And all systems beside bitcoin had a lot of trouble finding it's acceptance.

Well thinking about that is obviously purely speculative.

But what i think is that exchanges would not have to fear any danger. I had to think about what i can do to protect me as an escrow too. And that was the solution i see for me. Only accepting coins that came in on both chains. When i receive coins only visible on the bitcoin address on one chain then i won't accept them. Too risky.

A long fork is extremely risky business.  During the next few weeks, the standard Bitcoin side of the fork can easily overtake the other side again.  Actually the most profitable strategy in this game to a miner would be to announce the intent of switching, then not do it when the switch is supposed to happen.  Many other miners will then waste their resources on the wrong side of a fork, while you keep mining on the side you know will win.  One or two large miners or pools who do this will be enough to tip the scale.  Since other miners will watch each other closely just after the fork is supposed to happen, you can mine a few fork blocks before switching back again, covertly mining standard Bitcoin blocks.  If one or two miners switch side after mining on the fork for a few hours to days, and then silently switch to standard Bitcoin again, the standard Bitcoin blockchain will overtake the fork.  So a closure of exchanges is pretty much 100% certain, at least if the fork has support from anything less than 90% of the mining power.  The weakness of the forks is the fact that if the standard bitcoin chain overtake the fork, all mining effort and transactions on the fork will be wasted and lost forever.  The standard Bitcoin chain can not be overtaken by a fork however, since the blocks from the forks will be invalid.

Anyhow, I don't believe there will be a hard fork.  Now "Classic" have released binaries, which has lead to a sharp increase in "Classic" nodes.  At the same time the number of "BitcoinXT" nodes is falling as if it went over a cliff.  Bitcoin Core has the same share of nodes on the network as it had before "Classic" binaries were released.  About 88%.  The last 12% are divided between "XT", "Classic" and "Unlimited".

Thanks sturle... so far segwit sounds pretty positive to me now if watched at isolated. It has to show that it reaches the effects claimed first, i think. There are very different estimates as to how far segwit will be able to stop a blocksize limit increase from happening. I hope an increase will be done anyway when problems arise and that bitcoin does not lose one of its rare advantages, the cheap transaction. The visions some people have are, thought to an end, frightening. I really don't want to see a bitcoin whose fees are so high that practically only companies and "BANKS" will be able to pay it by merging many transactions into one bitcoin transaction. It would mean the opposite of what satoshi wanted i think.

I only hope it does not come to this point. Anyway, segwit alone seems to a nice project and i don't see real reasons to not implement it.

---

SPV Mining led to the losses because the did not verify the block at all, i believe. Now they changed their ways and they verify, but they already start mining on that block. The verification should not take ages so it will be seen fast that the block is valid or not. But they safe the first time where it is unknown so that in case they find a legit block they can propagate it without losing the profit. It seems mostly this behaviour worked even with unproven blocks so it will be a good decision business wise.

Of course the network can block this simply, which is a legit way in my eyes.

---

So is the solution for this 10 minute quadratic solving time only a hardlimit for the transaction size? I have read somewhere that it was a proper solution BIP something or so. Though it might have been such a hack only.

I wonder if core really would not need it. There are calculations showing that worldwide adoption will make it inevitable to raise blocksize limit anyway. I wonder how far segwit can go there. I mean how many times more transactions can be handled when all safe optimizations are used.

I hope segwit does not implement new attack vectors no one thought about yet. At the end segwit works on basic principles that were not hackable. And practically every new hack goes ways nobody thought about before. Not that i think that bitcoin will be hackable, but maybe harm can be done.

When speaking about forks, CIYAM claimed that exchanges would need to close down when a fork happens that divides the network. Since exchanges can't risk to lose the value when the coins in their wallet are coins from the losing chain.

But i think that exchanges can still run normally, the only thing they would need to do is holding the wallet they chose to use AND holding a wallet that runs on the other chain. Then they import the privkeys of the first wallet into the second wallet and when someone deposits then they only will accept the withdraw when the coins show up in the bitcoin address on BOTH chains. Then they can be sure to not lose anything. If it does not show up then they reverse the transaction on the one chain that worked.

Am i right with thinking so?

For segwit alone, yes.  Of course segwit makes other optimizations very easy.  You can pass long chains to to the blockchain, A to B to C to ... to Z, where a node can validate and commit A to Z in one operation, leaving all the intermediates out of the blockchain.  And the best of all is the fact that all transactions in between, e.g. Q to R, can have the same instant security as the number of confirmations of A.  I am sure this will be the preferred way to transfer bitcoins in the future, due to the instant secure transfers and better privacy.

This has lead to chain forks and large losses for miners.  But the real danger is for SPV clients.  An SPV client will not be able to validate the chain at all.  If a chain is built on an invalid block, SPV clients will see false confirmations.  One proposal in segwit can eliminate this to a varying degree.  Eiher in a mild form, by including a proof of knowledge of the contents of the previous block, a stronger form that you must have validated the previuos block, and an even stronger form where you have to include transactions in the block you mine for it to be valid.  All this is possible, and of course the strongest forms are controversial.

Core doesn't need it.  Worst case for core is about 25 seconds, and this risk is eliminated when segwit has been deployed.  XT had a bad hack where they introduced a hard limit on 100 kB for transactions.  It would take a new hard fork to raise this limit.  I have no idea what the so-called "Classic" implemented, but last time I checked thje suggestion for doing the same in "Classic" had very few followers.  "Classic" is supposed to be a hard fork to increase the blocksize to 2 MB, and nothing more.  Then again, I think "Classic" mostly ignore this consisder.it thing, and just do what they want.

Correct.

All nodes will do that now, in fact.  Your node will accept transactions out of order, i.e. a transaction spending from a transaction you haven't seen yet.  Your node will not know if the transaction is valid until it has seen the parent.  It won't be confirmed until the parent is, of course.

Thank you guys for your answers.

So regarding cpu usage segwit has some advantage when transactions included are big. Discspace won't be affect since the data needed for segwit is probably a little bit more than it would have been for the same amount of bitcoins in old blocks. The same should be true for the bandwith usage.

Might be that segwit miners have an advantage in mining too since they can confirm a block faster. Though i think the best way to mine would be to start mining as if the block was real then start to verify the previous block and start to include transactions into the new block, changing part of the seeds. That would probably be the fastest way to mine since miners cold mine instantly on the probable newest block.

By the way, i have read that there is already a fix against this 10 minute validation of a transaction. It only is not implemented in core yet. Might be that it is, or get, included in classic. Surely should to not give open space for attack.

Sturle, when segwit eliminates one hash operation then this has no effect at all on the safety on bitcoin, right?

I think it sounds pretty scary that old nodes will accept transactions they can't verify. Luckily only coming when segwit practically won. Otherwise this could have become a mess.

CPU usage will be lower.  Large transactions with many signature validations may take very long without segwit.  A few months ago there was a 1 MB transaction, taking an entire block, which took 25 seconds to validate on a modern CPU.  It is possible to create a 2 MB transaction which take 10 minutes to validate, because signature checking is O(n²).  Segwit eliminates one hash operation, making this scale linearly.  A 2 MB transaction with a segregated witness will take less than a second to validate.

I'm not quite sure what you are asking, but I will try to answer what I think you are asking.

Old nodes/miners would still see segwit transactions and accept them as valid. However, if someone wanted to spend from a SegWit transaction, they could try and old nodes would accept any spend from a segwit transaction even if the spending transaction wasn't signed with the proper private key since old nodes would treat segwit transactions as anyonecanspend transactions. However the inclusion of any such transaction in a block would result in that block being orphaned as well as that transaction being rejected by many nodes. However, that does appear to be an attack vector and I don't know why 75% was chosen. I'll look around and ask it on the mailing list as well if I don't find an answer.

Thanks for explaining.

I find it a bit strange then why so many say that we should not raise the blocksize limit because segwit can do the same. Though it has only the advantage that it protects against an attack vector. Though good to know.

So at 75% a kind of fork starts? Old nodes would not create invalid blocks when trying to send bitcoins from addresses that were already cleard though a segwit transaciton because old nodes would still see these transactions right? So no big problem for the old nodes at this point?

With the capacity, it has the same effect as increasing to 2 Mb. However, another benefit (the original purpose actually) is that it makes transaction malleability entirely impossible. SegWit would still have been created and used because it fixes transaction malleability. It just became something for capacity which is just a side effect of moving the witness data out of the block.

Pretty much.

SegWit blocks will be produced when at least 750 out of the last 1000 blocks indicate SegWit support by having a version number of 5. Due to the backwards compatible nature of segwit blocks, this is fine and non segwit blocks can actually be built on top of SegWit blocks. However, after 950 of the last 1000 blocks, all blocks less than version 5 are considered invalid and that is actually when the forking happens.

Thank you for the explainations. I'm not so much into the details of the tech so i appreciate to learn how it works.

So when the witness is segregated into a parallel block then the amount of data to be transferred and to stored would not be less than if you would put the same amount of data into a normal traditional block? I thought this was one of the main reasons that were brought up against raising the blocksize limit. And the segwit nodes would have to verify the transactions, which then would mean the CPU would still have to work on, let's say, 2MB worth of transactions.

So the internet use, harddisc space and CPU-Usage would not be lower for the same amount of transactions than with traditional blocks?

sturle, you say that it is very unlikely for an old node to create an invalid block. Though segwit surely won't start with the majority of miners. So when segwit hashpower is at 10% of the net then no segwit blocks will be created, segwit blocks start at 95% of hashpower only. So 5% of the blocks would have potentially a chance of being invalid blocks because the old nodes can't see that some addresses already have their bitcoins taken away and they might try to spend them again. Though it doesn't sound like a big problem since when segwit reached that threshold then it is sure that it won't lose that power anymore. It would be safe to switch.

But it is not sure that segwit will reach that, right? Though it would be the same like with the old nodes. It would be safe to assume that segwit wins and that this transaction will never get invalidated.

So it is sure that segwit blocks only start to be created once segwit nodes hashpower reach 95%? I have read it differently, like it would be done from the start to enforce the adoption. So implemented in a different way than previous soft forks. So it is definitely the case that the old threshold is used?

To be honest... at the moment i don't even see anymore why segwit is an advantage when the arguments against 2mb blocks, internet, cpu and harddiscspace usage, are not changed. So it is only easier to raise?

I guess i misinterpreted since that sounds strange.

The merkle root is part of the block header and the block header is what determines the block hash.

Always, even after segwit has been deployed.  Only the witness is segregated, as the name implies. 

The only thing an old node cannot do after activation, is verify if a transaction to a segwit address is valid or not, as it will always seem valid to an old node.  Fortunately this is of no consequence, since old nodes will never generate that kind of addresses or receive segwit transactions, and the risk of an old node generating a block with an invalid transaction is very small since more than 95% of the hashrate follow the new rules.  A longer chainfork is very unlikely, but as with all soft forks merchants should of course upgrade.  Old nodes can send to segwit addresses, but not spend coins sent to segwit addresses.  Read the BIP.

Why do you think segwit has less datausage?  It doesn't.  When it has been deployed, segwit transactions (i.e. only transactions to the new address types associated with segwit) will have their witnesses recorded in a parallel block of witness data.  The total capacity of the two blocks is 4 MB.  This can be extended by various mechanisms in a later soft fork, or more likely by using sidechains and payment channels.  The latter mechanisms are IMHO better, since they scale better and don't increase the cost of running a full node.

Do you speak about the time that will be used by segwit to reach 95%?


Then were comes the less datausage from? The signatures are not needed to verify the tx?
[/quote]

There have been many soft forks so far, and it is nothing to be afraid of.  There was an issue with one of them due to a malicious miner who ended up loosing 175 BTC.  A merchant running an ancient version of bitcoin accepted the bad chain and lost on a double spend, but that's the only issue I can remember. 

Hard forks is a completely different matter.  Hard forks don't resolve themselves until 100% of all nodes have upgraded.  Until then Bitcoin will be unsafe to use, and people will lose money.  Even worse is the forking planned by some by releasing various altcoins and try to overtake a majority of the bitcoin hashpower.  In that case even upgrading to the latest version won't resolve the problems.

Wrong.  All transactions are recorded in the block.  Only the signatures are moved.

Wrong.  An old and a new node will have the coins at exactly the same places.  The UTXO set will be identitcal.

Segwit will not be activated until 95% of all hashpower support it, like with all soft forks.

Please educate yourself about segwit and bitcoin in general.  Have you been on Reddit or something?

Then the transactions get only checked against the merkle tree, which can contain all segwit transactions too, as long as the basetransaction is in there too.

But the transactions or the merkle tree plays no role in the calculation of the block hash?


Ok, the OP sounded differently and i'm no expert.


Good to hear that. If segwith really reaches that leven then it is pretty sure that it will stay since it won't lose support then anymore.

Soft forks are backwards compatible meaning that people running old nodes do not need to upgrade. Hard forks are not so everyone will need to upgrade their software in order to remain compatible.

People are not afraid of soft forks, they are actually the preferred method of the devs to deploy new features. It is just that people don't like SegWit which will be deployed as a soft fork.

Can anyone explain the major difference between a soft fork and a hard fork? And why is everyone afraid of soft fork?