<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <span dir="ltr"><<a href="mailto:adam@cypherspace.org" target="_blank">adam@cypherspace.org</a>></span> wrote:<br><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"><br>
It would probably be a good idea to have a security considerations<br>
section</blockquote><div><br></div><div>Containing what? I'm not aware of any security considerations that are any different from any other consensus rules change.</div><div><br></div><div>(I can write a blog post summarizing our slack discussion of SPV security immediately after the first greater-than-1mb-block if you like).</div><div><br></div><div> </div><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">, also, is there a list of which exchange, library, wallet,<br>
pool, stats server, hardware etc you have tested this change against?<br></blockquote><div><br></div><div>That testing is happening by the exchange, library, wallet, etc providers themselves. There is a list on the Classic home page:</div><div><br></div><div><a href="https://bitcoinclassic.com/">https://bitcoinclassic.com/</a><br></div><div> <br></div><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">
<br>
Do you have a rollback plan in the event the hard-fork triggers via<br>
false voting as seemed to be prevalent during XT? (Or rollback just<br>
as contingency if something unforseen goes wrong).<br></blockquote><div><br></div><div>The only voting in this BIP is done by the miners, and that cannot be faked.</div><div><br></div><div>Are you talking about people spinning up pseudo-full-nodes that fake the user-agent?</div><div><br></div><div>As I said, there are people who have said they will spin up thousands of full nodes to help prevent possible Sybil attacks which would become marginally easier to accomplish immediately after the first >1mb block was produced and full nodes that hadn't upgraded were left behind.</div><div><br></div><div>Would Blockstream be willing to help out by running a dozen or two extra full nodes?</div><div><br></div><div>I can't imagine any even-remotely-likely sequence of events that would require a rollback, can you be more specific about what you are imagining? Miners suddenly getting cold feet?</div><div> </div><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">How do you plan to monitor and manage security through the hard-fork?<br></blockquote><div><br></div><div>I don't plan to monitor or manage anything; the Bitcoin network is self-monitoring and self-managing. Services like <a href="http://statoshi.info">statoshi.info</a> will do the monitoring, and miners and people and businesses will manage the network, as they do every day.</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div>--<br>Gavin Andresen<br></div><div><br></div></div></div></div>
</div></div>