|
|
|
|
|
|
by codingmyway
3408 days ago
|
|
|
I didn't write the and test code myself so you can label that as appealing to authority all you like but I have looked into it and understand the benefits of moving the witness to a subtree of the merkle root so that it can be dropped when it is no longer needed as well as the other changes that are included in the update that allow further soft fork changes enough to see the benefits. I don't just accept someone saying it is good or bad. Can you explain why such an obvious refactor that is backward and forward compatible isn't a clear benefit? No it isn't sufficient and won't instantly increase the transaction throughput but the the arguments against it that I've heard are weak and almost all political and could also be argued as appeal to a different authority. There are two visions of what people see as scaling and are pushing for, on-chain and off-chain. Segwit helps both so being against it can only be politically motivated. |
|
|
I found this article describes the problem well: https://medium.com/the-publius-letters/segregated-witness-a-...
I'm not against segwit but I and many other have problems with segwit as a soft-fork. The push for a soft-fork segwit seems to be politically motivated.
> Can you explain why such an obvious refactor that is backward and forward compatible isn't a clear benefit?
If seen as a blocksize increase it isn't backwards compatible as old transactions will not get the benefit. It is also not transparent as all wallets needs to be updated to support the new transaction format. No such extra effort is needed for a blocksize increase.
It is in fact necessary to push for on-chain and off-chain scaling, nobody is against that. The position for "big blockers" has been the same for years: we need actual bigger blocks. See: https://medium.com/@johnblocke/the-importance-of-clear-defin...