From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8D2CEC000B for ; Tue, 8 Mar 2022 17:10:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 7C62540438 for ; Tue, 8 Mar 2022 17:10:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MplYEjmGWmnt for ; Tue, 8 Mar 2022 17:10:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by smtp4.osuosl.org (Postfix) with ESMTPS id 1FBD540304 for ; Tue, 8 Mar 2022 17:10:12 +0000 (UTC) Received: by mail-lf1-x12a.google.com with SMTP id bu29so33518551lfb.0 for ; Tue, 08 Mar 2022 09:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=g1RzaOU1c/H4NV2MfnxCrRS9We8aCFk+qUeSYsPRp7o=; b=BJmto2nHDGo4RgRLGqCi0UZe/L4pgrgvaPvMvOTUBGqMu9kXHCjWbO4RmIC6qIj113 LC567+sh6PHeeu0z7T4JUuWEWFJoPgWqztE5JVkX1u9GaK/ZfhdSfyhm8X2E5+Pi9Y/N dnqzTd4LG9AQmBYGDqZ2DnYCxJ3Eu4DTwaKm9oNxKLHobyV4Vs9ozT3tz/sMWdrtm++a IhVas4kY9hSSc2BfODt2hatGuqrQc2iRWb6eHWbROwTe5/SgdNB3CTHIBt80gZyNDxJQ Riii+DptSHnhx74++GMv3Tc4/V6zLruS3fWF72MVZM6ZMjKHgjlCd9OxdXg73F+AIMZo r7sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=g1RzaOU1c/H4NV2MfnxCrRS9We8aCFk+qUeSYsPRp7o=; b=kU//5jVcuofwYV0yJLcPxESwcYloUGU9bpVUr1NSqQbI3ocgEpbYWQE8l0dr6gsaXX D+sb8tnme7uDGARkZ2jQeqqG8cdSUHB1pYMQU1yiwirf7vmJsdlkxzZWLwAK4lf6Vp2R r3oWQ8IjVmfYOHTs8gIuq9Rrg9u9gZP1HRKXnUxpamiOdrBAc/6X+tQDNpFzqfOqQzoH fXjCqIukRs4w06DhU2acCFaZQw4SrVBTi0RyvieXCUqSGmQuFgCd3G34T2oK6GVd/B1b ceoKt3arppKUelX/XLK4umZ7gfLaNfSy7f2xSWMf/OC1qV+Vprj7pcgH5yQcYtqhHxwh IwDw== X-Gm-Message-State: AOAM531N+lvzJ0iiX6o9SdfCmml3BP1MUi06aakbbF+no1qPG0T93gOW az33Rdvq0y6Y8BEofEfKx7pDOc2qCwW5xRpoJOg1tK1JOWA= X-Google-Smtp-Source: ABdhPJwahSNTTBHc2sJUoyjsIjz/yOlgxaT7jJy6Tm8irOMjViez/FatFJzRQcyEsku5ynDOgg+Du6YXKPctTN2hygo= X-Received: by 2002:a05:6512:1288:b0:443:f15d:6a2e with SMTP id u8-20020a056512128800b00443f15d6a2emr11433010lfs.363.1646759409595; Tue, 08 Mar 2022 09:10:09 -0800 (PST) MIME-Version: 1.0 From: Jeremy Rubin Date: Tue, 8 Mar 2022 09:09:58 -0800 Message-ID: To: Bitcoin development mailing list Content-Type: multipart/alternative; boundary="000000000000a3b90105d9b80d87" Subject: [bitcoin-dev] OP_AMOUNT Discussion X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2022 17:10:13 -0000 --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 --000000000000a3b90105d9b80d87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Devs,

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

I= t could come in many variants:

OP_PUSHAMOUNT
OP_AMOUNTVERIFY
OP_PUSH= AMOUNTSPLIT
OP_SPLITAMOUNTVERIFY

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.

The SplitAmount form= at is required because amounts are > 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.

And c= ould be applied to the cross product of:

The Transaction
An Input
A= n Output
The fees total
The fees this input - this output
This Input
&= quot;This" Output

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).


A while back I designed some logic for a split amoun= t verifying opcode here: (I don't love it, so hadn't shared it wide= ly). https://gist.github.com/JeremyRubin/d9f146475f53673cd03c26ab4649= 2504

There are some decent use cases for amount checking.

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.

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

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.

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.

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'm spending less effort on CTV.

Block= stream liquid has some work in this regard that may be copyable for the mat= h part, but likely not the amount opcode: https://github.= com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md =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?).

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

=
Cheers,

Jeremy

--000000000000a3b90105d9b80d87--