Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D30AD6246 for ; Sat, 1 Jun 2019 05:36:00 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53A82E7 for ; Sat, 1 Jun 2019 05:36:00 +0000 (UTC) Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x515ZvUf025910 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 1 Jun 2019 01:35:58 -0400 Received: by mail-ed1-f42.google.com with SMTP id h10so2465235edi.13 for ; Fri, 31 May 2019 22:35:58 -0700 (PDT) X-Gm-Message-State: APjAAAW5LWF6ralIId2zkAYE30ZB/POs27sRSfEEgIJ5PMG3caxRq0Iq X3RVW+P1ZaNMzho07Jh2upharPYg27D6GHoAnHY= X-Google-Smtp-Source: APXvYqzI89N/0bUIIwa0Zaw7lgPma10WyFgcyWH27GPqcqtcWaZQiKMOyFCR5uGvrHmHAWOT7ccKAsm/eI5T+5Da49k= X-Received: by 2002:a17:906:b741:: with SMTP id fx1mr12743530ejb.45.1559367357106; Fri, 31 May 2019 22:35:57 -0700 (PDT) MIME-Version: 1.0 From: Jeremy Date: Fri, 31 May 2019 22:35:45 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list Content-Type: multipart/alternative; boundary="000000000000651034058a3c810c" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 01 Jun 2019 16:46:30 +0000 Subject: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 05:36:01 -0000 --000000000000651034058a3c810c Content-Type: text/plain; charset="UTF-8" Hi All, OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. OP_SECURETHEBAG does more or less the same thing, but fixes malleability issues and lifts the single output restriction to a known number of inputs restriction. OP_CHECKOUTPUTSVERIFY had some issues with malleability of version and locktime. OP_SECURETHEBAG commits to both of these values. OP_SECURETHEBAG also lifts the restriction that OP_CHECKOUTPUTSVERIFY had to be spent as only a single input, and instead just commits to the number of inputs. This allows for more flexibility, but keeps it easy to get the same single output restriction. BIP: https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki Implementation: https://github.com/JeremyRubin/bitcoin/tree/secure_the_bag A particularly useful topic of discussion is how best to eliminate the PUSHDATA and treat OP_SECURETHEBAG like a pushdata directly. I thought about how the interpreter works and is implemented and couldn't come up with something noninvasive. Thank you for your review and discussion, Jeremy * Plus the name is better --000000000000651034058a3c810c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

OP_CHECKOUTPUTSHASHVERIFY is retracted in favor = of OP_SECURETHEBAG*. OP_SECURETHEBAG does more or less the same thing, but = fixes malleability issues and lifts the single output restriction to a know= n number of inputs restriction.

OP_CHECKOUTPUTSVERIFY had s= ome issues with malleability of version and locktime. OP_SECURETHEBAG commi= ts to both of these values.

=
OP_SECURETHEBAG also lifts the restr= iction that OP_CHECKOUTPUTSVERIFY had to be spent as only a single input, a= nd instead just commits to the number of inputs. This allows for more flexi= bility, but keeps it easy to get the same single output restriction.

BIP: https://github.com/JeremyRubin/bips/blob/= op-secure-the-bag/bip-secure-the-bag.mediawiki
Implementation: https://github.com/JeremyRubin/bitcoin/tree/secur= e_the_bag

A particularly useful topic of discussion i= s how best to eliminate the PUSHDATA and treat OP_SECURETHEBAG like a pushd= ata directly. I thought about how the interpreter works and is implemented = and couldn't come up with something noninvasive.

Than= k you for your review and discussion,

Jer= emy

* Plus the name is better

--000000000000651034058a3c810c--