[Note: the 10th anniversary of the Bitcoin whitepaper is this month.  Below is a detailed interview with one of the first individuals to have interacted with Satoshi both in public and private: Ray Dillinger.

All of the written responses are directly from Ray with no contributions from others.]

Q1: Tell us about yourself, what is your background?

A1: I am originally from Kansas.  At about the same time I entered high school I became interested in computers as a hobbyist, although hobby computers were still mostly useless at that time.  I got involved in early BBS systems when DOS hadn’t been released yet, modems were acoustically coupled and ran at 300 bits per second or slower, and software was stored mostly either on notebook paper or cassette tapes.

The early interest in computers is part of my lifelong tendency to become deeply involved in technology and ideas that are sufficiently interesting. This has led me to develop interests, obsessions, and expertise in a huge variety of things most of which the public does not discover reasons to care about until much later.

I graduated from KU with a degree in Computer Science in December of 1995 after spending far too long alternating between semesters of attending classes and semesters of working to pay for classes.

After graduation I moved to the San Francisco Bay area.  I worked for several AI startups in the next seven years and hold a couple of patents in natural-language applications from that work.  After that, I worked the night shift for FedEx for some years while doing occasional security consulting gigs during daytime hours.  I am currently doing AI algorithm research and implementation (and some cryptographic protocol/document design) at a FinTech startup.  I work on General AI projects on my own time.

I am somewhat pessimistic by nature and tend to assume until given reason to believe otherwise that anyone trying to sell me something or convince me of something is a scammer.  I know that’s irrational, but knowing doesn’t make the belief stop.  I have an abiding hatred of scammers and find them viscerally disgusting.

I consider making noise to be rude, avoid crowds and public appearances, and distrust anyone speaking faster than they can think.  Although I write a great deal, I rarely speak and strongly dislike talking on the phone.

In spite of my peculiar interests and asocial tendencies, I somehow managed to get married to a wonderful woman who tolerates an unbelievable degree of geekdom in an unbelievable variety of subjects, ranging from mild interest to full-on mad scientist levels in scope. I am tremendously thankful to have her in my life, and to whatever degree
I might be considered social, she deserves most of the credit.

I became marginally involved with Bitcoin in its early development because cryptocurrency, and the application of block chains to cryptocurrency in particular, are interesting.  I ceased to be involved in Bitcoin when the next steps would necessarily involve salesmanship, frequent talking, and social interaction, because those things are not interesting.

Q2: Perry Metzger created the now infamous Cryptography mailing list years ago.  When did you join and what made you interested in cryptography?

A2: I joined so many years ago it’s hard to remember.  It was pretty much as soon as I became aware of the list, but I’m sure it was more than fifteen years ago. It may have been late 2001 or early 2002.

I think I may even have been one of the first twenty or thirty posters on that list – it was still very young.

I remember being vaguely annoyed that it hadn’t been available when I was actually still in college and doing a crypto project in a grad-level networking course – I’d been a member of the even-earlier ‘cypherpunks’ list back when I was in school, but its strident political ideologues (including a guy named Hal Finney, whom you’ve probably heard of)
annoyed me, even back then.

‘cypherpunks’ was where I became aware of and started corresponding with Hal.  Although, way back then, I think we were both mostly annoying to each other.  And possibly to others as well.  Hal had been stridently political all the way from those days (and probably before) to the day he died, and in retrospect, I think I really needed some ‘remedial human-being lessons’ and some wider education at the time.  I’ve learned a lot since then – and perspective outside the narrow specialties we studied in school really does matter.

Q3: There were a lot of other non-cryptocurrency related discussions taking place simultaneously in November 2008 and many of the frequent posters didn’t comment on Bitcoin when it was first announced.  What interested you in it?  How involved would you say you were with providing coding suggestions prior to the genesis block that following January?

A3: I was interested in it for several reasons.  First, Bitcoin was a digital cash protocol, and digital cash protocols have some significant challenges to overcome, and I’d been interested in them for a long time already.  I’d even designed a couple by then.  The first I designed was unsound. The second, which is the only one worth talking about, which I’ll talk more about below.

Second, Bitcoin used a central proof chain (which we now call a block chain) as means of securing the history of each note, and I had known for a long time that any successful digital cash protocol had to use proof chains in some form or it couldn’t circulate (couldn’t be spent onward by someone who’d been paid in it).  And I was very, very much interested in proof chains, especially for a digital cash protocol.  I had already used proof chains (very differently) for a digital cash protocol when I extended Chaum’s e-cash protocol in 1995.

(see Digression #1 below to understand the differences between my protocol and Satoshi’s, and their effect on protocol design.)

Third, Satoshi eventually convinced me that he wasn’t a scammer.  I’m sort of a natural pessimist at heart, and digital cash protocols have a long history of scammers, so at first I had assumed the worst.  I think a lot of others also assumed the worst, which would be why few of them responded.  I made my first couple of replies without even having read it yet, to see how he responded before I wasted mental effort on something that would probably turn out to be a scam.

When I finally bothered to actually read the white paper, and spent the mental effort to understand it, I realized that (A) it wasn’t the usual incompetent bullshit we’d seen in far too many earlier digital-cash proposals, and (B) Its structure really and truly contained no Trusted Roles – meaning the opportunity to scam people was NOT built into the structure of it the way it had been with e-gold, e-cash, etc.

Fourth, and absolutely the clincher for me; it was very very INTERESTING!  It was an entirely new paradigm for a digital cash protocol, and had no Trusted Roles!  Nobody had EVER come up with a digital cash protocol having no Trusted Roles before!

Of course it wasn’t a “serious” proposal, I thought. It wouldn’t work for any kind of widespread adoption (I thought at the time) because of course people would conclude that spent hashes which absolutely couldn’t be redeemed for the electricity or computer power that had been used to create them were valueless.  And it would never scale beyond small communities or specialized applications of course because of its completely stupid bandwidth requirements.

But it was INTERESTING!

I could never have come up with Bitcoin because of the tremendous bandwidth.  Without Satoshi’s proposal, the idea of transmitting every transaction to every user would just have bounced off my mind as inconceivable.  Hell, I didn’t even understand it the first couple of times through the white paper because I was looking for ANY WAY AT ALL to parse those sentences and ‘transmitting every transaction to every user wasn’t even a POSSIBLE parse for me until Satoshi explicitly told me yes, that really was what he meant.

When I finally understood, I started doing math to prove to him that it was impossible, tried to relate bandwidth to rate of adoption and got a largest possible answer that’s only about one-eighth of today’s number of nodes.   I was assuming transaction volume proportional to userbase, which would be at least three times the transactions that today’s blocksize-limited block chain handles, and looking at a version of the protocol which doubled it by transmitting every transaction twice.  So,GIGO, I was wrong – but for good reasons and in the correct order of magnitude anyway.

But that was a couple orders of magnitude larger than the highest answer I had expected to get!  And that meant Satoshi’s idea actually seemed…. surprisingly plausible, if people really didn’t care about bandwidth.

The fact that bandwidth seemed to be available enough for the proposal to be technically plausible was sort of mind-boggling.  So was the idea that so many people did not care, at all, about bandwidth costs.

(See digression #2 to understand why it was hard for me to accept that
people now consider bandwidth to be valueless.)

Anyway, problems aside, it was INTERESTING! If the proof-of-concept actually sort-of worked at least on scales like for a campus or community merchandise token or something it would extend our understanding of protocol design!

What I had done back in 1995 had been INTERESTING for a different reason. At that time nobody had ever come up with a digital cash protocol that allowed people who’d been paid digital coins to respend them if they wanted instead of taking them right back to the issuer.  Of course it wouldn’t work for general adoption because of its own problems, but it had extended our understanding of protocol design back then, so back then that had been INTERESTING!

And before that, Chaum had demonstrated a digital cash protocol that worked at all, and at the time that was INTERESTING!

And in between a whole bunch of people had demonstrated ways to cooperate with bankers etc to have different kinds of access to your checking account or whatever.  Some of those had had privacy features v. the other users, which were also INTERESTING!

And so on.  I was very much looking at things that improved our understanding of digital cash protocols, and had no idea that Bitcoin was intended for widespread release.

Anyway, Satoshi and I talked offlist about the problems, and possible solutions, and use of proof chains for digital cash, and my old protocol, and several previous types of digital cash, and finally he sent me the proof chain code for review.

And the proof chain code was solid, but I freaked out when I saw that it used a Floating Point type rather than an Integer type for any kind of accounting. Accounting requirements vs. floating point types have a long and horrible history.

So that prompted some more discussion. He was designing specifically so that it would be possible to implement compatible clients in languages (*cough* Javascript *cough*) in which no other numeric type is available, so he wanted to squish rounding-error bugs in advance to ensure compatibility.  If anybody gets different answers from doing the same calculation the chain forks, so it’s sort of important for everybody to get the same answer.  Because Javascript clients were going to use double float, and he wanted them to get the same answer, he was going to make sure he got correct answers using double floats.

He was trying to avoid rounding errors as a way of future-proofing: making it completely consistent so clients with higher-precision representations wouldn’t reject the blocks of the old chain – but on the ground he wanted to be damn sure that the answers from Javascript clients, which *would* by necessity use double float, could be compatible with checking the block chain.

The worst that could happen from a rounding error, as long as everybody gets the *SAME* rounding error, is that the miner (whose output is unspecified in the block and defined as “the rest of the TxIn values input”) gets a few satoshis more or less than if the rounding error hadn’t happened, and no satoshis would be created or destroyed.

But if people on different clients get *DIFFERENT* rounding errors, because of different representation or differently implemented operations, the chain forks. And That Would Be Bad.

I would have said *screw* Javascript, I want rounding errors to be impossible, and used integers.  If the Javascripters want to write a float client, they’d better accept accurate answers, even if they have to allow for answers different than their code generates.  And if they make transactions containing rounding errors, let everybody in the universe reject them and not allow them into blocks.  But that’s me.

It was when we started talking about floating-point types in accounting code that I learned Hal was involved in the effort. Hal was reviewing the transaction scripting language, and both the code he had, and the code I had, interacted with the accounting code. So Satoshi brought him in for the discussion on floating point, and both of us reviewed the accounting code. Hal had a lot of experience doing exact math in floating point formats – some of his crypto code in PGP even used float types for binary operations. So he wasn’t as freaked-out about long doubles for money as I was. We talked a lot about how much divisibility Bitcoins ought to have; whether to make ‘Satoshis’ an order of magnitude bigger just to have three more bits of cushion against rounding errors, or keep them near the limit of precision at 10e-8 bitcoins in order to assure that rounding errors would always fail. Failing, immediately, detectably, and hard, at the slightest error, is key to writing reliable software.

So I went over the accounting code with a fine-toothed comb looking for possible rounding errors.  And I didn’t find any.

Which is more than a little bit astonishing.  Numeric-methods errors are so ubiquitous nobody even notices them.  Inevitably someone multiplies and divides in the wrong order, or combines floats at different magnitudes causing rounding, or divides by something too small, or makes equality comparisons on real numbers that are only equal 65535 times out of 65536, or does too many operations between sequence points so that they can be optimized differently in different builds, or uses a compiler setting that allows it to do operations in a different sequence, or checks for an overflow/rounding in a way that the compiler ignores because it can prove algebraically that it’s “dead code” because it will never be activated except in case of undefined behavior (like eg, the roundoff or overflow that someone is checking for)!  Or SOMETHING.  I mean, in most environments you absolutely have to FIGHT both your language semantics and your compiler to make code without rounding errors.

Clearly I hadn’t been the first pessimistic screaming hair-triggered paranoid aware of those issues to go over that accounting code; I could not find a single methods error.  The ‘satoshi’ unit which is the smallest unit of accounting, is selected right above the bit precision that can be handled with NO rounding in the double float format, and every last operation as far as I could find was implemented in ways that admit no rounding of any bits that would affect a unit as large as a satoshi.

To cause rounding of satoshis in the Bitcoin code, someone would have to be adding or subtracting more than 21 million Bitcoins (I think it’s actually 26 million, in fact…).  So, the Bitcoin chain is, I believe, rounding-free and will continue to check regardless of whether clients use any higher floating point precision.

For comparison Doge, which has so many coins in circulation that amounts larger than 26 million Doge are actually transacted, has rounding errors recorded in its block chain.  If a new client ever uses a higher-precision float format, their old chain won’t check on that client.  Which would be seen as a bug in the new client, and “corrected” there (by deliberately crippling its accuracy when checking old blocks). In fact it’s a bug in the Doge coin design which will never be fixed because they’ve already committed too much to it.

Integers.  Even with code that is meticulously maintained and tested for consistency, even where methods errors have been boiled out by somebody’s maniacal obsessive dedication, Integers would have been so much cleaner and easier to check.

Digression #1:
Why I was VERY interested in proof chains and digital cash protocols.

When I extended Chaum’s protocol in 1995, I had used proof chains attached to each ‘coin’, which grew longer by one ‘link’ (nowadays we say ‘block’) every time the coin changed hands. That allowed coins to circulate offline because all the information you needed to make another transaction was in the chains attached to the individual coins.  In order to make it possible to catch double spenders, the ‘links’ contained secret splits which, if two or more contradictory links were combined, would reveal the identity of the spender.

So, it could circulate offline and make transfers between users who weren’t even connected to the Internet. It didn’t have the ferocious bandwidth expense and even more ferocious proof-of-work expense of Bitcoin. Double spenders couldn’t be caught until the differently-spent copies of a coin were compared, potentially after going through several more hands which meant you had to have some kind of resolution process. And a resolution process meant you absolutely had to have a Trusted Certificate Authority with a database that could link UserIDs to RealWorld IDs in order to figure out who the RealWorld crook was.

Buyer and seller had to have valid UserIDs issued by the Trusted CA, which were known to each other even if to no one else.  And although not even The Trusted CA could link UserIDs and transactions except in case of a double spend, the parties to each transaction definitely could. Either party could later show and cryptographically prove the details of the transaction including the counterparty’s UserID, so your transactions were “Private”, not “Secret”. Finally, the ‘coins’ were non-divisible meaning you had to have exact change.

It was, at best, clunky compared to Bitcoin, and not being able to identify double spends until unspecified-time-later would probably be a deal-killer for acceptance. But it also had some advantages: It didn’t create a central permanent ledger that everybody can datamine later the way Bitcoin does, so Trusted CA or not it might actually have been better privacy in practice.  It was completely scalable because no transaction needed bandwidth between anybody except buyer and seller. And it had no proof-of-work expense.  But it needed a God-Damned Trusted Certificate Authority built directly into the design, so that CA’s database was open to various kinds of abuse.

Digression #2:

I had no comprehension of modern attitudes toward bandwidth costs.

I mean, I knew it had gotten cheap, but it was still taking me hours, for example, to download a complete Linux distribution. I figured other people noticed big delays like that too, and wide adoption of Bitcoin would mean slowing down EVERYTHING else they (full nodes anyway) did.  I just hadn’t understood that – and still have trouble with – the idea that by 2008, nobody even cared about bandwidth any more.

I got my first computer, because at that time privately owned computers were INTERESTING!  So I had to, even though they were also mostly useless.  (See a pattern here?)

But at that time, computers were not communications devices.  At All. If you hadn’t invested in something called a “LAN”, which anyway could only work inside one building, probably cost more than the building itself, and was useless unless you’d also invested in multiple computers, you moved data back and forth between your machines and your friends’ machines using cassette tapes.  Or, if and your friend were both rich enough to buy drives, or had been lucky enough dumpster diving to get drives you could repair, and had access to the very expensive media through some kind of industrial or business supply place, you might have done it using floppy disks.  Which held eighty kilobytes.

I got my first modem a few years later, and modems at the time were flaky hardware only BARELY supported by single-tasking systems that had never been designed to handle any signal arriving anywhere at a time they did not choose.  If your computer didn’t respond fast enough to interrupts, a modem could crash it.  If you were running anything that didn’t suspend and resume its business correctly (and most things didn’t because they’d never had to before) or anything that was coded to use the same interrupt, the modem would crash it.  If the software on your end ever started taking too long to execute per input character, the modem would fill up the short hardware buffer faster than your software could empty it, and crash it.  If you transmitted characters faster than the software running on the remote system could handle them, you’d crash the remote system.  There were no error correcting protocols because none of us had the compute power to run them fast enough to avoid a crash at the speeds the modems ran.

And that modem couldn’t transmit or receive characters even as fast as I could type. Sometimes you could crash the remote system just by accidentally typing too fast for a minute or two.

Computer security wasn’t a thing. Pretty much anybody you allowed to connect could at least crash your system and probably steal anything on your computer or delete everything on your computer if they really wanted to.   The host programs weren’t *intended* to allow that, but something as simple as transmitting an unexpected EOT signal could often crash them – sometimes crashing the whole machine, sometimes leaving the caller at the all-powerful command-line prompt. Stuff like that happened all the time, just by accident!  So people were understandably reluctant to let strangers connect to their systems.

There was one place in my whole state that I could call with it where I found people who’d leave a modem running on their machine despite the risk of crashes, and would allow a stranger on their system.  That sysop, in an act of sheer grace that he didn’t have to extend and which nobody was paying him for, allowed me to connect to it.  There were no such things as commercial providers; they could not exist until at least some system security actually worked.

There was barely even any commercial software: Every machine came with its own BIOS and Operating System, and the ONLY way to distribute a program that would run on more than a tiny fraction of systems was to distribute it as source code which people could tweak and fix and adapt in order to get it running, and commercial vendors didn’t want to distribute any source code.

So our software was all shared.  It came from fellow hobbyists, and unless we were physically in the same room to exchange media (and had the ability to read and write media compatible with the other’s systems), we could not share it without using bandwidth.

Long distance calls were over a dollar a minute, modems ran at 160 or 300 bits per second, and I could have burned through my entire monthly paper route income in under three hours.

Finally, every second I was connected to that remote system, that phone line was busy and everybody else couldn’t use it. And the other users needed it for reasons FAR more important than I did. They were military veterans, some of them profoundly not okay after Viet Nam, using it as sort of a hobby-mediated support group, and I was a fifteen-year-old kid hobbyist with a paper route.  Hobby in common or not, I had no illusions about the relative value of our access.   So I tried to be a good guest; I took my turns as fast as possible, at times least likely to conflict as possible, using as many pre-recorded scripts (played off a cassette tape deck!) as possible to waste absolutely no time, and got off.  I didn’t want to keep anybody out of something which was that important to them.

That’s the way things were when I started learning about the value of bandwidth.

No matter how much bandwidth I’ve got now, no matter how cheap it becomes, I’m still aware of it and it’s still important to me to not waste it.  I’ve sweated every byte every time I’ve designed a protocol.

And that’s why – to me anyway – universal distribution of a globally writable block chain is still amazing.  Just the fact that it’s now POSSIBLE seems incredible.

Q4: When Satoshi released the white paper, you had many public exchanges with her on that mailing list.  For instance, you asked her about inflation and Satoshi seemed to think that there could be some price stability if the number of people using it increased at the same level as the supply of bitcoins increased.  But, relative to the USD, there has never really been much price stability in its history to date.  Is there a way to re-engineer Bitcoin and/or future cryptocurrencies to do so without having to rely on  external price feeds or trusted third parties?

A4: Whoof…  that’s a hard question.  “Is not Gross Matter Interchangeable with Light?”  was considered impossible until Einstein figured it out. And the people who’d been asking that question didn’t even recognize or care about Einstein’s answer because his answer wasn’t about bodies and souls and the afterlife.  If the answer is ‘yes’ but the re-engineering involved changes the fundamental qualities that make you (or anybody) value cryptocurrencies, then is the answer really yes?

Satoshi tried to do it by anticipating the adoption curve.  We know how that turned out.

I think it’s fundamentally impossible to plot an adoption curve before launch.  I mean, I was the pessimist who assumed that there’d be a small group, formed early, that wasn’t going to be growing at all as these additional millions of coins pumped into that campus or that community economy.  So I figured, some initial value and rapid inflation thereafter.

Satoshi was far less pessimistic in figuring a widespread and fairly gradual adoption, and had picked the logarithmic plot to put coins into the economy at about the rate envisioned for adoption, assuming Bitcoin would follow a logarithmic adoption curve. It wasn’t a bad guess, as it’s a decent approximation to the Bass Diffusion Model, but the
parameters of the curve were completely unknown, and the Bass curve often appears after something’s been around a long time – not just when it’s launched.

Most importantly, nobody anticipated Bitcoin’s primary use as being a vehicle of financial speculation. The Bass Diffusion Model isn’t applicable to speculative commodities, because price changes in speculative commodities are responsive to PREVIOUS price changes in the speculative commodity.  That makes them nonlinear and chaotic.

And that, I think, is what it comes down to.  If people will be using something as a vehicle of speculation, then its price point is chaotic and defies all attempts to stabilize it by predicting and compensating for it.  So I think we need to abandon that notion.

You’ve already ruled out the idea of external price feeds and trusted third parties, because those would change the fundamental qualities that make you value cryptocurrencies.

That leaves internal price feeds:  If a cryptocurrency is used as a medium of exchange in other fungible assets, and those exchanges are recorded in its own block chain, then exchanges of crypto for dollars and exchanges of crypto for, eg, gold bars are visible in the block chain and could at least in theory be used to detect economic conditions and adjust the rate of issue of cryptocoins.

But the fly in that ointment is, again, the fact that the crypto is being used as a speculative asset.  People can read the block chain before the changes are made, anticipate what changes the code is about to make, and will front-run them.  Or, operating as “Sybil and her Sisters”, make a thousand completely bogus transactions in order to fool the software into doing something crazy.  Either way reintroducing positive feedback via market manipulation.

Most schemes aimed at stabilizing the value of a coin via any automatic means assume that the price can be changed by changing the rate of issue.  But the more coins are in circulation, the less possible it becomes for changes in the rate of issue to shift the price, meaning it devolves back to the first case of nonlinear and chaotic feedback.  IOW, the new coins being added represent a much smaller fraction of the available supply, and withholding them will affect almost no one except miners.

Honestly I’m very surprised Tethercoin isn’t dead yet.  What they propose, economically speaking, simply will not work.  They got themselves somehow declared to be the only way to get money OUT of a major wallet, which props up their transaction volume, but if the people haven’t already walked away with most of the money they’re supposedly holding but won’t say where, then I’m very surprised.

Q5: About a year ago you wrote a highly-commented upon, passionate retrospection published on LinkedIn.  You called out a lot of the nonsense going on then, is there anything that has been on your mind since then that you wanted to expand upon?

A5: Um.  Artificial Intelligence, Financial Markets, Human Brains and how they are organized, the nature, origins and mechanisms of consciousness and emotion, a generalization of neuroevolution algorithms intended to scale to recurrent networks of much greater complexity than now possible, scope of political corruption and the politics of divisiveness, gene migration and expression, the way cells control and regulate mutation in different kinds of tissues, directed apoptosis via a multiplicity of P53 genes as a preventive for cancer (happens naturally in elephants; easy to do with CRISPR; engineered humans would probably be radiation-resistant enough for lifetimes in space, or just plain longer-lived, or both), history of the Balkans, history of the Roman Empire, ancient religions, writing a science fiction novel ….

You know, things that are INTERESTING!  I actually _can’t_ turn my brain off.  It’s a problem sometimes.

I have had a few thoughts about cryptocurrencies, however, which is probably what you intended to ask about.

The first:

I have figured out how to redesign the cryptographically secured history database built by cryptocurrencies so that you don’t need any full nodes.  There are other ways to organize the blocks that give the proof property you need; They don’t have to form something that’s only a chain, and you don’t have to have specialized nodes for the purpose of holding them because everybody can hold just the blocks they need to show the validity of their own txOuts.

In order to verify the validity of any txOut, you need three things:  to see the block where it was created, to be sure that block is part of the same database as that proposed for the transaction, and to be sure that no block exists between those two in which that txOut was spent in another transaction.

Call it a “Block Hyperchain”, by reference to the N-dimensional hypercube it’s based on and the block chain it replaces.

I should be clear and say there are things it does and things it doesn’t do.  If your goal is to check all transactions, you’ll download a scattering of blocks for each transaction that soon add up to most of the block database, so someone who wants to check every transaction will rapidly accumulate the whole database.

But most users should be happy with just the few blocks they need to demonstrate the validity of the txOuts they hold, and it’s damn nice to be able to download a client, open it up, and just use it with minimal delay because someone offered to pay you bitcoins one minute ago and you want to be able to make sure the transaction he’s offering is valid RIGHT NOW, instead of waiting to accumulate the whole chain to check anything.

Suppose we pick a base, for convenience, of 10.  This helps make things easy to explain because we work with base-10 numbers, but we could have picked 16 and used hexadecimal for our explanations.

In a base-10 Block Hyperchain, every block that’s published has its own set of transactions, and the hashes of the blocks  10^N blocks ago for every integer value of N from N=0 to N <= log10 of block height.

Every block would record its own transactions, and also one list of destroyed txOuts per integer value N over the same range.

Each destroyed-txOut list would be all txOuts created in blocks whose block numbers match (modulo 10^N) the current block number, that have been destroyed in the last 10^N blocks.

Example:
If someone shows me a transaction seeking to spend a txOut, I want to check and see if it’s valid.  Ie, I want to see the block where it was created, and see evidence that it hasn’t been spent since.

So I can look at that txOut’s ID and know it was created in block 124. If the current block is 7365,  I get block 7365 and 7364 to make sure it hasn’t been spent in those, the same way we can do with a block chain.

Then I have a block whose last digit matches the last digit of the block where the txOut was created.  So I start checking the 10-block txOut-destroyed lists.  I check the list in block 7364 to make sure it wasn’t spent in blocks 7354 to 7363.

Then, jumping back by 10-block increments (relying on the second recorded hash in the header), I can check to make sure it hasn’t been spent in the previous ten blocks to each of blocks 7354, 7344, and 7334.  Then I get block 7324.

Now I’m at a block whose last 2 digits match the block where the txOut was created, so I can start checking the previous hundred blocks using the second txOut-destroyed list, and jumping back by hundred-block increments using the third recorded hash.  So I get blocks 7224 and 7124.

Finally, I’m at a block whose last 3 digits match the block where the txOut was created, so I can start jumping back by thousand-block increments, checking the thousand-block txOut-destroyed lists.  So I get blocks 6124, 5124, 4124, 3124, 2124, 1124, and finally 124.

So finally, I have a txOut created over 7200 blocks previous to the current block, and I have downloaded a total of 15 blocks to make sure that it was created in the same Hyperchain and hasn’t been spent since.

The number of blocks downloaded is proportional to the log base 10 of the number of blocks in the chain.

The blocks I’ve downloaded are larger because of the spent-txOut lists, but the spent-txOut lists have an average length that is the same regardless of the span of blocks they cover.  Lists that report transactions from a set 10x as long, only need to report individual transactions from that set 1/10 as often.

With more efficient access to the history database, it is possible to substantially raise transaction bandwidth.  People who make transactions during the next 7 blocks or so would need to see that block;  Later on, people who accept txOuts created during that block will need to see that block. And there’ll be about 49 blocks worth of txOuts,  scattered through the earlier history, that someone eventually has to traverse this block to verify.

All this means you have drastically smaller bandwidth requirements (remember I obsess on bandwidth costs?) for the same transaction volume but larger data-at-rest requirements (for any weirdo who for whatever reason feels like they need to collect the WHOLE database in one place, and why would anybody do that?) by a factor of seven.

And I keep thinking I’m going to do it, because it’s INTERESTING! And I ought to do it, because it’s VALUABLE!  But then I think about the current state of the cryptocurrency world and the quality of the people it would bring me into contact with and the ways people would try to scam with it and the number of people who’d find reasons to lie to me or about me, and then I get a sour stomach and go on to do something ELSE!

And feel vaguely guilty for not doing it, because it actually would be valuable.

It’s really hard for me to be motivated or enthusiastic about a cryptocurrency project, until the whole field is more full of people I’d be happy to interact and exchange ideas with and less full of ….  um.

The words that come to mind really shouldn’t be printed.  [This is fine meme]  I don’t mind if people know I’m sort of upset with the conditions and business ethics out there, or even that being so upset is literally preventing me from doing something useful.  But I’d rather not have it expressed in terms that are an incitement to violence.

Anyway, moving on;  In order to mine, someone would have to be able to see seven of the previous blocks; a different set of seven every time. But if I thought bandwidth was going to waste, that doesn’t even START to address the costs of hashing!  Deploying something that saves bandwidth without also figuring out a way to save hashing would fail to address a critical point.

So, I’ve had a bunch of thoughts about mining.  Most of which aren’t as interesting or valuable as the thought about how to organize the history database.  In favor of mining, it’s good that someone is able to join the network permissionlessly, help secure it, get paid, and initially get coin into circulation going from “none” to “some”.

My thoughts for securing a chain without proof-of-work are something I suppose I ought to call “Proof-of-Total-Stake.”

Congratulations!  This conversation with you got me to name it!  I had been calling it “proof-of-activity” but I see that name has acquired a much more specific meaning than it had when I started calling this by it, and no longer fits.

I still need to figure out what to call my revised structure for the block history database though.

Proof-of-Total-Stake  means measuring the priority of a fork by the total value of TxOuts that existed BEFORE the fork that have been spent AFTER the fork.  In other words, the total stake: how much of EVERYBODY’s money the blocks formed after the fork represent.  That is a well-founded mechanism for security that doesn’t involve trusted parties nor burning hashes.  It’s the only one I’ve come up with.  In the long run, unless somebody comes up with another fundamentally new idea, or accepts the idea at least of trusted block signers, that’s what I think a proper cryptocurrency would have to wind up with.

But there’s a problem with it.

Proof-of-Total-Stake, by itself, doesn’t provide an obvious way to determine who gets to form the next block – which can be a CRUCIALLY important security concern.

And Proof-of-Stake, including Proof-of-Total-stake, doesn’t handle the initial, permissionless, distribution of coins.  They can’t go from “none” to “some.”  They can only go from “some” to “some more.”

So I think it could only be deployed along with some kind of mining.

Q6: We first started interacting some four years ago when I was doing some research on dead cryptocurrencies, most of which were just direct clones or copies of Bitcoin.  At the time you were doing the heavy lifting categorizing how they died in a BitcoinTalk thread.  Today sites like Deadcoins.com have tried to do something similar.  Even though loud advocates at events like to claim blockchains ” live immutably forever” empirically there are probably just as many dead blockchains than living blockchains.  What do you think the top reason for why so many blockchains lose support to the point of death and do you think those reasons will change much in the future?

A6: By far the vast majority of those people were not doing anything INTERESTING!  A lot of the honest ones discovered that it was a lot of work and had other commitments in life.  A lot of the dishonest ones made their money and walked away leaving the  suckers behind.  A lot of people discovered that maintaining a codebase needed more programming chops than they actually possessed, and quietly withdrew from the field. A fair number ran into scammers and crooks whose utterly disgusting behavior left them convinced they wanted to do something else rather than meeting any more of those guys.

But the most important point? Hardly any of those coins was ever used in any transaction for an actual thing – not even an initial experiment like Laszlo’s Pizza.

Most of them were only ever mined by people who intended absolutely nothing beyond immediately converting them into Bitcoin, and only ever held by people who daily watched their value trying to guess the right time to sell them for Bitcoin.

It’s not so much that most of them *failed* – it’s more the case that the vast majority never even remotely began to *succeed*. There was no economic activity, meaning sales of merchandise or payment for work, that they facilitated.  Put bluntly, they just didn’t do anything beyond providing a temporary and completely discardable medium for speculation and scamming.  And, as surely as atomic decay, they got used, for that purpose only, and discarded.

Q7: Based on the original white paper, the intent of Bitcoin was to be an e-cash  payment system which could be utilized without needing to disclose a real identity to an administrator.  It seems that over time several different tribes have popped up, including those who market Bitcoin as a form of “e-gold.”  What do you think of the visible fracture that has occurred between the various Bitcoin tribes?  Does proof-of-work really act as a type of DRM for coin supply or do all the forks we have seen turn the advertised “digital scarcity” and “digital gold” into an oxymoron?

A7: That endless fight, starting with the block size fight, with everybody yelling and nobody listening, pretty much convinced me that the “community” which had grown around Bitcoin was in deep trouble.

The differences between the various proposed technical changes to the block chain, are far less important to the futures of those forks, than the integrity of the people who support and do business using them.

But the technical merits were never discussed by most. Instead, repetitive sound bites and slogans about them containing absolutely no new information were shouted.  Integrity was seldom displayed either. Instead, the fight was carried forward almost exclusively by partisans who had already decided what was the only possible solution that they would accept, and in many cases using tactics that inspire an absolute refusal to support their interests, or even participate in the communities where they are found.

If someone hires a troll army to attack a community by astroturfing fake support for something, can you respect that person?  If someone drives people who disagree away with personal abuse, is that a reasonable method for coming to an agreement about a protocol?  Is it a valid form of technical reasoning to launch a sabotage against a block chain based consensus mechanism?  What can you say about someone who buys existing accounts of users whom others trust in order to fake trusted support for their agenda? How about when it happens after those users whom others trust have been driven away or left in disgust?  Is it a respectful negotiator interested in the insights of others in solving a problem, whose negotiating skills include locking the damn doors and refusing to let someone leave the room until they get his signature on an “agreement” that they wrote without his knowledge before he even got there?

Is someone who would participate in a fight, on those terms, someone whose agenda or business interests you really want to support?  Hint: You already know that people who fake support for their agenda, or tell lies about other in order to discredit them, or who deliberately deceive others about the merits of their own proposal or others’ proposals, are doing business by means of fraud.  Do you want to carry on until the fraud is financial and the victim is you?

These factions had no interest whatsoever in reaching a consensus.  And nothing prevented each from implementing their idea and launching, with no hard feelings from anybody and no fight.  The only thing they were really fighting over was the name “Bitcoin,”  which was absolutely unrelated to the technical merit of any proposal.  And, to a first approximation, the other merits of having the name is a thing that none of them even mentioned during the fight.

Technically speaking, there is not much wrong with any of these forks. They address certain problems in different ways slightly favoring the interests of different groups, but not seriously to anyone’s disadvantage.  None of them was entirely without technical merit.

On the other hand none of them make more than a tiny amount of difference.  None helped with the bandwidth or transaction volume by anything more than a small constant factor, so the problem they were supposedly about solving was not in fact solved, nor even very much affected.

So while none of the proposed changes were objectionable in themselves, there was really no *very* compelling reason for any of them to be implemented.  Each of those ideas is merely a stopgap that pushes the rock down the road another foot or two without moving it out of the way. If you want to move that rock out of the road, you will need a much more powerful idea.

Q8: You’ve mentioned that limited supplies simply incentivizes hoarding which leads to low economic activity.  You have proposed a type of “proof-of-activity” replacement.  Can you expand more on either of these views?

A8: Suppose you have an economy that’s growing (more value is being created) but has a constant supply of coins.

In that case your coins represent, let’s say, one-millionth or so of the money that’s in circulation.

And, as the economy continues to grow, your coins will continue to represent one-millionth or so of the money that’s in circulation.  But that will be one-millionth or so of a lot more actual wealth.  In fact, your money, just sitting there in your wallet, is GUARANTEED to rise in value by the same fraction that the economy is growing by.  In our terms, this would be exactly the market average, as though you were holding stocks invested in ALL the businesses in your economy in proportion according to their  capitalization.  This is what index funds and IRAs make, mostly, but it’s making it with no risk.

Now, if you offer any investor a risk-free investment that’s guaranteed to make the same return as the market average, that investor would be mad to pass it up.  No investor is confident that she’ll beat the market average in any given year.  That’s why they call it “AVERAGE!”  And volatility – variance in return – is an unqualified bad thing because it will always take an 11% gain to make up for a 10% loss.  That money sitting right there in her wallet is the best investment she could possibly make.  There might be things that would make as much or more money, but all of them involve risk out of proportion to their marginal return.  Let other investors do that; they’re suckers and she’ll make the same money they do.

The problem with that is that the other investors are looking at the same question.  And reaching the same conclusion.  Why invest in companies doing anything productive, and expose yourself to risk, when you can make the same money just by holding your investment in your wallet?

And then who invests in the businesses that, if they were working, would actually create the value these people all intend to have some share in?

… (sound of crickets chirping) …  Suckers.

Suckers who lose more often than they win, because it takes an 11% gain to recover a 10% loss.  And the money the lose? Eventually trickles into the hands of the people who are hoarding it.

With no reason for investors to invest in business, the businesses eventually starve and the economy shrinks.  And all those coins that represent one-millionth of the economy’s wealth start representing one-millionth of less and less actual value.

This is what happened to ancient Rome.  They used metals (gold and silver and bronze) as currency, and their economy collapsed WHILE people had plenty enough money to keep it going!  Everybody stashed all their coins expecting to benefit later from prospering businesses, and the businesses, for want of capital, did not prosper.

Then the death spiral started: everybody stashed their coins waiting for the economy to come back so the coins would be worth their “real” value, and the economy never came back.  The coins were never worth their “real” value, until the people who remembered where the coins were buried had also been buried.

It’s a millennium-and-a-half later and we are STILL finding stashes of Roman coins!  The people who could have gotten their economy moving again, if they had EVER supported a business, instead buried their money in sacks.

The government tried to get it moving again, or pretend for a while that it hadn’t collapsed, making coins with increasingly ridiculous adulterated alloys.  But that didn’t change the underlying dynamic.

The Gold bugs of course have all told each other a different version of this story, where the adulterated coins were the cause of the collapse rather than the increasingly desperate attempt to recover from it.  And it’s pointless to try to convince them otherwise; they believe they already know the only possible truth. But for those actually motivated to investigate, the chronology of the events is reasonably clear.

===============================================================

The next thing is about “Proof-of-Total-Stake”, which I guess is what I’m going to call this idea for securing the chain.

The fundamental idea behind Proof-of-Total-Stake is that the priority of any branch of a fork is the total amount of EVERYBODY’s money which that fork represents.  That means, coins generated in that fork and pre-existing coins brought into the fork by transactions.

Coins generated in a fork are the coinbase transactions; Coins moved into the fork from earlier parts of the chain are TxOuts from earlier in the block chain that have been spent during the fork.

But we have to know which BRANCH of the fork they were spent into. ie, someone trying to create a fork should not be able to stick transactions from the valid branch of the chain into it, or they can match the txOut spending from earlier in the chain.  This is the basic problem with most implementations of proof-of-stake, which some writers have called “nothing at stake.”   Whatever resource you are using to secure the chain is meaningless when it can be used to secure *BOTH* forks of the chain.

In order to prevent the replay attack, each transaction would have to “stake” a recent block, making a commitment to supporting only forks which include that block.  This adds a field to each transaction.

The new field would give the (hash) ID of a block, indicating that this particular transaction is not valid in any branch of the chain which does not include the staked block.

So, let’s say that two transactions “coffee” and “eggs” are made at the same time,  after the chain forks at block 50.  “Coffee” stakes block 48 and “eggs” stakes block 51A.

When “coffee” appears in block 51B, the total stake of fork B is increased by that amount; its weight counts toward that resolution of the fork.

Then “eggs” is added to block 52A, and can’t be placed in chain B because it staked a block doesn’t exist in chain B.  Now “eggs” counts as stake in favor of the A branch and “coffee” counts as stake in favor of the B branch.

But then “coffee” appears in branch 53A, where it is also valid because the same block 48 is behind both branches.  This cancels out its support for branch B, just by being equal – revealing that stake which can be used in favor of both chains counts for nothing.

Security happens because some finite resource (coins created before the branch point and spent in transactions that are staked after the branch point) is committed detectably and irrevocably to the support of one branch (by staking after the branch point), and cannot be used to support any other.

This is exactly what Bitcoin does with hashes:  Hashes per second and number of seconds spent hashing are finite.  Hashes are irrevocably used in support of one branch (because the hash preimage can never be made to match a different block).  And the fact that they are used to support a particular branch is detectable.

Well, strictly speaking there’s only one “detectable” hash in each block. All we know about the others is, on average, how rare that one “detectable” one was and therefore, on average, how many they must have been.

But it’s still the same basic criteria.  Some finite resource, committed detectably and irrevocably to the support of one branch, which cannot be used to support conflicting branches.  And proof-of-total stake says that resource is the amount of EVERYBODY’s coins that branch represents.

With transactions supporting the basic security of the chain, and the idea behind coinbases being that they are payment for providing chain security, we want our “coinbases” to reward the people who make transactions that stake recent blocks.

PoTS is strong in the long run, or when the chain is seeing a high volume of legitimate transactions, but has its own problems.

Transactions in most cryptocurrencies are a very bursty use of something with long latent periods.  Absent heavy transaction volume, you can’t really expect PoTS to definitively reject a branch in such a way that a crook couldn’t resurrect it with a very large spend.  If the crook has more coins than the difference in total-stake between the two forks, the crook could resurrect the “dead” fork.

This is why the “interest” payments (actually per-transaction coinbases of a particular sort) when a transaction staking a recent block are made. To encourage a fairly constant stream of transactions that support one particular version of the chain up to a very recent block.

But the peril with that is that you want to structure it in such a way that you don’t incentivize people to overwhelm your bandwidth by transferring every coin they own from their left pocket to their right every block either.  So the actual design would come down to some compromise between transaction fees, and interest payments on transactions staked in very recent blocks, where the breakevens represent the transaction volume you want.

And there are a couple of final things to address together.  First, PoTS, while it has a workable rule for figuring out which branch of forks is preferred, is pretty silent about who gets to form blocks and how.  Second, Interest on coins spent has the “nothing to something” problem where if you don’t have anything in the system to start with, you won’t have anything ever.  These are both classic problem with PoTS coins.  The final design has to include some additional kind of coin creation that doesn’t depend on previous holdings (even if it gets de-emphasized after a while) and some way to determine who forms the next block.

Q9: ICOs have been around in some form or fashion for about five years now.  What’s your view on these fundraising schemes?

A9: The SEC is bouncing on them pretty hard, and as far as I can see it’s pretty much deserved.  Everybody wants something they can freely trade on secondary markets, and sell on the basis of its future value, but they also want to lie about it by saying it isn’t a security.

It is a security.  If a security is sold by a company to raise money, but does not represent a bond (a promise to buy it back) nor a stock (a share in future earnings) then an investor is getting nothing for her money – except maybe a receipt for having made a donation.

Another investor (a “real” investor who knows and understands a broad market, not a speculator who made a lot of money by a couple of strokes of sheer luck) will not buy it from them, at any price.  Such a thing has only speculative value.

If something’s continued value depends on a company, but the company’s continued existence doesn’t depend on that thing having value, it would be an excellent thing to not buy.

And all of that, we can say without ever touching on ethics and business practices of the people who run them.  But when we do touch on the people who run them, the story gets worse.  Much worse.  Much, much worse.  In this most are following the path trod by Altcoins.  And racking up a very similar ratio of efforts that fail, or which never even start to succeed.

Q10: You have alluded to tokenized securities in the LinkedIn article as well as our correspondence, what is your take on this topic?  What are the advantages versus say, simply doing what Carta (formerly eShares) does?

A10: I would have to answer that admitting to some degree of ignorance about Carta.  As I remember eShares, it was very much a top-down stock and option management tool, in that a private company with (non-traded) shares typically uses it to keep track of who owns what – actually issuing assets or recording changes in their status, making info about them available for the holders but mostly just to view online.

What it does not do, as I understand it, is directly enable the shareholders to trade those shares or options with each other.  Nor does it handle securities involved with or created by more than one company at a time.  It is a management interface, not a market.

I envision a block chain – sigh, now I have to come up with a name again.  Phooey.  I never care about naming anything, and then someone wants me to talk about one of my ideas and I have to come up with a name for it on the spot.  Let’s go for the pun and call it the Stock Trading and Options CryptoAsset Keeper.  I could come up with  something even dumber, but for the sake of exposition, call it STOCK.

The idea is that STOCK would act both as a Transfer Agent (which Carta does) AND a market (which AFAIK Carta does not).   A company could issue securities such as stocks and bonds directly on the STOCK block chain (“cryptoassets”) and the block chain could record trades in those issues against its native cryptocurrency.  The benefit here is the clear record and history to keep track of all trades and the current disposition of all the different cryptoassets – the stocks, the bonds, and the “cash” used to trade in them, would all be on the chain.

As long as no off-chain assets like bushels of wheat or truckloads of sneakers need to be delivered, and dividends/prices/etc accruing to these instruments are paid out (or in) in the cryptocurrency, the block chain could then function directly as market, transfer agent, means of delivery, and payment channel.  The task of converting the cryptocurrency to and from actual fiat, and the heavily regulated business of delivering the fiat currency, could be left to already-established cryptocurrency markets.

Trading in stocks/bonds/etc is highly regulated, and debts (NEGATIVE amounts) can crop up unexpectedly when companies go south or options traders go bust. Stuff gets into the RealWorld quickly when someone has to be found for debt payments, served process, and/or prosecuted for fraud, etc.  So STOCK couldn’t be an  “anonymous/permissionless” chain, at least not for regulated trades.  Each person or entity authorized to actually make securities trades would have to have a vetted, verified ID as specified by KYC laws, and would have to sign each such transaction with a public/private key pair proving Identity.

From the point of view of investors, STOCK would be a very sluggish market – submit your trade, have a completely random execution window averaging ten minutes (or whatever) during which the price might change, then a whole block of transactions all fly past at once and everybody’s waiting for the next completely randomly-timed block.  On the other hand, you don’t need an agent, or a broker, or a company transfer agent, or a registrar, or a clearance period, or ANY of those people who normally collect fees on every trade.  You could actually have a market where the buyer and seller get the exact same price with no ‘float’ whatsoever.  And you don’t have to worry about what time it is.  NASDAQ closes at 5PM new york time, and then a whole bunch of “off-market,” “private,” and “over the counter”  trades that nobody but the insiders can participate in or see happen. But STOCK would go on making blocks twenty-four hours a day seven days a week.  Why should it ever stop?

The SEC would be all over it of course; they’d be sticking a microscope up the butts of everybody involved to make sure that there was absolutely no scamming the investors.  Which is, after all, their job. And they’d require KYC compliance, and a whole lot of other regulatory compliance.  But, y’know, that’s kind of how starting any _legitimate_ business in financial services works.  No need to feel special or particularly victimized about that.

And the regulators would need some privileged keys that could be used to “seize” assets when a court orders them to, as part of a settlement for fraud or theft or something.  And everything else.  There’s a great irony that they’re interested in nobody having the opportunity to scam the investors, but they structurally require, just to be able to do their fundamental mission, builtins to the protocol that if misused would allow somebody to scam the investors.

But once satisfied and functioning within the law, I think they’d welcome STOCK as something that puts down a visible, provable, inalterable, unfakeable history of all trades.

Q11: Is there any cryptocurrency you think could become widely used outside of geeks, cypherpunks, and ideologues?  If not, what would need to change and how?  Has any popular coin ossified to such an extent that it can’t meaningfully evolve?

A11: Homer Husband and Harriet Housewife want convenience and familiarity. Which is mostly about form factor and compatibility.  They do not want to deal with key management in any form.

To do that, you have to make a hardware wallet small enough to fit into a wallet or a purse.  It doesn’t have to be literally credit card sized, but couldn’t be much bigger.  It should be the size of a stack of five credit cards, at most.  Or maybe it gets stuck back-to-back onto their cell phone.  It has to have an end that acts like a chip card, or an edge that acts like a mag stripe, or both, so that it can interact with the grocery stores, auto shops, restaurants, etc that Homer and Harriet already do business with.

That’s very very important, because Homer and Harriet aren’t evangelists.  The mechanic they’ve been going to for fifteen years has never heard of cryptocurrency and is never going to deal with the inconvenience of getting set up to accept it.  He wants people to pay cash or pay with a card, and Homer and Harriet would NEVER consider arguing with him about it, don’t want to go to the effort of explaining it to him, and probably couldn’t explain it very well anyway.  If they have to do any of those things, that’s a deal-breaker.

After that you have to get your cryptocurrency onto the Plus or Cirrus network, using the same interface as a foreign fiat currency.  That would allow Homer and Harriet to automate the sale and exchange to whatever local people think is money, or the purchase and exchange to crypto, when they want to spend or accept stuff from that “card.”  This will mean that they get hit with some extra fees when they use it, but
those fees are both unavoidable if you want to be on those networks, and relatively familiar to them.

Finally, there’s that key management thing.  You could handle most of it by making the wallet do it.  But sooner or later, that hardware wallet is going to fall and bounce of the curb, and go crunch under the tires of a bus.  Or, you know, get dropped into the ocean accidentally, or just get lost.

Homer and Harriet are NOT willing to accept that this is not something they can recover.  The only thing that they accept not being able to recover, when they lose their wallet, is familiar, folding fiat currency.  And that’s why they don’t keep very much of folding fiat actually in their regular wallets.

If you do convince them that losing the wallet makes the funds unrecoverable, they will never want to have more than fifteen dollars on it, which will mean it isn’t useful.  So, your hardware wallet has to interact with SOMETHING that keeps enough information about what’s on it, to enable a new wallet to recover everything that got lost.

Q12: Mining farms, mining pools, and ASICs. Many accounts are that Satoshi did not anticipate the full industrial scale these would reach.  Do you agree with this?  What are your views on mining pools and ASICs as we know them know today (specifically as described by Eric Budish’s paper)?

A12: My first problem with ASICs is that they can be used for exactly two things:  Mining cryptocurrencies, and carrying out attacks on cryptocurrencies.

Every day of every year, people who own those enormous ASIC farms are deciding which is the most profitable use of them, on that day.

And the rewards for mining cryptocurrencies ratchet downward every couple of years.

That seems problematic.  I keep watching to see what emerges each time the reward ratchets down, but I haven’t seen evidence yet that any of the big ASIC farms have turned around on any large scale.

My second problem with ASICs is that they are sucking up ridiculous amounts of energy that can never be recovered or used for anything else. I don’t so much mind this when converting the energy into heat is actually useful – replacing electric heaters in the basement of a building with a bank of Antminers that use the same amount of power is
energy-neutral and helps secure the chain.

But that’s not what happens in huge ASIC farms.  All that heat is just waste. Nobody’s home is made more comfortable, no furnace’s power bill is alleviated, no greenhouses are enabled to grow food in the winter, nobody’s oven gets to bake bread with that heat, and all that energy is just plain gone.

The Bitcoin chain issues the same number of coins per day regardless of how much energy is spent; I’d like to think that spending a whole lot less of it, at least in ways where the heat produced isn’t useful, would be better.

But then we get back to the first problem;  If honest miners start spending a whole lot less on the energy costs of hashing, then there’s a whole lot of ASICs not being used, and the owners of those are going to be looking around making their daily decision about what’s more profitable….

So the logic finally does work out the same. Security requires the vast majority of those ASIC boxes to be in use mining.  It just seems such a colossal expenditure of power, and it might be that a different design could have achieved chain security without that global cost.

My third problem with ASICs is that they have become a way for their owners to steal money from the taxpayers in many nations.  Countries that mean to do a good thing for everybody, create “development zones” with subsidized electricity, paid for by the taxpayers of that country. And then people move in with ASIC farms to suck up that electricity which the public paid for, and convert it into bitcoins in their private possession.  These are business that employ very few people, drive the development of no other resources, and otherwise do pretty much nothing for the development of the local economy.  IOW, the taxpayers who paid for that electricity are definitely not getting their money’s worth in economic development.

My fourth problem with ASICs is that there really is no way to monitor centralization of hashing power.  People keep pretending that they’re tracking whether a 51% attack is underway, but I think most of them probably suspect, as I do, that what they’re really tracking is probably nothing more than whether or not the cabal of ASIC farm owners
remembered to configure that new warehouse full of machinery to use a different identifier.

In all fairness, this last thing results directly from anonymous, permissionless mining, which is something that was a very specific and very much desired part of Satoshi’s vision; he wanted anybody to be able to connect and participate, without any interference of a gatekeeper. But there can never be security from a Sybil attack when you don’t have any way of tracking RealWorld identities, and a “majority” can never be
relied on to be more than the front for some cabal or business interest, as long as a Sybil attack is possible.

And that was what Proof-of-work was supposed to prevent.  In those early days everyone was thinking of hashing power as a side effect of computing infrastructure that was likely to be there, or be useful, for other purposes when it wasn’t hashing.  And EVERYBODY has a use for warehouses full of computers, so it was easy to think that hashing power would remain at least somewhat distributed.  The idea that someone would amass enormous numbers of special-purpose machines which made every other kind of computer in the world utterly useless for mining and which are themselves utterly useless for any other job (except attacking the network), was not, I think, really considered.

Satoshi definitely understood, and planned, that there would probably be server farms devoted to mining and that economies of scale and infrastructure would eventually drive individuals with ordinary desktop machines out of the mining business by being more efficient and making it unprofitable for the less efficient machines.

But I’m pretty sure he didn’t think of miners in places with artificially low subsidized rates for electricity outcompeting all other miners because of that advantage, driving the concentration of the vast majority of hashing power into just one country where it’s subject to the orders and whims of just one government and a few businessmen who
pal around with each other.

So he probably figured, yes, there’d be a few dozen large-ish server farms and a couple hundred small-ish server farms, but I’m pretty sure he envisioned them being scattered around the planet, wherever people find it worthwhile to install server farms for other reasons.

I’m fairly sure Satoshi’s notion of the eventual centralization of hashing power didn’t really encompass todays nearly-complete centralization in a single country, owned by a set of people who are subject to the whims and commands of a single government, who very clearly know each other and work together whenever it’s convenient.

And I find it worrisome.

Those enormous mining farms, and the way economics drove them together, are a structural problem with converting electricity into security.

I am not comfortable with the implication that, for any Proof-of-Work block chain including Bitcoin, economics will eventually devolve to the point where, when Beijing says ‘jump’ the mining and security of that block chain says ‘how high?’

And that is one of the greatest reasons why I look around for a different means of securing block chains.

El Fin