BU should take a stance against "anti-replay" measures.

[priestc]

There has been much talk in Core circles about "fixing the replay attack". The replay *effect*, (not "attack") is a good force within the network and should not be seen as an attack. The real network is the one with the majority hashpower, any other network that claims to be that network is a fake clone. Any user using the minority network is a scam victim. The BU project should be against any project that that claims to be "bitcoin" despite not being the majority hashpower. "Anti-replay" technologies have one purpose: to allow for the existence of a minority scam coin.

There are two forms of anti-replay technologies that I know of. One is "tainting", and the other is "OP_CHECKBLOCKATHEIGHT". Both of these schemes can and should be twarted BU's code.

Twarting "OP_CHECKBLOCKATHEIGHT" is easy, just ignore the rule. So if a user "intends" to only allow their TX to be recorded into the minority scam chain, the majority chain will record the TX regardless.

Twarting tainting is a little bit more complicated, but also possible. When someone tries to move coinbase from a block on the minority chain, then that tx will not be recorded on the majority chain. Any coins that try to move that are derived from some pre-fork inputs and some post-fork inputs will be recorded, but with the post-fork balance subtracted.

The reason why it is so important to record transactions made by users intending to only have their transactions recorded on the minority chain is as follows:

1. The minority chain is bound to fail. It won't fail immediately, but it will once people realize the alternate vision of Bitcoin (LN, sidechains, etc) are finally realized are not feasible. If we record all their transactions, those users will have their balances restored when they move back to the majority chain.

2. The users who ascribe to this vision do not deserve to lose their coins, as they are victims of misinformation.

One more thing I want to mention: This stance only applies to the hard fork resulting from a capacity increase (removing 1MB max blocksize). In the future if another hard fork occurs, replay protection may be a legitimate solution. Stances like this (regarding changing consensus rules) should be taken on a case by case basis, and are not set in stone to be applicable for every single future situation.

 

[AdrianX]

@adamstgbit I haven't processed this or your last comment but will have a read when I'm a little more able, given you last post I wondered what you thought of these developments.

 

[adamstgbit]

I agree with @priestc the replay effect isn't worth much consideration, not for the majority fork anyway. by definition the majority fork is bitcoin and it should view any other fork as INVALID therefore not worth considering.

if the majority fork codes in some anti-replay, this gives validity to the other fork(s), which might be fine...

its ODD that core is talking about helping minority forks happen more smoothly... I mean they say "HF are dangerous because it might split the network" and then they go an make splitting off the network easier?!

 

[freetrader]

I see a couple of things in OP's post which I consider flaws in logic.
Of course I'm biased here, after all I'm developing on a project (BTCfork) which is all about making minority forks (spin-offs) viable and safe, as potential mechanism for hardfork-based upgrades to the currency. And obviously I've endorsed "replay protection" in the past, and continue to do so.

However, I will attempt to show reasoning for all my counterarguments to OP , so that you can at least see where my bias derives from.

There has been much talk in Core circles about "fixing the replay attack".

Core were eager to demonize the "replay attack" and hard forks when it was a minor problem for ETH/ETC. I didn't see much public discussion around this topic from them at all until Luke-jr's recent bip-noreplay. There were some subdued references to Luke paying attention to this in the California transcripts, but if OP says there has been "much talk in Core circles", then I sure haven't seen it, but maybe that's because I don't travel much in Core circles. Links to the extensive discussions there would be appreciated.

The replay *effect*, (not "attack") is a good force within the network and should not be seen as an attack.

Let's call this a postulate, and see what logic is offered up behind it:

The real network is the one with the majority hashpower, any other network that claims to be that network is a fake clone. Any user using the minority network is a scam victim.

It seems the entirety of the argument presented here is: a minority that wishes to diverge is a scam or 'fake'. This is the moral high ground fallacy described in [3] - not a rational argument.

I reject this - there are legitimate scenarios (even today) in which the majority hashing power could become compromised. I can talk more about those if anyone doesn't see them.

However, for a long time since [1], it looked like such a scenario had already materialized.
Centralized control of development, hashrate centralized in China with miners making deals with the devs which would get them the "benefit of killing the competition" (Classic at the time) [2].
The only thing that convinced me that this had not played out successfully was the ensuing rise of the BU project and its increase in popularity even among miners (today still a minority - are you going to call them scammers?)

Twarting tainting is a little bit more complicated, but also possible. When someone tries to move coinbase from a block on the minority chain, then that tx will not be recorded on the majority chain. Any coins that try to move that are derived from some pre-fork inputs and some post-fork inputs will be recorded, but with the post-fork balance subtracted.

I am not sure how you envision this working technically without completely breaking transaction validation in the process.

A tainted transaction from the minority chain could not be validated on the majority chain since there is no way to resolve those coinbase inputs - the majority network doesn't want to know about the minority blocks and couldn't possibly track all other forks that might exist.
This hypothesized defense against tainting seems technically unworkable to me, though I'd be glad to hear OP (or anyone else) try to argue it in depth.

The reason why it is so important to record transactions made by users intending to only have their transactions recorded on the minority chain is as follows:

1. The minority chain is bound to fail. It won't fail immediately, but it will once people realize the alternate vision of Bitcoin (LN, sidechains, etc) are finally realized are not feasible. If we record all their transactions, those users will have their balances restored when they move back to the majority chain.

2. The users who ascribe to this vision do not deserve to lose their coins, as they are victims of misinformation.

re 1. : *generally* unfalsifiable claim as it invokes the infinite future, but as long as ETC hangs around, it's false for the time being.

re 2. : I will argue that the users who wish to transact only on the minority coin are making the conscious, informed decision to do so under the premise that they are able to transact freely and independently on these different currencies (whichever one gets the 'Bitcoin' name is speculative and will depend on market forces).

I am not aware of covert attempts to build in anti-replay protections.
Certainly BTCfork's work is public, as is Luke-jr's 'bip-noreplay' work.

There is one argument I will buy which holds against such protective measures, and it is one I have discussed in the past on BU slack with Justus Ranvier and others. However, it does not any require misinformation or deception, and therefore I argue that point #2 above is a false conclusion.

I would need a solid substantiation of the 'misinformation' aspect to give any more credence. "It's a scam" is not going to cut it, as stated.

One more thing I want to mention: This stance only applies to the hard fork resulting from a capacity increase (removing 1MB max blocksize). In the future if another hard fork occurs, replay protection may be a legitimate solution. Stances like this (regarding changing consensus rules) should be taken on a case by case basis, and are not set in stone to be applicable for every single future situation.

@priestc : Can you clarify why, in particular, your argument should apply to a capacity increase hard fork, but not to others? Because that does not follow as far as I'm concerned. Certainly not when you say this categorically:

"Anti-replay" technologies have one purpose: to allow for the existence of a minority scam coin.

Finally, I'd like to comment on this:

The BU project should be against any project that that claims to be "bitcoin" despite not being the majority hashpower.

It is my hope that the BU project will speak out against ideas on the basis of rational arguments that point out actual flaws, not on the basis of superficial labels or simple denouncements.
The kind of assurance you are requesting amounts to a blank cheque by the BU project that majority of miners could do anything they please in the name of Bitcoin, without the right of a hashrate minority to dispute that. If your argument was acceptable, it would delegitimize the entire movement for bigger blocks (the sum total of whose supporting projects currently do not have a majority of the hashrate, but just under 20% and apparently growing).

[1] https://blog.plan99.net/the-resolution-of-the-bitcoin-experiment-dabb30201f7

[2] https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-634#post-22454

[3] https://bitco.in/forum/threads/commandments-of-rational-debate.1185/

 

[priestc]

@priestc : Can you clarify why, in particular, your argument should apply to a capacity increase hard fork, but not to others?

Good question. This is a hard question to answer but I'll try my best. Network splits like the one that may happen when BU activates is not something that happens spontaneously. Whenever they do happen, there is a story behind why the split is happening. How to deal with such a split varies from split to split. The factors that come into play during the 1MB split are not going to be the same factors that come into play on a future split. I find it very common in the cryptocurrency world to overgeneralize events. I don't want people to think BU thinks *all* future minority chains are scam chains, because that won't necessarily always be true.

For instance people say ETH is "no longer immutable" because they did their hard fork to rewind the blockchain that one time. All they did was roll back one address's balance for the purpose of one single instance of theft. By the way some people talk, you'd think the developers included a mechanism to roll back any address on the whim of the dev team. If the ETH devs had been more clear in their communications about what the change entails, ETC may not have caught on the way that it did.

Basically being extremely clear, leaving no room for misrepresentation is always the best way.

I am not sure how you envision this working technically without completely breaking transaction validation in the process.

First off, you establish a new node type called "Bridge Node". These nodes provide a link between the minority network and the majority network. These Bridge Nodes only need to maintain connections with both networks to propagate transactions between each other. Once the fork happens, both minority nodes and majority nodes will ban each other, so the Bridge Nodes will repair this rift.

When someone tries to move tainted coins, the majority nodes will know the coins are from the minority coinbase by referring to the Bridge Nodes. When these transactions get mined to the blockchain, the miner can add a note to the block noting that these outputs need to be decreased by whatever amount is accounted for by the minority coinbase.

Imagine a transaction with two inputs, one 12.5BTC input that was mined before the fork, and one input of 12.5 that was mined after the fork. There are also two outputs, both going to different addresses and one worth 15BTC and the other worth 10BTC. When the majority chain mines this transaction, it notes that the second output has to be penalized by 6.25BTC, and the other one 6.25BTC. The penalty comes from that one input being of "fake" coins (fake from our [the majority] perspective, but genuine from the user's perspective).

The next time one of these outputs is spent, the majority chain records them with the penalty, calculated by adding up the amount of fake coin that make up the input amount. 6.25BTC in this example makes up the total amount of fake coins, so that penalty gets added to the outputs of the second transaction.

Hopefully this will incentivize merchants and exchanges from accepting tainted coins, and wallets from making them. The majority network is providing a sort of "insurance" service to the minority network. If they segregate their pre-fork and post-fork UTXOs, they will get the full benefit of this insurance. If they go tainting their coins, they are incurring a "tax" on their holdings in the case of the minority chain being abandoned.

 

[GriffGreen]

I hope to revive this discussion.

tl;DR
Replay protection will be implemented. It would be ideal if it were implemented client side as opposed to the user's side to protect the user's from losing their BTC. Trust me. The ETH/ETC fork was a shit show we should learn from.

--

The fact is Bitcoin is based on an Opt-in mentality. Anyone who tries to enforce their opinion on others will fail, this is what I love most about this remarkable technology! No matter how small the minority, no one can be forced to adopt any new changes, everyone can run whatever software they prefer.

I worked for Slock.it and was very much an insider in the ETC/ETH hard fork. We made a conscious decision ignore replays for the exact same reasons you have outlined above @priestc . It was the wrong decision.

By leaving it out we thought it would act as a deterrent, making it harder for ETC to exist, but this was a big mistake. There was a group of people that felt strongly that the hard fork was unnecessary and they were able to maintain the value of their chain and over come the replay issues. Don't let history repeat itself.

Not including replay protection caused many people to lose value (e.g. exchanges where scammers (and non-scammers) were able to deposit [ETH] and then withdraw [ETH + ETC] continuously until all the exchange's ETC was drained) and IMO we are at fault for being arrogant.

By not including replay protection, you impose upon every exchange and wallet service to implement a version of replay protection on their side. They have to protect themselves and their users, there will be a % of these services that fail to implement the proper precautions and a % of your loyal users will lose money and become disenchanted.

A hard fork requires people to update the software they are running, within that updated software, including a protection against replays is the responsible decision that protects your users.

When people feel too stupid to be their own bank we lose... It's already hard enough, please protect the average user. Succeed where Ethereum failed.

 

[freetrader]

[ copy from my response at: https://github.com/BitcoinUnlimited/BitcoinUnlimited/issues/383#issuecomment-287830868 ]

Appreciate the input, Griff. We are currently working on collecting information w.r.t. replay protection.

We are aware that there are several proposals around this, but it is also very important to get the "WHY" right as well as the "HOW".

To mention just one subtle point - the coming fork is not about BU only, it is about all implementations that want to transition to > 1MB blocks.
Implementing a change in transaction signatures (aka replay protection) would affect all other software that wants to maintain compatibility with the greatest-work chain.
We should ask what is the cost imposed on all those implementations too.

Another point that needs to be re-iterated is that replay 'protection' is something that is specific to a particular chain being mined. It is such a chain which wants to protect its transactions from being replayed by others. And it is the miners who validate these transactions before mining them into blocks. So they get to decide on what to 'protect' their chain against - not the BU project or implementation. BU can, at best, offer some tools to the users of its software, to allow them some choices in the matter. Such changes, which affect consensus, would be implemented by BUIPs, voted on by BU members. But anyone can submit technical proposals (even BUIPs) with specific ideas.
We may see such technical proposals if some decide they are technically worth proposing.

And the discussion about understanding transaction replay and its implications on the majority and minorities in a Bitcoin forking scenario is definitely open.

Let's explore it in depth in this thread and others here.

 

[priestc]

There is three ways to deal with the "replay issue"

1. "Fix the replay attack". This is where you acknowledge that "replays" are a bad things and should be dealt with by stopping them.

2. "Force the replay effect". This is where you acknowledge that replays are a good things and should be made to happen with all trasnactions that appear on each network.

3. Do nothing. Some transactions may be replayed, some won't.

----------------------------

The mistake ETH/ETC made was they choose option 3. I'm not advocating BTC take option 3 either. I think they should take option #2.

Lets me use this analogy:

Imagine a city with land split up into parcels. Each parcel has a corresponding title deed. These deeds are stored in the archives building.

Imagine some weird freak of nature event occurs and the archives building is duplicated. Instead of there being one deed for each parcel of land, there are two deeds for each parcel of land. Does this mean that all land has been doubled? Of course not. There is still only one parcel of land, just with two deeds.

"Forcing the replay effect" just means that every time you go into one of those archives buildings, and make a change to the ownership of one of those deeds, that change is guaranteed to be relayed to the other archives building. This will result in both archives being synchronized when it comes to land deeds that existed before the duplication.

"Fixing the replay attack" basically means that the two archives buildings are permanently out of sync and will remain out of sync forever. Why is this desirable?

In the bitcoin world, when a fork happens, its much like the doubling of archive buildings. The mechanism for recording ownership has duplicated **NOT THE BITCOINS THEMSELVES**. Just like the duplication of the archives building does not actually duplicate the amount of land that exists in the city.

The only coins that are actually duplicated are ones mined after the fork.

New land created after the archives building duplication will be disputed because there will be two deeds, but land created before the duplication will say the same thing in both archives. (if the replay effect is forced)

Coins mined after the fork will be disputed because there will be two blocks for every block height.

By the way, every single "replay protection" I've seen so far has been done in such a way that it can be thwarted. "Forcing the replay effect" is possible as far as I can tell. The only way for "forcing the replay effect" to be impossible is if someone could come up with a way to do "replay protection" that can't be thwarted. Since all BTC transactions and blockchains are public information, I predict true in-thwartable replay protection is impossible.

 

[adamstgbit]

isn't there some tool we can come up with that wouldn't require a change to the protocol and would virtually guarantee you can easily split the coins, and once thats done, replay attacks are not possible.

 

[torusJKL]

2. "Force the replay effect". This is where you acknowledge that replays are a good things and should be made to happen with all trasnactions that appear on each network.

What happens if the transaction gets confirmed on one chain but stays unconfirmed or even leaves the mempool on the other chain?

 

[GriffGreen]

@priestc I really don't think you can impose that on another chain. Hard Core Core Supporters will find a way to split their coins apart and send them to separate addresses. I might be wrong... if it's technically feasible to prevent that, kudos to you and your devs! That is a workable solution and I am glad we agree that we need to find a way to protect the user from inadvertently losing their bitcoins at the client level

Do you have links to where the devs are building these solutions?

And the discussion about understanding transaction replay and its implications on the majority and minorities in a Bitcoin forking scenario is definitely open.

Let's explore it in depth in this thread and others here.

This is exactly why I love the Unlimited Community, thank you for keeping an open mind and allowing for an open debate.
[doublepost=1490084513][/doublepost]

isn't there some tool we can come up with that wouldn't require a change to the protocol and would virtually guarantee you can easily split the coins, and once thats done, replay attacks are not possible.

The problem is not every user will implement that tool and people will lose money.

It needs to be part of the fork otherwise non-tech people will be afraid to use their coinage.

 

[freetrader]

I thought this topic-related comment from the GCBU thread was so good that I have to cross-post it to here.

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-937#post-36485

 

[priestc]

@priestc I really don't think you can impose that on another chain. Hard Core Core Supporters will find a way to split their coins apart and send them to separate addresses. I might be wrong... if it's technically feasible to prevent that, kudos to you and your devs!

What is replay protection other than obscuring a transaction so that one type of node can understand it, while the other node can't. That's like someone making a post to a forum and obscuring it such that core supporters can read the post, but unlimited supporters can't. Whatever obscuration that is applied can be undone by everyone if it can be undone by anyone.

At the very least, unlimited nodes can track both chains, the minority chain, and the majority chain. Even if unlimited nodes can't understand the signature scheme, they can assume a transaction has a valid signature if that transaction gets mined into a block on the minority chain. The only way to stop this is to make the minority chain completely private. As long as the data is public, the contents can be read. If the contents can be read, they can be replayed.

 

[GriffGreen]

I thought this topic-related comment from the GCBU thread was so good that I have to cross-post it to here.

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-937#post-36485

From that post: In the cryptocurrency world, we saw this happen with the ETH/ETC fork when many users dumped coins on a fork they believed rapidly would lose value. A moment's reflection will show that this would not have happened without replay protection since it makes zero sense for anyone to spend a valuable coin in order to sell a less valuable one.

Clearly, this guy doesn't know what he is talking about because the first ETC/ETH fork did not include replay protection. It had to be added in later forks! The users and exchanges had to create their own ways to split the coins.

Which is my whole point. The technical users will figure out a way to split their coins no matter what you do. The real question is whether you want to protect the average user.

The consensus around currencies is and always will be social. There is no code you can write that will make people follow one chain or another. It is a truly free market, there is no way to force your choice down other people's throats (btw, I am more sympathetic to Unlimited than Core I use the strong language only to make my point).

If replay protection is not added, many non-technical users and technical users that aren't following the news will unknowingly be sending two bitcoins for years to come unless there is a second fork. Think about all those people with paper wallets that die and their next of kin has to spend an hour to figure out what to do with a QR code, not even mentioning how to hack around splitting their coins.

Please reconsider your stance.

@priest I promise you that not including replay protection in the BU client just moves the replay protection to the users.

There are many ways to make a transaction invalid on one chain but valid on the other. Off the top the top of my head, after the chain has forked, you could get freshly mined coins from either chain (or any coins someone split already) and send them to your address. So lets say you have 1 address with 1 BTC in it prefork, then you send 0.1 Unlimited BTC to it, then you if you make a transaction sending 1.1 BTC from your address to a newly generated address it will fail on the Core chain and succeed on the Unlimited side. EASY.

And since there are a lot of other code discrepancies on the core side, I am sure there are 10 other creative ways to split the coins people already came up with.

Again, if you choose not to include replay protection, you are only hurting the general users of bitcoin and helping all the alt coins.

 

[freetrader]

the first ETC/ETH fork did not include replay protection

I think that is a point we are also trying to make - it should be the minority fork that implements replay protection.

You might think "oh, but that's just recklessness on BU's part to take such a stance". I disagree

But let's not forgot that there are significant differences between a BTC hard fork and the ETH / ETC fork.
These pre-existing differences (per-block retargeting) made the ETC minority fork viable from the beginning.

A majority BTC hard fork (let's say at 80% of hashpower) doesn't really suffer from this problem.
The survival chances of a minority fork (remaining on same POW) are very slim, esp. if the majority hashpower decides to protect their economic interests in any way.

The logical conclusion, if you want to fork away as a minority in Bitcoin, is that you either:
a) persuade the miners of the merits of your proposed protocol changes
b) "fire the miners" by changing POW, and see how the market evaluates your spin-off

It seems Core are taking route (b) after (a) has failed.

My current assessment from talking to people in the Bitcoin economy is that existing Bitcoin miners want what's best for Bitcoin.

They don't want an extremely disruptive split of the coin. Therefore, they are taking a cautious approach, trying to make this hard fork as safe as possible - in terms of high hashpower agreement , planning a grace period for businesses and users to upgrade to bigger-block compatible solutions, and also not increasing the block size irresponsibly.
However, they can only advise the ecosystem of their opinion and exercise their right to build on the chain they feel is the most responsible.

So I think we'll see a step up to 2MB or something, with a grace period of at least a few weeks for larger systems to make changes.

Of course they cannot prevent someone from doing a minority POW fork.

But come the time and given sufficient details, exchanges will evaluate carefully whether to list such a minority Bitcoin fork in competition to the majority hashpower 'Bitcoin'. It is *that* decision which will most impact users.

By the time the fork happens, I am sure there will be a couple of tools - and services - offering the possibility for Bitcoin users to safely split their coins as needed. The mechanics are well understood, and those who implement them will attract custom.

In that sense, the ETH/ETC fork served as a wake-up call to Bitcoin.

---

Maybe I need to re-emphasize the main point:

There are several good proposals on how a minority fork can implement 'replay protection'.
Some already implemented and at least partly tested.

A minority fork that doesn't do this is in fact hurting its own chances.
It is therefore rational to expect that the outcome of a split (as brought about by an intention minority forking off) would not result in the scale of problems experienced initially during ETH / ETC fork.

---

https://github.com/BitcoinUnlimited/BitcoinUnlimited/issues/389#issuecomment-288499177

---

Disclaimer: all of the above is my personal opinion. I don't speak for Bitcoin Unlimited more than anyone else. There may be others who see things differently and have a more nuanced view, and I hope they will speak out too.

 

[priestc]

@priest I promise you that not including replay protection in the BU client just moves the replay protection to the users.

Only if it's even possible to "split coins" in the first place. If BU wants to, it is possible to make it impossible for the minority's replay protection to function at all (however they implement it). It may not be possible for us to force the minority chain to record our transactions, but it is possible for us to record their transactions against their wishes for us to not record them. Will that be enough to prevent an exchange between both chains? I hope so. In my opinion we should do everything to prevent "cross chain dumping" as much as possible. It is not OK for users to "dump their BU coins", or even "dump their core coins". Neither activity should be possible (unless you're a miner).

I'm not saying there can't or shouldn't be a market for coins exclusive to one chain where they can be traded against coins exclusive to the other chain. But I do think such markets should only be open to those who hold coins mined after the fork, not holders of coins mined before the fork. Coins mined before the fork are uncontested BTC and should not be thought of as either "core coins" nor "BU coins".

If a user manages to taint prefork coins with post fork coins, it is possible for BU to record this taint, and record the transaction anyways. I describe how to do this in my OP.

If either party allows replay protection to be "successfully" implemented (either by the minority or the majority), then that pretty much guarantees that there will be two coins forever and BTC has permanent split. This will be bad and should be avoided. If replay protection is made to be impossible to establish, it would ensure one chain *could* die, which is the better outcome.