Double Spending for BTC businesses - Best practice Solutions ?

[RockHound]

What's the fastest/secure/best practice for new BTC enterprises?

Hi,

I am currently developing a BTC online service which ideally will trigger our implementation upon receiving 0-1st Confirmation.

Interviewed several software engineers this week, one engineer brought up a point regarding Double Spending - Is there a secure way to validate a BTC transfer without waiting for xConfirmations?

Eg. Does using the BIP 70 protocol solve this?

Any suggestions from the Bitcointalk Braintrust would be greatly appreciated.

RH






https://bitcointalk.org/index.php?topic=622376.0 Sorry if I've posted in wrong section.

[1714773625]

1714773625

[1714773625]

1714773625

[1714773625]

1714773625

[Ratters]

Hi,

From what I know on this (very little) by the first confirm the opportunity for double spending has already passed.

[DeathAndTaxes]

No BIP 70 doesn't solve the problem of double spending.  That is the point of confirmations.   How many confirmations you should wait for will depend on exactly what you are selling, what it is worth, how likely someone is to try and steal it.

Even 1 confirmation will require significant computing power at significant cost to reverse.  If that is sufficient for your service will depend on what the service is and how valuable a reversal would be.   Is 1-confirm sufficient for selling a digital game service which you can revoke later if needed? Yes and 0 confirms is probably good enough as well.   Is 1-confirm sufficient for a service that converts BTC to USD and instantly sends it to any bank in the world? No, not even close.

[RockHound]

Hi,

From what i know on this (very little) by the first confirm the opertunity for double spending has already passed.

I see, thanks mate - wondering if Double Spending problem can be negated with 0 Confirmations?

[Ratters]

If your sale is worth less than the current block reward current thinking is that it would not be worth the effort to maliciously double spend. An accidental double spend is another matter though, although you’d have to be bloody quick!

I've read up on this today for another project, ill see if I can dig it up for you.

[jonald_fyookball]

BIP70 is talking about:

Resistance from man-in-the-middle attacks that replace a merchant's bitcoin address with an attacker's address before a transaction is authorized with a hardware wallet

(This is not the same as a double spend.)

How would 0 confirmations negate the double spending problem?  
Its just the opposite -- the more confirmations you have, the
harder it is to double spend.  

The only way I can see around that is using a trusted third party
like Coinbase that can provide instant confirmation.

However, in most point-of-sale applications, you wouldn't need
confirmations, because most people aren't going to double spend.

Just like you could write a bad check, or shoplift, you can try
to cheat the system (but most people don't for fear of going to jail).

In a more expensive transaction, you wait for confirmations just
like you would wait for a check to clear.

[RockHound]

No BIP 70 doesn't solve the problem of double spending.  That is the point of confirmations.   How many confirmations you should wait for will depend on exactly what you are selling, what it is worth, how likely someone is to try and steal it.

Even 1 confirmation is relatively difficulty to reverse and will require significant computing power at significant cost.  If that is sufficient for your service will depend on what the service is.  If 1 confirmation good enough for selling a digital game service which you can revoke later if needed? Yeah and 0 confirms is probably good enough as well.   If 1 confirm good enough for a service which sends a bank wire of up to $10M instantly to any bank in the world?  No, not even close.

Nice One D&T!

Our model is based on rapid service to our end users, so efficient validation is a must!

We may write some Permissions/Limits for larger transactions.

[DeathAndTaxes]

I see, thanks mate - wondering if Double Spending problem can be negated with 0 Confirmations?

No.  If it could then we wouldn't need confirmations, blocks, mining, and the massive expenditure of hardware and energy that goes along with it.   "Mining" is forcing a consensus on the network as to the ordering of transactions.  You "may" be able to accept 0-confirm txs with no or an acceptable rate of fraud but everything will depend on what you are selling, how much a theft is worth, if it is repeatable, how convertable would it be for a thief, how traceable, etc.

Nobody can say "in 100% of scenarios you must use X confirmations".  Well they can say it but they would be wrong.

To give you an example at one time Tangible Cryptography sold mobile phone reloads for Bitcoins.  For phone codes (which could be used to recharge any phone) we required 1 confirmation (sometimes 2 if we experienced a large amount of volume).  For direct reloads (where the user supplies a phone number and the time/value is directly added to their account) we didn't require any confirmations*.  Since the purchase was linked to a phone account the risk of a double spend was reduced and the repeatability of the attack was also reduced.  For BitSimple (a direct broker/dealer in Bitcoins) we require 3 confirmations as some of the withdraw methods as irreversible.

It all comes down to risk management.



*It is important to understand how you can detect double spends on the network using multiple nodes (listening nodes).  This doesn't guarantee a double spend (the thief could have a secret deal with one or more miners) but it does ensure you will not lose a "race" which ensures honest miners won't be working against you simply because they encountered the double spend first.  You should not accept 0-confirm transactions unless you understand the risks involved.  This means understanding how tx are relayed, what can prevent tx from being relayed, how an attacker could work directly with a miner, how a "Finney Attack" works and why it can't be detected. 

[RockHound]

BIP70 is talking about:

Resistance from man-in-the-middle attacks that replace a merchant's bitcoin address with an attacker's address before a transaction is authorized with a hardware wallet

(This is not the same as a double spend.)

How would 0 confirmations negate the double spending problem?  
Its just the opposite -- the more confirmations you have, the
harder it is to double spend.  

The only way I can see around that is using a trusted third party
like Coinbase that can provide instant confirmation.

However, in most point-of-sale applications, you wouldn't need
confirmations, because most people aren't going to double spend.

Just like you could write a bad check, or shoplift, you can try
to cheat the system (but most people don't for fear of going to jail).

In a more expensive transaction, you wait for confirmations just
like you would wait for a check to clear.

Cheers Jonald;

- No checking software available?

- Wonder how Coinbase instantly validates?

- Don't really want to create a bias implementing "Limits" / We want to be just as rapid for larger volume transactions. 

[RockHound]

I see, thanks mate - wondering if Double Spending problem can be negated with 0 Confirmations?

No.  If it could then we wouldn't need confirmations, blocks, mining, and the massive expenditure of hardware and energy that goes along with it.   "Mining" is forcing a consensus on the network as to the ordering of transactions.  You "may" be able to accept 0-confirm txs with no or an acceptable rate of fraud but everything will depend on what you are selling, how much a theft is worth, if it is repeatable, how convertable would it be for a thief, how traceable, etc.

Nobody can say "in 100% of scenarios you must use X confirmations".  Well they can say it but they would be wrong.

Clear and Concise, cheers man!

[odolvlobo]

Hi,

From what i know on this (very little) by the first confirm the opertunity for double spending has already passed.

I see, thanks mate - wondering if Double Spending problem can be negated with 0 Confirmations?

It is relatively easy to successfully double-spend with 0 confirmations. If a customer double-spends, then there is roughly a 50% chance that the merchant will see the legitimate transaction, and 50% chance that it will not be added to the block chain.

There are ways for both the merchant and the scammer to increase their odds. For example, a merchant with a better connection to the network is more likely to see both transactions and detect the attempted double-spend. The scammer can omit the transaction fee on the merchant's transaction, reducing the likelihood that it will be the one that is confirmed.

[RockHound]

Hi,

From what i know on this (very little) by the first confirm the opertunity for double spending has already passed.

I see, thanks mate - wondering if Double Spending problem can be negated with 0 Confirmations?

It is relatively easy to successfully double-spend with 0 confirmations. If a customer double-spends, then there is roughly a 50% chance that the merchant will see his transaction, and 50% chance that it will not be added to the block chain.

There are ways for both the merchant and the scammer to increase their odds. For example, a merchant with a better connection to the network is more likely to see both transactions and detect the attempted double-spend. The scammer can omit the transaction fee on the merchant's transaction, reducing the likelihood that it will be the one that is confirmed.

This was my main concern - Our potential engineer said he's tested and was easy to do.

I can't believe there is no service or software available to check duplicate(/multiple) transaction requests. Obviously, our system would then invalidate the transaction.

[DeathAndTaxes]

I can't believe there is no service or software available to check duplicate(/multiple) transaction requests. Obviously, our system would then invalidate the transaction.

It is probably good there is no such service.  It would be rather trivial to make a service like that however double spend detection alone can't guarantee a tx won't be double spent (technically neither can confirmations).  Double spend detection can provide a reasonable assurance that your transaction has "won the race" (propagated the network) and ensure that no honest miner is working against you.  However a Finney attack can't be detected until after it has occurred by monitoring the network.  Likewise a thief could defraud you by working directly with a malicious pool.  There is no requirement that transactions have to be sent over the network (and no way to enforce that requirement if there was).  So a thief conspiring with a miner/pool doesn't have to broadcast the double spend, and this means there is nothing to detect.  Your first indication would be when the dishonest miner broadcasts a block with the double spend and your 0-confirm payment becomes invalid.

All of these factors depend heavily on what you are selling, how anonymous it is, how convertable it is to a thief, how much it is worth, etc.  There is no magic or simple "oh if you do this you will be safe".  It would not be difficult for a competent developer to code up a detection network but it should be part of a larger risk analysis.  Some services will simply always need confirmations or a way to secure alternate payment.  One example of this would be a grocery store.  Grocery store already accepts credit cards (and the associated risk).  If the store wanted to accept 0-confirm transactions for fast checkout line payment they could have users register a credit card and sign an agreement that if their bitcoin payment doesn't confirm the backup card will be charged.  The store is not taking any more risk.  If a thief has a stolen credit card and willingness to use it in person they would simply pay with the stolen credit card rather than try to perform a double spend.  So there are a lot of potential solutions but it will be very business specific.  What works for one business will not necessarily work for another.  Having a cookie cutter solution almost guarantees that naive businesses will be defrauded.

[edd]

- No checking software available?

There is, it's called the Bitcoin protocol.

Seriously, this is the purpose of mining - to relay and validate transactions.

- Wonder how Coinbase instantly validates?

Same way everyone else does.

- Don't really want to create a bias implementing "Limits" / We want to be just as rapid for larger volume transactions. 

You are limited by the network. Is one confirmation really too long to wait?

[jonald_fyookball]

- Wonder how Coinbase instantly validates?
 

Because you would be paying with your coinbase account, so they are really controlling
the funds.  They are the trusted third party.   This is another LAYER.  Essentially, you are telling
coinbase to pay them, and the merchant is assuming coinbase won't double spend.  Hope that
makes sense.   

[RockHound]

I see, thanks mate - wondering if Double Spending problem can be negated with 0 Confirmations?

No.  If it could then we wouldn't need confirmations, blocks, mining, and the massive expenditure of hardware and energy that goes along with it.   "Mining" is forcing a consensus on the network as to the ordering of transactions.  You "may" be able to accept 0-confirm txs with no or an acceptable rate of fraud but everything will depend on what you are selling, how much a theft is worth, if it is repeatable, how convertable would it be for a thief, how traceable, etc.

Nobody can say "in 100% of scenarios you must use X confirmations".  Well they can say it but they would be wrong.

To give you an example at one time Tangible Cryptography sold mobile phone reloads for Bitcoins.  For phone codes (which could be used to recharge any phone) we required 1 confirmation (sometimes 2 if we experienced a large amount of volume).  For direct reloads (where the user supplies a phone number and the time/value is directly added to their account) we didn't require any confirmations*.  Since the purchase was linked to a phone account the risk of a double spend was reduced and the repeatability of the attack was also reduced.  For BitSimple (a direct broker/dealer in Bitcoins) we require 3 confirmations as some of the withdraw methods as irreversible.

It all comes down to risk management.



*It is important to understand how you can detect double spends on the network using multiple nodes (listening nodes).  This doesn't guarantee a double spend (the thief could have a secret deal with one or more miners) but it does ensure you will not lose a "race" which ensures honest miners won't be working against you simply because they encountered the double spend first.  You should not accept 0-confirm transactions unless you understand the risks involved.  This means understanding how tx are relayed, what can prevent tx from being relayed, how an attacker could work directly with a miner, how a "Finney Attack" works and why it can't be detected. 

Excellent! Will bring to our Dev's attention

[RockHound]

I can't believe there is no service or software available to check duplicate(/multiple) transaction requests. Obviously, our system would then invalidate the transaction.

It is probably good there is no such service.  It would be rather trivial to make a service like that however double spend detection alone can't guarantee a tx won't be double spent (technically neither can confirmations).  Double spend detection can provide a reasonable assurance that your transaction has "won the race" (propagated the network) and ensure that no honest miner is working against you.  However a Finney attack can't be detected until after it has occurred by monitoring the network.  Likewise a thief could defraud you by working directly with a malicious pool.  There is no requirement that transactions have to be sent over the network (and no way to enforce that requirement if there was).  So a thief conspiring with a miner/pool doesn't have to broadcast the double spend, and this means there is nothing to detect.  Your first indication would be when the dishonest miner broadcasts a block with the double spend and your 0-confirm payment becomes invalid.

All of these factors depend heavily on what you are selling, how anonymous it is, how convertable it is to a thief, how much it is worth, etc.  There is no magic or simple "oh if you do this you will be safe".  It would not be difficult for a competent developer to code up a detection network but it should be part of a larger risk analysis.  Some services will simply always need confirmations or a way to secure alternate payment.  One example of this would be a grocery store.  Grocery store already accepts credit cards (and the associated risk).  If the store wanted to accept 0-confirm transactions for fast checkout line payment they could have users register a credit card and sign an agreement that if their bitcoin payment doesn't confirm the backup card will be charged.  The store is not taking any more risk.  If a thief has a stolen credit card and willingness to use it in person they would simply pay with the stolen credit card rather than try to perform a double spend.  So there are a lot of potential solutions but it will be very business specific.  What works for one business will not necessarily work for another.  Having a cookie cutter solution almost guarantees that naive businesses will be defrauded.

D&T appreciate your valuable feedback! PM'ed

[RockHound]

- Wonder how Coinbase instantly validates?
 

Because you would be paying with your coinbase account, so they are really controlling
the funds.  They are the trusted third party.   This is another LAYER.  Essentially, you are telling
coinbase to pay them, and the merchant is assuming coinbase won't double spend.  Hope that
makes sense.   

I see, guess their model is more akin to a brokerage. Handling FIAT, I would assume that have adequate anti-fraud, charge-back assessments, insurance with there affiliate banking partner. Actually does anyone know who that is?

Well explained - Thanks btw

[RockHound]

- No checking software available?

There is, it's called the Bitcoin protocol.

Seriously, this is the purpose of mining - to relay and validate transactions.

- Wonder how Coinbase instantly validates?

Same way everyone else does.

- Don't really want to create a bias implementing "Limits" / We want to be just as rapid for larger volume transactions. 

You are limited by the network. Is one confirmation really too long to wait?

Nice one Edd, don't get me wrong mate - Love the Bitcoin protocol and have massive respect for the time and effort honest miners sacrifice. They're Legends in my book.

1 Confirmation may work for our model

[Meuh6879]

for double-spending invalidate method, use 3 criterias to valid the real payment :
- bitcoin-QT server with instant verification
- blockchain.info instant verification (with blockr.io in backup or on main verification)
- bitcoinj verification (bitcoin android wallet)

when customer send bitcoin ... the cashier must see the 3 criterias at GREEN statut after max 10 seconds.