[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Melvin Carvalho melvincarvalho at gmail.com
Wed Oct 11 13:06:21 UTC 2017


On 11 October 2017 at 14:27, Junyi Li via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

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

IMHO this is a misunderstanding of Satoshi's quote.

The longest chain is specific to a given protocol, and a given genesis
block.  The purpose is simply to synchronize a given network and avoid race
conditions associated with double spending.

If protocols diverge, as is the case of a hard fork, the length of the
chain become irrelevant.  For example ethereum, or litecoin, or some sha256
alt coin, or even a copy of bitcoin with a different genesis block could
have more provable length (ie implied hash power) and yet be a different
entity.

About all you can say is that for a given protocol, and a shared history,
nodes will work on the longest one that it knows.

It would be absurd to argue that if a sha256 fork of bitcion (eg peercoin)
for some reason got more hashing, it would become bitcoin.

History has shown that there have been over 1000 forks of bitcoin core, and
yet it has always remained the dominant.  This is true measurable
consensus.


>
> 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
>>
>>
>
> _______________________________________________
> 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/f49b69e8/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list