Ensuring security of funds and preserving anonymity when using Bitcoin for e-commerce

Retrieved from the Wayback Machine.

When configuring an e-commerce website to accept Bitcoin, it is important to be aware of the extra security considerations relating to private keys. Each payment needs its own Bitcoin address so these need to be readily available on the system providing the e-commerce functionality. This is not true of the private keys. Unless payments need to be made in an automated manner in response to user actions on the website, the wallet that holds them can be stored in a much more secure environment. This can make it significantly harder for a hacker to steal the funds.

There are various techniques to have a continuous supply of addresses for a wallet stored elsewhere:

Immediate forwarding to fixed address

Addresses are generated from a hot wallet the e-commerce system has full access to, e.g. bitcoind. Once the customer has sent the funds to a Bitcoin address for a specific payment, a subsequent transaction can be created by the system to forward the funds to an address that has its private key stored in a more secure manner. The exact outputs received from the customer can be used as the inputs for the forwarding transaction. This means that it is not necessary to wait for multiple confirmations of the original transaction, minimising the window of attack when the funds could be stolen. However, it may be prudent to wait for 1 confirmation to avoid transaction malleability issues.

The problem with this technique is that all the funds received end up in a single address. This is very bad for anonymity because it links together on the public ledger all of the payments made on your website.

Extended public keys

Addresses could be generated in the wallet and uploaded to the live system in bulk, however there is no standardized way for this to happen and a much more elegant system exists. As described in detail in my previous post, xpubs can be used to generate endless addresses for a wallet that is maintained elsewhere. This is exactly what we need, but there are a number of problems:

• Low wallet support:
  Electrum: exports an account xpub for receiving purposes for normal and multisig wallets.
  Wallet32: works, but this is not a multisig wallet.
  Coinkite: will export multisig xpubs, but they actively do not support what they term subkey front running.
• Low e-commerce software / service support:
  The only e-commerce systems that I know of that will accept xpubs for generating addresses are CoinDirect and my own Drupal Coin Tools.
• Hard to setup:
  Even with a non-multisig arrangement, care has to be taken that the correct path prefix is used with the xpub to generate addresses that match those in the wallet software. With multisig an xpub from each key signer has to be put into the system.

Obtain addresses from web wallet API

Some web wallets provide API access to obtain new addresses for an account. Of course this is only available for wallets that are maintained by a third party. Coinkite and BitGo are examples of this. Fortunately both these services are multisig so the risk of utilising a third party is minimised.

This technique has a number of disadvantages. In order for the e-commerce solution to be able to retrieve addresses from your wallet, it will need some sort of credentials. If a hacker stole these they could then access the wallet and steal the funds anyway. It is necessary that these APIs are able to utilise credentials that do not have spending capability. For example, Coinkite has this capability.

The APIs are not standardised so e-commerce systems will need to have a unique plugin written for each wallet service.

Use third party provider for payment workflow

Services such as Bitnet, BitPay and Coinbase offer a much more managed solution for Bitcoin payments. They do much more of the heavy lifting and the e-commerce system just has to do the bare minimum to integrate. This means that you do not have to have Bitcoin addresses stored on your system whatsoever.

Advantages:

• Easier to integrate if integration doesn't already exist.
• Not necessary to run your own Bitcoin node or use a service such as Chain.
• Customers may feel more confident using one of these trusted brands rather than a solution directly built into your web site.
• Because these services typically just maintain a database record for how much they owe you, they effectively act as a mixing service. This can preserve payment anonymity.
• Built-in conversion to fiat.
• Prevent exposure to exchange rate volatility.

Disadvantages:

• These payment providers are subject to very strong KYC and AML regulations.
• Again, these APIs are not standardised so e-commerce systems will need to have a unique plugin written for each wallet service.

Stealth addresses

At the moment stealth addresses are purely theoretical, but they could be an extremely useful means of generating addresses for e-commerce.

A highly simplified overview of how it works is that a single address is provided by the payee (your back-end wallet). This is stored on the e-commerce platform. Endless addresses can then be generated from this address that the wallet will be able to detect and spend.

It has a number of advantages over xpubs:

• Much improved usability. It is a much shorter address and can even generate multisig addresses from a single address.
• The same stealth address can be used by multiple payers while maintaining anonymity. This is useful for addresses that are publicised.
• Has the potential to have broad wallet support.