Hacker News Reader

Comment by ikeboy | Hacker News Reader

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