<div dir="ltr"><div>SPV is tiny weaker than full nodes in security model ONLY when you read codes carefully, understand it thoroughly, and compile it with trusted tools. So, it&#39;s very irresponsible to spread the FUD to frighten users away SPV. Sticking to full nodes results in unnecessary burden to Both users and Bitcoin network, while bringing in literally zero benefits.</div><div><br></div><div>I agree with Both Jeff and Sjors on the protocol process. RFC 7282 successfully prevented the fake UASF although most of committee members were corrupted. However, it may have fatal disadvantages. A small portion, i.e. three members, can unite to prevent all commits others who they dislike make, thus the most talented devs will leave gradually, while the same kind of people will join them. Under RFC 7282, the formation of cliques for their selfish interests is inevitable.</div><div><br></div><div>Fortunately, the success of Bitcoin (SegWit2X) will set a precedent that no group is irreplaceable, thus there will be less effort and money to be used to corrupt committee members. Corruption would be delayed.</div><div><br></div><div>So RFC 7282 is at least insufficient. It only can prevent contentious Soft Fork and contentious Hard Fork. Instead, it encourages contentious No Fork. Certain &#39;No fork&#39; is more dangerous than SF and HF.</div><div><br></div><div><br></div><div>I oppose the replay protection part. As Satoshi stated, the only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what [1]. With the support of majority hashrate, Bitcoin (SegWit2x) shall be seen as an update, without any doubt. According to the forks history of Bitcoin, no update added replay protection. If someone or certain group plan to issue an altcoin before or after the update, and if they believe they can gain majority hashrate in the future with the help of censorship, the burden of adding replay protection is on them. We have no reason to care about if they have anti-HF ego or if it&#39;s only an excuse.</div><div><br></div><div>It&#39;s exciting to see Bitcoiners who defended Bitcoin in front of CIA and NYDFS come together to defend Bitcoin (SegWit2X) again. Some people might have negative impression on Jihan Wu due to smear campaign they read, yet the censor won&#39;t tell you the fact that it&#39;s Jihan who firstly translated Bitcoin White Paper into Chinese.</div><div><br></div><div>Bitcoin (Segwit2X) is certainly not perfect and that&#39;s exactly why this mailing list exists. Some trolls were actually wasting their time in the hope of persuading us with the misinformation they &#39;learned&#39; under censorship [2]. I agree with Mike Belshe. If everybody comes here to state what they believe just to be told it is incorrect, we aren&#39;t going to have a very high noise to signal ratio. If those trolls really care about Bitcoin as they claimed, please help this project become more perfect and more successful by being constructive. </div><div><br></div><div>Cheers.</div><div><br></div><div>Junyi</div><div><br></div><div><br></div><div>[1] <a href="http://satoshi.nakamotoinstitute.org/quotes/nodes/">http://satoshi.nakamotoinstitute.org/quotes/nodes/</a></div><div><br></div><div>[2] <a href="https://www.youtube.com/watch?v=0Fe6HbNdbrA">https://www.youtube.com/watch?v=0Fe6HbNdbrA</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 10, 2017 at 12:07 PM, Sjors Provoost via Bitcoin-segwit2x <span dir="ltr">&lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">bitcoin-segwit2x@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><br><div><blockquote type="cite"><div>Op 10 okt. 2017, om 16:11 heeft Jeff Garzik via Bitcoin-segwit2x &lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>&gt; het volgende geschreven:</div><br class="m_-5858279628907671330Apple-interchange-newline"><div><div dir="ltr">All,<div><br></div><div>This is not an extension of social media.  This is a technical mailing list for discussions related to segwit2x.</div><div><br></div><div>It is self-evident that (1) _not_ upgrading past 1M base block size has been contentious and does not have consensus, and (2) the segwit-only path did not have consensus.  segwit2x solves these problems.</div><div><br></div><div>If there are technical suggestions, please send a technically-specific email or file a PR at github.</div></div></div></blockquote><br></div></span><div>I really like RFC 7282 as it suggests a more precise definition of technical rough consensus than what I see on this list. In particular it distinguishes between technical objections and non-technical objections. I assume you&#39;re referring to that when saying &quot;consensus&quot;. If not, let me know, so we&#39;re on the same page with regards to the expected process.</div><div><br></div><div>It is my understanding that only miners objected to the SegWit-only path (2) and that they did so without technical arguments. RFC 7282 explicitly addresses situations like that and states that such non-technical objections should be ignored. More precisely, it suggests insisting the miners communicate their technical objections (though perhaps not on this list, as it&#39;s too late for that).</div><div><br></div><div>It also cautions against the use of polls to measure the level of (dis)agreement, which cuts both ways here.<div><br></div><div>This RFC makes no guarantees that things move quickly and defaults to doing nothing.</div><div><br></div><div>It has a bias towards a more complex solution, when this addresses all issues raised against the simpler solutions, e.g. initial size increase via SegWit soft-fork and various wallet upgrades, rather than just a consensus HF.</div><div><br></div><div>It has a bias towards slower deployments and no hard deadlines, since fewer people believe those to be unsafe. Hence Spoonnet HF at some ill defined time in the future, vs. a specific time commitment that SegWit2x signatories would prefer.</div><div><br></div><div>This can be quite frustrating. People might even see it as a fatal flaw, still others see it as a strength.</div><div><br></div><div>My impression of the SegWit2x deal is that it (temporarily and selectively) abandons RFC 7282 in favor of making progress (in the eyes of its participants).</div><div><br></div><div>More important than a size increase, at least to me [1], is that I see this pattern at a more detailed level. There are many unanswered questions about the precise workings of a contentious hard-fork. Specific technical objections against pull requests were raised, but not addressed. These PR&#39;s were merged despite that, again for the sake of expediency. The re-opening of the replay attack issue is a good example; it should not have been merged (yet), given that the objections cited for reopening it were raised before the merge. If these objections had been addressed before the merge, there would have been no need to reopen it.</div><div><br></div><div>As much as I&#39;m in favor of good replay protection (opt-in both ways at minimum), changing consensus rules five weeks before a hard-fork seems quite dangerous. There&#39;s a high likelihood of some critical security bug not getting detected in time. There&#39;s even some political and economic incentive to withhold such vulnerabilities until the last moment (e.g. to speculate on BT2 tokens). In addition future scaling work might be hindered, although sunset code could help with that.</div><div><br></div><div>Another process issue to think about, is that although a code freeze was scheduled for some time ago, there wasn&#39;t a clear fallback plan for when issues were found after the freeze. For example, a good policy could be to postpone the fork to at least N months after any new issue is found. The current deal doesn&#39;t provide room for this, which I think people pointed this out from day one. It&#39;s probably unwise to set a date in stone before a proposal and working code are fully fleshed out and thoroughly reviewed and tested. It prevents conundrums like having to choose between (a) sticking to the code freeze and not adding replay protection, (b) rushing it in and risking a zero-day or (c) renegotiating a HF block that miners are already signaling for.</div><div><br></div><div>Sjors</div></div><br><div>[0] <a href="https://tools.ietf.org/html/rfc7282" target="_blank">https://tools.ietf.org/html/<wbr>rfc7282</a> (HT Rusty Russel)</div><div>[1] this may be my own bias, as it&#39;s easier for me to understand these specific problems whereas the scaling debate is quite complex </div></div><br>______________________________<wbr>_________________<br>
Bitcoin-segwit2x mailing list<br>
<a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>segwit2x</a><br>
<br></blockquote></div><br></div></div>