Pages:
Author

Topic: What the "average user" needs to know about Transaction Mutability - page 5. (Read 38935 times)

newbie
Activity: 14
Merit: 0
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.
hero member
Activity: 968
Merit: 515
Best statement issued so far.

Quote
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?
legendary
Activity: 1414
Merit: 2174
Degenerate bull hatter & Bitcoin monotheist
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? 
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.
donator
Activity: 1218
Merit: 1079
Gerald Davis
This only affects unconfirmed transactions.  Once confirmed tx ids are immutable (baring a re-org of the blockchain).
member
Activity: 114
Merit: 10
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)
donator
Activity: 1218
Merit: 1079
Gerald Davis
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.
full member
Activity: 164
Merit: 100
Did I understand wrong, or in the example TX.A the user spends 0.6 and not 0.4?
newbie
Activity: 14
Merit: 0
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.
hero member
Activity: 742
Merit: 500
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.
full member
Activity: 168
Merit: 100
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.
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.
hero member
Activity: 742
Merit: 500
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.

full member
Activity: 168
Merit: 100
And if I understand correctly, this is an issue where the THEIVES have to act QUICKLY.

If you wait 10-20 minutes (confirmations), then there is way too many computers, ie: the whole network with the transaction and question already confirmed and buried under other ones- can't change the hashes now. (lest you do a 51% attack, which presumably again is harder with the passage of time)

The thieves can only copy transactions, they cannot change the contents. Only one of the copies can be included in the blockchain. If further transactions are based on one of the transactions that will never be part of the blockchain, all these transactions will also timeout when the not-included copy does.

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.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Wouldn't there be some way to discourage miners from solving a block with malleated (or should I say mallified :-) ) transactions?

If there is less of a reward, it might not be worth the energy or investment, and if malleated transaction do not get mined, they would be pointless, wouldn't they?

There really is no such thing as a Bitcoin "network" it is a loose organization of independent nodes.  A particular node has no way of knowing which tx is the original and which one is the modified one.  The modified one potentially could be received first.   There is also no way to reduce the compensation to miners as the tx and its duplicate are identical in terms of the inputs, outputs, and fee paid.

It may be possible to reduce the % of times that the duplicate gets included in a block by improving the tx selection criteria among miners who voluntarily upgrade their systems, but it probably would never reduce it to zero even among participating miners.  There is also the possibility that the attacker/griefer is also mining and favoring the duplicates over the original.   Both are valid copies of the transaction, a block containing either one is considered valid by other nodes.


member
Activity: 114
Merit: 10
You guys agree or what?

You misunderstand. There is an explanation here.

https://bitcointalksearch.org/topic/explain-the-gox-transaction-malleability-issue-like-you-are-five-458386


Well although the problem was known before, nobody exploited it on a large scale until now. And why now?

Because Mt.Gox put it in the spotlight. I doubt more than a handful of people were aware of this before.

Because MtGox said they would not allow withdrawals until the issue non-issue was fixed. They dug a hole and this is their way of forcing a fix so they can get out of it.

I actually think I do understand.... I read that first post, and it confirms what I said in my post above. Correct me if I'm wrong but I think I'm right.


And if I understand correctly, this is an issue where the THEIVES have to act QUICKLY.

If you wait 10-20 minutes (confirmations), then there is way too many computers, ie: the whole network with the transaction and question already confirmed and buried under other ones- can't change the hashes now. (lest you do a 51% attack, which presumably again is harder with the passage of time)
legendary
Activity: 3430
Merit: 3080
Sensible suggestions D&T, as has been pointed out, the first solution has already been implemented.


Interesting that Mt Gox appeared to be the only affected service at first. It looks like the "attacker" waited until Gox announced on Monday, watched the markets react, then stabilise, then unleashed the attack on the other exchanges on Tuesday.

So, systematic FUD campaign? Seems very like it. And the biggest wave of the whole attack happened just after a few bad news stories, too. Someone's definitely trying to exploit the exchange rate.
newbie
Activity: 14
Merit: 0
Wouldn't there be some way to discourage miners from solving a block with malleated (or should I say mallified :-) ) transactions?

If there is less of a reward, it might not be worth the energy or investment, and if malleated transaction do not get mined, they would be pointless, wouldn't they?
member
Activity: 70
Merit: 10
You guys agree or what?

You misunderstand. There is an explanation here.

https://bitcointalksearch.org/topic/explain-the-gox-transaction-malleability-issue-like-you-are-five-458386


Well although the problem was known before, nobody exploited it on a large scale until now. And why now?

Because Mt.Gox put it in the spotlight. I doubt more than a handful of people were aware of this before.

Because MtGox said they would not allow withdrawals until the issue non-issue was fixed. They dug a hole and this is their way of forcing a fix so they can get out of it.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Well although the problem was known before, nobody exploited it on a large scale until now. And why now?

I have two theories.  The mass mutating of transactions occured shortly after MtGox suspended withdrawals and the statement by core developers so my assumption is the "mass mutater(s)" are either
a) the same entities which used it to exploit MtGox's lack withdraw system.  Now that the option to stealthily profit from this is gone, they are just using it to "grief the network"

OR

b) it is someone trying to prove a point  ("oh it isn't a problem, and only affects poorly designed custom clients? Well lets just see about that").

Either way the reality is that mass modification of transaction hashes has never occurred before.  But the genie is out of the bottle now, and given the ease at which someone looking to disrupt the network can carry on this modifications I don't expect they will stop.  Casual users are the ones who are most likely to be affected (caught in the crossfire) simply because they may not understand what is going on.  The issues are more of a nuisance nature, and don't present a security risk (outside of those incorrectly relying on txid for unconfirmed tx as proof of transactions) but they do make the system as a whole look bad (likely the intent of whoever is doing it).
Pages:
Jump to: