December 2015 Journal

WORDS is a monthly journal of Bitcoin commentary. This issue collects the December 2015 writing in the WORDS archive. For the uninitiated, getting up to speed on Bitcoin can seem daunting. Content is scattered across the internet, in some cases behind paywalls, and content has been lost forever. That’s why we made this journal, to preserve and further the understanding of Bitcoin.

Subscribe

---

BIP-0000

By Beautyon

Posted December 8, 2015

Satoshi Nakamoto, the creator of Bitcoin, left us with a fantastic tool to change how everything is done in finance. When he created Bitcoin, a large number of them were kept by him. Its easy to understand how this happened. Would Bitcoin take off? Would the Bitcoin ever be worth anything? There was no way of knowing in advance. Others had tried in the past to solve the problem of how to make an electronic money and failed. In all probability, this attempt would have fail also, and the bitcoin in his wallet end up being worthless.

But it Bitcoin didn’t fail. Bitcoin succeeded.

Now we know for certain that Bitcoin, both as a novel and stable form of programmable money, and a programmable contract system, is worth literally trillions of dollars. Getting this new money and platform into the hands of as many people as possible as quickly as possible has to be the goal; the more Bitcoin users there are, the bigger the ecosystem becomes, the more platforms and uses are developed, and the faster the transformation happens. The faster the transformation happens, the more likely it is that we get to set the rules and standards by which this new economy is governed.

With our project Azteco, we’ve created the easiest way of getting Bitcoin, using a simple and familiar 16 digit redeemable code system. These codes can be printed by any device, from generic computer hardware to the most modern POS systems. A vendor could even choose not to print them at all, and dictate them to the customer. The Azteco Vendor System can run anywhere, just like the MPESA vendors in Kenya run from wooden shacks, but unlike MPESA, which is a country specific locked in fiat system, Azteco sells access to Bitcoin, giving everyone a door to global e-commerce and its fluid, unrestricted facilities. Azteco users don’t need to own a smartphone or a computer. All they need is an Azteco Voucher.

We’ve been hard at work doing the final decentralization development so that each of our vendors no longer shares a single hardware platform, but now has their own dedicated server. Next in our roll out will be the opening of our first vendors on this new platform, and bearing this in mind, we have a bold proposition for you Mr. Nakamoto.

Give us your Bitcoin… For great justice!

If you give us access to your huge store of Bitcoin, we can disburse and diffuse it to the demographic that need it most in a fine grained way, so that a large number of different groups get to own Bitcoin. We do not need it all at once; we only need it in very small tranches the size of which can grow with the number of outlets we put on stream.

Releasing your Bitcoin into the market in this slow and deliberate and diffuse way will remove the risk of market shocks and a backlash. Everyone will know that your Bitcoin will not suddenly flood the market, crashing the price. It will also increase the demand for Bitcoin services and encourage more retailers to accept it. Right now, Bitcoin is in the hands of a very narrow demographic, and its movement is not as fluid at it could be. When a new demographic comes on board who need to actually use Bitcoin rather than store it as a speculation vehicle, the dynamic will change. Bitcoin will start to behave even more like money, and will begin to fulfil its global potential.

That is our proposal in a nutshell, Satoshi. Allow us to Johnny Appleseed your Bitcoin into the un-banked world. Sitting on an enormous cache of Bitcoin can only serve one purpose; to protect the price in the market. That Bitcoin would be far more useful were it in motion, circulating in the hands of everyone with even the smallest need for it.

You do not have to contact us to agree to our audacious proposal. All you have to do is deposit a first tranche of 1000BTC into this address:

1J786dgHzJyAYG5AJMFGasp52yFphrWsST

whenever you are ready. We will distribute that Bitcoin through Azteco, with a discretionary maximum single voucher amount of £5,000 at whatever the real time rate is on the exchanges. The sooner we start the process of spreading Bitcoin into the hands of the people who need it most, the sooner the transformation to the “Bitcoin Reality” can begin.

According to this tweet you have about 1,000,000 BTC lying dormant. If for example, we sell 1000 Bitcoin a month through our Azteco vouchers, it will take 19.1781 years to sell them all. This would be a clean, slow and steady dispersal of this large hoard of Bitcoin, over many years without disrupting the market. And we can go faster of course.

If you are living in a troubled country like Australia, continuing to hold this Bitcoin is literally dangerous for you. Once it is dispersed, the danger to you is dissipated also. This plan is good for you, and good for the world.

What say you?!

Not Satoshi? Westmalle Tripel then! ⤵

---

Waiting for blocks

By Dave Hudson

Posted December 19, 2015

Bitcoin blocks take 10 minutes to find don’t they? Well, actually no they don’t. Sometimes they can be found really quickly, but other times they can take a very long time. Just to make things confusing, the gaps between blocks can change depending on whether the hashing network is stable, expanding or contracting. What if we need 6 blocks (to get 6 confirmations)?

So what should we expect? What happens during hashing growth phases, and what would happen if the network were to lose large amounts of hashing capacity?

Running like clockwork?

In a somewhat perfect world we might hope that our nominal 10 minute gap between blocks would be exactly 10 minutes, but anyone who has ever watched block arrival times will know that that’s not what happens:

Probabilities for finding one Bitcoin block

The blue probability line shows the incremental probability of finding a block at a given time. This might seem a little strange until we look at the red, cumulative probability, line. The cumulative probability indicates how likely it is that we already found a block by a given time, so the blue line makes more sense. As time progresses it’s more and more likely that we already found a block so the number that will be found after a long time reduces significantly.

In the Bitcoin network our mean block finding time is 10 minutes, but by the time we reach 10 minutes there’s a better than 63% probability that we’ve found a new block, not 50%. In fact 50% of blocks have been found within 415 seconds (just under 7 minutes).

The 37% of the blocks, that take longer than 10 minutes, can take a very long time to find! At an hour we’ve still not found a block a little less than 0.25% of the time; that means that typically 1 block in 401 will take more than an hour to find! There are a few subtleties to this particular number but we’ll come back to those in a little while.

If, like me, you find the 1 in 401 number was something of a surprise (that’s about once every 2.8 days on average) then it’s perhaps worth looking at some gaps between blocks. In the 12 day period up to 2015-02-05 (when the data was captured) I quickly located 5 blocks that took more than an hour to find! The number might be higher as I was doing this manually by checking a blockchain explorer. For the record these were 340450 (77 mins), 340521 (63 mins), 340544 (67 mins), 341727 (60 mins) and 342002 (72 mins). Three of these occurred in a single 24 hour period over the 25th and 26th of January.

6 confirmations?

If a single block can take so long to find, what about the 6 blocks that we need for many simple Bitcoin clients (SPV wallets)?

Probabilities of finding 6 consecutive Bitcoin blocks

We’d certainly expect that things will be closer to our anticipated 10 minutes per block and that is indeed the case. 50% of the time we’ve found 6 blocks by 3400 seconds (a little under 57 minutes). At 60 minutes we’ve found about 55% of blocks. A surprise, however, is that in 10% of cases it takes more than 5560 seconds (more than 1 hour, 32 minutes) to find 6 blocks; in 1% of cases it takes more than 7870 seconds (2 hours, 11 minutes)! On the flip side of this though, in 10% of cases we get all 6 blocks within 1890 seconds (a little under 32 minutes) and in 1% of cases we have all 6 within 1070 seconds (just under 18 minutes).

The network isn’t static!

So far none of the results we’ve seen should come as anything of a shock to anyone who understands the statistics assoicated with a Poisson process. The real Bitcoin network is somewhat more subtle though because it is really a non-homogeneous Poisson process; underlying hashing capacities change throughout each difficulty period of 2016 blocks. If we start out at, say, 300 PH/s but add 0.2% new capacity every day, then after 14 days (a little more than the 2016 blocks take) we’d have 308.5 PH/s. That means that towards the end of the 2016 blocks we’re actually going to see blocks found more quickly than at the start. In addition, as we saw in “Lies, damned lies and Bitcoin difficulties”, the nominal hash rate calculated at the end of each difficulty period lags about a week behind the current hash rate.

The 0.2% increase per day isn’t a completely random number; it’s a good approximation to the underlying trend for the last couple of months. Comparing this and the “ideal” numbers where there’s no change in the network’s hash rate we can see the following:

Comparison of probabilities for finding a Bitcoin block with 0% and 0.2% per day hash rate expansion

The difference isn’t all that great. Our mean block finding time is closer to 9 minutes 45 seconds, while our mean time to see a block take an hour or longer increases to once every 480 blocks.

What about more extreme changes in hash rate?

A hash rate increase of 0.2% per day doesn’t have much effect, but what about 2% per day? 2% seems like a huge number based on recent months, but was quite common in the earlier part of 2014. At the same time as considering positive increases it seems worth considering negative changes too.

A +2% per day change corresponds to a nominal 24.8% increase in hash rate over 2016 blocks and takes about 11.2 days. The rapid increase causes us to find blocks very quickly and thus readjust the difficulty quickly. A -2% per day change has a much larger impact, however, because our 2016 blocks end up taking nearer to 21 days. This would correspond to a hash rate reduction of 34.6%.

The following curves assume a steady state change, i.e. what would happen if we’d been seeing a steady +2%, 0% or -2% change in the previous difficulty period too. As such these are more extreme that we would see in the first difficulty period for which the change was occurring; they do match a second or subsequent period:

Probabilities of finding a single Bitcoin block under -2%, 0% and +2% daily hash rate changes

During our +2% expansion we see a mean block time closer to 8 minutes, but with a -2% contraction the mean moves closer to 15 minutes!

Now let’s look at the same behaviour for our 6 confirmations:

Probabilities for 6 Bitcoin blocks being found during -2%, 0% and +2% hash rate changes per day

As we might expect, the pattern for a single block is mirrored for 6 blocks.

Final thoughts

The Bitcoin design is surprisingly well adjusted for a network in which hash rates are expanding. Given that technologies continually improve then that’s probably the right bias as a normal schedule of replacing older, less power efficient, hardware with newer, more power efficient models will tend to see global hash rates increase.

On the surface it looks like it works much less well when we see steady contraction of the global hash rate, but such contractions are much less likely. In general miners will remove their least power efficient hardware from the network rather than their most efficient, so if the BTC price reduces the impact on the hash rate is significantly dampened.

There is another interesting aspect to the reduced block finding rate. One of the theories about the recent decline in the BTC price is that a lot of the downward pressure comes from miners selling newly-mined coins. If miners start to unplug hardware and the block finding rate falls then some of this pressure will also reduce because fewer coins will be being mined each day. Whether this actually happens or not may be an interesting indicator of what might happen when the block reward halves in 2016.

---

Source code

The source code for the simulation tool that generated the results for this article can be found on github at: https://github.com/dave-hudson/waiting-for-blocks

---

Bitcoin traffic bulletin (redux)

By Dave Hudson

Posted December 20, 2015

In November 2014 I wrote an article, “Bitcoin traffic bulletin?” that sought to look at what happens if the Bitcoin network started to get congested. Since then there has been considerable debate about the Bitcoin block size and there are now many proposals to increase block capacity.

In the original blog post the network’s block capacity was at about 30%. As of early December 2015 the network’s block capacity is at least 58%. In practice some blocks are mined smaller than the full 1M bytes that could be used (see “The myth of the megabyte Bitcoin block”) and so we may have more block capacity being used:

Effective block sizes over time

The simple Monte Carlo simulation from that earlier post models the effects of loading on first transaction confirmations:

Probabilities for the time to a first block confirmation with the Bitcoin network at various load levels (log scale)

During 2015 we have seen a few attempts to generate “stress tests” that spam the Bitcoin network with large volumes of transactions. In each instance transaction confirmation times were seen to increase, and arguably fees increases to match. This suggests that the network can adapt reasonably well, but service was certainly affected, not least because transactions with small fees could be almost indefinitely delayed.

---

How segregated witness is not the same as bumping block size limit

By Oleg Andreev

Posted December 22, 2015

“Segregated witness” (“segwit”) is a proposed feature to improve transaction mutability, enable smooth script upgrades and double Bitcoin capacity by moving signature scripts out of the transaction inputs into a separate data structure committed to a block using a new rule compatible with older nodes.

Bumping block size limit is a hard fork: first, everyone must agree to follow new rules, then everyone willing to verify a payment to themselves has to download and verify bigger blocks. So a minority of less-powerful miners and/or recipients is out of luck: they have to beef up their bandwidth and CPU resources or disconnect from the network. This is how “hard fork” works.

Segregated witness, among other things, increases capacity of the blocks without forcing everyone to validate bigger blocks. If you expect old-style transactions, you can still validate 1 Mb base blocks as you always did. However, if you wish to accept payments using segwit transactions, you have two options: 1) either validate additional data (that is, loading and validating all segregated signature scripts that do not fit into base blocks); 2) or trust majority of miners to validate these for you, then you can validate only base blocks ignoring segwit data, or even just use SPV proofs.

Segregated witness can only be used safely if the super-majority of miners enforce it. This can be done in two ways: validating segwit transactions according to the new rules, or not mining segwit transactions yourself and only trusting other miners to mine segwit transactions correctly (see below on why it’s not a huge security hole).

If you are a miner with sufficient resources, you can fully enforce and validate segwit transactions at the expense of larger consumed bandwidth and higher CPU consumption.

If you receive payments and have sufficient resources, you can accept both old-style and segwit transactions doing full validation yourself (at the expense of higher consumed bandwidth and higher CPU consumption).

If you wish to receive only old-style transactions, you can safely ignore all extra overhead of segwit transactions.

If your resources are very constrained, you can opt into accepting old-style transactions at old costs and using SPV proofs (trusting miners) to validate segwit payments. You may choose supporting segwit transactions for lower-value payments and require old-style transactions for higher-value payments if you only can afford old-style validation.

If you are mining with constrained resources, then you may resort to not mining segwit transactions at all and trust other miners to validate segwit transactions (if any) correctly. You can validate old-style transactions at no extra cost. Why can you trust others not to mess with you? It’s easy. Imagine some miner with 20% hashrate directs half of their hashrate (10%) to create blocks with invalid segwit data. They make you lose 10% of earnings, but they themselves lose 50% of their income because half of their blocks are invalid. The cost of attacking a constrained minority of miners is hugely asymmetric: large-scale attack makes the attacker run out of money much faster than the victim.

As a result, segwit allows scaling Bitcoin capacity in a opt-in way. Those who want to take advantage of extra capacity need to expend extra resources, but those who do not want to use the feature (no matter how small that minority is), do not need to expend any extra resources at all. Therefore, censorship-resistance property of Bitcoin remains unchanged.

---

An historical timeline of The Real Bitcoin (TRB) development, part i.

By Pete Dushenski

Posted December 25, 2015

On October 10, 2014, on the well-intentionedⁱ premise that more relay nodes would mean a healthier, more robust, and more reliable Bitcoin network, I whipped up alittle guide for setting up el cheapo AWeSque nodes. How easy, how simple, how innocent, no ?ⁱⁱ

At the time, the Vessenes Phoundation was promoting their version of the Bitcoin reference code, which they called “0.9.x” or “Core,” but which was widely known to be at best a laughingstock and at worst a very marginal improvement on webwallets.ⁱⁱⁱ But while the old Foundation’s jig was up and their puerile pretenders to the throne were literally tripping over themselves to lie to Bitcoin users in an attempt to subvert this world-eating little project, the emerging Republic calling #bitcoin-assets home lacked a reference implementation to call its own. Each individual member carefully guarded their homebrew concoctions with all the shrewdness of poker players in an old Western Saloon, leaving the hows and whys of each stack almost entirely unknown, even if theories swirled.

With this in mind, my $20 node guide^iv was never intended to be the final word on the matter, but rather a stop-gap measure that at the time seemed better than nothing, being predicated on the not-overly-ridiculous-sounding-notion that someone, somewhere in my WoT had a decent reference implementation (and that they’d be willing to share) that I could just plug in, press the big red LAUNCH button, watch the thing build in a flurry of lines whizzing across the terminal screen before kickin my feet up on the desk, breathing a sigh of satisfaction, and then deciding if I wanted to spend the next hour shoveling snow or reading poetry or something, all the while smugly content in the knowledge that I was supporting the Bitcoin network.^v Oh, the innocence of youth… and how dubious this all seems in hindsight !

Needless to say, this reference codebase thing wasn’t quite so simple.^vi Fast forward to today and we’re still here, still glued to our chairs as the since-established Bitcoin Foundation (the Real one) hacks away at Satoshi’s codebase, getting ever-closer yet paradoxically ever-further from their objective, all the while trying to hygienically remove as much stupidity / FOSS as possible while keeping the important bits ticking.

This is their story :

October 21, 2014: Bitcoin 0.5.3 selected by Mircea Popescu^vii

After Ben Vulpes sifted through the history of Bitcoin’s development from Satoshi to Phoundation, the call was made to select a development branch upon which to base future efforts.^viii The balance of considerations saw 0.5.3 selected, with cutting edge features like encrypted wallets (ooh! ahh!) being included and obvious prole-related nonsense like support for “click-to-pay” being eschewed. That the 0.5.3 branch was far from perfect was no mystery, but it was the tallest midget so to speak.

October 22, 2014: The (Real) Bitcoin Foundation established

In order to guide this process as formally and as professionally as possible, Mircea Popescu selected Shane Kinney^ix and Ben Vulpes^x as co-chairs and Juraj Variny^xi as treasurer for the newly formed (Real) Bitcoin Foundation, an organisation tasked with taking the 0.5.3 turd and polishing it into something resembling Anish Kapoor’s Cloud Gate in Chicago, except useable and meaningful.

While Mr. Kinney and Mr. Vulpes were tasked with guiding and moderating development of The Real Bitcoin (TRB), patch submissions have always been open to anyone in assbot’s L2 WoT. As you’ll see, this is an important consideration, not the least of which because it’s the opposite of the FOSS^xii approach that rendered the reference software so mangled in the first place.

The Real Bitcoin Foundation’s charter is found here.

October 24, 2014 : Qt excised by Stanislav Datskovskiy^xiii

With “chicken,” the first scruffy feathers to be plucked from the frankly fetid corpse of 0.5.3 was Qt, which was the basis for the program’s Graphical User Interface (GUI). Qt uses C++ with signals and slots^xiv to provide a cross-platform application framework. for, essentially, illiterate amateurs.^xv~~~~

As Qt introduced weight and complexity to the code, both mortal enemies of security and “fits in head,” philosophically as much as practically, Qt had to go. Bitcoin, after all, is for professionals and this first excision was telling of this fundamental reality. What remained after the excision of Qt could more properly be called “bitcoind” once again as it was accessible exclusively via the command line interface, as you do.

October 25, 2014 : UPNP excised by Ben Vulpes

With the “rm_rf_upnp” patch, Universal Plug and Play (UPnP) – which allows inter-device networking and communication but in doing so creates a security vulnerability – was plugged. The issue with UPnP centres around the “libupnp” library – that is, the Linux Software Development Kit (SDK) that provides “developers” with an Application Programming Interface (API) and open source code for building control points, devices, and bridges – and in which multiple buffer overflow vulnerabilities were widely recognised, even by the US Department of Homeland Security. (N.B. If something isn’t good enough for the enemy, it’s a pretty damn good bet that it won’t be good enough for the Republic.)

October 28, 2014 : HTTPS/SSL excised by Stanislav Datskovskiy

With the “https-snipsnip” patch, the vulnerability that exposed the Bitcoin network to Heartbleed via Public Key Infrastructure (PKI) was removed.^xvi OpenSSL is a cryptographic library that enables Secure Sockets Layer (SSL) or Transport Security Layer (TLS) encryption across the web. In theory, this is both a “cost-effective” and “industry approved” method of encrypted communication. In practice, however, the project was subverted sometime in 2012, if not sooner, and no amount of rubber-stamping could prevent the stench of roadkill from betraying the true state of the library, viz. unknowably large and impossible to trust.

Given that Mr. Datskovskiy is on the record as calling out this turd way back in 2013, it’s little wonder he was the one to pull the trigger here.^xvii

October 29, 2014 : Win32 excised by Stanislav Datskovskiy

With the “goodbye-win32” patch, the swiss cheese mousetrap that is Microsoft’s Windows operating system was trimmed from the reference implementation. This should really require no further explanation other than fuck Bill Gates.

October 30, 2015 : Upgrade warning excised by Stanislav Datskovskiy

With the “turdmeister-alert-snip” patch, the old-fashioned, out-dated “upgrade needed” warning message from USGavin et al. was put on the chopping block.^xviii The idea being that The Real Bitcoin will eventually be whittled into a weaponised implement of such robustness that it would never need software updates,^xix certainly not those “recommended” by Central Command.

December 19 2014 : DBD parameters set by Shane Kinney

With the “db_config” patch, the wedge issue at Block 252450 was overcome. The ram exhaustion wedge was apparently caused by less than ideal Berkeley DB (BDB) configuration settings. BDB is a relatively simple-to-use database management library that’s used to keep track of Bitcoin transactions.

[To be continued]

---

1. Yes, the road to hell is undeniably paved with good intentions and quadruply so when you have the good intentions of others in mind, with evil squaring further still as a function of distance between you and the intended recipient. So ya, mind your own fucking business ! Ya bunch of fucking wreckers… Oh, you “just wanted to” ? Shut up and get back in the kitchen. What is this, a democracy ? And no, I don’t give a shit if you fancy yourself “a guy who doesn’t do kitchens,” stop being such a sexist tard and find a worthwhile cock to suck already. You’re not getting any younger, you know.↩
2. This was itself motivated by an article I’d penned just a few days prior, specifically : The biggest challenge ahead isn’t “bringing Bitcoin to the people” or some such nonsense, it’s in maintaining a sufficient number of nodes to relay and verify transactions. This is challenging issue that has yet to be fully addressed. But hey, we need something to do in 2015 once all the derps are dead, y’know? Which was itself informed by a comment to this effect by Mircea Popescu, which was itself informed by Gavin Andresen’s idiocy, which was itself informed by Gavin’s mother dropping him on the head as a child, etc., etc., ad infinitum. Little did I, or anyone else, suspect the magnitude of the task at the time… perhaps Alf notwithstanding.↩
3. This open secret was due in no small part to the at-the-time-recent Heartbleed OpenSSL vulnerability that Mike Hearn surreptitiously inserted into version 0.9, only to have his efforts blown apart by Riku, Antti and Matti of Codenomicon (“independent” and “simultaneous” discovery of the bug by Google Security my ass !) But what was the big deal with Heartbleed and OpenSSL ? Well, we’re getting to that
4. Also at the time, $20 was about 0.05 BTC and would just barely cut the mustard. Today, even with BTC trading for about 30% on the exchanges, you’re looking at about 0.18 BTC to run a node. That being said, Bitcoin’s due for another bounce-and-resettle, so 0.05 BTC per year is likely a reasonable rate going forward, which means that, yes, if you can’t afford that, you can’t afford to be in Bitcoin. ↩
5. Why did I want to support the Bitcoin network in the first ? Why not just be a free-rider and coast off the accomplishments of others ? Well, my personal reasons were, and still are, two-fold : i) It’s in my rational self-interest to do so, and ii) If you can, you must, and I figured that I could.↩
6. See this conversation, which took place shortly after I tried and failed to follow my own recipe : mircea_popescu: pete_d you really should know better than taking bitcoin “foundation” shit at face value yo. asciilifeform** read the published script, sees nothing to verify installation of particular known-hygienic classical ver. of bitcoind **pete_d:** This i know ! Any suggestions for how to remedy this ?? **mircea_popescu:** Nothing good short of running some decent nodes. **pete_d:** And where might I find the scripts for this? **mircea_popescu:** For running a node you mean ? **pete_d:** 0.9.3 is obviously dirt but how would one go about installing 0.6.x on a VPS ? **mircea_popescu:** Well you get the code off the repository and compile it. Or if you trust anyone, you get a binary from them. **pete_d:** The instructions in my “guide” definitely need improvement. Currently point people towards latest bitcoind as per pankkake’s script. **mircea_popescu: Generally the people involved in Bitcoin to this level kinda have the history, and a complete file of historical versions and so on. I guess it’s an interesting question, “What’s the new guy to do”. Bunch of playing catchup it seems. asciilifeform: n00b, as in any serious business, must apprentice to another. Or make good friends with the nuts and bolts alone, for ages. pete_d now accepting offers for binary of bitcoind 0.6.x for Contravex guide. mircea_popescu: But actually his is a legitimate request. I guess I’m adding this to the “wanted maintainer for eulora binaries” thing : wanted maintainer for bitcoin binaries. Anyone want to do a bunch of compiling and sign stuff ? And so it began. Of course, since the lathe dog is a more notable player in this saga than I could ever hope to be (as you’ll readily observe from the sheer volume and quality of patches he’s thus far submitted to TRB development) his open order for a printed and bound volume of the 0.6-era source code is commonly regarded as the first cause in The Real Bitcoin’s development, even though it took place some 10 days *later, and only after much collective stumbling around in the dark and pawing at the edges of the iceberg that is modern general purpose computing… But hey, we could point to specific causes and their causes and their causes all the way back to infinity and we’d just end up at that Douglas Adams line about the creation of the Universe and how it made a lot of people very angry and was widely regarded as a bad move. __ __ *You may recall pankkake as being he of “OMG YOU GUISE R A CULT” fame.↩
7. mircea_popescu is identified by PGP Fingerprint : 6160 E1CA C8A3 C529 66FD 7699 8A73 6F0E 2FB7 B452↩
8. Update : MP can be credited with his selection of the “no later than 0.6.x branch” as early as February 2014 December 2013 (h/t to Alf!) May 2013 (!).↩
9. mod6 is identified by PGP fingerprint : 027A 8D7C 0FB8 A166 4372 0F40 7217 05A8 B71E ADAF↩
10. ben_vulpes is identified by PGP fingerprint : 4F79 0794 2CA8 B89B 01E2 5A76 2AFA 1A9F D2D0 31DA↩
11. jurov is identified by PGP Fingerprint : BBB0 A999 5003 7551 F533 850A 677A BD62 D0AE E7D7↩
12. Free and Open Source Software.↩
13. asciilifeform is identified by PGP fingerprint :1721 5D11 8B72 3950 7FAF ED98 B982 28A0 01AB FFC7.↩
14. Signals and slots work a bit like a spreadsheet in that certain objects auto-update when other objects that they’re linked to are modified.↩
15. A little birdy tells me that Qt isn’t just for illiterates, but is unfortunately, “the ~only~ remaining working cross-platform native-widget graphic lib for cpp.”↩
16. The issue with PKI is that it requires “Certificate Authorities”, ie. third-parties who may or may not have your best interests at heart, and whose opinion of you may change over time. For obvious reasons, then, PKI is a political tool rather than a security tool and therefore has no place in sane personal computers any more than your national army does.↩
17. From “Don’t Blame the Mice,” September 2013 : Let’s go back to your kitchen. It is squeaky-clean, you say, because nowhere in your house do you make use of Microsoft’s miserable imitation of an operating system. Guess what, the mounds of garbage are still there, stinking brazenly; the mice leap, they play without fear, because virtually all of your cryptographic needs are serviced by some variant of OpenSSL. What a monstrous turd of a library! Have you read and understood it – any of it? Do you personally know a single living soul who has done so? Dare to contemplate the very idea of plowing through these megabytes of gnarly crapola. ↩
18. “WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade” from out of the blue ? Pfff. No thank you. That being said, “InvalidChainFound: WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.” is still in place as a warning in TRB.↩
19. Even if hard drive updates are inevitable as the blockchain grows ever more voluminous.↩

---

Salvaging the Blocksize Discussion, in Two Questions

By Paul Sztorc

Posted December 28, 2015

A recipe for productive conversation.

Well, here they are:

The Magic Discussion Template

1. “Why do you think we have a blocksize?”
2. “What has changed, between the time that the blocksize was introduced (July 15th, 2010), and today, which motivates us to make a corresponding change in the constraint?”

Now, if everyone just makes an extra effort not to be a sore winner, the crisis will be solved!

You’re welcome!

Now, I guess I’ll explain about those two questions in greater detail.

Motivation and Background

Because of the way Bitcoin is designed, in-fighting is inevitable. In fact it will be getting worse. Those who understand this problem can, at least, feel better about it.

A Lost Cause

I don’t expect this post to help very much. The debate is already over, and everybody lost. We’re full tribalism* on this issue; anyone who pokes a curious head into the conversation is mind-killed immediately and with extreme prejudice.

Nearly everyone is doing exactly those things which should be avoided (assuming bad faith, stonewalling, outright coercion/death-threats). Worst, those who were originally happy to not have an opinion, are now “selecting” an opinion, just to defend their friends and allies.

• I can already see my inbox and comments section filling up with “praise” from people who think that I am in their tribe, and ““criticism”” from people who think that I am not in their tribe. It’s a sad state of affairs.

Why Write This?

My only purpose here, is to comfort those who are frustrated. I hope to explain why the blocksize conversation is so horrible, and help move it forward.

If you aren’t interested in that, now’s the time to navigate elsewhere.

Background: Zero-Sum Games, Software Forks, and Bitcoin

Zero-Sum Games

A “zero-sum game” is a term in game-theory, referring to a situation where “you doing well” is indistinguishable from “your opponent doing badly”. Examples include: two guys who are romantically interested in the same girl, two politicians competing for the same office, a race where only one person can come in 1st place, etc. These ZSGs are brutal; your opponent has every reason to try to make you do worse. This permanent, unalterable antagonism can be a very distressing experience. Why - even your success is dangerous, as, if you are currently winning, your opponent may become more desperate and more unpredictable.

too funny to print Just axe Leon Trotsky. /*rimshot

Software Forks

Open source software is (mostly) liberated from this dark reality, thanks to the ability to ‘fork’ the software. If you don’t like something - anything - you can change it! A fork is the opposite of a zero-sum game: instead of conflict being unavoidable, conflict is completely impossible.

Bitcoin

But, here’s the bad news: Bitcoin’s design does not allow software forks, at all. It does allow “upgrades”, and we have labeled these upgrades “soft forks” and “hard forks”, but these phrases do not actually refer to the split of one project into two. Bitcoin is designed to take many, many, possible forks (one per miner) and use the ‘heaviest chain rule’ to select the - The - single block to be the only valid one. There can’t be two blockchains…by definition. The project can’t split.

If Bitcoin ever did split, for any reason, we’d either have [1] an unexpected and instantaneous doubling of the money supply, or [2] the reversal of an arbitrary subset of transactions. Both are terrible not-Bitcoin-ness.

Hard Fork = Conflict

Bitcoin (despite being open source, and despite being on GitHub), is a zero-sum game. XT’s success is Core’s failure. The stakes are high – the two cannot coexist.

Until we have sidechains, of course.

Background: Why Does Bitcoin Have Limits, Anyway?

To invoke von Mises: “human action is purposeful action”. Why would someone purposefully choose to take an action which limits his/her future actions?

A Contract is a Mutual Limitation

Bitcoin is a protocol, or ‘set of rules’. Every ‘rule’ everywhere is, of course, a limitation or constraint. It harms our ability to “act purposefully”. This ‘binding’ of everyone in the Bitcoin Network under the same, agreed-upon rules, gives each of us less autonomy (we can each do fewer things); however, we can more easily work together (our expectations of others are more reliable). For example, I “give up” my “right” to create 50 million Bitcoin out of thin air, but you give up that right as well. As a result: no counterfeiting.

By definition, every one of Bitcoin’s rules is an inconvenience – something obstructing our individual puposeful action! Obviously, we tolerate these inconvenient rules because they themselves serve some purpose in helping us work together.

First Half: What is a Blocksize Limit, anyway?

The biggest stumbling block so far.

It turns out, surprise surprise: people don’t agree on “what a blocksize limit is”.

This is a big problem, because if we can’t talk about x at all, then we certainly can’t use conversation to compare different versions of x to see which x-version is the best.

boring, belongs elsewhere A general recipe for success, then, would be to: 1. Agree on the definitions (including our definition of “should”, ie our “objective”). 2. Agree on the relationship between our defined terms and our objectives. Typically this is done by ‘analysis’, ie by breaking concepts down into smaller / easier-to-understand (but slower and less-generalizable) sub-concepts. 3. Select the action which most-achieves our objective.

So, below, I present: the Common Blocksize-Arguments, grouped by Flavor.

By ‘flavor’, I mean the core assumption of the form “the blocksize exists … [ reasons ]”.

Note: I have changed the word ‘Camp’ to ‘Flavor’, because it is more obvious that a person can not be a ‘Flavor’. Flavors are for arguments, Tribes are for (unlucky) people. Tribes != Flavors == Camps. I regret using the word Camp, as it was unclear, and primed people to react defensively. I have made minor edits (viewable on

GitHub

) to emphasize this difference. It is a confusing topic, because each individual should care most about one single Flavor, at which point they could be said to be, for example, “in Camp D”.

Notice that it is the arguments which come in flavors, not their arguers. Someone who is particularly unwary might accidentally mix all kinds of Flavors together, unaware of their potential for logical inconsistency. ( This is not to be confused with the concept of ‘caution’, where someone is knowingly concerned about multiple things at once. )

What is a blocksize limit?

Help me end the madness:

Flavor A: It isn’t anything (not anything useful, anyway).

Sample Arguments

This flavor includes phrases such as:

• “We must raise the limit, because we are about to hit it!”
• “We don’t have time to try anything else [Lightning Network].”
• “7 transactions per second isn’t enough to compete with VISA!”

As well as:

• “The soft limit imposed by individual miners will work just fine.”
• “The blocksize limit will never be a binding constraint, anyway.”
• “Let the free market (“something else”) determine [transaction fees / the block size].”

It does not include an argument of the form:

1. We are about to hit the limit.
2. Hitting the limit is bad.
3. We should do something to avoid hitting the limit (options include: rewrite wallet software, warn users, increase limit, …).

Implications

Flavor

A necessarily implies that the blocksize limit should be removed altogether.

Flavor B - It Stops Validators from Being Robbed by Users

Each Bitcoin transaction needs to be..

• ..routed to all of the full nodes (“validators”) in the network.
• ..independently verified by each full node.
• ..stored forever by each full node.

In other words, Bitcoin transactions aren’t free.

Who should pay for them? Clearly, the user (ie “they who wish to transact”). The problem is that miners get 100% of the transaction fees, but do not need to pay all of the bandwidth or storage costs (in fact, some miners don’t even pay the validation cost).

( For Full Nodes, it is actually reversed: they get 0% of the transaction fees, but must pay all of these costs! )

Sample Arguments

The

Flavor

B arguments include:

• “The number of full nodes has been falling.”
• “It will be too difficult for X to run a full node.”
• “More individuals will resort to light-clients.”

And so forth. It does not necessarily contradict the premise that a blocksize increase could cause a higher quantity full nodes (by, perhaps, causing greater interest in Bitcoin).

Implications

This Flavor, to be logically consistent, concludes that the blocksize limit should increase when “running a node” becomes easier. Correspondingly, Flavor B concludes that the limit should decrease, when/if running a node becomes too difficult.

It seems that this Flavor’s ideal blocksize limit (IBL) would be primarily driven by the availability of bandwidth, and by improvements in hardware (fiber / CPUs / hard drives) and by improvements in the software which utilizes that hardware.

SubFlavor B2 - Selfish mining / block-propagation

This flavor emphasizes the validation performed by miners. Specifically, these arguments emphasize that miners will be unable or unwilling to validate properly (and that this lack-of-validation is bad).

For B2, any technology which improves block propagation (improved bandwidth, the miner relay network, “weak” blocks, IBLTs, …) would favor a higher IBL.

SubFlavor B3 - O(n^2) Fundamentalism

The B3 Flavor implies that everyone is running a full node (or needs to be able to do so). From this, it is clear that each new Bitcoin user (n) will receive payments at a full node, and all other nodes (* (n-1)) must also receive, validate, and permanently store the transactions sent to this new node (in contrast to, for example, the lightning network, where this is not a requirement).

Someone invoking B3-flavors, may be interested in new technology (ie, ‘fraud proofs’ enabled by segregated witness, ability to quickly compare reports from different full nodes, resistance to Eclipse attacks, zk-SNARKS) that enables users to trust full nodes which they did not create. However, such individuals may also reject these technologies as insufficient substitutes for a full node.

B3 will always tend to advocate a very low blocksize, as, from principles of mathematics, we know that f(n)=n^2 reacts explosively as n increases. However, individuals can be expected to leave B3 if/when Bitcoin’s adversarial environment changes. For example, if the entire world uses only Bitcoin, few would be interested in attacking it and SPV security would probably be fine.

Flavor C - It is a Stabilizer

Some believe that the Blocksize limit removes fluctuations from Bitcoin’s state. This belief is associated with questions like:

• “What would happen to transactions fees in the absence of a blocksize limit?”
• “Without a limit, how will we fund Bitcoin’s security in the future?”
• “When transaction fees dominate the miner reward, how can we ensure that mining continues ‘when the sun is over the Pacific’?”

And tends to be associated with the phrase “constant backlog of transactions”.

Implications

A C-Flavor would tend to support a blocksize which slowly and continually increases, until problematic fluctuations arise, or are expected to arise (at which point the limit is halted or decreased).

The IBL of Flavor C would be driven by..

1. ..demand for BTC transactions, (which is in turn driven by “substitutes” [off-chain alternatives, altcoins, …] and “compliments” [SilkRoad, JoyStream, …]).
2. ..improvements the technology which manages payments (fee-aware / fee-minimizing wallet software, lightning network).

As these drivers improve, we can have a higher IBL without the risk of severe fluctuations.

Thus, Flavor C is more focused on the long term, and those who take arguments from Flavor C are likely also to borrow from other Flavors.

Flavor D - It represents Decentralization / a Contract (and must be upheld, on Principle).

If Bitcoin’s rules can be changed by someone, then what matters isn’t the rules themselves, but the people who control these rules. Some arguments object to this, implying that things are inherently better for Bitcoin if no one is in charge.

For example:

• “People need to change themselves to fit Bitcoin, not the other way around.”
• “It is the policy of X Organization not to support any ‘contentious’ hard fork.”
• “Developers at X are controlled by Y corporation or agents of Z government (and we don’t want them in charge).”
• “We want hard forks to be rare/difficult.”

Implications

Flavor D would lose relevance if the decision-making process became more transparent (or longer, and more difficult to subvert), or, perhaps, if Satoshi reappeared (or new info was learned about his design).

However, Flavor D rarely, if ever, allows the blocksize (or anything else about Bitcoin) to change. Perhaps the sole counterexample would be an existential threat: if Litecoin, or Ethereum, ever grew so as to be taken seriously, this might persuade Flavor D aficionados to rethink the relevance of the social contract, and increase the blocksize.

SubFlavor D2 - “Moral Hazard” / Antifragility

Some people try to avoid doing things “the easy way”. There’s some wisdom to it: “the crutch begets atrophy”, “comfort is where we stop growing”, “necessity is the mother of invention”, and so forth.

Arguments in D2 ask: would we ever have heard of the Lightning Network (or Segregated Witness, …) if the blocksize had simply been raised earlier this summer (as many advocated)? Certainly, as the need for Lightning Network diminishes, it becomes less and less of a development priority (and you become less famous for having invented/worked on it). It is possible, as with the US Debt Limit, that the quick-and-easy thing (raising the limit) is consistently chosen over the more-difficult, more fundamental changes.

Implications

D2 would want to stall all “easy changes” (of any cost, no matter how small or ambiguous) while: [1] good ideas are still being worked on, [2] good ideas are still being theorized and introduced regularly, and [3] there exists a shortage of good developers.

Part Two: Using the Blocksize

If the blocksize acts to help solve problem X, then we simply move the limit up as problem X becomes less relevant, and down as problem X becomes more relevant.

Relationships Between Concepts If the purpose of ‘a jacket’ is to keep you warm, then you know that “Do I need my jacket?” and “Do I need to keep warm?” are related. If you don’t leave your house, or if the weather outside is already warm, then you don’t need the jacket! However, if the purpose of the jacket is because it is a badass leather jacket that makes you look fukin’ awesome and women will be falling over themselves to sleep with you if you wear it to a bar, well, then the questions “Do I need my jacket?” and “Do I need to look good?” are related. If you have the flu, or aren’t going to a bar, then you might not need the jacket. #### What do you want? It’s like any other recipe: if you have [1] the inputs [2] the relationship between the inputs and the output, then, you can swap those inputs for an output!. If you have peanut butter, jelly, bread, a knife, a plate, paper towels, … and you know what to do, then you can make a pretty mean PB&J sandwich! The blocksize debate is so messy because of [2]. As I mentioned in my Montreal talk, this is often because we haven’t even stated (let alone agreed on) what the output should be!

Example

Let’s assume that Satoshi introduced the blocksize limit “to prevent an attacker from DoS-attacking with a large block”.

Well, if that’s true, we would now ask “Is the Bitcoin network still vulnerable to the use of a large block in a DoS-attack?”.

• Since the blocksize served a specific purpose, a statement like “But we are about to hit the limit!” is irrelevant, as is “But we need to fund network security in the future!”. The network is either vulnerable to DoS-attacks or it isn’t.

Then, we would continue: “Is the Bitcoin network (effectively) 8 times less-vulnerable today, than it was when Satoshi inserted the limit?” If the answer is yes, then the limit can increase from 1 MB to 8 MB.

• Not only did we settle on a purpose, but, we have an implied goal, which is “a network which is resistant to DoS-attacks”. Maybe, you don’t want “a network which is resistant to to DoS-attacks”. Instead, you may want “a high quantity of Bitcoin nodes”. If so, you may reject the above conclusion.

At this point, you may want to begin a new argument. For example: “a larger blocksize may cause more people to be interested in Bitcoin, which will more than offset the decline in some people’s ability to …”

This, however, is precisely what derails the conversation and makes it confusing.

Trade-offs

You see, there are some changes which don’t hurt anybody. No one cares about those. They are “uncontroversial”.

However, Actual Important Discussions are always about trade-offs: they help X, by hurting Y.

If you want X, and someone else wants Y, then nothing can really be done. Hopefully, you can both at least agree that “pointless argument” is a waste of both of your time, and that you can “agree to disagree”, and that you should peacefully go your separate ways (but…if one of you refuses to drop the argument, you are mortal enemies and one of you will eventually have to violently destroy the other; it is a sad reality of our imperfect universe).

So, if someone wants “a high quantity of Bitcoin nodes” and someone else wants “all Bitcoin nodes to be cheap” and someone else wants “cheap payments” and someone else wants “high transaction fees”, these people really have nothing to say to each other.

Just take out your machine guns and get it over with!

Or, search for common ground: As I presented in Montreal, I suggest that the Bitcoin Exchange Rate be the common ground.

Or, best of all, search for a better way of doing things, one which eliminates the trade-off: the sidechain.

Bottlenecks

Nothing prevents someone from using arguments from several Flavors at once (unless they draw from Flavor A, of course). After all, you can wear a leather jacket for more than one reason: to look stylish and to stay warm on a cold day.

If two blocksize-purposes are equally relevant, then the blocksize limit can only increase when circumstances have improved in both areas. You’d need it to be a warm-enough day, and you’d need to be not-interested in looking stylish (perhaps because you have the flu or something).

However, at each point in time, we can expect one single constraint to be the most constraining…the “bottleneck” constraint. So, while one can mix flavors, one flavor should dominate. Someone who predominantly uses arguments from a single flavor, for example Flavor D, could be said to be “in Camp D”.

Final Thoughts

Politics, the eternal science, the terminal brain-disease to which all eventually succumb.

It isn’t a tech problem.

All changes to Bitcoin require carefully-crafted, high quality code…written and reviewed by the best and brightest.

Unfortunately, the problem of the community-wide hard fork concerns two additional problems: [1] “how information spreads”, which could be described as “media”, and [2] “how disagreements are resolved” which could be described as ‘governance’. They’re big problems, and there’s no reason to suggest that skilled developers or cryptographers will be any good at solving them.

Fortunately, I came up with some promising stuff already! Sadly, this first solution required a technique that frequently embarrasses intellectuals, making it a non-starter among today’s Bitcoin elites.

I anticipated this resistance, and have an uncensorable version on the way. It has been primarily delayed, in my view, by the blocksize debate itself (which has derailed progress on sidechains). Once it is on, we shouldn’t need to worry about this.

I’ve also solved this problem a second time, with the two-way peg. This one is even simpler, and likely to be popular.

If You Insist

If you’d rather “talk things out” like some kind of Communist (I am not joking.), well, I can win on that playing field as well (as I’ve tried to demonstrate in this post).

I’d be happy to moderate some kind of debate, or forum or something, to facilitate this discussion.

But I’m not sure anyone would really be interested. Instead, I think people will just try to capture the forum and use it to punish the people who insulted them.

I also doubt that it would really be helpful – if it actually concluded anything, individuals who disagreed would just de-legitimize and ignore it.

After all, I’ve already done this twice before, and no one says “This blocksize controversy sucks, we need to create the two-way peg as fast as possible!”. Instead people start with “That other guy, who insulted me, he can’t get away with this! …how could you side with them?!” and cover it up as best they can.

More Food for Thought

• In my opinion, Reddit is a highly biased and irrelevant source of information. Reddit manipulation software is cheap, and it can automatically solve captchas, down/upvote, write sentences, etc. For a single individual to control a supermajority of Reddit votes, probably costs <$100. Moreover, I estimate that /r/bitcoin accounts for a very small percentage of the total Bitcoin community (and this minority tends to be younger and less-educated). What reddit does well, I think, is aggregate and present links to websites which are not reddit. Those who make use of this useful feature, usually don’t have accounts on the site, and (unfortunately) don’t participate in the voting-feedback process.
• Its possible that Big Bitcoin CEOs want to get users away from running full nodes, and are nefariously supporting bigger blocks (after all, their service competes with node-running). Or, they are merely pandering to potential-customers (ie, the individuals who don’t run nodes).
• Its possible that most Blockstream / Bitcoin Core developers actually are very blocksize-liberal (or don’t care), but the recent gmaxwell smear campaign has reverse-motivated them to close ranks on a consistent message (and/or destroy this Threat to Bitcoin). Similarly, it is possible that BitcoinXT developers are actually blocksize-conservative, but can’t understand theymos / bitcoin.org ‘s arbitrary manipulation of the conversation, and have concluded “anything that suspicious has got to be bad”.
• Although Satoshi argued that the limit could (not “should”) be eventually removed, he did made a few claims which he later walked back, and a few which later turned out to be unreasonable. Satoshi himself inserted the blocksize limit, and he did not insert any code phasing this limit out. So his original position is very ambiguous, and I’m sure he would prefer people to stop talking about it.
• In a complex system, it is logically defensible to say “I don’t know what the rule is for, but we should keep it right where it is anyway.” In fact, civilization practically depends on this (namely, our laws).
• People choose to speak up (or not speak up) for many reasons. The result is that determining “what most people think” is very very difficult. My guess is that most individuals, and most Btc, favor a 1 Mb blocksize. Of those people who I’ve physically met, in real life, mostly at Scaling Bitcoin conferences, >50% favored keeping 1 MB blocks for many months
• The process of ‘governance’ is one which answers the timeless question: “How are disputes resolved?”. If we set a bad governance precedent today, where disputes are resolved by a tiny group of people making incomprehensible decisions, or by backroom deals, or by reddit upvotes, we will regret it in the future.

To say that “the conversation is a lost cause”, isn’t to say that Bitcoin is a lost cause, or the blocksize battle itself is a lost cause (for anyone).

In fact, at 9 PM EST today I will drink a toast (you are welcome to join me) – to the Bitcoin software, for lasting this long!

Add Disqus comments.

comments powered by

Disqus

---

Blockchain, What Art Thou?

By Dave Hudson

Posted December 29, 2015

Begin Content

Details Published: 29 December 2015

As we approach 2016 there seem to be endless discussions about “blockchain”. It’s a term that is ever-more frequently cited in even mainstream journalism, while in the fintech space alone there are a slew of would-be suppliers and would-be users claiming that “blockchain” will revolutionize any number of applications. This now-common usage suggests it must be something precisely defined and well understood, but this seems to be more a matter of mantra than comprehension.

The echo chambers of the Internet reverberate to many opinions, but attempts to find a precise meaning seem to find a dismaying lack of agreement. To be anything more than marketing hyperbole we really need the answers some questions. What is it? What isn’t it? What might it be? Can it be something that will allow us to build new and enduring systems? In short, what is the essence of blockchain?

Image: The Menai Suspension Bridge, Bangor, North Wales, UK, completed in 1826 (almost 190 years ago), demonstrates how blocks and chains can create something quite remarkable and enduring (photograph taken by the author).

The Satoshi Whitepaper

Almost every discussion of blockchains starts with the Satoshi whitepaper, but it is this very foundation that starts us on a path to confusion. Neither the terms “blockchain” or “block chain” appear there; there are 67 uses of “block” and “27” of chain, but 0 of “block chain” or “blockchain”. This aside though, let’s see where this origin leads us.

The whitepaper is short; it’s just 9 page long. The first mention of “block” and “chain” starts at the bottom of page 2, section 3, where there is a discussion of a basic timestamp server. Prior to this the whitepaper describes a series of design goals associated with the Bitcoin design such as the ability to allow two parties to transact without needing to trust a third party.

The statement of the design goals are fundamentally important. They set the scene for an implementation to meet those goals in which characteristics are layered upon each other, but it is informative to look at what each new layer does. In our quest for the nature of a blockchain we need to be careful to look for things that are its attributes, rather than characteristics of this first implementation.

Transactions

Section 1 of the whitepaper is an introduction and it is with section 2 that we see anything really substantive. Section 2 sets a scene for a digital coin, but it is described as being a chain of transactions in which the “coin” is assigned to new owners. The coin is really a metaphor for a transaction history of linked transactions.

Interestingly, section 2 also describes how a centralized system doesn’t actually need to do this.

Blocks And Chains

With section 3 we see the essence of the design pattern that might best describe the basis of a blockchain. It is given as something that is constructed from a series of incremental blocks of data, each of which can be identified by a cryptographic hash over its contents. In addition, each block incorporates the cryptographic hash of its predecessor block to ensure the construction of a chain. The block hashes are published as a form of widely witnessed evidence that demonstrate shows the existence of both the block data and the predecessor hash. Changing either the predecessor or the other data within the block would result in a different hash signatuare for the block that would not match the widely witnessed view.

These characteristics are all fundamental, and without them we cannot construct anything interesting. What is equally interesting though is what is not stated as necessary at this point. There are no mentions of coins, no mentions of peer-to-peer networks, no mentions of mining, etc. Instead the suggestion is that publishing hashes in any widely disseminated form would be sufficient, with the 2 examples being given as publication in a newspaper or publication via Usenet.

While we see some explicit characteristics these lead to a few implicit ones:

• Publication of the hashes is meaningless unless those same hashes can be independently recomputed by an external observer who is given just the data from the blocks in the chain. It is this characteristic that enables the observers to not have to trust the originator of the chain of blocks; instead they are able to compare historical hashes for themselves.
• Recomputing of the hashes requires that the algorithm by which the blocks is produced be deterministic and well specified. Without these our external observer cannot recompute the hashes.

Enabling Peer-To-Peer Operations

The next section, 4, of the whitepaper talks about proof-of-work. The first line is interesting: “To implement a distributed timestamp server on a peer-to-peer (P2P) basis, we will need to use a proof-of-work system similar to Adam Back’s Hashcash”. Proof-of-work is not required to construct a blockchain, just to enable the peer-to-peer implementation of the timestamp server. Subsequent cryptocurrency designs have shown there are potentially other approaches that can be taken here too (e.g. forms of proof-of-stake, or hybrids of both), but if we are happy with a client-server approach then none of these are actually necessary.

This is not to say that proof-of-work might not have some other uses with a blockchain design, but none seem fundamental to our quest.

Network And Beyond

Section 5 describes the implementation characteristics of the Bitcoin network. Nothing here explicitly extends the concept of what a blockchain is, or might require. Indeed, neither sections 6, 7, 8, 9, 10, 11 or 12 (the final section) go on to explicitly offer any new ideas about what a blockchain might be.

Answers To Our Questions

If the Satoshi whitepaper is the origin of the blockchain design we’re left with a rather thin definition, but perhaps that is the most enlightening aspect. It is very explicit about particular design choices and their purpose, which tends to lead towards a realization that many of the claims about “blockchains” may actually be a matter of implementation rather than architecture.

Let’s ask some specific questions then!

Must A Blockchain Have Coins?

There is an interesting discussion in the whitepaper about the need to provide incentives to those providing security to the P2P network to remain honest and as a means to introduce “coins” into the system, but the discussion is clearly in the context of the P2P network. The concept of coins themselves is noted as unnecessary with a trusted “mint”.

A trusted mint is not something desirable in a cryptocurrency, but there seems to be no requirement for coins if we wish to construct a chain of cryptographically-linked blocks. There is an interesting question to ask about trust but we will return to that later.

Must A Blockchain Implement Smart Contracts?

From the perspective of the whitepaper this seems unlikely. The word “contract” does not appear anywhere.

Might a blockchain enable smart contracts? Yes, of course it might, but it might enable many other things too.

Must A Blockchain Be Programmable?

Again the answer seems to be no. Neither the words “program” or “script” appear in the whitepaper.

A blockchain does have a requirement to be interpretable by one or more indepdendent observers, so it is clearly built from one or more well-defined data structures. The block data structure must contain a previous block hash, and the cryptographic hash of the block must be performed in a very specific way, but none of these require that the data structure carry any notion of executable code.

Can a blockchain contain some form of program code? This is an implementation question and the answer is yes. Bitcoin includes a limited scripting language, and other systems, such as Ethereum, have subsequently attempted to support more elaborate programming models. The choice to support such concepts seems more to be either expedience, or, more ambitious design goals, but it seems a blockchain need no more be “programmable” than any other linked list data structure.

Is A Blockchain A Database?

Once more the answer seems to be no. As before, the word “database” does not appear in the whitepaper.

At its core a blockchain is a special type of data structure. The blocks within the chain contain data, but this does not make it a database; at best the blocks represent the transaction log of a specific database implementation. Similarly there are no semantics for querying a blockchain, any more than there are for querying a linked list. A specific implementation might allow for queries of either but the implementation does not define the thing itself.

As a point of comparison, the IP packets that for the TCP packets carrying this article are defined as data structures in a series of IETF (Internet Engineering Task Force) RFC (Request For Comments) documents. The documents describe the form of the packets and their behaviour when they are transported. Recipients of those packets are able to make their own determinations of their validity without regard to any part of the network implementation between them and the originator. An implementation of a router/firewall may offer a feature to capture those packets so that they can be analyzed later, and may offer database queries of those packets, but there is nothing in the nature of an IP packet that makes it a database, nor is there anything in the RFCs that would suggest otherwise. Implementation features and specification are very different things.

Is A Blockchain Trustless?

The answer here is no too, but that’s because the question is too broad. A blockchain does allow us to require less trust than many traditional systems but any implementation still requires some level of trust.

A recipient of block data must trust that it has been delivered without being compromised by some intermediary. The P2P distribution of blocks within the Bitcoin and similar networks set out to try to minimize trust in peers, but even this model has potential failure points. Here are a few:

• We trust that the blockchain software that we are running has not been compromised to deliver falsified data.
• We trust that the operating system under which our blockchain software is running has not been compromised to deliver falsified data.
• We trust that the network processors providing connectivity to our system have not been compromised to deliver falsified data.

“In code we trust” makes for an interesting mantra, but 30+ years of malware, spyware, etc., informs us that this is a highly debatable strategy.

A blockchain design does make falsifications harder for an adversary, and makes accidental errors dramatically less likely. We are able to “trust but verify” (within bounds), but this is still a significant improvement over blindly trusting. Most importantly, none of these trust minimizing characteristics are aspects of the P2P network design, but are instead intrinsic to the block encoding.

Must A Blockchain Be Non-Permissioned Or Can It Be Permission-less?

A blockchain is just a data structure so really the question makes no sense. Who has the ability to read or write a data structure is a totally different question.

Let’s ignore this subtle distinction for a moment, though, and act as if the question might make sense. Consider the case of Bitcoin; who writes the blockchain? The answer is that miners (or more precisely, block makers such a mining pool operators, not those who just hash blocks) get to write new blocks. Transactors on the network can provide candidate transactions to be included in blocks, but this does not guarantee blocks will ever contain those transactions. With Bitcoin we talk about this being “non-permissioned” because no-one needs any explicit permission to become a block maker.

If we consider other potential uses of a blockchain design, though, there are a often very well defined set of participants who we would wish to be able to write block data. In many cases this may even be one single participant. A critique levelled at such potential uses of a blockchain are that this makes it no better than a database, but a conventional database is something in which blind trust must be placed. Its internal state is generally unknowable. Even in its simplest uses a blockchain can at least provide a means to verify the state of such a system, and to do so in a way that enables histories to be validated. This is only the start of the possibilities, however!

Is A Blockchain The Internet Of Money (Or The Internet Of Anything Else)?

Realistically, no, or at least not on its own.

When we looked at “not a database” we also touched on why this claim doesn’t really make sense. Superficially the argument seems seductive. The thought is that we can build lots of technology on top of a blockchain in the way that a network stack is layered.

There are many problems with this proposition, but the obvious one is that a blockchain is just a data structure. It makes a good candidate for being used to convey information across the Internet but doesn’t enable anything in and of itself. Separating the blockchain from any transport of a blockchain, however, does give some hope that blockchains may enable more reliable financial applications over the Internet. A clear separation also allows experimentation at each layer of the system design and this is a key characteristic that has enabled the Internet to be so successful. With the Internet, candidates for all layers of the network stack are able to be trialled, replaced or modified, allowing the best designs to win. Similarly the standards-based approach has enabled disparate implementations to work together without preventing commercial advantages from being sought and monetized.

In the case of blockchains we have already seen that there is a requirement to support external observers and this mandates a level of interoperability.

Last Thoughts

We have looked at what a blockchain might or might not be, and perhaps seen some hints of what it might enable. The technology that underpins Bitcoin can be used to build many things, and Bitcoin’s legacy should not just be Bitcoin itself, but that is has shown the viability of something far more fundamental. The debate over what constitutes a blockchain won’t end here, but we need to move the discussion forward and we need to resist the urge to allow it be just another marketing buzzword.

To make that happen we need both clear terminology, and well reasoned usage. We need to avoid conflating many different ideas, and we need technology claims to be realistic and achievable. If we fail then, eventually, the term blockchain will be meaningless and have to be replaced. This seems like the wrong outcome. If we succeed then the idea of a blockchain will not be the end of the story. Instead it will take its place as a layer upon which better and ever-more useful systems can be built.

End Content

---