Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of dashjr.org
	designates 85.234.147.28 as permitted sender)
	client-ip=85.234.147.28; envelope-from=luke@dashjr.org;
	helo=zinan.dashjr.org; 
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net,
 s7r@sky-ip.org
Date: Fri, 15 May 2015 16:31:47 +0000
User-Agent: KMail/1.13.7 (Linux/3.14.41-gentoo; KDE/4.14.3; x86_64; ; )
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
	<5555C26F.7080706@sky-ip.org>
In-Reply-To: <5555C26F.7080706@sky-ip.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201505151631.48765.luke@dashjr.org>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Precedence: list

On Friday, May 15, 2015 9:54:55 AM s7r wrote:
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays. This could
> work if we were using only one scriptPubKey per tx. But this is not
> enforced, ...

Assuming you mean one output per scriptPubKey (and not limiting tx to one 
output), the alternative is essentially undefined, and creates real problems 
for Bitcoin today. It's not something we should go out of the way to support 
or encourage. Therefore, regardless of whatever other options are available, I 
would like to see a scriptPubKey-only sighash type for strong safety within 
all malleability situations (including CoinJoin and other sender-respends) 
that more advanced wallet software could take advantage of in the future 
(while strictly enforcing no-reuse on its own wallet to avoid known replays).

Luke