Topic: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions - page 2. (Read 11466 times)

Take a look at bitcoin magazines website.

well... duh?

Who would have thought it was a good idea to consider a transaction complete if a guy claims to have sent you funds but they haven't actually been verified as legit by ANYONE yet?

still no details? you got me curious...

Thanks! Glad to help.

We had temporarily disabled zero-confirmation deposits at bitZino, but we have now re-enabled them thanks to Mike Hearn's help. We've also added a series of additional anti-fraud checks in order to ensure our risk from a double-spend attack is minimal. As always, we only allow withdrawals back out of our site after a deposit has received multiple confirmations.

I'd really like to thank retep and Mike for their responsible disclosure and help in getting this issues resolved. We've tipped each of you 5 BTC as a way to say thanks from bitZino for helping us operate our business in a secure manner.

I think they are related, in that someone was trying to exploit (or test) it.  I mean, why else would you throw around 20 .000082 transactions at once?

I know how the relay works.  I'd like to designate these transactions as 'misbehaving', but not with a huge 24hr ban, more like 1hr.  I'll probably change it in my client later.

http://blockchain.info/ip-address/78.47.187.253

They start at 2013-01-15 10:40:03 and end at 10:58, about 400 in total, on that IP.  There was one other German node that was getting some first and also a UK node.

http://blockchain.info/address/1Ct8vwFzpWGzUyNagYUyV6NFP5cjBNkgoW       or      http://blockchain.info/address/18dzWGn9wMHA46GmBFRNgwrT3yJneKaKkA


entirely unrelated

They are not related to the vulnerability discussed in this thread.
Your bitcoin node is complaining about transactions that do not meet the minimum relay fee. So basically what it tells you is that it will not forward the transactions to other nodes in the network. These transactions may however still reach a miner and get included in a block as some nodes have other relay policies and/or are connected directly to a miner who includes any transaction regardless of fees. This is for instance the case with the first one on your list: ee1a7973ffe7f2515f6c12526b90f6255ca13bbe776e082bf0178d65663eeba9

can anyone tell me where all these 0 fee blocks spamming my logs are coming from?

i already got rid of the 2 IPs it's showing as relaying on blockchain

i guess i need to add IPs to transactions in source too =/

2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees ee1a7973ffe7f2515f6c12526b90f6255ca13bbe776e082bf0178d65663eeba9
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f0b511b75aa9aa442434a59765b98b4fd2756524fd8f9c2b11f5c888bde9958f
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f0d0a79791b5b78a022331a6389297e3eee9b9f3034c878d8c6cee2412691571
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees efb77fc35a8a6bc33e5c58b284e81be2b353874cb13838ff4c74ca51b5ba793c
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees efbdc9e1a1bf3a3c7fd3132cb777431ffa73d6fc836e1d1b70489cdccdfeac6c
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f0543537bb137ae02c5eefb93dc5d362623ba8480e1563b4937aca5013da5854
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f1c34730e5a0940c65e4a0b37cc2d1fce9ce0f1c730d3de0b5e005d0f0b4db7f
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f74b022b82f9a3e1d0f0515b05e85564bfa07ad0c9e6ace89b2ce7f2752011b6
2013-01-15T10:56:14 ERROR: CTxMemPool::accept() : not enough fees cf540360acbdcdf6afa58ee2adec991301d4ba992e2be242071087b45f05be93
2013-01-15T10:56:14 ERROR: CTxMemPool::accept() : not enough fees d3c90dbdde9eec6063571cd0236d6bfd142a373d65e25f4fa3e975ace446e524
2013-01-15T10:56:15 ERROR: CTxMemPool::accept() : not enough fees d8543699b679c45cd36705f025c54d3039a1ed2dfb63466c193b320dec5e400f
2013-01-15T10:56:15 ERROR: CTxMemPool::accept() : not enough fees d9286580caabcfecaa67904cd217207e92885ed71c37ec4377336bda0c23e207
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees ee399a5e806540e0fd1bc1d46f37a34ce74a6811550dc5f5683c2bf5028443b2
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f0115ef694c04dcbc48068755498a6d5158d316380459f096bae8f7724227176
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f026656b07abc5708d06e763583f56e3cc9124dde85e2ddad1ee724d5645c1db
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f39996eb7d6a45f9193daf58ca5f20d378c81eb0598746fd5e1cd692658709fb
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f6b3421a3b01240ed9d7744350ebf00bfd0b966e991b98d02da7b83d5596ea69
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cddf3a1683d1429b6e85da4f96039041fb42bd12e36766720db95eafd0235b7a
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ce7c0dbfa5d2a89787a62d9d1473fe60662622fa6d14d93dcfdb460e7f92b15d
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cfe8b131f8d24bcb97a32367724991667ddc077c2ae0f84b6f4b3c37a04e37b4
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d744f1bb7049f720f7913b2bc43e763aeabb069bce156262463f436e7daca37d
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dbfd6af1f0a106d3abbf110f445031e1988fe810088bcf110d2a865983d5b928
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ccebe83aa809a3f5446398f0e5449803f71b55e635143e83edcf451e25e84b20
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cd6d323d755e65efa638bc6157c89bc88b6cacc8b5181d438e36ec28bb7426a3
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ce1f54c78b8f3e0ebe04fafbd5c6d5c46aab92e4e4d13ef1a6832a223154fe18
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ce32ad556d883d3df90ac3463f94e854fe9d3e016bfcf603d1c0e00fddac2043
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cf233c426e941967014cd118cbf70c38186e3da5f17629b37863e97d676d8f8d
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cf5c391b229c6d0d59580bd894ccfcd42811ee4a5a456a6648c9bcdd7b34e9ac
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cf91339258163883e1747cf48c54590542f7acbe7f8a2aba527752398c360baa
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d0d2edd026073b8e548623be491ffd5acf57d4db454a9c041a4cb56a726308de
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d0ea334244eca1dc51ed875959a126434ec70368dd62059961a8fb704449dfe3
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d1ef53d215ce4620790af274e8374410121837db59d099b311829dd51fb21070
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d2878c33afaa8023e2695bff2c83586068cc447ddaf684705ce10bb07cf193b7
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d2d21775d847bf1f8b0819c30f4acdaa24e4b1067012de6f2109f93e1d0daac7
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d302d1a7354fdddd120c5582a14d86b5a04ca678ddb730eae665a6bc90872a32
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d56cdda9a4d2006814affe057bc4edb2d7adec39bb62faf54b8f557e93ea7870
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d5d02daa5e19f5f7c4d037d60949bc6cbd0cc52e49f80cbd1409f7973269f07e
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d71fa20523418f39c6908545401c6a85c95bf254cb00c955887bcdeabfaeaa56
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d83b16d1400497a17ed1d1a9fe1c2cce4a5f9bf55dae1832d3755b39ee7f2a77
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees db009790fe3f7416dc97b43212aaa847b151c81c24c972610aa3d36951ab47a1
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dbd43f0addf1a654ac8965a49f99f7e013dd78294a3fc66848738e8b0b90f1d9
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dc3f7b3515416ec6fec66b6c47fac7d822a03abadc0794c6de58afe21f561b2b
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dc5b696042870930d58b4351f7e088bd51a2ae3863d86946d2e7bf3f17e8571a

and so on

Yes, I'd think it is similar to the process of paying with a check at the grocery store. The store takes the signed piece of paper that promises that the bank will deliver them the money. You can still drive home really fast and withdraw all of your money from your account, rendering your earlier check useless to the store.

The same way banks deal with this kind of fraud (with verifying proof of identity when presenting the check, check-scanning machines that can talk to the bank to verify the check, and of course real legal liability for bounced checks) will definitely come to Bitcoin as well at some point. I can definitely see the case where merchants may only accept co-signed transactions from big payment providers, so they can have someone to sue when the funds don't come in.

Not really no.

I feel obligated to inform that many places use zero-confirmation in one way or another. BitPay and WalletBit is no exception.

But imagine this from a customers point of view, they do not want to stand in the store waiting 1 minute or more for a confirmation, so therefore we have to let the mobile checkout (point of sale) use 0 confirmation to display payment done notification to the customer as soon as we register the payment, even if this poses a risk for the merchant.

At the same time from the merchants point of view they will still have to wait 6 confirmations for the payment to arrive in their account and be transferred as bitcoin payment to their own wallet or as bank transfer to their local bank account. We do have issuance if a finney attack or other takes place by a "customer" out in a store using Mobile Checkout (See it here), but then again this is very unlikely to happen unless they got remote access to a setup at "home" able to do the attack.

As far as eCommerce or online shops, there really is no risk in accepting bitcoin via WalletBit or BitPay, since both system sends out a Instant Payment Notification when a defined bitcoin confirmation number have been reached.

Here it is up to the merchant if he wants quick notification of payment or very safe with no risk at all = 6 confirmations. It is as simple as setting your Notification in your account to High, Medium or Low in your WalletBit business tools, I think the same goes for BitPay in one's account.

In the end if we could iron out every attack involving zero-confirmation that would of cause be the way to go, but I can say right away that this won't happen, there will always be a loophole to find if you search enough.

Well, for sure BitPay might be useful for transfers to a bank account but I'm talking about merchants that want payment in bitcoin. Why use a middle-man when you can directly use bitcoin? Bit-Pay offers bitcoin transfers for 0.99%.

BitPay has misrepresentation in their promotional material: "With Bitpay you can eliminate the risk of Fraud" This is false.

You could say BitPay offers software solutions that do not exist elsewhere, but that is completely redundant as soon as anyone creates a open-source merchant software that suports bitcoin.

sigh... I didn't want to mention what exactly who I exploited precisely because the network is public.


You sure you understand the attack? You don't need to mine at all to pull it off. Email me if you want further clarification.


No it's not. Because clients validate all transactions in blocks against the same rules whether the tx is in the most recent block, or how ever many blocks back, the rules for confirmation are the rules for subsequent confirmation. The rules for every single node on the network are exactly the same; if they aren't you get a network split.

On the other hand there is no single set of rules that decides if a transaction will get into a block in the first place; that's up to miners and the relay-rules of the network itself and every miner and every node can, and does, have somewhat different rules they operate by. Some miners ignore satoshidice tx's, other miners ignore zero fee tx's; it's all over the place.


I'm not one of the core dev's, so maybe they think otherwise, but I'm pretty sure they'd agree that building API's to allow zero-conf transactions to be accepted "safely" sounds like a world of hurt. It's a moving target for one thing as attacks are discovered, and in addition the best ways of detecting them can't be done unless you have access to many different nodes to do network propagation measurement.

If you want to allow zero-conf tx's to be accepted safely, start a service to do so. Have staff that maintain this service, do constant risk analysis and continual threat detection, and if you have good reason to believe your counter-measures are adequate, offer insurance on transactions using the service. It's not a new idea, but there isn't anyway doing it right now as far as I know, so maybe you can make it work?

Putting this functionality in the satoshi client just leads people to believe the functionality works properly. It'll just lead to more examples of people getting defrauded, and we don't need that.


The API's already let you use Bitcoin safely: just don't accept unconfirmed transactions.


It'd be nice of you to ask the core-devs and other members of the community about when is right to release the full details. In addition, when that time comes, I think it'd also be nice to let me do it.

The limit for a single unconfirmed transaction is ~10 BTC and ~25 BTC simultaneous unconfirmed paid out at any one time. There have been two double spends in 6 months, both using methods mentioned in this thread.

You're cute and all but I was talking about CC chargeback. I'm saying the promise of BitPay to merchants is to eliminate CC chargeback risks (by using an alternative payment system obviously).
Of course you can accept BTC without BitPay, but not every internet merchant wants to know about Bitcoin, or understands it enough to feel comfortable accepting them themselves.

We all thought that this was correct.  But as I understand retep, he is trying to warn us that this is not correct, that there is a way to reliably double-spend without the help of miners.

That of course increase the risk of accepting zero-confirmation transactions, and for many people may move it from a small but acceptable risk, to a risk too great to run.

But there is of course a reason that all exchanges require at least 3 confirmations: Accepting zero-confirmation transactions will never be 100% safe.

Mike Hearn I like how you push for your "it depends" point of view. Nothing is only black and white and we will find ways to estimate risks. Accepting a transaction will be based on the blockchain, the transaction in question, confirmations, time since first seen, count of pools reporting to have seen it, the client's record, recent double-spend alerts, the weather, whatever … matched against a threshold set by the merchant.

This is circular.

Anyway, I'm not making my point clear. You're saying, in effect, that a Bitcoin payment can take completely random and arbitrary amounts of time to arrive, including never arriving.

This is the kind of statement that is both technically true and not really useful. It's like me saying email does not guarantee delivery times, or even delivery at all, so only fools would send an email about some future event.

If I said that, I'd be technically right, but in practice such a statement would be ignored because everyone knows from experience that 99.9% of the time you can send an email and it'll arrive at its destination a few seconds later.

What we have with the Bitcoin community today is people using APIs that don't make it easy to do accurate risk analysis. Of all transactions, not just unconfirmed. For instance the current best practice is to wait some number of blocks before considering a transaction "done" but the actual hardware cost of mounting an attack doesn't depend on the number of blocks, it depends on how difficult those blocks were to create (yes, I'm oversimplifying a bit). So really sites should think about confidence in terms of gigahashes of work done, but in practice no sites actually do. I've tried to support this kind of approach in bitcoinj, where you can query any wallet transaction to find out how much work has been done on top of it, but I never had time to really push this idea.

So it's up to us, the community, to build APIs that ensure users can use Bitcoin safely.

In your case, as caveden points out, detecting a massive chain of unconfirmed transactions that has low fees is easily done using software. There are no cases where wallets will build such things today, so a quick fix is just to forbid it. More generally, estimating confirmation time based on history of observed behaviour can be done by any full node and over time, when provided with the tools, merchants will use them to optimize their risk and user experiences.

From a site that swaps unconfirmed coins for confirmed coins. That is not at all the majority of merchants.


Somebody doing currency exchange for unconfirmed transactions with no delay at all has always been vulnerable( to Finney attacks). And doing it for PayPal with untrusted partners has been known to be risky for years.

I don't understand why you assert that the attacker doesn't need a bunch of machines. They still need to mine.


All bitcoin transactions have risks, including ones that have been included in blocks. There are lots of applications that want ~instant delivery and can provide it with little or no fraud risks, if they have an understanding of those risks. As demonstrated by the number of sites that do it.

Like I said, I'll post the full details in a week or two. As you note yourself, not every site can be contacted manually. Besides anyone who wants to can figure out what you're talking about just by looking at recent changes to various client apps anyway.

Come on, it's safer than that. To pull off a double-spend, you need some technical expertise, and perhaps the help of a miner. While Mr Everybody can easily break a promise, I wouldn't say he can make a double-spend.

But yeah, you're right that if you have no way to go after your customer or interrupt the service, you probably shouldn't be accepting unconfirmed transactions.


Software can/should be clever enough to detect such a thing.

Mike isn't saying that 0 conf is safe. He's saying that with a small fix it is as safe as (most people thought it was) it was before which may be not safe at all or totally fine depending on what you are doing.