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

ECDSA signatures are pairs (r,s) such that r = x(m/sG + r/sP) mod n, where P is the public key and m is the message digest. x() in that equation means "the X coordinate of". In that equation, if you substitute s = -s', you get *r = x(m/(-s')*G + r/(-s)P) mod n, or *r = x(-(m/s'*G + r/s'P)). However, it is true that for any point Q, x(Q) = x(-Q), as ...


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

If [a funding transaction only consuming segwit inputs] was for preventing tx malleability it should be a MUST. Slightly above the quoted text, it says: "The sender MUST set: [...] funding_txid to the transaction ID of a non-malleable transaction." Segwit inputs are not required in case the sender knows a non-segwit way to create a malleability-resistant ...


2

The following is my humble understanding, I am not an expert in BOLTs. First, the reason to include this requirement is indeed transaction malleability. If malleable outputs are consumed for the funding transactions, then: funding_txid may change after the transaction is broadcasted; checking the status of the tx may fail (funding_locked); the channel will ...


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, ...


2

The transaction ID is the SHA256d(signedTransaction) = SHA256(SHA256(signedTransaction)). Sha256d is SHA256 applied two times. Example: Let us consider the transaction with ID 844c00ca065bc26eb61bfee203df2f7bcbc72a6bb77697a32d2a98dad5941109. The hex encoding of this transaction is: ...


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 ...


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" ...


1

The punishment transaction construction requires an immutable commitment transaction. Transaction malleability was an issue in that regard because it allows for more than one valid version of the same transaction.* Before the funding transaction is committed to the blockchain, the two channel partners are exchanging commitment transactions that allow each ...


1

All transaction data is committed to the WTXID, unlike in the case of TXID's. Malleability is found in the unlocking script/data of a transaction. It is malleable, because is not committed to the signature (circular dependency). Sources of TX Malleability: Signature Malleability Input Script Malleability See BIP62 for a great overview of TX ...


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