Crypto
A Bitcoiner’s Guide To Proof-Of-Stake
This is an opinion editorial by Scott Sullivan.
Normally Bitcoiners don’t care too much about what goes on in Shitcoin-land, but now that Ethereum has merged to proof-of-stake (PoS), there’s been quite the buzz on Bitcoin Twitter. Of course, the Bitcoin network itself will remain unaffected, but I think this “upgrade” is still worth paying some attention to. Now that Ethereum has cleansed itself of the “dirty” and “wasteful” externalities associated with proof-of-work (PoW), we can expect the gloves to come off in the narrative war, and I think Bitcoiners should be ready to punch back.
Learning how PoS works is a really good way to internalize the differences and trade-offs between PoW and PoS. Even though I had seen all the high-level arguments against PoS before — that PoS is more permissioned, centralizing, and oligarchical — I’ll admit that without looking into the details, it all felt kind of hand-wavy. By actually diving into the PoS algorithm, we can begin to see how all these properties naturally emerge from first principles. So if you’re curious about how the PoS algorithm works, and why it leads to these kinds of properties, then read on!
Solving The Double-Spend Problem
Let’s start with a quick recap of the problem we’re trying to solve. Suppose we have a large group of participants in a cryptocurrency network trying to maintain a decentralized ledger. Here’s the problem: How can new transactions be added to everyone’s ledger, such that everyone agrees on which new transactions are “correct”? PoW solves this problem quite elegantly: Transactions are grouped together in blocks, whereby each block takes a large amount of computational work to produce. The amount of work required can move up or down to ensure blocks are produced every ten minutes on average, giving each new block plenty of time to propagate throughout the network before the next one is created. Any ambiguity is resolved by selecting the chain with the most work, and double-spending is prevented due to requiring at least 51% of the global hashpower for a double-spend block to catch up.
But suppose now we want to throw away Satoshi Nakamoto’s key insight that made all of this possible in the first place. After all, those pesky ASICs are loud and annoying, and they consume more energy than all of George Soros, Bill Gates and Hillary Clinton’s private jets combined. Is there some way we can unambiguously agree on which transactions are true just by talking it out?
Ethereum’s proof-of-stake proposes to solve this problem using two key ingredients. The first is to make special “checkpoint blocks” every now and then, whose purpose is to give assurance to everyone in the network about the “truth” of the system at various points in time. Creating a checkpoint requires a two-thirds majority vote by stake, so there is some assurance that the majority of validators agreed on what the truth actually was at that point in time. The second ingredient is to punish users for adding ambiguity to the network, a process known as “slashing.” For example, if a validator were to create a fork, or vote on an older sidechain (similar to a 51% attack), then their stake would get slashed. Validators can also be slashed for inactivity, but not as much.
This leads us to our first principle behind PoS, which is that PoS is based on a negative (penalty-based) incentive system.
This contrasts heavily with Bitcoin and proof-of-work, which is a positive (reward-based) incentive system. In Bitcoin, miners can attempt to break the rules — badly formatted blocks, invalid transactions, and so on — but these blocks will just get ignored by full nodes. The worst-case scenario is a bit of wasted energy. Miners are also free to build on older blocks, but without 51% of the hashpower, these chains will never catch up, again just wasting energy. Any miner who participates in these actions, whether intentionally or not, need not worry about losing their accumulated bitcoin or mining machines, but they won’t get new rewards. Rather than live in fear, bitcoin miners can err on the side of taking action and risk.
The world is a very different place for validators living in Ethereum-land. Instead of working hard and being rewarded for adding security to the network, validators do no actual work, but must be careful that their node never misbehaves, lest they watch their savings go up in flames. If any proposed changes were made to the network, a validator’s first instinct would be to comply with whatever everyone else was doing, or else risk getting slashed. To be a validator is like walking on eggshells everyday.
By the way, living under a negative incentive system is one of the, ahem, “benefits” of proof-of-stake, according to the Ethereum network’s co-founder Vitalik Buterin’s FAQ:
So how would slashing actually work on a technical level? Wouldn’t we need to first create a list of all the validators, in order to have something to slash in the first place? The answer is yes. To become a validator in Ethereum, one must first move ETH into a special “staking” address. Not only is this list needed for slashing, but also for voting since a two-thirds majority vote is needed for checkpoint blocks.
There are some interesting implications to maintaining a list of all validators at all times. How hard is it to join? How hard is it to leave? Do validators get to vote on the status of other validators?
This brings us to our second principle behind PoS, which is that PoS is a permissioned system.
The first step in becoming a validator is to deposit some ETH into a special staking address. How much ETH? The minimum required is 32 ETH, or about $50,000 at the time of this writing. For context, a decent bitcoin mining rig typically runs in the single-digit thousands of dollars, and a home miner can start with a single S9 for a few hundred bucks. To be fair, ETH’s high entry fee has a technical justification, since a higher stake means fewer validators, which lowers bandwidth.
So the deposit fee is high, but at least anyone who owns 32 ETH is free to join or leave at any time, right? Not quite. There are security risks if large coalitions of validators were to all enter or exit at the same time. For example, if a majority of the network all left at once, then they could double-spend a finalized block by replaying a fork in which they never left, without getting slashed on either chain. To mitigate this risk, the on- and off-ramps have a built-in throughput limit. Currently this limit is set to max(4,|V|/65536) validators per epoch (every 6.4 minutes), and is the same for both entering and leaving. This translates roughly to one full validator set every ten months.
By the way, even though it’s currently possible for validators to publish an “exit” transaction and stop validating, the code to actually withdraw funds hasn’t even been written yet. Sounds a bit like “Hotel California” …
There is one last point about the incentives behind approving new validators. Suppose you were a shareholder in a large and stable company paying regular dividends every quarter. Would it make sense to give new shares away for free? Of course not, since doing so would dilute the dividends of all existing shareholders. A similar incentive structure exists in PoS, since each new validator dilutes the revenue of all existing validators.
In theory, validators could simply censor every single transaction that adds a new validator; however, in practice, I think such a blunt approach would be unlikely. This would be very noticeable and would destroy Ethereum’s image of “decentralization” overnight, potentially crashing the price. I think a more subtle approach would be used instead. For example, the rules could slowly change over time making it harder to become a validator, with excuses being offered such as “security” or “efficiency.” Any policies that enrich existing validators at the expense of new validators would have financial tailwinds, whether spoken out loud or not. We can start to see why PoS would tend towards oligarchy.
Overview Of The Casper Algorithm
Now that we know the high-level strategy behind PoS, how does the algorithm actually work? The main ideas behind checkpoints and slashing were put forward in an algorithm called Casper, so we’ll start there. Casper itself doesn’t actually specify anything about how to produce blocks, but rather provides a framework for how to superimpose a checkpoint/slashing strategy on top of some already-existing blockchain tree.
First, some arbitrary constant (C) is chosen to be the “checkpoint spacing” number, which determines how many blocks occur between checkpoints; for example, if C=100 then checkpoints would occur at blocks 0, 100, 200, and so on. Then the nodes all vote on which checkpoint block should be the next “justified” checkpoint. Rather than vote on single blocks in isolation, validators actually vote on (s,t) checkpoint pairs, which link some previously justified checkpoint source “s” to some new target checkpoint “t.” Once a checkpoint link (s,t) gets a two-thirds majority vote by stake, then “t” becomes a new justified checkpoint. The diagram below shows an example tree of checkpoints:
In this diagram, the h(b) function is referring to the “checkpoint height,” e.g., the block’s multiple of 100. You may have noticed that not every hundredth block is necessarily justified, which can happen if the vote failed at a certain height. For example, suppose at height 200 two separate checkpoints each received 50% of the vote. Since voting twice is a slashable offense, the system would get “stuck” unless some validators willingly slashed their own stake to achieve a two-thirds vote. The solution would be for everyone to “skip” checkpoint 200 and “try again” at block 300.
Just because a checkpoint is justified, does not mean it is finalized. In order for a checkpoint to count as finalized, it must be immediately followed by another justified checkpoint at the next possible height. For example, if checkpoints 0, 200, 400, 500 and 700 were all justified and linked together, only checkpoint 400 would count as “finalized,” since it is the only one immediately followed by another justified checkpoint.
Because the terminology is very precise, let’s recap our three categories. A “checkpoint” is any block which occurs at height C*n, so if C=100, every block with height 0, 100, 200, 300, and so on would all be checkpoints. Even if multiple blocks were created at height 200, they would both be “checkpoints.” A checkpoint is then “justified” if it’s either the root block at height 0, or if two-thirds of the validators voted to create a link between some previously justified checkpoint and the current checkpoint. A justified checkpoint is then “finalized” if it then links to another justified checkpoint at the next possible height. Not every checkpoint necessarily becomes justified and not every justified checkpoint necessarily becomes finalized, even in the final chain.
Casper Slashing Rules
The slashing rules in Casper are designed such that it is impossible for two finalized checkpoints to exist in two separate forks, unless at least one-third of the validators broke the slashing rules.
In other words, only finalized checkpoints should ever be counted as unambiguous “truth” blocks. It’s even possible for two justified checkpoints to occur on both sides of a fork, just not two finalized checkpoints. There’s also no guarantee about when or where the next finalized checkpoint will occur, just that if a chain split were to occur, then you should sit back and wait until a finalized block shows up somewhere, and once it does then you know that’s the “correct” chain.
There are two slashing rules in Casper which enforce this property:
The first rule forbids anyone from double-voting on checkpoints with the same target height, so if a validator voted for two different checkpoint blocks with target height 200, that would be a slashable offense. The purpose of this rule is to prevent the chain from splitting into two different justified checkpoints with the same height, since this would require 2/3 + 2/3 = 4/3 of the total validator votes, implying that at least one-third of the validators broke the slashing rules. However, as we saw previously, it’s possible for justified checkpoints to “skip” certain block heights. What prevents a chain from splitting into different target heights? For example, couldn’t checkpoint 200 fork into justified checkpoints at 300 and 400 without anyone getting slashed?
That’s where the second rule comes in, which basically prevents validators from “sandwiching” votes inside other votes. For example, if a validator voted for both 300→500 and 200→700, that would be a slashable offense. In the case of a chain split, once one branch sees a finalized checkpoint, it becomes impossible for the other branch to see a justified checkpoint afterwards unless at least one-third of the validators broke rule #2.
To see why, suppose the blockchain forked into justified checkpoints 500→800 and 500→900, then at some point the first chain saw a finalized checkpoint with link 1700→1800. Since both 1700 and 1800 can only be justified on fork #1 (assuming nobody broke the first slashing rule), the only way fork #2 could see a justified checkpoint after 1800 is if there was some voted-in link between heights H<1700 and H>1800. But since this vote would “sandwich” the 1700→1800 link and require a two-thirds vote, and the 1700→1800 already passed with a two-thirds vote, then at least one-third of the validators would need to break rule #2. The Casper paper has a nice diagram demonstrating this property:
And that’s it, just follow the Casper rules and you’re good!
Seems pretty simple, right? I’m sure PoS would only ever use slashing as an absolute last resort to maintain consensus, and not as an extortionary mechanism to pressure validators into behaving a certain way … right?
This brings us to our third principle behind PoS: There are no rules. The “rules” are whatever everyone else says they are.
One day your node could be technically following every Casper commandment to the letter, and the next day your savings could be slashed because you were doing something everyone else didn’t like. Approved a “team red” transaction that one time? Tomorrow the “team blue” majority might slash you. Or maybe you did the opposite and omitted too many “team red” transactions? Tomorrow the “team red” majority might slash you for censorship. The ability to slash goes far beyond the limited scope of OFAC (Office of Foreign Assets Control) censorship. PoS is like a nonstop Mexican standoff, where the implicit threat of slashing is ever-present at all times.
I wouldn’t be surprised if in a contentious hard fork, both sides hard-coded the validation rules of the other fork, just in case they wanted to punish anyone who joined the “wrong” side. Of course, this would be a nuclear option, and like nukes, each side might only choose to strike in retaliation. I would guess that most individual validators are neutral in that they would prioritize financial self-preservation over political self-sacrifice, but might outwardly take a side if they sensed that was the correct move to avoid getting slashed.
What Time Is It?
Now that we know the basics of checkpoints and slashing, we can move onto the actual algorithm used in Ethereum, called Gasper. This is a portmanteau of Casper, which we’ve already covered, and GHOST, a strategy for selecting the “best” chain of blocks in between checkpoints.
The first thing to understand about Gasper is that time itself is the main independent variable. Real-world time is divided into twelve-second units called “slots,” where each slot contains at most one block. These slots then form larger groups called “epochs,” where each epoch refers to one checkpoint. Each epoch contains 32 slots, making them 6.4 minutes long.
It’s worth noting that this paradigm flips the causal relation between time and block production when compared to PoW. In PoW, blocks are produced because a valid hash was found, not because enough time had passed. But in Gasper, blocks are produced because enough real-world time has passed to get to the next slot. I can only imagine the tricky timing bugs such a system may encounter, especially when it’s not just one program running on one computer, but tens of thousands of computers trying to run in sync all over the world. Hopefully, the Ethereum developers are familiar with the falsehoods programmers believe about time.
Now suppose you were starting up a validator node, and you were syncing the blockchain for the first time. Just because you observed that certain blocks referenced certain timestamps, how could you be sure that those blocks were really produced at those times? Since block production doesn’t require any work, couldn’t a malicious group of validators simulate an entirely fake blockchain from day one? And if you saw two competing blockchains, how would you know which is true?
This brings us to our fourth principle behind PoS, which is that PoS relies on subjective truth.
There is simply no objective way to pick between two competing blockchains, and any new nodes to the network must ultimately trust some existing source of truth to resolve any ambiguity. This contrasts significantly with Bitcoin, where the “true” chain is always the one with the most work. It doesn’t matter if a thousand nodes are telling you chain X, if a single node broadcasts chain Y and it contains more work, then Y is the correct blockchain. A block’s header can prove its own worth, completely removing the need for trust.
By relying on subjective truth, PoS reintroduces the need for trust. Now I’ll admit, I’m perhaps slightly biased, so if you want to read the other side, Buterin wrote an essay containing his views here. I will admit that in practice, a chain split doesn’t seem all that likely given the Casper rules, but regardless, I do get some peace of mind knowing that this isn’t even a possibility in Bitcoin.
Block Production And Voting
Now that we’re familiar with slots and epochs, how are individual blocks produced and voted on? At the beginning of each epoch, the full validator set is “randomly” partitioned into 32 groups, one for each slot. During each slot, one validator is “randomly” chosen to be the block producer, while the others are chosen to be the voters (or “attestors”). I’m putting “randomly” in quotes because the process must be deterministic, since everyone must unambiguously agree on the same validator sets. However this process must also be non-exploitable, since being the block producer is a highly privileged position due to the extra rewards available from miner extractable value (MEV), or as it’s being renamed, “maximum extractable value.” “Ethereum Is A Dark Forest” is a great read on this.
Once a block is produced, how do the other validators vote or “attest” to it? Block proposal is supposed to happen within the first half (six seconds) of a slot, and attesting within the second half, so in theory there should be enough time for the attestors to vote on their slot’s block. But what happens if the block proposer is offline or fails to communicate or builds on a bad block? The job of an attestor is not necessarily to vote on that slot’s block, but rather whichever block “looks the best” from their view at that point in time. Under normal conditions this will usually be the block from that slot, but could also be an older block if something went wrong. But what does “look the best” mean, technically? This is where the GHOST algorithm comes in.
GHOST stands for “Greediest Heaviest Observed SubTree” and is a greedy recursive algorithm for finding the block with the most “recent activity.” Basically, this algorithm looks at all the recent blocks in the form of a tree, and walks down the tree by greedily selecting the branch with the most cumulative attestations on that entire subbranch. Only the most recent attestation of each validator counts towards this sum, and eventually this process lands on some leaf block.
Attestations are not just votes for the current best block, but also the for the most recent checkpoint which lead to that block. It’s worth noting in Gasper, checkpoints are based on epochs rather than block heights. Each epoch refers to exactly one checkpoint block, which is either the block in that epoch’s first slot, or if that slot was skipped, then the most recent block before that slot. The same block can theoretically be a checkpoint in two different epochs if an epoch somehow skipped every single slot, so checkpoints are represented using (epoch, block) pairs. In the diagram below, EBB stands for “epoch boundary block” and represents the checkpoint for a specific epoch, while “LEBB” stands for “last epoch boundary block” and represents the most recent checkpoint overall.
Similar to Casper, a checkpoint becomes justified once the total number of attestations passes the two-thirds threshold, and finalized if it was immediately followed by another justified checkpoint in the next epoch. An example of how this voting works is shown below:
There are two slashing conditions in Gasper, which are analogous to the slashing rules in Casper:
- No voting twice in the same epoch.
- No vote can contain epoch checkpoints which “sandwich” another vote’s epoch checkpoints.
Despite being based on epochs instead of block heights, the Casper rules still ensure that no two finalized checkpoints can occur on different chains unless one-third of the validators could be slashed.
It’s also worth noting that attestations are included in the blocks themselves. Similar to how a block in PoW justifies itself using its hash, a finalized checkpoint in PoS justifies itself using all of its past attestations. When someone does break the slashing rules, those bad attestations are included in a block which proves the violation. There’s also a small reward for the block producer who included the violation, in order to provide an incentive to punish rulebreakers.
Forks
It is interesting to think about what would happen in the case of a fork. To quickly recap, a fork refers to a change in the consensus rules, and they come in two varieties: hard forks and soft forks. In a hard fork, the new rules are not backwards-compatible, potentially resulting in two competing blockchains if not everyone switches over. In a soft fork, the new rules are more restrictive than the old rules, while keeping them backwards-compatible. Once over 50% of the miners or validators start enforcing the new rules, the consensus mechanism switches over without splitting the chain. Soft forks are generally associated with upgrades and new transaction types, but they also technically include any type of censorship enforced by a 51% majority. PoS also has a third type of “fork” not present in PoW: a chain split without any changes to the rules. But since we’ve already covered this, we’ll focus on hard and soft forks.
Let’s start with the simplest case: a standalone contentious hard fork. By contentious, I mean a rule change that divides the users politically. A bug fix or minor technical change likely wouldn’t be contentious, but something like changing the validation reward probably would be. If a hard fork was contentious enough, it could result in a chain split and would get resolved economically by users selling one chain and buying the other. This would be similar to the Bitcoin Cash split in 2017, which seems to have a clear winner:
Now suppose the validators were sitting around one day and decided they weren’t getting paid enough, and decided they should raise their rewards from 5% per year to 10% per year. This would be a clear trade-off in favor of the validators at the expense of non-validators who would now be getting more diluted. In the event of a chain split, which chain would win?
This leads to our fifth principle of PoS, which is that money is power.
Out of the 120M ETH in existence, over 10% of that is currently being staked, as seen in the chart below:
Given a contentious hard fork between the validators and non-validators, assuming that all the non-validators market-sold the new chain and all the validators market-sold the old chain, then in theory the old chain would win, since the majority of ETH would still held by non-validators (90% versus 10%). But there’s a few more things to consider. First, after any chain split, the validators would still be “in control” of both blockchains. If the validators were able to influence the other chain, they might be incentivized to make it fail. Second, there’s also the nuclear option discussed earlier, whereby the new chain might slash anyone still validating the old chain to pressure them into joining. Finally, the validators would likely carry significant social and political influence over everyone else in the network. If Buterin, the Ethereum Foundation and the exchanges all decided in unison they were going to raise the staking reward, I find it difficult to believe that regular Ethereum users and validators could keep the old fork going while also making it more valuable through buying pressure.
Moving on to soft forks, what would happen in a contentious soft fork, such as OFAC censorship? The validators are fairly centralized, as we can see in the chart below:
Unlike PoW where miners can switch pools at the press of a button, validators in Ethereum are locked into a staking address until they process an exit transaction. If Lido and the top exchanges were made to censor certain transactions, they could easily pass the two-thirds majority needed for deciding checkpoints. Earlier, we saw how Buterin and the other ETH validators could try to counter a censorship soft fork with their own counter-censorship hard fork, while slashing the censors in the process. Even if they succeeded in creating a fork, a lot of value would be destroyed in the process, both from the slashing and from a loss of trust.
Closing Thoughts
In this essay, we looked at how PoS solves the double-spend problem with Gasper, a combination of checkpoint/slashing rules called Casper, and a “best block” voting rule called GHOST. To recap, Gasper divides time into units called slots, where each slot can have at most one block, and the slots are grouped into epochs, where each epoch refers to one checkpoint. If a two-thirds majority votes on a checkpoint, it becomes justified, and if two justified checkpoints occur in a row, the first of those two checkpoints becomes finalized. Once a checkpoint becomes finalized, it becomes impossible for a parallel chain to be finalized, unless one-third of the validators could get slashed.
In this process we uncovered five principles of PoS:
- PoS uses a negative (penalty-based) incentive structure.
- PoS is a permissioned system.
- PoS has no rules.
- PoS relies on subjective truth.
- In PoS, money is power.
Each of these principles has opposite behavior in PoW:
- PoW uses a positive (reward-based) incentive system.
- PoW is a permissionless system (anyone can start or stop mining at any time).
- In PoW, forks which change the rules get ignored.
- PoW relies on objective truth.
- In PoW, miners serve the users and have little power themselves.
I believe everyone should strive to create the kind of world that they want to live in. If, like me, you want to live in a permissionless world where you can have control over your money, where hard work is rewarded and passive ownership is a liability and where your money will store its value far into the future without changing on a whim, then you may want to think carefully about the trade-offs between PoW and PoS, and fight in favor of the principles you want to live by.
This is a guest post by Scott Sullivan. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.
El Salvador’s Minister of the Economy Maria Luisa Hayem Brevé submitted a digital assets issuance bill to the country’s legislative assembly, paving the way for the launch of its bitcoin-backed “volcano” bonds.
First announced one year ago today, the pioneering initiative seeks to attract capital and investors to El Salvador. It was revealed at the time the plans to issue $1 billion in bonds on the Liquid Network, a federated Bitcoin sidechain, with the proceedings of the bonds being split between a $500 million direct allocation to bitcoin and an investment of the same amount in building out energy and bitcoin mining infrastructure in the region.
A sidechain is an independent blockchain that runs parallel to another blockchain, allowing for tokens from that blockchain to be used securely in the sidechain while abiding by a different set of rules, performance requirements, and security mechanisms. Liquid is a sidechain of Bitcoin that allows bitcoin to flow between the Liquid and Bitcoin networks with a two-way peg. A representation of bitcoin used in the Liquid network is referred to as L-BTC. Its verifiably equivalent amount of BTC is managed and secured by the network’s members, called functionaries.
“Digital securities law will enable El Salvador to be the financial center of central and south America,” wrote Paolo Ardoino, CTO of cryptocurrency exchange Bitfinex, on Twitter.
Bitfinex is set to be granted a license in order to be able to process and list the bond issuance in El Salvador.
The bonds will pay a 6.5% yield and enable fast-tracked citizenship for investors. The government will share half the additional gains with investors as a Bitcoin Dividend once the original $500 million has been monetized. These dividends will be dispersed annually using Blockstream’s asset management platform.
The act of submitting the bill, which was hinted at earlier this year, kickstarts the first major milestone before the bonds can see the light of day. The next is getting it approved, which is expected to happen before Christmas, a source close to President Nayib Bukele told Bitcoin Magazine. The bill was submitted on November 17 and presented to the country’s Congress today. It is embedded in full below.
This is an opinion editorial by Joakim Book, a Research Fellow at the American Institute for Economic Research, contributor and copy editor for Bitcoin Magazine and a writer on all things money and financial history.
I don’t.
That’s it. That’s the article.
In all sincerity, that is the full message: Just don’t do it. It’s not worth it.
You’re not an excited teenager anymore, in desperate need of bragging credits or trying out your newfound wisdom. You’re not a preaching priestess with lost souls to save right before some imminent arrival of the day of reckoning. We have time.
Instead: just leave people alone. Seriously. They came to Thanksgiving dinner to relax and rejoice with family, laugh, tell stories and zone out for a day — not to be ambushed with what to them will sound like a deranged rant in some obscure topic they couldn’t care less about. Even if it’s the monetary system, which nobody understands anyway.
Get real.
If you’re not convinced of this Dale Carnegie-esque social approach, and you still naively think that your meager words in between bites can change anybody’s view on anything, here are some more serious reasons for why you don’t talk to friends and family about Bitcoin the protocol — but most certainly not bitcoin, the asset:
- Your family and friends don’t want to hear it. Move on.
- For op-sec reasons, you don’t want to draw unnecessary attention to the fact that you probably have a decent bitcoin stack. Hopefully, family and close friends should be safe enough to confide in, but people talk and that gossip can only hurt you.
- People find bitcoin interesting only when they’re ready to; everyone gets the price they deserve. Like Gigi says in “21 Lessons:”
“Bitcoin will be understood by you as soon as you are ready, and I also believe that the first fractions of a bitcoin will find you as soon as you are ready to receive them. In essence, everyone will get ₿itcoin at exactly the right time.”
It’s highly unlikely that your uncle or mother-in-law just happens to be at that stage, just when you’re about to sit down for dinner.
- Unless you can claim youth, old age or extreme poverty, there are very few people who genuinely haven’t heard of bitcoin. That means your evangelizing wouldn’t be preaching to lost, ignorant souls ready to be saved but the tired, huddled and jaded masses who could care less about the discovery that will change their societies more than the internal combustion engine, internet and Big Government combined. Big deal.
- What is the case, however, is that everyone in your prospective audience has already had a couple of touchpoints and rejected bitcoin for this or that standard FUD. It’s a scam; seems weird; it’s dead; let’s trust the central bankers, who have our best interest at heart.
No amount of FUD busting changes that impression, because nobody holds uninformed and fringe convictions for rational reasons, reasons that can be flipped by your enthusiastic arguments in-between wiping off cranberry sauce and grabbing another turkey slice. - It really is bad form to talk about money — and bitcoin is the best money there is. Be classy.
Now, I’m not saying to never ever talk about Bitcoin. We love to talk Bitcoin — that’s why we go to meetups, join Twitter Spaces, write, code, run nodes, listen to podcasts, attend conferences. People there get something about this monetary rebellion and have opted in to be part of it. Your unsuspecting family members have not; ambushing them with the wonders of multisig, the magically fast Lightning transactions or how they too really need to get on this hype train, like, yesterday, is unlikely to go down well.
However, if in the post-dinner lull on the porch someone comes to you one-on-one, whisky in hand and of an inquisitive mind, that’s a very different story. That’s personal rather than public, and it’s without the time constraints that so usually trouble us. It involves clarifying questions or doubts for somebody who is both expressively curious about the topic and available for the talk. That’s rare — cherish it, and nurture it.
Last year I wrote something about the proper role of political conversations in social settings. Since November was also election month, it’s appropriate to cite here:
“Politics, I’m starting to believe, best belongs in the closet — rebranded and brought out for the specific occasion. Or perhaps the bedroom, with those you most trust, love, and respect. Not in public, not with strangers, not with friends, and most certainly not with other people in your community. Purge it from your being as much as you possibly could, and refuse to let political issues invade the areas of our lives that we cherish; politics and political disagreements don’t belong there, and our lives are too important to let them be ruled by (mostly contrived) political disagreements.”
If anything, those words seem more true today than they even did then. And I posit to you that the same applies for bitcoin.
Everyone has some sort of impression or opinion of bitcoin — and most of them are plain wrong. But there’s nothing people love more than a savior in white armor, riding in to dispel their errors about some thing they are freshly out of fucks for. Just like politics, nobody really cares.
Leave them alone. They will find bitcoin in their own time, just like all of us did.
This is a guest post by Joakim Book. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
This is an opinion editorial by Federico Tenga, a long time contributor to Bitcoin projects with experience as start-up founder, consultant and educator.
The term “smart contracts” predates the invention of the blockchain and Bitcoin itself. Its first mention is in a 1994 article by Nick Szabo, who defined smart contracts as a “computerized transaction protocol that executes the terms of a contract.” While by this definition Bitcoin, thanks to its scripting language, supported smart contracts from the very first block, the term was popularized only later by Ethereum promoters, who twisted the original definition as “code that is redundantly executed by all nodes in a global consensus network”
While delegating code execution to a global consensus network has advantages (e.g. it is easy to deploy unowed contracts, such as the popularly automated market makers), this design has one major flaw: lack of scalability (and privacy). If every node in a network must redundantly run the same code, the amount of code that can actually be executed without excessively increasing the cost of running a node (and thus preserving decentralization) remains scarce, meaning that only a small number of contracts can be executed.
But what if we could design a system where the terms of the contract are executed and validated only by the parties involved, rather than by all members of the network? Let us imagine the example of a company that wants to issue shares. Instead of publishing the issuance contract publicly on a global ledger and using that ledger to track all future transfers of ownership, it could simply issue the shares privately and pass to the buyers the right to further transfer them. Then, the right to transfer ownership can be passed on to each new owner as if it were an amendment to the original issuance contract. In this way, each owner can independently verify that the shares he or she received are genuine by reading the original contract and validating that all the history of amendments that moved the shares conform to the rules set forth in the original contract.
This is actually nothing new, it is indeed the same mechanism that was used to transfer property before public registers became popular. In the U.K., for example, it was not compulsory to register a property when its ownership was transferred until the ‘90s. This means that still today over 15% of land in England and Wales is unregistered. If you are buying an unregistered property, instead of checking on a registry if the seller is the true owner, you would have to verify an unbroken chain of ownership going back at least 15 years (a period considered long enough to assume that the seller has sufficient title to the property). In doing so, you must ensure that any transfer of ownership has been carried out correctly and that any mortgages used for previous transactions have been paid off in full. This model has the advantage of improved privacy over ownership, and you do not have to rely on the maintainer of the public land register. On the other hand, it makes the verification of the seller’s ownership much more complicated for the buyer.
Source: Title deed of unregistered real estate propriety
How can the transfer of unregistered properties be improved? First of all, by making it a digitized process. If there is code that can be run by a computer to verify that all the history of ownership transfers is in compliance with the original contract rules, buying and selling becomes much faster and cheaper.
Secondly, to avoid the risk of the seller double-spending their asset, a system of proof of publication must be implemented. For example, we could implement a rule that every transfer of ownership must be committed on a predefined spot of a well-known newspaper (e.g. put the hash of the transfer of ownership in the upper-right corner of the first page of the New York Times). Since you cannot place the hash of a transfer in the same place twice, this prevents double-spending attempts. However, using a famous newspaper for this purpose has some disadvantages:
- You have to buy a lot of newspapers for the verification process. Not very practical.
- Each contract needs its own space in the newspaper. Not very scalable.
- The newspaper editor can easily censor or, even worse, simulate double-spending by putting a random hash in your slot, making any potential buyer of your asset think it has been sold before, and discouraging them from buying it. Not very trustless.
For these reasons, a better place to post proof of ownership transfers needs to be found. And what better option than the Bitcoin blockchain, an already established trusted public ledger with strong incentives to keep it censorship-resistant and decentralized?
If we use Bitcoin, we should not specify a fixed place in the block where the commitment to transfer ownership must occur (e.g. in the first transaction) because, just like with the editor of the New York Times, the miner could mess with it. A better approach is to place the commitment in a predefined Bitcoin transaction, more specifically in a transaction that originates from an unspent transaction output (UTXO) to which the ownership of the asset to be issued is linked. The link between an asset and a bitcoin UTXO can occur either in the contract that issues the asset or in a subsequent transfer of ownership, each time making the target UTXO the controller of the transferred asset. In this way, we have clearly defined where the obligation to transfer ownership should be (i.e in the Bitcoin transaction originating from a particular UTXO). Anyone running a Bitcoin node can independently verify the commitments and neither the miners nor any other entity are able to censor or interfere with the asset transfer in any way.
Since on the Bitcoin blockchain we only publish a commitment of an ownership transfer, not the content of the transfer itself, the seller needs a dedicated communication channel to provide the buyer with all the proofs that the ownership transfer is valid. This could be done in a number of ways, potentially even by printing out the proofs and shipping them with a carrier pigeon, which, while a bit impractical, would still do the job. But the best option to avoid the censorship and privacy violations is establish a direct peer-to-peer encrypted communication, which compared to the pigeons also has the advantage of being easy to integrate with a software to verify the proofs received from the counterparty.
This model just described for client-side validated contracts and ownership transfers is exactly what has been implemented with the RGB protocol. With RGB, it is possible to create a contract that defines rights, assigns them to one or more existing bitcoin UTXO and specifies how their ownership can be transferred. The contract can be created starting from a template, called a “schema,” in which the creator of the contract only adjusts the parameters and ownership rights, as is done with traditional legal contracts. Currently, there are two types of schemas in RGB: one for issuing fungible tokens (RGB20) and a second for issuing collectibles (RGB21), but in the future, more schemas can be developed by anyone in a permissionless fashion without requiring changes at the protocol level.
To use a more practical example, an issuer of fungible assets (e.g. company shares, stablecoins, etc.) can use the RGB20 schema template and create a contract defining how many tokens it will issue, the name of the asset and some additional metadata associated with it. It can then define which bitcoin UTXO has the right to transfer ownership of the created tokens and assign other rights to other UTXOs, such as the right to make a secondary issuance or to renominate the asset. Each client receiving tokens created by this contract will be able to verify the content of the Genesis contract and validate that any transfer of ownership in the history of the token received has complied with the rules set out therein.
So what can we do with RGB in practice today? First and foremost, it enables the issuance and the transfer of tokenized assets with better scalability and privacy compared to any existing alternative. On the privacy side, RGB benefits from the fact that all transfer-related data is kept client-side, so a blockchain observer cannot extract any information about the user’s financial activities (it is not even possible to distinguish a bitcoin transaction containing an RGB commitment from a regular one), moreover, the receiver shares with the sender only blinded UTXO (i. e. the hash of the concatenation between the UTXO in which she wish to receive the assets and a random number) instead of the UTXO itself, so it is not possible for the payer to monitor future activities of the receiver. To further increase the privacy of users, RGB also adopts the bulletproof cryptographic mechanism to hide the amounts in the history of asset transfers, so that even future owners of assets have an obfuscated view of the financial behavior of previous holders.
In terms of scalability, RGB offers some advantages as well. First of all, most of the data is kept off-chain, as the blockchain is only used as a commitment layer, reducing the fees that need to be paid and meaning that each client only validates the transfers it is interested in instead of all the activity of a global network. Since an RGB transfer still requires a Bitcoin transaction, the fee saving may seem minimal, but when you start introducing transaction batching they can quickly become massive. Indeed, it is possible to transfer all the tokens (or, more generally, “rights”) associated with a UTXO towards an arbitrary amount of recipients with a single commitment in a single bitcoin transaction. Let’s assume you are a service provider making payouts to several users at once. With RGB, you can commit in a single Bitcoin transaction thousands of transfers to thousands of users requesting different types of assets, making the marginal cost of each single payout absolutely negligible.
Another fee-saving mechanism for issuers of low value assets is that in RGB the issuance of an asset does not require paying fees. This happens because the creation of an issuance contract does not need to be committed on the blockchain. A contract simply defines to which already existing UTXO the newly issued assets will be allocated to. So if you are an artist interested in creating collectible tokens, you can issue as many as you want for free and then only pay the bitcoin transaction fee when a buyer shows up and requests the token to be assigned to their UTXO.
Furthermore, because RGB is built on top of bitcoin transactions, it is also compatible with the Lightning Network. While it is not yet implemented at the time of writing, it will be possible to create asset-specific Lightning channels and route payments through them, similar to how it works with normal Lightning transactions.
Conclusion
RGB is a groundbreaking innovation that opens up to new use cases using a completely new paradigm, but which tools are available to use it? If you want to experiment with the core of the technology itself, you should directly try out the RGB node. If you want to build applications on top of RGB without having to deep dive into the complexity of the protocol, you can use the rgb-lib library, which provides a simple interface for developers. If you just want to try to issue and transfer assets, you can play with Iris Wallet for Android, whose code is also open source on GitHub. If you just want to learn more about RGB you can check out this list of resources.
This is a guest post by Federico Tenga. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
