Pillars of Bitcoin: Decentralization

Day 4: Rubin's Bitcoin Advent Calendar

Welcome to day 4 of my Bitcoin Advent Calendar. You can see an index of all the posts here or subscribe at judica.org/join to get new posts in your inbox

Many may have tried, but few have successfully characterized what “being decentralized” means in an objective / quantitative sense. Instead, we’re left with soft “know it when I see it”s.

Decentralization may be a pillar of Bitcoin with a lotta fanfare, but it’s still just a means to an end. It’s about the Pantheon, not the pillars! A system can be very decentralized and still kinda suck. Much like pillars with no roof won’t keep the rain out!

Got Gas?

For a more than slightly contrived example, imagine a pre-internet driver navigating gas stations prices. Kind of “decentralized”, right? Users/purchasers operate on local information to see pricing and make a decent decision, and sellers operate on local information to stay competitive. Over time the network should “converge” a sellers learn who has better prices throughout town, but from the perspective of an individual purchaser it’s really hard for them to determine within their remaining tank range/willingness to drive across town for a dollar who has the best prices. So while the market works as a decentralized pricing system, it’s not highly consistent!

It’s Hard; No CAP

Computer network nerds have three rules for keeping their jobs: consistency, availability, and partition tolerance. What do these mean in practice? Thinking back to our gas analogy, gas stations are very available (you can always get gas at some price), they’re strongly partition tolerant (i.e., if you can’t see other gas station’s advertised prices you won’t know if it’s better, but you can still get gas). But the pricing might be all over the map! No consistency!

It’s really hard to achieve all three properties – there even exist proofs of its impossibility. Instead, engineers make tradeoffs to achieve different amounts of guarantee across the properties.

For Bitcoin we care a lot about consistency¹. If I send money to Alice, I should not be able to send it to Bob. We also care a lot about partition tolerance. If some group of participants should shunt themselves out from others, the system should still operate? So do we inherently care less about availability? Well, kinda! If the “blockchain is closed” and you can’t transact, at least you still have your money. And technologies like Lightning Network can help bridge the gaps if the Bitcoin blockchain is unavailable that you can still fully confirm transactions as long as it comes back eventually.

So, interestingly, Availability seems like the property we need to care about the least… but it’s one of the main reasons we need decentralization! That’s because even though we might have a design that elevates the other two properties, it doesn’t mean that availability is unimportant. And availability is not one monolithic level, there are many different types of availability fault one might experience on a network. For example, you might experience reduced or no availability if:

1. The network doesn’t have blockspace at your price
2. The internet is down
3. Your usual peers are offline
4. Theres a fire at a major data center
5. Your battery on your phone dies
6. A big solar flare happens
7. An evil government changes your DNS records to your mining pool and you don’t know the IP address
8. An evil government runs the network entirely and doesn’t like your transactions so they get censored.

Some of these problems, decentralization can help us with! Some, decentralization can’t help with. And some are caused by decentralization. Uh oh!

For example…

A fire a major data center can be defrayed by being more decentralized – a fire can only spread so far! The other data centers should be fine, since Bitcoin is partition tolerant, the overall network is available.

If a big solar flare happens, there’s not much any of us can do if all the internet is down and our devices got fried. Too catastrophic… We can recover eventually, your metal seed plates will be fine, but hopefully someone had some Faraday cage shielded backups.

If blockspace is too expensive, decentralization may be the cause!

In order to keep the network decentralization friendly, Bitcoin uses far less bandwidth and storage than a centralized system (like Google) could use. This ensures that participants on the network need not be particularly well resourced or well connected to be a meaningful, full participant in the Bitcoin Network.

That’s because of another availability issue: censorship. Bitcoin fundamentally stands as a fuck-you to the entrenched powers that be. As such, Bitcoin uses decentralization to guarantee censorship-resistance against state actors. While there’s been much ink scaled about the censorship of scalability v.s. the censorship of state actors, Bitcoin is hyper focused on providing some form of “equal protection”.

Everyone hates that you lose availability from high tx prices, and all are equally affected². Everyone hates solar flares, and all are equally affected. But with state actor censorship, enemies of the state, be they Jews, Conservative Non-Profits, Black Americans, Gazan Chocolatiers, People who believe things posted on *******’s Twitter Account etc, can be picked apart and subjected to selective abuses. If anyone can run a node (and hopefully miner), and most people don’t have a political agenda, we can maybe protect individuals of any background.

As such, Bitcoin’s decentralization is focused on censorship-resistance, even at the expense of on-chain availability.

The Neverending Story

The story doesn’t end there. Decentralization, as we noted earlier, is very tough to quantify. Even if we can’t quantify it, we can still reason about decentralization efficiency. Given the “costs of decentralization”, how much censorship resistance do we get? Can we decrease the costs and achieve the same amount? Can we keep the cost the same and gain more censorship resistance? Or… do we need to increase the costs, because we’re not censorship resistant enough? Stay tuned for future posts we’re we’ll see if we can’t do something about it!

Pillars of Bitcoin: Self Custody

Day 3: Rubin's Bitcoin Advent Calendar

Welcome to day 3 of my Bitcoin Advent Calendar. You can see an index of all the posts here or subscribe at judica.org/join to get new posts in your inbox

Not your keys, not your coin. A simple maxim often repeated by Bitcoiners, but an important one. Why?

That thing about the gold standard you probably heard before:

In the existing financial system, your assets aren’t really your assets. Let’s suppose you own a share of Google. You don’t really own that share, you own a virtual claim and the actual certificate sits somewhere with a corporation like The Depository Trust & Clearing Corporation (DTCC). So what? Why does it matter who holds the paper?

The U.S. Dollar is a great example of why you should care. One dollar used to represent an amount of Gold you could redeem for real physical bite-it-to-see-its-pure gold. This was a promise of course, the paper dollar did not have the actual gold in it. This was all good and dandy until in 1933, Executive Order 6102 was put in place which made the holding of physical gold illegal. Get arrested and go to jail illegal. EO 6102 mandated that all Gold be turned in to the Federal Reserve. This was quickly followed by a devaluing of the redemptive value of the dollar in Gold by the government from $20.67 per troy ounce to $35 as a “one time” move¹. Today a troy ounce costs around $1,800. This is because in 1971 an Executive Order was put through that ended the dollar’s gold backing entirely.

What’s this got to do with Bitcoin?

If Bitcoin is held in accounts at regulated entities like exchanges a similar act to 6102 could make redeeming actual bitcoin impossible for users of those services. Suppose those users are forced to receive in place of their exchange Bitcoin a Bitcoin Note that is backed by bitcoin. And then one day, the amount of Bitcoin per Bitcoin Note can be reduced – or worse, completely unlinked.

If this happens, all is lost. Bitcoin is fundamentally about a monetary standard for the world where no self-important rulers can manipulate the currency. Self custody is a requirement for Bitcoin to avoid these sorts of takeovers.

OK, OK, I’ll keep my coins off exchange…

Just fixing your behavior isn’t enough, to keep Bitcoin functional you need most users to follow suit. Yet many users today do choose to keep some or all of their Bitcoin on centralized services (yours truly included!).

This is for two main reasons:

1. Game Theory: we can’t do anything about this. As long as not too many other people are using an exchange for custody, it doesn’t matter if you are since a regulatory takeover won’t be too effective. So selfishly, you may as well benefit from the ease of keeping your coin on a service (assuming it is easier) rather than taking responsibility for your own assets. Likewise if no-one else is self custodying there’s not much advantage for you to be either.
2. Software freakin’ sucks for self custody! We can fix this. Although the quality of wallets has improved dramatically from Bitcoin’s early days, it’s still incredibly difficult to do well. Further, self-custody solutions don’t have solid options for handling many common needs such as inheritance, spending limits, and more.

If we work on strengthening the fully self-sovereign self-custody options that Bitcoin users have at their disposal, we can help more Bitcoin users to choose to keep their funds themselves and achieve “herd immunity” against future executive order 6102s. If we self custody in great number, we don’t permit them the immediate victory over most users. You can’t arrest everyone, not easily at least.

in short…

PLEBZ

TOGETHER

STRONK

Pillars of Bitcoin: Scalability

Day 2: Rubin's Bitcoin Advent Calendar

Welcome to day 2 of my Bitcoin Advent Calendar. You can see an index of all the posts here or subscribe at judica.org/join to get new posts in your inbox

This is the first of four posts in an advent mini-series about four fundamental pillars of Bitcoin. I know, I know, a series within a series. What am I, nuts? But it’s important that we begin our journey by setting the stage with a few big picture objectives for Bitcoin before we get into why Smart Contracts matter.

After all, we’re trying to build the hardest money possible, not Crypto Kitties… right?

The four pillars I’ve chosen to focus on are Scalability, Self Custody, Decentralization, and Privacy. Are there other properties that are also important? Sure. Might there be a “more fundamental” name for each pillar? Ok. But generally I find that these 4 categories are different enough from one another and capture a very wide swath of what Bitcoin is and not overly specific or overly general. Otherwise we’d just have one pillar for Bitcoin: “To Fix This”.

Now onto the content.

Scalability is a controversy generating issue. Throughout Bitcoin’s history there have been acerbic disagreements about what sort of scale is required and how to accomplish it. Back then I even helped create a conference series, Scaling Bitcoin, where people got to present to/shout at each other in person!

But why is scalability so important? And why does it generate controversy?

Famously, certain folks have remarked that, “you can’t buy coffee with Bitcoin” because fees would be too high. This is an issue that’s easy to empathize with; if transactions cost $10 who wants to do that for a $5 coffee – No One!

The common response is that Bitcoin isn’t for trivial purposes like buying a cup of coffee, it’s The Hardest And Most Sound Money To Ever Exist And If You Buy Coffee With It You Are Stupid.

There’s some truth to that. Bitcoin doesn’t need to function to enable your trivial day to day purchases, it needs to exist to help you take self-sovereign control over your money! Forget about your coffee, stack sats, survive hyperinflation, avoid the pod, don’t eat the bugs. Capiche?

So what’s the rub? Well, if Bitcoin is to really be the vaccine against autocratic rulers and corrupt financial systems, it needs to protect everyone, not just elite sat-stackers who can afford to use it. Scalability represents our desire for Bitcoin to be affordable for all who could benefit from it. Many who live under abusive or corrupt regimes today might already be priced out. Imagine earning 1000 satoshis per day and spending 300 satoshis to do a transaction. Real bummer. And what if fees go up? There’s also the insulting concept of dust in Bitcoin, 546 satoshis, currently about $0.30. Some people work hard just to earn that much! Where do you think people who fall on this low end of the economic spectrum live… in the freest of the free western countries? No, they’re Congolese children mining cobalt. Maybe it’s OK that they’re priced out: Bitcoin preserves wealth (and freedom), it doesn’t create it. And just having cheaper fees isn’t going to free the child workers. But still, wouldn’t you rather have Bitcoin be able to benefit anyone who might have the need to use it, regardless of net worth?

Good news: there are techniques that exist today for scaling access to Bitcoin. Bad news: they all have different tradeoffs.

Just Make the Blocks Bigger Bro

Early on in Bitcoin’s history a contingency of Bitcoiners felt strongly that Bitcoin should scale by increasing the size of Blocks to accommodate more transactions per second and keeping fees low. While mild block size increases (e.g., as done with SegWit) are probably ok, the ever-increasing block size would threaten Bitcoin’s decentralization and make it harder for anyone to be able to run and audit the system. And if you can’t run and audit Bitcoin yourself, you might as well be using the legacy financial system.

There are some efficiency improvements that can shrink transactions marginally, contributing to an effectively larger block. But Blockspace will always be scarce, no matter how space efficient transactions are.

Lightning Network

The Lightning Network is a very popular means of scaling bitcoin. It makes a second layer on top of Bitcoin where you can make cheaper and lower latency payments. It functions sort of like the equivalent of Venmo versus Bank Wire Transfers. You set up a “payment channel” with a counterparty, and are able to make many cheap payments between you and the counterparty. You can even route payments through friend’s channels if you don’t have a direct link. A few major downsides to this approach are as follows:

1. That it requires an active online presence and ability to get bitcoin transactions confirmed (which still costs money!)
2. It requires some form of durable storage any time you make a transaction.
3. That in order to receive funds, you have to have someone loan you the “potential” capital (think credit worthiness, which requires some sort of reputation system and identities).

In countries like El Salvador, which have begun adopting Bitcoin as legal tender, many users of the Lightning Network are doing so through a centralized service provider which doesn’t protect users from the types of abuse possible in current banking paradigms. In theory, this central service provider isn’t there because the El Salvador government is some kind of soon-to-be dictatorship, but rather because solving the problems of capital loan, regular online presence, and durable storage are hard problems for citizens of a poor country.

Sidechains

Another popular approach is to make federated sidechains, such as RootStock, Liquid, Nomic, or ThorChain, etc. A Federated Sidechain is essentially a “fancy multisig”, where funds are sent into the custody of a set of entities (usually such that many independent entities would have to collude to steal funds). The federation then runs some sort of cryptocurrency backed by the deposits. Users are granted virtual bitcoin on the sidechain which they can use in accordance with the rules of the sidechain. Eventually they may request that whatever balance they have on the sidechain be sent out of the sidechain and into a normal bitcoin address of their choosing. This achieves a sort of scalability because the base layer does not have to validate or store any of the transactions occurring on the sidechain. However, the tradeoff is severe: the funds are completely owned by the Federation, which means that users are not guaranteed to be able to access their funds. It’s basically a bank with a cool API.

This post doesn’t end in a fun or upbeat way: we want everyone to be able to access and benefit from Bitcoin; we can’t get everyone for access in the obvious way of bigger blocks or we risk unravelling Bitcoin’s core guarantees; and the solutions using layers on top of bitcoin reduce some of the core properties that make Bitcoin valuable to society in the first place. Some of these tradeoffs may be acceptable in certain cases, but we must always strive to support the most users with the strongest Hard Money properties we can.

In future posts we’ll see how more sophisticated smart contracts could improve Bitcoin’s scalability, or at least provide a different set of tradeoffs compared to the solutions above.

Day 1: Rubin's Bitcoin Advent Calendar

What says Christmas more than an Advent Calendar to count the days till Santa comes? Honestly, I’m not too sure, I’m a Jew. Happy Hanukkah everyone! But in the spirit of the season, I figured the community would love a series of blog posts (one a day) discussing the future of Bitcoin and Smart Contracts.

You can find an index of all the posts here.

So here’s how it’s going to work:

Today’s the first day!

Advent Calendars are designed to be from the 4th Sunday before Christmas till Christmas and as such vary in length. Lucky you; this year is a long one! Unfortunately for me, I’ve got to make 26 more exciting posts to pull this off. Each of these posts is going to be short-but-sweet (much like the chocolates you’re used to) and designed to highlight an important concept or idea about Bitcoin Smart Contracting. I’ll put each post on my personal blog, email out a link on the judica newsletter, and tweet it out.

This series is for you.

It doesn’t matter if you’re a programmer, investor, pleb, or just trying to learn more. Through the series I’ll do my best to thoroughly introduce concepts for anyone to follow along and learn.

Of course I’m going to be a little biased.

The perspectives shared are my own and the focus is on things that I focus on, but I’ll do my best to present the balance and nuance!

If you want to send me some holiday cheer: 3E6p1UgrgwAFvZAF7xUiRcBR2vAEdYNXjZ

Hope you enjoy the series!

CheckSequenceVerify DISCOURAGE_UPGRADABLE_NOPS Defect

The other day I was writing some tests for BIP-119 (shoutout Gloria for the detailed feedback on improving tests). I noticed something peculiar while attempting to write static test vectors for CTV. This peculiar thing led me to discover a minor flaw in Bitcoin’s interpreter – it isn’t going to break anything in the short term, but it has implications for how certain upgrades might be done in the future.

In the interpreter we pass specific flags in at different times to check different rules at different times. This is used because we generally want the Mempool to be “restrictive” and block validation to be unrestrictive. That sounds like the opposite of what you would want, but it’s because we want to ensure that we never break a consensus rule, so our mempool is “strict” to protect e.g. a miner from making a bad block, because our node’s understanding of consensus validation is less strict so we always know the mempool is full of stuff that will pass consensus.

One of the specific types of “stricter” that is in the mempool is for things that may be changed in the future. For example, Taproot (a change proposed to Bitcoin) uses a Witness V1 script. Before Taproot activates, Witness V1 Scripts are always valid no matter if they’re signed or not. After it activates, a new rule takes effect in consensus, and Witness V1 Scripts will be processed in accordance with Taproot’s rules. Because the Mempool is stricter, it never lets in any Witness V1 script spends until it knows how to properly validate it. That way, for a miner who doesn’t want to upgrade to Taproot, they can use the old rules in their Mempool and not ever mine a bad block.

One of the flags used for this purpose is DISCOURAGE_UPGRADABLE_NOPS. A NOP is simply an opcode in bitcoin that has no effect (nada). In the future, someone could add a rule to that NOP (e.g., check that the stack args present when the NOP executes satisfy some properties or the transaction is invalid, but do not remove anything from the stack so that the old consensus rules still seem correct). This is sufficient for consensus, but maybe people have decided that they want to create a bunch of outputs with NOPs in it because they are cute. Then, a fork that would add new semantics to a NOP would have the impact of locking people out of their wallets. To prevent this, the Mempool uses the rule DISCOURAGE_UPGRADABLE_NOPS which makes it so that if you try to broadcast an output script with a NOP it gets bounced from the Mempool (but not consensus of course, should a deviant miner mine such a transaction). Hopefully our users get the message to not use NOPs because we… discourage upgradable nops.

CheckSequenceVerify (CSV) was one such NOP before it grew up to be a big n’ important opcode. Essentially all that CSV does is check that the sequence field is set in a particular manner. This lets you set relative block and time lock (e.g., takes this much time before a coin is spendable again). However, it’s possible that we might come up with new kinds of lock times in the future, so we have a bit we can set in the sequence that makes it ignored for consensus purposes. Maybe in the future, someone would find something nice to do with it, eh?

This is the sequence verification code:

case OP_CHECKSEQUENCEVERIFY:
{
    if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
        // not enabled; treat as a NOP3
        break;
    }

    if (stack.size() < 1)
        return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

    // nSequence, like nLockTime, is a 32-bit unsigned integer
    // field. See the comment in CHECKLOCKTIMEVERIFY regarding
    // 5-byte numeric operands.
    const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5);

    // In the rare event that the argument may be < 0 due to
    // some arithmetic being done first, you can always use
    // 0 MAX CHECKSEQUENCEVERIFY.
    if (nSequence < 0)
        return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);

    // To provide for future soft-fork extensibility, if the
    // operand has the disabled lock-time flag set,
    // CHECKSEQUENCEVERIFY behaves as a NOP.
    if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0)
        break;

    // Compare the specified sequence number with the input.
    if (!checker.CheckSequence(nSequence))
        return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);

    break;
}

Spot anything funky? Look closer…

    // To provide for future soft-fork extensibility, if the
    // operand has the disabled lock-time flag set,
    // CHECKSEQUENCEVERIFY behaves as a NOP.
    if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0)
        break;

Here, where we say it behaves as a NOP we don’t check any rules and skip the checks.

See where the problem lies? If we ever did get around to a future upgrade here, then old miners who refuse to upgrade would be more than happy to accept invalid transactions into their mempool, and then following the fork, would end up mining invalid blocks leading to potential network partitions.

That would be bad! Let’s not do that.

What we really should be doing is:

    // To provide for future soft-fork extensibility, if the
    // operand has the disabled lock-time flag set,
    // CHECKSEQUENCEVERIFY behaves as a NOP.
    if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) {
        if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS)
            return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
        break;
    }

Which is exactly what I propose to do in this PR.

If this solution is adopted, then after the last release of the Bitcoin Core Implementation that has the unpatched code goes End-of-Life, we could safely deploy new sequence rules. Because it takes a while for software to go EOL, I hope we can patch this soon.