considering the obstacles it faces, I will not implement segwit support into initial iguana versions. If a bunch of users end up with unspendable funds, then I guess I will be forced to massively complicate the blockchain handling.
does anybody know the BIP that defines the new network message(s)? I assume each block would need a getsegwitdata equivalent so existing nodes just do the existing getdata and the segwit softforks (ha ha) do the additional call, process the new data format, update the internal dataset, validate the signatures and enable spending. Seems like a LOT of work to get a 60% increased capacity.
I would advise that you actually read all of the BIPs.
The one you are looking for is BIP 143:
https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki.
Since this is basically a hardfork (let us not kid ourselves that creating INCOMPATIBLE bitcoins is in any way backward compatible!!), and it requires the additional data, then just hardfork 2MB.
That would not require wtxid wasting precious space in the blockchain.
How does the wtxid waste space? The only place it ends up in the blockchain is in the coinbase transaction as the witness root hash where the wtxids are hashed together.
The logic used to justify wtxid permanently using up space that otherwise wouldnt be needed is that it allows a softfork. But this is a fake softfork, as existing nodes wont be able to validate or spend any segwit payments it gets. HOW ON EARTH IS THAT BACKWARD COMPATIBLE?? which is the industry's understanding of softfork behavior (I know technically that is not what softfork is, I speak of what users are thinking)
It is a soft fork because after the upgrade old nodes and wallets still function perfectly fine with the old system. They can still receive segwit transactions, they just can't spend from them. They can still receive and spend from traditional transactions which will still be valid under the new rules
So, if segwit gets 75%, then it forces all the nodes to update. How is that not a hardfork?
No. It simply means that the new rules can go into effect and are now considered valid. No one is being forced to upgrade and you can still function fine without upgrading for a while.
The logic is segwit allows 60% increase in capacity without a hardfork, but this premise is wrong. It is effectively a hardfork, actually I think it is worse. If it was a hardfork, then users who know about such things will understand that they have to update. Saying it is a softfork will make users think they dont have to upgrade. Then they find out that they cant spend the bitcoins they got. So we end up with two incompatible bitcoins. this is not a good plan at all
No. It will not fork the blockchain. All of the blocks produced after the fork are still valid under the old rules. This is part of what makes it a soft fork. It doesn't fork the blockchain like a hard fork does.
Let us call a hardfork a hardfork. segwit is a hardfork from the most important aspect that is it NOT BACKWARD COMPATIBLE with existing wallets and independent cores.
OK, so that then means that segwit is WASTING precious blockchain space and not avoid a hardfork. It makes no sense to me that a defacto hardfork that breaks ALL EXISTING wallets and also requires all independent cores to make significant changes, testing, field updates, customer support, and it is all to permanently waste space with the redundant wtxids that would not be needed if we just hardforked 2MB
Please tell me there is some sanity here. There is no logical justification for segwit and plenty of risk factors of creating the impression that bitcoin is broken, and if you dont consider the existing installed base not being able to validate or spend bitcoins as not broken, then something about how you evaluate brokenness is broken.
Segwit is needed for its solution to the transaction malleability problem. It makes transaction malleability impossible to occur now since the txids now contain only data that is already signed. If everyone were to upgrade to segwit, it would indeed be a very good thing for Bitcoin. It also solves the O(n^2) hashing problem.
Additionally, you can still use Bitcoin as it is now after the fork. A lot of people seem to forget that.
Lastly, I will say that marketing segwit as a scalability solution was probably a bad idea. Its original intent was to solve the transaction malleability problem and a side effect was that the block space was effectively doubled. People use the 60% - 80% figure because the assumption is that people won't upgrade to segwit and make use of its advantages. Otherwise it would be the same as a block size doubling.
Are you trying to claim that having the entire existing installed base not being able to validate the wtxids they get is acceptable? And that not being able to spend it, is acceptable? The customer support issues it is guaranteed to cost, is acceptable? That the lost reputation for backward compatibility and reliability, is acceptable?
fixing malleability, great!
But to be able to spend the wtxids dont you need to get the extra witness data? Is that data part of the segwit blockchain? If it is part of the segwit blockchain, isnt there the wtxid for each txid that wouldnt otherwise be needed?
What am I missing?
To spend any received wtxid, you need to update to segwit chain, which is increased in size and includes the wtxid's for EVERY segwit tx, not just the merkle root. And this wtxid wouldnt be needed if we just hardforked to 2MB. So segwit as a space saver, actually loses space. Segwit as a softfork might be technically true, but it forces everyone to update to a sole sourced wallet or not be able to spend the coins received. And when they update, the wtxids are sitting there in their blockchain that wouldnt have been needed otherwise.
So, for fixing malleability and other things, great. no problems with that. but to claim it is increasing tx capacity without a hardfork is disingenuous at best. Most people would like to be able to spend the bitcoins they get. If you can agree with that, then you must agree that they will need to load the segwit blockchain, which is bloated with wtxids that would not be needed in a simple 2MB hardfork
I know you must have some sort of marching orders to follow the party line, but please, let us not make silly claims like "wallets still function perfectly fine with the old system. They can still receive segwit transactions, they just can't spend from them" I dont want you to lose your credibility
James