<div dir="ltr">I think this needs more details before it gets a BIP number; for example, which opcodes does this affect, and how, exactly, does it affect them? Is the merkle root in the block header computed using normalized transaction ids or normalized ids? <div><br></div><div>I think there might actually be two or three or four BIPs here:</div><div><br></div><div> + Overall "what is trying to be accomplished"</div><div> + Changes to the OP_*SIG* opcodes</div><div> + Changes to the bloom-filtering SPV support</div><div> + ...eventually, hard fork rollout plan</div><div><br><div>I also think that it is a good idea to have actually implemented a proposal before getting a BIP number. At least, I find that actually writing the code often turns up issues I hadn't considered when thinking about the problem at a high level. And I STRONGLY believe BIPs should be descriptive ("here is how this thing works") not proscriptive ("here's how I think we should all do it").</div></div><div><br></div><div>Finally: I like the idea of moving to a normalized txid. But it might make sense to bundle that change with a bigger change to OP_CHECKSIG; see Greg Maxwell's excellent talk about his current thoughts on that topic:</div><div> <a href="https://www.youtube.com/watch?v=Gs9lJTRZCDc">https://www.youtube.com/watch?v=Gs9lJTRZCDc</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 13, 2015 at 9:12 AM, Tier Nolan <span dir="ltr"><<a href="mailto:tier.nolan@gmail.com" target="_blank">tier.nolan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I think this is a good way to handle things, but as you say, it is a hard fork.<br><br></div>CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to fix malleability once and for all.<br><div><div><br>This has the effect of doubling the size of the UTXO database. At minimum, there needs to be a legacy txid to normalized txid map in the database.<br><br></div><div>An addition to the BIP would eliminate the need for the 2nd index. You could require a SPV proof of the spending transaction to be included with legacy transactions. This would allow clients to verify that the normalized txid matched the legacy id.<br><br></div><div>The OutPoint would be {LegacyId | SPV Proof to spending tx | spending tx | index}. This allows a legacy transaction to be upgraded. OutPoints which use a normalized txid don't need the SPV proof.<br><br></div><div>The hard fork would be followed by a transitional period, in which both txids could be used. Afterwards, legacy transactions have to have the SPV proof added. This means that old transactions with locktimes years in the future can be upgraded for spending, without nodes needing to maintain two indexes.<br></div></div></div>
<br>------------------------------------------------------------------------------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href="http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target="_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">--<br>Gavin Andresen<br></div>
</div>