One of the commonly cited problems that many people see with Bitcoin as a payment method is the fact that all transactions are final and irreversible. With credit cards, if you buy something but never receive the product, you can issue a chargeback to recover your funds potentially weeks after the transaction. With Bitcoin, on the other hand, no such option exists. Of course, in many cases the lack of chargebacks in Bitcoin is actualy an advantage; in transactions where the two parties have an established relationship, or one party is a reputable business, the possibility for any kind of fraud on the merchant’s side is quite low, and the lack of an institution to mediate chargebacks is what allows Bitcoin to avoid the high fees charged by credit cards and Paypal. But nevertheless, there are definitely many industries in which the level of consumer protection that credit cards offer is very useful – and, so far, in those cases Bitcoin has had little to offer. Now, however, Bitrated is positioning itself to be the first mainstream Bitcoin service to change that fact.
Bitrated’s solution to consumer protection is in some ways an old one: escrow. Rather than a customer sending a payment to a merchant directly, the customer sends the payment into escrow, and the funds are released from escrow only when the customer confirms that they received the product or service. However, Bitrated makes one major addition to the model: multisignature transactions. Rather than the customer sending money directly to a trusted escrow agent, the customer sends the money to what is called a “2-of-3 multisignature address” constructed using the customer, merchant and escrow agent’s public keys. The mechanics behind a 2-of-3 address are exactly what one might guess from the name: funds sent to this address can only be spent with the cooperation of any two of the three parties.
The process for making an escrow transaction in Bitrated works roughly as follows:
- Suppose that Alice wants to send money to Bob through escrow. To start off, Alice goes to the Bitrated website and goes to “Browse arbitrators”. She then selects an escrow agent (say, Trent) and clicks “Start transaction”.
- Alice pastes the conditions of the transaction (eg. “in exchange for the 0.5 BTC, Bob ([email protected]) agrees to send Alice ([email protected]) a new Samsung Galaxy S4 smartphone, still in the box and undamaged”; for actual escrows, Bitrated offers a helpful page listing important details to include in the contract). She clicks “start”,
- The Bitrated interface provides Alice with a link. Alice sends this link over to Bob, and Bob opens the link in his web browser, and accepts the contract.
- At this point, the Bitrated interface generates the 2-of-3 multisignature address between Alice, Bob ad Trent (because only Trent’s public key is required to make such an address, this can be done without Trent’s participation). Alice sends funds to the address, and after one confirmation (usually 0-15 minutes) Bob sees that the funds are in escrow.
- When Alice wants to release the funds, she enters Bob’s address and an amount to release, and clicks “release”. The interface creates a transaction sending the specified amount to Bob’s address, and signs it with Alice’s private key.
- Bob sees a pending transaction in his interface, and he clicks on it to inspect it. Seeing that the transaction is sending funds to his address, he clicks “approve”. The interface signs the transaction with Bob’s private key and the transaction is published, completing the transfer.
If Alice and Bob have a dispute, at the bottom of the page the interface presents a link which either of the two can send to Trent. At that point, Trent will contact Alice and Bob to gather evidence from both of them, and adjudicate the dispute. If he rules in favor of Alice, he will construct a transaction sending the funds to Alice’s address and sign it. Alice will then need to approve the transaction, at which point she will have her funds back. If Trent rules in favor of Bob, the same process occurs between him and Bob.
What are the advantages of this multisignature escrow process? There are three main factors to consider. First, in all cases where there is no dispute Trent is not involved at all. As a result, nearly all transactions will have no fee. If Trent gets involved, he will likely charge a fee, but the fact that fees are charged only when the escrow agent is actually brought in ensures that the system is paid for primarily by the very same people who make the heaviest use of it – a drastic change from the credit card system, where the fallout from fraud is evenly spread across everyone in the form of a 2.9 fee charged to every merchant and ultimately passed on to every consumer, regardless of how much due diligence each individual consumer does to deal with reputable merchants. Second, even if Alice and Bob bitterly disagree over whether or not Bob adequately fulfilled the conditions to receive the payment, if they both agree that Trent is doing a bad job of adjudicating, or is charging excessive fees, the two can sign a transaction together to send the funds directly into another escrow with another escrow agent. Finally, Trent himself has no opportunity to run away with the funds. In theory, Trent can conspire with Alice to split the funds fifty-fifty and leave Bob with nothing, but such a situation would require two of the three parties involved to be dishonest, rather than only one.
If multisignature escrow is so attractive, why has it not been done before? The answer is, of course, that it has been done; the tools to do so have existed since 2012, and are now available in the form of moderately easy-to-use command line tools such as sx and my own pybtctool. Bitrated innovates over such cruder “do-it-yourself” escrow solutions in several places. First, the service is very easy to use. Anyone can understand how to use Bitrated even if they have no idea how multisignature transactions or public and private keys work. And for those users who are more advanced, Bitrated provides the option for users to add their own public key instead of having one generated for them by the service.
The first thing that we see is that most of the data is hidden behind a “hashtag” (a technical term for a number sign). This is an idea originally conceived by the creators of RushWallet, an online “instant wallet” service requiring no username or password. The reasoning behind this choice is that the data behind the hashtag is actually not sent to the server, meaning that the server learns almost nothing about any of the transactions that take place over its site. Right now, the server does see partially signed transactions, but in future versions even that data transfer would be encrypted. Then, we see five parameters: “alice”, “trent”, “terms”, “proof”, “bob-priv”, each with a value that is made up of around fifty letters and numbers. All five of these parameters are base64 encodings; the value of the “alice” parameter represents Alice’s public key, the “trent” parameter Trent’s public key, “terms” the terms, “proof” a signature of the terms by Alice (proving that the terms were not modified in transit) and “bob_priv” Bob’s private key. Alice has a similar URL but with her private key and a signature from Bob instead of herself. Thus, even if BitRated shuts down, Alice and Bob can still decode their URLs and, perhaps with the help of a more technical user, get their funds out.
One area where Bitrated is still lacking, however, is in the choice of escrow agents. The escrow agent list is essentially unmoderated, and although a sort of reputation system is present it is still difficult to determine how trustworthy an escrow agent is. A partnership with professional escrow agents that are vetted by Bitrated may improve the service in the short term, especially if Bitrated intends to target those users who are not yet used to the concept of evaluating and choosing their own escrow agents. Bitrated’s current architecture also presents a problem on the escrow agent’s side: escrow agents have no way of filtering escrows. In fact, it is technically possible to use literally anyone who has ever sent a Bitcoin transaction as an escrow agent without their permission. On the one hand, this does make life easier for Alice and Bob – Alice does not need to wait for her escrow transaction to be approved before sending the funds. On the other hand, many escrow agents will likely want to set restrictions on the kinds of deals that they adjudicate – perhaps even limiting deals to a few standard transaction types. Although escrow agents can certainly simply state their policies on their webpage and refuse to even look at arbitration requests from noncompliant escrows, the service could be improved by creating a more explicit interface for escrow agents to set their policies.
What is the future of Bitrated going to be? At this point, Bitrated is still limited in scope; the service as it stands is designed only for person-to-person transactions with an active participant at each end. One possible next step that Bitrated may wish to target is facilitating semi-automated transactions such as e-commerce setups. If Bitrated is correctly set up to deal with such transactions, online e-commerce startups should be able to “plug in” to third party arbitration with minimal effort. All they would need to do is show the customer a multisignature address instead of their address, and provide an interface for the customer to confirm that they received a given product. If Bitrated reaches that stage, then multisignature arbitration may well become a mainstream, low-cost alternative to traditional credit card transactions with chargebacks. Such a system would protect the merchant and the customer, and if a given merchant always delivers what they promise and never gets into a dispute the fees on both sides would be quite low. The future of consumer protection with cryptocurrency is only just beginning.