no cats harmed in the making of this post
06 Jul 2021
I recently published a blog
post about signing up to a
5 byte value using Bitcoin script arithmetic and Lamport signatures.
By itself, this is neat, but a little limited. What if we could sign longer
messages? If we can sign up to 20 bytes, we could sign a HASH160 digest which
is most likely quantum safe…
What would it mean if we signed the HASH160 digest of a signature? What the
what? Why would we do that?
Well, as it turns out, even if a quantum computer were able to crack ECDSA, it
would yield revealing the private key but not the ability to malleate the
content of what was actually signed. I asked my good friend and cryptographer
Madars Virza if my intuition was correct, and he
confirmed that it should be sufficient, but it’s definitely worth closer
analysis before relying on this. While the ECDSA signature can be malleated to a
different, negative form, if the signature is otherwise made immalleable there
should only be one value the commitment can be opened to.
If we required the ECDSA signature be signed with a quantum proof signature
algorithm, then we’d have a quantum proof Bitcoin! And the 5 byte signing scheme
we discussed previously is a Lamport signature, which is quantum secure.
Unfortunately, we need at least 20 contiguous bytes… so we need some sort of
OP_CAT like operation.
OP_CAT can’t be directly soft forked to Segwit v0 because it modifies the
stack, so instead we’ll (for simplicity) also show how to use a new opcode that
uses verify semantics, OP_SUBSTRINGEQUALVERIFY that checks a splice of a string
for equality.
Fun Fact: OP_CAT existed in Bitcoin untill 2010, when Satoshi “secretly”
forked out a bunch of opcodes. So in theory the original Bitcoin implementation
supported Post Quantum cryptography out of the box!
... FOR j in 0..=5
<0>
... FOR i in 0..=31
SWAP hash160 DUP <H(K_j_i_1)> EQUAL IF DROP <2**i> ADD ELSE <H(K_j_i_0)> EQUALVERIFY ENDIF
... END FOR
TOALTSTACK
... END FOR
DUP HASH160
... IF CAT AVAILABLE
FROMALTSTACK
... FOR j in 0..=5
FROMALTSTACK
CAT
... END FOR
EQUALVERIFY
... ELSE SUBSTRINGEQUALVERIFY AVAILABLE
... FOR j in 0..=5
FROMALTSTACK <0+j*4> <4+j*4> SUBSTRINGEQUALVERIFY DROP DROP DROP
... END FOR
DROP
... END IF
<pk> CHECKSIG
That’s a long script… but will it fit? We need to verify 20 bytes of message
each bit takes around 10 bytes script, an average of 3.375 bytes per number
(counting pushes), and two 21 bytes keys = 55.375 bytes of program space and 21
bytes of witness element per bit.
It fits! 20*8*55.375 = 8860, which leaves 1140 bytes less than the limit for
the rest of the logic, which is plenty (around 15-40 bytes required for the rest
of the logic, leaving 1100 free for custom signature checking). The stack size
is 160 elements for the hash gadget, 3360 bytes.
This can probably be made a bit more efficient by expanding to a ternary
representation.
SWAP hash160 DUP <H(K_j_i_0)> EQUAL IF DROP ELSE <3**i> SWAP DUP <H(K_j_i_T)> EQUAL IF DROP SUB ELSE <H(K_j_i_1)> EQUALVERIFY ADD ENDIF ENDIF
This should bring it up to roughly 85 bytes per trit, and there should be 101
trits (log(2**160)/log(3) == 100.94), so about 8560 bytes… a bit cheaper!
But the witness stack is “only” 2121 bytes…
As a homework exercise, maybe someone can prove the optimal choice of radix for
this protocol… My guess is that base 4 is optimal!
Taproot?
What about Taproot? As far as I’m aware the commitment scheme (Q = pG + hash(pG
|| m)G) can be securely opened to m even with a quantum computer (finding q
such that qG = Q might be trivial, but suppose key path was disabled, then
finding m and p such that the taproot equation holds should be difficult because
of the hash, but I’d need to certify that claim better). Therefore this
script can nest inside of a Tapscript path – Tapscript also does not impose a
length limit, 32 byte hashes could be used as well.
Further, to make keys reusable, there could be many Lamport keys comitted inside
a taproot tree so that an address could be used for thousands of times before
expiring. This could be used as a measure to protect accidental use rather than
to support it.
Lastly, Schnorr actually has a stronger non-malleability property than ECDSA,
the signatures will be binding to the approved transaction and once Lamport
signed, even a quantum computer could not steal the funds.
02 Jul 2021
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.
- CSFS
- CTV
- CAT
- APO
Explanations & Open Questions:
- CSFS is very simple and there is essentially a single way to implement it. Three open questions are:
- Should CSFS require some sort of tagged hash? Very likely answer is no –
tags interfere with certain use cases)
- 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
- 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.
- 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.
- 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)
- 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.
- 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).
- 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:
- 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.
- 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.
- 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.
- 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.
- 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)
- Should APO allow signing with the external taproot key: Current Answer:
no, because it makes APO not “double opt-in”.
- 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.
- Should APO commit to the signing script? Answer: let’s do two variants.
- 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.
- CTV
- CSFS
- APO
- 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:
- CAT + CSFS: full blown arbitrary covenants
- With arbitrary covenants you can deploy many different kinds of smart
contracts which are out of scope for this article.
- CAT + CTV: Expanded covenants
- slightly simpler to use interface but fewer features than CSFS + CAT which can
covenant over witness data and inputs.
- CTV + CSFS: Eltoo
- 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.
- CTV + APO: Slightly Different
- 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:
- CTV
- CSFS
- APO
- 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.
30 Jun 2018
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.
\[C_P(v_a, v_w) = \sqrt{(\hat{v}_m - \hat{v}_w)^2}\]
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:
\[C_G(v_a, v_w, \Delta v_a) = C_P(v_a + \Delta v_a, v_w
) - C_P(v_a, v_w) + \eta \cdot || \Delta v_a||\]
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!
\[\Delta v_a = [10, 10] \to C_G \approx 0.018\]
Too much! Our money is less efficient.
What if we tax Bob a little and give to Alice?
\[\Delta v_a = [1, -1] \to C_G \approx -0.047\]
What if we tax Bob a lot and give the tax to Alice?
\[\Delta v_a = [6, -6] \to C_G \approx 0.011\]
What if we just destroy some of Bob’s assets?
\[\Delta v_a = [0, -11] \to C_G \approx 0.023\]
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:
\[\eta = \frac{1}{||v_a||} = \frac{1}{\sqrt{10^2 + 20^2}} \approx 0.045\]
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?
