The benefits are listed and explained in more detail at
https://bitcoincore.org/en/2016/01/26/segwit-benefits/You of course forgot one of the biggest things this fixes which is the O(n^2) hashing problem. With segwit it is incredibly difficult to produce a large transaction which would require several seconds to a few minutes to verify.
Segwit is a softfork
- it hardly qualifies as a soft fork; users & wallets that do not implement segwit and receive funds from a segwit TX will end up with TX they cannot validate.
they should be able to spend the funds even if they dont upgrade they simply see the TX as anyone-can-spend, when infact noly they can spend...
- Segwit allows a softfork by requiring a significant wast of space in the wtxid, it should be implmented as a hardfork.
This is not true. The wtxid is never stored anywhere in the blockchain, nor is the regular txid. It does not waste space.
its only 1kb wasted, softforks are favorable.
- calling segwit a softfork might lead people to believe they do not need to upgrade, confidence in the dev team will drop as these users figure out that it was indeed a mandatory upgrade.
-SegWit is technically superior as a hard fork. Witness proofs would be about 50% or 1,000 Bytes larger, and code would be more complex, as a soft fork.
Users do not need to upgrade. They can simply continue to spend and use Bitcoin as they do now to no ill effect.
How is it technically superior as a hard fork? The only difference that would have been made if it was a hard fork is that committing the witness root hash would have occurred in the block header instead of an OP_RETURN output in the coinbase. The amount of data needed to be stored would have been the same except if it was hard forked everyone would have to upgrade but as a soft fork there is no mandatory upgrade.
I have no idea what you mean by "witness proofs would be about 50% or 1,000 Byes larger". The witnesses would have been the same no matter what.
The implementation of segwit is complex and multifaceted
- all the different wallets will need to implement segwit themselves, its unlikely they will all get it right the first time, could lead to some serious loses.
That is true, but the core devs have helped with that by creating a document to explain all of the segwit changes and help developers implement segwit into their code. See
https://bitcoincore.org/en/segwit_wallet_dev/Bitcoin is fairly simply to explain, poeple can trust it because they understand it, segwit makes understanding bitcoin an order of mangure more complex, which could lead to poeple not trusting bitcoin.
You still explain it in the same way. Functionality has not changed, and neither have most of the abstractions that people use to describe Bitcoin. The only thing that changes is a little bit of the technical stuff which, to the average person, is already extremely complex because on a technical level Bitcoin doesn't use the command abstractions of an address or balances.
Upon adoption, segwit creates a 4X adversarial attack surface.
miners and network engineers have to design their systems to be able to handle 4 MB blocks without bogging down, but we only get to actually use about 40% of that capacity. This 4x adversarial case will make it very difficult to increase the blocksize limit in the future. With a 1 MB base block size, it's 4 MB, but with a 2 MB base block size, the adversarial case would be 8 MB.
Future block size increases need not be in 1 Mb increments. They can be in 0.25 Mb increments or something else so that the intended effective block size can be achieved.
Introduces a new type of DOS attack (go-fish-wit-ddos)
An attacker mines a segwit-block with 1000 transactions the network has not yet seen (The attacker creates these TX herself )The attacker has the witness data readily available. When other miners try to validate this block they will go through every single one of these TX and say "I don't have the witness data for this TX_ID, I have to call TCP::GetWitnessData( TX_ID ) aw yes this is valid"
No, not possible. Nodes will request from that miner the block with the witness serialization by using the inv type MSG_WITNESS_BLOCK. The miner must send the block with the transactions with the witness serialization otherwise the block will be invalid. If the witnesses are not there, the node doesn't know that and will calculate the witness root hash. If that doesn't match what is committed in the coinbase, then the block is invalid and subsequently rejected. They will not be requesting the witness data for each and every transaction in the block.
Subsidizes signature data in complex/large multisig transactions.
Weights signature data at 1/4 the level of transaction/UTXO data. Signatures are more expensive to validate than UTXO, so this is not justifiable in terms of computational cost.
Not sure what that means and where you got that info from. Could you explain this?
Increased resource usage (capacity, bandwidth, processing power)
Same can be said about other scalability proposals. Block size increase will require more capacity, bandwidth, and processing power to handle more and larger blocks.
