Bitcoin vs. Bits & The Legacy Financial System

Over the past few months I’ve been participating in the Bitcoin Foundation’s Financial Standards Working Group (as time permits). Below are my thoughts on ISO Standardization.

This article was originally posted November 14, 2014 at jason.dreyzehner.com.

It seems there are two primary areas for standardization: 1) display unit user preferences, and 2) software modeling and communication.

Formatting numbers for users is technically trivial, and probably needs no standardization at this stage in Bitcoin’s growth; product designers are already well incentivized to offer users in-demand options and reasonable defaults for viewing balances. (Product design teams are also likely better equipped than us to answer those questions.)

On the other hand, communication between software packages is non-trivial and already causing problems in bitcoin implementations. Jeff Garzik’s thoughts here are very relevant: https://blog.bitpay.com/bitpay-bitcoin-and-where-to-put-that-decimal-point/

It seems to me the most valuable contribution this committee can make is more along the lines of technical standardization for the world outside of the bitcoin ecosystem.

To expand on Jeff’s thoughts, I see two technical realms requiring standardization:

1) “Bitcoinland”

This is the realm of financial software born and bred in the Bitcoin ecosystem. Following the lead of Bitcoin Core, nearly all bitcoin software, libraries, and APIs operate in terms of simple integers of satoshis (eliminating entire classes of language-specific implementation bugs). The base unit here is 1 satoshi, and is unlikely to change before a hard fork that increases the divisibility of bitcoin.

Exceptions to this standard — mostly Software as a Service APIs (like BitPay) — typically format numbers to improve human readability and usability (right now, almost all in whole BTC), and probably best fit into the previous category of “user preference” (which as mentioned above, I think is clearly not yet mature or stable enough for formal standardization).

Generally, I’d say “Bitcoinland” is not the primary audience of this ISO standard. These software solutions and services are built to deal with bitcoin as their primary currency, and often, as their only currency. International currency standards will typically not be strongly considered — rather, many “Bitcoinland” developers expect Bitcoin will grow to replace national currencies and render obsolete the very standard we are developing.

2) Legacy Financial Systems

This is the the realm of financial software predating Bitcoin. Right now, all but the most sophisticated financial software worldwide assumes a “currency” is a number with 2 decimal places. This fundamental assumption is deeply ingrained into data structures, application logic, and communications infrastructure. Expanding this abstraction usually requires very significant, often-dangerous modifications to business-critical code. Even simple updates can take fast-moving startups weeks to review and test sufficiently — for very large, fragmented companies, it may take months or years.

For this segment of software implementations, there is also an emerging standard. Given the technical challenges to modifying the software concept of a currency, many companies are choosing to model bitcoin like the other currencies (with 2 decimal places), and defer conversion to a “user preference” unit until immediately before displaying the amount. Many of BitPay’s shopping cart and eCommerce integrations work this way, and a number of companies are choosing to account for bitcoin in this way as well.

I think this is the realm in which this committee’s standardization can add the most value. Legacy financial systems are actively using international standards in their products, and a matching standard for Bitcoin would both make Bitcoin easier to implement and lower the perceived risk of development teams “doing it wrong”.

So:

It is currently difficult to reconcile the reigning “user display preference” standard unit of 100,000,000 satoshis, or 1 “bitcoin”, with the reigning technical standard unit — 100 satoshis, or 1 “bit”.

A significant increase in price will eliminate this difficulty. Until that time, I’d recommend we treat our task as a technical problem and reduce the scope of our solution to the more relevant “Legacy Financial Systems” audience defined above. This also avoids the sticky problem of publicly presenting a solution arrived at by voting. (Which, in engineering, typically means both parties are wrong.)

Are there other thoughts on this idea?

To summarize: This committee would present a reasoned argument for providing ISO with standards that closely match those expected (and currently being used) by most Legacy Financial Systems implementing bitcoin. Additionally, we could clarify that “Bitcoinland” development seems to remain generally “not affected” by ISO’s legacy currency standardizations, and that given bitcoin’s current volatility and growth, the “display unit” preferences of the market are also not yet mature enough for non-controversial standardization to a single unit.