What the "average user" needs to know about Transaction Mutability - page 5.

dorobotsdream

newbie

Activity: 14

Merit: 0

Quote from: eldentyrell on February 11, 2014, 08:28:56 PM

Quote from: dorobotsdream on February 11, 2014, 08:09:24 PM

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.

btcash

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?

HairyMaclairy

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?

eldentyrell

donator

Activity: 980

Merit: 1004

felonious vagrancy, personified

Quote from: dorobotsdream on February 11, 2014, 08:09:24 PM

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.

DeathAndTaxes

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

rebel24

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)

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: agath on February 11, 2014, 08:09:35 PM

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.

agath

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?

dorobotsdream

newbie

Activity: 14

Merit: 0

Quote from: eldentyrell on February 11, 2014, 07:55:24 PM

Quote from: DeathAndTaxes on February 11, 2014, 07:37:17 PM

Quote from: dorobotsdream on February 11, 2014, 07:32:46 PM

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.

FeedbackLoop

hero member

Activity: 742

Merit: 500

Quote from: Barek on February 11, 2014, 07:58:57 PM

Quote from: FeedbackLoop on February 11, 2014, 07:55:13 PM

Quote from: Barek on February 11, 2014, 07:47:35 PM

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.

Barek

full member

Activity: 168

Merit: 100

Quote from: FeedbackLoop on February 11, 2014, 07:55:13 PM

Quote from: Barek on February 11, 2014, 07:47:35 PM

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.

eldentyrell

donator

Activity: 980

Merit: 1004

felonious vagrancy, personified

Quote from: DeathAndTaxes on February 11, 2014, 07:37:17 PM

Quote from: dorobotsdream on February 11, 2014, 07:32:46 PM

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.

FeedbackLoop

hero member

Activity: 742

Merit: 500

Quote from: Barek on February 11, 2014, 07:47:35 PM

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.

Barek

full member

Activity: 168

Merit: 100

Quote from: rebel24 on February 11, 2014, 07:36:56 PM

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: dorobotsdream on February 11, 2014, 07:32:46 PM

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.

rebel24

member

Activity: 114

Merit: 10

Quote from: Stevets on February 11, 2014, 07:30:44 PM

Quote from: Barek on February 11, 2014, 07:18:11 PM

Quote from: rebel24 on February 11, 2014, 07:13:53 PM

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

Quote from: TheFootMan on February 11, 2014, 07:17:50 PM

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)

Carlton Banks

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.

dorobotsdream

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?

Stevets

member

Activity: 70

Merit: 10

Quote from: Barek on February 11, 2014, 07:18:11 PM

Quote from: rebel24 on February 11, 2014, 07:13:53 PM

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

Quote from: TheFootMan on February 11, 2014, 07:17:50 PM

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: TheFootMan on February 11, 2014, 07:17:50 PM

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

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