Doublespend Protection Insurance

[FreeTrade]

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?

[1713999897]

1713999897

[1713999897]

1713999897

[1713999897]

1713999897

[1713999897]

1713999897

[dogisland]

The BDPIC concludes there is no doublespend attack in progress and within seconds sends an equal amount to the retailer(minus small fee).

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.

[sadpandatech]

The BDPIC concludes there is no doublespend attack in progress and within seconds sends an equal amount to the retailer(minus small fee).

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....

[finway]

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

[wareen]

The BDPIC concludes there is no doublespend attack in progress and within seconds sends an equal amount to the retailer(minus small fee).

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.

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. 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.

[FreeTrade]

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

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.

[finway]

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.

[FreeTrade]

Double spend 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.

[wareen]

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.

Have a look at this calculation from Satoshi and the Transaction Radar.

[Meni Rosenfeld]

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.

[Steve]

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?

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.

[FreeTrade]

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.

[Steve]

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.

[EhVedadoOAnonimato]

Have a look at this calculation from Satoshi

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.

[jav]

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.

[EhVedadoOAnonimato]

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.

[EhVedadoOAnonimato]

With this setup, I can now attempt to double-spend until I succeed.

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

[jav]

Have a look at this calculation from Satoshi

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.

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).

[DeathAndTaxes]

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.

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.

[nmat]

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

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.