From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WDifW-0003OZ-Nr for bitcoin-development@lists.sourceforge.net; Wed, 12 Feb 2014 22:52:38 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([192.3.11.21]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WDifV-0006dT-St for bitcoin-development@lists.sourceforge.net; Wed, 12 Feb 2014 22:52:38 +0000 Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:be5f:f4ff:febf:4f76]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id BB0B2108377E; Wed, 12 Feb 2014 22:52:56 +0000 (UTC) From: "Luke-Jr" 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: <52FBD948.906@monetize.io> In-Reply-To: <52FBD948.906@monetize.io> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402122252.31060.luke@dashjr.org> X-Spam-Score: -0.7 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WDifV-0006dT-St Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 22:52:38 -0000 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... ;)