MIME-Version: 1.0
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Tue, 8 Mar 2022 09:09:58 -0800
Message-ID: <CAD5xwhgYyR0dK_Fm0ikHi+JSoJcsczrfxrO6p5oa1cRVD_DTaw@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a3b90105d9b80d87"
Subject: [bitcoin-dev] OP_AMOUNT Discussion
Precedence: list

--000000000000a3b90105d9b80d87
Content-Type: text/plain; charset="UTF-8"

Hi Devs,

Recently, I've been getting a lot of questions about OP_AMOUNT. It's also
come up in the context of "CTV is unsafe because it can't handle differing
amounts". Just sharing some preliminary thinking on it:

It could come in many variants:

OP_PUSHAMOUNT
OP_AMOUNTVERIFY
OP_PUSHAMOUNTSPLIT
OP_SPLITAMOUNTVERIFY

If we want to do a NOP upgrade, we may prefer the *VERIFY formats. If we
want to do a SUCCESSX upgrade, we could do the PUSH format.

The SplitAmount format is required because amounts are > 5 bytes (51 bits
needed max), unless we also do some sort of OP_UPGRADEMATH semantic whereby
presence of an Amount opcode enables 64 bit (or 256 bit?) math opcodes.

And could be applied to the cross product of:

The Transaction
An Input
An Output
The fees total
The fees this input - this output
This Input
"This" Output

A lot of choices! The simplest version of it just being just this input,
and no other (all that is required for many useful cases, e.g. single sig
if less than 1 btc).


A while back I designed some logic for a split amount verifying opcode
here: (I don't love it, so hadn't shared it widely).
https://gist.github.com/JeremyRubin/d9f146475f53673cd03c26ab46492504

There are some decent use cases for amount checking.

For instance, one could create a non-recursive covenant that there must be
an output which exactly matches the sats in the input at the same index.
This could be used for colored coins, statechains, TLUV/EVICT based payment
pools, etc.

Another use case could be to make a static address / descriptor that
disables low security spends if more coins are the input.

Yet another could be to enable pay-what-you-want options, where depending
on how much gets paid into an address different behaviors are permitted.

Lastly, as noted in BIP-119, you can make a belt-and-suspenders value check
in CTV contracts to enable a backup withdrawal should you send the wrong
amount to a vault.

Overall, I think the most straightforward path would be to work on this
only for tapscript, no legacy, and then spec out upgraded math operations,
and then OP_PUSHAMOUNT is pretty straightforward & low technical risk.
Unfortunately, the upgraded math and exact semantics are highly
bikesheddable... If anyone is interested in working on this, I'd be happy
to review/advise on it. Otherwise, I would likely start working on this
sometime after I'm spending less effort on CTV.

Blockstream liquid has some work in this regard that may be copyable for
the math part, but likely not the amount opcode:
https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
 However, they chose to do only 64 bit arithmetic and I personally think
that the community might prefer wider operations, the difficulty being in
not incidentally enabling OP_CAT as a size, bitshift, and add fragment (or
proving that OP_CAT is OK?).

see also: https://rubin.io/bitcoin/2021/12/05/advent-8/#OP_AMOUNT

Cheers,

Jeremy

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

--000000000000a3b90105d9b80d87
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">Recently,=
 I&#39;ve been getting a lot of questions about OP_AMOUNT. It&#39;s also co=
me up in the context of &quot;CTV is unsafe because it can&#39;t handle dif=
fering amounts&quot;. Just sharing some preliminary thinking on it:</div><d=
iv 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:#000000">I=
t could come in many variants:</div><div class=3D"gmail_default" style=3D"f=
ont-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:#000000">OP_PUSHAMOUNT</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">OP_AMOUNTVERIFY</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">OP_PUSH=
AMOUNTSPLIT</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">OP_SPLITAMOUNTVERIFY</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
"><div class=3D"gmail_default">If we want to do a NOP upgrade, we may prefe=
r the *VERIFY formats. If we want to do a SUCCESSX upgrade, we could do the=
 PUSH format.</div></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000"><div class=3D"gmail_default">The SplitAmount form=
at is required because amounts are &gt; 5 bytes (51 bits needed max), unles=
s we also do some sort of OP_UPGRADEMATH semantic whereby presence of an Am=
ount opcode enables 64 bit (or 256 bit?) math opcodes.</div><br class=3D"gm=
ail-Apple-interchange-newline"></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">And c=
ould be applied to the cross product of:</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">The Transaction</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000">An Input</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">A=
n Output</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">The fees total</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">The fees this input - this output</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">This Input</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">&=
quot;This&quot; Output</div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:#000000">A lot of choices! The simplest version of it j=
ust being just this input, and no other (all that is required for many usef=
ul cases, e.g. single sig if less than 1 btc).</div><div class=3D"gmail_def=
ault" 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:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">A while back I designed some logic for a split amoun=
t verifying opcode here: (I don&#39;t love it, so hadn&#39;t shared it wide=
ly). <a href=3D"https://gist.github.com/JeremyRubin/d9f146475f53673cd03c26a=
b46492504">https://gist.github.com/JeremyRubin/d9f146475f53673cd03c26ab4649=
2504</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">There are some decent use cases for amount checking.</div><d=
iv 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:#000000">F=
or instance, one could create a non-recursive covenant that there must be a=
n output which exactly matches the sats in the input at the same index. Thi=
s could be used for colored coins, statechains, TLUV/EVICT based payment po=
ols, etc.</div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:#000000">Another use case could be to make a static address / descri=
ptor that disables low security spends if more coins are the input.</div><d=
iv 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:#000000">Y=
et another could be to enable pay-what-you-want options, where depending on=
 how much gets paid into an address different behaviors are permitted.</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
">Lastly, as noted in BIP-119, you can make a belt-and-suspenders value che=
ck in CTV contracts to enable a backup withdrawal should you send the wrong=
 amount to a vault.</div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000">Overall, I think the most straightforward path wo=
uld be to work on this only for tapscript, no legacy, and then spec out upg=
raded math operations, and then OP_PUSHAMOUNT is pretty straightforward &am=
p; low technical risk. Unfortunately, the upgraded math and exact semantics=
 are highly bikesheddable... If anyone is interested in working on this, I&=
#39;d be happy to review/advise on it. Otherwise, I would likely start work=
ing on this sometime after I&#39;m spending less effort on CTV.</div><div c=
lass=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:#000000">Block=
stream liquid has some work in this regard that may be copyable for the mat=
h part, but likely not the amount opcode: <a href=3D"https://github.com/Ele=
mentsProject/elements/blob/master/doc/tapscript_opcodes.md">https://github.=
com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md</a> =C2=
=A0However, they chose to do only 64 bit arithmetic and I personally think =
that the community might prefer wider operations, the difficulty being in n=
ot incidentally enabling OP_CAT as a size, bitshift, and add fragment (or p=
roving that OP_CAT is OK?).</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-ser=
if;font-size:small;color:#000000">see also:=C2=A0<a href=3D"https://rubin.i=
o/bitcoin/2021/12/05/advent-8/#OP_AMOUNT">https://rubin.io/bitcoin/2021/12/=
05/advent-8/#OP_AMOUNT</a></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">Cheers,</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">Jeremy</div><br clear=3D"all=
"><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_s=
ignature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin=
" target=3D"_blank">@JeremyRubin</a><br></div></div></div></div>

--000000000000a3b90105d9b80d87--