|
|
|
|
|
|
by makomk
3244 days ago
|
|
|
It's a quite a bit more complicated than just increasing the block size to 8mb, actually, and in reality Bitcoin Cash ended up using one of SegWit's key changes in modified form. The default Bitcoin signature algorithm has quadratic performance due to repeated hashing and if the block size is increased above 1MB an attacker can use this in a fairly nasty DoS attack that, worst case, might be able to fork the blockchain. The BTC/SegWit side fixes this by creating a new transaction type that moves the signatures outside the main block into a separate "witness" and uses more efficient signature hashing. The new transactions appear to older nodes as though they simply didn't require signatures, so existing software keeps working. This also fixes an annoying issue called "transaction malleability" which allows attackers to change the transaction IDs of other people's transactions; all of the data hashed to compute the transaction ID is now signed. It's apparently this malleability fix that makes off-chain payments easier. BCH essentially replaces the original signature hashing algorithm with the SegWit one but keeps the signatures in the block. Bitcoin also has a hard cap on the number of expensive CHECKSIG operations that can be carried out to prevent DoS attacks and both sides take different approaches to raising that, neither of which is straightforward. |
|
|
It also appears that there were some proposals related to SegWit that advocated putting the signatures in a separate block, but the actual implemented SegWit does not do this. Instead it simply moves the signature to the end of the transaction (which allows them to fix most of the malleability issues).
There are many proposals for scaling bitcoin. One of the proposals is to increase the size of the blocks. Segwit also does this by changing how much the signature "counts" as part of the block size. This will allow blocks to be roughly 2mb in size.
Most other scaling techniques can't currently be implemented because they rely on the transaction not being malleable. If SegWit is successful, then these other scaling techniques could be used (but they don't have to be).
It appears that one of the things some people don't like about SegWit is that it was introduced as a "soft fork". This means that it won't be activated in the client unless 95% of the clients support it. Some people feel that this will never happen because some miners are against SegWit. There are also other proposals for fixing the malleability issues and so there isn't a complete consensus about how it should be done (some people appear to complain that the implementation of SegWit is too complicated).
So instead on waiting for other scaling techniques, BCH has advocated a hard fork which increases the block size, but that does not address the transaction malleability problem. Some people have suggested that increasing the block size is the only thing necessary for scaling bitcoin and that other scaling techniques are unwanted.
My understanding is that SegWit will not, in itself, solve the scaling issue other than making a small increase in the block size (effectively doubling it), but that it paves the way for other techniques later (none of which have been decided on yet, but there are working implementations of several).
Is that accurate?