Joining the ranks of Coinbase, MtGox and Blockchain, Bitcoin developers Stefan Thomas and Jeremias Kangas have released a lightweight Bitcoin payment processor of his own, with a twist: you do not have to trust it to use it. The way that all other payment processors to date have kept track of individual orders is by creating a unique address for each payment, and forwarding any payments that they receive to the merchant. This does prevent the main issue with not bothering with payment processors and instead just having a single address – namely, that if you receive a payment you have no way to tell who sent it, but it also presents a trust problem: the merchant must trust the processor to hand back the bitcoins. Although over the normal course of business the incentives are aligned for the processor to do just that, as otherwise the merchant would immediately abandon the processor and the processor would lose that merchant’s revenue forever, in reality merchants’ revenues are often not a smooth daily trickle. For example, when Butterfly Labs opened up their ASIC mining computers to pre-orders this June, they received $250,000 in a single day. One can easily see how a merchant might be uncomfortable with trusting a third party with such a large windfall.
One solution is for the merchant to provide a few hundred addresses controlled by himself for the payment processor to use, but that requires the merchant to constantly have to replenish the processor’s database with new addresses. One could give more addresses at a time, and release an automatic script for generating addresses and including them in one’s wallet, but the problem remains that either the merchant must at some point replenish the processor’s address database, a concept foreign to any other payment system used today, or the initial database would have to be impractically large. In order for such a setup to work nicely, the merchant would have to somehow give an infinite number of addresses to the payment processor at the same time – in a finite amount of data. AcceptBit, in effect, does exactly that.
Explaining how AcceptBit does such a thing requires a basic knowledge of the mathematical properties of Bitcoin’s elliptic curve cryptgraphy. A private key in Bitcoin, used to sign transactions, is a number roughly between 0 and 2256. A public key is a point, with coordinates (x,y) both in approximately the same range. Elliptic curve mathematics has an operation of “adding” two points to generate a third point, such that this addition satisfies the standard mathematical properties of commutativity and associativity (ie. a+b = b+a and a+(b+c) = (a+b)+c). Thus, you can “multiply” a point by a number by repeatedly adding it to itself (or more efficiently with the double-and-add algorithm), and this multiplication is also associative. The elliptic curve standard also defines a specific point (Gx,Gy) as the “base point”, the values of which can be looked up in Bitcoin source code or the SEC2 specification. A public key in Bitcoin, from which Bitcoin addresses are derived, is simply the base point multiplied by the private key. It turns out that there is no known way of determining the private key corresponding to a given public key in less than about 2128 operations (at current levels of computing power, longer than the lifetime of the universe), and this is part of the basis of Bitcoin’s security. There exist operations of “signing” a message and “verifying” a signature for a given message such that signing requires a private key and verifying requires the corresponding public key. Public keys are, as their name implies, public, and so the entire Bitcoin network can verify that the owner of a given address actually signed transactions that appear to be spending from that address by verifying the signatures with the address’s corresponding public key.
AcceptBit takes advantage of the “multiplication” operation that elliptic curve mathematics allows. It asks you to take a root private key, which you keep to yourself, and multiply it by the base point to generate a root public key, which you submit to AcceptBit. AcceptBit can generate new addresses by multiplying the root public key by a given number, for which you can generate the private key, and therefore spend from, by multiplying your root private key by the same number. AcceptBit can keep multiplying the key by different numbers to generate new addresses, so the number of addresses that they have is basically infinite. However, AcceptBit can only watch the addresses that it generates; it cannot spend from them – solving the payment processor trust problem.
This is not a new idea; the concept has already been implemented in the popular Bitcoin client Electrum and is formalized in the BIP 0032 specification. However, AcceptBit is the first service that makes use of it to do something that would not be possible without it. For now, the only wallet that includes built-in support for the specification is Electrum, and so an Electrum wallet is currently required to use AcceptBit.
AcceptBit has a simple form where you fill in your business’s name and your root public key from Electrum (obtained with electrum get master_public_key), and you can start generating invoices immediately. The form for generating an invoice is simple; just fill in a currency amount, a currency (with dozens to choose from) and click “Create”. You then get a payment page containing an address to pay to and a QR code to scan, and which shows the status of the transaction: unpaid, paid or confirmed. The main page also shows a list of all invoices that have been generated, allowing you to see which of them have been paid.
However, there are a few features which are still lacking from the service. One major weakness is a lack of automatic updating for the payment pages. Currently, in order to see whether an invoice has been paid or not you need to refresh the payment page. The service would become much more usable if it included a script which checks for payment every couple of seconds and updates the page automatically. Another flaw is its lack of an API. The only way to generate invoices is to fill in the form on your main merchant page; there is no convenient way to generate invoices automatically. Of course, one can hack one’s way around the restriction by filling in the form automatically; the command line script for this is ” wget --header 'Cookie: csrftoken=0' http://acceptbit.com/m/3psKTF6icX2GU9Beo1PPgb --post-data 'csrfmiddlewaretoken=0¤cy_amount=0.1¤cy=USD' “, substituting in your own merchant page and desired amount. However, this is far from convenient, and there is no way to keep track of invoices that is convenient for an automated script either. Thus, using AcceptBit to accept payments on one’s website is currently difficult.
If AcceptBit implements these missing features, it can become a competitive means of accepting payments even for those who are willing to trust an established third party merchant provider. It and Blockchain are the only two providers that do not require any kind of account to use, and right now Blockchain mirrors its weaknesses; although its merchant system has an exemplary interface for automated scripts, its operators have not seen a need to develop any merchant interface for human beings. Blockchain also has another weakness: less privacy. Because its merchant system requires you to specify a specific address to send bitcoins to, unless you specify a list of a hundred addresses to randomly choose from all of your customers’ payments will be collected in one place. AcceptBit, on the other hand, has the ability to generate new addresses that belong to you with every invoice, solving this problem. Although AcceptBit’s model of providing addresses that are already directly under the merchant’s control does mean that it will never be able to match BitPay and WalletBit’s offerings to convert earnings directly into fiat currency deposited in the merchant’s bank account, for those merchants who simply want an easy-to-use, hassle-free solution with minimal setup required AcceptBit definitely has the potential to become the best choice.
