<oembed><type>rich</type><version>1.0</version><author_name>npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs</author_name><author_url>https://nostr.ae/npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2014-02-12&#xA;📝 Original message:On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote:&#xA;&gt; On 02/12/2014 08:44 AM, Alan Reiner wrote:&#xA;&gt; &gt; Changing the protocol to use these static IDs is a pretty fundamental&#xA;&gt; &gt; change that would never happen in Bitcoin.   But they can still be&#xA;&gt; &gt; useful at the application level to mitigate these issues.&#xA;&gt; &#xA;&gt; Not to mention that it would be potentially very insecure to have&#xA;&gt; consensus depend on data (scriptSigs) which are not hashed in the Merkle&#xA;&gt; structure of a block.&#xA;&gt; &#xA;&gt; Not that anyone on this list has suggested such a change, but I&#39;ve seen&#xA;&gt; it raised multiple times on the forum....&#xA;&#xA;This would be a problem if it was used in the merkle tree, but I&#39;m pretty sure &#xA;using it for input selection would be pretty safe. One could even avoid the &#xA;index by simply using the hashScript as the sole input value; then even &#xA;CoinJoins would be safe without breaking chains of transactions (although this &#xA;would break address reuse entirely - but I don&#39;t see that as a problem in a &#xA;theoretical world). One of those things that an altcoin could improve upon &#xA;Bitcoin with... ;)</html></oembed>