đ—Șđ—ąđ—„đ——đ—Š

đ—Șđ—ąđ—„đ——đ—Š

đ—Șđ—ąđ—„đ——đ—Š is a bastion of Bitcoin knowledge. Read đ—Șđ—ąđ—„đ——đ—Š.

July 2017 Journal

48 minute read

WORDS is a monthly journal of Bitcoin commentary. This issue collects the July 2017 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

Bitcoin is just like the Dutch tulip bubble.

By Yan Pritzker

Posted July 3, 2017

If you could use tulips to transmit value across the globe instantly to anyone in any country regardless of whether they had a functioning government or banking system.

If the government couldn’t come to your door and take away your tulips or control who you could sell them to or in what ways.

If tulips could last for hundreds of years or millennia and be handed down to your children and then redeemed for other forms of value.

If you could hide tulips in your brain and walk out of a failing nation holding all your wealth in your head without anyone being the wiser.

If you could program tulips to require authorization from multiple parties before they could be passed on in a way that was completely unbreakable.

If it was impossible to grow inferior malnourished tulips by skimping on nutrients and sell them like the real deal.

If each tulip carried inscribed on its petals its entire unforgeable history of ownership.

If someone couldn’t invent a superior way to produce tulips and flood the market to crash the price.

Yep, bitcoin is the Dutch tulip bubble.

Proof of Stake is Still Pointless

By Paul Sztorc

Posted July 7, 2017

I go line-by-line against Vitalik’s Proof of Stake FAQ. PoS is still just as expensive as PoW (but it may have different security features).

Proof of Stake is Back

Yesterday I noticed that someone from Ethereum has responded to my August 2015 article “Nothing is Cheaper than Proof of Work” on their Proof of Stake FAQ.


and now I see that it was written by Vitalik Buterin himself, almost a year ago (!).

Oh, brother..

I’m not sure it makes any difference at this point, but I started this so I suppose I may as well finish it.

Here we go!!

The Claim

Doesn’t MC => MR mean that all consensus algorithms with a given security level are equally efficient (or in other words, equally wasteful)? > > This is an argument that many have raised, perhaps best explained by Paul Sztorc in this article. Essentially, if you create a way for people to earn $100, then people will be willing to spend anywhere up to $99.9 (including the cost of their own labor) in order to get it; marginal cost approaches marginal revenue. Hence, the theory goes, any algorithm with a given block reward will be equally “wasteful” in terms of the quantity of socially unproductive activity that is carried out in order to try to get the reward.

Yep.

Vitalik’s phrase “equally efficient” is vague, but fortunately he clarifies it to mean “equally wasteful”. So, we’re back in business.

Vitalik Seeks a Work-Independent Protocol

There are three flaws with this: > It’s not enough to simply say that marginal cost approaches marginal revenue; one must also posit a plausible mechanism by which someone can actually expend that cost. For example, if tomorrow I announce that every day from then on I will give $100 to a randomly selected one of a given list of ten people (using my laptop’s /dev/urandom as randomness), then there is simply no way for anyone to send $99 to try to get at that randomness. Either they are not in the list of ten, in which case they have no chance no matter what they do, or they are in the list of ten, in which case they don’t have any reasonable way to manipulate my randomness so they’re stuck with getting the expected-value $10 per day.

Vitalik correctly notes that there must be a “plausible mechanism” to turn work into blocks. In other words, there must exist a f1 of type { work –> result }. We might call this the “workability” of the protocol – the extent to which it can be “worked”.

However, Vitalik ignores that I address this here by saying that, in a peer to peer network, all f’s that map to result (ie, every f which { ?? –> result } will have an input which is work related. In other words, the f1 in question will always exist. All protocols are “workable”.

Amazingly, Vitalik gives an example which is so bad, it almost proves my point by contradiction. He uses “my [Vitalik’s] laptop’s /dev/urandom” as an example of something which cannot be “worked”. His example cannot be worked, because and only because it is not P2P – it is a trusted 3rd party source of randomness.

(In practice it is not even true that his scenario is “unworkable”, as a prospective “worker” could try to bribe Vitalik, or could try to hire people to track down his laptop’s physical location and then take it from him at gunpoint).

MC => MR does NOT imply total cost approaches total revenue. For example, suppose that there is an algorithm which pseudorandomly selects 1000 validators out of some very large set (each validator getting a reward of $1), you have 10% of the stake so on average you get 100, and at a cost of $1 you can force the randomness to reset (and you can repeat this an unlimited number of times). Due to the central limit theorem, the standard deviation of your reward is $10, and based on other known results in math the expected maximum of N random samples is slightly under M + S * sqrt(2 * log(N)) where M is the mean and S is the standard deviation. Hence the reward for making additional trials (ie. increasing N) drops off sharply, eg. with 0 re-trials your expected reward is $100, with one re-trial it’s $105.5, with two it’s $108.5, with three it’s $110.3, with four it’s $111.6, with five it’s $112.6 and with six it’s $113.5. Hence, after five retrials it stops being worth it. As a result, an economically motivated attacker with ten percent of stake will inefficiently spend $5 to get an additional revenue of $13, though the total revenue is $113. If the exploitable mechanisms only expose small opportunities, the economic loss will be small; it is decidedly NOT the case that a single drop of exploitability brings the entire flood of PoW-level economic waste rushing back in. This point will also be very relevant in our below discussion on capital lockup costs. Proof of stake can be secured with much lower total rewards than proof of work. What about capital lockup costs?

Here, Vitalik gives an example where a blockreward can be “worked” in two ways. The second (“forcing a reset”) is irrelevant, but this is the one which he carefully elaborates. But the first “capital lockup costs” is relevant, and it is de-emphasized.

My simple equation does not require that the “workers” attack the system. If the total reward is $1000, then the total waste will be $1000, and it will all take the form of capital lockup costs. This would still be true (ie, I would still be right), if it were impossible to reset the randomness.

For Vitalik has neglected the “very large set”. It will indeed be very large, and it will be very very wasteful. Capital which is attempting to be staked must, necessarily be “locked up” to at least a minor extent. And if this is not the case in the protocol, it is the case in practice – money that is waiting to be staked cannot be turned toward other purposes. The fact that these “bonds” might be very short-term, will only make them more convenient which will only make the “very large set” even larger – and more wasteful. Instead of two medium numbers multiplied together, we will have a small number multiplied by a large number (but the product will be the same).

If these funds are not officially regarded as “staked” (ie, locked for a full year), we might call them “prestaked” for a day, or an hour. Instead of buying PoW lottery tickets, they will buy prestake PoS lottery tickets in order to win the privilege of becoming a validator.

There are other problems, but they distract from the overall message of MC=MR. Instead, just imagine the total reward is $1000, and that the randomness can not be messed with. In such a case, individuals will tend to invest (“stake”, or “prestake”) a marginal dollar, until the MC=MR, as I suggest. Imagine it were any other way, for example that MC<MR? This would imply that the first person to invest $1 in staking (in joining the “very large set”) would get an expected return of more than $1. So, this will obviously draw more capital in.

Vitalik’s example assumed that Waste = Attack. But this is not necessarily the case; if Attacks = 0 then Waste will just equal regular Work.

lower total rewards

We’ll get back to this “security” claim later.

The Waste-Equivalence Argument, Restated

Locking up X ether in a deposit is not free; it entails a sacrifice of optionality for the ether holder. Right now, if I have 1000 ether, I can do whatever I want with it; if I lock it up in a deposit, then it’s stuck there for months, and I do not have, for example, the insurance utility of the money being there to pay for sudden unexpected expenses. I also lose some freedom to change my token allocations away from ether within that timeframe; I could simulate selling ether by shorting an amount equivalent to the deposit on an exchange, but this itself carries costs including exchange fees and paying interest. Some might argue: isn’t this capital lockup inefficiency really just a highly indirect way of achieving the exact same level of economic inefficiency as exists in proof of work? The answer is no, for both reasons (2) and (3) above.

Let me restate my argument by comparing and contrasting PoW and PoS.

In PoW, you do the following: borrow $W1 money at rate r, buy a bunch of equipment and electrical power, earn BTC, and then liquidate everything and repay what you can, which is $W2 (which is very little, possibly zero). You have come up short, spending a total of $A = (W1*R)-W2 , but meanwhile you have earned $A worth of BTC.

(note: R = (1+r), the loan factor)

In PoS, you do the following: you borrow $S1 money at rate r, “stake it” (ie lock it away for a year, or a day or whatever), earn ETH, get the staked funds back, and repay the loan, which is $S1. But because interest rates were not zero, you still come up short. You invested a total of $B = (S1*R)-S1 , but earned $B worth of ETH.

In PoW, you paid cost_w = (W1*R)-W2 .
In PoS, you paid cost_s = S1*r .
In PoW you received benefit_w = $A worth of BTC.
In PoS you received benefit_s = $B worth of ETH.

This is all quite basic, and possibly undisputed.

The point I have made since Nov 2014, is that the second half of each sentence drives the first (ie “earned $B worth of ETH” determines how much total money is deployed in “borrow $S1 money”). And therefore the social waste per block will equal the block’s value.

If the benefit of mining, or of stake-ing, is higher then the cost, more people will do it. In practice there is no way to prevent people from staking (where this is defined as: joining the “some very large set” above). At least, there is no P2P way, because all are equal peers, and so no one has the privilege of denying someone entry.

So, if a blockchain currently emits X = $A worth of value in each block, then this blockchain gains nothing by switching to proof of stake. For a given X = $A, all four quantities would be the same: cost_w = cost_s = benefit_w = benefit_s . They are all equal to $X (call it: the “critical $X”).

I really have no idea if Vitalik disputes any of the above facts (which are all that I require to prove my “equally wasteful” thesis).

Waste is Different From Security

Now, we return to the point that we passed over earlier.

Below, Vitalik argues that the security, ie what an attacker would have to pay, is different under PoW and PoS. Specifically, he summarizes it (correctly) as “[the above] serves to show
that PoS gets more bang for its buck in terms of security”.

Let us start with (3) first. Consider a model where proof of stake deposits are infinite-term, ASICs last forever, ASIC technology is fixed (ie. no Moore’s law) and electricity costs are zero. Let’s say the equilibrium interest rate is 5% per annum. In a proof of work blockchain, I can take $1000, convert it into a miner, and the miner will pay me $50 in rewards per year forever. In a proof of stake blockchain, I would buy $1000 of coins, deposit them (ie. losing them forever), and get $50 in rewards per year forever. So far, the situation looks completely symmetrical (technically, even here, in the proof of stake case my destruction of coins isn’t fully socially destructive as it makes others’ coins worth more, but we can leave that aside for the moment). The cost of a “Maginot-line” 51% attack (ie. buying up more hardware than the rest of the network) increases by $1000 in both cases. > >Now, let’s perform the following changes to our model in turn: > > Moore’s law exists, ASICs depreciate by 50% every 2.772 years (that’s a continuously-compounded 25% per annum; picked to make the numbers simpler). If I want to retain the same “pay once, get money forever” behavior, I can do so: I would put $1000 into a fund, where $167 would go into an ASIC and the remaining $833 would go into investments at 5% interest; the $41.67 dividends per year would be just enough to keep renewing the ASIC hardware (assuming technological development is fully continuous, once again to make the math simpler). Rewards would go down to $8.33 per year; hence, 83.3% of miners will drop out until the system comes back into equilibrium with me earning $50 per year, and so the Maginot-line cost of an attack on PoW given the same rewards drops by a factor of 6. > Electricity plus maintenance makes up 1/3 of mining costs. We estimate the 1/3 from recent mining statistics: one of Bitfury’s new data centers consumes 0.06 joules per gigahash, or 60 J/TH or 0.000017 kWh/TH, and if we assume the entire Bitcoin network has similar efficiencies we get 27.9 kWh per second given 1.67 million TH/s total Bitcoin hashpower. Electricity in China costs $0.11 per kWh, so that’s about $3 per second, or $260,000 per day. Bitcoin block rewards plus fees are $600 per BTC * 13 BTC per block * 144 blocks per day = $1.12m per day. Thus electricity itself would make up 23% of costs, and we can back-of-the-envelope estimate maintenance at 10% to give a clean 1/3 ongoing costs, 2/3 fixed costs split. This means that out of your $1000 fund, only $111 would go into the ASIC, $55 would go into paying ongoing costs, and $833 would go into hardware investments; hence the Maginot-line cost of attack is 9x lower than in our original setting. > Deposits are temporary, not permanent. Sure, if I voluntarily keep staking forever, then this changes nothing. However, I regain some of the optionality that I had before; I could quit within a medium timeframe (say, 4 months) at any time. This means that I would be willing to put more than $1000 of ether in for the $50 per year gain; perhaps in equilibrium it would be something like $3000. Hence, the cost of the Maginot line attack on PoS increases by a factor of three, and so on net PoS gives 27x more security than PoW for the same cost. > The above included a large amount of simplified modeling, however it serves to show how multiple factors stack up heavily in favor of PoS in such a way that PoS gets more bang for its buck in terms of security. The meta-argument for why this perhaps suspiciously multifactorial argument leans so heavily in favor of PoS is simple: in PoW, we are working directly with the laws of physics. In PoS, we are able to design the protocol in such a way that it has the precise properties that we want - in short, we can optimize the laws of physics in our favor. The “hidden trapdoor” that gives us (3) is the change in the security model, specifically the introduction of weak subjectivity.

In may be the case that PoS gets more bang for its buck, which is to say that PoS gets more “security” per blockreward value (ie, per “critical X”, or per “wasted” dollar), than would PoW.

(This is exactly the argument that Jae Kwon of Tendermint retreated to, after admitting that PoS was indeed just as wasteful as PoW.)

In my 2015 article, I emphasize that PoS is allowed to have different (probably worse) security assumptions than PoW:

I highly doubt that PoS is more secure. Perhaps it is, but I still wonder what would happen in my original scenario:

  1. Attacker 
purchases “used” private keys
  2. 
executes a large long-range NaS attack (making a trillion fake histories, that all look very very similar to each other) [cost: ~free],
  3. 
threatens to imprison/kill anyone who tries to point out which history is real [cost: mafia connections, law enforcement, or a couple million $$]).

I think it is hard for Vitalik to both [a] constantly tell us which PoS chain we should be on, and [b] constantly evade capture by the mob / world governments / private investigators.

And, last I heard, there were all kinds of scalability / uptime problems with PoS, which again I am going to just ignore. (And these are just the known/theoretical problems – remember how much we have learned about PoW’s little quirks [block withholding, selfish mining, relay/broadcast strategy, ASICBoost, etc] in just a few years of using it in practice).

For now lets just say that PoS does indeed get more bang for its buck – this is irrelevant to my argument about waste. Even if PoS is more secure than PoW, it is still just as wasteful as PoW. The “buck” of PoS is the same as the “buck” of PoW, whatever their respective “bangs”.

What Vitalik is trying to say (I assume) is that, since the security is lower, we can then, safely, decrease the critical X.

However, this notion, that one can control the critical X is a fallacy that I (in 2015) purposefully delayed handling



until the end of the piece.

Since Vitalik already ignored it once, I’m not sure what good it will do to repeat it, but here goes!

The Coinbase-Rot Paradox (Reprise)

Trying to reduce waste only re-increases the waste, and vice-versa.

How PoS Might Cash In on the Additional PoS Security

Ethereum might want to take advantage of the supposed PoS security advantage, by decreasing its Critical X, and thereby being less “wasteful” than Bitcoin. But how might it do this? It must decrease the value of its blockreward!

Blockreward = C "coins released" * M "market price per coin".

Ethereum can’t magically alter the market price (and if they could, they would hardly want to send it downward (!), as would be required in this case), so their only option is to try to decrease factor C, the quantity of Ethers released per block.

The Problem with That Strategy

First of all, I wonder if the PoS supporters know that Vitalik is essentially saying “we need to work on PoS so that we can achieve our goal of making sure that, relative today, a higher percentage of Ethers are mined in the future!”. Somehow I doubt it.

But there’s actually an even bigger problem. As I stated in my piece nearly two years ago, moving C down will tend to move M up, because:

  1. Logically, the blockchain must start with 0 coins issued, and end with 100% of coins issued. Thus the blockchain-designer (ie Vitalik) can only control the speed of issuance – he may choose a big candle with a slow fuse, or else he may choose a short candle with a quick fuse.
  2. Slowing the issuance speed, will cause today’s quantity of CryptoCoin issued per block to decrease. Hastening the issuance will necessarily require that more CryptoCoin be issued per block today.
  3. The units of money are fractional (as Vitalik ought to know), which is why inflation is a tax, and why switching from dollars to cents (or to millicents) would not directly affect anyone’s net worth.
  4. Thus, someone who buys into a slow candle will “own more money longer”. Someone who buys into a fast candle will own more money shorter. As a result, the market value of fast candle coins will be less than that of slow candle coins.

Item #2 is the “coinbase” part, and #4 the “rot” part of what I called the “Coinbase-Rot Paradox”.

And the paradox is likely to be quite strong.

Allow Me to Elaborate

Consider that society, in a given year, demands X amount of briefcases, and Y amount of refrigerators, and Z amount of money. If Ether were the only money in existence (ie, if no one used USD, gold, etc as money anymore), then public demand for it would total some amount (let’s call it “Sigma”, and let us measure it in purchasing power [as in $PPP]). So, the public wants Sigma$ worth of Ether to exist in the year 2017. In a world with fast Eth, the Eth price is Sigma$ / q_fast , but in a world with slow Eth, the Eth price is Sigma$ / q_slow .

q_slow is, paradoxically, growing at a faster rate, than q_fast!

q_fast :    4, 4, 2, 2, 1, 1, .5, .5 ;  [8 years, 15 total]
q_medium : 1.875, 1.875, ... , 1.875 ;  [8 years, 15 total]
q_slow :   .5, .5, 1, 1, 2, 2, 4, 4  ;  [8 years, 15 total]

Money supply growth rate in period 3:

g(q_fast, 3):    25%  (ie, 2/8)
g(q_medium, 3):  50%  (ie, 1.875/(1.875*2))
g(q_slow, 3):   100%

The math probably comes out to be a complete wash (in other words, that the Critical X cannot be altered at all), but perhaps not – I haven’t checked. I’m really not interested in this question, so perhaps you, the reader can put some thought into it. Perhaps there is an optimally slow issuance schedule.

Whatever the case may be, Vitalik/Kwon’s argument that “PoS is more secure” ends up translating only to a claim that “Bitcoin is too vulnerable to 51% attacks”. Even if every single one of their claims is correct (not likely), then the entire PoS project only amounts to a blockchain which is harder to 51% attack, but otherwise equally wasteful of resources. (Given that Bitcoin has been 51% attacked zero times, this would seem to be a dubious investment of resources.)

Let me repeat: the security level has nothing to do with my claim that PoW and PoS are equally wasteful. If Vitalik derives some rule for an optimally slow issuance schedule, then someone could just plug that schedule into a PoW chain, and that PoW chain would have the same (lower) economic waste (at an allegedly lower security level). Which is my point. Switching from PoW to PoS doesn’t matter. Both PoW and PoS will waste exactly the same amount: their Critical X.

So lowering the Critical X means that the protocol exhibits lower waste under PoS and a lower waste under PoW.

Because they’re THE SAME THING!!

Other

Vitalik continues, so I suppose I will as well:

Now, we can talk about the marginal/total distinction. In the case of capital lockup costs, this is very important. For example, consider a case where you have $100,000 of ether. You probably intend to hold a large portion of it for a long time; hence, locking up even $50,000 of the ether should be nearly free. Locking up $80,000 would be slightly more inconvenient, but $20,000 of breathing room still gives you a large space to maneuver. Locking up $90,000 is more problematic, $99,000 is very problematic, and locking up all $100,000 is absurd, as it means you would not even have a single bit of ether left to pay basic transaction fees. Hence, your marginal costs increase quickly. We can show the difference between this state of affairs and the state of affairs in proof of work as follows:

In the above paragraph, Vitalik draws a marginal/total distinction
but it is (seemingly) on the wrong variable.

I am saying that, to generate a block, users will pour forth effort ($PPP) totaling that of the block’s sale value (in $PPP). If MC is below MR, more people will take advantage of this opportunity to earn free money. If MC is above MR, some people will cease this activity (as it is deleting their money). In equilibrium the MC=MR, as taught to all ECON 101 students.

Vitalik is saying that, in pouring forth the effort, users will care relatively less and less about each dollar locked up. Locking up the first 1% of their net worth (ie just 1%) will not “hurt” as much as locking up the last 1% (ie, all 100% of it).

In other words, I am saying that “the auctioneer is selling $100 worth of gold, and people will keep bidding on it until the price reaches $100”. And Vitalik is saying “well, you are so rich that you can easily spare some of these $20 bills you have lying around”.

There is no contradiction whatsoever between the points. Vitalik is simply looking at a different variable.

In fact, when he says:

Hence, the total cost of proof of stake is potentially much lower than the marginal cost of depositing 1 more ETH into the system multiplied by the amount of ether currently deposited.

If this were true, what it would actually mean is that a higher quantity of Ether would be locked up. So it would be more wasteful!

For example, imagine that annual Ethereum tx fees + block subsidy, for the whole year, total only $10,000,000. But also imagine that many Eth-users do not care to use their parked Ether at all in the next year. All of the indifferent Ether would be staked – call it 2 billion USD, at today’s prices. A 2 billion dollar investment can guarantee one at least 24 million dollars or so, but the PoS project is only bringing in 10 million. An additional 14 million has been wasted.

( Users could buy a forward contract to repurchase their ETH next year (at today’s prices), sell it all today, buy Treasury Bonds, earn 24 million, and execute the forward contract to repurchase their ETH. They would be exactly where they were today, but they would have 14 additional million USD. )

Note that this component of the argument unfortunately does not fully translate into reduction of the “safe level of issuance”. It does help us because it shows that we can get substantial proof of stake participation even if we keep issuance very low; however, it also means that a large portion of the gains will simply be borne by validators as economic surplus.

As stated above, I object to the possibility of “keeping issuance low” (which is the Coinbase-Rot paradox). And I disagree that there will be economic surplus. I think Vitalik is overestimating the size of these “gains” – they would be tiny breadcrumbs spread over a vast population of stakers. And staking would be annoying, and so per capital (or per staked $) there would likely be very low surplus.

As I pointed out in the original article, claiming that “it is very easy to stake” is analogous to claiming that “it is very easy to hash”. But greater efficiency of mining equipment merely results in correspondingly greater hashing. To see this, imagine two worlds in which the block reward is worth $100: inefficient and efficient. In the inefficient world, hashes cost $1/hash, but in the efficient world they cost $0.00001/hash. In both worlds, miners will spend $100 total – in the first, on 100 hashes; in the second, on 1,000,000 hashes.

Summary

We have three major differences, as I see them:

  1. Vitalik believes that “prestaked” funds do not count as “locked up”, even though funds cannot be used for two purposes at once.
  2. Vitalik does not endorse the Coinbase-Rot paradox, for unknown reasons.
  3. Vitalik continues to believe that staking is not a big deal because it is easy and convenient to do. I agree, but Vitalik does not reply to my argument that –if staking is indeed very easy and convenient– it will result in tremendously high rates of staking, resulting in great waste (and tiny rewards per staker).

We agree that PoS and PoW can have different security levels and different security models. Vitalik thinks he can trade off some of this security, in return for reducing waste, but he has not explained how he plans to do this to my satisfaction (ie, the C-R paradox). It is also unclear to me if this is even desirable (perhaps security is generally more important than ‘waste’).

I suppose that Vitalik’s strongest pro-PoS argument, would be to take the first objection and try to argue that ‘there is no investment which is comparable to pre-staking’, therefore, society does not have to forgo anything as it watches users compete with each other over where/how to temporarily lock their checking accounts. Vitalik could try to argue that he had created something new and valuable (the ultra-short duration investment) at exactly the same time that he had “wasted” it. This is similar to Bram Cohen’s PoSPaT which would make unused hard drive space valuable and then immediately consume (“waste”) this value.

However, this is difficult, as short-duration investments (eg, 4 week treasury bond, savings account for 1 month, commercial paper) already exist. And even if they did not exist today, ultra-short duration investments could be invented. Similarly, Bram’s examples would “re-become” wasteful if something like Sia or (old-style) Wuala ever got off the ground.

Conclusion

I go through the PoS FAQ (where my arguments are mentioned) and reply, line by line.

I still do not believe that PoS represents a significant improvement over PoW. A world of PoS is still one of greater scarcity of capital, and a world of PoW is still one of greater scarcity of silicon/electricity. The dollar value (or gold value) of each of the two types of waste will tend to be exactly equal.

PoS is theoretically very similar to PoW. But in practice, we have more experience with PoW. A practical person would re-use what already works. However, PoS very suspiciously requires a team of highly skilled researchers to constantly be looking in on it. I continue to believe that this PoS research is itself a ‘waste’ of money and time, as it can’t really accomplish anything (and, in practice, doesn’t).

Add Disqus comments.

comments powered by

Disqus

Platform currencies may soon be obsolete

By Aleksandr Bulkin

Posted July 11, 2017

Here is my claim. Within 5 years the biggest cryptocurrency by market cap will not be Ethereum or any other platform currency. Instead, it will be an application token.

Yes, I said it. Ether (both real and “classic”) may be entirely obsolete and so will Atoms, Tezzies, and all others whose use is to pay for transaction capacity in a single blockchain network.

Let me explain.

The current investment thesis for platform currencies is usually based on the following claims:

  1. That network effects cause a single currency or just a few currencies to accrue most of the value in the space.
  2. That a single currency will serve as a dominant tool for injecting value into ICOs (this is Ether’s primary role today).
  3. That a single blockchain can and will host most of the dApps that generate value in the space.

All of these claims may be false in the long term.

  1. It is a mistake to think that network effects matter for cryptocurrencies. Cryptoexchange technology (both centralized and decentralized) is maturing every day, while at the same time multi-currency wallet technology becomes increasingly more accessible. As frictions to holding and exchanging multiple cryptotokens decrease any payment system and any financial flow whatsoever can easily extend to all existing cryptocurrencies. At that point it will matter not whether you use Ether, Bitcoin or any other token — all will work equally well.
  2. Ether became a dominant currency for token sales because it allows for their execution via smart contracts when project founders are distributing new ERC20 tokens. This is a significant selling point, but we do notice that many token sales today accept bitcoin and some accept other currencies as well. Blockchain interoperability technology via oracles both centralized and decentralized is maturing as fast as exchanges. Eventually a smart contract will be able to seamlessly issue tokens on one blockchain in response to events observed on others.

This shows that it is not at all necessary for a platform currency to become a large store of economic value. The next point provides a reason for why it is likely that the space will move away from this model altogether. The reason is that hosting all dApps on a single blockchain (and consequently relying on a single platform currency) is, actually, a very bad thing.

Consider two events: the DAO hack and the recent Status crowdsale. The first caused Ether price to drop by two thirds while the latter caused the Ethereum network to virtually stop processing transactions for an extended period time. These are both examples of inter-application contagion. The first one is economic: when one application suffers a collapse all other applications suffer from a perception spill-over of that collapse. The other is technical: when one application causes the transaction volume on the network to spike all other applications suffer from slowdowns and transaction bottlenecks.

Inter-application contagion is the reason why dApps that require reliability of both throughput and economic value may start choosing to host themselves on a separate blockchain altogether. And what could be easier? It is not that hard to clone the Ethereum blockchain with a different root block, crowdfund by selling the premined currency of that blockchain instance,and operate completely independently from others without worries of contagion.

Of course this can’t happen today. The reason is very simple: proof-of-work consensus requires miner cycles to secure the blockchain. Absent miner interest an Ethereum clone can’t operate. Miners look for the most profitable work per GPU cycle, and an upstart Ethereum clone isn’t going to look good to them. But not so when proof-of-stake consensus (Casper or BFT) becomes operational. When this happens a single node can validate as many blockchains as it has disk space for. Crowdsale participants can setup validator nodes and off we go.

The outcome is clear: platforms will be irrelevant and easily cloned. Application currencies will be tied to their own blockchain instances and will dominate the space.

Obviously, the picture I am describing here is years away. There still are a few pieces of technology that need to be perfected before we will see it play out. For the near term Ether and Bitcoin may remain both a store of economic value, de-facto index assets, and currencies intimately tied to the cryptoinvestment process. But I predict a cryptocurrency future less “maximalist” and more diverse than the conventional wisdom thinks.

Thanks to Greg Meredith ofRChainfor inspiring some of these thoughts.

CoinFundis a blockchain technology research company, advisory team, and private cryptoasset-focused investment vehicle. We work with companies in the blockchain space and beyond to understand how blockchain-based economics can be used for financial applications such as crowdfunding, and more. If you’re a blockchain project or are interested in exploring blockchain technologies for your product, pleaseget in touch with usor join us in theCoinFund Slack.

What did Bitcoin Core contributors ever do for us?

By John Newbery

Posted July 21, 2017

This afternoon, I tweeted a response to the strange suggestion that we fire core. I’ve ignored the fact that Bitcoin Core isn’t a person or an organization (in the traditional sense), and that everyone is perfectly free to run their own re-implementation of Bitcoin, but instead focused on a few of the things you’d need to do if you were serious about rejecting the work of the Bitcoin Core contributors.

I’ve included a mix of enhancements that have been around for one or more releases, stuff that’s going in to 0.15 right now, and longer-term development or research work. People who don’t actively follow the bitcoin core github repository probably aren’t aware of the wide range of work that the contributors are doing. Hopefully this gives some insight into that world.

Disclaimer: I contribute to Bitcoin Core.

So here goes, what have Bitcoin Core developers ever done for us?

libsecp256k1 is a heavily optimized library for doing elliptic curve math over Bitcoin’s secp256k1 curve. Elliptic curve math is used for creating signatures to spend transactions, and for validating signatures in transactions that you receive from the network. In addition to being several times faster than OpenSSL, libsecp256k1 has much better protection against timing, derandomization and side-channel attacks. Bottom line: transaction signing/validation is faster and more secure.

libsecp256k1 was mostly written by Pieter Wuille, Andrew Poelstra, Peter Dettman and Greg Maxwell, and started being used by Bitcoin Core in v0.12. Pieter, Andrew, Peter and Greg continue to maintain and make improvements to libsecp256k1.

Pruning allows a full node to discard old blockchain data, while still fully validating all the consensus rules. It means that users can run a Bitcoin Core node on diskspace-constrained hardware and enjoy the exact same security of running a full node. The blockchain is now over 125GB, but a pruning node can be fully synced to the network with just 2–3GB of disk storage.

Automatic pruning functionality was added in Bitcoin Core V0.11. The code was mostly written by Suhas Daftuar, Alex Morcos, Adam Weiss and Brad Andrews. Pruning was further improved in V0.14 to allow pruning to be run manually by the user. Principal contributors were Brad Andrews and Russ Yanofsky.

Multiwallet is a long-requested and wanted feature that has finally been merged in v0.15 🎉. This allows users to have completely segregated wallets, for use-cases such as separating business and personal accounts or having wallets for different purposes running concurrently. We don’t yet have separate authentication for different users, but future versions may allow multiple users to safely access different wallets on the same Bitcoin node.

Luke Dashjr contributed multiwallet in V0.15. The RPC interface was provided by Jonas Schnelli.

Having a fast, efficient networking layer is essential for quick block/transaction propagation and the overall health of the network. The faster that blocks are able to propagate through the network, the lower the block orphan rate, and the more secure the network is.

Cory Fields has been doing continued work to refactor the networking code for several releases, with a major and significant improvement delivered in V0.14. V0.15 and future releases will continue to see improvements in cleaning up and isolating the network code from the server code.

One of the most exciting benefits of segregated witness is that it gives us the ability to upgrade the scripting language. There are several exciting script upgrades under investigation, but the one that will probably get most attention in upcoming releases is Schnorr signature support. Schnorr signatures are an alternative signature scheme to the currently used ECDSA which allow multiple signatures to be added together or ‘aggregated’. This is a win for scalability (since if multiple signature are added together, the aggregated signatures takes up only as much space as one of input signatures), validation cost (since only one signature needs to be validated instead of many) and privacy (since an aggregated signature doesn’t reveal whether the input was a single signature or many signatures).

Greg Maxwell, Pieter Wuille and Andrew Poesltra have been investigating Schnorr signature aggregation, particularly working to make sure that the aggregation scheme is safe from the signature cancellation problem.

Currently, Bitcoin Core exists as a single process, with shared memory access between the network code, consensus code, wallet code and user interface code. Ideally we’d like to separate the wallet into a separate process, so if the networking function was hacked or compromised, your wallet function and private keys would be safer.

Russ Yanofsky has been doing the groundwork for process separation during V0.15. Look out for further progress in this area in V0.16 and V0.17.

Every transaction submitted to the Bitcoin network attaches a user-chosen fee, which goes to the miner who confirms that transaction in a block. Set the fee too low and your transaction won’t get confirmed in a block. Set it too high and you’ve donated money to the miner unnecessarily. Between those two extremes is a continuum of where to set your fee — a high fee will probably get you confirmed in the next block, a slightly lower fee might see your transaction confirmed in the next 3 or 4 blocks, and even lower than that and your transaction could take a few hours to get confirmed. Choosing the correct fee for your transaction is a hard problem, requiring knowledge of the current state of the network and some smarts to predict what will happen depending on where you set the fee.

Alex Morcos has spent a lot of time thinking about and analyzing fee strategies and significantly improved the fee logic in V0.15.

Bitcoin Core runs multiple threads so different tasks can be run in parallel on a multi-core computer. However, a lot of the functions grab a ‘global lock’ before doing their work, and other threads need to wait for that global lock to be released before they can do continue with their work. Result: Bitcoin Core is not as able to do as much work in parallel as we’d like. If we can reduce the places where that global lock is grabbed and held, then Bitcoin Core would be able to things like run wallet tasks, validate blocks and serve blocks and transactions to peers simultaneously .

This is very delicate work and requires a deep understanding of Bitcoin Core’s multi-threading model. Get it wrong and you could easily cause crashes or memory corruption. Matt Corallo has done a lot of the plumbing work for this in V0.15. We should see some major payoff for that work in V0.16.

Several companies now offer hardware wallets, which allow you to keep your private keys and signing code on a dedicated security device. That’s a much, much more secure model than having you private keys on a network-connected computer, which could potentially get hacked. Sadly there’s no standardized interface for hardware wallets, so each vendor provides their own software wallet to use with their hardware wallet. It’d be great if Bitcoin Core could support hardware wallets so users could benefit from running fully hardware-separated signing code behind the most secure Bitcoin full node.

HWW support is probably at least a couple of releases away, but Jonas Schnelli and Nicolas Dorier have already been doing some early work to make sure that Bitcoin Core is ready for HWW support. Hopefully we’ll see some more progress on this in V0.16 or V0.17.

Of course, none of these code changes would be of any use at all if we didn’t have repository maintainers to do the work of signing and merging all the commits, making sure translations are ready, preparing release notes, and doing all the other things that turn a bunch of code changes into a software product that normal people can run. Wladimir van der Laan is lead maintainer and has been tirelessly doing that work for many releases. Everyone in the Bitcoin community owes him a huge debt of gratitude.

I’ve tried to give shout-outs to the main contributors behind each of these features. Open-source software is a collaborative activity and there are far more who have contributed code, review, testing time, documentation and much more to these and other initiatives. If I’ve made any egregious omissions, please accept my apologies and message me on twitter so I can set the record straight!

Against the Minimum Majority Measure

By David A. Harding

Posted July 28, 2017

Balaji Srinivasan and Leland Lee of the company 21 Inc. recently posted a detailed article about measuring Bitcoin’s decentralization. This is a description of some concerns I have with the article:

1. Naming things after Satoshi Nakamoto

The article proposes a name for the minimum number of individuals within a collection of groups necessary to represent greater than 50% of any of those groups. The name proposed is “minimum Nakamoto coefficient”.

I’m not fond of naming things after Bitcoin creator Satoshi Nakamoto. I understand that it’s often done out of respect for Nakamoto and what he achieved by inventing, programming, and maintaining Bitcoin—but it’s also often done to in order to promote a product or an idea by associating it with Nakamoto’s well-deserved fame.

I suggest that we name products, ideas, and other things after the people actually involved in creating them or with other unique branding.

In this case, English actually already has a word for describing the minimum number of individuals within a group necessary to represent more than 50% of that group: majority.

That means we can either call this concept the minimum Srinivasan-Lee coefficient or descriptively call it the minimum majority measure. I’ll use the later term in this article as I don’t want to name things after people without their permission.

2. Measuring things that ought not to be measurable

Srinivasan and Lee measure 6 things for their minimum majority calculation:

  1. Hashrate by self-reported miner name
  2. Full nodes by self-reported version
  3. Developers by count of self-identified commits
  4. Full nodes by IP address (IPv4 and maybe IPv6 receiving nodes only)
  5. Exchanges by self-reported volume
  6. Balances by self-chosen addresses

I think it’s notable that all six of these things don’t have to be—and ideally wouldn’t be—measurable. Let’s go through the list again:

  1. Hashrate is only measurable because miners choose to put their names into blocks—wasting block space and making themselves the target for attackers in the process. Ideally, we’d have many small and anonymous miners.
  2. Full node versions are routinely faked on the network today. Ideally, people would stop paying attention to this statistic so that developers could use it as intended to figure out which versions were still popular enough to require support; if that doesn’t happen, this field will become increasingly meaningless.
  3. Developers choose what to put in their commit listings and many besides Nakamoto have chosen to give false names or even random strings. Ideally code changes and reviews would be conducted entirely anonymously, at least until the change was deployed, so that there’d be no reason to compromise developers.
  4. Full node IP addresses are also easy to fake, although at some cost per IPv4 address. Ideally, everyone would use Tor or a stronger anonymity relay network.
  5. Exchanges have been known to publish fake volume numbers or to craft policies that lead to high amounts of volume in the absence of underlying demand. Ideally exchanges wouldn’t keep unnecessary logs of their customer activity.
  6. Balances are something that could be much more distributed today given that new addresses are free to create and free to use if you’re receiving a new transaction anyway. Ideally something like confidential transactions will deployed on Bitcoin in the future so that it won’t be possible for third parties to monitor balances.

Given that we will hopefully work towards making these things harder to measure in the future (particularly hashrate and balances), I think the minimum majority measure has limited utility even without any other problems.

3. Not objective

Given that things such as miner names, full node versions, developer commit listings, full node IP addresses, and exchange volume can be faked, one needs to subjectively adjust for that possible faking. This makes measurements more arbitrary and comparisons more difficult.

For example, 21’s own bitnodes node monitoring service, which is used as the source for two of the measurements, only counts nodes that accept receiving connections. By some measurements, this represents less that 5% of the total node count—but that alternative measurement has its own problems which need to be corrected for.

Edit: This section was slightly rephrased to address a concern from the original authors about the phrase “objective”. (diff)

4. Why we need decentralization (the main point)

Bitcoin users want many things, but I think the most important is that they don’t want their bitcoins to disappear from their wallets or become unspendable. There are two ways this can happen in Bitcoin:

  1. A reorganization of the block chain can undo previous transactions, removing bitcoins from the wallets of the people who received those transactions.
  2. A consensus change can invalidate bitcoins that were previously valid and spendable.

Defense against reorganization

The defense against reorganization is mining (hashrate) decentralization. A majority of hashrate can theoretically reorganize the chain as far back as they want, invalidating any transaction, and (theoretically) at no extra cost.

Less than a majority can also reorganize the chain to invalidate a previous transaction, but they have to sacrifice resources to do so and that sacrifice is greater the more confirmations a transaction has but lesser the more hash rate the attacking miner or miners control.

Here’s a quick plot I made back when the block reward was 25 BTC per block and transaction fees were negligible (so I could ignore them and Bitcoin Core’s anti-fee-sniping):

If no miner controls more than 1% of hashrate, then once-confirmed transactions are pretty safe against attacking miners (though not accidental conflicting blocks). If no miner controls more than 10% of hashrate, then six-confirmed transactions are quite safe.

That’s the first type of decentralization Bitcoin needs—mining decentralization. The minimum majority measure only applies here to the first part, where we worry about a miner or mining cartel with greater than a majority share; the minimum majority measure doesn’t consider that we also have to worry about a minority who are willing to spend money to make their attack.

Defense against consensus change

If every Bitcoin user wanted to pay Alice more than they wanted anything else in the world, Alice would get to define the Bitcoin consensus rules—but that means the safety of your bitcoins would depend entirely on Alice’s policies.

However, if half of all Bitcoin users wanted to pay Alice more than anything else and half wanted to pay Bob more than anything else, then Alice and Bob would have to either agree on the consensus rules or split the network with different rules. This would be a bit safer: if Alice decided to steal your bitcoins, there would at least be a chance that Bob wouldn’t.

As we extend this from Alice and Bob to Charlie, Dan, and more and more people who someone wants to pay, there are more and more people who have a say in defining the consensus rules—even though on average they each individually have a smaller say.

What they can do to combine their voices is to choose software that automatically enforces the rules they think are important and the non-objectionable rules that they think other people think are important.[1] That’s what full nodes do, and the more people who use full nodes to process the payments they receive, the harder it is to change Bitcoin’s consensus rules in a way that would hurt you.

I believe this is what Nakamoto was trying to describe when he said that he didn’t think that alternative implementations were a good idea. Even with two or more implementations of what the developers and users think are exactly the same consensus rules, there’s a chance that an accidental bug could divide that economic union.

Some people worry about developers attempting to take control, but the defense against that is for other developers to review their code and sound an alarm if they see something inappropriate. Creating multiple codebases creates more work for reviewers, increases the chance of consensus-breaking bugs, and ultimately weakens the economic union that enforces the consensus rules.

There is no way I know to measure economic enforcement except by attempting to change Bitcoin’s consensus rules. Happily, after several years of people expending considerable resources to do that, the rules have only changed for the better and in relatively small ways (BIP66 strict DER, BIP65 CLTV, BIP68/112/113 sequence/RCLTV/median-time, and soon BIP141/etc segwit).

However, there is an important metric related to ensuring economic enforcement remains intact: Cost Of Node OPeration (CONOP), which is described in quite a bit of detail at the preceding link.

Conclusion

Srinivasan’s and Lee’s article attempts to quantify Bitcoin’s decentralization using metrics that aren’t objective, may not be available in the future, and some of which are entirely unrelated to the reasons Bitcoin needs decentralization—or even contrary to keeping the system decentralized.

An alternative strategy that has been reasonably successful at maintaining decentralization on Bitcoin to date is to attempt to mitigate problems known to cause centralization among miners (e.g. the original Fast Block Relay Protocol [and Network] to mitigate the high orphan risk that caused GHash.io to obtain a majority of hashrate even after executing a $100,000 double spend attack) and to keep cost of node operation low to ensure large numbers of people can validate the transactions they receive with their own full nodes.

I personally suspect that Bitcoin’s steadily improving privacy will prevent us from ever measuring decentralization in a truly objective way. Losing easy quantification but gaining stronger privacy seems like a good tradeoff to me.

  1. Full nodes users also have to enforce the non-objectionable rules they think other people think are important in order to form a unified economic bloc. For example, if Alice thinks the 1 MB block size is important but doesn’t care about subsidy halvings and Bob things subsidy halvings are important but doesn’t care about the 1 MB block size, they can form a economic union stronger than either of them individually by each enforcing both rules. ↩

The Rubber Hose Factor

By Elaine Ou

Posted July 28, 2017

[

The strongest encryption in the world can be broken with a rubber hose. It’s easy; all you have to do is smack the keyholder with a rubber hose until they reveal the private key. Have you ever been hit with a hose? It hurts.

Early-stage investors have a metric called the Bus Factor, the number of people who can get hit by a bus before the company dies. It’s sort of a proxy for investment risk. A startup where only one founder has industry or technical expertise has a Bus Factor of 1.

My company has something called the Rubber Hose Factor, a measure of security risk. How many humans have to be coerced before an account is compromised? Single rubber hose attacks are to be expected, a double attack conceivable, a triple Rubber Hose would require extraordinary circumstances and a really long hose.

To launch a nuclear strike, two out of five ICBM squadrons must simultaneously turn their launch keys. So, an unintended nuke would require two rubber hose attacks. Don’t worry, the squadrons are located in distant underground bunkers and surrounded with physical security layers as well.

How many successful rubber hose attacks are required to disable the Ethereum Network? Two.

Ethereum hashrate distribution

What about Bitcoin? Ostensibly four, but possibly just one.

Bitcoin hashrate distribution

It’s easy to overestimate your Rubber Hose Factor. Ethereum’s Parity client comes with a built-in multi-signature wallet, where outgoing transactions have to be signed by multiple account holders. That’s the right idea, except that no one ever looked at the wallet source code.

It only took one person to introduce a bug and another to merge the changes. That was enough to get a backdoor deployed to thousands of users, which was later exploited to the tune of $32 million in ether. Perceived Rubber Hose Factor: Many. Actual Rubber Hose Factor: 2.

I don’t mean to give Parity developers a hard time; users are responsible for their own free software. But it’s worth pointing out that every Bitcoin Core update is reviewed by at least twelve eyeballs, and those eyeballs are connected to a half-dozen brains. The last thing you want is for users to believe that the Rubber Hose Factor is higher than it really is.

Funny story: Last year, the central bank of Bangladesh got hacked and $81 million was sent to the Philippines. Bangladesh Bank officials insisted that it was SWIFT’s fault, because they had a super secure computer system that required six different bank managers to place their palms on a touch screen before a transaction could be authorized. Turns out the touch screen was connected to a single malware-infected computer, which issued fraudulent transactions without any authorization at all. Perceived Rubber Hose Factor: 6. Actual Rubber Hose Factor: 1.

Don’t worry about those who get hacked in Ethereum. When life hands you lemon socialism, make lemonade.

[

We would support this. We’re all in this together!

— Bancor (@BancorNetwork) July 22, 2017

Categories:

Updated: