Author: evoskuil

#libbitcoin lead developer

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.

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 mean / receipts standard deviation

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

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 evenly distributed 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 distribution of 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 * distribution * 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 lowest coefficient of variation in the sum of incoming edges (“receipts”), or:

economic decentralization = recipients * receipts mean / receipts standard deviation

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 lowest coefficient of variation in weights, or:

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

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.

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 gives every person their own say in the money. 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.

What is Bitcoin Infrastructure?

Recently I was confronted with the idea that “Bitcoin infrastructure companies” consist of the following:

  • wallet companies (hosted or local apps)
  • APIs (block explorers or blockchain analysis)
  • payment processors

As Ryan X. Charles reported from Montreal, among this group apparently “everyone wants the block size to increase”.

Merriam-Webster defines infrastructure as follows:

the underlying foundation or basic framework (as of a system or organization)

Apart from “local apps” (wallets, presumably open source), the list above consists entirely of centralized services. These are not Bitcoin infrastructure by any definition. These are peripheral services that use Bitcoin.

Actual Bitcoin infrastructure (validating wallet, node, miner) developers should be extremely wary of pressure coming from this sector. The business model of each of these types of companies requires centralization. Each would prefer a substantial portion of activity relating to Bitcoin pass through their gateways. Ryan described the group as representing a:

large fraction, if not majority, of bitcoins held, bitcoins transacted and bitcoin API calls made

In other words, it may be that this small group of companies is a gateway for the majority of Bitcoin transactions and is acting as a bank for the majority of coins in existence. It may even be that a large portion of these so-called Bitcoin transactions are actually off chain. It may also be that these so-called Bitcoin wallets are actually custodial accounts.

fox-hen

But even the best of these services (i.e. those who claim you control your own keys and that only transact on chain), with the best of intentions, represent a dangerous centralization trend for Bitcoin. These are hardly the voices that Bitcoin developers should heed.

Good intentions won’t stop these types of services from failing their customers when the shit hits the fan. And when Bitcoin starts to significantly challenge seigniorage revenues, the shit will be all over the room.

Many of the good people in these companies naively believe that Bitcoin is a super-efficient system. They see the core value as cheap and rapid transactions for the masses. Some are even interested in the benefits of sound money or even pseudonymity. They are right, these are ultimately the benefits to the user base (all humans).

What they fail to understand is that these benefits are a strictly consequence of the single innovation of Bitcoin – consensus without trust. This innovation allows Bitcoin users to resist censorship. This censorship resistance is only achieved through decentralization. Some may think that only applies to mining, which is not the case. These business models are themselves the primary threat. Each new user of a centralized service expands the attack surface.

Bitcoin BIP38 Security Advisory

You may use third party services (“printers”) to produce encrypted Bitcoin keys, based on an “intermediate code” that you (“owner”) create independently, and which starts with the letters “passphrase”, such as “passphraseouGLY8yjTZQ5Q2bTo8rtKfdbHz4tme7QuPheRgES8KnT6pX5yxFauYhv3SVPDD”.

If so you are using BIP38, also known as “passphrase-protected private keys”. Libbitcoin developers recently integrated this technology into the development kit.

The encrypted private key produced by the printer typically begins with the letters “6P”, such as “6PnQ4ihgH1pxeUWa1SDPZ4xToaTdLtjebd8Qw6KJf8xDCW67ssaAqWuJkw”.

This standard defines a “confirmation code”, which is another value the owner may receive from the printer, and begins with the letters “cfrm”, such as “cfrm38VUEdzHWKfUjdNjV22wyFNGgtRHYhXdBFT7fWw7cCJbCobryAYUThq4BbTPP15g4SeBsug”.

Payments can be made to the corresponding Bitcoin payment address, in this case “1AoLqsujagqD7NmbQKYBEuhRMnCfwJzGoy”. The owner, using the passphrase originally used to create the intermediate code is the only party who can spend money sent to this address, and is therefore protected from printer malfeasance and ineptitude.

However, I strongly recommend against reliance on the confirmation code. Validating this code with your original passphrase tells you nothing about your ability to spend money sent to its corresponding bitcoin payment address. In fact this code is not useful in any scenario where the printer cannot be trusted by the owner. This lack of trust is of course the reason for both the intermediate code and the confirmation code in the first place.

The only thing that the owner learns from validating the confirmation code is that only the owner could spend money sent to the corresponding address. But this assumes the owner has the corresponding private key. The encrypted private key provided by the printer may be entirely bogus. The only way to know whether you have the necessary private key is to validate the encrypted private key.

You are fine as long as you validate the encrypted private key, but don’t use the confirmation code for anything, even after you have validated the encrypted private key. This validation must include deriving the payment address from the encrypted private key. It is our recommendation that the confirmation code section be struck entirely from BIP38.