What the "average user" needs to know about Transaction Mutability

[eldentyrell]

Wouldn't there be some way to discourage miners from solving a block with malleated (or should I say mallified :-) ) transactions?

No, it is not possible.  Some forms of transaction mutation, like the ECSDA sign-inversion mutation, can't be distinguished from the original even if you have both of them side-by-side.

There are other forms of mutation involving alterations to the script.  There have been proposals to prohibit obviously-mutated scripts (like scripts with a bunch of no-ops stuck on the end), but going beyond the obviously-mutated scripts risks accidentally banning useful scripts or future uses of the script system not currently foreseen.

A middle ground is to come up with rules for preferred transactions (ECDSA sig has the preferred sign, DER encoding, only very basic scripts) and hold any non-preferred transactions until the next block to see if a preferred spend of the same outputs shows up.  But you can't force miners to do this and it's slightly contrary to their interests since they'd have to forego the transaction fee and essentially give it to whoever finds the next block instead of taking it for themselves.  Cooking up new rules also isn't the sort of thing you want to do in a crisis like the current situation.

[Barek]

This changes nothing on the usual practice that once a transaction is part of the blockchain it is safe to trust it. A 51% attack actually rewrites the blockchain.

NO it actualy doesn't: https://en.bitcoin.it/wiki/Attacks#Attacker_has_a_lot_of_computing_power

Sorry for the tangent, second time that 51% BS was creeping in, and thank you DandT.

Uhm, yes, it does? With enough time and >50% you can start at any point in the blockchain and eventually overtake the current one.

That is why there is the 6 confirmations thing. The more confirmations there are the harder it is to create a malicious fork. With >50%, all bets are off.

[FeedbackLoop]

This changes nothing on the usual practice that once a transaction is part of the blockchain it is safe to trust it. A 51% attack actually rewrites the blockchain.

NO it actualy doesn't: https://en.bitcoin.it/wiki/Attacks#Attacker_has_a_lot_of_computing_power

Sorry for the tangent, second time that 51% BS was creeping in, and thank you DandT.

Uhm, yes, it does? With enough time and >50% you can start at any point in the blockchain and eventually overtake the current one.

That is why there is the 6 confirmations thing. The more confirmations there are the harder it is to create a malicious fork. With >50%, all bets are off.

You made it sound both as if the attacker could re-write past blocks (before he managed to compute a lot of blocks in a row) and that he could do whatever he wanted with the blocks he wrote and both are not true. I felt I should shortly dispel that idea in this thread due to the potential readership. But please lets not derail this. I will stop responding to this off-topic. Thanks again DT.

[dorobotsdream]

Wouldn't there be some way to discourage miners from solving a block with malleated (or should I say mallified :-) ) transactions?

No, it is not possible.  Some forms of transaction mutation, like the ECSDA sign-inversion mutation, can't be distinguished from the original even if you have both of them side-by-side.

There are other forms of mutation involving alterations to the script.  There have been proposals to prohibit obviously-mutated scripts (like scripts with a bunch of no-ops stuck on the end), but going beyond the obviously-mutated scripts risks accidentally banning useful scripts or future uses of the script system not currently foreseen.

A middle ground is to come up with rules for preferred transactions (ECDSA sig has the preferred sign, DER encoding, only very basic scripts) and hold any non-preferred transactions until the next block to see if a preferred spend of the same outputs shows up.  But you can't force miners to do this and it's slightly contrary to their interests since they'd have to forego the transaction fee.  Cooking up new rules also isn't the sort of thing you want to do in a crisis like the current situation.

I was under the impression that the Sign conversion / Modulo change of the signature was immediately obvious, because the default client would only choose positive R and S and there is only one other solution in the available length.

Maybe the majority of miners could cooperate to block the spending of matured coins from a coinbase of a block that contains more then the usual share of malleated transactions by not accepting it in a block for mining. Then the original miners would have to spend a double effort to spend their coin.

[agath]

Did I understand wrong, or in the example TX.A the user spends 0.6 and not 0.4?

[DeathAndTaxes]

Did I understand wrong, or in the example TX.A the user spends 0.6 and not 0.4?

Oops typo.  Good catch.  Should be fixed now.  He spends 0.6 BYC, receives 0.4 BTC back as change.

[rebel24]

Can some of you guys please respond to my post on the first page.

I think I understand and have made it pretty clear and easy to understand, but I want to be sure.



And a short cliffnote/tidbit is-
this only affects VERY RECENT transactions. ie 100 transactions down the blockchain are not at risk, only VERY recent in which the attacker is fighting against the time to get his altered transaction recorded before the original transaction got recorded (and of which he would have to have control over both the sending and receiving wallet to get his bitcoins back AND request a withdrawl from the exchange, thus getting the cash AND the coins, is this right? (please do answer that as I believe its very pertinent to the problem)

[DeathAndTaxes]

This only affects unconfirmed transactions.  Once confirmed tx ids are immutable (baring a re-org of the blockchain).

[eldentyrell]

I was under the impression that the Sign conversion / Modulo change of the signature was immediately obvious, because the default client would only choose positive R and S and there is only one other solution in the available length.

Only if it's immediately obvious that every user is using OpenSSL-linked bitcoin-qt.  That's neither obvious nor true!

For example, the transactions I use to move coins in and out of cold storage are generated by a javascript client, since it can run on an "air-walled" laptop with no network connection.  A lot of people do this.  In that case the sign of the ECDSA signature depends on what javascript VM I'm using…  Standards are standards, especially for crypto -- never a good idea to start assuming people are using specific implementations.

[HairyMaclairy]

Can someone please confirm if Bitcoin QT will show the correct balance after say six blocks.

In other words the false balance only displays for unconfirmed transactions.

*edit*. Can the casual user completely avoid this issue by waiting for at least one confirmation before spending a second transaction? 

[btcash]

Best statement issued so far.

The first issue is that the QT client is blissfully unaware of the fact that a transaction is a duplicate of another transaction, so it reports both txs to the user as if they are unique transactions.

1. I send a tx->Bitcoin-QT stores the TX and deducts the amount from the spendable balance (this tx can be prunned later)
2. Attacker creates a duplicate transaction
3. The malicious duplicated TX gets in a block
4. I receive the block->Bitcoin-QT stores the "new" tx and deducts the amount again
-> 2 identical TX (besides the ID) in the history and the double amount deducted

So Bitcoin-QT can not handle transaction malleability in general or under what circumstances do these duplicates appear in Bitcoin-QT? Does Bitcoin-QT continue to rebroadcast the original TX?

[dorobotsdream]

I was under the impression that the Sign conversion / Modulo change of the signature was immediately obvious, because the default client would only choose positive R and S and there is only one other solution in the available length.

Only if it's immediately obvious that every user is using OpenSSL-linked bitcoin-qt.  That's neither obvious nor true!

For example, the transactions I use to move coins in and out of cold storage are generated by a javascript client, since it can run on an "air-walled" laptop with no network connection.  A lot of people do this.  In that case the sign of the ECDSA signature depends on what javascript VM I'm using…  Standards are standards, especially for crypto -- never a good idea to start assuming people are using specific implementations.

Yes, but wouldn't it be beneficial to agree on a canonical signature with positive R and S that gets preferential treatment for mining? Otherwise with your change hanging on confirmations, you could get severely limited in exchanging digital coins which supposedly are the new fast thing.

[DeathAndTaxes]

Best statement issued so far.

The first issue is that the QT client is blissfully unaware of the fact that a transaction is a duplicate of another transaction, so it reports both txs to the user as if they are unique transactions.

1. I send a tx->Bitcoin-QT stores the TX and deducts the amount from the spendable balance (this tx can be prunned later)
2. Attacker creates a duplicate transaction
3. The malicious duplicated TX gets in a block
4. I receive the block->Bitcoin-QT stores the "new" tx and deducts the amount again
-> 2 identical TX (besides the ID) in the history and the double amount deducted

So Bitcoin-QT can not handle transaction malleability in general or under what circumstances do these duplicates appear in Bitcoin-QT? Does Bitcoin-QT continue to rebroadcast the original TX?

The duplicates appear whenever you node learns of them.  Either when a peer relays the duplicate to your node, or when a peer relays a block containing the duplicate to your node.

It is important to understand you don't actually "pay twice".  The balance *reported* by the client may be reduced but this is a reporting issue.  It would be like if you have 100 gold bars in a vault and the auditor miscounts it as 99 or 101.  The reported balance will be incorrect, but your wealth really hasn't changed but .  The incorrect report can't change the amount of actual gold in the vault.

If the duplicates were "hidden" from display and counting (and the balance is simply counting the value of all unspent outputs) it would display correctly.

[eldentyrell]

Yes, but wouldn't it be beneficial to agree on a canonical signature with positive R and S that gets preferential treatment for mining?

That's what I suggested:

A middle ground is to come up with rules for preferred transactions (ECDSA sig has the preferred sign, DER encoding, only very basic scripts) and hold any non-preferred transactions until the next block to see if a preferred spend of the same outputs shows up.  But you can't force miners to do this and it's slightly contrary to their interests since they'd have to forego the transaction fee and essentially give it to whoever finds the next block instead of taking it for themselves.  Cooking up new rules also isn't the sort of thing you want to do in a crisis like the current situation.

I think the point is that this wasn't done when transaction mutability was first noticed, and at the moment it can't be done quickly enough to solve the problem.

PS, like your username.  And, yes, they do -- of electric sheep.  At least the androids.

[dorobotsdream]

PS, like your username.  And, yes, they do -- of electric sheep.  At least the androids.

Thanks. Or maybe they are counting Satoshi's. 

Still, delaying a non canonical transaction to a later block wouldn't be a problem for miners, or would it? The original transaction should be there to mine also, unless it is a transaction which actually uses the capabilities of the script format and has a good fee. But then it wouldn't be a problem to mine it.  And in the end it is in the interest of the miners when bitcoin functions well and is valued, because it increases the value of their reward.

Also the stick could be applied to keep miners that apparently prefer non canonical transactions for no valid reason and keep them from spending matured coins unless they mine them theirselves.

[eldentyrell]

The original transaction should be there to mine also,

Yeah, and whoever finds the next block gets the fee, instead of you.

It simply isn't in the interest of any particular miner (or pool).  The decision about transaction inclusion is made by each miner (or pool) individually; it's not some sort of thing that the miners collectively vote on "for the common good".

[justusranvier]

Clients should also record but flag and hide duplicate transactions (but not true double spends involving different outputs).  The client should not include these flagged/hidden transactions in the balance computations. Ultimately It doesn't matter which one of the duplicates is hidden as long as one is.  If the flagged tx is the one which is ultimately confirmed then the duplicate flag should be moved to the other copy.  The user would see no change other than the tx id would change when the duplicate is included in a block.

The more permanent fix is to identify transactions by inputs and outputs, and (correctly) treat the relationship between transactions and txids as one-to-many.

That way a client could do the right thing if multiple txids appear for the same transactions: display the duplicates seen on the network at least until the transaction is unconfirmed, and optionally discard the ones that don't make it into the blockchain.

[btcash]

Either when a peer relays the duplicate to your node, or when a peer relays a block containing the duplicate to your node.

Doesn't Bitcoin-QT reject a duplicate TX that inputs are already used by another TX the node knows about? I think getting the duplicated TX in a block is the only way to create a duplicated transaction visibility. Correct me if I am wrong.

[DeathAndTaxes]

Either when a peer relays the duplicate to your node, or when a peer relays a block containing the duplicate to your node.

Doesn't Bitcoin-QT reject a duplicate TX that inputs are already used by another TX the node knows about? I think getting the duplicated TX in a block is the only way to create a duplicated transaction visibility. Correct me if I am wrong.

You are incorrect.  

The node will not RELAY it to other nodes but it records and shows all transactions related to your inputs or outputs that it becomes aware of.

[btcash]

Either when a peer relays the duplicate to your node, or when a peer relays a block containing the duplicate to your node.

Doesn't Bitcoin-QT reject a duplicate TX that inputs are already used by another TX the node knows about? I think getting the duplicated TX in a block is the only way to create a duplicated transaction visibility. Correct me if I am wrong.

You are incorrect.  

The node will not RELAY it to other nodes but it records and shows all transactions related to your inputs or outputs that it becomes aware of.

Reminds me of the satoshi spam issue. Thanks for clarification.