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 18838C9F; Mon, 2 Jul 2018 18:11:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f66.google.com (mail-vk0-f66.google.com [209.85.213.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DEFE5689; Mon, 2 Jul 2018 18:11:55 +0000 (UTC) Received: by mail-vk0-f66.google.com with SMTP id b14-v6so4017108vke.13; Mon, 02 Jul 2018 11:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zHSQFRW8qhAZeP4B81CS/ggLithRFUxQpEXT8+pAOOw=; b=GAAn0hr09mKOLghPuK/SuZiNpfcCvBG929uIZ/e0JFHQQ6L3InyNPjpMdTVL9dtDgU rSQXlt42gWB6s18qqDByI/wL2NVtIdD3FvlyRvwDadfM6vWU8rPxIhQg0knWcS30LPnn oXSTNUeFPAiS3MkpHRR3mX67YcqnkdIHWnhDtFZl7RbFBHTcVEy/LBeNBUkksFXEH6A7 SKuTWO9TzglkZsQDJO72fov6VNssVk/OZM4U3Pg8ar6uv1Vx0WJD9CHjoidUlMuVhWbc J4w+TgC6gFurIDjUha3PXQ6qtJ1L6d2t3rXNkdscixFTXSc3C4f7AX85icN9JOZorUOx 8YIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zHSQFRW8qhAZeP4B81CS/ggLithRFUxQpEXT8+pAOOw=; b=r6RjsCRzrMYfXn+C9IgIGkaDK2wJRyM9ElDD764WHSVKCXL19czP3a8WeGUcqk0+hI LGeomjnQQ6rFRZqJBQzpozUvVvq8F66skZpuO/xe4GDXSVSYzjqGMPNCCZy9MYpKzp93 P/N3wftYFXZebFQHyfqTs3Jw/61vKUIz5wo8ttWGEkcBBuPsPkgqQdrzGNvoYdsTCJq9 YK6BUW2q+AsqxeW6uiiIaDQ2/F9Lh1FRouXMrhXPrS3fGDph9I73tK3SvMdrqETS8OUp ZkUYbB8qU09gHxPy7zC/81AuVYX+C8CI7PLsMXOhHN0RYI2/Ww9koOFEXkvB8yOOohRD m+1g== X-Gm-Message-State: APt69E1wJF2OdOFLNRxWfmV7cJWNwqG/A4oyTcE3htSYtjDbXd5l0g2S zdFMmkfeuw6GXyhgnjlCi+RXbX8xq7TWMXTlKSw= X-Google-Smtp-Source: AAOMgpdrT5qOLjSABXWZe94J6Rju9Yi9QN/D9O+NdEOF5qTKLEsa/l81quroITI+n/xQ3AvODtFHTzbECHjjCpPFEek= X-Received: by 2002:a1f:a285:: with SMTP id l127-v6mr15694074vke.95.1530555115008; Mon, 02 Jul 2018 11:11:55 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 2002:a67:51c9:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 11:11:54 -0700 (PDT) In-Reply-To: <871sewirni.fsf@gmail.com> References: <871sewirni.fsf@gmail.com> From: Gregory Maxwell Date: Mon, 2 Jul 2018 18:11:54 +0000 X-Google-Sender-Auth: gRHzNaAUSDYfXSbySYfBOOVaFJQ Message-ID: To: Christian Decker , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 Cc: lightning-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 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: Mon, 02 Jul 2018 18:11:57 -0000 On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev wrote: > Hi all, > > I'd like to pick up the discussion from a few months ago, and propose a new > sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous I know it seems kind of silly, but I think it's somewhat important that the formal name of this flag is something like "SIGHASH_REPLAY_VULNERABLE" or likewise or at least "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially insecure for traditional applications where a third party might pay to an address a second time, and should only be used in special protocols which make that kind of mistake unlikely. Otherwise, I'm worried that wallets might start using this sighash because it simplifies handling malleability without realizing that when a third party reuses a script pubkey, completely outside of control of the wallet that uses the flag, funds will be lost as soon as a troublemaker shows up (but not, sadly, in testing). This sort of risk is magnified because the third party address reuser has no way to know that this sighash flag has (or will) be used with a particular scriptpubkey. So, one could even argue that the possibility that someone might use this flag means that it's generally unsafe to reuse a scriptpubkey. I don't think the same argument applies for NONE or the single-bug because they render even a single use insecure... The best mitigation I can think of is defence in depth to ensure that anyone who uses this sighash flag understands the consequences.