3. Countersigning by a trusted party

GreenAddress.it has proposed a scheme whereby multi-signature coins are owned by a combination of the user and a trusted wallet server. When a payment is made the wallet server signs a statement asserting that it won’t allow double spending of the used outputs.

In practice this means signing the BIP 70 Payment message with some key that is identifiable as coming from a particular trusted third party (TTP); the PKI is a good way to do this.

Whilst this technique is simple and would work, it effectively brings back elements of the old banking model with its known disadvantages:

Users who don’t have a relationship with a TTP would be out of luck. The coins must be 2-of-2 because if the user could sign with a key they exclusively controlled, the extra protection wouldn’t work. GreenAddress tries to mitigate this by providing time locked transactions so if they go away or blacklist you, you will eventually get the coins back. This is a neat solution. But it’s something no other provider has adopted and I’m not sure how the tools situation looks. Merchants have to learn about and evaluate TTPs. They must then configure their system to recognise those TTPs. Then Bitcoin users must also find a TTP, evaluate them, pick one and configure their coins. This is sticky and would give existing incumbents an inertial advantage. Ideally there would be a way to automatically distribute a fraud proof and revoke the TTP if it misbehaved, but this isn’t specced.

This approach is in some ways like a network of non-anonymous miners that use regular signatures instead of PoW-style “signatures of effort” (Blockstream calls them “dynamic membership multi-party signatures”). But the current Bitcoin structure has quite a few advantages, namely that mining is a very liquid market. Ideally we’d do our best to keep that and fall back to the more traditional scheme only if we can’t make Satoshi’s more novel approach work reliably.

4. Remote attestation

A variant of the GreenAddress scheme is to use trusted computing with remote attestation instead of a trusted wallet company.

Trusted computing is a feature of modern chipsets. The CPU or TPM chip signs a statement saying “I am a real piece of hardware manufactured by X and I am running software Y”. Remote attestation is a complex technology and I’m glossing over a lot of details, but to sum up — it would allow your computer to prove to another that it’s not double spending.

In effect, the manufacturer of your computer becomes the trusted third party, except one that doesn’t even know it’s doing so because the entire process is run entirely locally with no servers required.

The problem with TC is that the implementations shipped by AMD, Intel and ARM all suck, and actually building a computer capable of remote attestation is an exercise in frustration. The technology is currently targeted only at the server market and requires exceptionally good systems programming skills to utilise.

Intel are working on a new iteration of the idea called SGX. SGX is looking a lot more promising than the existing technologies based on the documentation they’ve published so far. Unfortunately, SGX is currently vapourware: beyond some technical docs, a scientific paper from Microsoft and a handful of blog posts nothing else about it is available. It seems likely to be several years before an SGX based solution becomes workable. And unfortunately whilst ARM TrustZone is widely deployed in mobile phones it apparently can’t do remote attestation. So it seems likely that only desktop wallets will be able to pull off this trick in the forseeable future.

Even if implemented this scheme has the same problem as all the others: if not all users can do it, then payment fraudsters will just pretend they don’t have the right setup and double spend with plain old transactions. Unless almost all transactions were being counter-signed in this way it wouldn’t be feasible to restrict regular old-style transactions and the benefits wouldn’t appear.

5. ID verification

A very simple approach to fighting double spending is to just do what credit card accepting merchants already do: incrementally more aggressive ID verification of buyers depending on how much of a fraud problem there is. For example some payment processors in the credit card space use IP address profiling, billing/delivery address matching, Javascript, evercookies etc to try and catch repeat fraudsters. In extreme cases users can be blocked outright, or asked to submit documents.

This approach is simple and well tested, but of course, highly inconvenient for the buyer. Sufficiently advanced technology can make it much less inconvenient, but ideally this will never be needed because regular transactions will work well enough.

6. Waiting for confirmations

This one might seem too obvious to mention. If you can wait for confirmations, ideally you would. Unfortunately often merchants don’t do so, even in cases you’d intuitively expect would be possible like shipping items from a warehouse.

I suspect the main reason is that existing business workflows are based on the assumption that payments take only a few seconds and double spending is revealed weeks or months later. This is the model used by credit cards. It’s not unheard of for chargebacks to roll in 4 or 5 months after the original payment, long after the goods have shipped. Delays of many weeks are more common as it takes time for people to get and check their statements. So outside of things like holidays or flight tickets, most merchants just have to accept credit card double spending as a business risk and price it in: they can’t usually undo a sale before the goods or services have been provided because credit cards are too slow.

So paradoxically even though Bitcoin can reveal that a double spend took place within minutes rather than months, these businesses cannot use the new information as they have no tools or procedures in place to do so. By the time the block chain makes a decision the merchant was already informed of the payment, databases have been updated, the orders dispatched to the warehouses, the email receipt has been sent etc. Being able to undo a purchase requires software and procedures they don’t have.

Businesses could fix that by making the user sit on the invoice screen for a couple of blocks, but that interrupts the users flow and would make Bitcoin feel much slower than credit cards, even though in a sense it’s actually much faster. So they just accept unconfirmed transactions via BitPay or Coinbase and enjoy the fact that double spending against them is still very rare anyway.

7. Punishment of double spending blocks

The purpose of mining is to prevent double spending by recording the chronological order of transactions as accurately as possible. Miners that execute Finney attacks to defraud sellers are not doing that; they’re charging the collective Bitcoin community money via the inflation subsidy for a service they aren’t actually providing.

Normally when an entity charges you for something and then doesn’t provide it, there are consequences. The consequence for a miner trying to fork the chain and undo confirmed transactions is that they stand a good chance of losing the electricity (i.e. money) they used to mine: this is a good incentive to behave. For Finney attacks there are no consequences.

Tom Harding has been researching the possibility of identifying blocks that appear to be engaging in Finney attacks and making a slight alteration to the first seen rule for blocks. Of course, this rule is critical for Bitcoin’s operation so changes to it are not to be taken lightly at all. He has written a paper on his proposed change to the rules which features a lot of analysis of the potential impacts. His goal is to give more certainty for transactions after about thirty seconds has passed.

I have not had time to thoroughly read or analyse this proposal and so have no strong opinion on it. That said, it’s unclear to me that 30 seconds is significantly better than ten minutes: I suspect the utility dropoff after about 5–10 seconds is dramatic given the desired “guy in queue paying for coffee” type user experience. 30 seconds is probably OK on the web but it would still make us far slower than EMV contactless credit cards for in person transactions.