Hacker News Reader

Comment by Natanael_L | Hacker News Reader

SegWit can only reduce bandwidth for clients that don't need to perform full validation. Blocksize is otherwise unchanged. Miners' and payment processors' bandwidth requirements are unchanged. Lightweight wallets does benefit, as does the nodes/servers they get their data from.

View on HN

SegWit is also intended up to open up some new middle ground security options-- e.g. making it realistically possible for nodes that verify a random fraction of the data; with a security model in between light an full.

It also addresses some of problems with validation costs that are quadratic in transaction size.

It's also, by far, not the only tool in the Increased-capacity-without-harming-decentralization tool belt, for example I recently described a new approach for signature aggregation which, if applied to the current transaction load would decrease transaction sizes around 30% while making verification somewhat faster.

The point is increasing transactions that can be included without hard forking.

All fully validating nodes must still download all the signature data. The total can not exceed 1MB per block without forking. SegWit does not reduce transaction sizes.

SegWit is not a compression technique, it is a bandwidth redundancy reduction technique. It simply makes it so that some nodes doesn't need to fetch all of the transaction data.

Take a look at the discount for segregated witness transactions. You'll see that in a world with segwit there are more transactions per block than without.

Can't be done without forking if the total data per block required to validate all the transactions exceeds 1 MB. Old full nodes will reject the blocks.

Only compression or merging can increase the transaction count per block without becoming incompatible with old full nodes.

Luke jr showed how you can implement segwit as a soft fork. The txs look like "anyone can spend" txs and the signatures are excised to the witness data structure (decreasing the tx size). To validate the segwit txs you need to upgrade, but it's not correct to say that a hardfork is needed to increase the number of txs per block.

Only works with a majority hashrate enforcing the new rules, and miners still need full bandwidth and storage like before. Then you really just create a secondary blocksize limit for the associated signature data. And old full nodes are silently converted into non-full nodes, SPV nodes.

But sure, it is a backwards compatible way to reduce overhead for old nodes. But if they want to remain full nodes then they must upgrade and take on larger storage and bandwidth requirements anyway.

AFAIK the intent of segwit is not to reduce overhead but to fix tx malleability. As an consequence of the politicized block size debate a discount was added to increase the number of txs per block--and this was seen as a compromise for the big blocker camp. It turns out you can roll it out with a softfork as well (and provide script versioning), making it a safer alternative to upping the limit with a contentious hardfork.

Can you clarify what you mean by the majority hash rate needs to enforce the new rules?

If they're anyone-can-spend scripts superficially, then old nodes will accept any attempt to spend, not just those of the actual intended recipient. Because they doesn't recognize the softfork rules that restrict who are supposed to be able to spend. To determine that you need the additional signature SegWit data, and only SegWit parsing nodes will understand the difference.

They're non standard and therefore don't get relayed by old nodes. They won't make it into the longer chain because we're assuming the fork is activated. So what does an attack look like, exactly?

If someone blindly accepts non-standard zero confs they've got bigger problems.

I just realized I might be wrong. Anyone-can-spend transactions will be non standard, but transactions spending those outputs might be standard (don't know offhand). In that case, the risk is someone accepting standard transactions with zero confs, which is slightly worse but still doesn't seem too bad considering that all such forks are well publicized and there's no guarantee for zero conf security.

Reply on news.ycombinator.com