From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id CECD6C000B for ; Thu, 10 Jun 2021 17:35:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id B6D4C40118 for ; Thu, 10 Jun 2021 17:35:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 as-IUh6jHoCq for ; Thu, 10 Jun 2021 17:35:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by smtp2.osuosl.org (Postfix) with ESMTPS id 840F2400F3 for ; Thu, 10 Jun 2021 17:35:45 +0000 (UTC) Received: by mail-ed1-x535.google.com with SMTP id ba2so32254878edb.2 for ; Thu, 10 Jun 2021 10:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nEXNlsWTGF89S+UaEevRty4WEPR/igkcEjgwFNgFYY8=; b=f8gOvrj56QXmYzzDpVjog8WIaa1QCjrVTT5ytaFdk98SBfypzTzTQRETdG5taVORoS altQ21l4Tt5sLTeXL+wldGsRrrF3P+4Qn3pW3dRCNHxImTzGuvqFMajVYyh2M7NkH6Q4 fgaIhaVGlqH0R3a4SdiJMfsQXrvo0zl6Lv3kwYUO4t4aZ08417lxlQcav/Z/qee+4zXL CCvO14XGtIr9vd+CU0Wgmp9E7LAui+ssbdnITdVsPSACttsVe/wwhy4uCAF5BS2RipbK ymXoieQqE7SCdoRMR9UohWTHPdTnz8Ik5KtPY5DsEe4W0O49u1xw7dhQE8pDeKMe2dtE dAUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nEXNlsWTGF89S+UaEevRty4WEPR/igkcEjgwFNgFYY8=; b=kvTTOQdAEH06BQyruZzb1onLj+ykxr8v2hs/EYKDc7doDqQyo1GfoMIxsmvBbRHlZu 3HwZye6Z9VPNAA+3DMlVaVY5O9OWSMptTQrg0P/5HViB/eTFvLkKg336L6Eq8RTXg0Is Gvh+pd4JfZwO5uBgWIfZYsNdCnwDKKHJMZNY4QtygQ5mCzI8VqgxfT3xG6s3m/WDiRQ9 aIdM+ja84kGWIVDoH7rDt+nz4o2YhC6i55aZ/rrBcLaDUhsl9ZTu3I6NkF6rYDQgnu9m 0oUP+Zsp6JCSG0a4jPBzimxs+4yx4yJ6eUWnMrgWPGNW4OcoVIBzl2+1LiRAMt7P+Inp ONng== X-Gm-Message-State: AOAM531IJyMAVd95rEVt65EkYykmXOOK6Z4Bvmeh1Knxg5w1ieDnip/6 zizfTG3VmAHejUQknLhPNme/yJ38ZCyGv5u1+wwnHREMLMW0Yw== X-Google-Smtp-Source: ABdhPJz2TirjRotYk/Jk7TpzykhVDkYLHjq4Dm+mvdmd3eJ3+TzGf3bcKOwWTqXDAK93xYfxvEfbLqGnXsrcLi3Fx1k= X-Received: by 2002:aa7:d388:: with SMTP id x8mr599878edq.338.1623346543008; Thu, 10 Jun 2021 10:35:43 -0700 (PDT) MIME-Version: 1.0 From: Billy Tetrud Date: Thu, 10 Jun 2021 10:35:25 -0700 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000000b1fd205c46cd2c5" X-Mailman-Approved-At: Thu, 10 Jun 2021 17:56:42 +0000 Subject: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block 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: Thu, 10 Jun 2021 17:35:46 -0000 --0000000000000b1fd205c46cd2c5 Content-Type: text/plain; charset="UTF-8" Hi Everyone, I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY (OP_BBV) which is similar to ones that have been discussed before (eg OP_BLOCKNUMBER). The opcode is very simple: the it takes as a parameter a number representing a block height, and marks the transaction invalid if the current block the transaction is being evaluated for is greater than or equal to that block height, the transaction is invalid. I wrote up a bip for OP_BBV here . The motivation for this opcode is primarily to do switch-off kinds of transactions. Eg, an output that contains both a spend path that uses OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that before a particular block one person can spend, and after that block a different person can spend. This can allow doing things like expiring payments or reversible payments in a cheaper way. Currently, things like that require a sequence of multiple transactions, however OP_BBV can do it in a single transaction, making these applications a lot more economically feasible. The particular application I'm most interested in is more efficient wallet vaults. However, wallet vaults requires other new opcodes, and I've been given the (good, I think) advice to start off this discussion with something a bit more bite sized and manageable. So I want to keep this discussion to OP_BBV and steer away from the specifics of the wallet vaults I'm thinking of (which are more involved, requiring other new opcodes that I think makes more sense to discuss in a different thread). The main thing I'd like to discuss is the historical avoidance of and stigma toward opcodes that can cause a valid transaction to become invalid. It seems there are two concerns: 1. that an opcode like might create a DOS vector where a malicious actor might be able to spam the mempool with transactions containing this opcode. 2. that an opcode like this could cause "bad" reorg behavior, where in a reorg, transactions that were spent become not spend and not spendable because they were mined too near their expiry point. While I don't want to claim anything about opcodes that can cause spend paths to expire in general, I do want to claim that *some* opcodes like that are safe - in particular OP_BBV. In the context of OP_BBV specifically, it seems to me like item 1 (mempool handling) is a solvable problem and that point 2 (reorg issues) is not really a problem since people should generally be waiting for 6 confirmations and software can warn the user to wait for 6 confirmations in relevant scenarios where a 6-block reorg might reverse the transaction. I discuss this in detail in the Design Tradeoffs and Risks section of the document I wrote for OP_BBV. I'd love to hear thoughts from others on here about these things and especially the discussion of these issues in the document I linked to. Thanks, BT --0000000000000b1fd205c46cd2c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Everyone,

I'd like to open a dis= cussion of an opcode I call OP_BEFOREBLOCKVERIFY (OP_BBV) which is similar = to ones that have been discussed before (eg=C2=A0OP_BLOCKNUMBER). The opcode is very simple: the it takes= as a parameter a number representing a block height, and marks the transac= tion invalid if the current block the transaction is being evaluated=C2=A0f= or is greater than or equal to that block height, the transaction is invali= d. I wrote up a bip for OP_BBV here= .

The motivation for this opcode is primarily to d= o switch-off kinds of transactions. Eg, an output that contains both a spen= d path that uses OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY s= o that before a particular block one person can spend, and after that block= a different person can spend. This can allow doing things like expiring pa= yments or reversible payments in a cheaper way. Currently, things like that= require a sequence of multiple transactions, however OP_BBV can do it in a= single transaction, making these applications a lot more economically feas= ible.=C2=A0

The particular application I'm mos= t interested in is more efficient wallet vaults. However, wallet vaults req= uires other new opcodes, and I've been given the (good, I think) advice= to start off this discussion with something a bit more bite sized and mana= geable. So I want to keep this discussion to OP_BBV and steer away from the= specifics of the wallet vaults I'm thinking of (which are more involve= d, requiring other new opcodes that I think makes more sense to discuss in = a different thread).

The main thing I'd like t= o discuss is the historical avoidance of and stigma toward opcodes that can= cause a valid transaction to become invalid.

It = seems there are two concerns:

1. that an opcode li= ke might=C2=A0create a DOS vector where a malicious actor might be able to = spam the mempool with transactions containing this opcode.
2. tha= t an opcode like this could cause "bad" reorg behavior, where in = a reorg, transactions that were spent become not spend and not spendable be= cause they were mined too near their expiry point.=C2=A0

While I don't want to claim anything about opcodes that can caus= e spend paths to expire in general, I do want to claim that *some* opcodes = like that are safe - in particular OP_BBV. In the context of OP_BBV specifi= cally, it seems to me like item 1 (mempool handling) is a solvable problem = and that point 2 (reorg issues) is not really a problem since people should= generally be waiting for 6 confirmations and software can warn the user to= wait for 6 confirmations in relevant scenarios where a 6-block reorg might= reverse the transaction. I discuss this in detail in the=C2=A0Design Tradeoffs and Risks= =C2=A0section of the document I wrote for OP_BBV. I'd love to hear thou= ghts from others on here about these things and especially the discussion o= f these issues in the document I linked to.=C2=A0

= Thanks,
BT

--0000000000000b1fd205c46cd2c5--