Bitcoin: Architectural Problems and Limitations
Bitcoin is unquestionably the most ballyhooed digital currency around today, touted as the world's populist savior from the tyranny of central banks. But is it really? While it's true that Bitcoin wallet hashes are anonymous (meaning they're just a string of numbers with no real world identity attached to them), there are a number of serious issues with Bitcoin, especially from a privacy perspective. For example, did you know that:
- Once mined, bitcoins are perpetual objects endorsed repeatedly to their new holders. This means that every coin carries a transaction history showing every wallet which has ever contained that coin, in a permanent record tied to the coin. Which is a lot like having an RFID chip embedded in the physical cash in your wallet!
- Our solution: digital cash vouchers are always destroyed in every transaction, and replaced with new vouchers bearing fresh serial numbers. This makes tracking the flow of value around the system impossible.
- The Bitcoin "blockchain," which is a distributed public ledger, contains a record of every bitcoin transaction, ever. This is like taking the concept of a title database for real estate or motor vehicles, and extending it to individual pieces of paper currency. Ridiculous!
- Our solution: servers do not keep or record transaction history. Only wallets do, by means of encrypted receipts provided by payees to payers (which receipts the servers cannot see). The wallet owners can also delete these per-transaction receipts permanently at any time. Our servers have no way to determine which vouchers are in which wallets, or the amount of any wallet's current balance.
- The IP address from which a bitcoin spend originated is recorded on the blockchain as part of the transaction. This means that unless you're using a third party wallet or a VPN service, every bitcoin spend you ever made can be searched out using your IP address. Only with the latest release of the Bitcoin reference client (0.11.0, released in July 2015), has the ability to submit spends using a proxy or TOR exit been added. (But it would have been better not to fool with recording IP addresses all along.)
- Our solution: the system simply cannot see a wallet user's IP address, even if they're not using a VPN. Login gateways that receive user traffic are cryptographically prevented from seeing which wallets are logging in. No IP address or other identifying information is ever recorded, period. Since IP addresses are never seen by a Voucher Publisher or Issuer, this fact is by necessity not by design.
- The Bitcoin blockchain now occupies over 43 Gigabytes of storage. This makes running your own client cumbersome (talk about a giant footprint!), which is why most people use "web wallets," where their bitcoins are stored by a third party. But this creates the opportunity for theft by hackers, and/or censorship by the wallet providers. (Coinbase has been caught doing that, related to iGaming.) This effectively centralizes Bitcoin usage around a very few providers — the very thing Bitcoin's "decentralized" architecture is supposed to prevent!
- Our solution: store wallets in the server cloud, but encrypted so that servers cannot read them. All decryption is done only on the user's own device after the data is retrieved. Thus no wallet data (other than some preference settings) is stored on the user's device, yet at the same time the server operators do not need to be trusted.
- The global Bitcoin network can only handle an estimated three (3) transactions per second. By comparison, Master Card and Lady Visa can handle tens of thousands of transactions per second (and probably do at times, especially between Black Friday and Boxing Day). Yet Bitcoin is the currency that's going to take over the world and replace fiat central bank money? The only way it could do so is if most transactions in bitcoin were cleared in centralized pools, run "off the blockchain." These pools would most likely be run by — you guessed it — banks! (Though systems like ours can provide an off-chain pool, too.) Bitcoin's throughput cannot be increased significantly without either reducing transaction size (which is impractical, given all the extra baggage people want to stick into a transaction at times), or by increasing the size of a block (which would probably increase the time spacing between blocks, effectively thwarting the purpose). In fact, it appears that a fork of Bitcoin known as Bitcoin XT has been deemed necessary by key deveopers Gavin Andresen and Mike Hearn. But even this drastic measure only increases the maximum throughput to 24 transactions per second!
- Our solution: some things really are better centralized, and payment clearing is one of those things. Our network throughput, like that of Visa and MC, can be increased simply by throwing more hardware at the problem. Our payment capacity already meets or exceeds that of the entire Bitcoin network, and would likely do so even if our entire system were running on a single modern desktop! Instead of trying to decentralize clearing, we could simply parallelize the entire system, by establishing additional, entirely separate Voucher Publisher networks. In the Voucher-Safe digital cash architecture, success leads to more competition and alternatives, not to less.
- A Bitcoin transaction normally requires between ten minutes and an hour to clear, depending upon how many confirmations the payee wants. Confirmations are of course required only because the network is "decentralized." Clearly this is just as unworkable as the transactional speed limit, and again points inevitably back toward centralization. (A recent software upgrade glitch caused the dev team to recommend waiting for more than five hours' worth of additional confirmations, and they apparently still don't know when this issue will be resolved!)
- Our solution: centralizing the payment clearing between the Voucher Publisher and the relevant voucher Issuer causes voucher payments to resolve usually within a few seconds. About as fast as swiping a credit card (but a whole lot more private!).
- A Bitcoin transaction takes place only if 50%+ of the hashing power on the network (provided by "miners") agrees that it did. While there's never been a successful "51% attack," in which a majority of computing power invalidates transactions submitted by a minority, what kind of payment system needs a majority vote to decide whether a transaction actually happened or not? Only an absurd one obsessed with decentralization above all else. There is technically no such thing as objective reality on a blockchain. Reality amounts to collective subjective majority opinion. (Claiming that no one needs to be trusted is just another way of expressing that no one is ultimately responsible.)
- Our solution: a payment either happened, or it didn't. If it did, somebody got a new voucher sent to them. The force of objective reality runs strong in the Voucher-Safe family.
- Bitcoin is vulnerable to Denial of Service (DOS) attacks. In recent months the Bitcoin network has been struggling with a high volume of attempts to spend annoyingly small amounts of bitcoin. Basically, spammers are circulating "bitcoin dust" around just to be irritating, something like email spam. This soaks up and wastes scarce transactional bandwidth. The only solution found so far is to raise the toll demanded by miners for mining payments into new blocks, hoping that this will make it painfully expensive for the spammers to continue doing this. It might be more useful to ask instead why it is that thousands of powerful computers are needed to process the spend of a value worth less than a micro-penny, and why it is that every node in the whole network needs to see a copy of every such transaction. (The answer, unfortunately, seems to be "because there's no other way to do it.")
- Our solution: voucher payments are paid for using "tokens," which are essentially micro-vouchers denominated in the same asset type as the vouchers, i.e. from the same Issuer. The fees in tokens for making spends are set by each Issuer, and are generally modest (say between a dime and a dollar), regardless of the amount of the spend. This does however make it inherently un-economic to spam micro payment amounts in the digital cash wallet system. Moreover the smallest voucher value which can exist is 0.0001. There really is little point in allowing vastly more decimal places than are materially meaningful. But that can happen when geeks go wild and aren't paying attention to the context in which they expect their system actually to get used. (Or if they fantasize that every last Satoshi will someday be an economically meaningful quantity.)
- Bitcoin blocks are vulnerable to fragmentation, which can cause delays in clearing transactions due to serialization. Bitcoins are mined in blocks, made up of a declining number of coins. (Originally there were 50 coins in a new block, then 25, then 12.5 at present.) When a transaction is posted using a coin, or a part of a coin, in a given block, other transactions using coins in that same block must serialize behind it. This means that transactions involving pieces of the same coin cannot clear in parallel. This is normally not a problem, unless a transaction involves a large value which is made up of many coin fragments which come from multiple blocks. Such transactions may logjam behind others, with increasing probability depending upon how many different blocks are involved in making up the values. In this way the blockchain resembles what happens when a hard disk drive becomes fragmented: the rate of data throughput is reduced. Since many bitcoin blocks do not circulate at all, activity tends to be concentrated in more recently mined blocks anyway. In view of the "dusting" problem described in the previous item, coin fragmentation on the blockchain is constantly increasing. As bitcoin becomes more widely adopted and used, this could become an acute problem.
- Our solution: vouchers are automatically merged to provide source value for payments as required. The voucher received by the payee will always be singular, as will any change voucher returned to the payer. Vouchers can also be merged into a single voucher at will. Because vouchers are always destroyed and replaced in every transaction, fragmentation is essentially impossible.
- Lost Bitcoin wallets cannot be recovered. Access to native Bitcoin wallets (e.g. wallets run with Bitcoin Core) cannot be recovered, if the passphrase which unlocks the wallet has been lost or forgotten. Failure to encrypt the wallet with a passphrase makes it trivial to steal all of the bitcoins in it, simply by purloining a single file (wallet.dat). However, addresses associated with public keys in a lost wallet, if known to others, can still receive bitcoin spends (see next issue).
- Our solution: digital cash wallets can be recovered, by providing the answers to five security questions which match the answers that were given when the wallet was originally created. The recovery answers are hashed together along with the wallet ID, and if a lookup succeeds using the hash of the hash, then the encrypted full login coordinates are retrieved, and decrypted on the user's device using the hash as the key.
- Bitcoins can be spent out of existence. If bitcoins are spent to an address for which the private key has been lost (known as a "dead wallet"), those bitcoins are irrecoverably lost. It's literally like pitching money into a black hole. Worse, there's no way for the payer to determine in advance whether a given bitcoin address hash is attached to a dead wallet. (Short of making a tiny spend first, and asking the recipient whether they got it.) No one knows what percentage of all bitcoins mined to date are forever sitting in dead wallets. Thus it isn't possible to know the real quantity of bitcoin actually in circulation.
- Our solution: payments are a two-step process: the payer spends, and the payee picks up. If the payee doesn't pick up their payment within the time limit the payer specified (1-7 days), then the payment can be reclaimed by the payer (who has till doomsday to do so). This neatly eliminates the dead wallet problem. Also, wallets can be closed voluntarily by their owner, which adds the wallet's key to a CRL (certificate revocation list). This prevents the PKS (public key server) from returning the wallet's key, which makes it impossible to make spends to a closed wallet in the first place. (Bitcoin has no such mechanism for revoking a wallet, not even a wholly empty one.)
- Bitcoin cannot control server updates. Because the Bitcoin architecture pushes what are properly server-side functions out onto the client-side, individual wallet clients running in the network can cause problems when they are "down-rev," i.e. running on an old version, and thus doing server-side operations using out-of-date software. There is no direct way to force network nodes to update. The end result can be farcial comedic tail-chasing like this.
- Our solution: our clients are clients only, and do not do server things. We generally release updates to servers and clients simulaneously. While we do pay attention to upward compatibility, in the event that a server change necessitates a client update, we could notify users that they needed to upgrade from inside the client when they logged in. It's a messaging system, after all!
- Contary to the popular notion that Bitcoin is "censorship-proof," it would actually be pretty easy to stop it. All a country or an ISP would need to do is program their intelligent edge routers to interdict packets which conform to the specialized Bitcoin protocol. Bitcoin employs a distinctive custom protocol, and routers have extraordinary intelligence these days. That plus blocking a few key websites which host web wallets, and it's pretty much over. (Unless you're using a VPN or TOR of course!)
- Our solution: we use an ubiquitous protocol, XMPP aka Jabber chat. The 'X' stands for "eXtensible," and that's just what we've done: extended the packet definitions to support wallet and payment-related messaging. Because this extended data is encrypted, and only transmitted over secure connections anyway, it would be extremely difficult to detect or interdict. And blocking XMPP in general, which is widely used on computers, tablets, and smartphones for chat apps, would be only slightly less of a blunt instrument approach than blocking HTTP would be.
If you think these issues might make it hard for Bitcoin, and other cryptocurrency blockchain technologies, to serve as reliable private money, you're certainly not alone. It's pretty obvious that widespread adoption of Bitcoin will lead inevitably to the centralized clearing and control of Bitcoin. Which probably explains why Wall Street and financial regulator types are not only investing in Bitcoin businesses big time (to the tune of $315 million in 2014 alone), but are even starting their own ventures.
But, not to worry: if you use Silent Bitcoin (SBC), the voucher asset type backed by stored bitcoins, you can spend them just as safely and anonymously as you can any other voucher type. Note that SBC already exists and is fully usable today! You can even spend SBC directly to any Bitcoin address, in addition to other wallets within our network. Certainly it's not up to us to decide what people should use as money. However our digital cash technology can make even Bitcoin perfectly safe and anonymous to use!
As Gandalf urged, "Keep it secret, keep it safe." Transform Bitcoin into digital cash!