Bitcoin: Evolution to a Private Network

blind_alley

FIBRE is a major upgrade to the Bitcoin Relay Network, both of which were developed and maintained by the hard work and generosity of Matt Corallo. Unlike it’s predecessor, FIBRE is not a network operated by TheBlueMatt but instead is an add-on to Bitcoin Core:

The Fast Internet Bitcoin Relay Engine (FIBRE) codebase is designed as an extension to Bitcoin Core which enables very fast relay with manually selected peers over UDP.

This builds on the Compact Blocks proposal (BIP152) to extend the P2P protocol. A change to the P2P protocol is neither a hard fork nor a soft fork. Instead of affecting block validity, if affects how peers on the network communicate.

One additional improvement in FIBRE is that servers relay individual packets to their peers as soon as they arrive. This way, extra hops do not introduce more latency. Sadly, due to the nature of our FEC encoding, we cannot know if individual packets are a part of a legitimate, or any, block, and thus only enable this optimization between nodes run by the same group.

The Future of The Bitcoin Relay Network(s): BlueMatt’s Blog

In other words, optimal FIBRE requires a VPN between miners. Not coincidentally the P2P Encryption proposal (BIP151) establishes the basis for building VPNs in the P2P protocol and explicitly depends on the establishment of node identity:

The encryption does not include an identity authentication scheme. This BIP does not cover a proposal to avoid MITM attacks during the encryption initialization. Identity authentication will be covered in another BIP and will presume communication encryption after this BIP.

The expectation is that by integrating much of this into the P2P protocol (via BIP151 and BIP152) it will be easier to deploy, resulting in more mining competition.

According to Corallo, work is underway to encourage other parties to create their own FIBRE-based relay networks – an effort he said is needed to keep things decentralized.

Coindesk: Bitcoin’s ‘Nervous System’ Gets an Upgrade With FIBRE Network

This expects that miners will be joined together in VPNs, which of course means miners must exclude other miners who are not in their cartel. So the hope is that there will be multiple competing mining cartels.

TheBlueMatt should certainly extricate himself from control over the relay network, which FIBRE accomplishes. However the decentralized replacement is a well-intended but economically flawed solution. The larger cartel will be more profitable, driving the others out of business or into its arms. Ultimately faster relay is not a solution to the lack of mining decentralization. The advantage to larger hash power must be reduced to the point where factors other than block latency dominate profit.

Clearly only approved parties can connect to a cartel’s private Bitcoin network. This list of approved parties may include payment processors, exchanges, and web wallets. The boundary between this private network and the anonymous public necessarily constitutes a firewall. The cartel will censor transactions; censorship is the point of a firewall. Whether it desires this outcome is irrelevant to Bitcoin security, it will ultimately be decided by the stroke of a pen.

Bitcoin must be a distributed anonymous public network. Its blockchain and mempool are a cache of public information. The P2P protocol is a means for an anonymous party to relay that information to another, including miners. I believe the effort to introduce encryption and therefore identity into the P2P protocol is dangerously misguided. It may accelerate the evolution of Bitcoin to a private network while not actually resolving any privacy or security failings.

Once every node can easily establish an identity, how long will it be before major economic nodes require it of their peers? This could easily flow from exchanges, payment processors and web wallets to their peers as an obvious requirement of KYC/AML. How long before anonymous nodes cannot find peers with welcoming ports and a path through the firewall? How long before anonymous transactions cannot penetrate the firewall?

This is fundamentally the same problem as the optional client supplied identification of the Out of Band Address Exchange using Payment Protocol Encryption proposal (BIP75). BIP151 does not work without node identity and, despite being optional, node identity is, “an extremely undesirable feature to be baking into standards.”

Not Satoshi, Again

bbcfail

There is a lengthy offering of proof of Satoshi on Dr. Wright’s blog. The narrative is mostly tutorial, but also the following.

Proof of the ability to base64 encode a phrase.

IFdyaWdodCwgaXQgaXMgbm90IHRoZSBzYW1lIGFzIGlmIEkgc2lnbiBDcmFpZyBXcmlnaHQsIFNh 
dG9zaGkuCgo=
$ bx base64-decode IFdyaWdodCwgaXQgaXMgbm90IHRoZSBzYW1lIGFzIGlmIEkgc2lnbiBDcmFpZyBXcmlnaHQsIFNhdG9zaGkuCgo=
Wright, it is not the same as if I sign Craig Wright, Satoshi.

Proof of the ability to base64 encode old blockchain data.

------------------------- Signature File -------------------------
MEUCIQDBKn1Uly8m0UyzETObUSL4wYdBfd4ejvtoQfVcNCIK4AIgZmMsXNQWHvo6KDd2Tu6euEl1
3VTC3ihl6XUlhcU+fM4=
------------------------- End Signature --------------------------
$ bx base64-decode MEUCIQDBKn1Uly8m0UyzETObUSL4wYdBfd4ejvtoQfVcNCIK4AIgZmMsXNQWHvo6KDd2Tu6euEl13VTC3ihl6XUlhcU+fM4= | bx base16-encode
3045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb6841f55c34220ae0022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce

The data is extracted from the following transaction.

$ bx fetch-tx 828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe

Notice transaction.inputs.input.script matches decoding above (excluding the trailing 01signature hash type byte). Credit to jouke in #bitcoin for discovering this link.

transaction
{
    hash 828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe
    inputs
    {
        input
        {
            previous_output
            {
                hash 12b5633bad1f9c167d523ad1aa1947b2732a865bf5414eab2f9e5ae5d5c191ba
                index 1
            }
            script "[ 3045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e8efb6841f55c34220ae0022066632c5cd4161efa3a2837764eee9eb84975dd54c2de2865e9752585c53e7cce01 ]"
            sequence 4294967295
        }
    }
    lock_time 0
    outputs
    {
        output
        {
            address 1ByLSV2gLRcuqUmfdYcpPQH8Npm8cccsFg
            script "[ 04bed827d37474beffb37efe533701ac1f7c600957a4487be8b371346f016826ee6f57ba30d88a472a0e4ecd2f07599a795f1f01de78d791b382e65ee1c58b4508 ] checksig"
            value 1000000000
        }
        output
        {
            address 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S
            script "[ 0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3 ] checksig"
            value 1800000000
        }
    }
    version 1
}

Proof of possession of a public key.

The command to export our public key is given below.
openssl ec -in sn-pub.pem -pubin -text -noout
        0411db93e1dcdb8a016b49840f8c53
        bc1eb68a382e97b1482ecad7b148a6
        909a5cb2e0eaddfb84ccf9744464f8
        2e160bfa9b8b64f9d4c03f999b8643
        f656b412a3
$ bx ec-to-address 0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3
12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S

The address of the public key has been used in 9 transactions to date.

$ bx fetch-history 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S

Notice transfers.transfer[3].received.hash is the same as transaction.hash above.

transfers
{
    transfer
    {
        received
        {
            hash 5d607ae88c2caf1329e758ccb1eb8a359f6df434ee84e03b9e14cea300a85f97
            height 409857
            index 0
        }
        value 66600
    }
    transfer
    {
        received
        {
            hash 20fb69a94413637cb50f65e473f91d2599a04d5a0bf9bf6a5e9e843df2710ea4
            height 228208
            index 0
        }
        value 30000
    }
    transfer
    {
        received
        {
            hash 1554a02d4eb1c7a73e3736922ed99530e360784e709896c42e5756e65b2da341
            height 220151
            index 2
        }
        value 1
    }
    transfer
    {
        received
        {
            hash 828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe
            height 248
            index 1
        }
        value 1800000000
    }
    transfer
    {
        received
        {
            hash 12b5633bad1f9c167d523ad1aa1947b2732a865bf5414eab2f9e5ae5d5c191ba
            height 183
            index 1
        }
        value 2800000000
    }
    transfer
    {
        received
        {
            hash 591e91f809d716912ca1d4a9295e70c3e78bab077683f79350f101da64588073
            height 182
            index 1
        }
        value 2900000000
    }
    transfer
    {
        received
        {
            hash a16f3ce4dd5deb92d98ef5cf8afeaf0775ebca408f708b2146c4fb42b41e14be
            height 181
            index 1
        }
        value 3000000000
    }
    transfer
    {
        received
        {
            hash f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
            height 170
            index 1
        }
        value 4000000000
    }
    transfer
    {
        received
        {
            hash 0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9
            height 9
            index 0
        }
        value 5000000000
    }
}

Retrieving the transfers.transfer[8].received.hash from above returns the following.

$ bx fetch-tx 0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9
transaction
{
    hash 0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9
    inputs
    {
        input
        {
            previous_output
            {
                hash 0000000000000000000000000000000000000000000000000000000000000000
                index 4294967295
            }
            script "[ 04ffff001d0134 ]"
            sequence 4294967295
        }
    }
    lock_time 0
    outputs
    {
        output
        {
            address 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S
            script "[ 0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3 ] checksig"
            value 5000000000
        }
    }
    version 1
}

In other words the public key represents the address that received payment of the full award for block 9.

In newer standard transactions the public key of an address is not exposed on the blockchain until coin spent to the address is subsequently spent. Furthermore the public key of an address cannot be obtained from the address without reversing the ripemd160 and sha256 hashes, which is infeasible.

However these are old transactions that use pay-to-public-key as opposed to pay-to-public-key-hash. The public key that Dr. Wright offered is actually exposed in transaction.outputs.output.script above (and incidentally transaction 828ef… also above).

No Proof

So everything he offered as proof of being Satoshi is actually public information.

consensus

Consensus, you keep using that word

Consensus is referenced in the last sentence of the Bitcoin paper.

Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

Consensus refers to the agreed definition of block validity. From this we derive the term “consensus rules” which are the formalization of the agreement. A person uses the rules to determine whether a received payment is valid.

Conflicts between competing valid blocks are resolved by a proof of greater work. A majority “vote” by processing power controls the long chain and thereby has control over double spends.

As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they’ll generate the longest chain and outpace attackers.

Rule Changes (Forks)

Changes to these rules are referred to as hard forks and soft forks. In the case of a hard fork, a new transaction may be valid despite not conforming to the original rules. In the case of a soft fork, new transactions are valid under the original rules. In other words, holders of a money have not agreed to a hard fork but inherently accept a soft fork.

Majority Rules

A soft fork can be enforced by simple majority of processing power. In other words a soft fork isn’t actually a change in consensus among people, it’s a change that flows from the people controlling a majority of processing power.

The original paper does not articulate a distinction between these rules, loosely referring to both scenarios as consensus. However it is an error to refer to soft fork rules as “consensus rules”. These are “majority rules” with the caveat that it is majority of processing power not majority of people. Bitcoin’s disruption social security guards against soft forks by less than a majority of people.

Consensus Rules

A hard fork requires that all participating people change rules. If a person fails to accept a change in the rules he can spend his existing money with others who have accepted the change. However he will reject new money that doesn’t conform to his unchanged rules. Widespread rejection of the money would result in failure of a hard fork. When people generally refuse to accept a new money it will not be able to fund its own security.

The consensus to be reached in acceptance of a hard fork is among those holding the money. Only those who hold the money have something at stake. However it is not actually savers who protect the money against hard forks, it is those validating money received in trade.

Anything about the money can be changed in a hard fork and any change can constitute a taking from a saver. Hard-forking a person’s savings without their agreement is unethical and harms the necessary predictability of the money. Bitcoin’s economic social security guards against hard forks that lack consensus among stakeholders.

Software Developers

Software developers either sell or donate software to the community. Agreement among them is not a consensus referred to in the original paper, nor is it an aspect of Bitcoin. They contribute neither to the majority nor the consensus. They do not contribute processing power toward the majority, do not contribute validation of their own trades in defense of the consensus, and are not stakeholders in the consensus.

 

Bitcoin’s Social Security

Bitcoin incorporates countless aspects of security. Some are exceedingly complex yet uncontroversial. Bitcoin’s “social security” is simple yet surprisingly controversial.

chain

Bitcoin is not a payment protocol, it is a money. A money is useful because of its properties, one of which is immutability. Holders of a money suffer a loss when changes to the money are not predictable. Gold has been used as a money for millennia. It is much easier to discover than to manufacture, and its scarcity ensures a fairly predictable rate of inflation. If alchemists had discovered a way to change these “rules” of gold, they could have stolen from all others who held it.

Bitcoin’s social security architecture exists to prevent such changes. As an information money, its rules could otherwise be changed quite easily. There is only one case in which change to a money is not a theft — when every individual holding the money agrees to the change. Bitcoin therefore refers to its definition as consensus rules. It is not a problem that consensus is exceedingly hard to achieve, it is a requirement.

Social security is a consequence of choices made by people. It has nothing to do with cryptography, network protocols, hashing or any other technology. Bitcoin gives people the ability to make these choices, but effective defense is only a consequence of people actually doing so. In a previous post I explored definitions of decentralization for defense against against both changes to, and disruption of, the money.

State of Mining Decentralization

In Bitcoin, mining is only a defense if it’s distributed among a large number of people. The total level of mining is important, but it is only decentralization that makes it useful. A large amount of centralized hash power is at best a waste of energy and at worst a threat itself. In the current situation 8 mining pools direct 90% of the Bitcoin hash power.

It is an error to assume that widely used things will not be attacked by the state. There are countless existence proofs to dispel this theory, including alcohol, drug, gambling, firearm, and prostitution prohibitions as well as taxes and restrictions on travel, speech, trade, etc. But more to the point, witness the perpetual example of currency debasement.

Bitcoin social security is specifically designed as the defense against such attacks. But currently a state-level attack could subvert the protections of mining by direct action against 2 pools, and collusion of pools would enable just 2 people to subvert these protections. Whether or not they are likely to do so is irrelevant to Bitcoin’s security. What matters is the system’s ability to repel the attack.

State of Economic Decentralization

Large miners are publicly using their disproportionate influence over the network in an ongoing attack on consensus. While they do not have the ability to compel a hard fork, the attack is coordinated with payment processors and web wallet services. The lack of economic decentralization resulting from use of such services may result in a failure of Bitcoin’s defense of consensus.

Efforts by developers to persuade these people to preserve consensus are a matter of horse-trading. Round tables have the room to seat the people who can currently compel a change in “consensus” rules. This is sufficient evidence that Bitcoin’s social security has been reduced to a point where it is failing to achieve its objective.

I do not consider this a failure of Bitcoin, this is a human failure. Too many people have chosen to leave their doors unlocked. As developers we need to provide better information and tools for people to protect themselves. Self defense is the basis of social security.

Defining Social Security

So how would we define the state of social security? From the previous post:

economic decentralization = recipients * receipts standard deviation / receipts mean

mining decentralization = miners * hash power standard deviation / hash power mean

These definitions are a level of decentralization in two independent axes, not a level of security.

A maximum level of participation (recipients and miners respectively) at a maximum level of activity (receipts and hash power respectively) is required to achieve the maximum level of security. Given that there is no limit to humanity, trade or computation, the level of security in each axis is unbounded. A minimum level of zero in each axis is achieved with either no participants or no activity.

The level of security in each axis can thus be defined as a function of total humanity, participation, and levels of decentralization:

consensus security = receipts * economic decentralization / humanity

disruption security = hash power * mining decentralization / humanity

Note that this is the product of (1) the level of activity, (2) the coefficient of variation in the activity, and (3) the fraction of participating humanity. The last two factors are unitless (percentages). In other words, the level of security in each axis is a fraction of total activity:

security = activity * variation * participation

These relations do not say anything about the absolute effectiveness represented by any value, or the relative effectiveness of any two values except that a greater value represents a greater effectiveness. This is not due to a deficiency in the method. The factors include people, specifically the effectiveness of their individual abilities to resist (and their perception of value in the money). All who validate or mine offer some level of resistance, but there is no implied continuity. We refer to a “level” of security, not an “amount” of security.

Ignoring Decentralization

Removing decentralization produces the following:

consensus security = receipts

disruption security = hash power

This is the reductio ad absurdum of any such theory. Activity only contributes to social security to the extent that it is distributed among independent people.

Price of Attack

Consensus and disruption security definitions cannot be combined. These definitions model attacks against distinct aspects of Bitcoin, with distinct consequences. Certainly such attacks can be applied in concert, but equating them would require pricing the consequences of each and defining the probably of occurrence, arriving at a unified concept of risk. This would only follow from projecting against historical measurement.

The price of a consensus attack is the price of forcing people to accept a change to consensus rules. In a highly centralized economy this would cost the price of a physical attack on a small number of people. For an evenly distributed economy, this may cost more than the amount of the money each person holds.

The price of a disruption attack is the price of directing a majority of total hash power. With highly centralized mining this would cost the price of a physical attack on a small number of people. For evenly distributed mining this would require independent production of 100% of the total other hash power during the attack.

A state actor may attempt widespread compulsion in either distributed scenario. This and the other decentralized attack scenarios are highly subjective and cannot be priced, even with a perfect measure of decentralization. The social security model rests on the axiom that such an attack is infeasible.

Fundamental Disagreements

The fundamental difference in the security model of one who rejects decentralization is a different choice of axiom. Such a person accepts either (1) the state can be trusted to not attack the money, or (2) the state can be trusted with control of the money. Either is a choice that rejects Bitcoin and explains the interest in private blockchains.

We have proposed a system for electronic transactions without relying on trust.
– Satoshi Nakamoto

Bitcoin’s Distributed Defense

Bitcoin is a Peer-to-Peer Electronic Cash. The P2P aspect is intended as a defense against state-level attack.

Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.
– Satoshi Nakamoto

Some claim Bitcoin will never withstand a concerted state-level attack. Others consider Bitcoin decentralization an undefined concept with no ideal measure, and imply that decentralization is a red herring disguising a developer conspiracy.

If Bitcoin is indefensible then there is no point in it; if decentralization is not important then Bitcoin is indefensible.

According to Paul Baran’s 1964 paper on distributed networks the importance of topology in network design is in the ability of communications to withstand the loss of a certain number of nodes. A centralized (star) network will fail with the loss of one node. A distributed (mesh) network is more resilient. A hybrid of these systems is considered decentralized.

networks

In terms of Bitcoin defensibility, it is not the wire protocol we are referring to and communication is not the property we are protecting.

As a money Bitcoin forms a social graph — relations between people. Defense refers to this social graph, not the wire protocol. We defend against the tendency toward authority in order to preserve utility. Authority in a monetary system is the ability to define the money.

In Bitcoin a set of rules define the money. Changes to these rules are referred to as hard forks and soft forks. In the case of a hard fork, a new transaction may be valid despite not conforming to the original rules. In the case of a soft fork, new transactions are valid under the original rules. In other words, holders of a money have not agreed to a hard fork but inherently accept a soft fork.

By way of analogy, in 1933 the gold obligation was dropped from Federal Reserve notes (hard fork), and periodically these notes are replaced with new designs, though old notes remain valid (soft fork). A hard fork without universal consensus by holders of the money is a theft. This is why rules that require a hard fork to change are called consensus rules. By the same reasoning, rules that can be changed by a soft fork are properly referred to as majority rules.

As monies, the Federal Reserve system is centralized (one authority) and gold is distributed (no authority). Gold is a commodity money, defined by its atomic number. It cannot be carried on a wire, making it unsuitable for modern commerce. As an information money the novel aspect of Bitcoin is its resistance to authority (censorship resistance). A Bitcoin hard fork is the monetary equivalent to changing the atomic number of gold.

The social graph is about choices made by people. It is the choice of a person to accept or reject changes to the money (validation) in trade that protects him/her from fraud. And it is only the broad application of this selfish policy that protects the money from authority (i.e. non-consensual hard forks). The strength of Bitcoin’s censorship resistance is a function of how broadly people validate in trade.

How might we define this strength, which is generally referred to as decentralization?

In modeling the system as a graph, a vertex represents a person (“recipient”) and an edge represents a validated trade in bitcoin. The graph is directed in that each edge indicates the direction of movement of the bitcoin, and quantified in terms of the amount of bitcoin traded (“receipt”).

If a person never accepts bitcoin in trade, or does not validate it in the trade, he/she does does not contribute to defense. If a person delegates his/her validation to another party, it is the delegate represented by a vertex. In other words, a “payment processor” or “web wallet service” is just one vertex on the graph and none of this delegate’s customers are represented.

While customers could decide to leave the processor and validate their own transactions, they cannot act in defense until they actually do so. The distinction is analogous to being armed vs. having the ability to become armed. The latter matters not at all when you are getting robbed. Imagine yelling, “Leave my house or I will run down to the gun store!”

For any period of time, the defensibility of Bitcoin is a function of the number of people and the distribution of amounts traded. The strongest system would be all people in the world accepting the same amount of bitcoin in the period, an ideal which I would call “distributed”. The most anemic system would be one payment processor (or web wallet service) accepting all bitcoin traded during the period, which would be a “centralized” system.

centrality

A visualization of centrality.

More specifically, the system is strongest which has the greatest number of vertices with the highest coefficient of variation in the sum of incoming edges (“receipts”), or:

economic decentralization = recipients * receipts standard deviation / receipts mean

What about miner decentralization?

A majority of mining hash power can double spend by reversing transactions indefinitely, can enforce a soft fork and can deny service in various ways. Mining decentralization is independent of the level of economic decentralization.

While economic advantage typically works against a 51% attack, state attackers may be more interested in disruption. Total hash power is the defense against such attacks, but centralization of hash power works against the defense. This is because it may become easier to co-opt large hash power than to deploy it.

Mining decentralization can be defined similarly to economic decentralization. Again we are referring to a social graph. The ideal scenario is every person in the world mining with equal hash power. It is important to security that there is sufficient total hash power to defend against sustained, coordinated, state-level attacks, however decentralization is not security. For a definition of security see the subsequent post.

Each miner is represented by one vertex on the graph. If a miner delegates decision-making to a pool operator, only the operator is represented. The reasoning is the same as with delegation in economic decentralization. The total hash power directed by a miner is the weight (value) of the vertex. There are no edges.

For any period of time, the decentralization of Bitcoin mining is a function of the number of miners and the distribution of hash power they direct during that period. More specifically, the system is strongest which has the greatest number of vertices with the highest coefficient of variation in weights, or:

mining decentralization = miners * hash power standard deviation / hash power mean

What about developer decentralization?

While software is necessary, developers are fundamentally advisers. A diversity of implementations strengthens a standard, but developers cannot compel people to not mine or to not validate as they see fit.

Can we measure decentralization?

Bitcoin is a cash system, and a fundamental aspect of cash is fungibility, which requires anonymity. Bitcoin’s opacity is by design and there is significant effort underway to improve it. Despite having a clear definition we cannot expect to measure decentralization.

However, it is possible to estimate mining centralization using information provided or exposed by miners. It is also possible to estimate economic centralization using information provided by web wallets and payment processors.

It would be a significant error to assume that decentralization is either unimportant or that we cannot determine whether certain changes will advance or diminish it.

What does failure look like?

A contentious hard fork, backed by web wallets, payment processors and large miners, drawing people into a new altcoin out of fear of monetary loss.

Bitcoin development serves those holding bitcoin

This post is offered in response to a Bitcoin Magazine article entitled Gavin Andresen: Bitcoin Core Is Not Listening to Its Customers, in particular the following quote by Mr. Andresen.

The root of my issue with [Bitcoin] Core is I just think that they’re not listening to their customers. I don’t think that they’ve been listening to the miners, and I don’t think that they’ve been listening to the people that do the bulk of the transactions on the network.

Who is the customer of a software system that implements a money? It is of course the person that owns the money.

This person can choose to spend money on services like a bank (e.g. Coinbase) or transaction processing (miners), or he/she can simply save. The money is not the property of these businesses and therefore the software system that implements the money does not serve them. This is a critical distinction when considering the impact of changes to the money — the motivation for the quote.

When a money is modified without universal consent, money is stolen. Money is property and it can’t be stolen from you unless it’s your property. The 1913 U.S. Federal Reserve Note was a gold obligation. The money was hard-forked in 1933, resulting in catastrophic losses for its holders. Except to the extent that they held these notes in their own account, banks and mints were not robbed by this act, and generally thrived. A contentious hard fork in Bitcoin would be the same larceny.

note

“REDEEMABLE IN GOLD ON DEMAND”

In the case of actual consensus (universal agreement) all owners of the property consent to the change, in which case it is an increase in value to everyone. Bitcoin developers can help people achieve consensus, but to the extent that a proposal does not have consensus, it is unethical to push a hard fork. The interests of services, that are paid by coin-holders, are not only irrelevant (it’s not their money) but often in conflict with the interest of their customers.

It should be quite clear that, if a contentious hard fork is possible, Bitcoin is broken. I’ll explore the measure of this damage in a subsequent post.

A Bitcoin Governance Analogy

This post is offered in response to a Bitcoin Magazine article entitled The Checks and Balances of Bitcoin Governance, in particular the following statement.

“It’s almost like the government where you have the executive branch, the legislative branch [and the judicial branch].”

Presumably (being generous here) the state exists in the interest of individuals as a collective security organization. At the same time the state exists contrary to the interests of individuals, given its taxing power.

shoes

It is a mistake to think of the state as consisting of independent entities that counterbalance each other in defense of the individual. That is a fiction taught by the state to school children, and considered from a security standpoint is an absurdism. There is no force in such a system that counteracts the growth of the state at the expense of the individual, except the individual.

Individuals can opt out of Bitcoin by deferring to web wallets (banks). This reduces the number of individuals that exist in counterbalance to existential threats. In other words, a highly decentralized Bitcoin is much like a well-armed population. Centralize the arms, and the ability to resist is destroyed.

The better political analogy is that of miners as the state and users as individuals. This relationship is formed as a collective defense, and the same tension exists between miners and users as between the state and individuals. It’s remarkably similar, miners even “tax” users via inflation and fees.

The state is always attempting to increase its power (money) at the expense of the individual, as a miner is always attempting to increase his power at the expense of users (those who save and transact). The state will collude with banks and other states to increase its taxing power, and miners will collude with web wallets and other miners for the same reason. This is already the case.

The only defense the user has is to validate (personally) – the analog of being armed (individually) and defending one’s self and others against encroachment of the state.