The malleability attack is creating a lot of trouble, we need a quick fix

[jl2012]

The malleability attack becomes a DOS attack. We need a quick fix. Before there is a better solution, the bitcoind should not report unconfirmed transactions. Account balance should be solely based on confirmed transactions. Before malleability is fixed (if ever), unconfirmed outputs should not be spent.

[thenoblebot]

I already have highlighted an attack scheme here (https://bitcointalk.org/index.php?topic=458608.0) for those entities using the txid to track payments.

People have been proposing using other means to track payments and rightly so. But my suggestion even in the above thread has been to at least issue an advisory for entities using txid to stop.

However, I do realise the consequences of such a step : 1) It has already been highlighted before that its not the correct way to do it. 2) Issuing an advisory at such a point might only give more legitimacy to claims by Gox (which is obviously a silly thing to do).

[buffett]

oh gosh this issue need to be fixed asap. it might be not a big issue for bitcoin enthusiast who understand how it works. but for common people, it is a very big concern! it's not common a tx id can be changed in any payment systems. if we transfer money with our bank, or paypal, the tx id wont change, forever. developers used to rely on tx id for any payment systems in the past.

[nmersulypnem]

The devs are notoriously slow...  They aren't even talking about it on the development mailing list today.

I guess that's what happens when you become rich...  well, they'll soon know what it's like to be poor again...

[bitbouillion]

So why not create own txids from the blockchain and compare them to the transmit log, to see if a tx went through?

[NanoAkron]

We need a quick fix.

Quick fixes are never the right answer. I'd rather they took their time and produced a good fix.

[NanoAkron]

The devs are notoriously slow...  They aren't even talking about it on the development mailing list today.

I guess that's what happens when you become rich...  well, they'll soon know what it's like to be poor again...

Are you kidding? They've been discussing it on github:

https://github.com/bitcoin/bitcoin/pull/3651

[nmersulypnem]

The devs are notoriously slow...  They aren't even talking about it on the development mailing list today.

I guess that's what happens when you become rich...  well, they'll soon know what it's like to be poor again...

Are you kidding? They've been discussing it on github:

https://github.com/bitcoin/bitcoin/pull/3651

ah, thanks. I'll retract my comment.  I was looking in the wrong place.

EDIT: sorry, looking at that pull request - it doesn't seem like it's going to fix the problem.  It'll just patch the wallet to not recognize the unconfirmed trandsactions.  Malleable transactions will still happen, we'll still be subject to the DDOS, and the exchanges will still need to make significant changes to their accounting software before re-opening withdrawals.

Let me know if I got anything wrong there.

[Peter Todd]

The devs are notoriously slow...  They aren't even talking about it on the development mailing list today.

I guess that's what happens when you become rich...  well, they'll soon know what it's like to be poor again...

Are you kidding? They've been discussing it on github:

https://github.com/bitcoin/bitcoin/pull/3651

ah, thanks. I'll retract my comment.  I was looking in the wrong place.

EDIT: sorry, looking at that pull request - it doesn't seem like it's going to fix the problem.  It'll just patch the wallet to not recognize the unconfirmed trandsactions.  Malleable transactions will still happen, we'll still be subject to the DDOS, and the exchanges will still need to make significant changes to their accounting software before re-opening withdrawals.

Let me know if I got anything wrong there.

You are. We're talking to those pools about how they can make use of that patch and others to make their accounting software work.

[thenoblebot]

You are. We're talking to those pools about how they can make use of that patch and others to make their accounting software work.

Hi Peter,

I believe to an extent there is some truth (about the delay). Check the mailing list, I believe you replied to me yesterday about the issue. I won't say any further about the concerned topic on the forums here. But yea it kind of a sad situation when the process could have been expedited. Ah nvm - lips sealed .

Cheers

[nmersulypnem]

You are. We're talking to those pools about how they can make use of that patch and others to make their accounting software work.

I see that now in some of the other github threads.  Just a question thoguh:  Does the Bitcoin Foundatoin have any type of PR person?  I mean, there are real merchant & consumers out there that are seeing their BTC jump up and down 20% every day.

Some sort of press release saying that the issue is known and is being worked on, would help a lot.  I mean, it was mentioned on the front page of the Wall Street journal this morning for Christ sake.

[tacotime]

This is what I would do; ignore txid itself, but instead use the output from 4.):
1.) For any incoming transaction generate a list of inputs and values from inputs, concatenate into a string; sort addresses alphanumerically before doing so
2.) Generate output hashes and values and concatenate into above string; sort addresses alphanumerically before doing so
3.) Concatenate the pubkeys from the inputs that are regenerated from the signatures (NOT the signatures themselves) into the above string; sort pubkeys alphanumerically before doing so
4.) Hash this big string and use it as the txid

Even if someone regenerates signatures at random for any tx, the above will never change.  Any duplicate tx that are mutated will come up the same using the above scheme.

Probably even more simply you can just skip step 1.) and put the values of the inputs after their respective pubkeys and then stick it into a string along with the outputs

This can be implemented quickly, probably in 30 min - 1 h.  Exchanges verifying that a tx went through need only look for the above alternative txid hash in the next block and then can verify its incorporation into the blockchain.

I'm tired and going to bed so I hope this is coherent, but verifying blockchain incorporation using this scheme should enable protection from tx malleability

Comments welcome

[thenoblebot]

This is what I would do; ignore txid itself, but instead use the output from 4.):
1.) For any incoming transaction generate a list of inputs and values from inputs, concatenate into a string; sort addresses alphanumerically before doing so
2.) Generate output hashes and values and concatenate into above string; sort addresses alphanumerically before doing so
3.) Concatenate the pubkeys from the inputs that are regenerated from the signatures (NOT the signatures themselves) into the above string; sort pubkeys alphanumerically before doing so
4.) Hash this big string and use it as the txid

Even if someone regenerates signatures at random for any tx, the above will never change.  Any duplicate tx that are mutated will come up the same using the above scheme.

Probably even more simply you can just skip step 1.) and put the values of the inputs after their respective pubkeys and then stick it into a string along with the outputs

This can be implemented quickly, probably in 30 min - 1 h.  Exchanges verifying that a tx went through need only look for the above alternative txid hash in the next block and then can verify its incorporation into the blockchain.

I'm tired and going to bed so I hope this is coherent, but verifying blockchain incorporation using this scheme should enable protection from tx malleability

Comments welcome

Hi tacotime,

Easier fix would be to track transactions using (add,amt,time) .... no ?

Btw your quite an inspiring character, read some of your posts when trying to mine initially. Thanks for all the work you have put it. Appreciate it a lot

Regards

[Lethn]

Quick fixes would be disastrous for Bitcoin, it's a very simple example but take Battlefield 4 as a perfect example of how not to fix code, if you rush out large patches very quickly that fix very little you'll not only piss off the people using the software you'll also create more problems in the process because you haven't checked the code and made sure the changes you've made haven't fucked something else up which is exactly what happened when DICE were rushing out patches when the game first came out.

Take the time to look at it properly, if anything if the situation gets worse it will become a lot more obvious what is wrong with the code because more and more people will be trying to abuse it.

[DeathAndTaxes]

Easier fix would be to track transactions using (add,amt,time) .... no ?

There are no timestamps in bitcoin transactions.

[thenoblebot]

Easier fix would be to track transactions using (add,amt,time) .... no ?

There are no timestamps in bitcoin transactions.

Try this in the console :

gettransaction 6baf826a0c5dcd22d28640233cae375cf8a3b37cf7251a93475986e3f42fa823-000

Output :

{
"amount" : 0.00016720,
"confirmations" : 16124,
"blockhash" : "000000000000000a0f90a320fd1adea3bfefee716fa98c9f10625021d8d4f29e",
"blockindex" : 655,
"blocktime" : 1383072371,
"txid" : "6baf826a0c5dcd22d28640233cae375cf8a3b37cf7251a93475986e3f42fa823",
"time" : 1383070892,
"timereceived" : 1383070892,
"details" : [
{
"account" : "Default",
"address" : "1rU2kc24GcRUjXLm3MZ8RQtjL1zpcsnK3",
"category" : "receive",
"amount" : 0.00016720
}
]
}

What are those "time" and "timereceived" ? Although again its kind of circular where we have to depend on txid :-( .. maybe another way to get those perhaps will do the trick.

[oakpacific]

Easier fix would be to track transactions using (add,amt,time) .... no ?

There are no timestamps in bitcoin transactions.

Try this in the console :

gettransaction 6baf826a0c5dcd22d28640233cae375cf8a3b37cf7251a93475986e3f42fa823-000

Output :

{
"amount" : 0.00016720,
"confirmations" : 16124,
"blockhash" : "000000000000000a0f90a320fd1adea3bfefee716fa98c9f10625021d8d4f29e",
"blockindex" : 655,
"blocktime" : 1383072371,
"txid" : "6baf826a0c5dcd22d28640233cae375cf8a3b37cf7251a93475986e3f42fa823",
"time" : 1383070892,
"timereceived" : 1383070892,
"details" : [
{
"account" : "Default",
"address" : "1rU2kc24GcRUjXLm3MZ8RQtjL1zpcsnK3",
"category" : "receive",
"amount" : 0.00016720
}
]
}

What are those "time" and "timereceived" ? Although again its kind of circular where we have to depend on txid :-( .. maybe another way to get those perhaps will do the trick.

There is no way you can verify independently whether these time datas are correct.

[thenoblebot]

There is no way you can verify independently whether these time datas are correct.

Hmmm. Are you referring to the median time that is used ? Or are you getting a different output ? Its from the blockchain so it should be consistent for all of us as long as there is no reorganisation .. isn't it ? This should work for confirmed transactions with a mutated txid as a check, isnt it ?

Please help me understand more.

[oakpacific]

There is no way you can verify independently whether these time datas are correct.

Hmmm. Are you referring to the median time that is used ? Or are you getting a different output ? Its from the blockchain so it should be consistent for all of us as long as there is no reorganisation .. isn't it ? This should work for confirmed transactions with a mutated txid as a check, isnt it ?

Please help me understand more.

Well, on second reading you've pointed out yourself that if you don't check the txid then the time datas can actually be tampered with by the relaying nodes before it's mined, I have nothing new to add.

[DeathAndTaxes]

There is no way you can verify independently whether these time datas are correct.

Hmmm. Are you referring to the median time that is used ? Or are you getting a different output ? Its from the blockchain so it should be consistent for all of us as long as there is no reorganisation .. isn't it ? This should work for confirmed transactions with a mutated txid as a check, isnt it ?

Please help me understand more.

It isn't from the blockchain it is from the client.   The time is not part of the transaction.  The wallet provides additional data beyond the actual transaction.  In your example does it seem likely that "account" = "Default" is also part of the transaction?


This is a bitcoin transaction.
https://en.bitcoin.it/w/images/en/e/e1/TxBinaryMap.png

There is no timestamp in the transaciton.   Relying on timestmamps is even less secure than relying of tx id.  It doesn't take any clever modification of the transaction to change the timestamp.