From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <decker.christian@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A41164A6 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 21 Nov 2018 11:20:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0770A6C5 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 21 Nov 2018 11:20:54 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id z28so4559245edi.8 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 21 Nov 2018 03:20:54 -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=nGIZlu+tp3GPK7vf93qSXBwMfKj66R/duZu7SKH5l+Y=; b=jbeuy4tFAu3ApeCSwiCJj0MqlQzgItDUiQQ54wuPSudEZCV7J2bcTYTnndgvvXzfwr IkW4FP6cGyXDYynBI1ANHsiKoqRLuYxjqEjCHJH49iLcgBhr4PA+i8BfZ7b9N4SVZlGl R0lT6v3kWhx999Rth9PoYl0d645iu0fu/+/DGnAb4AG2Utn4cB33YntZMUHTX1WqlImW vQtlvZhGNLBNJG/ROOrQ8mr2lK8wtrDwM4ToAu8B9ORQztce3k53PXjEYlOjNAZnZu1j sCd5XoW32FyFZzWim7cUr2wl0AGY7ZfFcx2gRgHEQPeLFks4PYV568yBmbSG5LnKumRj F0RA== 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=nGIZlu+tp3GPK7vf93qSXBwMfKj66R/duZu7SKH5l+Y=; b=k2kI9MQOi8MfQ3zHf64pCer1yrjPxw8RutAhsN3Oqx1gg/3zbxg/kcAemC12ydCKC6 UajHySFCdXQzAYpYEGq3BeHYEn6kqAcLDqUc6/qK+vpihxf/YiE9R51YX3bFiWrtidMO VmKGliQ4sd4airUhffyGGv/Z2Z+u3v7zJvqgWeZ3md8oMR8CWZmVx4wlmeTENjPENTon VlAHP8evXjwAz/wf7PnnRbZsnMDbwE6mkU9pkINcn87QIPpuWhwVpZTPJOX9lJydWFha QElDgCnAw3+jR5AMslrhQm31S9CFQsskM1JjS71U41cR9VEno1n5rIs/qiGmU6x9iK6u 6q2w== X-Gm-Message-State: AA+aEWZDCSFY6KGKPiREQIEvMK1ZmG1lO4u4qrv8s7L2I2VbHRTx/Fac nSRw8cpSYwDlTaQlOHG4T9Q= X-Google-Smtp-Source: AFSGD/XeyXU+37bEWYf5+1Qhokw3r/hvNKiFKOPh9ZBQhZf1K8Q+l5MLZshuDdj9isN7uk3kHuRnjA== X-Received: by 2002:a50:b082:: with SMTP id j2-v6mr5335573edd.150.1542799253467; Wed, 21 Nov 2018 03:20:53 -0800 (PST) Received: from localhost ([2a02:aa16:1102:5480:1115:8f2f:6db1:5c0a]) by smtp.gmail.com with ESMTPSA id q4sm9528274eda.50.2018.11.21.03.20.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 21 Nov 2018 03:20:52 -0800 (PST) From: Christian Decker <decker.christian@gmail.com> To: Pieter Wuille <pieter.wuille@gmail.com>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> In-Reply-To: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com> References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com> Date: Wed, 21 Nov 2018 12:15:44 +0100 Message-ID: <87k1l6d6lb.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: Thu, 22 Nov 2018 14:08:02 +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: Wed, 21 Nov 2018 11:20:55 -0000 Hi Pieter, great proposal, I think this may address some of the (perceived) downsides of BIP118, by committing to the script when possible (always?). One minor thing that I noticed a while ago and that I meant to fix on BIP118 is that `hashSequence` does not need to be blanked for eltoo to work (since where it is needed we also use `sighash_single`), so I'm tempted to remove that redundant blanking. It may not make a lot of difference but it'd limit the ability to change the number of inputs to a NOINPUT transaction (this now being the only field that commits to the set of inputs). As for your proposal, I really like the `sighash_scriptmask` proposal, and committing to the fees (with the `nofee` escape hatch) also works seems also a nice fix. My one concern is that introducing a new opcode to mask things in the sighash looks like a similar layering violation as `codeseparator` was, but that's just a minor issue imho. Cheers, Christian Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: > Hello everyone, > > For future segwit versions, I think it would be good add a few things > to the sighash by default that were overlooked in BIP143: > * Committing to the absolute transaction fee (in addition to just the > amount being spent in each input) would categorically remove concerns > about wallets lying about fees to HW devices or airgapped signers. > * Committing to the scriptPubKey (in addition to the scriptCode) would > prevent lying to devices about the type of output being spent, even > when the scriptCode is correct. As a reminder, the scriptCode is the > actually executed script (which is the redeemscript in non-segwit > P2SH, and the witnesscript in P2WSH/P2WPKH). > > As this implies additional information that may not be desirable to > commit to in all circumstances, it makes sense to make these optional. > This obviously interacts with SIGHASH_NOINPUT, which really adds two > different ways of rebinding signatures to inputs: > * Changing the prevout (so that the txid doesn't need to be known when > the signature is created) > * Changing the script (so that the exact scriptPubKey/redeemScript/... > doesn't need to be known when the signature is created) > > Of course, the second implies the first, but do all use cases require > both being able to change the prevout and (arbitrarily) changing the > scriptPubKey? While BIP118 correctly points out this is secure if the > same keys are only used in scripts with which binding is to be > permitted, I feel it would be preferable if signatures/scripts would > explicitly state what can change. One way to accomplish this is by > indicating exactly what in a script is subject to change. > > Here is a combined proposal: > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, > and SIGHASH_SCRIPTMASK. > * A new opcode OP_MASK is added, which acts as a NOP during execution. > * The sighash is computed like in BIP143, but: > * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode > the subsequent opcode/push is removed. > * The scriptPubKey being spent is added to the sighash, unless > SIGHASH_SCRIPTMASK is set. > * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set. > * hashPrevouts, hashSequence, and outpoint are set to null when > SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode). > > So my question is whether anyone can see ways in which this introduces > redundant flexibility, or misses obvious use cases? > > Cheers, > > -- > Pieter > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev