From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9A9AAB78 for ; Thu, 29 Nov 2018 17:00:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 489FC27B for ; Thu, 29 Nov 2018 17:00:17 +0000 (UTC) Received: by mail-ed1-f47.google.com with SMTP id r27so2522134eda.0 for ; Thu, 29 Nov 2018 09:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=BqvLiD+SnPeNXvwpHhAWOyJaL/bmNzLhIAToNwrhJLQ=; b=a6gjDJ1dnKq7AyRQe9i3Ej9PxwxPw63psK02RCqG7dWGEgkaBppk4WtyQdRWCtGVou ZB3mQ+/FR72huBa51vcAnXRZgrJlEhYypVQ2UDh93T5ZSYISSnJlkTRp+P3f4uFgS3HL HQaizL8q2OSWntW4v2iYUIODA9dQnWByz2OkFPM1hZ4CHdm3Tg2Zd0d4eXh4w1sElxKc rJs8rNvAnq57OoVVKEkI5D7a+/p14G6XccW0Hgd1c1/nfBmK+sUVrP8gLnhiRCjKmxjM EsO0LOakR4xjucod/T1BGkeO5vu6mO7OQ4dUmNLDIaLFzSIAfgVxJQdLRH9Y/6sv5Ovp bDdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=BqvLiD+SnPeNXvwpHhAWOyJaL/bmNzLhIAToNwrhJLQ=; b=p2JJiOTdtdsoCyk9lLCDR+yXHypavD1200W6z/r2jWmYLFBs5TCJvrXpAKEEnM8w6A 4yZ4/wow1MNftZnElCcYf0Zt22rWl7CYkIVra2Tu/75zl1V55QB13SzfwKpIXHsPfvzb NPmNR1vi85fO2JVV1EOOI3shWQFCTdLSiWH0NYbEwL8+8/LUgpVuw53aBG9zuMniuwmE nmIJyh9hxa2JnEIGffNT7tl92kR8QPsd0do5VNMPDlJvjvdKECZmJ7uC+6Wfot1T2Uqy qPfYlZ6ydLTfBes0e9hkG+qAN2Kw3iTnt6ZJrw+AAmtd9/BRnUO7CkO9RdGmYmB+mdbl Utjw== X-Gm-Message-State: AA+aEWYo84xX5aeCUYgQklupNK11Fg2xTuEgj0A8V7dkOPWsM67TBHJ6 w5fMZevsS9VP+BXCIQThXwk= X-Google-Smtp-Source: AFSGD/WPskAd9iN+xcQnyGhzsHtCPYt5qtL10Ho9pw8HDcoJI2qrGi686+vmb6iaQe/7H+loBtEMXg== X-Received: by 2002:a50:b667:: with SMTP id c36mr2433337ede.190.1543510815730; Thu, 29 Nov 2018 09:00:15 -0800 (PST) Received: from localhost ([2a02:aa16:1102:5480:b8c8:56f0:43e2:f1fe]) by smtp.gmail.com with ESMTPSA id p21-v6sm425005ejz.45.2018.11.29.09.00.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 29 Nov 2018 09:00:14 -0800 (PST) From: Christian Decker To: Pieter Wuille , Bitcoin Protocol Discussion , Bitcoin Dev In-Reply-To: References: Date: Thu, 29 Nov 2018 18:00:09 +0100 Message-ID: <87d0qnrf8m.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE 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: Fri, 30 Nov 2018 14:47:14 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2018 17:00:18 -0000 Pieter Wuille via bitcoin-dev writes: > On Mon, 19 Nov 2018 at 14:37, Pieter Wuille wrote: > * It's probably better to sign the amounts of all inputs, as suggested > by Johnson Lau. As that would cause default sighashes to sign all > input and output amounts, is there still a need to sign the tx fee > explicitly? Or in other words, are there situations where changing the > set of inputs or outputs after signing is desired, but the net > difference between them cannot change? If not, that would remove the > need for NOFEE. So the final proposal would be to append a new `hashValues` field to the hashed representation, with `hashValues` just being the double SHA256 of all values? In that case SINGLE needs to blank that hash, otherwise we'd be committing to all inputs again. Once we have that detail, we can start thinking about what it means to commit to the fee vs. committing to the values. Since the fee is given by the output values and the input values we only need to consider the cases in which they can be modified. - NOINPUT (as in BIP118) commits to the value (and I can't think of a usecase where we'd want to change that), and that transparently extends to all other inputs. - For ANYONECANPAY can't really commit to a fee anyway so ANYONECANPAY would likely imply NOFEE. - With NONE all bets are off anyway, so no need to consider that :-) - SINGLE is a bit special, and for value commitments it reduces to the current commitment to its own value, for fee commitment it's hard to see a use of that commitment at all afaik (I think the combination SINGLE|NOFEE would always be used). > * Do we need to keep the rule that sequence values of other inputs are > only signed with default sighash? It feels cleaner to always sign the > sequence values of all inputs that are included in the sighash anyway > (so all of them, unless ANYONECANPAY or NOINPUT, which would make it > sign only the current input's sequence value). If NOINPUT also blanks > the sequence values (as currently specified by BIP118), and all input > amounts are signed, that would make amounts/sequence values always be > treated identically. Single cannot commit to other the sequence of other inputs, otherwise we're breaking SINGLE completely. As mentioned before NOINPUT doesn't need to blank `hashSequence`, but I'm happy to make it match if that makes implementations handle fewer cases. > * If MASK implies NOINPUT, and NOINPUT implies ANYONECANPAY, the 3 of > them can be encoded in just 2 bits using the > PARTIALSCRIPT/KNOWNSCRIPT/KNOWNTX/ALL_INPUTS encoding Anthony Towns > suggested. So we'd end up enumerating the combinations rather than having independent bits for each of them? This might save us storage bits, but it'd also result in uglier code imho, not a strong feeling but might come back to haunt us if we ever come up with something new :-) > So a combined proposal: > * All existing sighash flags, plus NOINPUT and MASK > (ANYONECANPAY/NOINPUT/MASK are encoded in 2 bits). > * A new opcode called OP_MASKEDPUSH, whose only runtime behaviour is > failing if not immediately followed by a push, or when appearing as > last opcode in the script. > * Signatures are 64 plus an optional sighash byte. A missing sighash > byte implies ALL, and ALL cannot be specified explicitly. > * The sighash is computed from the following: > * A 64-byte constant tag > * Data about the spending transaction: > * The transaction version number > * The hash of txins' prevouts+amounts+sequences (or nothing if ANYONECANPAY) This needs to be partially blanked for SINGLE as well, otherwise we break SINGLE. > * The hash of all txouts (or just the corresponding txout if > SINGLE; nothing if NONE) > * The transaction locktime > * Data about the output being spent: > * The prevout (or nothing if NOINPUT) > * The amount > * The sequence number I assume the sequence number here refers to the input being signed, not the sequence number of the transaction output being spent :-) Might be easier if we consider 3 parts: the spending transaction, the input being signed, and the output (or TX) being spent. Cheers, Christian