From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 12 Feb 2014 22:52:30 +0000
User-Agent: KMail/1.13.7 (Linux/3.12.6-gentoo; KDE/4.11.2; x86_64; ; )
References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
	<CALf2ePwc=es-aDSeJO2DZwu9kyHwq9dcp5TrMAhN-dvYwNjy-w@mail.gmail.com>
	<52FBD948.906@monetize.io>
In-Reply-To: <52FBD948.906@monetize.io>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201402122252.31060.luke@dashjr.org>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
	malleability
Precedence: list

On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote:
> On 02/12/2014 08:44 AM, Alan Reiner wrote:
> > Changing the protocol to use these static IDs is a pretty fundamental
> > change that would never happen in Bitcoin.   But they can still be
> > useful at the application level to mitigate these issues.
> 
> Not to mention that it would be potentially very insecure to have
> consensus depend on data (scriptSigs) which are not hashed in the Merkle
> structure of a block.
> 
> Not that anyone on this list has suggested such a change, but I've seen
> it raised multiple times on the forum....

This would be a problem if it was used in the merkle tree, but I'm pretty sure 
using it for input selection would be pretty safe. One could even avoid the 
index by simply using the hashScript as the sole input value; then even 
CoinJoins would be safe without breaking chains of transactions (although this 
would break address reuse entirely - but I don't see that as a problem in a 
theoretical world). One of those things that an altcoin could improve upon 
Bitcoin with... ;)