Anti-replay / Replay protection

[chjj]

@gavinandresen's anti-replay patch carries with it the benefit of preventing the 1mb chain from ever reorging the 2mb chain. As soon as an OP_RETURN [segwit2x] transaction is mined on the 1mb chain, the 1mb chain is now invalid in the eyes of the HF code. I think this should be implemented for both anti-replay and anti-reorg benefits.

While Gavin's anti-replay is probably the simplest, it's worth mentioning that @jl2012 also had a clever way of preventing replays on spoonnet: a special tx version bit enforces segwit-style sighashing for even non-segwit inputs (a nice perf boost to boot), but this is a bit trickier, since it has a higher chance to invalidate existing pre-signed transactions, and requires more to implement in wallets (especially hardware wallets).

Thoughts?

[RHavar]

Probably the simplist wipeout protection is to just require that the first block of the HF is to have a blockweight > 4M and <= 8M

[jmprcx]

@RHavar https://github.com/btc1/bitcoin/pull/35

With that above commit there will be no risk of a re-org since it enforces a large block at a certain block index...I'm still catching up here but how come OP_CHECKBLOCKATHEIGHT isn't suggested as a solution?

[jgarzik]

@joshuayabut I'm a personal fan of OP_CHECKBLOCKATHEIGHT (though that's outside the scope of segwit2x)

[RHavar]

One idea (and totally out of scope) I had was to use the block hash of the nLock of a transaction to sign inputs (similar to how segwit uses the amount). You could opt out of it by setting the transaction nLock to 0, and if you want to time lock a transaction in the future, you'd have to use a future time and not a block number.

The benefit would be that all transactions by default would be very replay resistant (since they're only valid on a specific chain) while being no bigger in actual size. It would also make selfish mining and reorg attacks less profitable.

But it'd bring in a fair bit of complexity, and probably has quite a few downsides I haven't thought of.

[earonesty]

We could just reject all non segwit tx. That way malleability is fixed for good. Since we're bothering to hard fork anyway... might as well reject pesky legacy transactions.

[JaredR26]

There are probably valid use cases that benefit from malleability. Unless we're sure that there are not and that segwit is rock solid, we wouldn't want to do that. Maybe after a few years when we have more data showing the uses, support, and risks.

[robbak]

We can't just drop legacy transactions. A stated use case of bitcoin was locking away funds until a future time with nlocktime. So people who have locked funds up using that method need to be able to get their legacy transactions mined whenever they become valid - so current transactions need to remain valid. Such a pity that the original transaction format had such an annoying bug.

[earonesty]

Too bad nlocktime isn't part of the signature.

On Jul 16, 2017 6:17 AM, "robbak" notifications@github.com wrote:

We can't just drop legacy transactions. A stated use case of bitcoin was locking away funds until a future time with nlocktime. So people who have locked funds up using that method need to be able to get their legacy transactions mined whenever they become valid - so current transactions need to remain valid. Such a pity that the original transaction format had such an annoying bug.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/btc1/bitcoin/issues/34#issuecomment-315599552, or mute the thread https://github.com/notifications/unsubscribe-auth/AADGUXt2beX-Unlf7baarrKwTEa_6CUcks5sOeNRgaJpZM4N_1RZ .

[jprupp]

nLockTime is not part of the signature, but it is part of the pkScript, and a pkScript is spent by a sigScript, not by a witness. A somewhat-disruptive hard-fork rule could allow a witness to spend a legacy pkScript, but that's not currently on the table.

[jgarzik]

Changing Issue title to focus more narrowly on just the replay protection issue, since wipeout protection was already added.

Replay protection remains an issue of much discussion throughout the community.

To reiterate, opt-out replay protection creates chain splits and goes against the goal of remaining one chain.

Opt-in replay protection, such as the @gavinandresen example in @chjj 's OP, seems like something we could merge.

[booung]

@jgarzik I think btc1 should consider a chain-split a very real possibility. Or will btc1 abandon the project if it looks like it may cause a split as that goes against the goal of remaining one chain?

I just checked https://coinmarketcap.com/exchanges/volume/24-hour/ compared to https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77 and only 4 of the top 20 exchanges have committed to the NYA and there is also this list http://nob2x.org/. I know most of these businesses haven't said they wont follow btc1 but that's far from committing to it. As its a HF they will need to upgrade/change code and are therefore currently incompatible with btc1 and will cause a split (apologies if I have this wrong)

https://cash.coin.dance/blocks/thisweek shows bitcoin.com, BTC.com, Antpool, BitClub, and ViaBTC are all now mining another chain. These companies all signed the NYA but are now mining something else proving that hashpower can change and (used by itself) may not be a good measure for consensus.

I have heard argument for core to implement replay protection but this doesn't make sense as they are not the ones doing the HF that requires an update.

Also there doesn't seem to be many poeple running btc1 yet https://coin.dance/nodes is this accurate?

@jgarzik @chjj @jameshilliard @SergioDemianLerner Would be great to get some feedback on this thanks.

[rodasmith]

It's starting to look like replay protection may not be needed for the NYA 2 MB activation in November. We may not even have to fork! At https://github.com/NYAcoin/bitcoin/issues/1 the idea is to implement replay protection only at a later date when ~4 MB blocks are needed. For now we can get to ~2 MB with SegWit, so we don't even need to fork in November!

[NiKiZe]

@booung simple correction:

https://cash.coin.dance/blocks/thisweek shows bitcoin.com, BTC.com, Antpool, BitClub, and ViaBTC are all now mining another chain. These companies all signed the NYA but are now mining something else proving that hashpower can change and (used by itself) may not be a good measure for consensus.

These are mining pools, which are now also mining Bitcoin Cash due to high user demand, but they (as companies) are still dedicated to NYA. Just to mention one easy to find statement: https://www.bitcoin.com/public-service-announcement

btc1 nodes are not the only ones that accept >1MB blocks, and are also not the only ones enforcing the rules needed for Segwit2x, With little more then 50% of the miners enforcing >1MB block this is enough since 1MB+ accepting nodes will be just fine.

This is something that have been asked over and over again - so I suggest reading the responses that already exists.

[booung]

These are mining pools, which are now also mining Bitcoin Cash due to high user demand, but they (as companies) are still dedicated to NYA. Just to mention one easy to find statement: https://www.bitcoin.com/public-service-announcement

Thanks, yes that's my point, miners follow user demand. As they are doing with bitcoin cash they can also do to the core chain. Bitcoin cash did the responsible thing and implemented replay protection.

As I mentioned only 4 of the top 20 exchanges have signed to run btc1. Here https://www.btcc.com/news/en/announcements/2017/03/18/hard-fork-statement/ is a statement from some of the exchanges from the previous BU hardfork attempt. Obviously a different situation but shows exchanges like replay protection.

It's possible (likely imo) btc1 doesn't have the consensus its needs to pull of the HF without creating a split so replay protection should be implemented if its going ahead.

[Pheromon]

The NYA was only a charade to let segwit happen.

The only way to make a block increase successfull would have been to hard fork to 2MB together with the activation of segwit, and this has been repeated by me and others ad nauseam.

Now that we have Bitcoin Cash the need for this fork is not needed anymore, farewall for the (few) people that in good faith thought that the NYA could work.

[pekatete]

I apologise in advance if this is meant to be a strictly technical discussion.

I have heard argument for core to implement replay protection but this doesn't make sense as they are not the ones doing the HF that requires an update.

You comprehensively misunderstand this.

1. The 2MB HF of SegWit2x is an upgrade to Bitcoin, Moreover, the upgrade was locked-in by majority network hash (over 85%).
2. Core refusing to merge the consensus rules upgrade (and partitioning the network with the 0.15 release) is effectively a HF off the Bitcoin network BUT with minority hash (not unlike the Bitcoin Cash fork).
3. The NYA seeks to avoid a split, which implementing (mandatory / opt out) RP would encourage, and should rightly persue this goal perpetually.

It is therefore incumbent on core, as the minority chain forking off Bitcoin (not unlike Bitcoin Cash which they applauded for implementing RP), to implement RP and not btc1

[Mashuri]

Disclaimer: I am not a lawyer nor do I represent anyone legally. This is not legal advice. Please consult a lawyer and perform your own due diligence before coming to any legal conclusions. There are serious legal issues to consider here. Causation ( https://en.wikipedia.org/wiki/Causation_(law) ) is a cornerstone of law when determining what parties are responsible for particular situations. If a chain split happens, then the parties who actively created the conditions that enabled the split are legally viewed as responsible. Being passive (not doing anything) typically legally exempts one from any responsibility. In this situation, it would be the parties involved with the btc1 project who are actively creating the conditions for a chain split -- and currently with no replay protection for users. This puts anyone who chooses to adopt btc1 into potentially serious legal trouble. Exchanges and payment processors in particular could be targets of damaging lawsuits and/or criminal charges. Replay protection not only protects users on both chains from financial loss / fraud, but also a myriad of legal problems.

[earonesty]

IMO, replay protection guarantees that there is no chance that btc1 will ever be called "Bitcoin" by anyone. In order to "be bitcoin", SPV users should not have to upgrade their code. If protections are added, then we just get "B2X coin".

On Mon, Aug 21, 2017 at 12:51 PM, Mashuri notifications@github.com wrote:

Disclaimer: I am not a lawyer nor do I represent anyone legally. There are serious legal issues to consider here. Causation ( https://en.wikipedia.org/wiki/Causation_(law) ) is a cornerstone of law when determining what parties are responsible for particular situations. If a chain split happens, then the parties who actively created the conditions that enabled the split are legally viewed as responsible. Being passive (not doing anything) typically legally exempts one from any responsibility. In this situation, it would be the parties involved with the btc1 project who are actively creating the conditions for a chain split -- and currently with no replay protection for users. This puts anyone who chooses to adopt btc1 into potentially serious legal trouble. Exchanges and payment processors in particular could be targets of damaging lawsuits and/or criminal charges. Replay protection not only protects users on both chains from financial loss / fraud, but also a myriad of legal problems.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/btc1/bitcoin/issues/34#issuecomment-323796938, or mute the thread https://github.com/notifications/unsubscribe-auth/AADGUbJ_ZUjKO2adcEjTPjdm_Ryn_pWuks5sabWfgaJpZM4N_1RZ .

[jgarzik]

This issue is for discussing the technicals of an implementation that would work for segwit2x.

The goal of segwit2x is to upgrade Bitcoin - to be Bitcoin - not create an altcoin.

[Mashuri]

My concern deals with that very issue. Exchanges and payment processors will not want to subject themselves to legal risk. How can segwit2x "become" bitcoin when their participation is so heavily disincentivized?

[JaredR26]

If a chain split happens, then the parties who actively created the conditions that enabled the split are legally viewed as responsible.

Good luck suing Bitcoin.

If what you say were true, Bitcoin Core could be liable for removing Bitpay from bitcoin.org. I already thought about that, and if it were feasible to do so, Bitpay should sue them. It isn't possible unless they have standing, the proper jurisdiction, bitcoin.org would have had an obligation to Bitpay, and there must be damages calculable.

No standing without claiming ownership over btc1/Bitcoin, which no one can.

Bitcoin doesn't have a jurisdiction.

There's no obligations implicit in using Bitcoin, or in Bitcoin.org.

While Bitpay might be able to measure damages, CoreCoin's split could not. Users have a responsibility to take prudent actions to mitigate their damages prior to being able to claim them. As core themselves have repeatedly stated regarding BIP148(And BCH), coins can be split without replay protection.

No standing... No jurisdiction... No obligations... No unmitigable damages... No lawsuit possible. You're not actually a lawyer, are you?

[JaredR26]

My concern deals with that very issue. Exchanges and payment processors will not want to subject themselves to legal risk.

Please explain the standing, jurisdiction, what obligations exchanges owe to Bitcoin/Core, and the unmitigable damages that represent such a risk.

[Mashuri]

JaredR26,

No major exchanges declared they would adopt a BIP148 split chain either for obvious reasons. The concern is not "suing bitcoin". It's the identifiable participants, like exchanges and payment processors, who are vulnerable. If they choose to run code that can cause financial damage to parties they do business with, they can be held liable. Don't kid yourself.

[JimHarperDC]

I am a lawyer, and I differ with @Mashuri's take on the application of the law. In brief (because @jgarzik just cautioned about keeping things technical!), you have got to have a theory of liability before you go into causation, which examines the extent to which the breach of a duty or obligation caused an injury.

Is there a contract? Almost certainly not. Is someone being defrauded? No. (Fraud is deception intending financial gain, not failing to cure others' ignorance.) Is there a general duty on the part of FOSS devs to provide some level of protection to users of the software that results from their efforts? That's the most plausible legal theory, but I think it's still not a strong one, and nobody should want it to be because devs would drop off of projects en masse.

Here's a Twitter conversation from a few years back that explores some of these issues: https://twitter.com/Jim_Harper/status/633123290261921792

I think legal liability shouldn't be a concern of FOSS developers. Carry on! (But, of course, I must add that I am not giving you advice! Consult your own member of the attorney cartel!)

[JaredR26]

IMO, replay protection guarantees that there is no chance that btc1 will ever be called "Bitcoin" by anyone.

It already is. Sorry if you don't like it.

In order to "be bitcoin", SPV users should not have to upgrade their code.

Correct, which is why weren't not breaking compatibility with them, especially since they are not affected by the only consensus change being made in this codebase.

If protections are added, then we just get "B2X coin".

I find it rather funny that this issue has been brought up no less than 10 times, and this issue has been open for 20 days, yet we still don't have any discussion or a pull request for the thing that was found acceptable - an optional replay protection mechanism.

If this really were all about protecting the users as claimed, this would have been done at least... no? Why not? We even have someone trying to create a fork that isn't compatible instead after being told it would not be accepted... How odd... Maybe it isn't really about protecting the users, maybe it's about trying to protect something else instead?

[JaredR26]

If they choose to run code that can cause financial damage to parties they do business with, they can be held liable.

Then this would be governed by their terms of service, no?

That's easily handled on a business by business level. It doesn't warrant protocol-level discussion.

[mjamin]

SegWit2x has no future other than to become an altcoin. Might as well make the split as safe as possible for everyone involved.

The core project will not be coerced to merge SegWit2x's changes without sound reasoning. Core however will move full speed ahead while SegWit2x is stuck on 0.14. This project doesn't have the power to keep up.

What you have is a several months old, non-binding agreement that's starting to fall apart in light of bcash. An agreement among businesses and miners, trying to decide for their customers and the rest of the bitcoin userbase. An agreement that sets a very bad precedence. "Why do we want to hard fork? Because our group agreed on doing that."

But I guess "It is difficult to get a man to understand something, when his salary depends on his not understanding it."

[Mashuri]

JimHarperDC: Would you say there is more or less legal risk for exchanges to run a fork without replay protection? At the very least, would you say there is more or less chance for relatively higher legal expenses for exchanges that run a fork without replay protection?

[jgarzik]

@JaredR26 TBF, there is a patch linked in the OP :) Just needs some unit tests written.

[jgarzik]

@Mashuri Off topic.

If non-technical discussion continues, the issue will be locked for 24 hours, then unlocked.

[JaredR26]

The core project will not be coerced to merge SegWit2x's changes without sound reasoning

They don't have to. As Core is fond of saying so frequently, users have a choice.

Core however will move full speed ahead while SegWit2x is stuck on 0.14.

??? Core's changes can be merged here, after removing obvious attacks on the correct Bitcoin majority fork.

What you have is a several months old, non-binding agreement that's starting to fall apart in light of bcash

Pools are giving their users a choice. None have changed their default settings to support Bitcoin Cash.

An agreement among businesses and miners, trying to decide for their customers and the rest of the bitcoin userbase.

Core is literally doing the EXACT SAME THING. Congrats on highlighting Core's hypocrisy.

This agreement has broad support across the rest of the community in uncensored forums.

An agreement that sets a very bad precedence. "Why do we want to hard fork? Because our group agreed on doing that."

No, because this was the only way to get Core's unpopular decisions to pass so Bitcoin could make progress. Don't blame us for Core's unpopular decisions.

[JaredR26]

TBF, there is a patch linked in the OP :) Just needs some unit tests written.

Ah, I stand corrected. Still, I don't see any action from those demanding replay protection on the issue. :(

[jrallison]

Thought we were keeping this repo for technical discussion only?

Can the owners of this repo ban JaredR26 and others who have yet to provide any technical discussion (across who knows how many comments...) and just wish to spout their political babble over and over?

On Mon, Aug 21, 2017 at 12:32 JaredR26 notifications@github.com wrote:

TBF, there is a patch linked in the OP :) Just needs some unit tests written.

Ah, I stand corrected. Still, I don't see any action from those demanding replay protection on the issue. :(

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/btc1/bitcoin/issues/34#issuecomment-323805297, or mute the thread https://github.com/notifications/unsubscribe-auth/AABTTmtW0peSwClzyXXXYLdgEsC114VDks5sab89gaJpZM4N_1RZ .

[JaredR26]

JaredR26 and others who have yet to provide any technical discussion (across who knows how many comments...) and just wish to spout their political babble over and over?

I love how I get called out every time, despite quoting, piece by piece, what I'm responding to. If people didn't come in here and start political discussions about support levels or failure or "what is Bitcoin" it wouldn't need to be responded to. But if it is left alone, uninformed users would be even more confused after the censorship we've seen from Theymos & Co.

[jgarzik]

This applies to segwit2x supporters too :) Locking for 24 hours to cool down, then unlocking.

[sturles]

@jgarzik The NY agreement point two says:

o Activate a 2 MB hard fork within six months

This hard fork will be an altcoin, just like BCH and other hard forks of Bitcoin. Pretending it is not is cute, but you know better. I can't be selling S2X or BCH to my customers, pretending it is Bitcoin. I would get sued out of this Universe! And I can't afford to pay BTC prices for BCH or S2X. That would break my back economically. The hashrate of each chain is irrelevant. BCH and BTC won't switch names the minute BCH hashrate becomes higher than BTC hashrate, which is likely to happen many times.

The risk now is that all of the coins will get hurt by the wild hashrate swings resulting from the lack of merged mining. (With the exception of ASICBoost style half-merged mining of BTC and S2X until the first difficulty adjustment.) To avoid this, btc1 could implement merged mining, as NMC did when the same happened to them in 2011.

The agreement goes on:

We are also committed to the research and development of technical mechanisms to improve signaling in the bitcoin community, as well as to put in place communication tools, in order to more closely coordinate with ecosystem participants in the design, integration, and deployment of safe solutions that increase bitcoin capacity.

There is absolutely nothing safe in the way btc1 attempts to hard fork. There are several independent implementations of the NYA, and for now it seems only btc2x and NYACoin are doing it safely. I will recommend everyone to use one of those instead of btc1, because those are the only versions supportable by exchanges. AFAIK miners signed to the NYA, not to a specific unsafe implementation of only a part of the agreement.

[mjamin]

@JaredR26

They don't have to. As Core is fond of saying so frequently, users have a choice.

Yes, and without going into any numbers, it's fair to say that a significant chunk of users won't choose your implementation, no matter what.

If you truly believe that users have a choice, then honor that by adding replay protection.

??? Core's changes can be merged here, after removing obvious attacks on the correct Bitcoin majority fork.

They can, but probably won't as this is a lot of work. Jeff already stated somewhere that for the time being, S2X will probably remain on the 0.14.x branch and maybe cherrypick some essential stuff from later core releases.

Core is literally doing the EXACT SAME THING.

Absolutely not and I have no idea where you get that from.

This agreement has broad support across the rest of the community in uncensored forums.

sigh

No, because this was the only way to get Core's unpopular decisions to pass so Bitcoin could make progress. Don't blame us for Core's unpopular decisions.

You have a very distorted view of reality. Core's decisions are mainly unpopular among a very small group of miners and conspiracy theorists.

[Pheromon]

There is absolutely nothing safe in the way btc1 attempts to hard fork If there is >90% miner support it's as safe as it can be.

[sturles]

@Pheromon 40% is already mining on a different chain. AFAIK just a few pools have signed the NYA, which says something different than what btc1 implements. I don't think anyone expects the pools to be able to convince all their miners to break the NYA and mine btc1 instead. Miners want ROI and profit, and i doubt they will be very faithful to pools trying to minimize their profit.

[jcansdale]

There are several independent implementations of the NYA, and for now it seems only btc2x and NYACoin are doing it safely.

Let's have a look at those independent implementations: https://github.com/NYAcoin/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr https://github.com/btc2x/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr

[chrisrico]

If people didn't come in here and start political discussions about support levels or failure or "what is Bitcoin" it wouldn't need to be responded to.

What a perfect analogy for btc1. @JaredR26, you blame others for your comments, just as you blame Core for not merging your hasty and poorly thought out hard fork. How about even the tiniest amount of self awareness and personal responsibility?

[rodasmith]

We are not yet ready to implement replay protection in NYAcoin because we first have to complete the analysis of the costs and benefits of a hard fork to 4 MB blocks. https://github.com/NYAcoin/bitcoin/issues/5 If it turns out that 2 MB blocks on a single chain is preferable, then our recommendation will likely be not to fork.

I invite both of the other independent teams of developers to issue any guidance on what details to cover in that review and to propose a process by which signatories could review and either ratify or reject the hard fork.

[phzi]

Let's have a look at those independent implementations: https://github.com/NYAcoin/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr https://github.com/btc2x/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr

You could use compare? https://github.com/btc1/bitcoin/compare/segwit2x...btc2x:segwit2x https://github.com/btc1/bitcoin/compare/segwit2x...NYAcoin:segwit2x

I'd say both are actually relevent, having reviewed the fairly minor but important changes (README/doc changes and setting the hardfork bit).

[JaredR26]

It seems like this thread has devolved into pure politics, and any attempt to correct the misinformation and poorly-supported claims would only make the problem worse.

Until Core implements mandatory replay protection for their fork, there's no point in discussing it here, as it will not happen. The onus is on the requestor and the non-sybilable, measurable minority.

Does anyone want to make any actual technical suggestions or comments about opt-in replay protection methods?

[sturles]

@JaredR26 Core is ambigous. This project claims to be Bitcoin Core as well. See the readme on top of the repository.

Bitcoin Core, as in the original Bitcoin project started by Satoshi Nakamoto, already has mandatory replay protection. It has had replay protection from the beginning. Instead of changing a constant, btc1 has copied this replay protection exactly, to force the transactions to be valid on the hard forked chain as well. There is nothing Bitcoin can do to stop btc1 from doing this. This is the technical facts, and I guess politics stops the btc1 Bitcoin Core project from implementing protection, in spite of the NY agreement's clear statement that the hard fork should be safe. That makes it a political discussion.

To exchanges replay protection is a very important property, and probably the reason why only four exchanges have stated they are going to support S2X at all.

[JaredR26]

This project claims to be Bitcoin Core as well.

Redefinition debates help no one. The people requesting replay protection are free to implement replay protection on their fork of choice.

and probably the reason why only four exchanges have stated they are going to support S2X at all.

Not sure where you read that, I count 16 just from signatories to the agreement.

[NiKiZe]

NYA must be compatible with existing clients, meaning all clients that isn't hard limited to blocks of 1MB or less.

~40% of total hashrate is right now pointing to a different chain (it is around 43% Bitcoin Cash and 57% main source: http://fork.lol/pow/hashrate) and despite that 90% of the current hashrate on the main chain still intends to support Segwit2x (source: https://coin.dance/blocks)

[is55555]

NYA must be compatible with existing clients, meaning all clients that isn't hard limited to blocks of 1MB or less.

I'm sure you understand that compatibility in consensus rules means more restrictive rules, not less. You sounded there like you had it completely backwards.

[felipelalli]

@jgarzik stop with this 2x bullshit and become a hero.

[phzi]

@JaredR26 btc1 is not NYA. Calling it NYA is a political act on your part. Some would argue that NYA agreement has actually already been 100% fulfilled after the creation of bcash, or even that we now have the ability for 2+MB blocks with segwit. The numbers of ways to interpret the terms of the NYA are pretty wide to say the least.

This branch is the forking client. Trying to claim that "bitcoin core" or whatever you feel like calling the existing chain is the one "forking" is utterly ridiculous. If old/existing clients on the network diverge, as is the case with btc1, then it is very clearly the divergent branch that is responsible for providing replay protection, and any attempt to obfuscate that is simply untenable. Over in Ethereum world, when there was a contentious fork, proponents for ETC and Eth argued exactly the same thing AFTER the fact - that the other should fork again and add replay protection; that turned into a great mess. That certainly looks a LOT like this fork here... adding replay protection to the Eth hard-fork would have saved a LOT of headaches. How are we not learning that experience here?

If you're implementing an incompatible change, as this branch plans, it is simply irresponsible not to implement strong replay protection. Period.