path: root/e1/a3370e9f82bca165ebf8be76275e4767458c38

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 16E7AC001E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  5 Jan 2022 22:45:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id E428882C89
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  5 Jan 2022 22:45:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id pX6rvAOdTWS7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  5 Jan 2022 22:45:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp1.osuosl.org (Postfix) with ESMTPS id F035E82BED
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  5 Jan 2022 22:45:09 +0000 (UTC)
Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com
 [209.85.167.47]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 205Mj692000398
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 5 Jan 2022 17:45:07 -0500
Received: by mail-lf1-f47.google.com with SMTP id g11so1149271lfu.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 05 Jan 2022 14:45:07 -0800 (PST)
X-Gm-Message-State: AOAM533eUVxEn2p2dRmc72+OmHzStau4z8WLbOKmvm1uT1mqMmFYJMMO
 hY+W/LZcxfhFLqlhtEeTN2NxZqXZjarIManChNA=
X-Google-Smtp-Source: ABdhPJy5in9ZkjA0RzPdYYI3sFX8sqRT3S19fLgyNRc9PVgmncYuStvnutQuSwjCpGtjGBh0/S34nPaghOErT3vyZ3k=
X-Received: by 2002:a05:6512:210f:: with SMTP id
 q15mr38457110lfr.112.1641422706198; 
 Wed, 05 Jan 2022 14:45:06 -0800 (PST)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 5 Jan 2022 14:44:54 -0800
X-Gmail-Original-Message-ID: <CAD5xwhg-uxvJ4BCEeo5h2BxvCo87xwZ6r7cT-=u5PT9yskpbJQ@mail.gmail.com>
Message-ID: <CAD5xwhg-uxvJ4BCEeo5h2BxvCo87xwZ6r7cT-=u5PT9yskpbJQ@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000544af505d4dd81fd"
Subject: [bitcoin-dev] Why CTV,
 why now? Was RE: Stumbling into a contentious soft fork activation
 attempt
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jan 2022 22:45:12 -0000

--000000000000544af505d4dd81fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Devs,

There's a lot of noise in the other thread and it's hard to parse out what
merits a response or not without getting into a messy quagmire, so I
figured a separate email with high level points was the best way to respond=
.

Covenants are an important part of Bitcoin's future, not for "adding use
cases" but for making the fundamental pillars underlying Bitcoin more
robust. For example, covenants play a central role in privacy, scalability,
self custody, and decentralization (as I attempted to show in
https://rubin.io/advent21).

Bitcoin researchers have known about covenants conceptually for a long
time, but the implications and problems with them led to them being viewed
with heavy skepticism and concern for many years.

CTV was an output of my personal "research program" on how to make simple
covenant types without undue validation burdens. It is designed to be the
simplest and least risky covenant specification you can do that still
delivers sufficient flexibility and power to build many useful applications=
.

CTV has been under development for multiple years and the spec has been
essentially unmodified for 2 years (since the BIP was assigned a number).

CTV's specification is highly design specific to being a pre-committed
transaction. It'd be difficult to engineer an alternative for what it does
in a substantially different way.

CTV composes with potential future upgrades, such as OP_AMOUNT, CAT, CSFS,
TLUV. (See https://rubin.io/blog/2021/07/02/covenants/ and
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/0194=
23.html
)

CTV is non-rival (that means "both can happen") with any other upgrade
(e.g. APO, TLUV).

During the last 2 years, CTV has been reviewed by a wide range of folks and
there have not been (any?) conceptual or concrete NACKs for CTV to have or
introduce any risk or vulnerability to Bitcoin.

The main complaints about CTV are that we might come up with something
better eventually, a better system of things, or that CTV is not flexible
or general enough to make interesting applications, and it would be
unfortunate to go through with using up the 32 byte argument version of an
OP_NOP and the pains of any soft fork for something that we may eventually
know how to do better, replacing CTV.

More general approaches (e.g., based on CAT+CSFS) while more capability
powerful, have limitations given large script sizes and difficulty in
manipulating transactions and their outputs (e.g., Taproot outs requires
some OP_TWEAK as well), and are harder to reason about given higher degrees
of malleability.

During the last 2 years, while some other interesting concepts have arisen
(such as IIDs or TLUV), nothing in particular has fully overlapped CTV's
functionality, the closest being APO and they would both be valuable tools
to have independently.

During the last 2 years, no other proposal has reached the level of
"technical maturity" as CTV in terms of spec, implementation, testing,
tooling (rust miniscript integration, Sapio, python-vaults), and the
variety of applications demonstrated possible. As the saying goes, one in
the hand is worth two in the bush.

Many current users (not just end users, but businesses and protocol
developers as well) see CTV as delivering useful functionality for existing
applications despite its limitations (and some of those limitations emerge
as strengths). In particular, CTV is helpful for Lightning Network
companies to deliver non-custodial channels to more users and generally
improving wallet vault custody software.

Applications that are improved/enabled by CTV and not used today, like
Payment Pools, deliver strong privacy benefits. Privacy is something that
the longer we exist in a worse state, the harder it becomes to improve.
This is unlike e.g. scalability or self custody where improvements can be
made independent of previous activity. On the other hand, information leaks
from records of transactions are forever. There is more benefit from
reducing privacy leaks sooner than later. In other words, privacy is a path
dependent property not immediately upgradable to whatever current
technology provides.

Software Development is also path dependent. Many have remarked that there
is not great alternative research on other covenant proposals, but not many
application builders or protocol researchers are investing deep time and
expertise on producing alternative paths to covenants either. Accepting an
upgrade for limited covenants, like CTV, will give rise to many application
builders including covenants in their stack (e.g. for batching or vaults or
other applications) and will encourage more developers to contribute to
generic tooling (Sapio can be improved!) and also to -- via market
processes -- determine what other types of covenant would be safe and high
value for those already using CTV.

In my advocacy, I published the essay "Roadmap or Load o' Crap" (
https://rubin.io/bitcoin/2021/12/24/advent-27/), which presents a
hypothetical path for 'completing' BIP-119 this year and analyzes some
possible future work as well as the timeline viability of some alternatives
based on my best understandings. In this essay, I say very plainly:

*More =E2=80=9Cregular contributors=E2=80=9D would need to spend time revie=
wing the code
> and BIP to assure themselves of correctness and safety. Nothing can move
> forward without, no matter the count of casual contributors. Many regular
> contributors don=E2=80=99t want to =E2=80=98get political=E2=80=99 and lo=
ok at forks. Fortunately,
> while all consensus changes are complex, CTV is a very tiny and easy to
> review change in comparison with SegWit or Taproot (more similar to
> CheckLockTimeVerify =E2=80=93 a couple hundred lines of consensus code, a=
 couple
> hundred lines of non consensus code, and a couple thousand lines of tests=
,
> no cryptographic primitives). NOTE: This is a big if! Every contributor h=
as
> the right to review, and ACK or provide a reasoned NACK. Even if everyone
> else is excited about something doesn=E2=80=99t mean there isn=E2=80=99t =
space for new
> thought-through dissent. At the end of the article, I discuss some concre=
te
> next steps to ensure more developer review occurs.*


Nowhere have I called for an imminent contentious soft fork attempt. All I
am doing is agitating for other developers to perform reviews. I recognize
that developers have limited time and individual priorities that may lead
them to prefer to spend time on improving Bitcoin in other ways, and I
would not call the soft fork process to bear for an upgrade that I did not
believe would yield large cross cutting benefits across a multitude of
interest areas. I've also plainly described that while "*there could be a
UASF for it, since there is strong user demand for CTV, ... I wouldn=E2=80=
=99t
personally lead the charge on that**...*". In no way am I endeavoring to
cause the community to take sides.

Lastly, and finally, I would like to close this email with a quote from my
Twitter from April '21
https://twitter.com/JeremyRubin/status/1384689155465089025

worth clarifying: I don't give a single fuck if BIP-119 CTV specifically is
> activated or not.



I want the functionality, in whatever form (eg noinput), to fix critical
> gaps in #Bitcoin's armor:



Decentralization.
> Scaling.
> Self Custody.
> Privacy.



let's. fucking. go.


This isn't an ego driven journey about getting in a feature I worked hard
on.

I couldn't care less.

This is about finding a pragmatic and low risk path to reinforcing
Bitcoin's fundamentals for the coming year.

This is about not resting on our laurels while we see properties critical
to Bitcoin erode.

Agree or disagree with CTV as the right next step, but we are all united in
wanting Bitcoin to be the best that it can be.

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

--000000000000544af505d4dd81fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Hi Devs,</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">There&#39=
;s a lot of noise in the other thread and it&#39;s hard to parse out what m=
erits a response or not without getting into a messy quagmire, so I figured=
 a separate email with high level points was the best way to respond.</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
>Covenants are an important part of Bitcoin&#39;s future, not for &quot;add=
ing use cases&quot; but for making the fundamental pillars underlying Bitco=
in more robust. For example, covenants play a central role in privacy, scal=
ability, self custody, and decentralization (as I attempted to show in <a h=
ref=3D"https://rubin.io/advent21" target=3D"_blank">https://rubin.io/advent=
21</a>).</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000">Bitcoin researchers have known about covenants conceptually =
for a long time, but the implications and problems with them led to them be=
ing viewed with heavy skepticism and concern for many years.</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">CTV was =
an output of my personal &quot;research program&quot; on how to make simple=
 covenant types without undue validation burdens. It is designed to be the =
simplest and least risky covenant specification you can do that still deliv=
ers sufficient flexibility and power to build many useful applications.</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0">CTV has been under development for multiple years and the spec has been =
essentially unmodified for 2 years (since the BIP was assigned a number).</=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000=
000">CTV&#39;s specification is highly design specific to being a pre-commi=
tted transaction. It&#39;d be difficult to engineer an alternative for what=
 it does in a substantially different way.</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">CTV composes with potentia=
l future upgrades, such as OP_AMOUNT, CAT, CSFS, TLUV. (See=C2=A0<a href=3D=
"https://rubin.io/blog/2021/07/02/covenants/">https://rubin.io/blog/2021/07=
/02/covenants/</a> and=C2=A0<a href=3D"https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2021-September/019423.html">https://lists.linuxfoundati=
on.org/pipermail/bitcoin-dev/2021-September/019423.html</a>)</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">CTV is n=
on-rival (that means &quot;both can happen&quot;) with any other upgrade (e=
.g. APO, TLUV).</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><div class=3D"gmail_default">During the last 2 years=
, CTV=C2=A0has been reviewed by a wide range of folks and there have not be=
en (any?) conceptual or concrete NACKs for CTV to have or introduce any ris=
k or vulnerability to Bitcoin.</div><div class=3D"gmail_default"><br></div>=
<div class=3D"gmail_default">The main complaints about CTV are that we migh=
t come up with something better eventually, a better system of things, or t=
hat CTV is not flexible or general enough to make interesting applications,=
 and it would be unfortunate to go through with using up the 32 byte argume=
nt version of an OP_NOP and the pains of any soft fork for something that w=
e may eventually know how to do better, replacing CTV.=C2=A0</div><div clas=
s=3D"gmail_default"><br></div><div class=3D"gmail_default">More general app=
roaches (e.g., based on CAT+CSFS) while more capability powerful, have limi=
tations given large script sizes and difficulty in manipulating transaction=
s and their outputs (e.g., Taproot outs requires some OP_TWEAK as well), an=
d are harder to reason about given higher degrees of malleability.</div><di=
v class=3D"gmail_default"><br></div><div class=3D"gmail_default">During the=
 last 2 years, while some other interesting concepts have arisen (such as I=
IDs or TLUV), nothing in particular has fully overlapped CTV&#39;s function=
ality, the closest being APO and they would both be valuable tools to have =
independently.</div><div class=3D"gmail_default"><br></div><div class=3D"gm=
ail_default">During the last 2 years, no other proposal has reached the lev=
el of &quot;technical maturity&quot; as CTV in terms of spec, implementatio=
n, testing, tooling (rust miniscript integration, Sapio, python-vaults), an=
d the variety of applications demonstrated possible. As the saying goes, on=
e in the hand is worth two in the bush.</div><br></div><div class=3D"gmail_=
default"><div class=3D"gmail_default" style=3D"color:rgb(0,0,0);font-family=
:arial,helvetica,sans-serif;font-size:small">Many current users (not just e=
nd users, but businesses and protocol developers as well) see CTV as delive=
ring useful functionality for existing applications despite its limitations=
 (and some of those limitations emerge as strengths). In particular, CTV is=
 helpful for Lightning Network companies to deliver non-custodial channels =
to more users and generally improving wallet vault custody software.</div><=
div class=3D"gmail_default" style=3D"color:rgb(0,0,0);font-family:arial,hel=
vetica,sans-serif;font-size:small"><br></div><div class=3D"gmail_default" s=
tyle=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:s=
mall">Applications that are improved/enabled by CTV and not used today, lik=
e Payment Pools, deliver strong privacy benefits. Privacy is something that=
 the longer we exist in a worse state, the harder it becomes to improve. Th=
is is unlike e.g. scalability or self custody where improvements can be mad=
e independent of previous activity. On the other hand, information leaks fr=
om records of transactions are forever. There is more=C2=A0benefit from red=
ucing privacy leaks sooner than later. In other words, privacy is a path de=
pendent property not immediately upgradable to whatever current technology =
provides.</div><div class=3D"gmail_default" style=3D"color:rgb(0,0,0);font-=
family:arial,helvetica,sans-serif;font-size:small"><br></div><div class=3D"=
gmail_default" style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-s=
erif;font-size:small">Software Development is also path dependent. Many hav=
e remarked that there is not great alternative research on other covenant p=
roposals, but not many application builders or protocol researchers are inv=
esting deep time and expertise on producing alternative paths to covenants =
either. Accepting an upgrade for limited covenants, like CTV, will give ris=
e to many application builders including covenants in their stack (e.g. for=
 batching or vaults or other applications) and will encourage more develope=
rs to contribute to generic tooling (Sapio can be improved!) and also to --=
 via market processes -- determine what other types of covenant would be sa=
fe and high value for those already using CTV.</div><div class=3D"gmail_def=
ault" style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font=
-size:small"><br></div><div class=3D"gmail_default" style=3D"color:rgb(0,0,=
0);font-family:arial,helvetica,sans-serif;font-size:small">In my advocacy, =
I published the essay &quot;Roadmap or Load o&#39; Crap&quot; (<a href=3D"h=
ttps://rubin.io/bitcoin/2021/12/24/advent-27/" target=3D"_blank">https://ru=
bin.io/bitcoin/2021/12/24/advent-27/</a>), which presents a hypothetical pa=
th for &#39;completing&#39; BIP-119 this year and analyzes some possible fu=
ture work as well as the timeline viability of some alternatives based on m=
y best understandings. In this essay, I say very plainly:</div><div class=
=3D"gmail_default" style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sa=
ns-serif;font-size:small"><br></div></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;border-left-color:rgb(204,204,204);padding-left:1ex"><i>More =E2=80=
=9Cregular contributors=E2=80=9D would need to spend time reviewing the cod=
e and BIP to assure themselves of correctness and safety. Nothing can move =
forward without, no matter the count of casual contributors. Many regular c=
ontributors don=E2=80=99t want to =E2=80=98get political=E2=80=99 and look =
at forks. Fortunately, while all consensus changes are complex, CTV is a ve=
ry tiny and easy to review change in comparison with SegWit or Taproot (mor=
e similar to CheckLockTimeVerify =E2=80=93 a couple hundred lines of consen=
sus code, a couple hundred lines of non consensus code, and a couple thousa=
nd lines of tests, no cryptographic primitives). NOTE: This is a big if! Ev=
ery contributor has the right to review, and ACK or provide a reasoned NACK=
. Even if everyone else is excited about something doesn=E2=80=99t mean the=
re isn=E2=80=99t space for new thought-through dissent. At the end of the a=
rticle, I discuss some concrete next steps to ensure more developer review =
occurs.</i></blockquote><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">Nowhere have I called for an imminent contentious =
soft fork attempt. All I am doing is agitating for other developers to perf=
orm reviews. I recognize that developers have limited time and individual p=
riorities that may lead them to prefer to spend time on improving Bitcoin i=
n other ways,=C2=A0and I would not call the=C2=A0soft fork process to bear =
for an upgrade that I did not believe would yield large cross cutting benef=
its across a multitude of interest areas. I&#39;ve also plainly described t=
hat while &quot;<i>t<span style=3D"font-family:Arial,Helvetica,sans-serif;c=
olor:rgb(34,34,34)">here could be a </span>UASF<span style=3D"font-family:A=
rial,Helvetica,sans-serif;color:rgb(34,34,34)"> for it, since there is stro=
ng user demand for CTV, </span><span class=3D"gmail_default">...</span><spa=
n style=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">=C2=
=A0I wouldn=E2=80=99t personally lead the charge on that</span></i><span cl=
ass=3D"gmail_default"><i>...</i>&quot;. In no way am I endeavoring to cause=
 the community to take sides.</span></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
<span class=3D"gmail_default"><br></span></div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000=
000">Lastly, and finally, I would like to close this email with a quote fro=
m my Twitter from April &#39;21=C2=A0<a href=3D"https://twitter.com/JeremyR=
ubin/status/1384689155465089025">https://twitter.com/JeremyRubin/status/138=
4689155465089025</a></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding=
-left:1ex"><span class=3D"gmail-css-901oao gmail-css-16my406 gmail-r-poiln3=
 gmail-r-bcqeeo gmail-r-qvutc0" style=3D"border:0px solid black;box-sizing:=
border-box;display:inline;font-stretch:inherit;line-height:inherit;margin:0=
px;padding:0px;word-wrap:break-word;min-width:0px">worth clarifying: I don&=
#39;t give a single fuck if BIP-119 CTV specifically is activated or not.</=
span></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex">=C2=A0</blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><spa=
n class=3D"gmail-css-901oao gmail-css-16my406 gmail-r-poiln3 gmail-r-bcqeeo=
 gmail-r-qvutc0" style=3D"border:0px solid black;box-sizing:border-box;disp=
lay:inline;font-stretch:inherit;line-height:inherit;margin:0px;padding:0px;=
word-wrap:break-word;min-width:0px">I want the functionality, in whatever f=
orm (eg noinput), to fix critical gaps in #Bitcoin&#39;s armor:</span></blo=
ckquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,20=
4,204);padding-left:1ex">=C2=A0</blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class=3D=
"gmail-css-901oao gmail-css-16my406 gmail-r-poiln3 gmail-r-bcqeeo gmail-r-q=
vutc0" style=3D"border:0px solid black;box-sizing:border-box;display:inline=
;font-stretch:inherit;line-height:inherit;margin:0px;padding:0px;word-wrap:=
break-word;min-width:0px">Decentralization.<br></span><span class=3D"gmail-=
css-901oao gmail-css-16my406 gmail-r-poiln3 gmail-r-bcqeeo gmail-r-qvutc0" =
style=3D"border:0px solid black;box-sizing:border-box;display:inline;font-s=
tretch:inherit;line-height:inherit;margin:0px;padding:0px;word-wrap:break-w=
ord;min-width:0px">Scaling.<br></span><span class=3D"gmail-css-901oao gmail=
-css-16my406 gmail-r-poiln3 gmail-r-bcqeeo gmail-r-qvutc0" style=3D"border:=
0px solid black;box-sizing:border-box;display:inline;font-stretch:inherit;l=
ine-height:inherit;margin:0px;padding:0px;word-wrap:break-word;min-width:0p=
x">Self Custody.<br></span>Privacy.</blockquote><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=C2=A0</bl=
ockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex">let&#39;s. fucking. go.</blockquote><div><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">This isn&#39;t an ego driven journey =
about getting in a feature I worked hard on.</div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I couldn&#39;t car=
e less.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)">This is about finding a pragmatic and low risk path to =
reinforcing Bitcoin&#39;s fundamentals for the coming year.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Thi=
s is about not resting on our laurels while we see properties critical to B=
itcoin erode.</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">Agree or disagree with CTV as the right next step=
, but we are all united in wanting Bitcoin to be the best that it can be.</=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">Best,</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)">Jeremy</div><br clear=3D"all"><div><div dir=3D=
"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank=
">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_bl=
ank"></a></div></div></div></div>

--000000000000544af505d4dd81fd--