Doublespend Protection Insurance

[DeathAndTaxes]

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.

[EhVedadoOAnonimato]

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

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

[FreeTrade]

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.

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.

[jav]

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

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

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'm not sure to what you are referring here exactly, but I'm also not that familiar with the semantics of nLockTime.

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.

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.

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

[nmat]

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?

[DeathAndTaxes]

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

[EhVedadoOAnonimato]

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

The miner wouldn't follow the Bitcoin protocol, so I'm not sure I would call it 'logical'.

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.

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'm not sure to what you are referring here exactly, but I'm also not that familiar with the semantics of nLockTime.

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)

[nmat]

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.

I don't agree. Note that we are talking about conflicting transactions only. Which means that if I see 2 transactions spending the same coins from the same address, I will include the one I saw first. Seems like a pretty good strategy for me. Otherwise you can triple-spend, quadruple-spend, ...., N-spend. You just need to keep issuing transactions with higher fees than the others.

The decision strategy for non conflicting transactions can and should be based on fees.

[DeathAndTaxes]

I don't agree. Note that we are talking about conflicting transactions only. Which means that if I see 2 transactions spending the same coins from the same address, I will include the one I saw first. Seems like a pretty good strategy for me. Otherwise you can triple-spend, quadruple-spend, ...., N-spend. You just need to keep issuing transactions with higher fees than the others.

The decision strategy for non conflicting transactions can and should be based on fees.

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.

[nmat]

I don't agree. Note that we are talking about conflicting transactions only. Which means that if I see 2 transactions spending the same coins from the same address, I will include the one I saw first. Seems like a pretty good strategy for me. Otherwise you can triple-spend, quadruple-spend, ...., N-spend. You just need to keep issuing transactions with higher fees than the others.

The decision strategy for non conflicting transactions can and should be based on fees.

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

[jav]

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.

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 .

[nmat]

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

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

[DeathAndTaxes]

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.

[BitPay Business Solutions]

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 .

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.

[FreeMoney]

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.

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.

[nmat]

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.

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 

[jav]

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 .

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

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

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.

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

[FreeTrade]

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.

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.

[Etlase2]

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.

[wareen]

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

...

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.