path: root/58/767ce35208529bf2b58f8e79f9e96bf2674b9a

Return-Path: <jlrubin@mit.edu>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8C073C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Jul 2021 22:32:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 5AD2D400FA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Jul 2021 22:32:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Level: 
X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_SBL=1.623,
 URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id LCuVhoyV1ptd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Jul 2021 22:32:38 +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 smtp2.osuosl.org (Postfix) with ESMTPS id 606E2400EF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Jul 2021 22:32:38 +0000 (UTC)
Received: from mail-il1-f177.google.com (mail-il1-f177.google.com
 [209.85.166.177]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 162MWa63020920
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 2 Jul 2021 18:32:36 -0400
Received: by mail-il1-f177.google.com with SMTP id t12so11102400ile.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 02 Jul 2021 15:32:36 -0700 (PDT)
X-Gm-Message-State: AOAM53289MM7VepOnU5fSu7Oy9vADzighDuTkR5jP579k+W2L1wkTK2s
 evfs7427Bh4pvgojCDaEPHC6sfMcC2e6dq3g54w=
X-Google-Smtp-Source: ABdhPJwbKQFBgdCNbyALG/PIJ/B43ODuLiAB7TAnUG6ry9eZQuuiLwYuBJwtpy2dCe2Bx2IqLrcolMKa6PE3gOTyLqM=
X-Received: by 2002:a05:6e02:1203:: with SMTP id
 a3mr1407039ilq.164.1625265155723; 
 Fri, 02 Jul 2021 15:32:35 -0700 (PDT)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 2 Jul 2021 15:32:24 -0700
X-Gmail-Original-Message-ID: <CAD5xwhg7ksET7YjsJ4BnQW-pdmVSbuueEKzdJvTYH8KoHgQLZA@mail.gmail.com>
Message-ID: <CAD5xwhg7ksET7YjsJ4BnQW-pdmVSbuueEKzdJvTYH8KoHgQLZA@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000045d6f405c62b88bc"
X-Mailman-Approved-At: Sat, 03 Jul 2021 08:31:03 +0000
Subject: [bitcoin-dev] Templates, Eltoo, and Covenants, Oh My!
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: Fri, 02 Jul 2021 22:32:41 -0000

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

Dear Bitcoin Devs,

I recently put a blog post up which is of interest for this list. Post
available here: https://rubin.io/blog/2021/07/02/covenants/ (text
reproduced below for archives).

The main technical points of interest for this list are:

1) There's a similar protocol to Eltoo built with CSFS + CTV
2) There may be a similar protocol to Eltoo with exclusively CSFS

I'm curious if there's any sentiment around if a soft fork enabling CSFS is
controversial? Or if there are any thoughts on the design questions posed
below (e.g., splitting r and s value).

Best,

Jeremy

---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
------------------------------------------------------

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 no=
t
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](
https://github.com/bitcoin/bips/blob/d616d5492bc6e6566af1b9f9e43b660bcd48ca=
29/bip-0118.mediawiki).



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=E2=80=99t exist at the time the script was made. T=
his
would be
a new promise enforced by Bitcoin (ex. =E2=80=9CYou can close this Lightnin=
g channel
and receive these coins if you give me the right proof. If a newer proof
comes
in later I=E2=80=99ll trust that one instead.=E2=80=9D).


APO=E2=80=99s primary purpose is to enable off chain protocols like
[Eltoo](https://blockstream.com/2018/04/30/en-eltoo-next-lightning/), an
improved non-punitive payment channel protocol.


APO can also
[emulate](
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017038.ht=
ml
)
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](
https://github.com/ElementsProject/elements/blob/bd2e2d5c64d38286b2ca0519f1=
215bed228e4dcf/src/script/interpreter.cpp#L914-L933
)
and [Bitcoin
Cash](
https://github.com/bitcoincashorg/bitcoincash.org/blob/3e2e6da8c38dab7ba121=
49d327bc4b259aaad684/spec/may-2018-reenabled-opcodes.md
)
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 wit=
h
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 ([par=
t
1](https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html) an=
d
[part
ii](https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html))
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](
https://github.com/ElementsProject/elements/blob/bd2e2d5c64d38286b2ca0519f1=
215bed228e4dcf/src/script/interpreter.cpp#L1580-L1618
)
and in [Bitcoin
Cash](
https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_check=
datasig.md
),
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](
https://stanford2017.scalingbitcoin.org/files/Day1/SB2017_script_2_0.pdf)
(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](https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki).


CTV enables committing to a specific "next" transaction from script. This i=
s
the ability to make an unbreakable promise on chain which Bitcoin can
enforce
(e.g. =E2=80=9CThis coin can only be spent to my multisig, or my backup aft=
er a
timelock=E2=80=9D). This is a departure from normal script which is traditi=
onally
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](https://utxos.org/uses/). There=E2=80=99s also
[Sapio](https://learn.sapio-lang.org) 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 upgrad=
e
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 wha=
t
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 input=
s
   being spent, therefore CTV does not have much space for variation on
design.
   1. Should the digest be reordered or formatted differently? If there wer=
e
      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 fee=
s
    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](https://github.com/ElementsProject/elements/pull/817),
    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 ver=
y
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 tw=
o
instances of the same channel, state updates from one channel can be used o=
n
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 mor=
e
compactly (e.g., 2x16x32 byte hashes could be used to construct a signature
of
a post-hoc selected Sequence lock). [Read more
here](/blog/2021/07/02/signing-5-bytes/). 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 an=
d
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 reus=
e
safety and statefulness of information. See the above description in CTV fo=
r
why this is tangibly worse for APO than CTV. [See more discussion of APO's
safety & design trade offs
here](
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/00=
2176.html).



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 i=
t
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 neithe=
r
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. It's commonly claimed that APO is a perfect substitute for CTV. 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](
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016996.htm=
l
),
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 give=
s
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](https://github.com/pyskell), [Keagan
McClelland](https://twitter.com/ProofOfKeags), [Ryan
Gentry](https://twitter.com/RyanTheGentry), and [Olaoluwa
Osuntokun](https://twitter.com/roasbeef). Edit + Feedback &#8800;
Endorsement._

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

--00000000000045d6f405c62b88bc
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">Dear Bitcoin Devs,</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" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
I recently put a blog post up which is of interest for this list. Post avai=
lable here:=C2=A0<a href=3D"https://rubin.io/blog/2021/07/02/covenants/">ht=
tps://rubin.io/blog/2021/07/02/covenants/</a> (text reproduced below for ar=
chives).</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">The main technical points of interest for this list are:</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">1) There&#39;s a similar protocol to Eltoo built with CSFS=C2=A0+ CTV</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000">2) There may be a similar protocol to E=
ltoo with exclusively CSFS</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-seri=
f;font-size:small;color:#000000">I&#39;m curious if there&#39;s any sentime=
nt around if a soft fork enabling CSFS is controversial? Or if there are an=
y thoughts on the design questions posed below (e.g., splitting r and s val=
ue).</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_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000">Best,</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,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">Jeremy</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000">---------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------</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">If you&#39;ve been following The Discourse, you prob=
ably know that Taproot is<br>merged, locked in, and will activate later thi=
s November. What you might not<br>know is what&#39;s coming next... and you=
 wouldn&#39;t be alone in that. There are a<br>number of fantastic proposal=
s floating around to further improve Bitcoin, but<br>there&#39;s no clear p=
icture on what is ready to be added next and on what<br>timeline. No one --=
 core developer, technically enlightened individuals, power<br>users, or pl=
ebs -- can claim to know otherwise.<br><br><br>In this post I&#39;m going t=
o describe 4 loosely related possible upgrades to<br>Bitcoin -- SH_APO (BIP=
-118), OP_CAT, OP_CSFS, and OP_CTV (BIP-119). These four<br>upgrades all re=
late to how the next generation of stateful smart contracts can<br>be built=
 on top of bitcoin. As such, there&#39;s natural overlap -- and competition=
<br>-- for mindshare for review and deployment. This post is my attempt to =
stitch<br>together a path we might take to roll them out and why that order=
ing makes<br>sense. This post is for developers and engineers building in t=
he Bitcoin space,<br>but is intended to be followable by anyone technical o=
r not who has a keen<br>interest in Bitcoin.<br><br><br>## Bitcoin Eschews =
Roadmaps and Agendas.<br><br><br>I provide this maxim to make clear that th=
is document is by no means an<br>official roadmap, narrative, or prioritiza=
tion. However, it is my own<br>assessment of what the current most pragmati=
c approach to upgrading Bitcoin is,<br>based on my understanding of the sta=
te of outstanding proposals and their<br>interactions.<br><br><br>My priori=
ties in producing this are to open a discussion on potential new<br>feature=
s, risk minimization, and pragmatic design for Bitcoin.<br><br><br>### Upgr=
ade Summaries<br><br><br>Below follows summaries of what each upgrade would=
 enable and how it works. You<br>might be tempted to skip it if you&#39;re =
already familiar with the upgrades, but I<br>recommend reading in any case =
as there are a few non obvious insights.<br><br><br>#### APO: SIGHASH_ANYPR=
EVOUT, SIGHASH_ANYPREVOUTANYSCRIPT<br><br><br>Currently proposed as<br>[BIP=
-118](<a href=3D"https://github.com/bitcoin/bips/blob/d616d5492bc6e6566af1b=
9f9e43b660bcd48ca29/bip-0118.mediawiki">https://github.com/bitcoin/bips/blo=
b/d616d5492bc6e6566af1b9f9e43b660bcd48ca29/bip-0118.mediawiki</a>). <br><br=
><br>APO provides two new signature digest algorithms that do not commit to=
 the coin<br>being spent, or the current script additionally. Essentially a=
llowing scripts<br>to use outputs that didn=E2=80=99t exist at the time the=
 script was made. This would be<br>a new promise enforced by Bitcoin (ex. =
=E2=80=9CYou can close this Lightning channel<br>and receive these coins if=
 you give me the right proof. If a newer proof comes<br>in later I=E2=80=99=
ll trust that one instead.=E2=80=9D).<br><br><br>APO=E2=80=99s primary purp=
ose is to enable off chain protocols like<br>[Eltoo](<a href=3D"https://blo=
ckstream.com/2018/04/30/en-eltoo-next-lightning/">https://blockstream.com/2=
018/04/30/en-eltoo-next-lightning/</a>), an<br>improved non-punitive paymen=
t channel protocol. <br><br><br>APO can also<br>[emulate](<a href=3D"https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017038.html">ht=
tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017038.html=
</a>)<br>some of the main features of CTV and could be made to work with Sa=
pio,<br>partially. See the complimentary upgrades section for more detail.<=
br><br><br>#### CAT (+ variants)<br><br><br>Currently no BIP. However, CAT =
exists in<br>[Elements](<a href=3D"https://github.com/ElementsProject/eleme=
nts/blob/bd2e2d5c64d38286b2ca0519f1215bed228e4dcf/src/script/interpreter.cp=
p#L914-L933">https://github.com/ElementsProject/elements/blob/bd2e2d5c64d38=
286b2ca0519f1215bed228e4dcf/src/script/interpreter.cpp#L914-L933</a>)<br>an=
d [Bitcoin<br>Cash](<a href=3D"https://github.com/bitcoincashorg/bitcoincas=
h.org/blob/3e2e6da8c38dab7ba12149d327bc4b259aaad684/spec/may-2018-reenabled=
-opcodes.md">https://github.com/bitcoincashorg/bitcoincash.org/blob/3e2e6da=
8c38dab7ba12149d327bc4b259aaad684/spec/may-2018-reenabled-opcodes.md</a>)<b=
r>as a 520 byte limited form, so a proposal for Bitcoin can crib heavily fr=
om<br>either.<br><br><br>Cat enables appending data onto other pieces of da=
ta. Diabolically simple<br>functionality that has many advanced use cases b=
y itself and in concert with<br>other opcodes. There are many &quot;straigh=
tforward&quot; use cases of cat like requiring<br>sighash types, requiring =
specific R values, etc, but there are too many devious<br>use cases to list=
 here.=C2=A0 Andrew Poelstra has a decent blogpost series ([part<br>1](<a h=
ref=3D"https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html=
">https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html</a>)=
 and<br>[part<br>ii](<a href=3D"https://www.wpsoftware.net/andrew/blog/cat-=
and-schnorr-tricks-ii.html">https://www.wpsoftware.net/andrew/blog/cat-and-=
schnorr-tricks-ii.html</a>)) if<br>you&#39;re interested to read more. In p=
articular, with much cleverness, it seems<br>possible one could implement f=
ull covenants with just CAT, which covers<br>(inefficiently) most of the ot=
her techniques discussed in this post.<br><br><br>#### CSFS: CHECKSIGFROMST=
ACK<br><br><br>Currently no BIP. However, CSFS exists in<br>[Elements](<a h=
ref=3D"https://github.com/ElementsProject/elements/blob/bd2e2d5c64d38286b2c=
a0519f1215bed228e4dcf/src/script/interpreter.cpp#L1580-L1618">https://githu=
b.com/ElementsProject/elements/blob/bd2e2d5c64d38286b2ca0519f1215bed228e4dc=
f/src/script/interpreter.cpp#L1580-L1618</a>)<br>and in [Bitcoin<br>Cash](<=
a href=3D"https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spe=
c/op_checkdatasig.md">https://github.com/bitcoincashorg/bitcoincash.org/blo=
b/master/spec/op_checkdatasig.md</a>),<br>so a proposal for Bitcoin can cri=
b heavily from either.<br><br><br>CSFS enables checking of a signature agai=
nst a message and key from the stack<br>without including any transaction d=
ata.<br><br><br>Use cases include oracle protocols, key delegations, a [cha=
nnel update<br>invalidation<br>variant](<a href=3D"https://stanford2017.sca=
lingbitcoin.org/files/Day1/SB2017_script_2_0.pdf">https://stanford2017.scal=
ingbitcoin.org/files/Day1/SB2017_script_2_0.pdf</a>)<br>(Laolu claims this =
can be tweaked to be fully non punitive like eltoo, but<br>you&#39;ll need =
to bug him to write it up), and (+CAT) full covenants.<br><br><br><br><br>#=
### CTV: OP_CHECKTEMPLATEVERIFY<br><br><br>Currently proposed as<br>[BIP-11=
9](<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0119.mediawik=
i">https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki</a>).<br>=
<br><br>CTV enables committing to a specific &quot;next&quot; transaction f=
rom script. This is<br>the ability to make an unbreakable promise on chain =
which Bitcoin can enforce<br>(e.g. =E2=80=9CThis coin can only be spent to =
my multisig, or my backup after a<br>timelock=E2=80=9D). This is a departur=
e from normal script which is traditionally only<br>concerned with restrict=
ions on the sender, CTV imposes restrictions on the<br>recipient. More tech=
nically, CTV is essentially the ability to embed a<br>signature of a specif=
ic transaction inside of a script without needing any<br>elliptic curve ope=
rations. The validation costs are low. For more advanced<br>logic, you can =
nest multiple different CTV Hashes either using taproot or up to<br>the scr=
ipt length limits in regular script.<br><br><br>CTV can be used for vaults,=
 channels, and [many other<br>uses](<a href=3D"https://utxos.org/uses/">htt=
ps://utxos.org/uses/</a>). There=E2=80=99s also<br>[Sapio](<a href=3D"https=
://learn.sapio-lang.org">https://learn.sapio-lang.org</a>) which is a langu=
age and toolkit for<br>creating many kinds of programs with CTV.<br><br><br=
>CTV compliments CSFS to be able to emulate APO-like functionality<br>suffi=
cient to build Eltoo, potentially making APO feature-wise redundant.<br><br=
><br>## Comparative Analysis<br><br><br>Now that we&#39;ve got the basics c=
overed, let&#39;s explore these upgrades<br>comparatively across several di=
mensions.<br><br><br>### Design Specificity<br><br><br>&quot;Design Specifi=
city&quot; is a subjective measure of how substantially an upgrade<br>could=
 change from its current design while still meeting the features goals. It<=
br>is not to be confused with security or safety. Ranked in order from most=
 to<br>least design specific, with non-exhaustive lists of design questions=
 based on<br>ongoing community discourse as well as my own personal underst=
anding of what<br>might be desirable.<br><br><br>1. CSFS<br>2. CTV<br>3. CA=
T<br>4. APO<br><br><br>#### Explanations &amp; Open Questions:<br>1. CSFS i=
s very simple and there is essentially a single way to implement it. Three =
open questions are:<br>=C2=A0 =C2=A01. Should CSFS require some sort of tag=
ged hash? Very likely answer is no --<br>=C2=A0 =C2=A0 =C2=A0 tags interfer=
e with certain use cases)<br>=C2=A0 =C2=A02. Should CSFS split the signatur=
e&#39;s R &amp; S value stack items for some<br>=C2=A0 =C2=A0 =C2=A0 applic=
ations that otherwise may require OP_CAT? E.g. using a pinned R<br>=C2=A0 =
=C2=A0 value allows you to extract a private key if ever double signed, usi=
ng 2 R<br>=C2=A0 =C2=A0 values allows pay-to-reveal-key contracts. Most lik=
ely answer is no, if that is<br>=C2=A0 =C2=A0 desired then OP_CAT can be in=
troduced<br>=C2=A0 =C2=A03. Should CSFS support a cheap way to reference th=
e taproot internal or<br>=C2=A0 =C2=A0 =C2=A0 external key? Perhaps, can be=
 handled with undefined upgradeable<br>=C2=A0 =C2=A0 keytypes. One might wa=
nt to use the internal key, if the signed data should be<br>=C2=A0 =C2=A0 v=
alid independent of the tapscript tree.=C2=A0 One might want to use the ext=
ernal<br>=C2=A0 =C2=A0 key, if the data should only be valid for a single t=
apscript key + tree.<br>2. CTV is a commitment to all data that can malleat=
e TXID besides the inputs<br>=C2=A0 =C2=A0being spent, therefore CTV does n=
ot have much space for variation on design.<br>=C2=A0 =C2=A01. Should the d=
igest be reordered or formatted differently? If there were<br>=C2=A0 =C2=A0=
 =C2=A0 more data on what types of covenants might be built in the future, =
a<br>=C2=A0 =C2=A0 better order could be picked. Some thought has already g=
one into an order and<br>=C2=A0 =C2=A0 commitments that make covenants easi=
er, see the BIP for more. It&#39;s also<br>=C2=A0 =C2=A0 possible the seria=
lization format for the variable length fields (scriptsigs,<br>=C2=A0 =C2=
=A0 outputs) could be changed to make it easier to work with from script. (=
Maybe,<br>=C2=A0 =C2=A0 minor change)<br>=C2=A0 =C2=A02. Should CTV include=
 more template types? Possibly, CTV includes an upgrade<br>=C2=A0 =C2=A0 =
=C2=A0 mechanism baked in for new template types, so it is extensible for f=
uture<br>=C2=A0 =C2=A0 purposes. <br>=C2=A0 =C2=A03. Should CTV commit to t=
he amounts? CTV does not commit to the amount that<br>=C2=A0 =C2=A0 =C2=A0 =
a coin has. Input-inspecting functionality should be handled by separate<br=
>=C2=A0 =C2=A0 opcodes, as CTV would be overly restrictive otherwise. E.g. =
dynamic fees<br>=C2=A0 =C2=A0 through new inputs would be harder: given CTV=
&#39;s design it is not possible to<br>=C2=A0 =C2=A0 detect which field did=
 not match therefore it is not possible to script against<br>=C2=A0 =C2=A0 =
unexpected amount sent errors without some compromise (e.g. timeouts).<br>3=
. CAT is simplistic, and there are really few ways to implement it. However=
,<br>=C2=A0 =C2=A0because it requires some restrictions for security, there=
 are difficult to<br>=C2=A0 =C2=A0 answer open design questions:<br>=C2=A0 =
=C2=A01. What is the appropriate maximum stack size CAT should permit? Curr=
ently<br>=C2=A0 =C2=A0 =C2=A0 the design in Elements is 520 bytes, the max =
general stack size permitted<br>=C2=A0 =C2=A0 in script.<br>=C2=A0 =C2=A02.=
 Should CAT be introduced or<br>=C2=A0 =C2=A0 =C2=A0 [SHASTREAM](<a href=3D=
"https://github.com/ElementsProject/elements/pull/817">https://github.com/E=
lementsProject/elements/pull/817</a>),<br>=C2=A0 =C2=A0 SUBSTRING, or anoth=
er variant? There is a strong argument for SHASTREAM because<br>=C2=A0 =C2=
=A0 when constructing covenants (e.g. for use with CTV) based on TX data it=
&#39;s<br>=C2=A0 =C2=A0 possible for size of a data field (e.g., serializat=
ion of all outputs) to<br>=C2=A0 =C2=A0 exceed 520 bytes.<br>4. There are m=
any tough questions that the community has grappled with during<br>=C2=A0 =
=C2=A0APO&#39;s design and engineering process, generally asking how APO-li=
ke<br>=C2=A0 =C2=A0 techniques can be made &#39;Generally Safe&#39; given i=
it breaks current assumptions<br>=C2=A0 =C2=A0 around address reuse.<br>=C2=
=A0 =C2=A01. Should APO require chaperone signatures (in order to ensure th=
at replay<br>=C2=A0 =C2=A0 =C2=A0 is not done by 3rd parties)? Current Answ=
er: No, anyone is free to burn<br>=C2=A0 =C2=A0 their keys by revealing the=
m to similar effect.<br>=C2=A0 =C2=A02. Should APO use key tagging to mark =
keys that can use APO: Current Answer:<br>=C2=A0 =C2=A0 =C2=A0 yes, APO sho=
uld be &quot;double opt-in&quot; (both requiring a tag and a signer to<br>=
=C2=A0 =C2=A0 produce such a signature)<br>=C2=A0 =C2=A03. Should APO allow=
 signing with the external taproot key: Current Answer:<br>=C2=A0 =C2=A0 =
=C2=A0 no, because it makes APO not &quot;double opt-in&quot;.<br>=C2=A0 =
=C2=A04. Should APO optimize signing with the internal taproot key? Answer:=
<br>=C2=A0 =C2=A0 =C2=A0 default key 0x01 refers to taproot internal key, s=
o it can be made<br>=C2=A0 =C2=A0 cheaper if you&#39;re going to need it wi=
thout having to repeat the entire key. <br>=C2=A0 =C2=A05. Should APO commi=
t to the signing script? Answer: let&#39;s do two variants.<br>=C2=A0 =C2=
=A06. Should APO instead be a larger refactoring of sighash logic that<br>=
=C2=A0 =C2=A0 =C2=A0 encapsulates APO (e.g. sighash bitmasks)? Current Answ=
er: No, APO is good<br>=C2=A0 =C2=A0 enough to ship as is and doesn&#39;t p=
reclude future work.<br><br><br>### Safety<br><br><br>This category covers =
how &quot;safe&quot; each change is ranked from safest to least<br>safe. Wh=
at makes a change more or less safe is how limited and foreseeable the<br>u=
ses are of a specific opcode, in other words, how well we understand what i=
t<br>can do or where it might interact poorly with deployed infrastructure.=
<br><br>1. CTV<br>2. CSFS<br>3. APO<br>4. CAT<br><br><br>CTV is the safest =
new feature since fundamentally what it introduces is very<br>similar to wh=
at can be done with pre-signed transactions, so it is only a pivot<br>on tr=
ust and interactivity. Where there is some risk from CTV is that addresses<=
br>(or rather, invoices) that are reused might have the same program behind=
 them<br>which could cause unintended behavior. This differs from the reuse=
 problem in<br>APO because the problem is stateless, that is, if you verify=
 what is behind an<br>address you will know what exists and does not exist.=
 E.g., two payment channel<br>addresses will create distinct payment channe=
ls that updates cannot be replayed<br>across. In contrast with APO, paying =
one APO using address twice creates two<br>instances of the same channel, s=
tate updates from one channel can be used on<br>the other.<br><br><br>CSFS =
is the next safest, it is just a small piece of authenticated data. CSFS<br=
>and CTV are relatively close in terms of safety, but CSFS is slightly less=
 safe<br>given a remote possibility of surprising =C2=A0uses of it to perfo=
rm unforeseen<br>elliptic curve operations. This functionality already exis=
ts for up to 5-byte<br>messages. A hash preimage revelation can emulate a s=
igner compactly. Using<br>binary expansions and addition could be used to a=
llow signing of values more<br>compactly (e.g., 2x16x32 byte hashes could b=
e used to construct a signature of<br>a post-hoc selected Sequence lock). [=
Read more here](/blog/2021/07/02/signing-5-bytes/). Therefore it is appropr=
iate to think of<br>CSFS as an expansion of the efficiency of this techniqu=
e, reusability of keys,<br>and the types of data that can be signed over. A=
lthough CSFS is famously used<br>to build covenants by comparing a CSFS sig=
nature to a CHECKSIG signature and<br>getting transaction data onto the sta=
ck, CSFS cannot do that without CAT.<br><br><br>APO. This is the next safes=
t because APO has some questions around key reuse<br>safety and statefulnes=
s of information. See the above description in CTV for<br>why this is tangi=
bly worse for APO than CTV. [See more discussion of APO&#39;s<br>safety &am=
p; design trade offs<br>here](<a href=3D"https://lists.linuxfoundation.org/=
pipermail/lightning-dev/2019-September/002176.html">https://lists.linuxfoun=
dation.org/pipermail/lightning-dev/2019-September/002176.html</a>). <br><br=
><br>CAT is the least &#39;safe&#39; in terms of extant Bitcoin concepts as=
 it is highly<br>likely CAT introduces at least advanced covenants if added=
, especially in<br>conjunction with the above opcodes, but may also enable =
other unintended<br>functionality. CAT is a source of continual surprise wi=
th regards to what it<br>enables in composition with existing opcodes, ther=
efore a systematic review of<br>composability and known uses should be done=
 before considering it. That CAT was<br>forked out by Satoshi is of limited=
 relevance as the variant proposed for<br>reintroduction would not have the=
 vulnerability present initially.<br><br><br>### Complimentary Upgrades<br>=
<br><br>Pairings of upgrades can work together to deliver functionality tha=
t neither<br>could alone:<br><br><br>1. CAT + CSFS: full blown arbitrary co=
venants<br>=C2=A0 =C2=A01. With arbitrary covenants you can deploy many dif=
ferent kinds of smart<br>=C2=A0 =C2=A0 =C2=A0 contracts which are out of sc=
ope for this article.<br>2. CAT + CTV: Expanded covenants<br>=C2=A0 =C2=A01=
. slightly simpler to use interface but fewer features than CSFS + CAT whic=
h can<br>=C2=A0 =C2=A0 =C2=A0 covenant over witness data and inputs.<br>3. =
CTV + CSFS: Eltoo<br>=C2=A0 =C2=A0 1. This can add very similar functionali=
ty to eltoo with the script fragment:<br>=C2=A0 =C2=A0 `CTV &lt;musig(pka, =
pkb)&gt; CSFS &lt;S+1&gt; CLTV`<br>=C2=A0 =C2=A0 The protocol is essentiall=
y identical to the Eltoo paper, however there are<br>=C2=A0 =C2=A0 a couple=
 subtle differences required for dynamic fee rates.<br>4. CTV + APO: Slight=
ly Different<br>=C2=A0 =C2=A01. It&#39;s commonly claimed that APO is a per=
fect substitute for CTV. This is<br>=C2=A0 =C2=A0 =C2=A0 false. Their diges=
ts are slightly different, as such there are some niche<br>=C2=A0 =C2=A0 sm=
art contracts that could use the differences in commitment structure for<br=
>=C2=A0 =C2=A0 interesting effects (CTV commits to all scriptsigs and seque=
nces, APO cannot<br>=C2=A0 =C2=A0 cover that data but can cover a few varia=
nts of less data covered).<br><br><br>By all means not an exhaustive list -=
- feel free to message me with additions.<br><br><br>### Recommendation<br>=
<br><br>My recommendation is to deliver the upgrades described in this docu=
ment in the<br>following order:<br><br><br>1. CTV<br>2. CSFS<br>3. APO<br>4=
. CAT/SHASTREAM/SUBSTRING/etc<br><br><br>This recommendation comes as a syn=
thesis of the thoughts above on the<br>composability, safety, and open desi=
gn considerations of the various proposals<br>currently in flight. <br><br>=
<br>With CTV in place, we can begin experimenting with a wide variety of co=
ntracts<br>using the Sapio toolchain, as well as improve and invest in matu=
ring the<br>toolchain. Mature toolchains will make it easier to safely engi=
neer and deploy<br>applications making use of CTV and future upgrades.<br><=
br><br>CSFS is an independent change that can be deployed/developed in para=
llel to or<br>before CTV, the implementation from Elements could be easily =
ported to Bitcoin.<br>With CSFS and CTV, Eltoo-like constructions will be p=
ossible as well.<br><br><br>APO can then be deployed as an optimization to =
existing use patterns driven by<br>market adoption of CTV+CSFS based use. T=
his also gives us time to kick the can<br>down the road on the design quest=
ions that APO prompts around generalization of<br>signature digests and key=
 reuse safety.=C2=A0 A similar approach was [discussed on<br>the mailing<br=
>list](<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
019-May/016996.html">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2019-May/016996.html</a>),<br>but without the insight that CSFS + CTV was=
 sufficient for Eltoo like<br>constructions, requiring CAT instead. <br><br=
><br>Lastly, OP_CAT can be delivered as part of an effort towards generaliz=
ed<br>arbitrary covenants and perhaps in conjunction with some special purp=
ose<br>opcodes (such as OP_CHECKINPUT) that can more easily handle common c=
ases. CAT,<br>although it has safe implementations used in Elements, deserv=
es very strict<br>scrutiny given it&#39;s documented surprising uses.<br><b=
r><br>This approach represents a gradual relaxation of Bitcoin&#39;s restri=
ctions around<br>smart contract programming that introduces useful, safe pr=
imitives and gives<br>the community time to build and deploy useful infrast=
ructure. The path<br>described in this post is an opportunity to upgrade bi=
tcoin with simple<br>primitives that compose nicely for permissionless inno=
vation.<br><br><br>_Thanks to those who reviewed drafts of this post and pr=
ovided valuable<br>feedback improving the clarity and accuracy of this post=
, including<br>[pyskell](<a href=3D"https://github.com/pyskell">https://git=
hub.com/pyskell</a>), [Keagan<br>McClelland](<a href=3D"https://twitter.com=
/ProofOfKeags">https://twitter.com/ProofOfKeags</a>), [Ryan<br>Gentry](<a h=
ref=3D"https://twitter.com/RyanTheGentry">https://twitter.com/RyanTheGentry=
</a>), and [Olaoluwa<br>Osuntokun](<a href=3D"https://twitter.com/roasbeef"=
>https://twitter.com/roasbeef</a>). Edit + Feedback &amp;#8800; Endorsement=
._<br></div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_signatur=
e" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"htt=
ps://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"=
https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></div></=
div>

--00000000000045d6f405c62b88bc--