Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B985BC87; Fri, 26 Feb 2016 03:21:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56F9E13B; Fri, 26 Feb 2016 03:21:03 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) id 1aZ8xg-0005pp-0q; Fri, 26 Feb 2016 13:21:01 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Fri, 26 Feb 2016 13:20:56 +1000 Date: Fri, 26 Feb 2016 13:20:56 +1000 From: Anthony Towns To: bitcoin-dev@lists.linuxfoundation.org, lightning-dev@lists.linuxfoundation.org Message-ID: <20160226032056.GA10450@sapphire.erisian.com.au> References: <20160226010746.GB10295@lightning.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 03:21:04 -0000 On Fri, Feb 26, 2016 at 01:32:34AM +0000, Gregory Maxwell via bitcoin-dev wrote: > 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. > .. I think this should probably be constructed as a new segwit script type, > and not a base feature. +1 to both > The exact construction you're thinking of there isn't clear to me... I think the idea is that you have three transactions: anchor: input: whatever output: - single output, spendable by 2-of-2 multisig - [possibly others as well, whatever] commitment: input: anchor outputs: 1. payment to A 2. payment to B 3. HTLC to A on R1, timeout T1 4. HTLC to A on R2, timeout T2 5. HTLC to B on R3, timeout T3 ... penalty: inputs: all the outputs from the commitment tx outputs: 1. 99% as payment to me 2. 1% as outsourcing fee As long as the key I use for spending each of commitment transactions outputs is "single use" -- ie, I don't use it for other channels or anywhere else on the blockchain, then as long as the signature commits to the outputs it's safe afaics. (You still have to send a lot of data to the place you're outsourcing chain-monitoring to; all the R1,R2,R3 and T1,T2,T3 values are needed in order to reconstruct the redeem scripts) > 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. If the fee for commitment transactions changes regularly (eg, a new commitment transaction is generated every few seconds/minutes, and the fee is chosen based on whatever estimatefee returns), I think this would cause problems -- you couldn't use a single signature to cover every revoked commitment, you'd need one for each different fee level that you'd used for the lifetime of the channel. Actually, the size of the commitment transaction will differ anyway depending on how many HTLCs are open, so even if estimatefee didn't change, the fee would still differ. So I think commiting to a fee isn't workable for the lightning use case... > 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. :) +1, though I'm not sure it's so much "vulnerable" to replay as it is "explicitly designed" to be replayable... Cheers, aj