summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAnthony Towns <aj@erisian.com.au>2018-11-23 15:03:30 +1000
committerbitcoindev <bitcoindev@gnusha.org>2018-11-23 05:03:40 +0000
commitf09eac6d4a87a1234c7f91c1e446453f42f6287f (patch)
tree3afbc97da319c008d3da3b56e400c878b1865216
parent905586cb158d7ff5bc733a5ede9b7ad978a7cf70 (diff)
downloadpi-bitcoindev-f09eac6d4a87a1234c7f91c1e446453f42f6287f.tar.gz
pi-bitcoindev-f09eac6d4a87a1234c7f91c1e446453f42f6287f.zip
Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
-rw-r--r--e7/ba4800339f48d144686c968e68d6073491925492
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")
+
+