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.
Topic: The malleability attack is creating a lot of trouble, we need a quick fix - page 2. (Read 5716 times)
February 12, 2014, 02:50:35 AM
February 12, 2014, 02:03:45 AM
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
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
February 12, 2014, 01:09:49 AM
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
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
February 11, 2014, 06:08:09 PM
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.
February 11, 2014, 03:47:51 PM
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
February 11, 2014, 03:42:52 PM
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...
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.
February 11, 2014, 03:13:46 PM
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...
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.
February 11, 2014, 03:06:06 PM
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...
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
February 11, 2014, 03:04:52 PM
We need a quick fix.
Quick fixes are never the right answer. I'd rather they took their time and produced a good fix.
February 11, 2014, 02:02:00 PM
So why not create own txids from the blockchain and compare them to the transmit log, to see if a tx went through?
February 11, 2014, 02:01:23 PM
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...
I guess that's what happens when you become rich... well, they'll soon know what it's like to be poor again...
February 11, 2014, 01:51:00 PM
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.
February 11, 2014, 12:39:43 PM
I already have highlighted an attack scheme here (https://bitcointalksearch.org/topic/imp-malleability-attack-scheme-458608) 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).
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).
February 11, 2014, 12:31:42 PM
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.
Jump to: