<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div></div></span><div>I don&#39;t really see how you can protect against total isolation of a node (POS or POW). You would need to find an alternative route for the information. </div></div></div></div></blockquote><div><br></div><div>&quot;Alternative route for the information&quot; is the whole point of weak subjectivity, no?</div><div><br></div><div>PoS depends on weak subjectivity to prevent &quot;<span style="font-size:12.7272720336914px">long term reversals&quot;, but using it also prevents &quot;total isolation&quot; attacks.</span></div><div><span style="font-size:12.7272720336914px"><br></span></div><div>The argument that PoW is better than PoS because PoS has to depend on weak subjectivity, but PoW doesn&#39;t is wrong.</div><div>Any practical implementation of PoW will also have to rely on weak subjectivity to be secure against isolation attack.</div><div>And if we have to rely on weak subjectivity anyway, then why not PoS?</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Again, it is part of the security model that you can connect to at least one honest node.<br></div></div></div></div></blockquote><div><br></div><div>This is the security model of PoW-based consensus. If you study PoW-consensus, then yes, this is the model you have to use.</div><div><br></div><div>But people use Bitcoin Core as a piece of software. They do not care what security model you use, they expect it to work. </div><div>If there are realistic scenarios in which it fails, then this must be documented. Users should be made aware of the problem, should be able to take preventative measures (e.g. manually check the latest block against sources they trust), etc.</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The problem is that if everyone uses the same check, then that source can be compromised.<br></div></div></div></div></blockquote><div><br></div><div>Yes, this problem cannot be solved in a 100% decentralized and automatic way.</div><div>Which doesn&#39;t mean it&#39;s not worth solving, does it?</div><div><br></div><div>1. There are non-decentralized, trust-based solutions: refuse to work if none of well-known nodes are accessible.</div><div>Well-known nodes are already used for bootstrapping, and this is another point which can be attacked.</div><div>So if it&#39;s impossible to make it 100% decentralized and secure, why not make it 99% decentralized and secure?</div><div><br></div><div>2. It is a common practice to check sha256sum after downloading the package, and this is usually done manually.</div><div>Why can&#39;t checking block hashes against some source become a common practice as well?<br></div><div><br></div><div> </div><div>Also it&#39;s worth noting that these security measures are additive.</div><div>Isolating a node AND hijacking one of well-known nodes AND hijacking a block explorer site user checks hashes against is exponentially harder than defeating a single measure.</div><div><br></div></div></div></div>