Corrections to 8/4/2017 Issue
A couple of Morlock friends of mine (thanks @theartlav and @tubelite) tell me (with barely concealed impatience for my point-haired-boss-level careless bullshitting), that I got several technical details somewhere between misleading and wrong in yesterday's newsletter. Enough to obscure the main point.
Since I am not immune to Brandolini's Law (it takes 10x effort to refute bullshit as it does to produce it) even with my own writing, I won't try to correct or clarify everything. I'll just flag 2 of the bigger howlers, and tldr the broader metaphysics-of-decentralization point that may have gotten lost.
#1: Points 47-48 are misleading/wrong. The 21 million bitcoin limit isn't directly related to the hash target being lowered via changing number of leading zeros. At best it's an engineered, empirical, artificial correlation because difficulty changes with time overall (every 2016 blocks), generally, but not necessarily, towards higher difficulty, and the rewards are halved periodically (every 210,000 blocks). The number 21 million is the result of a summed geometric series converging to zero rather than a direct countdown in the block hashes. I kinda handwaved the occasional correlation artifact into a direct coupling. In fact even the correlation can break down.
#2: Points 40-41 are just plain wrong: The difficulty of finding a "special true name" hash has no technical relation to generating a key pair. This was a genuine A-grade-bs conceptual howler on my part. Finding a high-difficulty hash is difficult for reasons (proof-of-work) completely unrelated to the difficulty (practical impossibility) of breaking a public-key encryption scheme. Both kinds of difficulty are used to make blockchains possible, but are not technically connected. I conflated the two kinds of difficulty in my head and hilarity and confusion ensued. To restate the broader point that depends on these 2, what is actually going on here is that one kind of difficulty is used to make true names special/unique identifiers of specific data bundles, and the other kind is used to make a related but distinct bit of data securely controllable by their rightful owners. If you have both properties, you can construct a secure true-naming and secure-rights scheme. Proof-of-work difficulty and decryption difficulty are like the engine and wings that make this plane fly. Different principles, different functions, both necessary.
There are other, more minor errors and confusions buried in points #38-#53, so overall let me just flag that entire portion as "quick-and-dirty handwavy thumbnail sketch" in service of making the main point about how blockchains are a way to convert energy into a space of true names that have uniqueness and security properties. If you are interested in gaining a more accurate understanding of how that magic works, go read more technical source documents.
And finally, the tldr summary of the overall metaphysical argument I was trying to construct:
A/ You can think of decentralization as a separation of power and information
B/ True-naming and name-destruction processes form the boundary layer between power and information
C/ Secure true-naming and name-destroying take energy, and energy/power benefits from efficiencies of concentration
D/ Information wants to be free = decentralization = divergence due to named variety
E/ Power wants to clump = centralization = convergence due to the fungibility of the unnamed
F/ Even true-naming may be decentralized away (Zcash) but overall, as long as there is some sort of "power" there will be power gradients and centralization
_Feel free to forward this newsletter on email and share it via the social media buttons below. You can check out the archives here. First-timers can subscribe to the newsletter here. You can set up a phone call with me via my Clarity.fm profile page. _
Check out the 20 Breaking Smart Season 1 essays for the deeper context behind this newsletter. If you're interested in bringing the Season 1 workshop to your organization, get in touch. You can follow me on Twitter @vgr
Copyright © 2017 Ribbonfarm Consulting, LLC, All rights reserved.