please delete

[SapphireSpire]

nothing to see

[pooya87]

Generate the txid after a transaction has been created but before signing it and include the txid with the parts of the transaction that get signed.

You mean what SegWit soft fork did 4.5 years ago?
txid is defined as you explained, hash of the transaction ignoring the "witness" which contains signature or scripts that may change. Then we have wtxid which is the same but with witness. In referencing transactions (eg as inputs) txid is used.

[Quickseller]

maleability was solved years ago when transactions that were maleabilated became non-standard.

[Charles-Tim]

Your simple solution to transaction malleability? What has been proposed in BIP62 and solved in BIP146 which proposes a change to bitcoin transaction validity rules to fix signature malleability related to ECDSA.

Or about taproot that makes use of schnorr signature? The SUF-CMA security of schnorr signature is enough to make malleability of taproot transactions to be impossible.

SUF-CMA security of Schnorr signatures implies that they are non-malleable. On the other hand, ECDSA signatures are inherently malleable[3]; a third party without access to the secret key can alter an existing valid signature for a given public key and message into another

[vjudeu]

Currently, typical coins are locked on some hash of the public key. That means any valid (r,s) pair can be used as a signature. But what about locking some output to some fixed r-value, so that there is only one correct s-value per transaction? Because r-value is just (k*G).x, it represents x-value of some ECDSA point, so it can be calculated in any deterministic way where the coin owner would know "k", but the rest of the world would only know "r". I know that checking the whole signature with OP_EQUAL is possible (but quite pointless, because then it can be used only in upfront-defined transaction), but is there any way to check only r-value of that signature? That could solve point 9 in BIP62: "The sender (or anyone with access to the relevant private keys) is always able to create new signatures that spend the same inputs to the same outputs".

[BlackHatCoiner]

Currently, typical coins are locked on some hash of the public key. That means any valid (r,s) pair can be used as a signature. But what about locking some output to some fixed r-value, so that there is only one correct s-value per transaction?

And instead of the hash of the public key, the receiver would give you the hash of the r-value? At the moment, they give you a hash of the public key and once you send them your money, they can spend it if they meet the following condition: If they provide a message which says they want to spend it, a public key that once you hash it it'll give you the hash you've locked your money and a valid pair of (r,s).

Right now, the sender just gives the public key which means they can change their signature since they can change r. Assuming we locked coins on the hash of the r-value and didn't announce what's the hash of the public key, what would stop someone from changing d (private key) each time?

Wouldn't the signature remain the same only if we gave both r AND public key?


Also, what's the problem if the sender can create multiple signatures when spending the same inputs to the same outputs?

[pooya87]

Using "r" value makes no sense with the definition of ECDSA (or other similar digital signature algorithms) because it requires you to also store "k" or the ephemeral private key to compute "s" later on, which was not supposed to be stored in first place. Besides it doesn't even make sense in terms of asymmetric cryptography where you publish your public key and then produce a signature for any arbitrary message that can be verified using that pubkey.

[kano]

...
This is how Mt. Gox was tricked into paying millions more than they should have.
...

Bullshit
There's no 'millions' involved in Gox screwing over everyone (and me included).

Anyway, the original malleability issue was only an accounting system issue for people who didn't code their system well.

Bitcoin core has NO address index - I guess it's too hard for them to code
So anyone using Bitcoin and needing an accounting system, has to watch addresses.

That same malleability exists today - it's called RBF - odd that no one is jumping up and down about RBF

[pooya87]

Bitcoin core has NO address index - I guess it's too hard for them to code

People are already complaining about the size of the "database", they will complain more if we add pointless indexes on top of it that only satisfies certain use cases and is just a burden for a regular full node user.

That same malleability exists today - it's called RBF - odd that no one is jumping up and down about RBF

That is not the same.
Unlike RBF, the actual malleability doesn't need access to the private keys. Anyone could just take literary any transaction and perform certain acts like inserting any garbage at the beginning of signature script and create unlimited number of still-valid transactions.

That doesn't justify the incompetence of those who coded MtGox though.

[gmaxwell]

This is how Mt. Gox was tricked into paying millions more than they should have.

Didn't happen.  MTGox was insolvent because they were robbed starting back in 2011 and were insolvent ever since.

https://blog.wizsec.jp/2015/04/the-missing-mtgox-bitcoins.html

can then claim that they haven't been paid knowing that the sender won't be able to find the txid of the original transaction in the blockchain and doesn't know the txid of the altered copy

That isn't how anyone determines if someone has been paid.  Mtgox did lose a tiny amount of funds due to repayments but this was mostly because they were issuing payments using unspendable immature coinbase outputs and then reissuing the payments without doing anything about the immature payments, some of which eventually became mature and went through.

The problem of malleability was that when you make a transaction you may use as inputs the outputs of prior transactions, often your own change output (unless you want to be restricted to make only a single transaction per block you must sometimes spend unconfirmed change).  Then third parties (or other signers) can alter the transaction and invalidate the subsequent spends.

This was fixed years ago through segwit by changing the signature hash to not cover the signatures of the prior transactions (just as you write "If instead the txid is generate before the signature, and therefore without it,").  Now only first party signers can create chain-breaking replacements which is the strongest protection possible (no stronger would be possible because unconfirmed double spends can't be prevented).