Date: Thu, 25 Feb 2016 17:48:07 -0800
From: Joseph Poon <joseph@lightning.network>
To: Gregory Maxwell <greg@xiph.org>
Message-ID: <20160226014807.GA23810@lightning.network>
References: <20160226010746.GB10295@lightning.network>
	<CAAS2fgTphe5T8EBtz0xKRpRuLaO0P=3WeW2d1WD6b4Ark79rMQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAS2fgTphe5T8EBtz0xKRpRuLaO0P=3WeW2d1WD6b4Ark79rMQ@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness
Precedence: list

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