Topic: Doublespend Protection Insurance - page 2. (Read 3722 times)

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?

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.

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.

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.