4

It's important to point out that segwit doesn't prevent malleability: in many ways the actual transaction data can still be changed by third parties. It just makes it harmless for the purposes of dependant transactions/higher level protocols, because when malleated, the resulting transaction will still have the same txid as the original. To get this ...


3

Does that mean that non-SegWit transactions are still malleable? Yes. Segwit does not change non-segwit inputs so the malleability fixes it introduces only apply to segwit inputs. If so, what types of malleability could still happen in practice? All of them (except the ones where the sender modifies the transaction himself). None of these are consensus ...


2

The transaction that you submitted and the transaction that was malleated in-flight or by a miner are both legitimate (valid) transactions. Transaction malleability means that a valid transaction can be modified in-flight, without invalidating it and without access to the relevant private keys. Even if changing the components of the transaction doesn't make ...


2

What malleability means is that you can create a transaction that is identical in its meaning (same inputs, same outputs) but with a different TXID. That is problematic for 2nd layer protocols where transactions build onto each other but aren't necessarily published to chain. But a "malleated" transaction is still a double spend. And it appears newer ...


2

The data of the scriptSig is mooved from TransactionInput to RawTransaction, so the Raw transaction doesn't is malleability? maybe I can't imagine what really happened to non-witness transactions during malleability, can you give me an example? The transaction ID is a hash of the entire transaction data structure (the version, inputs, outputs, signatures, ...


1

Yes. Many of the malleability sources listed in BIP 62 still exist today. Most (if not all) are not standard, i.e. most nodes will not relay transactions that exploit them, but they are not consensus rules. So a miner can still perform malleability attacks.


1

Yes, you are correct. Joseph Poon and Tadje Dryja in their Lightning Network whitepaper proposed the SIGHASH_NOINPUT flag to prevent transaction malleability flaw hampering the creation of commitment transaction prior to funding transaction. However, with the deployment of SegWit in 2017, NOINPUT was not longer needed as signatures are not part of the txid ...


1

Why the witness data is stored outside the block? what do you mean? I think I don't understand the sense of this space-saving because the witness data is present inside the blk file. The signatures are in the block. All signatures of a block form another merkle tree and are keeping in an output of the coinbase tx. I think this refers to the "UTXO set" ...


Only top voted, non community-wiki answers of a minimum length are eligible