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 589CEC65 for ; Fri, 26 Feb 2016 01:32:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A20D9731 for ; Fri, 26 Feb 2016 01:32:35 +0000 (UTC) Received: by mail-io0-f169.google.com with SMTP id 9so102827984iom.1 for ; Thu, 25 Feb 2016 17:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=WXlEzc8L9hdy22PhQ/yCaKtW1bkgDwM6WESyA6iF+KU=; b=Qg9+FDzxHwoiRPp+w1KH2sf/B20dfgFkXWZ6fLElTaqTCDvj3jvrtIKPe8kLO787Dp LViQq+gsRtw9BONR8aLQZvMeG4inWIoS9adRlt2aPNDV+cccRKandOps0+wME/FczfhT IFOsMi9iqE0vv8rKfXGed4l5qFcEKLZ+75KdX6MK5psrOOD1705j3liU1eYP/AOvwv1Y Y7jaWRx7F8VZ4vmB0n4Pa1kmCc8QhcC/oa5RLKwEDWC4UMKetLBSCgZO7coEwMc1phfO eEwidOZl69LbsoCQwxl4aU7cMobFQNpVbFY845LnbboA+5kK3+6TLNKF/xsA2TPDJBPA bjaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=WXlEzc8L9hdy22PhQ/yCaKtW1bkgDwM6WESyA6iF+KU=; b=fI7aJRIW7PC7bKFZbH34/p6GhHhJ+BRnENenNkHGJdsfboYmid7KK1BUsD0xw6ygPv t6g8u9B3hsF++FD2+u3QqX0q3O4h9f8O1QjWgYKMjGKphzGirOZFzFa0m6jMFOlf6Al4 xm+ExdaI88ZU1TbE2eZyDi1Wn1cIIIvvpX9UYHMOdwrQWe9tYA1l9SgO5c8EzA+YBOHU PSC/EG0EuRkh5DyCv4ye19zvKeBF+YasqvSLABhkRNUAXuSSBpP+yqjiE9VqDtqupP5S 13fAI/xCSMRW7e+EdJ2HJrkS0t8d4E6cphmtK4dBEtoBKuf9xa6mD0x+jdSJmIDbXsA7 hnUQ== X-Gm-Message-State: AG10YOR+Vky46/e0fsBsYwl+VqrbzUS+8cLmU1sjz/MKfj36zBQfh6rpNaXiBt+hfWBPf5ElxqkWKcrPTZvalQ== MIME-Version: 1.0 X-Received: by 10.107.14.66 with SMTP id 63mr6232259ioo.150.1456450354198; Thu, 25 Feb 2016 17:32:34 -0800 (PST) Sender: gmaxwell@gmail.com Received: by 10.107.132.75 with HTTP; Thu, 25 Feb 2016 17:32:34 -0800 (PST) In-Reply-To: <20160226010746.GB10295@lightning.network> References: <20160226010746.GB10295@lightning.network> Date: Fri, 26 Feb 2016 01:32:34 +0000 X-Google-Sender-Auth: QlmL3QWF6DYepChCKd7CtZhAZqY Message-ID: From: Gregory Maxwell To: Joseph Poon 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 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 01:32:36 -0000 On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev wrote: > I'm interested in input and in the level of receptiveness to this. If > there is interest, I'll write up a draft BIP in the next couple days. The design of segwit was carefully constructed to make it maximally easy and safe to soft-fork in future script enhancements after its deployment with the specific goal of avoiding indefinite delays in its deployment from inevitable scope creep from additional things that are "easy" to deploy as part of segwit. I think to be successful we must be absolutely ruthless about changes that go in there beyond the absolute minimum needed for the safe deployment of segwit... so I think this should probably be constructed as a new segwit script type, and not a base feature. The exact construction you're thinking of there isn't clear to me... one thing that comes to mind is that I think it is imperative that we do not deploy a without-inputs SIGHASH flag without also deploying at least a fee-committing sighash-all. The reason for this is that if hardware wallets are forced to continue transferring input transactions to check fees or to use without-inputs, they may choose the latter and leave the users needlessly exposed to replay attacks. When you do write a BIP for this its imperative that the vulnerability to replay is called out in bold blinking flaming text, along with the necessary description of how to use it safely. The fact that without input commitments transactions are replayable is highly surprising to many developers... Personally, I'd even go so far as to name the flag SIGHASH_REPLAY_VULNERABLE. :)