Topic: Double spending and btc wallets (Read 794 times)

When you transmit a transaction, there is nothing in the transaction that indicates what wallet sent it.  There is no way for a merchant (or BitPay, or anyone else) to know what wallet I'm using.  They can ask me to use MultiBit, and I can lie and say that I am using MultiBit, and I can even show them that the wallet looks exactly like MultiBit, and yet it could be my own custom software designed to look like MultiBit but actually designed to create fraudulent transactions.

If merchants use payment processor companies like BitPay to handle payments and if they dictate payments to be made via specific wallets at their POS, essentially only those specific wallets would be used?

This is not true.  Merchants that don't understand the risks blindly demand confirmations on bitcoin transactions so that they can't be reversed, while happily accepting credit card, debit card, and paypal transactions that can be reversed for several days (or in some instances months!).  There are many merchants that happily allow the customer to leave immediately after payment is made.  If the purchase is small in value, the risk of loss is acceptably small.  If the merchant has a trust relationship with the customer, the risk of loss is acceptably small.  If there are easier ways for the customer to steal, the risk of loss is acceptably small.  Essentially, any situation where a merchant would be willing to accept a credit card, there is a good chance that they can also accept a bitcoin transaction with 0 confirmations.


Agreed.  If I'm buying a car, or a boat, I won't mind waiting around for a few confirmations while the paperwork is all completed.  If I'm buying some very expensive jewelry, I won't mind waiting around for a confirmation or two as well.  On the other hand, if a merchant requires a confirmations when paying for a meal in a restaurant, or buying a candy bar in the neighborhood corner-store, then the merchant is probably being excessively paranoid and deserves to lose business to other merchants that have a better understanding of risk and profitability.


There is no way for a merchant to know this.  I could create a wallet that looks exactly like MultiBit or exactly like blockchain.info, but which is actually my own custom desigend double-spend wallet.  That would be an awful lot of effort to go to just to steal a candy bar that I could just as easily have shoved into my pocket when nobody was looking.


The risk is already quite low.  Merchants that feel they need to lower the risk even more can do things like run custom software that monitors a large number of peers to see if there are any competing transactions on the network.  If there are no competing transactions seen on the network, and if the customer's transaction includes a reasonable transaction fee, the risk of a double-spend is extremely small.  In that situation, the only way the customer is going to pull off a fraudulent transaction would be if they were cooperating with a solo miner (or mining pool) that has a significant percentage of the hash power of the entire network.  In that case, the customer could potentially commit the fraud even after 1 confirmation.

Danny, I really appreciate your reply. We are essentially talking about the same thing but from different perspective.

I am asking double-spending from the perspective of merchants. For them, the problem now is that customers need to wait for at least 1 confirmation before being allowed to leave. This is to reduce the risk of accepting double-spending payments. In most cases, this is unacceptable to customers.

However, if merchants know that customers are paying from wallets like MultiBit or Blockchain.info, and if such wallets do not allow double spending (by preventing spending of 0 confirmation coins), then merchants will face a much lower risk of accepting double-spending payments.

Does it make sense?  

Since the vast majority of peers on the bitcoin network are all running software that is based off the reference client,  once a peer hears about a transaction that spends a particular set of outputs, that peer will ignore all other transactions that they receive that attempt to spend any of the same outputs.  Since a broadcast transaction is relayed throughout the network in just a few seconds (often fractions of a second), a wallet that does not deduct the balance after spending would not allow you to broadcast a competing transaction.  By the time you created the second transaction and tried to send it, too much of the network would have heard about the first transaction, and the second transaction wouldn't get anywhere.

Unless you are a solo miner (or operator of a mining pool) with a significant percentage of the network hash power, to successfully broadcast 2 different transactions that share any of the same outputs, you either need to:

• Broadcast a transaction that is very unlikely to get confirmed within a few days
• Wait a few days for most peers to forget bout the first transaction.
• Broadcast a different transaction that spends some of the same outputs

or

• Create a transaction, but don't broadcast it
• Create different transaction that spends some of the same outputs, but don't broadcast it
• Create network connections to two separate sets of peers
• Broadcast one of the transactions to one set of peers while simultaneously broadcasting the other transaction to the other set of peers.

The first method can be accomplished accidentally if you use a wallet (such as blockchain.info/wallet) that automatically deletes a transaction from the wallet if it hasn't confirmed after a few days.  If you are using a wallet (such as MultiBit) that permanently remembers all the transactions that it sent unless you manually remove them, then it can only be accomplished intentionally.

There are no trusted open source wallets in common use that allow the second method, accidentally or intentionally.  You would either have to create your own custom wallet, or trust your bitcoins in some wallet hacked together by someone else.

How so? Is it because MultiBit automatically deduct the balance once the user sends out the coin?

Does it mean then in order to double spend, one will need to find a wallet which does not deduct the balance after sending? And because wallets usually do deduct the balance, the wallet will probably need to be self-developed?

In bitcoin, a real double-spend (where 2 separate transactions spending the the exact same outputs get confirmed into the blockchain) is always impossible no matter what wallet you are using.

On the other hand, it is possible in some situations with some wallets to send (intentionally or accidentally) two separate transactions that each attempt to spend the exact same outputs.  Any given peer will only recognize one of the competing transactions and will ignore the other.  While there are 0 confirmations, this can result in part of the bitcoin network being aware of one of the two transactions, and the rest of the network being aware of the other.  Once one of the transactions are confirmed into the blockchain with 1 confirmation, the entire network will recognize the confirmed transaction as the valid one, and will reject the other transaction.

Using MultiBit, it would be difficult to accidentally create competing transactions that spend the exact same outputs.  But a MultiBit user could receive a 0 confirmation transaction from someone without knowing that person sent a competing transaction that was seen elsewhere on the network.  Then if the competing transaction were to become confirmed, the MultiBit wallet might not immediately notify the user, and might continue to show the then invalid transaction as "unconfirmed" until the user rescanned the blockchain.

If one uses wallets which does not allow 0 confirmation spending, does it mean that the risk of double spending will be reduced?
For example, MultiBit does not allow 0 confirmation spending, does it mean that MultiBit users are not able to double spend?