Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1ABD0C8A for ; Mon, 3 Sep 2018 13:53:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5F3ABD3 for ; Mon, 3 Sep 2018 13:53:43 +0000 (UTC) Received: by mail-ed1-f48.google.com with SMTP id f38-v6so843357edd.8 for ; Mon, 03 Sep 2018 06:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=aMAJmXGind57xBDfHNBWrMwEZrfeg8zfcfaE7wctbA8=; b=en/ZuNYqAfKE22sMF1fWoGl/9LtGPym+3Y4+fof6WmoXWuPlKLoxKyJKKu4B3Z0Kyk 7ibVKCF1dUGRatR/pkiOcuxKUUTKoL5hrtHv9iJOgPY5rcWCXs9TwJGYO73RG2qP6wfK Q9wuWEJmfvt3u0TJGPCfqFztkYmAEiIsTrWpi+KX6Z0xxw10tUplhPZlhFqtBE4m+MF6 pKBx1v+cNtRVWTShkSIVZbDwMa0Lm/BZ8WM+Y1NtJD32t/rwyERgadzRLBXfPPf4kshm cAtEcY5RFab7HqBSc3cneek13Y3Cd5aHedWWh31nh/HV00X1gIE73PHJCcirCzBpMrej eOMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=aMAJmXGind57xBDfHNBWrMwEZrfeg8zfcfaE7wctbA8=; b=IfO2XhV5VFx2Uihwi3TirqA2ISDntrtuKLstjxjPvbWcqLzN0FfPB5eqoJHBKez4V5 Lz15cTFU/TaPIoiQfGKfKEswSsXN+KoHglx6/1atT67mMWglZBqPC2ljGgDc9RuZYXLI eWrBTT6XjBiUcioSy6O47U0OPs/Zpy7a7Nqz3BB7BHl5Pr7yrJZbG/GUf8tNg3ntVwwb BFlyHwqHXlUaBIYFHIcrgW7SWDg+xUmtMTeVvc6KunowcaTu4cLpQ1CDJ/1H604tvack z1ZrfBC9xkzVVkchBXSiHsvE1+YT19szIMO0ILU0pBvnBs0dIl3GVnb82IP60I/SapP6 uR3g== X-Gm-Message-State: APzg51DxLrDfR2iK1WvE+5cjWkA+cFJ7dCrOYttTYP+zGDnxZYIVQ0Yf glyHSFYkIGdrp2W44jAieP0= X-Google-Smtp-Source: ANB0Vdb3N6bqrIK6+oXN8CQLcRJOuaEche9ot7lktV7uitedLMxeqVXgrSDctRZl+FiLdXd5Fblk4A== X-Received: by 2002:a50:9feb:: with SMTP id c98-v6mr32640155edf.130.1535982821908; Mon, 03 Sep 2018 06:53:41 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9]) by smtp.gmail.com with ESMTPSA id c24-v6sm7818651ede.53.2018.09.03.06.53.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 06:53:40 -0700 (PDT) From: Christian Decker To: Johnson Lau In-Reply-To: <23B1C9E3-9C94-43A3-A543-0AF9A8C10C7E@xbt.hk> References: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk> <87sh2vlgsc.fsf@gmail.com> <23B1C9E3-9C94-43A3-A543-0AF9A8C10C7E@xbt.hk> Date: Mon, 03 Sep 2018 15:53:33 +0200 Message-ID: <87in3mlmaq.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 03 Sep 2018 23:25:52 +0000 Cc: bitcoin-dev Subject: Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme 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: Mon, 03 Sep 2018 13:53:44 -0000 Johnson Lau writes: > Great, I=E2=80=99ll revise it. > > Follow-up questions: > > 1. Is there any useful case which one would like to use NOINPUT with > scriptCode and/or scriptPubKey committed? (Note that with > taproot/MAST, scriptCode and scriptPubKey are not > interchangeable. scriptPubKey commits to all branches, and scriptCode > is just one script branch). If yes, we could make this configurable. There is the poor man's malleability fix that you get if you make only the previous outpoint rewritable, but that use-case is better covered by segwit already, and since both of our proposals would be for segwit outputs only, I don't see a point in doing that. > 2. Which of the following approaches is better? > A) sign scriptPubKey in every cases except NOINPUT > B) sign the type (P2SH-segwit vs. Native-segwit) of scriptPubKey in every= cases, including NOINPUT > C) all of the above > D) none of the above What do we effectively gain by committing to the scriptPubkey type? Is the concern here that we might run into ambiguity about whether this is a MAST, P2SH, or similar output, allowing an attacker to sideload unwanted effects? > Option B is very easy to implement as SignatureHash() could > distinguish the type by the size of scriptSig in TxTo. Option A is > more complicated as GenericTransactionSignatureChecker needs to know > the scriptPubKey. > > If the only reason for doing this is to allow hardware wallet to > distinguish the segwit type, option B is probably enough. This is also > compatible with eltoo. Agreed on compatibility :-) > Option A is useful when a hardware wallet reuses the same public key > in different scripts, but it couldn=E2=80=99t be applied to NOINPUT > > 3. Is the proposed DUALOUTPUT somehow useful for eltoo? Eltoo use > NOINPUT|SINGLE to allow fee pumping, since it is an > one-input-one-output tx. This is not possible with the existing LN as > the tx is one-input-two-output. If we had DUALOUTPUT which signs the > matched and last output, fee-pumping would be possible in the existing > LN. That's a very strange concept, but it strongly relies on the structure of the commitment, having two outputs. As soon as we have HTLCs included in the commitment we no longer have 2 outputs (2 for the endpoints, and 1 as a base for the two-phase HTLC resolution), so this would be a rather brittle fix or would require major restructuring of LN imho. Cheers, Christian