Why should Bitcoin protocol accept all openssl formats?
What we need is a protocol, not mad people whining in a forum. That sure won't make them change.
Thanks
Topic: New Attack Vector (Read 46618 times)
For the record, there is another possibility of signature malleability.
For every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. Note that the new signature has the same size as the original, as opposite as the malleabillity of padding.
For every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. Note that the new signature has the same size as the original, as opposite as the malleabillity of padding.
i can complete right upto sending then i get an error.. and its not scriptsig64 i have a solution for tht
Perhaps i didn't read it right; does malleability cause any issues in the real world for anyone that only deals with confirmed transactions?
Potentially.
https://bitcointalksearch.org/topic/what-the-average-user-needs-to-know-about-transaction-mutability-460944
The two issues that would face a user using a stock client would be incorrect reporting of duplicate tx and problems with spending unconfirmed change output. Both are described in the linked thread.
There are pull requests to provide better handling of both issues and eventually they will be included in the mainline client. These "fixes" don't make tx id immutable (that will require a protocol enhancement) but they will cause wallets to behave in a more expected manner when they encounter duplicate transactions. The long term solution is to make tx ids immutable (or at least immutable by third party) but that will take a lot longer as it may require a hard fork.
Perhaps i didn't read it right; does malleability cause any issues in the real world for anyone that only deals with confirmed transactions?
I believe the attack you describe is possible and real, but the effect is less troublesome. As soon as a modified echo of the transaction is included in a block, both sender and receiver will see this transaction too. The old transaction will linger on however, unconfirmed.
Ouch. I don't think he took all the variables when be made this call
This actually is quite similar to another "corner case" that I've been wondering about. Consider the following scenario:
User downloads installs bitcoin into a windows virtual machine, the copies the virtual machine to multiple locations.
Each of the virtual machines attempt to engage in transactions (receiving, sending, or even mining and block verification.)
What function is mitigating the collisions between clients, and which client becomes most authorative? While I see how this could result in issues in transaction confirmation, wouldn't confirmations by those cloned entities result in confirmation corruption?
Collisions are handled by the Bitcoin protocol. When you submit a transaction to the network, miners will begin to try to add it to the block chain. When a miner successfully mines a block, it is added to the block chain and other miners see this and begin working off of the new top block. There is a chance that two blocks are submitted nearly at the same time - and some miners see one block and other see the other block. This results in a fork of the block chain. Some miners will be working on one prong of the fork, while others work on the other prong. At each new block, miners will always begin working on the longest prong. Eventually, the longer prong becomes so long that all mining stops on the shorter prong, and it is orphaned - never to surface again. User downloads installs bitcoin into a windows virtual machine, the copies the virtual machine to multiple locations.
Each of the virtual machines attempt to engage in transactions (receiving, sending, or even mining and block verification.)
What function is mitigating the collisions between clients, and which client becomes most authorative? While I see how this could result in issues in transaction confirmation, wouldn't confirmations by those cloned entities result in confirmation corruption?
It might be a good idea to patch this before some enterprising person with excess time on their hands (cough) makes a cloned transaction echobot.
Yep, that might have been a good idea
Well this really came back as a big issue didn't it.
It might be a good idea to patch this before some enterprising person with excess time on their hands (cough) makes a cloned transaction echobot.
Gotta say Enochian gets props for seeing this so far ahead of time. It's almost too bad someone didn't make an echo bot to force the issue 2 years ago, so it'd have been fixed one way or another before bitcoin was so massive.
While Bitcoin is brilliant in that it makes mining significantly more profitable than cracking passwords, we do not yet have an altcoin that creates currency from proof-of-exploit.
So while it's easy to see some of these holes, there are perverse financial incentives that make it significantly more profitable for news media to make superheros and villians of the developers and hackers, depending on which side of the market you are on. In the meantime they have shell companies that tie up all the people who DO see the holes with non-disclosure agreements, and exploit insider access to that information to take the unsuspecting public's money.
The first step is admitting you have a problem.
The second step is charging a retainer any time someone uses the word 'confidential', 'proprietary' or 'shareholder value'
It might be a good idea to patch this before some enterprising person with excess time on their hands (cough) makes a cloned transaction echobot.
Gotta say Enochian gets props for seeing this so far ahead of time. It's almost too bad someone didn't make an echo bot to force the issue 2 years ago, so it'd have been fixed one way or another before bitcoin was so massive.
Is there concrete evidence in the block chain? Are there indeed altered transactions in the pool? Is Mt. Gox blowing smoke?
In my opinion, the answers are no, possibly, and yes. The issue is that I create and broadcast a transaction with TxId "X". Someone can tweak it to an equivalent (same send and receive addresses) transaction with TxId "Y". Assuming everything else about the transactions are valid, either one (but not both) might get pulled into the blockchain. I say there's no concrete evidence in the blockchain because the TxId only has an unambiguous meaning once it's incorporated into a block. At any given time, it's possible that both "X" and "Y" flavors of a transaction could be floating around in different unmined tx pools, but any given miner should only accept one. I think Mt. Gox is blowing smoke because everyone else seems to be able to deal with this issue satisfactorily, and the issue by itself doesn't explain all the problems folks are seeing at Gox.
Do you work for Gox?
Have you seen their code?
If not, then you are blowing smoke, and contributing a smokescreen to a market-manipulation coin-robbery of epic proportions.
If any exchange wants an independent review of their code, and a productive environment in which to fix any problems found, I will do it at no cost for code that will be disclosed to the public. If you have proprietary exchange code, my retainer for an NDA starts at $5000.
We have a bunch of guys with NDAs and 'secret proprietary code' all running around issuing press releases about how the other guy sucks, while the handlers that pay their bills are scooping up all the bitcoins they can before the heroic developers, who have been working on this day and night, issue a magical fix and the price of bitcoin doubles.
If broadcasting transactions to the entire network was a good idea for bitcoin, it's probably a good idea to broadcast the code that runs exchanges too. Unless you like handing your money over to the banksters, in which case I guess I can take your money too.
Interestingly other exchanges are having problems today also ...
Bitstamp and BTC-E
https://bitcointalksearch.org/topic/bitstamp-btc-withdrawal-problem-459836
Bitstamp and BTC-E
https://bitcointalksearch.org/topic/bitstamp-btc-withdrawal-problem-459836
Bter also suspended BTC withdrawals.
Interestingly other exchanges are having problems today also ...
Bitstamp and BTC-E
https://bitcointalksearch.org/topic/bitstamp-btc-withdrawal-problem-459836
Bitstamp and BTC-E
https://bitcointalksearch.org/topic/bitstamp-btc-withdrawal-problem-459836
Is there concrete evidence in the block chain? Are there indeed altered transactions in the pool? Is Mt. Gox blowing smoke?
In my opinion, the answers are no, possibly, and yes. The issue is that I create and broadcast a transaction with TxId "X". Someone can tweak it to an equivalent (same send and receive addresses) transaction with TxId "Y". Assuming everything else about the transactions are valid, either one (but not both) might get pulled into the blockchain. I say there's no concrete evidence in the blockchain because the TxId only has an unambiguous meaning once it's incorporated into a block. At any given time, it's possible that both "X" and "Y" flavors of a transaction could be floating around in different unmined tx pools, but any given miner should only accept one. I think Mt. Gox is blowing smoke because everyone else seems to be able to deal with this issue satisfactorily, and the issue by itself doesn't explain all the problems folks are seeing at Gox.
Is there concrete evidence in the block chain? Are there indeed altered transactions in the pool? Is Mt. Gox blowing smoke?
I was wondering how block intervals relate to this issue.
Would a coin with a 30 minute block interval be more susceptible to such a problem?
The coin itself isn't affected by transaction malleability, as one of the transactions will eventually be mined and at some point the coins will successfully be sent to their destination address as the sender intended. Software written to rely on tracking a txid alone is susceptible to such a problem. A solution would be tracking coins by their confirmed (immutable) outputs rather than tracking the txid that contains those outputs.Would a coin with a 30 minute block interval be more susceptible to such a problem?
Block time specifically, or any function of time, does not have much to do with this.
I was wondering how block intervals relate to this issue.
Would a coin with a 30 minute block interval be more susceptible to such a problem?
Would a coin with a 30 minute block interval be more susceptible to such a problem?
great thread reboot.
a very interesting read.
this issue has been know about for a long time, but it's still here and now it's causing problems.
a very interesting read.
this issue has been know about for a long time, but it's still here and now it's causing problems.
it makes it nearly impossible to create a alternative client, when the "standard" mutates all the time. bitcoin needs diversity in clients.
Do you have any idea what you're talking about?
The DER encoding for signatures is the most standard one that exists. We've been discussing enforcing the standard for a _year_ before implementing it - because, unfortunately, not everyone was following the same rules.
Do you know why we want to enforce this standard? To make sure Bitcoin can be implemented without relying on OpenSSL.
Jump to: