GMaxwell (Core #Bitcoin dev): It is exceptionally unlikely that malleability will be fixed in the year
Just because malleability won't be fixed this year doesn't mean they can't mitigate these DDoS attacks through other ways. That made no sense unless you actually present a way to mitigate this by presenting a feasible course of action. Everything else is just hope and faith. The DDOS is due to the fact that most clients currently allow you to spend unconfirmed change outputs. There are already patches being worked which will allow the user to require at least 1 confirmation before spending change outputs. There are also patches being worked which will hide the duplicate transactions. Exchanges and service providers will still need to not rely on tx id as canonical proof of payment but they shouldn't be doing that right now anyways. Relying on tx id as confirmation of a withdraw won't result in a denial of service, it will result in the exchange being robbed. More info: https://bitcointalk.org/index.php?topic=460944.msg5089865#msg5089865Also not all services are halted. BitSimple is still operating, the malleability of tx id doesn't affect our processing engine at all. |
|
|
|
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.pngThere 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. |
|
|
|
|
BitSimple still works fine. Also we don't hold client bitcoins so if we ever did have to take our wallet offline, no client bitcoins would be "frozen".
|
|
|
|
The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)
It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.
this is probably related to the current malleability attack on the bitcoin network (25% of transactions were affected today). it has nothing to do with your theft.
In addition to the above jgarzik is quoted on reddit to have said that one home PC could have done this. One home PC can screw up 25% of transactions! Hold on. Are there actually any reports of something being screwed, apart from couple of exchanges who stopped withdrawals as a precaution measure? It depends on what you mean by "screwed up". The attacker can't change the inputs or outputs or fees, however they can change the tx hash of unconfirmed txs. There were over 16,000 tx "mutated" in the last 24 hours. I am sure they weren't all withdraws from exchanges. It would appear the attackers are simply mutating in mass all transactions they are able to and broadcasting the mutated version into the network. If the mutated version of the tx is the one which gets confirmed it can have consequences for any user. https://bitcointalk.org/index.php?topic=460944.0So, don't deliver until the transaction to you is confirmed, is that....news? Obviously you didn't read the post or link. I said nothing about delivering goods before confirmed. |
|
|
|
Easier fix would be to track transactions using (add,amt,time) .... no ?
There are no timestamps in bitcoin transactions. |
|
|
|
I seriously hope they've done the legal paperwork for this, the Australian government is otherwise going to stamp on them and stamp hard.
At present, however, the bank – dubbed Denariuz Bank in honour of the ancient Roman coin, according to its founder, Dr Craig Steven Wright – has yet to attain an APRA licence. http://www.bankingday.com/nl06_news_selected.php?act=2&stream=1&selkey=16114&hlc=2&hlw=Not really sure why they decided to announce this before becoming licensed. Because I am sure being Bitcoin related is going to make the bank license process so much easier right? |
|
|
|
|
It should never happen in any credible exchange. It shows a flawed matching engine.
|
|
|
|
Their software won't transfer from a wallet with unconfirmed transactions.
might be time to get that fixed? Yes and that is besides the point. It is much harder to fix 100's or 1000's of clients instead of have something that cleans the dust out before it causes problems. The real fix is probably to get the pools to throw out these absurd transactions. No pool has included these "absurd transactions" that is why it is still unconfirmed. |
|
|
|
This is a denial-of-service attack; whoever is doing this is not stealing coins, but is succeeding in preventing some transactions from confirming. It’s important to note that DoS attacks do not affect people’s bitcoin wallets or funds. If no one is gaining anything, then why are they doing this? Not everything is for direct profit. Why do hackers DDOS charities? What is the point in that? Why do people spend countless hours ruining the work of others on wikipedia with stealth edits? Why do players grief other players in online games even to the point that it starts demanding a significant amount of their time? Maybe the intent is just to cause as much chaos, bad press, and confusion in the Bitcoin space, or maybe it is just some ass who is bored and likes screwing around with people. |
|
|
|
The large number of high speed, low latency connections means we likely are probably within 1 or 2 quick hops from most miners
Isn't it far more important to be connected to the pools? Most miners don't actually receive transactions, but receive blocks from their pools. Sorry by "miner" I mean the entity that is actually constructing the block. That would be pool operators, solo miners, p2p miners, etc. If you are not constructing the block you aren't a miner, you are a "hashrate provider" who blindly hashes whatever the pool tells you to. An independent contractor if you will who sells his hashing power for a contracted rate. |
|
|
|
the positive of a bitlience:
it will kill off teenage basement dwellers from making inferior exchanges.
because it requires full ID checks on the owners, running off with the funds would be near impossible, but atleast harder then present
the negatives:
time delay of innovation
redtape bottlenecking transaction flows
the major thing that should change:
regulators should actually regulate, and not just be admin assistants for registration forms and cashiers for the fee price
The real con is that it that the end game is you end up with a handful of US companies that now face high costs but which are protected by huge barriers to entry. This mean they can increase prices and margins, and without that fear of the next startup stealing their marketshare innovation dies off. The companies which get licensed now have the govt working for them and it is in there best interest to make licensing more and more difficult until nobody else joins the "good ole boy club". Even better they also have local law enforcement forcing consumers to use their product by shutting down alternatives like peer to peer portals. The best part is they don't have to pay a penny for that local "protection" as long as the laws remain punitive and regulation costly. What NY et al forgets is, NY MT bond requirement is "only" $300,000, but there are 50 states in the country. $300K bond * 50 states = $15M in surety bonds. Usually a surety bond company will not cover the bond unless the company has tangible net work in excess of the bond amount. This means if/when all the states follow NY lead the minimum to "play" is in the $25M to $50M range. Now the surety bond company is going to want 3% to 10% a year, and each state wants $10K or so in licensing fee so you are looking at up to $2M annually in overhead before accepting a single sale. Who pays that $2M? Why you of course in the form of higher fees. But wait you take your business to that low cost startup .... which no longer exists. Ever notice how after the states decided to regulate entities like PayPal there was no PayPal competitor no matter how bad PayPal got? PayPal's fees just went up and up and up, and the service just got worse and worse and worse yet not better competitor ever came along. Did you think that was a coincidence, or maybe nobody in the country thought "hey we could make a PayPal competitor"? Maybe, just maybe it was that the "pay to play" economics of regulation priced startups right out of the game. Of course a handful of companies isn't bad right? You still got competition. I mean WU and Money Gram compete real hard to drive down the cost of sending money overseas. When you have a high barrier to entry the market becomes more profitable the less players there are. You don't have to out compete your competitors to make more money, you just have to buy them or merge with them. So if eight US startups grow big enough to afford 50 state compliance before the "pay to play" walls go up, eventually there will be 6 then 5 then 3 as the merge and acquire each other. If Bitcoin does become the next big thing, the banks and credit card companies and PayPals will end up buying or merging with the few remaining players and we all know they will do an awesome job in keeping costs down and the innovation flowing. They might not be interested in an open free market with low barriers to entry and lots of competition, but a stagnant market with high regulatory overhead and little competition, they wrote the book on that. The good news is this won't affect the rest of the world. There has been talk for decades to streamline the money transmitter licensing, and create a national license. It hasn't happened because ... nobody wants it to happen. Well at least nobody with money and power. The state regulators don't want it to happen (they would be out of a job overnight) and the Western Unions, PayPals, and GreenDots of the world surely don't want that to happen. Lower barriers to entry mean more competition, especially young innovative startups and that means lower margins. It is far cheaper to "donate" to the campaigns of the right people and ensure the high cost, patchwork of laws we current have stay on the books. Kinda like how national banks, securities exchanges, commodity dealers, and forex markets are exempt from state money transmitter requirements. Full disclosure: we don't do business in NY even prior to the hearings due to the regulatory uncertainty. Then again if we can grow big enough, fast enough, who knows we might be on the other side of those barriers. Still that doesn't mean high regulatory compliance costs are good for the consumer. If history is any guide, the barriers will make a few winners and a lot of losers. |
|
|
|
I think I've grasped this malleability issue, but is it just me or is it really a non issue with reference to the core Bitcoin protocol?, i.e. current advise is to wait for 6 confirmations to safely assume your transaction is 'bedded in' to the block chain. The transaction IDs are different due to the 'relayer' created a second one but each input and output is identical (addresses, TXID, amounts etc), therefore only one will be accepted anyway !!
so I kinda agree with those saying this is more about the way the exchanges are working as opposed to a 'bug'.
It isn't as dire as some (Gox cough cough) make it seem but it does have the potential to cause issues even for those using the reference client "as-is". Under normal conditions it might not cause a problem but one or more entity is intentionally mutating all the transactions it can and rebroadcasting the duplicates. This can cause unexpected behavior so even normal users. More info: https://bitcointalk.org/index.php?topic=460944.0 |
|
|
|
|
Not all nodes are created equal. A node running on a residential ISDN connection isn't going to compare a super nodes with 25,000 connections on low latency, high bandwidth connections.
The "attack node" can also intentionally not relay the originals. If one wanted to increase the odds they would run multiple attack nodes each with thousands or tens of thousands of connection in an attempt to "cut off" and delay the original transactions from miners. They don't have to win every race, just enough to cause some "chaos".
Our broadcast node is on a datacenter connection and has a large number of inbound connections. At least so far, no mutated version of our spends have made it into a block. The large number of high speed, low latency connections means we likely are probably within 1 or 2 quick hops from most miners making it difficult for the duplicate to win any races. Someone with a few lower speed connections where half of them are to attack nodes wouldn't have the same "luck".
|
|
|
|
Either when a peer relays the duplicate to your node, or when a peer relays a block containing the duplicate to your node. Doesn't Bitcoin-QT reject a duplicate TX that inputs are already used by another TX the node knows about? I think getting the duplicated TX in a block is the only way to create a duplicated transaction visibility. Correct me if I am wrong. You are incorrect.  The node will not RELAY it to other nodes but it records and shows all transactions related to your inputs or outputs that it becomes aware of. |
|
|
|
Best statement issued so far. The first issue is that the QT client is blissfully unaware of the fact that a transaction is a duplicate of another transaction, so it reports both txs to the user as if they are unique transactions. 1. I send a tx->Bitcoin-QT stores the TX and deducts the amount from the spendable balance (this tx can be prunned later) 2. Attacker creates a duplicate transaction 3. The malicious duplicated TX gets in a block 4. I receive the block->Bitcoin-QT stores the "new" tx and deducts the amount again -> 2 identical TX (besides the ID) in the history and the double amount deducted So Bitcoin-QT can not handle transaction malleability in general or under what circumstances do these duplicates appear in Bitcoin-QT? Does Bitcoin-QT continue to rebroadcast the original TX? The duplicates appear whenever you node learns of them. Either when a peer relays the duplicate to your node, or when a peer relays a block containing the duplicate to your node. It is important to understand you don't actually "pay twice". The balance *reported* by the client may be reduced but this is a reporting issue. It would be like if you have 100 gold bars in a vault and the auditor miscounts it as 99 or 101. The reported balance will be incorrect, but your wealth really hasn't changed but . The incorrect report can't change the amount of actual gold in the vault. If the duplicates were "hidden" from display and counting (and the balance is simply counting the value of all unspent outputs) it would display correctly. |
|
|
|
The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)
It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.
this is probably related to the current malleability attack on the bitcoin network (25% of transactions were affected today). it has nothing to do with your theft.
In addition to the above jgarzik is quoted on reddit to have said that one home PC could have done this. One home PC can screw up 25% of transactions! Hold on. Are there actually any reports of something being screwed, apart from couple of exchanges who stopped withdrawals as a precaution measure? It depends on what you mean by "screwed up". The attacker can't change the inputs or outputs or fees, however they can change the tx hash of unconfirmed txs. There were over 16,000 tx "mutated" in the last 24 hours. I am sure they weren't all withdraws from exchanges. It would appear the attackers are simply mutating in mass all transactions they are able to and broadcasting the mutated version into the network. If the mutated version of the tx is the one which gets confirmed it can have consequences for any user. https://bitcointalk.org/index.php?topic=460944.0 |
|
|
|
Do alt-coins have this problem?
alt-coins are essentially carbon copies of bitcoin with hashing algorithm and names changed. Any coin forked off the bitcoin or litecoin source would be equally affected. A truly "custom" altcoin "may" have txid which are immutable but if you don't know for sure I would assume they are also affected. |
|
|
|
|
This only affects unconfirmed transactions. Once confirmed tx ids are immutable (baring a re-org of the blockchain).
|
|
|
|
Did I understand wrong, or in the example TX.A the user spends 0.6 and not 0.4?
Oops typo. Good catch. Should be fixed now. He spends 0.6 BYC, receives 0.4 BTC back as change. |
|
|
|
|
Show Posts
