diff options
author | Anthony Towns <aj@erisian.com.au> | 2018-11-23 15:03:30 +1000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-11-23 05:03:40 +0000 |
commit | f09eac6d4a87a1234c7f91c1e446453f42f6287f (patch) | |
tree | 3afbc97da319c008d3da3b56e400c878b1865216 | |
parent | 905586cb158d7ff5bc733a5ede9b7ad978a7cf70 (diff) | |
download | pi-bitcoindev-f09eac6d4a87a1234c7f91c1e446453f42f6287f.tar.gz pi-bitcoindev-f09eac6d4a87a1234c7f91c1e446453f42f6287f.zip |
Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
-rw-r--r-- | e7/ba4800339f48d144686c968e68d60734919254 | 92 |
1 files changed, 92 insertions, 0 deletions
diff --git a/e7/ba4800339f48d144686c968e68d60734919254 b/e7/ba4800339f48d144686c968e68d60734919254 new file mode 100644 index 000000000..ae56cc127 --- /dev/null +++ b/e7/ba4800339f48d144686c968e68d60734919254 @@ -0,0 +1,92 @@ +Return-Path: <aj@erisian.com.au> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 68344C9A + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 23 Nov 2018 05:03:40 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA9CB8A + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 23 Nov 2018 05:03:39 +0000 (UTC) +Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) + by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) + id 1gQ3ct-0001j5-L8; Fri, 23 Nov 2018 15:03:37 +1000 +Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); + Fri, 23 Nov 2018 15:03:30 +1000 +Date: Fri, 23 Nov 2018 15:03:30 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: Russell O'Connor <roconnor@blockstream.io>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <20181123050330.x4xrgouit7apwk45@erisian.com.au> +References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com> + <CAMZUoK==Bdn73Lc=swgf2F5_mqE84TR1GRBFhrFkn7kab4jBaw@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=iso-8859-1 +Content-Disposition: inline +Content-Transfer-Encoding: 8bit +In-Reply-To: <CAMZUoK==Bdn73Lc=swgf2F5_mqE84TR1GRBFhrFkn7kab4jBaw@mail.gmail.com> +User-Agent: NeoMutt/20170113 (1.7.2) +X-Spam-Score: -1.9 +X-Spam-Score-int: -18 +X-Spam-Bar: - +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY + 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, 24 Nov 2018 02:17:49 +0000 +Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +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, 23 Nov 2018 05:03:40 -0000 + +On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev wrote: +> Given that we want to move away from OP_CODESEPARATOR, because each call to +> this operation effectively takes O(script-size) time, we need a replacement for +> the functionality it currently provides.� While perhaps the original motivation +> for OP_CODESEPARTOR is surrounded in mystery, it currently can be used (or +> perhaps abused) for the task of creating signature that covers, not only which +> input is being signed, but which specific branch within that input Script code +> is being signed for. + +Would it be sufficient to sign the position within the script of the +last OP_CODESEPARATOR? That is, if your script is: + + DUP DUP CHECKSIG CODESEP CHECKSIG CODESEP CHECKSIG + +with the idea being that it can be spent by providing any pub key and +three different signatures by that key, with the first sig committing +to a "codesep position" of 0, the second a "codesep position" of 4, +and the third a "codesep position" of 6? In each case, the signature +also commits to the full (possibly masked) script as well. + +I think that covers all the behaviour you can currently achieve with +CODESEP (which is pretty limited since every sig effectively commits +to the full redeem script, and you can't commit to subsets of the +signature/witness), and it keeps the things you can do with the various +features a bit orthogonal: + + NOINPUT -- lets the sig apply to different transactions + OP_MASK -- lets the different txes have variations in the script the + sig applies to + CODESEP -- lets you require different sigs for different parts of a + single script + MAST[0] -- provides alternative scripts, doesn't affect sigs + IF/etc -- provides control flow within a script, doesn't affect sigs + +Cheers, +aj + +[0] (I think I'm going to claim "MAST" stands for "merkelized alternative + script tree" these days, since they're not "abstract syntax trees") + + |