Stats on malled transactions

[dexX7]

Do you know where these  28k for "nonstandard transactions come from? Normal nodes do not relay them. At least that is what I thought.

Hm. I'm unable to draw any conclusions based on the debug.log, but I extracted some lines and put it up on pastebin.com:

Code:

"version" : 80500,
"protocolversion" : 70001,
"walletversion" : 60000

http://pastebin.com/raw.php?i=qbt1Mgpw (nonstandard transaction type)
http://pastebin.com/raw.php?i=D1xzU0FU (inputs already spent)

It appears that those non standard tx are not relayed, as you mentioned.

Edit:
Spam marketing/advertisement via dust transactions has nothing to do with the mallability spam bot.

[Syke]

Don't worry, the amount of attempted double spends is irrelevant.

Just trying to find out if the exchange I am using will go bust 

Malled transactions cannot steal coins.

MtGox is losing coins because they are allowing customers to perform a withdrawal, claim they never received it, and then MtGox manually sends them a new withdrawal!

Does your exchange do that?

[BitAddict]

Don't worry, the amount of attempted double spends is irrelevant.

Just trying to find out if the exchange I am using will go bust 

Malled transactions cannot steal coins.

MtGox is losing coins because they are allowing customers to perform a withdrawal, claim they never received it, and then MtGox manually sends them a new withdrawal!

Does your exchange do that?

Why no one uploaded a video in youtube telling how to receive unlimited bitcoins using the malleability trick on MtGox? 

[klondike_bar]

here is my concern situation:

You have a bitcoin-qt wallet with 3BTC
you send 1BTC to somebody, and the wallet also sends some BTC to a change address within itself
a malled txid repeats this exact same transaction, and is seen by the bitcoin-qt wallet

what happens:
a) your wallet shows a balance of 2BTC and an unconfirmed txid that will never complete
b) your wallet shows a balance of 1BTC because it thinks that there is 1BTC that you sent away waiting on confirmation
c) your wallet shows something else entirely because the change addresses get FUBAR'd

My biggest concern is that while these malled transactions wont cause clients/wallets to report the wrong balance for received transactions (because it never confirms the second deposit), what if it is incorrectly displaying balances after a SENT transaction is malled with a copied txid that the wallet sees in the blockchain and beleives you have asked toi send funds

[Carlton Banks]

Any observable correlation with specific mining pool/s? Seems like a large number of successful id mutations

[nmersulypnem]

Can we get updated stats thus far today?

[itod]

here is my concern situation:

You have a bitcoin-qt wallet with 3BTC
you send 1BTC to somebody, and the wallet also sends some BTC to a change address within itself
a malled txid repeats this exact same transaction, and is seen by the bitcoin-qt wallet

what happens:
a) your wallet shows a balance of 2BTC and an unconfirmed txid that will never complete
b) your wallet shows a balance of 1BTC because it thinks that there is 1BTC that you sent away waiting on confirmation
c) your wallet shows something else entirely because the change addresses get FUBAR'd

My biggest concern is that while these malled transactions wont cause clients/wallets to report the wrong balance for received transactions (because it never confirms the second deposit), what if it is incorrectly displaying balances after a SENT transaction is malled with a copied txid that the wallet sees in the blockchain and beleives you have asked toi send funds

None of the a), b) or c) you've suggested is correct, although a) is close. Your wallet will show 2 BTC, and one of the two transactions, original or mutated one, will be confirmed and included in the blockchain permanently. Only thing that is let to be uncertain is the TxID of the confirmed transaction, it can be either one of these, depending on the miner who finds the block which includes the transaction, that miner decides which one will be in the blockchain forever.

Bitcoin-qt wallet is completely unaffected by this problem, so there's zero chance you can lose funds. Unfortunately, exchanges can't use that wallet in a way single persons use it because they serve multiple accounts, so they make their own wallet software implementation. MtGox software is sub-par, and depends on the TxID to account for the payment, which is unacceptable, only inputs and outputs inside the transaction should define if the funds are moved or not.

[dserrano5]

Only thing that is let to be uncertain is the TxID of the confirmed transaction, it can be either one of these, depending on the miner who finds the block which includes the transaction, that miner decides which one will be in the blockchain forever.

AFAIK the miner doesn't get to decide either, it takes the first (version of the) transaction it receives from the network.

[Loozik]

Don't worry, the amount of attempted double spends is irrelevant.

Just trying to find out if the exchange I am using will go bust  

Malled transactions cannot steal coins.

OK. Get it.

MtGox is losing coins because they are allowing customers to perform a withdrawal, claim they never received it, and then MtGox manually sends them a new withdrawal!

It is my understanding that both Gox and Stamp allowed this scheme - both halted btc withdrawals.

Does your exchange do that?

Gox and Stamp are my exchanges. I wanted to find out if there is a way to aproximate the value of double withdrawals from Gox and Stamp up till now.

E.g. someone finds a 7.95757474 BTC transaction from Gox address to a dishonest client's address on a certain day and next finds a corresponding doubled withdrawal of 7.95757474 BTC a few days later.

This is just an idea by a non-techie (me), so don't laugh at me.

Would it be at all possible to estimate the value of double withdrawals (effected through malled transactions)? If the exchanges were tricked into resending 1k BTC then it's no problem. If they were tricked into resending 100k BTC, then we might have a big problem.

[itod]

Only thing that is let to be uncertain is the TxID of the confirmed transaction, it can be either one of these, depending on the miner who finds the block which includes the transaction, that miner decides which one will be in the blockchain forever.

AFAIK the miner doesn't get to decide either, it takes the first (version of the) transaction it receives from the network.

Yes, that's what I've meant, "decide" was not the right term. One group of miners will receive original transaction first, the other group will receive the mutated one first. Whichever group submits solved block to the blockchain first "decides" which transaction is committed. Notice that whoever mutates these transaction must be very, very quick to be successful doing this, original transactions move across the network fast, and they have to beat them before they propagate to the majority of the network.

[GCInc.]

Malled transactions cannot steal coins.

You sure? It's pretty usual practice for Bitcoin merchants to update database upon transaction first seen in the network.

Usually funds are not released until confirmations come in, but I'm willing to bet there are businesses experiencing considerable losses because their bitcoind reports two incoming transfers while only one is valid.

Malled transactions never get even a single confirmation, right?

[itod]

Would it be at all possible to estimate the value of double withdrawals (effected through malled transactions)?[/b] If the exchanges were tricked into resending 1k BTC then it's no problem. If they were tricked into resending 100k BTC, then we might have a big problem.

It's not quite easy to hide your identity from the exchanges, one mistake and you reveal your router's IP to them. After that you are at their mercy not to bring up criminal investigation at you. MtGox maybe will not chase somebody and report him to the authorities for 1 BTC, but for 1k BTC they would surely do everything to put whoever does this in jail.

[nmersulypnem]

Would it be at all possible to estimate the value of double withdrawals (effected through malled transactions)?[/b] If the exchanges were tricked into resending 1k BTC then it's no problem. If they were tricked into resending 100k BTC, then we might have a big problem.

It's not quite easy to hide your identity from the exchanges, one mistake and you reveal your router's IP to them. After that you are at their mercy not to bring up criminal investigation at you. MtGox maybe will not chase somebody and report him to the authorities for 1 BTC, but for 1k BTC they would surely do everything to put whoever does this in jail.

If you think massive bitcoin network attack is going to be exposed by linking to an IP address, then you greatly underestimate who you're dealing with.

[itod]

Would it be at all possible to estimate the value of double withdrawals (effected through malled transactions)?[/b] If the exchanges were tricked into resending 1k BTC then it's no problem. If they were tricked into resending 100k BTC, then we might have a big problem.

It's not quite easy to hide your identity from the exchanges, one mistake and you reveal your router's IP to them. After that you are at their mercy not to bring up criminal investigation at you. MtGox maybe will not chase somebody and report him to the authorities for 1 BTC, but for 1k BTC they would surely do everything to put whoever does this in jail.

If you think massive bitcoin network attack is going to be exposed by linking to an IP address, then you greatly underestimate who you're dealing with.

Keep in mind that exchange has in their logs every IP from which you accessed them ever. That data is never erased and regularly log-rotated and backuped for legal purposes. I'm not saying it will be easy for them to catch who's messing with them, but you can bet they will do everything to reveal real identity of that account holder.

[Bogart]

Two transactions with different hashes and with overlapping inputs.
The definition is not entirely correct as a malled tx is not a double spend.

it will result in one though if the user has also tried to spend the change output of the original transaction that was voided by the malleable one. this seems to be happening quite a lot based on network chatter. probably because the client allows spending the change while it's unconfirmed.

I'm no expert on this stuff, but I'm wondering, could this behavior in the reference client be amplifying the effects of the malled TX attack as measured in the OP?  i.e. When a client attempts to spend unconfirmed change that never gets confirmed because its tx got malled, is that also counted as a double-spend attempt?

[DeathAndTaxes]

Two transactions with different hashes and with overlapping inputs.
The definition is not entirely correct as a malled tx is not a double spend.

it will result in one though if the user has also tried to spend the change output of the original transaction that was voided by the malleable one. this seems to be happening quite a lot based on network chatter. probably because the client allows spending the change while it's unconfirmed.

I'm no expert on this stuff, but I'm wondering, could this behavior in the reference client be amplifying the effects of the malled TX attack as measured in the OP?  i.e. When a client attempts to spend unconfirmed change that never gets confirmed because its tx got malled, is that also counted as a double-spend attempt?

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.

[Cygnify]

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.

Would that require a hard fork or just software update on bitcoin-qt and other wallet software? Im guessing the latter. That sounds like a short term solution at least.

[DeathAndTaxes]

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

[itod]

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.

It really is not that much of a problem IMHO. If those change outputs will eventually confirm or not has nothing to do with mutated TxID. If someone wants to include unconfirmed change outputs as his new inputs that's his problem. His last transaction will eventually confirm if those outputs are regular payment, or fail if it is double-spend attempt. The system is designed to work this way.

[DeathAndTaxes]

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.

It really is not that much of a problem IMHO. If those change outputs will eventually confirm or not has nothing to do with mutated TxID. If someone wants to include unconfirmed change outputs as his new inputs that's his problem. His last transaction will eventually confirm if those outputs are regular payment, or fail if it is double-spend attempt. The system is designed to work this way.

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.