I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)


Entries in bitcoin (6)


Mankind needs fractional satoshis

Update: Dr Craig Wright is pointing out that payment channels are a viable alternative to fractional satoshis. I am not an expert in payment channels, but it would certainly largely help in mitigating the problem discussed below. Then, choosing between on-chain scaling and payment channels boils down in establishing the actual limits of on-chain scaling. 

Bitcoin Cash aims at becoming the world currency. As discussed previously, terabyte blocks are needed to achieve this goal. However, the Bitcoin Cash protocol also needs a few changes as well. In this post, I will demonstrate why fractional satoshis are needed for Bitcoin Cash.

In the following, for the sake of concision, Bitcoin always refers to Bitcoin Cash.

Overview of the issue

A satoshi is, presently, the smallest unit of payment that can be sent across the Bitcoin network. There are 100 million satoshis in 1 bitcoin. In particular, the smallest non-zero transaction fee that can be paid is 1 satoshi. Non-zero transaction fees are desirable in order to eliminate spam; however, the original intent behind Bitcoin is clearly to keep those fees vanishingly small as far humans are concerned.

At mankind scale, let’s assume that we have 10 billion humans, and that every human wants to do 50 transactions a day. This might seem a bit high - after all, mankind won’t reach 10 billion humans before 2050, however, good engineering implies safety margins and thinking ahead. I firmly believe that Bitcoin must be engineered to support 10 billion humans and 50 transactions per day per human.

Let’s further assume that those transactions are secured by paying exactly 1 satoshi per transaction (1). The miners collect 1e10 * 50 * 365 / 1e8 ≈ 1.8 millions BCH per year. This amount is huge, about 10% of the total BCH that will ever be in existence (2).

Bitcoin Cash needs to be designed in such a fashion that it is possible for mankind to spend less than 0.001% of its whole monetary supply per year in order to transact freely. Over the lifetime of a human, 100 years, the total transaction fees would remain below 0.1% her or his average monetary capital, which feels about right.

Practical example: let’s assume that my average monetary capital is 100,000€ (just counting cash, not any other asset classes). Over the course of my 100 year’s lifetime, I will pay 0.1% of this amount to cover all my transaction fees, that is, 100€. On average, it’s 1€/year, that is, 0.27 cents per day. We are not far of the 1/10th of a cent per day of my previous analysis.

As such, the current Bitcoin protocol is not tenable at mankind scale. Satoshis are too large, mankind needs fractional satoshis.

14-bit left shift

The Bitcoin transactions are encoded with 64-bits integers. This choice, made back in 2009, remains sound. For the foreseeable future, all CPUs will be 64-bits CPUs. However, the current Bitcoin implementation is wasteful. There are 14 bits that are wasted, as we will see below. Yet, it turns out that those 14 bits are exactly what Bitcoin needs to make transaction fees low enough at mankind scale.

Proposal: 1 bitcoin is redefined as 1,638,400,000,000 naks - nak being the shorthand of Nakamoto - that is 214 nakamoto per satoshi.

Let’s demonstrate why 14 bits makes sense. With 50 bits, it is possible to represent 250 satoshis, that is, about 11 millions BCH. The richest BCH address in existence contains about 400k BCH. It’s unlikely that this address will ever grow 1M BCH, let alone 11M BCH.

Thus, in order to represent even the richest BCH address, the protocol only needs 50 bits. While it may be theoretically possible to accumulate more than 11M BCH on a single address, it’s straightforward to add a rule in the Bitcoin protocol to invalidate any transaction which would try to accumulate more than 11M BCH on a single address, forcing the owner of such a fortune to split her/his fortune over 2 addresses instead.

Now, the protocol is left with 64-50 = 14 bits which are “wasted” if we want to preserve the encoding of transactions inputs and outputs as 64-bits unsigned integers. Re-encoding all amounts in sat as nak only requires a 14-bit shift to the left.

As 214 = 16384, we can revisit our initial back-of-the-envelop calculations with 10 billion humans doing 50 transactions a day. We have 1e10 * 50 * 365 / (16384 * 1e8) = 111.4 BCH paid in fees to the miners per year. This is much better, about 0.0005% of the whole monetary supply paid to the miner per year, that is, 0.05% over the 100 year lifetime of a human.

A non-urgent yet kind-of-urgent change

Fractional satoshi won’t become a problem until about 1% of mankind starts using Bitcoin to pay for everything. However, every single day that passes, there are more software out there which are dependent on the current instance of the Bitcoin protocol. Thus, the Bitcoin ecosystem is accumulating technical debt.

We know that this debt will have to be paid back. Indeed, as demonstrated above, keeping satoshis as the smallest payment unit is not tenable. We also know that this debt comes with compound interests. At present time, fixing this issue will only incur a modest friction in the ecosystem. 10 years from now, if Bitcoin has any measurable degree of success at being a currency, then, it will be a huge mess. Every single piece of Bitcoin-dependent software will be broken by such a change.

Thus, I call to the Bitcoin developers to coordinate in order to introduce fractional satoshis in their mid-term roadmap.

Pre-emptive answers to questions

Will I still own the same amount of BCH? Yes, there is zero impact on your current BCH holding. If you have 1 BCH now, you will still have exactly 1 BCH after the change.

Does it change the upper limit on the number of BCH? Technically yes, but in practice, no. This change would push back the date when mining becomes purely fee-funded by 4*14=52 years; and the total amount of extra BCH which will ever be mined will be less than 0.001 BCH. Hardly noticeable.

Nitpicking, why not 18 bits?

I do feel strongly that fractional satoshis are needed, and that 14 bits of extra precision is a minimum. However, if someone has a good reason to motivate a shift beyond 14 bits, maybe up to 18 bits, then, this person might be right. The discussion below is merely opinionated. This is not a demonstration.

The richest BCH address hold about 400k BCH. Thus, technically, it is still possible to adjust the protocol to free up to 18 bits, with a hard-cap at 703k BCH for a single BCH address. However, I do see for potential edge cases in the ecosystem of Bitcoin.

If Bitcoin succeeds, then the world will start implementing accounting packages, ERP, POS, CRM …, where assets are valued in Bitcoins, or rather in naks. Most of those software developers will use int64 integers (signed) to track the valuations of those assets. Why? Just because it’s what naturally comes to mind as a developer if you need large signed integers.

As the non-monetary assets are typically valued more than the monetary assets - eg. for most people, their home is worth more than the cash they have at the bank, the same goes for companies - those accounting books may contain values that exceed 10M BCH. Those situations, arguably rare, would trigger bugs known as numeric overflows.

Through a 14-bit shift, naive financial software implementations would still work up to 5M BCH (beware, signed integers, we lose 1 bit of precision), while a 18-bit shift will cap the maximal amount at 350k BCH, that is, 16 times less. While, it’s only a hunch, my take is that this numeric precision of a 14-bit shift would be sufficient to eliminate all int64 numerical overflows in finance calculations even when dealing with the budget of giant corporations. With, a 18-bit shift, edge cases would remain somewhat possible.

(1) Most Bitcoin wallets that exist today do not let you pay 1 satoshi. Instead, the minimal non-zero payable fee is 1 satoshi per byte. However, this behavior only reflects the implementation of the wallet, not a limitation of the Bitcoin protocol itself.

(2) Technically, there is a limit at 21M BCH, however, experts suspect that a few millions BCH are lost forever. Anecdotal evidence: I personally know one person who has irremediably lost about 100 BCH. Thus, those estimates sound right. In any case, even if those coins where not actually lost, it would not fundamentally change the discussion above.


Terabyte blocks for Bitcoin Cash

Terabyte blocks are feasible both technically and economically, they will allow over 50 transactions per human on earth per day for a cost of less than 1/10th of a cent of USD. This analysis assumes no further decrease in hardware costs, and no further software breakthrough, only assembling existing, proven technologies.


As pointed out in the original Bitcoin whitepaper, achieving very large blocks do require taking advantage of Moore's Law rather than being stuck with fixed-capacity device. A terabyte block represents a block of 1e12 bytes, which can contain about 4 billion Bitcoin transactions. Assuming a worldwide population of 10 billion humans, terabyte blocks offer about 50 transactions per human per day (57 actually, but the extra numerical precision is not significant).

50 transactions per day per human appears sufficient to cover all human-driven activities; and only a healthy machine-to-machine market would require an even greater number of transactions. Such a market remains hypothetical at present time, and goes beyond the scope of this post.

Bigger blocks is the go-to plan to make the most of the hashing power invested in the Bitcoin network. Indeed, the hashing power provides the same security no matter if 1MB blocks or 1TB blocks are used, yet in the later case, the each transaction is secured with a million times less energy per transaction.

The on-chain scalability challenge is irrelevant for Bitcoin Core, as blocks are capped at 1MB which ensures no more than half a dozen of transactions per second. However, terabyte blocks are relevant for Bitcoin Cash, which could face about 7 millions transactions per second while producing terabyte blocks. In the following for the sake of concision, the term Bitcoin is always referring to Bitcoin Cash.

The mining rig detailed below, a combination of existing and proven hardware and software technologies, delivers the data processing capacity to process terabyte blocks. The cost associated to this mining rig is also sufficiently low to ensure a healthy decentralized market that includes hundreds of independent miners; arguably a more decentralized market than Bitcoin mining as of today.

For the sake of the scalability analysis, I am excluding the Bitcoin emission revenues, focusing only on the transaction fees and other alternative revenue streams which do not depend on Bitcoin inflation. Naturally, for the next decades, the bulk of the mining revenues are expected to be associated with the emission of Bitcoins rather than transaction fees.

A terabyte block mining rig

The mining rig includes 256 nodes, where each node includes:

  • 1 Intel Xeon Processor E7, 8 cores (USD 1250)
  • 2 Intel Xeon Phi 7210, 64 cores (USD 4000)
  • 1 Intel Optane 4800X 750GB (USD 3400) 
  • 2 Samsung 64GB PC4-19200 DDR4 (USD1400)
  • 2 WD Red 10TB HDD (USD 750)
  • Misc (rack, power, network) (USD 3000)

The prices have been obtained from public sources such as Amazon. Totaling those 256 nodes gives a price point of 3.5M USD. In addition to the nodes, a storage layer of optical storage based on the Freeze-Ray technology of Panasonic. While the pricing point of this technology is not publicly advertized, various sources are quoting 10 USD/TB as the price point for optical storage. This figure also matches the price point of the optical storage cartridges sold by Sony. Then, Facebook, who has deployed the freeze-ray claims a 80% reduction in energy consumption compared to HDDs. As current 10TB HDDs have a typical consumption of 5W when active, the freeze-ray energy consumption should be about 0.1W per TB. I will be using those two estimates in the following.

In order to cover 20 years worth of terablocks, the storage layer would require 553 free-ray rackable units of 1.9PB, which would represent a cost of 11M USD.

Then, the cost of energy should be accounted for. Each node consumes about 700W/h according to the nominal consumption of its parts, which gives about 180kW/h for the 256 nodes. Also with 0.1W per TB, the storage layer consumes an extra 100kW/h. Assuming a kWh at 0.1 USD, the yearly energy consumption cost would be 250k USD, totaling 5M USD over 20 years.

Finally, a 50Gbps internet connection is added for a price of 25,000 USD per month; which totals at 6M USD over 20 years.

The cost for the mining equipment per se, i.e. computing terahashes is voluntarily ignored, because this hardware can be considered as independently funded through the Bitcoin inflation.

Thus, I am considering here a 26M USD investment, to be amortized over 20 years; that is 1.3M USD/year of funding. At this point, it still needs to be proven that (A) the Bitcoin fee market can sustain such an expensive mining rig (B) this mining rig is capable of processing terabyte blocks.

As it does not make sense to build such a rig if the market cannot reasonably fund it, let's start with the financing part.

Financing terablocks

Assuming 250 bytes per transaction, terabyte blocks would deliver about 55 transactions per human per day, assuming a rough 10 billion humans on earth. The exact count of human is not important, as the cost of the mining rig is essentially linear in the number of transactions, which is also itself essentially linear in the number of humans transacting on the blockchain. If there are less humans using the blockchain, then the mining rig is linearly cheaper.

If we assume that the same 10 billion humans contribute 1/10th of a cent per day to fund the miners through their transaction fees, then the yearly transaction fees would be of 3,65 billion USD. Thus, those yearly transaction fees would cover the amortized cost of over 3650 / 1.3 = 2800 mining rigs. Assuming that miners want to profit beyond the marginal cost of operating a rig, a gross operating margin at 60% would still leave room for over 1000 profitable miners.

Funding a large number of copies of the blockchain is important to ensure a high degree of decentralization. The analysis that has been carried so far shows that minimal transaction fees would be sufficient to fund over a hundred of competing yet very profitable miners. However, our analysis is ignoring all the economic value that can be generated by holding a copy of blockchain data for other purposes than validating transactions.

Let's assume that a wallet app, which display an ad along with Bitcoin balance could earn about 1 USD per 100,000 views for a simple non-intrusive banner. Assuming that the same humans would check their balance once a week on such a service, we are considering a 5 billion USD market just through advertising revenues, which would fund hundreds of additional copies of the blockchain. This single use case does fund by itself hundreds more copies of the terabyte blockchain.

Then, assuming that the upper bound for the monetization of a terabyte blockchain is at 0.5 USD per user per year, is conservative. In 2016, Google is extracting about 7 USD per user per year, while Facebook is extracting about 16 USD per user per year. If Bitcoin reaches 1TB per block, a large portion of the world economy will be running on top of this blockchain offering numerous monetization opportunities.

I fail to see why, collectively, the market would not manage to extract at least 5 USD per user per year on average through blockchain related services. At this point, we are entering the realm of profitably funding a thousand more copies of the terabyte blockchain.

Scaling the terabyte blockchain

Some data processing problems are intrinsically difficult to spread over multiple computers (like machine learning) or are even designed to prohibitively difficult (like breaking encryption). However, Bitcoin is neither. Bitcoin is an embarrassingly parallel, the easiest and most straightforward kind of problems to be addressed through distributed systems.

The scalability challenges faced by Bitcoin are:

  1. Propagating transactions
  2. Validating transactions
  3. Building and broadcasting blocks

Let's review each one of those challenges.

Scaling the transaction propagation

Propagating transactions is the easiest. It merely requires bandwidth. As Bloom filters, or even better filters can be used, the P2P propagation of 1TB worth of transactions needs less than 3 TB of bandwidth per miner every 10 min (assuming that miner resent twice every transaction for fast propagation of the transaction through the network). Indeed, miners transmit the filters first which are vastly more compact, and transfers the actual transactions only when those transactions is actually requested.

A direct calculation gives a minimal requirement of 45 Gbps to operate. The mining rig has 50 Gbps which is sufficient to reach a sustained throughput of 1TB blocks while aggressively relaying transactions.

Scaling the cryptographic validation

Validating the correctness of a Bitcoin transaction is a two-fold process. First, the cryptographic correctness of the transaction must validated: the miner must verify that the transaction has been properly signed by the sender of the funds. Second, the economic correctness of the transaction must be validated: the miner must verify that the originating address contains enough fund to cover the transaction. In this section, I am focusing on the first part of this challenge, the cryptographic correctness.

Based on [1], I assume a 2ms CPU cost per transaction on a regular 2Ghz x86 CPU. At 250 bytes per transaction, a 1TB block every 10 mins represents 6.7 millions transactions per second. With 2ms of CPU per transaction, we need 13400 CPUs to perform the concurrent validation. The mining rig contains 256 * 2 * 64 = 32768 CPUs through the the Intel Xeon Phi boards. The mining rig is largely sufficient to keep up with the transaction validation. The rig has even spare capacity to catch-up with a delayed validation which could, for example, occur in case of a local network outage. As transactions can be trivially partitioned against a fast hash, achieving a linear scaling of the cryptographic validation is straightforward.

Scaling the economic validation

As pointed out above, in order to validate a transaction, the miner must also check the balance of the Bitcoin addresses in order to ensure that a transaction does not end-up creating Bitcoins out of thin air. In the present implementation of Bitcoin, this validation is performed through a software component known as the UTXO database, the database of unspent transaction outputs.

Terabyte blocks represent 7 millions transactions per second. An optimized implementation only requires 2 reads and 2 writes per transaction to the persistent UTXO storage:

  • First read: check whether the transaction is even legit.
  • First write: If the transaction is legit, the address is marked as dirty with the fund removed.
  • Second read: If the transaction makes its way into the next block (produced by another miner), another check is performed to recheck correctness.
  • Second write: if the foreign block is correct, update the balance of the transaction.

Thus, the miner needs a sustained IOPS throughput of 4*7=28 millions IOPS. As every Intel Optane card offers 550,000 IOPS, the mining rig delivers a collective 140 millions IOPS, largely sufficient to sustain the throughput associated with 1TB blocks. Moreover, the rig has also spare capacity to catch-up after an outage.

Once again, sharding transactions against a fast hash is trivial, thus, implementing a Cassandra-like UTXO database is straightforward. Using Cassandra, Netflix had already done benchmark up to 1 million write / sec back in 2011 while Intel Optane delivers more than 50x the IOPS available back in 2011 through SSDs. Thus, there is no doubt that a specialized database could scale to 28M IOPS and more.

Then, beyond the IOPS, the miner also needs to ensure to have enough storage to store UTXO database. A compact binary encoding of the UTXO database requires:

  • 1 byte for flags (up to 8)
  • 3 bytes for the block height
  • 20 bytes for the Bitcoin address
  • 4 bytes for the "clean" amount in Satoshis (*)
  • 4 bytes for the "dirty" amount in Satoshis (*)

(*) There are only 21 millions Bitcoins, and each Bitcoin contains only 100 million Satoshis. Thus, the number of Bitcoin addresses that can contain over 4 billions (2^32) Satoshis (40 bitcoins) is limited to 550,000 addresses or so. This number of "super-rich" addresses is very small, and thus would be special cased in order to let the rest of the UTXO database benefit from a more compact encoding. In total, 32 bytes are needed per entry in the UTXO database.

With 256 nodes equipped of 750GB Intel Optane, there is enough storage to store 6e12 hot addresses, that is, 600 addresses per user considering 1e10 humans. Then, the HDDs of the nodes, which provide over 20TB of additional storage could be used to increase to the number of hot addresses to 6000 per human, while keeping more than half of the original storage capacity to spare for other needs.

In practice, both modern HDDs and the Intel Optane are performing 4KB block reads and 4KB writes at the hardware level (beware block reads and block writes should not be confused with the blockchain blocks). Thus, the most efficient strategy when writing would be to read a storage block, which contains 4096/32 = 128 entries and to evict the oldest entry, according to the blockchain block height.

Beyond, those hot addresses, the miner leverages its slower optical storage layer, which contains checkpointed copies of the full UTXO database. As it would take more than 100 days for all users to collectively touch more than their 6000 "hot" addresses, the full snapshots of UTXO database can be done rather infrequently, probably about one per month, the final tuning being dependent on the precise hardware specification.

Updating the UTXO database once a new block is found is also a non-issue. The mining rig has 32TB of RAM available, and this RAM can be used to keep the latest blocks in-memory while those blocks are being gradually written to the UTXO database. In particular, the amount of RAM is sufficient to cover the even rarest situations where a short dozen of blocks end-up being orphaned.

Scaling the block propagation

Once a miner has found a target hash, there is a strong incentive of quickly broadcasting the corresponding block, otherwise, another miner might win the mining race by broadcasting faster its own alternative block in the mean time. However, by the time a block is found, the bulk of its content, the transactions is already known to the other miners. Thus, the only information that needs to be transferred is a compact filter which points out the exact set of transactions that has been included in the block.

This mechanism is leveraged by Graphene, which reduces the amount of data that needs to be broadcast when a new block is found to a fraction of the original block size. Graphene demonstrates a compression factor of 186, which would bring down a 1TB block to 5.5GB. As the mining rig has a 50Gbps network connection, it will take less than 1 second to transfer the the full payload to a second miner, triggering an exponential cascade of broadcasts. However, it would be inefficient for the receiving miner to wait for the full payload to be received; the cascade of broadcast would usually start from the first "chunk" received. The Graphene payload would be chunked in smaller chunks, of say, 100MB.

Indeed, the economic interest of the miners is to always work on the latest block, thus if a miner claim to have found a new valid block and that the latest, say, 100 claims made by the same miner all proved to be correct, then it would a profitable assumption to put a limited trust into this miner and immediately start the cascade of broadcasts. Breaching this trust would not earn anything to the miner as its peers would still reject the faulty block within a minute. Worse, the bad behaving miner would immediately lose its hard-earned reputation, hence slowing down the propagation of its own future blocks, for tens of blocks, as the other miners would opt for the full prior validation. In practice, such a miner would most likely have to re-earn the trust of its peers by mining dozens of reduced blocks (faster to transmit), forfeiting most of the transaction fees to the benefit of its peers.

Through an early broadcast, and assuming that the Bitcoin network is comprised of miners with similar or superior internet bandwidth, the full broadcast of the 5.5GB to 10,000 miners is straightforward to achieve in 10 seconds or so, assuming that each miner starts propagating the fresh data upon reception of the first chunk, which would happen in less than 200ms no matter the distance between two miners on earth.


At this point, we have seen that a rig costing 1.3M USD a year in amortized costs is sufficient to support terabyte blocks. However, my hardware and bandwidth costs assumptions are wildly unrealistic. It will take at least 5 years from now for the Bitcoin ecosystem to reach the point where terabyte blocks are needed (onboarding mankind just takes time). Within 5 years from now, the hardware costs will have diminished - a lot.

Since the publication of the original Bitcoin paper 8 years ago, practically every cost quoted in this document have been reduced by a factor greater than 10. The cost of long term data storage is already anticipated to be divided by 3 by 2020. The bandwidth cost is also expected to decrease of 30% per year for the coming years as well.

Then, I am not accounting for any additional software improvements. Flexible Transactions and Schnorr signature could reduce the transaction size by more than 20%. Pruning the blockchain itself could probably halve the amount of storage actually needed.

Thus, within 5 years, it is conservative to assume that the amortized cost will only be 1/3 of my present estimate with a conservative mix of cheaper hardware and more efficient software. At this point, we would be reaching 400k USD/year of a rig capable of processing all the transaction that mankind will ever need (maybe not all the transactions that machines will ever need though, but that's a different scenario altogether).

For the average individual, 400k USD/year may feel like a huge amount of money, yet from a business perspective, this is a modest amount. In Paris, many well-placed boutiques are paying more than that for the rent alone. A small consultancy firm of 50 consultants, still in Paris, does also pay over 400k USD/year for their offices. Opening an IKEA store is considered being a typical 50M USD investment, twice as much as much as the mining rig presently considered. The investment cost associated to a small 10 turbine's wind farm would also exceed the cost of such mining rig.

While it is true that this cost represents an entry barrier, mining has been a highly specialized business with high entry barriers for years already. Impotent miners, nodes who do not mine blocks, do not add security to the network. The only option to decentralize further Bitcoin is not to wish for a downsize of miners, but to organize a massive expansion of the mining pie which will comparatively shrink every miner.


Bitcoin Cash is Bitcoin, a software CEO perspective

TLDR: my company, Lokad, is redirecting its attention to Bitcoin Cash, as the true Bitcoin

Like Jeff Bezos, I also believe that being successful in business depends on being right rather than being smart. Smarter means that you will solve given problems faster and better. Righter means that you will identify better problems. As I had been writing in the past, smarter problems trump smarter solutions. Any single time.

What’s Bitcoin about? The intent is to let anyone send and receive secure money in a way that is almost free and almost instant (check the original paper). Over the last two years, Blockstream, a heavily funded company, has brought “smart” but terribly wrong “improvements” to Bitcoin:

  • They have denied the almost free property of Bitcoin by capping the block size.
  • They have denied the almost instant property of Bitcoin through RBF (Replace By Fee).
  • They have weakened the security of Bitcoin through SegWit (Segregated Witness)

To be fair to the Blockstream team, they can’t claim the full ownership of this mess. They got help from other, smart, but unfortunately equally wrong, people.

Now, the Bitcoin community is not without resources. Reasonable people, including the very first non-anonymous Bitcoin developer, have been pointing in the same direction for years. Thus, last August, the community finally made a stand: Bitcoin Cash.

The only thing that you really need to know about Bitcoin Cash is Bitcoin Cash is Bitcoin. Bitcoin Cash has simply undone the damaging Bitcoin features; and yes, sending money is back being almost free and almost instant. Plus, the whole thing does not rely anymore on insecure shenanigans such as anyone can spend tricks.

For my company Lokad which specializes in supply chain optimization, the blockchain has many promising applications. Naturally, it’s always possible to roll-out your own blockchain, but that somewhat defeats the purpose of having a globally unified ledger. Yet, a ledger limited to 7 transactions per second is unusable. At Lokad, we have clients who are already doing more than that! My company needs a ledger that can process tens of thousands of transactions per second; and this happens to be exactly what Bitcoin Cash is about.

Finally, the biggest hurdle that I see with SegWit Bitcoin (for a lack of better name) is SegWit. From my software engineering perspective, this feature is poison: an over-engineered mess that is going to increasingly hurt as time passes. Having personally rewritten four times the core forecasting engine of my own company, I do claim some experience in recognizing unsustainable engineering mess when I see one: SegWit is one of them. If you really seek to fix malleability (a non-urgent problem btw) then FlexTrans is a much simpler and more secure alternative. Removing SegWit from SegWit Bitcoin feels more unrealistic every passing day.

Thus, Bitcoin Cash remains as the only viable option, which fortunately, happens to be a very good option.


Bitcoin, more thoughts on an emerging currency

Two years ago, I was publishing some first thoughts on Bitcoin. Meantime, Bitcoin has grown tremendously, and I remain an enthusiast observer of those developments. I had originally proposed a vision in 5 stages for the development of Bitcoin with

  1. Mining stage
  2. Trading stage
  3. End-user stage
  4. Merchant stage
  5. Enterprise stage

Back in 2011, I had written that mining was taken care of. Well, since that time, Bitcoin has witnessed an explosion of the hashing power through the development of ASICs, that is, hardware dedicated to the sole purpose of mining Bitcoins. Mining has definitively emerged as an extremely specialized niche.

Bitcoin is now halfway through its trading stage. Two years ago, MtGox was so dominant that it was the closest thing to be considered as a single point of failure for Bitcoin. Meantime, many other exchanges have emerged: Bitstamp, Kraken, Btcchina … I suspect that MtGox holds no more than 20% of the exchange market share. Are we done with exchanges yet? Well, not yet, Bitcoins remain convoluted to acquire – I will get back to this point.

Fade of interest, a fading danger but still the main danger

Price volatility, malevolent uses and adverse regulations are usually quoted as dangers faced by the emerging currency. I think that those threats have grown into non-issues for Bitcoins. Indeed, the very same criticisms can be made about most currencies and commodities anyway, and Bitcoin is now beyond the point where a roadblock could wipe out the initiative.

No, the one major risk for Bitcoin remains a fade of interest from the community. High-tech is a fast paced environment and few technologies survive a decade. However, considering the steady growth of Bitcoin in the public awareness, I am inclined to think that this risk, the one true danger for Bitcoin, is itself fading away.

Bitcoin, a poster child for antifragility

Over the last two years, Antifragile from Nassim Nicholas Taled, is the most noticeable book I have given the chance to read. In particular, I realized that antifragility is probably one of the greatest and most misunderstood quality of Bitcoin. Bitcoin might seem complex, but it’s nothing but a protocol sitting on top of a shared ledger. Thanks to the present Bitcoin reach, the ledger itself – technically the blockchain – is probably the dataset in existence that benefits from the greatest number of backups world-wide. That part is safe, arguably orders of magnitude safer than the ledger of any bank.

What about the protocol then? Well, the protocol can fail, like any piece of software. It certainly did in the past, and most likely, it will fail again in the future. Let’s bring the case further, and imagine that instead of a simple glitch, someone manages to crack the protocol tomorrow, what would happen? Well, as it’s exactly what happened to Namecoin not too long ago, it’s not too hard to make a good guess. First, a corrupted blockchain would spread wreaking havocs in the Bitcoin ecosystem. Exchange rates would drop of 90% overnight, and then exchanges would simply stop operating. Meantime, within hours after the emergence of the problem, community developers, possibly members of the Bitcoin Foundation, would start working on a fix.

Depending on the nature of the weakness found the Bitcoin, fixing the problem would take from a few hours to a few weeks. Considering the amount of people involved, I fail to see why it would take much more than that. Indeed, Bitcoin is complex, but in the end, it’s not that complex, especially when compared to other popular open source projects such as Linux, Firefox or Open Office.

In the case of Namecoin, the terminal protocol bug was resolved in about 24h, and that’s Namecoin, an alt-coin with about 0.1% of the community traction of Bitcoin.

Then, once a solution is found, a new blockchain would be restarted from one of the many non-corrupted copies of the old blockchain still available. Depending on the depth of the problem, multiple and incompatible solutions might be proposed more or less at the same time by distinct developers. The market might even undergo a few competing solutions for a while, but then a “winner’s take all” effect will quickly push to oblivion all solutions BUT the leading one. Within a few months (maybe less), the exchange rates would have returned to their previous levels.

It’s Bitcoin as a ledger that is truly antifragile. The other part, the Bitcoin as a protocol is fragile and it is likely to be modified dozens of times over the next decade, each new version annihilating the previous version if the community consents to it.

If a massive protocol breach was to happen, many companies part of the Bitcoin ecosystem could go burst overnight: some exchanges might accumulate instant but terminal losses, a revised protocol could possibly make former hardware designs incompatible with the revised protocol, etc. The Bitcoin ledger itself is the only entity to be antifragile within the ecosystem, simply because many developers are personally vested in the preservation of this ledger.

Moreover, shocks do benefit to Bitcoin:

  • Blockchain spam forced the community into making the protocol more resilient,
  • Major thefts, the rise and fall of Silkroad, helped Bitcoin to make the headlines,
  • Cyprus crisis undermined a bit the trust in the euros, again in favor of Bitcoin,
  • Etc.

The next country printing its money into oblivion, the next bank failing with or without bail-out, the next country not to honor its debts … any of those events will further boost Bitcoin: not because Bitcoin will have succeeded at doing or succeeded at preventing anything, but merely because Bitcoin will have remained un-impacted.

In a way, betting on Bitcoin is betting on a degree of economic chaos for the years to come. A world of perfectly stable economies offering frictionless currencies does not need Bitcoin.

When an Unstoppable Force meets an Immovable Object

While many trading options have emerged for Bitcoin, exchanging national currencies for Bitcoin remains a convoluted exercise; and, I suspect that it will remain non-trivial for a while, possibly a long while.

Indeed, pretty much everything in the banking system has been built around the notion of reversible transactions: the money on the bank is your’s, but only from a legal viewpoint. If a court decides that one of the transactions that originally funded your account was not legitimate, then the transaction can be reversed, and the money can change of owner based on third party interventions. With Bitcoin, ownership is a matter of knowledge. If you know the private key of a Bitcoin address, and if nobody else knows it, then you are the true owner of whatever Bitcoins this address has accumulated. It’s very physical process deeply uncaring for any legal considerations: no court order can recover a transaction made toward an address if keys have been lost.

This aspect explains why it remains almost impossible to use a credit card to buy Bitcoins, and why considerable delays tend to be introduced by parties even when wire transfers are involved. Exchanging cash for Bitcoins feels a more natural option though. A Bitcoin-to-Cash ATM is now already available in Vancouver. However, I suspect that ATM owners are heading for frictions. For any ATM model that takes off, bad guys will start buying ATMs for the sole purpose of reverse-engineering them with ad-hoc counterfeit money printed for the sole purpose of fooling this specific type of ATM. Indeed, bad guys don’t need to produce quasi-perfect counterfeit bank notes, merely counterfeit notes good enough to fool this one machine – a much easier task.

Again, with regular ATMs, it’s a non-issue. If someone manages to stuff an ATM with counterfeit money, the bank will simply cancel the corresponding transaction later on when the misdeed is uncovered. The bank has full control on its ledger.

A store of value

When I discovered Bitcoin, I was inclined to think it would succeed because it made world-wide payment frictionless. Well, it’s certainly still part of the picture, but the more I observe the community, the more I believe it’s a positive but relatively marginal driving force.

Few people would argue that the growth of Bitcoin has been essentially driven by speculative investments. Then, according to the Bitcoin community wisdom, many would also argue that the ecosystem will gradually transition from pure speculation to more mundane uses, hence justifying high anticipated conversion rates. However,

  • what if speculation stayed the dominant force not to be replaced by any other?
  • what if Bitcoin did not need any alternative force to maintain its value?

Indeed, a shared yet incorruptible ledger may offer a fantastic intrinsic value on its own, as it gives people the possibility to save value without trusting any designated third party – trusting instead the community as a whole.

Gold arguably offers the same benefice, but in practice, gold is an impractical medium to make any payment; and, as a result, any gold transaction starts by converting the gold back to a local currency.

Then, why trusting a designed third party should be a problem, one might ask? Well, most currencies are simply not managed in the interest of the currency holders. China, Brazil, Russia and Argentina probably come top of the list here because of their respective size, but they are far from being the worst offenders. Then, even dollars, euros and yens are hardly managed in the best interest of currency holders.

Here, Bitcoin benefits from an ancient social pattern called the Gresham's law. According to the Wikipedia:

Gresham's law is an economic principle that states: "When a government overvalues one type of money and undervalues another, the undervalued money will leave the country or disappear from circulation into hoards, while the overvalued money will flood into circulation." It is commonly stated as: "Bad money drives out good".

This law has been quoted many times about Bitcoin, but its consequences are usually misunderstood. Many detractors argue People are just hoarding Bitcoin, instead of spending them, which will be the downfall of Bitcoin. This observation is partial, and I believe that the conclusion incorrect too. Note that Bitcoin can still fail, but not because of this (see above).

A more accurate observation would be Many, if not most, are hoarding Bitcoins until they have an actual need to spend them. Meanwhile, those people just keep spending whatever non-Bitcoin currency they have. This behavior exactly fits the Gresham’s law, but what does it imply for Bitcoin?

First, merchants should not expect too many people rushing to spend their Bitcoins. Most people will keep spending their non-Bitcoin currency as long as they can. However, as accepting Bitcoins is an inexpensive option, there are little downsides in accepting Bitcoins - especially if Bitcoins are immediately converted to the local currency. Second, the more people keep their coins, the more the exchange rate will rise, due to simple market mechanics; thus, actually preserving the value storage property of Bitcoin.

At this point, detractors would argue that if there is little exchanges through Bitcoin and if it’s only about hoarding something that has no real value, how could this something be worth anything? This brings me back to the ledger (i.e. the blockchain). The one distinctive innovation brought by Satoshi Nakamoto is to make the world realize that a fully decentralized and yet incorruptible ledger was possible. The Bitcoin ledger is unique and it’s is what gives Bitcoin its value.

What people really owns when owning Bitcoins is a quantified amount of favors that could be given back from any member of the community; as long community interest has not faded, and it can be a valuable privilege – hence, not needing further benefits to justify the value.

Alt-coins will drive the evolution of Bitcoin

As an asset, what is the value of the Bitcoin protocol? Well, zero. Anybody can fork the source code, almost 2000 already did. Anybody can restart an alt-coin variant, dozens already did. While Bitcoin can be arguably estimated as invaluable to mankind, the protocol itself has zero market value: nobody makes money by selling the protocol.

The market value is in the ledger and only in the ledger, and this is why alt-coins are unlikely to gain any significant market value: they recycle the bulk of the Bitcoin protocol (the value-less part) while ditching the blockchain (the valuable part).

Namecoin is barely an alt-coin, because it addresses a very different problem; and that’s precisely because it does not compete with Bitcoin that it managed to gain traction.

Nevertheless, alt-coins represent an incredible opportunity for Bitcoin. Through experiments with alternative approaches, alt-coins are producing the knowledge that will make Bitcoin more secure, more usable, leaner, etc. Alt-coins, by being fragile experiments, directly helps Bitcoin in becoming more antifragile.

For example, Zerocoin brings an unprecedented level of anonymity in transactions by introducing rocket-science zero-knowledge cryptography in the protocol. From the Bitcoin perspective, there is absolutely no need to rush to import Zerocoin into the protocol. After all, Bitcoin has been striving without it so far. It’s much more reasonable to remain a passive observer for a (long) while, to let Zerocoin take all the bullets as bugs and flaws are uncovered, to let the Zerocoin community patiently address performance issues; and then, once Zerocoin has fully matured, to upgrade the Bitcoin protocol leveraging all this hard-won knowledge.

Thus, from a currency holder perspective, it means that alt-coins are doomed with high probability, because they won’t be able to preserve any technological advantage over time, bringing the competition back to a competition between ledgers where Bitcoin will only grow stronger over time.

Preserving Bitcoins

Since Bitcoin is about storing value, foolproof ways to secure Bitcoins is a critical ingredient. Two years ago, I was already indicating this challenge was not specific of Bitcoins: it’s just incredibly convoluted to operate a computing environment that you can fully trust. Long story short: you need air gaps, but it’s harder than it looks.

Furthermore, the overall amount of trust that people should have in their computing devices - notebooks, phones, servers in the cloud – has rather gone downward since the Snowden revelations. Thus, I am inclined to think that many successful ventures of the end-user stage will be Bitcoin appliances, that is, hardware devices designed for the sole purpose of dealing with Bitcoins. The Bitcoin Card and Trezor are both promising appliances, and I suspect there is room for a lot more contenders in this market.

Indeed, as most people invest in Bitcoins, it’s fairly reasonable to assure that most of those people will be inclined in spending a bit to more to secure their investment.

The widespread availability of Bitcoin appliances that have gained the trust of the community will be the sign that the end-user stage of Bitcoin is taken care of.

Annex: More technical considerations

Instant transactions are coming without much effort. It takes half a dozen of blocks to gain an absolute confidence in a Bitcoin transaction, which means about 1h of delay. Many people see this aspect as a design failure, which prevents most live payment scenarios. However, if one is OK from relaxing the constraint from absolute confidence to quasi-absolute, then instant transactions can be made very secure, arguably a lot more secure than credit cards transactions (because of chargebacks). All it takes is an online service that aggressively spreads the transaction over the network while in the same time it aggressively monitors any double-spend attempt. Such a service does not exist yet, but it’s not the most pressing issue for Bitcoin either.

Scalability is a very addressable concern. Scalability is frequently presented as a core design flaw, that is, if Bitcoin starts gaining traction, it will fail because it won’t be scalable enough. (Disclaimer: argument from authority) My own experience in teaching distributed computing and tackling Big Data projects for year indicates is that scalability is never a terminal problem. Scalability problems are straightforward problems merely needing patience and dedication to be solved. Furthermore, many developers just love tackling scalability challenges well beyond market needs. That part of Bitcoin is probably very safe.


Instant transfer with Bitcoin but without 3rd parties

Update 2012-05-17: Double spending can be made extremely difficult through quasi-instant double spending attempt detection. See as an illustration. I now believe that the ideas posted below are moot, because early double spending detection is just the way to go.

Bitcoin is a crypto-currency (check out my previous post for some more introductory thoughts) that provides many desirable properties such as decentralization, very low transaction fee, digital-native, ... However enabling instant payment has not been a forte of Bitcoin so far. It's very noticeable that people did even raise funds to address this problem with a trusted 3rd party setup.

In this post, I will try to describe a convention that would offer instant (1) secure (2) decentralized (3) transactions with Bitcoin (4).

Let's start by clarifying the scope of this claim:

  1. Instant. There is no such thing as real-time on the Internet, if only because of speed of light. Here, I am considering as instant anything below 10 seconds, which would be sufficient for the vast majority of the mundane use of a currency such as shopping.
  2. Secure. With Bitcoin, a transaction can be propagated in the network within seconds, yet, the transaction only becomes secured - aka with no further possibility of double spending - once the transaction has been included into the blockchain (6 blocks inclusion being the default of the Bitcoin client). Obviously, this requirement somewhat conflicts with the previous one, because 6 blocks represents about 1h on average (10min per block being the target speed of Bitcoin).
  3. Decentralized. The solution to reconciliate 1 and 2 should not rely on a trusted 3rd party. I hold no grudge against BitInstant, but if a solution exists to do the same thing without middlemen, then I believe it will only make Bitcoin stronger.
  4. Bitcoin. The solution should preserve the Bitcoin protocol as it exists today, requiring no upgrade of the community, except for those who would like to leverage instant payments. It's a convention in the usage of Bitcoin that I am referring to: it fits into the existing protocol spec. Those who don't want to follow this convention can safely ignore the whole thing.

Disclaimer: I am neither a cryptograph nor a security expert, merely an enthusiast Bitcoin user.

The core idea of my proposal is to introduce a twist in the notion of security: instead of a strict prevention of double spending, let's make double-spending more expensive that the expected benefit. Indeed, if double-spending becomes possible but only a steep cost (cost being expressed in Bitcoin too) then there is no incentive to actually make any widespread use of the double-spending trick for instant payments. With this twist, we accept the possibility of double spending, but only because it's highly innefficient for the attacker. It will not prevent a crazy attacker to do some damage, but from a global perspective, the overal damage through this twist should stay insignificant (because there are so many better ways to wreak havoc anyway if you're willing to spend money on the case).

For the convention that reconcilitate 1, 2, 3 and 4, I use two ingredients:

  • A Bitcoin address that is provably expensive: the setup cost of the address is X BTC. 
  • A mechanism to check that garantees that no double-spending attack to place for the address in the past (blockchain-wise).

Usual Bitcoin addresses are quasi-free (the CPU cost to generate a new address is negligible), but it's not difficult to produce a Bitcoin address that comes with a provable cost. The easiest way is go for monetary destruction with a transaction that targets /null. Yet, destroying coins is not entirely satisfying. 

Thus, in order to prove the value of the address AX, I propose to have a transaction, originating from a single address 1A only (only 1 input) that by convention redistribute its value to the coinbase address (*) of 10 consecutive blocks that are less than 1 month old (at the time of the proof).

(*) It's the address of the first transaction of the block used by the miner himself to capture its reward.

Indeed, we cannot rely on transaction fee alone to prove the cost of address, because a miner could decide to create a ficticious high-fee transaction in a block - fictictious in the sense that the fee would cost nothing to the miner, who would immediately recover the fee through the ownership of the block.

Yet, by targeting 10 consecutive blocks, we prevent any miner to fully self-reward itself with the transaction. Indeed, blocks are assigned based on a lottery where the odds are proportional to the processing power injected in the process. A "smart" miner would be able to target one (**) of his block, lower the cost by 10% which does not compromise the pattern (the cost remains very real).

(**) Some super-heavy mining pool, like deepbit, could push the leverage further; but having a single mining operator representing more than 1/2 of the total hashing power of Bitcoin is a big problem for Bitcoin anyway; so I am assuming here that no operator has more than a fraction of the total computing power available.

Then, the 1 month old restriction is just there to increase the odds that the coins do not get lost. Indeed, since the owner of the targeted addresses do not expect further funds to be pushed on those addresses they may not even monitor them once they have been emptied. Yet, with the 1 month delay, the lucky reward will not stay unnoticed.

Another argument in favor of rewarding the coinbase addresses is that it increases the incentive on mining efforts, hence strenghtening Bitcoin as a whole.

Based on the convention established here above, we have now a way to prove that a Bitcoin address did cost at least X BTC to her owner. Yet, we still need a way to be sure that no double-spending attack has already been done.

Here, the intuition is the following: you cannot prevent double-spending with instant payment (aka without block validation), but you can expose afterward the double-spending attack which will destroy the trust invested in the provably expensive address.

Let Alice be the honest merchant who offer instant Bitcoin payment; let Bob be the bad guy who trying a double-spending attack on Alice.

At the moment of the transaction, Bob gives to Alice the content of the transaction Tx1 that has 1B as input (the address of Bob, proved being expensive) and 1A as output (the address of Alice). Yet, at the very same time, Bob is issuing another transaction Tx2 that empties the address 1B. As a result, after a while, Alice realizes that Tx1 has been rejected.

It's now time for Alice to retaliate by exposing Bob. In order to do that, Alice produces a small dummy transaction to herself where the transaction Tx1 in recursively embedded as data though a convention based on OP_DROP. (***) Once the transaction Tx1 is exposed, the community of merchants, who like Alice, accept instant transaction withness that 1B cannot be trusted any more because the cumulative effect of the transaction Tx2 going out of 1B and of the exposed transaction Tx1 (which never made its way to the block chain) leads to a negative coin amount on 1B.

(***) For the sake of concision I am leaving out the tiny specifics of how exactly should this recursive transaction embedding be implemented. Anyway, based on my understanding of Script, it's perfectly possible to recursively embark a transaction (treated as data) into another transaction.

At this point, we have a system where Bob, the bad guy cannot hurt Alice the merchant (recipient) without getting some retaliation. Yet, what if Alice is a bad merchant and Bob the honest client? Could Alice hurt Bob just for the sake of breaking the community trust into his provably expensive address 1B?

We need one final touch to the convention to protect Bob the sender from a false accusation of Alice. In order to achieve that Bob should make sure each emitted transaction Tx1 from 1B, his provably expensive address, is broadcasted to the network, and not just given to Alice. By doing this, Bob ensures that Tx1 will make its way to the blockchain and prevents Alice to report 1B as dishonest (to be safe Bob is better off putting some transaction fee in Tx1 that guarantees a speedy chain inclusion).

Implementating the convention

As far I can tell, the proposal does not involve any breaking change. Ideally, the convention would make its way to the Bitcoin client (or a dedicated fork) to support 3 extra features:

  • Spending BTC to increase the trust level on a particular Bitcoin address.
  • Performing instant transactions channelled through the "expensive" Bitcoin address.
  • Reporting the "cost" of the address for the incoming transactions. 

Then, there is many small details that would need to be polished such as the delay for the community to decide whether trust is lost on an address after being reported. Also, the convention as a whole can also probably be polished further.

Anonymous payments

This convention would be one step further is making Bitcoin less anonymous that it is today. Considering the scope of application of instant payments, it does not seem (to me) too much of a problem. If you really want to stay anonymous, then, entering a retail store isn't top notch anyway. Alternatively, for eCommerce, the 1h payment delay is mostly a non-issue (except maybe for pizza delivery).

In real life

Instant payments are needed for small purchases: you typically don't need to transfer both a big amount AND to do it instantly, it's either or. To accept (or not) whether an instant payment of X BTC made from a proved Y BTC address should go through instantly should be left to the merchant itself.

With a 10 BTC proof, it would reasonable to accept instant payment up to 10 BTC (maybe a bit less assuming a self-serving miner scenario). Coordinating triple-spending (or more) in real life seems complicated (but not impossible) but I seriously doubt people would actually bother for such a complex scheme except to demonstrate its feasability. Indeed, the stakes would be very limited anyway, as anything large would go the usual route of non-instant payments. 

Then, looking at recurring customers payment with the same address would be also a way to gradually increase the confidence cap (from the merchant viewpoint) for instant payments even without asking the client to increase its proof.

Compared to a rough 2% middleman fee (based on pricing of BitInstant), I feel that the provably expensive address would be amortized in less than 1 year considering weekly purchase. Not a deal breaker, but still an option probably worth having a look at considering the positive side-effect on the mining side.