[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Wed Oct 11 12:27:06 UTC 2017

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'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.

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.

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.

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 'No fork' is more dangerous than SF and HF.

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's only an excuse.

It'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't tell you the fact that it's Jihan who firstly translated
Bitcoin White Paper into Chinese.

Bitcoin (Segwit2X) is certainly not perfect and that's exactly why this
mailing list exists. Some trolls were actually wasting their time in the
hope of persuading us with the misinformation they 'learned' 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'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.

Cheers.

Junyi

[1] http://satoshi.nakamotoinstitute.org/quotes/nodes/

[2] https://www.youtube.com/watch?v=0Fe6HbNdbrA

On Tue, Oct 10, 2017 at 12:07 PM, Sjors Provoost via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

>
> Op 10 okt. 2017, om 16:11 heeft Jeff Garzik via Bitcoin-segwit2x <
> bitcoin-segwit2x at lists.linuxfoundation.org> het volgende geschreven:
>
> All,
>
> This is not an extension of social media.  This is a technical mailing
> list for discussions related to segwit2x.
>
> 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.
>
> If there are technical suggestions, please send a technically-specific
> email or file a PR at github.
>
>
> 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're referring to that when saying "consensus". If not, let me
> know, so we're on the same page with regards to the expected process.
>
> 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's too late for that).
>
> It also cautions against the use of polls to measure the level of
> (dis)agreement, which cuts both ways here.
>
> This RFC makes no guarantees that things move quickly and defaults to
> doing nothing.
>
> 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.
>
> 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.
>
> This can be quite frustrating. People might even see it as a fatal flaw,
> still others see it as a strength.
>
> 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).
>
> 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'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.
>
> As much as I'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's a high likelihood of some critical security bug
> not getting detected in time. There'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.
>
> Another process issue to think about, is that although a code freeze was
> scheduled for some time ago, there wasn'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't provide room for this, which I think people pointed
> this out from day one. It'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.
>
> Sjors
>
> [0] https://tools.ietf.org/html/rfc7282 (HT Rusty Russel)
> [1] this may be my own bias, as it's easier for me to understand these
> specific problems whereas the scaling debate is quite complex
>
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171011/0bb6c538/attachment.html>