4 ms·
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
by sonoffett 11y ago
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?
- Natanael_L 11y agoIf 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.
- ikeboy 11y agoThey'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.
- ikeboy 11y agoI 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.