Bitcoin Forum

Here's an idea I wanted to put out there. Interested if anyone can point out flaws or wants to run with it.

So a problem with Bitcoin in face-to-face/retail transactions that people are worried about is that one might have to wait for confirmation(s). As I understand it block confirmations arrive on average every 10 minutes but may take longer if you're unlucky - so you might be waiting 30 minutes (or even longer) for the first confirmation if you were unlucky.

Now let's say I found the 'Bitcoin Doublespend Protection Insurance Corporation' (BDPIC) to help protect against a double spend.

Here's how it works:
A customer buys a cup of coffee in your store. Retailer generates invoice. Customer sends payment to BDPIC using the retailer's BDPIC receiving address. The BDPIC concludes there is no doublespend attack in progress and within seconds sends an equal amount to the retailer(minus small fee). Retailer doesn't need to wait for confirmation as trusts a BDPIC 0/Unconfirmed transaction.

In the event of a doublespend attack, BDPIC eats loss.

So, what to do you think? License to print money?

How would you know that a double spend was in progress or not ?

I think a double spend has a potential window of 10 minutes ?

i.e. I buy an item say 20BTC, I walk out of the shop and I create another transaction signing the same outputs and send it.

   Exactly, and BDPIC is willing to take that risk for a small fee....

This mechanism has a new name now , called "Green Address".
Try Instawallet.com or Mtgox.com to feel it.

This problem has been much discussed: if you only delay the sending of your second (conflicting) transaction by one second, it will have a very low chance of being distributed to the Bitcoin nodes. BDPIC could check if the transaction is known to a large part of the network (or just the main mining nodes) in order to minimize the chance of a loss.
The big risk factor for the BDPIC however comes from the Finney attack (https://en.bitcoin.it/wiki/Weaknesses#The_.22Finney.22_attack). Since it is difficult to pull off, it won't be a problem for transactions of low value though.

The main issue I see is that of trusting the BDPIC and the additional fee/hassle for the merchant. If the merchant uses some sort of payment service provider like bit-pay anyway, then this would be a non-issue. If he doesn't, then waiting/checking the network for possible double-spends could also be done by the merchant himself.

I remember somebody suggesting that such a listening-period could even be included as a feature in the standard client at some point.

Thanks - the coffee seller would need to have a Green Address for BDPIC.

However, I'm not sure if you missed the main point - with BDPIC the customer wouldn't need to transfer funds to Instawallet/MtGox in advance. Customer/Vendor wouldn't need to agree on the trusted party in advance.

Since bitcoin is decentralized,
"double spending" happens on the other side of the bitcoin network 
it can't be detected in a short time
--let's say that.

Agreed - BDPIC couldn't be sure there was no attack underway. It would need to charge a fee in line with amount it was losing to cover those losses. I'd imagine that would be a very small fee - of the order of a tenth of one percent.

BDPIC might have a limit on the transaction size it was prepared to insure.

A centralized organization dedicated to identifying double spend attacks should have a better chance of identifying them than retailers or individuals though. I think its simpler for individuals and retailers if they don't have to worry about these kind of technically complex risks.

Have a look at this calculation from Satoshi (https://bitcointalk.org/index.php?topic=423.msg3819#msg3819) and the Transaction Radar (http://transactionradar.com).

The idea isn't new and if there's a market for it it will happen. I think this will be obviated by split-key wallets as discussed for example in this thread (https://bitcointalk.org/index.php?topic=49689.0).

This is my preferred solution for bit-pay.  We'll just guarantee transactions against double spend up to some value.  We need to implement the network monitoring aspect such that we don't immediately clear transactions that appear risky (i.e. only a small percentage of nodes are reporting the transaction) and we need to do some kind of risk modeling to decide on an appropriate value under which we'll provide this guarantee.  We had discussed the use of green addresses as well (and discussed a lot of those details with Jan even before he released it)…we may support green addresses as well, but the guarantee (with appropriate risk modeling and network monitoring) seems like a more general solution for smaller value transactions.

Cool. I guess Bit-pay is the closest thing in the market to it so far, so I'd see it as a natural fit for you. I guess it is a question of whether you guys offer a guarantee, and transfer the funds instantly. Currently I guess people need to trust from month-to-month, rather than for transaction-to-transaction.

The trust is only necessary day-to-day (we currently payout BTC and USD daily)…and for BTC, we will eventually go to an hourly payout.

Satoshi did not take transactions fees into account on that message. A double-spend attempt could carry a higher transaction fee in order to make miners give precedence to it.

A couple of months ago I have considered for a while to start something like the described BDPIC. In my opinion, it is only possible if you know the involved merchants very well. I did not want to have to whitelist merchants, so I decided not to attempt it.

The problem is this: Let's assume everyone can sign up for your BDPIC. If I'm an attacker, I set up a merchant account and can now pay myself through BDPIC any amount I want at a small fee. If there are limits in place, I just open multiple merchant accounts and bundle them.

With this setup, I can now attempt to double-spend until I succeed. The only conditions is, that the total amount of fees I have to pay is less than the payoff for a single successful double-spend. This will most likely be the case, unless you charge huge fees. Let's assume you charge 2% on all transactions (already on the expensive side, I would argue), then I as an attacker can try 50 times before it becomes unprofitable. I described one attack that can be performed here: http://www.reddit.com/r/Bitcoin/comments/kmo2l/suggestion_bitcoin_confirmation_honeypot/c2lhbv1 . The attack described there can not be detected by monitoring the network and if you have 50 tries you need to have a little bit more than 2% of total hashing power to make it work.

The only way to prevent this is to make sure, that all your merchants are legit and even among the legit merchants you need to forbid things that allow attackers to try multiple times. So for example an online casino, where you can withdraw funds that you have deposited through BDPIC would not be acceptable, as it would enable this attack.

If BDPIC doesn't have a way to identify (and punish?) the sender of a double-spend, one could steal from them as much as one wants. You just need to collude with some merchants - or be the "merchant" yourself.

I suppose there are ways to mitigate such risk, forcing merchants that deal with BDPIC to require clients identification, banning merchants with lots of double-spends etc. Anyway, what I want to say is that it's not as simple as calculating an adequate service fee based on prior double-spending statistics. There are opportunities of abusing such system, you must be ready for it.

You'll succeed in the vast majority of attempts if you just add a higher transaction fee to the double-spend.

That is not correct, transactions fees are irrelevant for this situation. If a Bitcoin node (which includes miners) receives two unconfirmed transactions, that are in conflict with each other, it will only accept the one it received first and drop the second one (which means it will also not be relayed). It does not matter whether the second transaction has more transaction fees. The node will only 'change its mind' if the conflicting transaction ends up in a block (which requires a miner which, for some reason, saw the second transaction first or a malicious miner).

Well you can say that but you would be wrong.

Transactions don't take very long to propogate the network.

You perfectly time a double spend.  I wait 60 seconds before handing over the goods.  If my node sees both transactions in <60 seconds then you failed.  Even worse I keep your money.  The risk is very low except for very high value items to make the attack worthwhile.

Despite risk being low one could make it even lower with a network of "super nodes" that are geogrpahically distributed and have thousands of tens of thousands of connections to peers.  No matter where you place the two double spends it likely is no more than 1 to 2 "hops" from a "super node".  Each super nodes rapidly shares all transactions with other super nodes.  Merchants could subscribe to "super node" service and have a high level of confidence that if no double spend has been detected within say 20 seconds that it is highly improbable that a double spend has occured.

Transaction fees have nothing to do with it. The only way you will be able to pull this off is with a Finney attack, like jav described, but you will need a decent amount of computational power. 2% of the network is 100GHash/second.

Insurance is unlikely simply because it is difficult to detect collusion between merchant and attacker (or the "merchant" is the attacker).

Instead I think a service of providing highspeed low latency transaction announcement is more viable business.  Merchants subscribe to a service for say a monthly fee.  They are then linked into a high speed network with massive number of peer connections.  This ensures that no matter where on the network the two half of the double spend originate the merchant would have a high confidence of "seeing" both of them in a reasonble amount of time, say 60 seconds.

Remember to pull off a "non-finney" double spend you must
a) origination transactions A & B
b) wait for transaction A to be seen by merchant A
c) wait for transaction B to be seen by merchant B
d) complete both transactions before merchant A "sees" transaction B or merchant B "sees" transaction A.

With a low latency network that has so many connections to peers that any origination is at most 1 or 2 hops from the network it is unlikely that you succeed with D.  Even better for the merchants since funds are irreversable every failed double spend nets them (on average) 50% of the amount.

I guarantee if someone tries to double spend me and fails they aren't getting their BTC back.

It's not a "malicious miner", it's just a logical miner. Miners should give priority to the transactions which pay more.

But yeah, if in the current implementation most nodes do not relay the double-spend, then the attacker would have to rely only on those logical miners, sending the second transaction directly to them, and hoping that they find the block instead of the miners which implement this first-seen-wins priority scheme. If such miners exist, of course... if every pool operator is implementing this priority rule, then the attack becomes harder. But not impossible, as you explain in your message above.

By the way, according to what you're saying, there's no way to redeem a transaction with a future nLockTime then? Or when nLockTime is present the first-seen-win rule is not applied? If it's not possible to redeem such transactions, they become rather useless...

I don't think so - BDPIC would notice a lot of double spend attempts originating from a single merchant and likely refuse to process for that merchant - or have a sliding scale of cost depending on the level of risk of the merchant.

The miner wouldn't follow the Bitcoin protocol, so I'm not sure I would call it 'logical'. Bitcoin can also be seen as a timestamp network (the paper specifically mentions the term "distributed timestamp server"). It is an attempt at establishing a chronological order between transactions in a distributed manner. So miners need to include the transaction they received first, if they want to follow the Bitcoin protocol. If they don't do that, I would call them malicious. (This only applies to transactions that are in conflicting with each other.)


I'm not sure to what you are referring here exactly, but I'm also not that familiar with the semantics of nLockTime.


Attempts of the attack I linked to can not be detected, so you would only notice it once its too late.

BDPIC could require 1 block confirmations for merchants with detected double-spend attempts...

Your attack is actually the only potential problem. If BDPIC monitors the network correctly, it is almost impossible to double-spend without a pre-mined block. Which makes me wonder (and this is probably a dumb question) if it isn't possible to detect the attack and reject your pre-mined block once you release it. Could the network do this?

No.

The transaction and block are valid. The only potential safeguard is hashing power and that just makes it more difficult but not impossible.  However one has to consider the value of the loss.  All forms of trade (cash, check, credit cards, gold, barter) involve fraud.  It will never be eliminated not in Bitcoin, not anywhere.

However the amount of fraud is what matters.  To have the ability to generate any more than a token amount of revenue in attacks requries a huge amount of hashing power and a large transaction.

So yeah if someone wants to perform a finney attack to get something that costs small number of BTC it is likely is impossible to avoid.  However the increased gain on their capital expense (hashing hardware) is not significant and that likely will keep most miners honest.  Large transaction should require 1+ confirmations.

I don't really seel much value in insurance because small transactions are unlikely to be double-spent and large transactions are likely uninsurable against a Finney attack.  It is precisely these large transactions which would be the target of a Finney attack (to justify the capital cost required).

Why? His block would be perfectly valid, he would not be violating any protocol rule. Transaction priority should not and probably cannot be defined by the protocol - each miner is free to make its own policy. We should not expect miners to adopt a policy that rejects a transaction for another that pay less fees, at least not when transaction fees become a substantial part of mining reward.


Apparently there's a feature in the bitcoin protocol that allows you to send a transaction with a lock which forbids it from being added to any block before a specified point in time. The main point of this feature is to be able to cancel the transaction before such point in time, if needed. Such feature is frequently mentioned on the heritage use case. (You could send a transaction to your heirs with a nLockTime and if the date approaches and you're still alive, or if you just want to spend it yourself instead of leaving it as heritage, you cancel the transaction)

There is no method of enforcing a miner to include or not include a particular transaction.  The network specifically allows a miner to include whatever transactions he wishes to in a block.

I think you may be confusing nodes with miners.  Nodes will only relay the first transaction and ignore the rest.  There is no financial incentive to do otherwise.

Why would it matter which transaction a miner includes in the block?  If this is a 0-confirm attack then the attacker already has the merchandise.  He doesn't care which (if any) transaction ever gets included in any block.

Yeah... You're right. My post doesn't make sense :P

Online gambling is an example where paying with 0-confirmation transactions would be nice (get started playing right away) and double-spend insurance/protection is necessary. Otherwise an attacker deposits, plays and double-spends in case they lost.

Also: If you don't do _any_ kind of double spend protection (i.e. don't monitor the network for conflicting transactions) it starts to become an even bigger problem. So if a vending machine operator wants to accept 0-confirmation transactions today, they would definitely need to monitor the Bitcoin network for double-spends. Not something your typical vending machine operator has the technical skills to program and set up, so out-sourcing this to a service provider in the form of an insurance definitely makes sense in my opinion.

If you just integrate the standard Bitcoin client into your vending machine, you would for example be open to a much simpler attack like this one: http://www.reddit.com/r/Bitcoin/comments/kmo2l/suggestion_bitcoin_confirmation_honeypot/c2lhfs1 .

I agree with you, but, theoretically, the miners could see that this was a double spend attempt and mine the next block based not on your block, but on the previous one. This would create a fork and invalidate your chain (unless of course you have 51%). But allowing something like this would probably have lots of other implications...

How would miners know.  No miner can be 100% certain they see all transactions from all nodes in the network at all time.  You may suspect it is true but you can't definitively know.  Worse if some miners accept the block and some don't then you have effectively reduced the hashing power on the longest chain.

Would be a good precursor to a 51% attack to break the "cohension" of the good miners by creating multiple "double spend blocks" and fragment the network hashing power into multiple sub-chains.

Given the limitations of bitcoin being a peer to peer network where no node can have 100% certainty that they have seen every transaction there is no solution to a Finney attack other than to required 1-confirm.

Jan do you think someone will really spend all this time and expense for a $1 soda from a vending machine? 

But there's no need for every vending machine to run the bitcoin client.  They would just link up to a server with enough connections to monitor the network.  So the mobile phone is paying bitcoins to the server, not to the vending machine.

I'm almost positive this isn't how it works. There are orphaned blocks and short splits all the time. If half the network is working on 160543A and half on 160543B this doesn't make it easier for an attacker to rewrite 160543. Someone who knows this stuff please confirm.

Thanks for the explanation. Now that I know the answer to all my geek questions, I will just sit back and agree with Steve: it's too much work for a pizza  8)

There isn't really any cost associated with that attack. As to time: I'm pretty sure someone would do it. You have a vending machine sitting somewhere and the prize of tricking it is a free coke. How can any decent hacker turn down this challenge? Someone would write a tool to perform the attack - not for the money, but because of the challenge. Then the tool is out there and the next thing you know is that people start using the tool all the time to get free soda from your machines. (I'm talking about a tool for the simple attack here - such a tool could be written, which would basically just need the IP address of the vending machine and the rest would be automatic.)


That's true - but that's what I said, that you need at least basic double spend protection and can't just completely ignore the problem. (Because you could also set up that central vending machine server in a naive way which still opens you up to the attack.)

Sounds good for a USD payout - if I were a retailer, I'd probably go with that option and a weekly/monthly payment would be fine.  Indeed if you're offering BTC conversion to USD at the market rate at the time of the transaction, together with a guarantee of non-repudiation of transactions then I think you've got all possible worries of a retailer covered - (chargebacks, delays and BTC volatility). If I were a small retailer, I'd be much happier paying a small percentage than trying to figure out that stuff for myself.

Worrying about double spending is such a waste of time. Ooh someone might be able to pull it off once every 10 minutes assuming they're lucky enough to get a block. The odds of this realistically being attempted go down as the network hash power goes up. So if bitcoin is popular, it isn't much of an issue. But if bitcoin is popular, it might garner the interest of malicious agencies who can:

* Prevent some or all transactions from gaining any confirmations
* Prevent some or all other miners from mining any valid blocks

No one is going to double spend on a coffee or to buy a coke from a vending machine. Even if they do, it isn't as if it is a constant threat. Any larger purchases can always wait until 6 confirmations or whatever seems prudent. The much bigger issue is being able to mess with EVERYBODY as in the above two scenarios which are often not brought up in discussion around here.

Maybe that's because they are _much_ harder to pull off?

Besides, if any such "agency" would really want to bring down Bitcoin, they could do so much more easily by influencing legislation, attacking the exchanges, spreading more FUD,...

I find it funny to assume that anyone with the power to quickly build a 30.000 GPU cluster just for the purpose of messing with Bitcoin, doesn't have any better, cheaper and slightly more subtle means of severely harming Bitcoin.

They aren't _much_ harder to pull off with pools being the way they are. Double spends aren't exactly easy as cake to pull off, and they will generally only affect a small number of people. Making an insurance company to reduce the threat is laughable. Merchants could merely add a small fee to their products to cover any potential loss.

Legislation is very expensive, probably more expensive than designing a big computer to compute SHA2 hashes. Not to mention there is no one-world government yet. Attacking the exchanges doesn't stop the network, especially if it's ubiquitous.

Having 2% of the network would be in excess of 100 Ghash currently see http://bitcoin.sipa.be/).  That kind of hardware will set you back by at least $50,000 (if not closer to $100k).  If you're talking about relatively small value transactions, you will need to pull off a lot of double spends to make it worthwhile.  I think if you employed counter measures once a double spend is successfully executed, you could easily undermine the economics of such an attack.  For in person transactions, where instant confirmation is most needed, the economics of such an attack are already not viable.  For online transactions, counter measures could be as simple as resorting to full confirmations in the event of a successful double spend.

(btw, some on this thread have mentioned listening for conflicting transactions…but that's not actually how it would work…you would receive your transaction through the network and then you listen for additional nodes reporting that same transaction…what you want is a high percentage of nodes reporting your transaction…if they report your transaction, it means that they consider it to be valid (and would have discarded any conflicting transaction)…you'll want to place more weight on mining nodes if you can determine them since you'll want to see that there are miners working on putting your transaction into a block)

Influencing legislation doesn't have to be very expensive: incriminating someone with selling cp or terroristic equipment for Bitcoins will quickly get you the negative publicity needed to pave the way for passing a bill outlawing anonymous cryptocurrencies. With some connections to politics and media, this should not be too difficult.

You are right in that attacking the exchanges won't stop the network, but it could cripple Bitcoin nevertheless (price would plummet, hashrate and confidence would follow soon). It would be more or less the same scenario as if some major jurisdiction was to outlaw Bitcoin.

Doublepspend insurance is not needed yet.  Either the item is too cheap and the attacker could get a larger reward by mining with his hardware, or the item is probably not going to be delivered before the doublespend is detected.

Maybe in the future someone will sell a database or software for BTC that is expensive, and deliver it too soon but I don't know of any serious attack possibility that would be financially worthwhile.

Maybe. It's just nice right now to have a good response to the argument - "Oh Bitcoin could never be used for retail, the transaction would take too long, or the retailer would risk getting stung by doublespends." This as a problem that is solved in theory.