You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this video James describes how the input script operation can be malleated without affecting validity. Can you speak more to how this can be taken advantage of? You mentioned it wasn't easy to correct, but are there any proposals to fix?
Why do layering protocols require tx malleability to be fixed?
How should one understand anyone-can-spend outputs? Do nodes with and without the SegWit upgrade behave differently while validating enforcing? How?
How do the SegWit script versions conceptually differ from the versions on transactions? Why couldn't the transaction versions be used to support newer functionality without hard forks?
Where are the locking script operations in P2WPKH/P2WSH?
How can new script versions remain backwards compatible?
What is weight/virtual bytes?
What rationale was used to decide on the 4 MB SegWit block weight (3 x old_tx_bytes + segwit_tx_bytes), instead of say a 2 MB block weight (old_tx_bytes + segwit_tx_bytes)?
How is witness data committed to the block?
What is the quadratic sighash problem prior to Segwit? How does BIP 143 solve this?
What would be the additional steps to include the fraud proofs described at the bottom of this doc and by Sipa in 2015 via a softfork?
How do users know whether miners support SegWit prior to activation?
How does a (virtual block increase) affect IBD cost over time?