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 D67E2D73 for ; Fri, 26 Feb 2016 01:48:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7A014141 for ; Fri, 26 Feb 2016 01:48:49 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id fy10so41858982pac.1 for ; Thu, 25 Feb 2016 17:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightning.network; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=ra2nZ9Ke0ljPOH/BbwYpRRBqjLmtPmJcwWHATWByWds=; b=aL+5/ovq0aWIP+1bT3mxd88aReFI8TFRoyJ1yuCEwSfSIL8mySqpQo5ujW9zRH3+Ra L8fwESavjBs+mBDmqLZemUjjLYm3DYomC7ppKs5Bh1hkXn1DdlAzziRQ/cZDFYgTO7Hu B/qHO4/NUFutwUPzclX49Hw7cV8hrV02CvKSE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to; bh=ra2nZ9Ke0ljPOH/BbwYpRRBqjLmtPmJcwWHATWByWds=; b=P9pMrTvPMYPpP2TB2f5liPupPlpmvIMp54YAmC7T8ojH9rTzDCieu1jsKDUKo0yC9P bFqW2N5iByytQnEw2zhCSmOfL+C9KhNnvEcX9RfHRAlI3IxcAM6acrkkXh8BzA5qE/g5 +SxnKV6sjGnjPZoDUZ+g84COwwfWw3gsovhA3uzvfnp5MrAJhOLxlYYf5W6pG99Yr9qQ bAlh+i+xtpwTWccu9toy8GK9gJnQfwrZ0cyU30nXg3L1ZJ5bVCrlO7hl57rv5+ghy7lF 4uWtImSHemeOcswF8U/iW4x2LKmHph4kRqVTtaP/G/F5yrUo+t9CgXV1HBQvAC8gVKoY 2icA== X-Gm-Message-State: AG10YOTBm9HpZeAsiCjwRDXdeYkVk/Zf+8JXSu9HvELpvhHXxy8fB9VEPkKNBaXqZgYO1A== X-Received: by 10.66.231.100 with SMTP id tf4mr67879898pac.44.1456451329198; Thu, 25 Feb 2016 17:48:49 -0800 (PST) Received: from localhost ([2605:6400:20:11aa:189e:28a5:52ed:8948]) by smtp.gmail.com with ESMTPSA id e1sm14937322pas.1.2016.02.25.17.48.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 17:48:48 -0800 (PST) Date: Thu, 25 Feb 2016 17:48:07 -0800 From: Joseph Poon To: Gregory Maxwell Message-ID: <20160226014807.GA23810@lightning.network> References: <20160226010746.GB10295@lightning.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU 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: Fri, 26 Feb 2016 03:13:08 +0000 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:48:50 -0000 Hi Greg, On Fri, Feb 26, 2016 at 01:32:34AM +0000, Gregory Maxwell wrote: > 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. Absolutely, I'd certainly be interested in this being the first proof/example for the script upgrade mechanisms if it's not ideal for this to be implemented as part of Segregated Witness itself. > 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. Yes, I think it's necessary to include the fees as part of the signature, which will also allow for wallets to not require downloading the input transactions. However, it's necessary to not include the input amount itself, as they may differ. SegWit itself is very nice in that it prevents improperly designed wallets and services using the bitcoin RPC from making mistakes, you can resolve malleability without compromises -- I also think any proposed SIGHASH should ensure some measure of safety from design error/shortcuts. > 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. :) That's a good point, choosing a scary name is probably very helpful. Thanks, I'll clarify with a specific BIP soon. -- Joseph Poon