How would you propose changing it?  I guess optionally you could hide transactions below a certain threshold (possibly the same limit as they will be uneconomical to spend anyways), but you can "undo" Bitcoin transactions even ones you don't "want".

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.

The reference client will not allow spending unconfirmed outputs received from outside the wallet.

If I send you 1 BTC right now, the client will indicate you do not have sufficient funds to make a tx if you try to spend it before it confirms.  Change outputs are handled differently though and could break transactions which use them before they are confirmed.

Yes.  The QT client (and all other clients AFAIK) does NOT allow spending unconfirmed outputs received from outside the wallet.  Change is treated differently and unconfirmed change is allowed to be spent.  Under normal conditions this is actually a beneficial thing (otherwise you can end up not being able to spend coins until change outputs confirm) but right now that action is undesirable.

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

No it is nothing like a 51% attack or even a normal double spend.  Using those terms just leads to unnecessary confusion and fear.

The issues outlined don't present a risk of losing funds for end users.   They do however have the possibility of making the client behave in a way that is counter intuitive to a user, especially one which is a non-developer and lacks a detailed understanding of what is going on behind the scenes.

I hadn't seen that update.  My intent wasn't to be controversial but to rather point out in plain english the types of issues that normal users running the reference client are likely to experience. I updated the title.

Well I don't know for sure if it the attacker has a direct connection OR if blockchain.info is relaying these non-standard transactions.  Without being on the receiving end of a spam attack I can't see where it is coming from.

Just putting both out as a possibility.  The attack may be doing all this on his own, or he may be just relaying them to blockchain.info knowing it will do the relaying for him, or he may be relaying them in additional to blockchain.info to increase the "coverage".  The relaying will stop when it hits a reference client so having multiple super nodes "helping" means it will reach more nodes.


Yes that is a good way to put it.  If you are running the QT client you aren't helping the spammer but if you got spammed it is going to show up.


Correct but the reference client (and other clients which enforce the same rules) make up a super majority of the bitcoin nodes.  Unless the attacker or some other custom super node (possibly blockchain.info) has a direct connection to you it is very likely all of your peers will drop these transactions and never rely them to you.

For example, maybe I was spammed and just don't know it because all my direct peers are nodes running the reference client (or one with similar relay rules).

Early statements seemed to suggest that this issue was limited only to custom implementations and services relying on the unconfirmed transaction id as proof of payment.  That normal users running standard clients were fine. This however isn't exactly the case anymore with one or more unknown third parties spamming modified versions of any transactions they receive into the network.  First let me say, none of this should be considered giving MtGox a pass.  Their issues go beyond just transaction mutability and the way they handled the issue was just awful however we can't pretend this isn't an issue for average users.  

I am running the stock reference client (Bitcoin QT or bitcoind) and don't externally use tx ids for any backend processing.  Am I stick affected?

Yes although the level this affects you may vary depending on your usage.  The Bitcoin reference client as currently implemented (i.e. QT client & bitcoind) does rely on transaction ids which can produce some unexpected behavior for end users.  Other major clients are likely affected to some degree you should contact the developers of those clients for more information.  To provide some reassurance these issues do not result in a risk of losing funds, but they can lead to scenarios which are confusing and complicated to resolved.  The long term goal should be immutable transaction ids (hashes) but a short term patch is also needed to make the behavior of the client predictable and intuitive.

The two major areas that a "normal user" will encounter unexpected client behavior relating to mutable transactions are duplicate transactions being reported & unconfirmed change output breaking subsequent transactions.

What is the problem with duplicate transactions being reported?
The first issue is that the QT client is blissfully unaware of the fact that a transaction is a duplicate (same inputs, outputs, and fee) of another transaction, so it reports both txs to the user as if they are unique transactions.  This can be confusing to the user. It may appear they received two payments, or that they accidentally spent coins twice.  Not only is the transaction reported twice, the duplicate(s) are included in the balance reported to the user which further reinforces the perception that the duplicates are an additional unique transaction.  This also appear to affect the balances in the "accounts" system of the reference client.

How can Transaction Mutability break break transactions which use unconfirmed change outputs?
All transactions use as their inputs (money going in) the outputs of a prior transactions.  The reference client as well as other major clients does not allow users to spend the output of unconfirmed transactions.  This is done for obvious reasons, the incoming transaction may never be confirmed and that would prevent any subsequent transactions from confirming as well.  If the clients allowed it this could be chained to involve many people.  Bob sends a coin to John who uses it unconfirmed to send a coin to Sarah who uses it unconfirmed to send a coin to Bill.  If Bob's tx doesn't confirm (say Bob double spent John, or the tx was spammy with no fee) then all the other tx break.  

Most clients however make an exception for unconfirmed change (i.e. output from a transaction back to the same wallet).   In the absence of a third party intentionally mutating transaction hashes this presents no issue as the wallet can be confident the transaction will eventually be confirmed.   The active efforts of malicious third parties, to mutate transactions however makes that assumption flawed and it should be changed.

Side note on inputs & outputs

The input portion of a transaction identifies the specific, unique output(s) being "spent" in the transaction by their unique combination of transaction id and index..  The input of a transaction doesn't reference a generic value (i.e. "spend one of my BTCs at this address") it references a specific output of a specific transaction (i.e. "spend output #0 of tx id 0e11592f65c349e44363362fe78791ccf3777da31b6bb0217422140212884356).  If the transaction id of the output being spent changes (and is included in a block) after the new transaction is created then it is referencing a transaction id which while valid can never be confirmed (because only one of the transactions in a pair of duplicates can be included in a block and the "other one" already is).  

At a protocol level the potential for an issue applies to any unconfirmed unspent output being spent in a new transactions.  The protocol makes no distinction between "normal" and "change" outputs.  Everything is an output.   However all "stock" clients prevent the user from spending unconfirmed outputs received from outside the wallet so unless you are running a modified or custom client the issue practically is limited to change outputs.  The reference client (and AFAIK many others) exempt "change" outputs from the requirement of being confirmed before being spent.  The tx id is being relied upon by the client while it is still mutable.  The tx id of the change output being spent may be modified, and the chance of that happening is now greatly increased due to ongoing malicious modification of transactions by one or more unknown third parties.

An example might help.  Lets image a hypothetical user which has a single unspent output worth 1 BTC and the user spends 0.6 BTC.  

A very simplified view of the tx would look something like this (non relevant portions removed)

Now this transaction is signed and hashed.  The transaction id is the computed hash, which in this example is "A".  The problem occurs if the user makes another spend before tx A is confirmed in a block.  There is no method for a user to restrict the client to only use confirmed change outputs in a new transaction.  So lets see what happens if the user creates a new tx and spends 0.3 BTC more.

Now this transaction is signed and hashed.  The hash is "B".  

Contrary to popular understanding of "spending coins", the user isn't spending some generic 0.4 BTC "balance" he is spending a specific unique output (id: "A", index: 1).  If a third party mutates tx "A" so this it now has a tx id of "Z", and "Z" not "A" ends up in a block first, then transaction "B" will never confirm.  It output it references (id: "A", index: 1) in the input side of the transaction can never be included in a block because "Z" already is.  

Potential short term fixes:
The first issue is really just a reporting issue.  The client is reporting data to the user which is confusing or inconsistent.  Clients should still record duplicate transactions but they should one a single tx in a duplicate pair should be shown to the user.  When the client computes the balance of the wallet, duplicates (both received and sent) should be excluded from the total.  Ultimately It doesn't matter which one of the duplicates is hidden as long as only one is shown.  The client will need to handle a situation where if flags and hides one transaction in a pair of duplicates and that ends up being the one which gets included in a block.  For consistency the confirmed transaction should always be shown to the user and the unconfirmed one hidden.  When this happens the user would see no change other than the tx id would change when the duplicate is included in a block.

The second issue can't be fixed other than by preventing the use of unconfirmed change.  The client could either by default or by user set option block all unconfirmed outputs from being spent.  The capability to do this already exists in clients as they already block the spending of "non-change" unconfirmed outputs.  Change would be treated the same as any other output.  Just 1 confirm is sufficient to ensure the tx id won't change in most cases.  In some situations this may result in the user not being able to make a second transactions until the change from the first one is confirmed.  Wallets can preemptively seek to reduce this scenario by monitoring the number of available outputs.  When the number of outputs is low, the client could use more than one change output in the next outbound transaction.  This requires no protocol changes because the protocol has no concept of "change" and already supports having more than two outputs.  A client could even prompt a user to authorize (will require wallet to be unlocked) the creation of a "splitting" transaction if the number of outputs is very low and the value is very high. A wallet with a three outputs with a value of one BTC each is more flexible than a wallet with only one output with a value of three BTC so the wallet could recommend the user split the output.

While these changes wouldn't make transactions immutable they would make the behavior of clients more consistent with the expectations of users and avoid confusing situations that can arise from transactions being mutated.



On edit: Changed title and introduction to reflect recent updates.

On edit2:  Yes mutability is a word.  OO languages have a concept of mutable (changeable) vs immutable (unchangeable) objects.  You can stop PM me that the "correct" word is malleable.  They are synonyms and developers programmers working in high level OO languages are more likely to use the word mutable over malleable.
http://en.wikipedia.org/wiki/Immutable_object

It does if your client uses unconfirmed change in a new outbound tx (which all of them do BTW).  The changing of the tx id will cause the child transaction to become invalid.

A temporary fix would be to
a) give users the ability to require change to have 1 confirmation before using it in a new tx.
b) flag duplicates txs and hide them so the user only sees one (and the balance only reflects one copy).

It isn't perfect but it would make the mutability a non-issue for ends users.  Service providers which keep records on outbound txs would still need to ensure they don't rely on tx ids.

I think you are misunderstanding.  

I send you 1 BTC.   It is tx id A.   Someone mutates it so there is a copy with tx id B.

You send a 0.1 BTC to your friend.   As a normal user it isn't you, but the QT client which picks which inputs are used.  The client picks tx id A, index 0 as the input for this new outbound tx.  It can do this because by the QT client right now uses unconfirmed change outputs as inputs in new txs.

Now lets say tx B not A ends up in a block.  Oops. 

The tx to your friend is now invalid, it uses as its input an output which is a double spend (tx a) of a valid confirmed tx (tx b) and thus will never confirm.  There is no user friendly way for you to remove that from your wallet.  Most users may not even know why it didn't work.  They will see the tx to their friend simply never confirms.  It won't be marked as a double spend (because it isn't) it simply will never confirm because it is no longer valid, it became invalid as soon as B not A was included in a block.  It can be solved but it is far from user friendly.  Now imagine that happening for thousands of users every single day forever because some malicious user is intentionally mutating tx to cause chaos.  Nobody ends up losing coins but it makes the system look bad, counterintuitive, and confusion especially for newer users.

If you wait until a tx is confirmed then the txid is immutable (baring a network re-org) and this becomes a non-issue.  Right now there is no way for an average user to force the client to only used confirmed change in new transactions even if they wanted to, other than manually wait and make sure they have no unconfirmed change outputs before sending funds.

The later.  It would be a client side change only and wouldn't require the support of anyone beyond the user using it.

There is no hard protocol rule which handles relaying.  A node can choose to relay whatever it wants.  While it is true the reference client won't relay these transactions I see two possibilities:
a) the "attacker" is directly connected to the receivers who see the spam.  The attacker can relay whatever it wants and while the QT client won't relay spam it will retain a local copy once it knows about it.

and/or

b) blockchain.info is relaying non-standard transactions and thus in this case making things worse.  Blockchain.info is connected to a lot of nodes so if it chooses to relay spam a lot of end users will end up seeing it.

It is also possible some other clients may relay tx below the 5430 sat threshold, and users running older versions of the bitcoin client will also continue to relay these types of transactions, but while they may expand the scope alone I doubt they alone have enough "coverage" without a or b above.

The best way to find out would be for someone who received the spam tx to record where they received the tx message from.  Not the sending bitcoin address but which peer sent the the tx message to their node.  Alas sadly I wasn't spammed so I can't help.

Wrong theories aren't worth much.  Transactions aren't sent to a particular address, there is nothing to trace.


Um there is thing called the blockchain which already contains every valid address that has received bitcoins.  For an "attacker" to send you a satoshi they would already by definition need to know your address and know it is valid.   

Bitcoin private keys can't be brute forced.  There isn't enough energy in our solar system.   If they could then someone sending you a satoshi is the least of your worries. 

You shouldn't re use a paper wallet after you import it into QT client and SPEND.  This is because the QT client sends the change to a new address.  So if you assume it went back to the original address, and then deleted the QT wallet you will lose coins.

You can receive an unlimited number of transactions TO a paper wallet.  They wouldn't be very useful otherwise.  Someone sending you can extra satoshi will do absolutely no harm to a paper wallet.  Unless some miner is very generous it is very likely the tx will never confirm anyways and will eventually be dropped by the network.

Not it would simply be an unconfirmed tx and after the parent is dropped it becomes an invalid tx.

However it is a genuine case for concern.  There is no profit in it, but the combination of:
a) malicious user malling all tx
and
b) the QT client using unconfirmed change outputs in new tx

can lead to a lot of confusion and broken transactions.   I am not sure what the immediate fix it.

One option would be to either by default or by a user enabled option don't use change outputs until they have at least 1 confirmation.  That combined with simply "hiding" duplicates would make the mutated spam pretty much invisible to "normal users".  Merchants and service providers not using a payment processor need to understand the mutability of txids but honestly they already should.

The QT client (and all clients) should be patched to delete or "hide" duplicates, and give user the option to no spend unconfirmed change.  

That would make the "mutate tx attacks" a non-issue (other than you can't assume tx id won't change which is more of an issue for service providers than end users).

"Nobody sell money for 20% off.  Nobody ... unless they have no intention on paying."

Depends on how secure the password is.  Humans are generally very bad at picking secure passwords.  If you took a hundred random people and asked them for their "Secure" password a good % of those will be on compromised password lists so they can be attacked in a matter of minutes.   A larger group will be simply too short to provide brute force resistance.

So yes the attacker needs the wallet and password but if you wallet is on dropbox and the password for your wallet is the same password you use everywhere (including dropbox) well you probably are going to lose the wallet.

... or if the attacker can trick you into providing the password you are going to lose the wallet.

... of if the attacker can brute force your password because you though SexM@n123 was a secure passord then you are probably going to lose the wallet.

What makes you think well connected nodes requires some massive expense and cost?

Also for MtGox most of their tx were defective in some way and being dropped by relay nodes.   You could have sent the tx to a miner by bike messenger and it would have "beat" MtGox.