Jeremy Rubin's Blog

CheckSigFromStack for 5 Byte Values

I recently published a blog post about covenants on Bitcoin.

Readers were quick to point out I hadn’t fully explained myself on a claim I made that you can do a form of CheckSigFromStack in Bitcoin today.

So I thought it would be worthwhile to fully describe the technique – for the archives.

There are two insights in this post:

1. to use a bitwise expansion of the number
2. to use a lamport signature

Let’s look at the code in python and then translate to bitcoin script:

def add_bit(idx, preimage, image_0, image_1):
    s = sha256(preimage)
    if s == image_1:
        return (1 << idx)
    if s == image_0:
        return 0
    else:
        assert False

def get_signed_number(witnesses : List[Hash], keys : List[Tuple[Hash, Hash]]):
    acc = 0
    for (idx, preimage) in enumerate(witnesses):
        acc += add_bit(idx, preimage, keys[idx][0], keys[idx][1])
    return x

So what’s going on here? The signer generates a key which is a list of pairs of hash images to create the script.

To sign, the signer provides a witness of a list of preimages that match one or the other.

During validation, the network adds up a weighted value per preimage and checks that there are no left out values.

Let’s imagine a concrete use case: I want a third party to post-hoc sign a sequence lock. This is 16 bits. I can form the following script:

<pk> checksigverify
0
SWAP sha256 DUP <H(K_0_1)> EQUAL IF DROP <1> ADD ELSE <H(K_0_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_1_1)> EQUAL IF DROP <1<<1> ADD ELSE <H(K_1_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_2_1)> EQUAL IF DROP <1<<2> ADD ELSE <H(K_2_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_3_1)> EQUAL IF DROP <1<<3> ADD ELSE <H(K_3_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_4_1)> EQUAL IF DROP <1<<4> ADD ELSE <H(K_4_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_5_1)> EQUAL IF DROP <1<<5> ADD ELSE <H(K_5_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_6_1)> EQUAL IF DROP <1<<6> ADD ELSE <H(K_6_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_7_1)> EQUAL IF DROP <1<<7> ADD ELSE <H(K_7_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_8_1)> EQUAL IF DROP <1<<8> ADD ELSE <H(K_8_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_9_1)> EQUAL IF DROP <1<<9> ADD ELSE <H(K_9_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_10_1)> EQUAL IF DROP <1<<10> ADD ELSE <H(K_10_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_11_1)> EQUAL IF DROP <1<<11> ADD ELSE <H(K_11_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_12_1)> EQUAL IF DROP <1<<12> ADD ELSE <H(K_12_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_13_1)> EQUAL IF DROP <1<<13> ADD ELSE <H(K_13_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_14_1)> EQUAL IF DROP <1<<14> ADD ELSE <H(K_14_0)> EQUALVERIFY ENDIF
SWAP sha256 DUP <H(K_15_1)> EQUAL IF DROP <1<<15> ADD ELSE <H(K_15_0)> EQUALVERIFY ENDIF
CHECKSEQUENCEVERIFY

In order to sign a 16 bit value V, the owner of K simply puts on the stack the binary representation of V indexed into the K. E.g., to sign 53593, first expand to binary 0b1101000101011001, then put the appropriate K values on the stack.

K_15_1
K_14_1
K_13_0
K_12_1
K_11_0
K_10_0
K_9_0
K_8_1
K_7_0
K_6_1
K_5_0
K_4_1
K_3_1
K_2_0
K_1_0
K_0_1
<sig>

This technique is kind of bulky! It’s around 80x16 = 1280 length for the gadget, and 528 bytes for the witnesses. So it is doable, if not a bit expensive. There might be some more efficient scripts for this – would a trinary representation be more efficient?

The values that can be signed can be range limited either post-hoc (using OP_WITHIN) or internally as was done with the 16 bit value circuit where it’s impossible to do more than 16 bits.

Keys can be reused across scripts, but signatures may only be constructed one time because a third party could take two signed messages and construct an unintended value (e.g., if you sign both 4 and 2 then a third party could construct 6).

There are certain applications where this could be used for an effect – for example, an oracle might have a bonding contract whereby posessing any K_i_0 and K_i_1 allows the burning of funds.

Templates, Eltoo, and Covenants, Oh My!

If you’ve been following The Discourse, you probably know that Taproot is merged, locked in, and will activate later this November. What you might not know is what’s coming next… and you wouldn’t be alone in that. There are a number of fantastic proposals floating around to further improve Bitcoin, but there’s no clear picture on what is ready to be added next and on what timeline. No one – core developer, technically enlightened individuals, power users, or plebs – can claim to know otherwise.

In this post I’m going to describe 4 loosely related possible upgrades to Bitcoin – SH_APO (BIP-118), OP_CAT, OP_CSFS, and OP_CTV (BIP-119). These four upgrades all relate to how the next generation of stateful smart contracts can be built on top of bitcoin. As such, there’s natural overlap – and competition – for mindshare for review and deployment. This post is my attempt to stitch together a path we might take to roll them out and why that ordering makes sense. This post is for developers and engineers building in the Bitcoin space, but is intended to be followable by anyone technical or not who has a keen interest in Bitcoin.

Bitcoin Eschews Roadmaps and Agendas.

I provide this maxim to make clear that this document is by no means an official roadmap, narrative, or prioritization. However, it is my own assessment of what the current most pragmatic approach to upgrading Bitcoin is, based on my understanding of the state of outstanding proposals and their interactions.

My priorities in producing this are to open a discussion on potential new features, risk minimization, and pragmatic design for Bitcoin.

Upgrade Summaries

Below follows summaries of what each upgrade would enable and how it works. You might be tempted to skip it if you’re already familiar with the upgrades, but I recommend reading in any case as there are a few non obvious insights.

APO: SIGHASH_ANYPREVOUT, SIGHASH_ANYPREVOUTANYSCRIPT

Currently proposed as BIP-118.

APO provides two new signature digest algorithms that do not commit to the coin being spent, or the current script additionally. Essentially allowing scripts to use outputs that didn’t exist at the time the script was made. This would be a new promise enforced by Bitcoin (ex. “You can close this Lightning channel and receive these coins if you give me the right proof. If a newer proof comes in later I’ll trust that one instead.”).

APO’s primary purpose is to enable off chain protocols like Eltoo, an improved non-punitive payment channel protocol.

APO can also emulate some of the main features of CTV and could be made to work with Sapio, partially. See the complimentary upgrades section for more detail.

CAT (+ variants)

Currently no BIP. However, CAT exists in Elements and Bitcoin Cash as a 520 byte limited form, so a proposal for Bitcoin can crib heavily from either.

Cat enables appending data onto other pieces of data. Diabolically simple functionality that has many advanced use cases by itself and in concert with other opcodes. There are many “straightforward” use cases of cat like requiring sighash types, requiring specific R values, etc, but there are too many devious use cases to list here. Andrew Poelstra has a decent blogpost series (part 1 and part ii) if you’re interested to read more. In particular, with much cleverness, it seems possible one could implement full covenants with just CAT, which covers (inefficiently) most of the other techniques discussed in this post.

CSFS: CHECKSIGFROMSTACK

Currently no BIP. However, CSFS exists in Elements and in Bitcoin Cash, so a proposal for Bitcoin can crib heavily from either.

CSFS enables checking of a signature against a message and key from the stack without including any transaction data.

Use cases include oracle protocols, key delegations, a channel update invalidation variant (Laolu claims this can be tweaked to be fully non punitive like eltoo, but you’ll need to bug him to write it up), and (+CAT) full covenants.

CTV: OP_CHECKTEMPLATEVERIFY

Currently proposed as BIP-119.

CTV enables committing to a specific “next” transaction from script. This is the ability to make an unbreakable promise on chain which Bitcoin can enforce (e.g. “This coin can only be spent to my multisig, or my backup after a timelock”). This is a departure from normal script which is traditionally only concerned with restrictions on the sender, CTV imposes restrictions on the recipient. More technically, CTV is essentially the ability to embed a signature of a specific transaction inside of a script without needing any elliptic curve operations. The validation costs are low. For more advanced logic, you can nest multiple different CTV Hashes either using taproot or up to the script length limits in regular script.

CTV can be used for vaults, channels, and many other uses. There’s also Sapio which is a language and toolkit for creating many kinds of programs with CTV.

CTV compliments CSFS to be able to emulate APO-like functionality sufficient to build Eltoo, potentially making APO feature-wise redundant.

Comparative Analysis

Now that we’ve got the basics covered, let’s explore these upgrades comparatively across several dimensions.

Design Specificity

“Design Specificity” is a subjective measure of how substantially an upgrade could change from its current design while still meeting the features goals. It is not to be confused with security or safety. Ranked in order from most to least design specific, with non-exhaustive lists of design questions based on ongoing community discourse as well as my own personal understanding of what might be desirable.

1. CSFS
2. CTV
3. CAT
4. APO

Explanations & Open Questions:

1. CSFS is very simple and there is essentially a single way to implement it. Three open questions are:
   1. Should CSFS require some sort of tagged hash? Very likely answer is no – tags interfere with certain use cases)
   2. Should CSFS split the signature’s R & S value stack items for some applications that otherwise may require OP_CAT? E.g. using a pinned R value allows you to extract a private key if ever double signed, using 2 R values allows pay-to-reveal-key contracts. Most likely answer is no, if that is desired then OP_CAT can be introduced
   3. Should CSFS support a cheap way to reference the taproot internal or external key? Perhaps, can be handled with undefined upgradeable keytypes. One might want to use the internal key, if the signed data should be valid independent of the tapscript tree. One might want to use the external key, if the data should only be valid for a single tapscript key + tree.
2. CTV is a commitment to all data that can malleate TXID besides the inputs being spent, therefore CTV does not have much space for variation on design.
   1. Should the digest be reordered or formatted differently? If there were more data on what types of covenants might be built in the future, a better order could be picked. Some thought has already gone into an order and commitments that make covenants easier, see the BIP for more. It’s also possible the serialization format for the variable length fields (scriptsigs, outputs) could be changed to make it easier to work with from script. (Maybe, minor change)
   2. Should CTV include more template types? Possibly, CTV includes an upgrade mechanism baked in for new template types, so it is extensible for future purposes.
   3. Should CTV commit to the amounts? CTV does not commit to the amount that a coin has. Input-inspecting functionality should be handled by separate opcodes, as CTV would be overly restrictive otherwise. E.g. dynamic fees through new inputs would be harder: given CTV’s design it is not possible to detect which field did not match therefore it is not possible to script against unexpected amount sent errors without some compromise (e.g. timeouts).
3. CAT is simplistic, and there are really few ways to implement it. However, because it requires some restrictions for security, there are difficult to answer open design questions:
   1. What is the appropriate maximum stack size CAT should permit? Currently the design in Elements is 520 bytes, the max general stack size permitted in script.
   2. Should CAT be introduced or SHASTREAM, SUBSTRING, or another variant? There is a strong argument for SHASTREAM because when constructing covenants (e.g. for use with CTV) based on TX data it’s possible for size of a data field (e.g., serialization of all outputs) to exceed 520 bytes.
4. There are many tough questions that the community has grappled with during APO’s design and engineering process, generally asking how APO-like techniques can be made ‘Generally Safe’ given iit breaks current assumptions around address reuse.
   1. Should APO require chaperone signatures (in order to ensure that replay is not done by 3rd parties)? Current Answer: No, anyone is free to burn their keys by revealing them to similar effect.
   2. Should APO use key tagging to mark keys that can use APO: Current Answer: yes, APO should be “double opt-in” (both requiring a tag and a signer to produce such a signature)
   3. Should APO allow signing with the external taproot key: Current Answer: no, because it makes APO not “double opt-in”.
   4. Should APO optimize signing with the internal taproot key? Answer: default key 0x01 refers to taproot internal key, so it can be made cheaper if you’re going to need it without having to repeat the entire key.
   5. Should APO commit to the signing script? Answer: let’s do two variants.
   6. Should APO instead be a larger refactoring of sighash logic that encapsulates APO (e.g. sighash bitmasks)? Current Answer: No, APO is good enough to ship as is and doesn’t preclude future work.

Safety

This category covers how “safe” each change is ranked from safest to least safe. What makes a change more or less safe is how limited and foreseeable the uses are of a specific opcode, in other words, how well we understand what it can do or where it might interact poorly with deployed infrastructure.

1. CTV
2. CSFS
3. APO
4. CAT

CTV is the safest new feature since fundamentally what it introduces is very similar to what can be done with pre-signed transactions, so it is only a pivot on trust and interactivity. Where there is some risk from CTV is that addresses (or rather, invoices) that are reused might have the same program behind them which could cause unintended behavior. This differs from the reuse problem in APO because the problem is stateless, that is, if you verify what is behind an address you will know what exists and does not exist. E.g., two payment channel addresses will create distinct payment channels that updates cannot be replayed across. In contrast with APO, paying one APO using address twice creates two instances of the same channel, state updates from one channel can be used on the other.

CSFS is the next safest, it is just a small piece of authenticated data. CSFS and CTV are relatively close in terms of safety, but CSFS is slightly less safe given a remote possibility of surprising uses of it to perform unforeseen elliptic curve operations. This functionality already exists for up to 5-byte messages. A hash preimage revelation can emulate a signer compactly. Using binary expansions and addition could be used to allow signing of values more compactly (e.g., 2x16x32 byte hashes could be used to construct a signature of a post-hoc selected Sequence lock). Read more here. Therefore it is appropriate to think of CSFS as an expansion of the efficiency of this technique, reusability of keys, and the types of data that can be signed over. Although CSFS is famously used to build covenants by comparing a CSFS signature to a CHECKSIG signature and getting transaction data onto the stack, CSFS cannot do that without CAT.

APO. This is the next safest because APO has some questions around key reuse safety and statefulness of information. See the above description in CTV for why this is tangibly worse for APO than CTV. See more discussion of APO’s safety & design trade offs here.

CAT is the least ‘safe’ in terms of extant Bitcoin concepts as it is highly likely CAT introduces at least advanced covenants if added, especially in conjunction with the above opcodes, but may also enable other unintended functionality. CAT is a source of continual surprise with regards to what it enables in composition with existing opcodes, therefore a systematic review of composability and known uses should be done before considering it. That CAT was forked out by Satoshi is of limited relevance as the variant proposed for reintroduction would not have the vulnerability present initially.

Complimentary Upgrades

Pairings of upgrades can work together to deliver functionality that neither could alone:

1. CAT + CSFS: full blown arbitrary covenants
   1. With arbitrary covenants you can deploy many different kinds of smart contracts which are out of scope for this article.
2. CAT + CTV: Expanded covenants
   1. slightly simpler to use interface but fewer features than CSFS + CAT which can covenant over witness data and inputs.
3. CTV + CSFS: Eltoo
   1. This can add very similar functionality to eltoo with the script fragment: CTV <musig(pka, pkb)> CSFS <S+1> CLTV The protocol is essentially identical to the Eltoo paper, however there are a couple subtle differences required for dynamic fee rates.
4. CTV + APO: Slightly Different
   1. Several sources have claimed that APO offers a strict superset of CTV’s functionality (but not efficiency). This is false. Their digests are slightly different, as such there are some niche smart contracts that could use the differences in commitment structure for interesting effects (CTV commits to all scriptsigs and sequences, APO cannot cover that data but can cover a few variants of less data covered).

By all means not an exhaustive list – feel free to message me with additions.

Recommendation

My recommendation is to deliver the upgrades described in this document in the following order:

1. CTV
2. CSFS
3. APO
4. CAT/SHASTREAM/SUBSTRING/etc

This recommendation comes as a synthesis of the thoughts above on the composability, safety, and open design considerations of the various proposals currently in flight.

With CTV in place, we can begin experimenting with a wide variety of contracts using the Sapio toolchain, as well as improve and invest in maturing the toolchain. Mature toolchains will make it easier to safely engineer and deploy applications making use of CTV and future upgrades.

CSFS is an independent change that can be deployed/developed in parallel to or before CTV, the implementation from Elements could be easily ported to Bitcoin. With CSFS and CTV, Eltoo-like constructions will be possible as well.

APO can then be deployed as an optimization to existing use patterns driven by market adoption of CTV+CSFS based use. This also gives us time to kick the can down the road on the design questions that APO prompts around generalization of signature digests and key reuse safety. A similar approach was discussed on the mailing list, but without the insight that CSFS + CTV was sufficient for Eltoo like constructions, requiring CAT instead.

Lastly, OP_CAT can be delivered as part of an effort towards generalized arbitrary covenants and perhaps in conjunction with some special purpose opcodes (such as OP_CHECKINPUT) that can more easily handle common cases. CAT, although it has safe implementations used in Elements, deserves very strict scrutiny given it’s documented surprising uses.

This approach represents a gradual relaxation of Bitcoin’s restrictions around smart contract programming that introduces useful, safe primitives and gives the community time to build and deploy useful infrastructure. The path described in this post is an opportunity to upgrade bitcoin with simple primitives that compose nicely for permissionless innovation.

Thanks to those who reviewed drafts of this post and provided valuable feedback improving the clarity and accuracy of this post, including pyskell, Keagan McClelland, Ryan Gentry, and Olaoluwa Osuntokun. Edit + Feedback ≠ Endorsement.

Giving Money Away?

a version of this originally appeared on tokendaily.co, I still need to verify all edits match.

Give a Man a Bitcoin, and You Feed Him for a Day. Teach a Man To Mine Bitcoin, and You Feed Him for a Lifetime. – Ancient Proverb

Don’t snooze – many cryptocurrency projects are giving away coins for free – act fast and you can get some too! Whatever they call it: an airdrop, a share, a gift, a giveaway, etc, the idea is the same, noble intentions of correcting long-standing social iniquities by “giving money away” (in the form of cryptocurrency) to disenfranchised groups¹. The disenfranchised group varies project-to-project; sometimes it is F/LOSS developers, sometimes all internet users, low-income individuals, etc.

There’s a catch that subverts this good intention – even ignoring difficult issues around identification of real users – it’s really hard to effectively correct these iniquities by giving away cash.

Plans that simply give out assets are misguided, because they conflate money with a different, though related, concept: wealth.

There are many ways to define these terms, but in this article I’ll define wealth as an individual’s ability to instigate changes that improve their current situation in some capacity. For example, I am wealthy if I know how to fix my own car when it breaks down. There are also harder to quantify forms of this wealth which only exist relative to a group such as leadership ability.

On the other hand, for this article, I’ll define money as a tool for convincing others of an individual’s wealth when they want something. For example, I could get a mechanic to fix my car in exchange a service or good of equal value – perhaps I can give the mechanic some advice on her ICO pitch deck – but in many cases it’s difficult to find something the other party wants, values equally, knows I have, or that I am able to offer currently. Instead, I give the mechanic a fixed amount of money, which is an easier to agree on means of exchange, unit of account, and store of value.

In another sense, money is a symptom of wealth. Where there is smoke, there is fire. Where there is money, there should be wealth. If one has a valuable skill, such as knowing how to rebuild an engine, one can use it to acquire money. While having money might be a good indicator that one possesses some valuable skill, you can easily imagine situations where this would be a false indicator – like lottery winners.

Giving money to a person lacking financial responsibility is unlikely to increase their wealth; like trying to use a cloud of smoke to start a fire. Lottery winners exemplify the challenge of converting ‘unearned’ money into wealth, about a third or more quickly go bankrupt despite their winnings². Intuitively, if you wouldn’t invest in a slot jockey with your money before they hit the jackpot, what makes you think they’d do any better with their winnings?

Giving people wealth is more effective than giving them money. But is giving away wealth possible? And just how effective can giving away money truly be?

Let’s set those questions aside for a moment, we’ll revisit them later.

For now, we’ll construct a toy model³ for discussing giveaways. As with any model, this toy model is overly simplified for many reasons – I’ll do my best to clarify which things are simplified. The main purpose in presenting a toy model is to establish a common framework for how to think about giveaways.

Suppose we can represent everyone in the world’s assets as a vector \(v_a\) and their wealth as a vector \(v_w\). Assets are tangible things usable for transactions or ownership, and wealth is a measure of an individuals quality. For instance, a debit card uses assets and a credit card uses wealth.

We can model assets as a proxy for wealth, and model the efficiency of the proxy with a cost function such as Euclidean distance between the normalized vectors. We normalize the vectors to account for unit bias⁴, if everyone had $100 or $1M, it wouldn’t matter.

In reality, Euclidean distance may be a really poor choice of cost function – perhaps a better choice is cosine similarity, perhaps there is a regularization parameter that says cost should be higher if the distribution doesn’t fall along a power law, perhaps Gini coefficient⁵ should be included, etc. But we will get a lot of mileage out of using a simple cost function for discussing the general shape of the problem.

I posit you can only meaningfully give people assets insofar as the giveaway works to minimize the cost function subject to a regularization parameter (otherwise our giveaway might be too radical, which could destabilize the economy). For example, the following formula is one possible giveaway cost function:

In plain English, you want the smallest giveaway for the largest correction in wealth/assets disparity. If \(C_G(v_a, v_w, \Delta v_a) > 0\), then you destabilize the monetary supply.

Again, this cost function is only offered as an example. We may also care about other regularizations against different types of giveaways – for instance, we might want to penalize giveaways that are ‘unfair’ with high variance between amounts – but we can use this model a starting point to look at a few examples.

If you want to follow along, the model is in python below:

def norm(v):
  w = sqrt(sum(map(lambda x: x**2, v)))
  if w == 0: return v
  return [x/w for x in v]

def cp(m, w):
  return sqrt(sum(map(lambda (a,b): (a-b)**2, zip(norm(m), norm(w)))))

def cg(m,w,dm, eta=0.01):
  return cp([a+b for (a,b) in zip(m, dm)], w) - cp(m, w) + eta*sqrt(sum(x**2 for x in dm))

To work a quick, concrete example of correcting inequalities:

Suppose Alice has $10 and Bob has $20, but Alice is “worth” $10 and Bob is “worth” $12. I.e., \(v_a = [10, 20], v_w = [10, 12]\). To correct for the inequality, we either want Alice to have more money or Bob to have less. How bad is the current inequality? The cost function tells us \(C_P([10, 20], [10, 12]) \approx 0.23\).

Suppose \(\eta = 0.01\).

Let’s examine four plausible giveaways

What if we give everyone a small amount? \(\Delta v_a = [1, 1] \to C_G \approx -0.0046\)

Negative cost! It works! By increasing Alice’s and Bob’s assets, we made the overall efficiency of the monetary supply better.

What if we give everyone a lot!

Too much! Our money is less efficient.

What if we tax Bob a little and give to Alice?

What if we tax Bob a lot and give the tax to Alice?

What if we just destroy some of Bob’s assets?

Let’s look at these examples as graphs. In the below graphs of giveaways, the blue areas are efficient, the red is inefficient, and the white areas are neutral. On the X axis is the amount Alice is to receive, on the Y axis Bob. Mind the scales on the right.

Nice – there is a large blue region where we can improve the inequality! This region is roughly a line segment from \((-10, -20)\) to \((18, 12)\).

In reality, in this model we might want to pick \(\eta\) such that the regularization amount is 1 if the size of the giveaway is the same as the monetary supply:

Now, the blue region is much smaller, and the maximum magnitude of the benefit is several orders of magnitude smaller. The giveaway doesn’t work that well!

Finding cost-reducing giveaways may be impossible in many circumstances (e.g., with a slightly greater \(\eta\)). This is always the case if the cost-function \(C_G\) is positive semi-definite with respect to the initial condition.

It bears repeating: this model is heavily simplified. In a real scenario, the regularization is much likely much larger.

Major wealth transfers often involve war, death, and destruction. Intuitively, if I stand to lose $M dollars, I am willing to spend $M dollars to prevent that loss (even if the total loss may be larger – see war of attrition⁶)

We also can’t simply find the blue-zones easily – ultimately, we don’t know how wealthy everyone is exactly and there are billions of people, not just two. Wealth is not a fixed quantity. Just giving someone assets doesn’t make them wealthier, nor does taking away some of their assets in the short term. In the long term, however, people’s wealth drifts and moves.

There’s been a lot of research that’s been done on the efficacy various forms of giveaway. Here’s a run down on 4 cases:

Example 1: Finland gave away 560 euros/month to 2,000 randomly selected unemployed Finns for two years. Finland didn’t find an increase in employment, but did find increased happiness. When the recipients base was slated to increase, unsavory side effects such as increased nationalism manifested⁷.

Example 2: GiveDirectly gives unconditional cash transfers to impoverished areas in East Africa. GiveDirectly claims to have seen a large improvement in the earnings of those who received unconditional cash transfers several years after the transfer⁸.

Example 3: The EU Africa Emergency trust, which is referenced in the Economist⁷, set up gifts to give to residents of countries which were below a certain poverty threshold if the government would share key reports and data. The program faced budgetary issues.

Example 4: GiveCrypto is a brand new initiative which gives crypto wallets with coins (unclear which ones) to those in need. This is substantial because cryptocurrency also helps fill in with banking infrastructure, unlike previous programs like GiveDirectly which relied on existing analog systems.

A problem shared across these studies broadly is that they are not large enough. The amounts of money dispersed is significantly smaller than the magnitude of inequality between the sponsors and the recipients. Performing such socioeconomic experiments at scale may self destruct an economy and society unwilling to bear the cost of a non-experiment sized giveaway. Increasing nationalism, as seen in Finland, could be a precursor for increased violence or decreased long term global development.

A second issue is that these programs are targeted at increasing wealth, not decreasing inequality. As is often said, a rising tide raises all boats. If the global economy improves as a result of assisting impoverished individuals, the benefit is not clearly greater for the receiver than the giver. For instance, the giver may benefit greatly from having new agricultural trade, sources of cheap educated labor, advanced manufacturing capability, or from increasing peace in troubled regions defraying the risk of costly wars.

A third concern is that such programs create subversive reliance. For instance, in Gambia, when politicians wanted to stop passing on surveillance data to the EU, which would end the payments, mass protests erupted. The Gambian citizens were put into a precarious relationship with the EU, whereby the EU had the power to influence their politics and conduct – perhaps against their longer term interests. This emphasizes the importance of unconditionality, as promulgated by GiveDirectly. Unfortunately, the discretion to continue or not continue a giveaway itself constitutes a conditionality. It’s best to structure programs so as to minimize the chance of dependence or economic reliance for the independence and freedom of the recipients.

Let’s look examine some strategies in light of the real world research and our model.

Give Small Amounts, Frequently

Giving away a large amount should be mostly infeasible because of regularization. However, by giving away small amounts repeatedly, we have an opportunity to re-examine the money to wealth ratios for each individual, and we also give the money distributed a chance to impact wealth. This is reminiscent of gradient descent as used in Machine Learning⁹.

The down side is that if the distributions are too small then the economy can sufficiently absorb and dissipate the extra money without benefiting anyone, and if they are too frequent then it may not be different than a single larger giveaway, causing chaos.

Target Specific Groups with Bad Wealth : Assets Ratios

One way to improve the odds of our distribution working is by finding small communities with bad money to wealth ratios and focusing on them exclusively. This is essentially the GiveDirectly model for working in East Africa.

However, we must be careful. Because of the normalization of the assets vector, giving money to one person fundamentally takes money from everyone else.

Shown below, 90 people with 10 wealth and 10 assets each, and 10 people with 10 wealth and 1 assets each. We give all 10 asset-poor people X assets each. Y is \(\eta\), the learning rate.

This shows us that there is a range of reasonable giveaways, so long as we discount giving money heavily (above \(\eta \approx 0.01 \) everyone is made worse off giving away any money).

It’s also critical to ensure that this is somewhat Pareto Efficient – if increasing the wealth of one group puts them on par or above another, that other group may suffer. For instance, if supporting a poor community results in a flood of agricultural products, existing farmers quality of life may be made worse.

Self Determination & Currency Competition

One way to improve the efficiency of the money supply is to allow people to issue currencies at will for whatever group wants to.

The price discovery process for this currency on the open market serves as a feedback loop for if that distribution formed a good giveaway or not and the integrity of those who operate and hold the new currency.

Internally to the group self-determining, the new currency should be viewed as more efficient among the group itself.

In a parallel world, instead of GiveCrypto, there’s GiveLiquidity which buys and sells cryptocurrencies issued by communities to help them bootstrap internationally. This would help avoid colonialist influence because communities would have more autonomy over the new money supply they are adopting.

Increase Wealth Directly

This is a bit of a trick. Recall, our cost functions from our toy model are about optimizing our money supply – not our overall outcome.

Individual wealth can increase directly without a gift of assets. For instance, sponsoring educational programs is a way to increase the wealth of society – this is commonly done through subsidized school programs. There’s evidence that shows that unconditional cash transfers increase attendance at schools more than conditional transfers, but improving the quality of education available could provide an even larger boost.

Another take on this is to remove “wealth-conversion depressants”. An example of this is hair stylist licenses¹⁰, they ultimately serve as a barrier for entry based on assets available (not based on skill).

Counteracting Another “Giveaway”

If other contemporaneous events emulate a giveaway that redistributes assets in such a manner that there is a substantial worsening of wealth to assets ratio, a concurrent giveaway could counteract this. Two examples of this are giving resources to educated refugees and asylum seekers who left behind their property and assets (the conflict is reassigning their assets via violence) as is being done in Turkey¹¹ and proposals to use Bitcoin in Venezuela to counteract the instability of the Bolivar¹².

In writing this article, my hope was not to convince you that you can’t make people’s lives better – au contraire! Working to improve the human condition is something that each and every one of us should do every day, and I laud those trying, even if I disagree with their tactics.

I do hope that you are left understanding how difficult it is to give away money with good effect. Fully fixing the inequality would cause massive upheaval and disorder, increasing the fairness but decreasing the wealth. Peer reviewed experiments with promising results are unlikely to scale because they don’t run up against this societal regularization. They also, at scale, may cause an untold loss of liberty as more income is unearned and dependent on the discretion of the ruling class.

I’ll leave you with this: In setting up the dichotomy between wealth and assets, I’ve completely side-stepped the much more interesting question: wealth inequality. Is it an issue if someone else is, by natural virtue, exponentially better off than me? Should that inequality be rectified? Can it be? When a new disease breaks out, the immunologist’s value to society increases, maybe that’s how it should be. Maybe we could all attain equal wealth at the cost of our individuality. Or perhaps we could all be equal, but none great. Maybe our best bet is for each of us to ask, are we better off than we were before; and what can we do for those of among us who are not as fortunate?

Open Letter on Diversity & Inclusion at Scaling Bitcoin

ATTN: Scaling Bitcoin Participants and Sponsors

We started Scaling Bitcoin with a deep commitment to diversity and inclusion. Fundamentally, Scaling Bitcoin is about bringing together elements of the Bitcoin community that would not otherwise – many of the core contributors met face to face for the first time in Montreal. Meeting face to face was a fantastic opportunity to bridge divides and seek common goals; at Scaling Bitcoin spontaneous discussions broke out which would have never occurred online. Diversity and inclusion are key elements in pulling together different parts of our community to have the discussions fruitfully. Fundamentally Scaling Bitcoin exists to work towards eliminating any barrier to entry for any person to contribute to Bitcoin’s scientific and engineering ecosystem.

Diversity and inclusion are complicated multi-faceted topics – at Scaling Bitcoin, we do our best to address them from all sides. Our conference aspires to be in a different region every time, from our first event in Montreal, to Hong Kong, to Milan, and now, to Silicon Valley. Our participants and sponsors come from all over the world (18 countries at the last event!), speak many different languages, and have vastly different perspectives on how we’ll accomplish our shared goal of Scaling Bitcoin.

We help people attend Scaling Bitcoin who would not be able to otherwise as a part of our diversity and inclusion efforts. This help comes in multiple forms, including discounted tickets for students, as well as travel and accommodation assistance for those who require it. Our chief concern is getting the individuals most likely to contribute to Bitcoin’s scientific and engineering ecosystem to the conference. We also try to help those who face additional difficulties to better integrate into the community. In past Scaling Bitcoins, this has included efforts and special programming through our academic supporting organizations to better socially integrate low-income, minority, and female participants at Scaling Bitcoin. For example, at Milan one of our Academic partners (The MIT DCI) hosted a special dinner for the students from their summer bootcamp (you can read about it here) to get to interact with some core developers in a smaller group setting.

Bitcoin developers and scientists don’t just materialize overnight, it requires diligent study and effort. This is an intimidating prospect for almost anyone, and many capable developers drop out for lack of good support. Initiatives like Chaincode’s Hacker Residency and DGLAB’s BC2 workshop have been wildly successful in nurturing talented Bitcoin Core Developers. Scaling Bitcoin is simply doing our part to onboard more talent. Explicitly seeking to onboard talent from diverse backgrounds is a critical for engineering Bitcoin to be an empowering technology to meet the needs of users all over the world. The last several decades of research on the subject shows that seeking out social diversity leads to better decision-making across the board (read about the research here).

This year, as a part of our efforts to improve Scaling Bitcoin by better structuring our Planning Committee we created a Diversity & Inclusion Committee. This committee is comprised of individuals who were excited to help us to continue our efforts around diversity and inclusion. One of the main tasks for this committee is to help us review and process subsidy requests, which are awarded based on many factors, including, likelihood of contributing to Bitcoin’s scientific and engineering ecosystem, demonstrated need, and total cost (we have a limited budget, after all). Despite now having an explicit committee for diversity and inclusion, it continues to be the job of every volunteer in Scaling Bitcoin to work towards eliminating any barrier to entry for any person to contribute to Bitcoin’s scientific and engineering ecosystem. Different people experience different barriers to entry to a field like Bitcoin, thus, the kinds of support programs we offer are not always available to everyone (we can’t afford to give everyone student ticket pricing!). The Diversity & Inclusion Committee is there to ensure that our efforts are fair and sufficient.

Technology conferences like Scaling Bitcoin present a remarkable opportunity for building community. In light of recent reports of incidents of harassment and exclusionary practices at tech conferences, we’ve take a progressive stance on making sure that Scaling Bitcoin remains a respectful and safe space for all of our participants to build that community. Incidents of harassment and exclusionary practices negatively impact people of all genders, races, and backgrounds, as well as the conferences and their communities. We take such issues seriously and have required all participants to follow our Code of Conduct since the first Scaling Bitcoin event in 2015.

Part of what makes Scaling Bitcoin such a remarkable gathering is the intense level of focus on the technology during the event. Our CoC exists to minimize the possibility of distractions and to maximize the learning, shared understanding and technical advancement of one of the most important engineering projects of our time. We hope that our attendees recognize and support that objective, and the organizing committee will as well.

Additionally, the Program Committee, which handles talk selection, operates with complete autonomy from the rest of the Scaling Bitcoin organization, including the Diversity & Inclusion Committee. No one is excluded from the conference as a result of our diversity and inclusion efforts. The main goal of the Program Committee is to unbiasedly select talks with the highest potential impact on Bitcoin. The majority of tickets are sold openly to the public. We welcome any suggestions and ideas from the Bitcoin community as to how our efforts can be more effective and we will continue to do our best to make Bitcoin a more diverse and inclusive environment.

We’re excited to be hosting what we expect to be the best Scaling Bitcoin yet this year. To increase our reach and impact in the community, we’re hosting a 2 Day tutorial preceding Scaling Bitcoin called Dev++. This is a wonderful opportunity for those just entering the space to get fast-paced high-quality instruction on becoming a Bitcoin Engineer. Following the conference, we will have a Career Fair and an event for startups to pitch to investors. You can read more about these new initiatives at BitcoinEdge.org.

Sincerely,

Jeremy Rubin

Scaling Bitcoin Planning Committee

With special thanks to Byron Gibson, Neha Narula, and the rest of the Scaling Bitcoin Planning Committee for reviewing and editing this letter, and for maintaining a strong commitment to diversity and inclusion in Bitcoin.

United States Government Censorship of Fuck Nazis Virtual Lapel Pin

My Right to Say "Fuck Nazis"

When I woke up in the morning of September 1st, 2017 I immediately began my morning ritual of lazily glancing through emails. On this morning, one particular email stood out — the Fuck Nazis Virtual Lapel Pin had been censored by the United States Government.

Let’s jump back a minute for some context.

On August 19th, 2017 I began a new project, the Fuck Nazis Virtual Lapel Pin. The project’s goal was to raise funds to resist the recent uptick in Nazism and other forms of violent racist extremism in America. The Fuck Nazis Virtual Lapel Pin is a unique fund-raiser because donors quid-pro-quo receive a digital asset in return for their contribution, I hoped this would harness the excitement around the emerging “Initial Coin Offering” phenomenon.

The reception was not as positive as I had hoped it would be — earlier in the week, I had been subject to some minor censorship by the Ethereum Maintainers and Community Moderators.

On September 1st, 2017 at 2:40 AM Pacific Daylight Time Neustar initiated a transfer of my domain. One hour and 29 minutes later Neustar sent me an email explaining the transfer.

I’ve sent Neustar an email requesting that they reinstate my registration, but I’ve not yet heard back from them.

Neustar is a contractor hired by the U.S. Governemnt to operate the .us TLD. Because they are managing a federally owned property, I beleive they are obligated to follow the First Amendment with respect to registered names. Otherwise, I do not think the FCC may legally continue to use them as a contractor. To quote ICANNWatch:

[W]hile a private entity like Neustar is under no intrinsic obligation to respect the First Amendment, the fact that they did this under government consultation, and pursuant to a government-granted charter to operate the country code registry for the United States, raises serious issues of Constitutionality.

It’s not a strange expectation to hold that contractors of the United States Government must abide by constitutional provisions. For instance, private prisons are not at liberty to exact cruel and unusual punishments. Kimberly N. Brown delivers a thorough treatment of this in “We the People,” Constitutional Accountability, and Outsourcing Government. While there are controversial cases, it is generally clear that public actors must hold accountable private actors that they delegate their constitutional powers to.

Notwithstanding the concern over whether it is the FCC or Neustar who is legally culpable, we can safely assume that the FCC is bound to ensure that Neustar respects constitutional rights in fulfilling their duties as a government contractor, and therefore examine Neustar as a government actor.

Neustar’s management policy document can be found here. The relevant sections are B-78 and B-98. Neustar claims that they will review domains which contain the “7 Words” and possibly delete them (presumably, ensuring that they are not violating the registrant’s First Amendment rights). Their claim is that the domain fucknazis.us violate’s the “7 Words” policy enforced by Neustar. (This is a reference to George Carlin’s infamous Seven Dirty Words skit) In this case, the presence of “fuck” in the domain is what alerted Neustar to need to review my domain. However, in failing to waive fucknazis.us I believe they violated my First Amendment rights.

There are three major relevant Supreme Court cases here, Cohen v. California (1971), Miller v. California (1973), and FCC v. Pacifica Foundation (1978).

In Cohen v. California, a man was arrested for disturbing the peace for wearing a “Fuck the Draft” shirt. In this case, the speech was found to be protected by the First Amendment for multiple reasons. Most relevantly, the court refused to recognize the speech as “Fighting Words”, or speech intended to elicit violence. This is because Cohen’s voiced dissent of the draft was not intended to elicit any violence, it was simply to voice an opinion. Similarly, the material published on the Fuck Nazis site was clearly in support of non-violent action, e.g.

As a first measure, and irrespective of what is most effective, I want to use funds raised ensure that it is possible to protest these Nazis as safely as possible. No one should permit the Nazis to intimidate them out of their freedom to speak against them.

along with a list of other non-violent actions I would use the funds raised to support. The court went further to find that

Finally, and in the same vein, we cannot indulge the facile assumption that one can forbid particular words without also running a substantial risk of suppressing ideas in the process. Indeed, governments might soon seize upon the censorship of particular words as a convenient guise for banning the expression of unpopular views. We have been able, as noted above, to discern little social benefit that might result from running the risk of opening the door to such grave results.

This makes it clear that the censorship of Fuck Nazis Virtual Lapel Pins by revocation of the domain fucknazis.us is unconstitutional.

Miller v. California is a case of a very different nature involving the distribution of pornographic content, but it established a simple three-prong test for unprotected explicit speech. If you pass all three tests, then the work is considered obscene.

(a) whether “the average person, applying contemporary community standards” would find that the work, taken as a whole, appeals to the prurient interest.

Fail: Fuck Nazis is clearly non-pornographic and elicits no sexual response.

(b) whether the work depicts or describes, in a patently offensive way, sexual conduct specifically defined by the applicable state law.

Fail: Fuck Nazis is clearly non-sexual.

(c) whether the work, taken as a whole, lacks serious literary, artistic, political, or scientific value. If a state obscenity law is thus limited, First Amendment values are adequately protected by ultimate independent appellate review of constitutional claims when necessary.

Fail: Fuck Nazis is a political and artistic project, and is presented cogently.

Having clearly failed all three tests, Fuck Nazis is non-obscene protected speech by all measures.

Critically, both Cohen v. California and Miller v. California are both rulings with regards to the state’s ability to restrict speech. Only FCC v. Pacifica Foundation deals with the federal government’s ability to restrict “obscene” speech, which established the “7 Dirty Words”.

The critically relevant part of FCC v. Pacifica Foundation is that the measures enforce by the FCC (to only broadcast during hours children are unlikely to be awake) did not prevent adults from accessing and finding the content. In this case, Neustar’s actions against Fuck Nazis does prevent adults from accessing the content unadulterated (whereas the time restriction enforced by the FCC permitted identical material to be broadcast at a reasonably later time). Furthermore, based on Neustar’s enforced policies I would be able to register the domain “nazis.us” (if it were available — it’s been held since 2014) and use the subdomain “fuck” giving me the “fuck.nazis.us” domain. This makes the case that there is zero benefit from the measure taken by Neustar, at the expense of the significant burden of forcing me to change a domain that I have already linked to in numerous communications. Of greater concern is the general freedom of speech risk established by this enforcement mechanism.

Based on the above, Neustar, acting as an agent of the United States government, plainly violated my First Amendment rights causing damages to my project that are difficult to quantify given that the fund-raiser I was hosting on the site is ongoing.