<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">I agree. It would be even sillier to start specifying container formats for random one-off &quot;that would be kind of nice, I guess&quot; features.</div></blockquote><div><br></div><div>No, it&#39;d be sensible.</div>
<div><br></div><div>Here&#39;s a list I drew up a long time ago of features I imagined adding to the payment protocol:</div><div><br></div><div><a href="https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147">https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147</a></div>
<div><br></div><div>The protocol is there to contain features! There is zero benefit to slavishly following some religious notion of purity or minimalism here. The shared resource in question is just varint encoded integers. So, we should be guided by what will help our users and what will help adoption.</div>
<div><br></div><div>Anyway, Gavin asked me to start handling more BIP 70 stuff a few weeks ago. I want to use something simple to set up the extensions process more formally. IMO we need a &quot;living document&quot; version of the payment protocol with all the different extensions out there folded into it, to simplify programming tasks and ensure field numbers don&#39;t collide.</div>
</div></div></div>