Many of us are familiar with BitInstant, the micro-credit provider that allows anyone to deposit money through bank wire transfers or even cash deposits at the local bank and get the deposit at any major Bitcoin exchange in less than an hour. However, what many do not realize is that, despite the name, BitInstant does not deal with Bitcoin at all; rather, it focuses purely on the fiat currency side of the Bitcoin exchange system. While BitInstant is undoubtedly very useful, helping people get their bitcoins faster, facilitating efficient international fiat money transfers using Bitcoin as an intermediary, and even being credited by some for Bitcoin’s recent price stability as people can easily and immediately buy in whenever the price drops, it does not quite solve the whole problem of transaction delays. Now, Jonathan Ryan Owens and his company Ringcoin is seeking to do just that by introducing Zipconf, a service that he calls “the other side of instant” – instant deposits into exchanges on the Bitcoin side.
While the prospect of instant Bitcoin transactions of any sort rightfully arouses suspicion among many, Jonathan is confident in his system’s ability to prevent or detect attempts to defaud his service by double-spending. The basic principles behind how his system works make sense. Double spend attempts on instant transactions work by first sending a transaction as directly to the receiver as possible and then soon after that sending the same transaction but with yourself rather than the receiver as an output to as many other nodes as possible. The attacker is hoping that the receiver will see the first transaction and accept it as payment but then the second transaction will drown out the first throughout the network as a whole, and ultimately get included in the blockchain, rendering the first transaction invalid. Zipconf’s software stack attempts to prevent this in two ways. First of all, it broadcasts the first transaction as loudly as possible as soon as it gets it, reducing the chance that a double spend will be successful. Transactions also always include a small fee to encourage miners to quickly confirm the transaction into the blockchain, adding a further line of defense. Second, Zipconf is willing to compromise slightly on being instant, waiting 5-10 seconds after receiving a transaction to listen for double spend attempts before finally accepting it. By then, the transaction will have spread to much of the network and it is nearly impossible for a second, conflicting transaction to get a foothold.
There are of course many special cases to deal with as well, but Jonathan believes that his software stack will be able to handle them. Code is in place to deal with block reorganizations and occasional glitches in the network, and he has been working with the owner of Slush, the third largest mining pool, to ensure that his transactions will always be included in blocks. “We’ve been developing this based on edge cases for 6 months,” Jonathan reassures, “including extensive testing ourselves, trying to break it. We’ve found some very simple, and also some very clever ways to avoid risk.” At the moment ZipConf is in private beta testing and will be officially launched around next week.
As for use cases for such a service, there are several possibilities. Arbitrageurs and speculators, Bitcoin investors catching market swings and earning a profit by correcting price differences between different exchanges, will of course be Zipconf’s most profitable customers. Aside from that, there is a partner API through which sites which hold bitcoins for their users (eg. wallets, commerce/auction site accounts) will be able to allow their users to instantly withdraw to Bitcoin exchanges. And, finally, Jonathan admits, “the most important use case is impatience.”
Although the service does not have nearly as solid a footing of compelling use cases as BitInstant as it stands, what may be its salvation is that it simply does not need to. While BitInstant must deal with money services licensing and relationships with banking partners across many countries, Zipconf stays entirely within the Bitcoin economy, and will thus be able to keep its costs much lower. The upfront work is already done; the core software stack is well-tested and Zipconf has already signed up multiple arbitrageurs and potential partners, so even if users turn out to be less impatient and arbitrage less lucrative than Jonathan had hoped and no other use cases reveal themselves to pick up the tab the service will still keep operating at a profit even with very minimal volume. But there is cause for hope too, as plans to expand Zipconf’s range of services are already underway. Finally, perhaps where Zipconf shines the most is not even in the practical applications that its current implementation lends itself to facilitating, but rather as a proof of concept, a demonstration of the principle that whatever limitations Bitcoin may have are not fatal – Bitcoin is merely a bottom layer protocol, and whether the issue is speed, consumer protection, anonymity or whatever else the community demands, it can always be overcome by adding another layer on top.