Fork address versions

[rodasmith]

Problem

Addresses for standard transactions in the 2X chain look like addresses in the 1X chain, so users may not realize which chain to use to send to a given P2PKH, P2SH, or bech32 address. Anyone who sends to an address on the wrong chain could lose money, so it should be clear from an address which chain it belongs to.

Mitigation option

Change the version for P2PKH addresses (the number that results in the "1..." prefix for addresses in the 1X chain), P2SH addresses (the version number that makes "3..." addresses in the 1X chain), and bech32 (future state SegWit addresses prefixed "bc1..." in the 1X chain).

[removed technically inaccurate secondary detail]

[petertodd]

ACK

We have reports of people accidentally sending Bcash to BTC addresses and vice-versa, resulting in losses that would have been easily avoidable if Bcash had properly used a different address type.

Again, note how all wallet software needs to be updated to safely support this proposed hard fork, so changing addresses can added as part of this necessary update.

[JaredR26]

NACK

This appears to be yet another attempt by a competing development team to cause a portion of the ecosystem to default to following the minority chain which may not even be a viable chain at all.

If the competing development team wishes to implement this on the minority chain, they are free to do so. This could possibly be added as an optional opt-in feature on both chains simultaneously, but like other changes intended to cause clients confusion or to cause them to default to the minority chain, this shouldn't be implemented unilaterally on the majority chain.

[rodasmith]

Giving users a choice of chains is clearly better than accidentally losing money.

[JaredR26]

Giving users a choice of chains is clearly better than accidentally losing money.

So the minority chain and the majority chain can both do this, yes?

If the answer is not yes, this discussion is over.

[NiKiZe]

@petertodd do you mean Bitcoin Cash? (bcash isn't released yet)

Only core clients will need to be updated the majority will already follow the upgraded chain by default.

If Core want to make sure they survive on the minority fork they must add necessary changes to it's software to give users the choice that is asked here.

[BashCo]

Strong ACK.

We have seen several instances where users unintentionally send BTC to BCH addresses which has resulted in a loss of funds in some cases since certain exchanges refuse to recover the funds, or because they do not control the private key of the destination address. Before chalking this up as a simple "user error", responsible action should be taken to avoid loss of user funds due to such easily preventable mishaps. Therefore, a unique address format must be a prerequisite for any looming fork attempts. This responsibility lies solely on the entity designing the fork attempt. This is no time for deceptive bickering.

[JaredR26]

We have seen several instances where users unintentionally send BTC to BCH addresses which has resulted in a loss of funds

Then both Core and btc1 can implement this simultaneously and activate it at the same blockheight. If they choose not to, that's on them.

This is no time for deceptive bickering.

You mean like banning everyone who doesn't agree with your agenda?

[CosmicHemorroid]

@JaredR26 Please take your politics elsewhere.

[mpatc]

NACK @petertodd if you're concerned about preventing people from wasting their money, how is this a thing? https://blockchain.info/address/1BitcoinEaterAddressDontSendf59kuE

The fact that people can be stupid doesn't mean we need to work to save them from their stupidity.

[rodasmith]

This project is not the first hard fork, not likely the last, and no hard fork will every get 100% of the hash rate. Every time any project hard forks the Bitcoin chain, they should do so responsibly by making it clear to users which chain they are transacting with. I would expect Core to do the same if/when they ever need to hard fork.

[mpatc]

@BashCo

We have seen several instances where users unintentionally send BTC to BCH addresses

Do you have any actual txids to support this statement, or are you basing this on reddit comments?

This responsibility lies solely on the entity designing...

The single bitcoin eater address I linked to above has over $45K wasted on it. There are many others. If preventing user error like this is so important to you, why haven't I seen a Bcore PR to validate send addresses before sending? Or Bcore could simply reject transactions that contain provably unspendable outputs, but you haven't implemented that. But a similar problem is really important in this case because.... ???

[betawaffle]

why haven't I seen a Bcore PR to validate send addresses before sending

Core does validate addresses before sending. The address you linked is a valid address.

Or Bcore could simply reject transactions that contain provably unspendable outputs, but you haven't implemented that.

The address you linked is not provably unspendable, nor would be any current Segwit2x addresses.

[mpatc]

@betawaffle, IIRC OpenBazaar has implemented bitcoin burn addresses as a reputation-building system, and these address are provably unspendable. I'm not a cryptographer, but I would suspect the bitcoin eater address is not a valid hash of a public key.

[betawaffle]

is not a valid hash of a public key

If you can prove that, please do.

[mpatc]

Not that particular one, but here you go: https://blog.openbazaar.org/proof-of-burn-and-reputation-pledges/

[betawaffle]

The point is, the information necessary to prove something like the linked address being unspendable is not available. Especially not to node software in any generalized sense.

But the topic is not sending to burn addresses, it is about sending to perfectly valid addresses on the wrong chain.

[mpatc]

The point is, the information necessary to prove something like the linked address is not available.

No, the point is the core network currently offers many ways for users to "mess up" and lose their coin. People can (intentionally or otherwise) provably burn their bitcoin, and bcore allows this.

There are many potential areas we could put training wheels on the protocol to help minimize user error, but this isn't a priority, unless there is evidence that it's a real problem. I still have yet to see a single txid of this happening in the wild, or any significant loss due to this. It's all just reddit claims at this point.

But the topic is not sending to burn addresses, it is about sending to perfectly valid addresses on the wrong chain.

These are essentially the same thing. This seems like a solution in search of a problem, since it's a pretty difficult "mistake" to actually make.

[ghost]

These are essentially the same thing.

wrong

[JaredR26]

@rodasmith

Every time any project hard forks the Bitcoin chain, they should do so responsibly by making it clear to users which chain they are transacting with. I would expect Core to do the same if/when they ever need to hard fork.

Fundamentally this issue comes down to differing visions for what Bitcoin is and should become. Core should have recognized these differences over a year ago and offered people - particularly the markets - a choice; Instead they went with the default course of action and force people to follow them or be kicked out of the communities that predated the issue.

Those days are over. Competing development teams have sprung up and stuck around to get past the blockade. Enough people have been banned from the major communities due to censorship to form their own vibrant and rapidly growing community, and have become big enough that now the original community brigades them instead of the other way around.

Overwhelming consensus has been reached outside core by compromise, as it should have been reached a year ago. If Core wishes to reject all compromises and try to have as much of the community follow their fork by default, that is not the fault of the outside super-majority who are trying to arrange the smoothest transition.

If Core wishes to implement the very features they are demanding of this project, we could have fruitful discussions on a clean fork. But pretending it is the responsibility of the super-majority to allow all existing systems to default to the minority chain (again) is deceptive. If Core truly wants to take the steps for a clean fork, most of the demanded changes can be done as opt-in or could be done simultaneously on each side as a forcing function.

One side, especially the supermajority, doing the change that benefits the other side unilaterally is not going to fly, no matter how much you pretend that it is really all about the users. If it was about the users, Core could implement the changes just as easily.

[rodasmith]

Fundamentally, this issue is about giving users a clear view into which chain they are transacting on. The NYA2X hard fork will survive for awhile even if users know when they are transacting on a bloated 2X chain. No good would be served by tricking users into following a hard fork.

[mpatc]

No good would be served by tricking users into following a hard fork.

Let's keep it professional, we should always assume good faith. Nobody here is trying to trick users. This is a straw-man argument.

[JaredR26]

Fundamentally, this issue is about giving users a clear view into which chain they are transacting on.

And this can be done on both chains if it is truly a problem, there is no reason not to do so.

No good would be served by tricking users into following a hard fork.

In my eyes, this issue is very similar to the numerous other issues raised that encouraged hardfork version bits to be changed, or encouraged transaction compatibility to be broken in a non-optional manner, or encouraged non-upgraded clients to be disconnected from nodes. The issue with all of those is what happens with the default users, and how much difficulty it adds for the ecosystem if the legacy chain is not viable and dies.

This concept adds difficulty to the fork if the legacy chain dies, and it breaks compatibility that would otherwise work fine. If the minority chain is not willing to add this, it must not be a big enough problem to be added here either.

[CosmicHemorroid]

@JaredR26 stop with your bizarre tirades, conspiracy theories and trolling.

[c4flash]

The overwhelming body of bitcoin users HAVE decided in favor of the Core devs' version. Careful, deliberative, well-tested code has brought bitcoin through thick and thin, and will continue to do so henceforth. It's not Core's job to fix rushed, irresponsible code dumped onto the network by forkers. It IS Core's job to protect users' considerable investments from hostile takeover attempts by implementing measures they deem necessary, imo.

[mpatc]

@CosmicHemorroid Not the place for personal attacks. Please do it somewhere else.

[betawaffle]

What about the children? Won't anyone think of the children?

[JaredR26]

The overwhelming body of bitcoin users HAVE decided in favor of the Core devs' version

This is false. They have followed the default client that the current set of core developers inherited when the schism originally happened in late 2015.

It's not Core's job to fix rushed, irresponsible code dumped onto the network by forkers.

It isn't the job of the majority fork to cater to the minority fork. Core refusing to compromise is the source of this problem, not the overwhelming majority fork.

Also this fork isn't rushed by comparison with any other examples of other hardforks, including BCC/BCH or ETC/ETH. The only people calling this fork "rushed" are the same set of core developers who have opposed every other fork in the past. Color me surprised.

If this is a big enough issue to warrant inclusion here, it is a big enough issue to warrant inclusion in the minority fork. If it isn't there, it isn't here.

[CosmicHemorroid]

@mpatc Your bias is showing. This whole bizarre conspiracy tirade belongs on reddit, not here.---> "Fundamentally this issue comes down to differing visions for what Bitcoin is and should become. Core should have recognized these differences over a year ago and offered people - particularly the markets - a choice; Instead they went with the default course of action and force people to follow them or be kicked out of the communities that predated the issue.

Those days are over. Competing development teams have sprung up and stuck around to get past the blockade. Enough people have been banned from the major communities due to censorship to form their own vibrant and rapidly growing community, and have become big enough that now the original community brigades them instead of the other way around.

Overwhelming consensus has been reached outside core by compromise, as it should have been reached a year ago. If Core wishes to reject all compromises and try to have as much of the community follow their fork by default, that is not the fault of the outside super-majority who are trying to arrange the smoothest transition.

If Core wishes to implement the very features they are demanding of this project, we could have fruitful discussions on a clean fork. But pretending it is the responsibility of the super-majority to allow all existing systems to default to the minority chain (again) is deceptive. If Core truly wants to take the steps for a clean fork, most of the demanded changes can be done as opt-in or could be done simultaneously on each side as a forcing function.

One side, especially the supermajority, doing the change that benefits the other side unilaterally is not going to fly, no matter how much you pretend that it is really all about the users. If it was about the users, Core could implement the changes just as easily."

[rodasmith]

Ok, point taken. We are not trying to trick users, so to make it clear to users which chain they are transacting on, the hard-forking chain should fork the address version.

[mpatc]

@CosmicHemorroid my "bias" is irrelevant. You need to treat others with respect if you want to participate here. Calling other people's ideas "bizarre" or "conspiracies", labeling those stating their opinions as going on "tirades" and accusations of trolling do not belong here. Please follow the rules and be nice to others, even if you strongly disagree.

[JaredR26]

so to make it clear to users which chain they are transacting on, the hard-forking chain should fork the address version.

Why should the supermajority compromise chain fork the address version and not the minority chain that has opposed progress for years and refused to give the markets or users any other choices? Including that that same minority chain derailed a fork project 1.5 years ago by signing an agreement that they never fulfilled? Even when viewed as "individuals' signatures" they failed to fulfill their commitments.

The entire point of what I am saying is that it is absolutely not clear that the responsibility for these type of forking mechanisms falls to one vision of Bitcoin but not the other.

Whenever there is a fundamental split in the visions of the community, the community needs to be forced to make a clean split, by both sides cooperatively. That means either the legacy clients default to both chains as much as possible(opt-in features), or both sides of the fork reject un-upgraded behavior.

This is what would have solved the scaling debate a year ago, and it is what should be done in the future whenever we encounter an issue as contentious as this one. Programmers unilaterally deciding what is best on an IRC channel, ejecting those who disagree, and silencing the opposition everywhere they can does not help anyone in a consensus network, especially if the network has competitor altcoins. The networks RELY on consensus, and the ecosystem relies upon adoption across multiple levels.

If the minority fork still won't take the steps they are demanding be added to the majority fork, that is a trick being played on the ecosystem. Either both sides take the steps, or neither side does.

[jrallison]

The entire point of what I am saying is that it is absolutely not clear that the responsibility for these type of forking mechanisms falls to one vision of Bitcoin but not the other.

Only one of those "visions of Bitcoin" is planning to hard fork in a few months.

Hard forking without taking adequate precautions to ensure users can transact on the chain they intend is irresponsible at best. This is a concern for users who plan to follow the hard fork as well as those who don't.

[JaredR26]

Only one of those visions of Bitcoin are planning to hard fork in a few months.

The other has been blocking progress by default for 2 years despite being in the minority.

Hard forking without taking adequate precautions to ensure users can transact on the chain they intend is irresponsible at best.

Refusing an ecosystem-wide compromise so you can continue forcing your vision on people is irresponsible at best.

This is a concern for users who plan to follow the hard fork as well as those who don't.

Great, then it can be added on both sides as I stated repeatedly. There is no justification for the supermajority chain breaking compatibility unilaterally, and proposals to that effect have repeatedly been rejected. None of those proposals are coming from within the people that support this project; All of the proposals and issues to the end that you describe have come from the competing development team.

[betawaffle]

The other has been blocking progress

Only your version of progress.

[JaredR26]

Only your version of progress.

All competing proposals for progress have been blocked. The only progress that has been allowed was the vision of the developers who did not quit Core in 2015, supported by heavy censorship in the main community forums.

[jrallison]

Great, then it can be added on both sides as I stated repeatedly.

So the solution to a major issue with your hard fork is another hard fork? This isn't how this works...

None of those proposals are coming from within the people that support this project; All of the proposals and issues to the end that you describe have come from the competing development team.

I'm not a member of any development team. I'm a user.

[JaredR26]

So the solution to a major issue with your hard fork is another hard fork? This isn't how this works...

The minority chain is almost certainly going to have to fork to change the difficulty and/or proof of work. But even if they don't... Yes.

My solution to the issue that has plagued the entire ecosystem for 1 year is to give the markets the cleanest choice possible and let every proposal compete fairly. I would prefer for one unified development team to do this with one codebase that has optional and/or required flags to specify which consensus ruleset the users/businesses wish to follow, and to ensure no proposals have any inherent adoption advantages over any others.

We can't have that, so the next best thing is competing clients. If one client makes choices to benefit from the default choices of the ecosystem, the other client needs to do the same wherever possible. If the goal here is a clean fork that protects the users as much as possible, both competing visions need to fork to do that. If that isn't truly the goal, then the premise of this issue is deceptive.

I'm not a member of any development team. I'm a user.

The proposer has contributed to and/or supported Core since the 2015 schism, as with nearly every other proposal like it in the past 2 months. If I had to guess, I would guess that you are not a neutral party in this issue and you know which vision you prefer and which fork you want to win.

[h0jeZvgoxFepBQ2C]

Strong ACK

This would ensure that many people won't lose coins accidentially.

[betawaffle]

ensure no proposals have any inherent adoption advantages over any others.

How could you possibly do that?

[betawaffle]

both competing visions need to fork to do that

That isn't true.

[CosmicHemorroid]

@mpatc "has opposed progress for years" <---That is an attack. " Including that that same minority chain derailed a fork project 1.5 years ago by signing an agreement that they never fulfilled? Even when viewed as "individuals' signatures" they failed to fulfill their commitments." <----That is an outright lie. Miners broke the agreement 2 weeks after it was signed, and besides several forks were offered and refused. "silencing the opposition everywhere they can" <----another attack and lie. I'm defending, not attacking.

@JaredR26 Please stop treating github like your personal subreddit.

[c4flash]

If one defines 'super-majority' as the body of default users holding, trading, converting BTC on a daily basis then one would endeavor to make these processes simple, straightforward and easy to use. I stand on my earlier post; anyone can fork off as we have just seen this week. But to do so while throwing a monkey-wrench into the QED vast majority blockchain is unacceptable. Just change the addressing scheme to avoid confusion causing default users to hesitate using bitcoin. Adoption of bitcoin by the general public is, after all, a desirable outcome.

[sturles]

@JaredR26 I don't think minority vs majority chain is a valid argument. The chain with the most amount of work can switch from day to day, even from hour to hour. I don't think one can expect every fork to switch address schemes every hour, according to how much work has been done on their chain compared to the rest.

Since segwit2x is forking into a new consensus, and everyone following this consensus must change their software, it is only logical that the fork make the necessary changes. Users staying with the current consensus can keep using what they are using now.

[JaredR26]

If one defines 'super-majority' as the body of default users holding, trading, converting BTC on a daily basis then one would endeavor to make these processes simple, straightforward and easy to use.

The simplest, most straightforward, and easiest to use process would be for the existing developer group to accept the compromise as the rest of the ecosystem has and move forward as one Bitcoin.

I stand on my earlier post; anyone can fork off as we have just seen this week. But to do so while throwing a monkey-wrench into the QED vast majority blockchain is unacceptable.

Refusing to accept an overwhelming consensus reached by the rest of the community is throwing a monkey-wrench.

This can be resolved by having both chains make the changes.

[betawaffle]

overwhelming consensus reached by the rest of the community

Miners and businesses are not "the rest of the community".

[h0jeZvgoxFepBQ2C]

If you want to leave consensus, it's your choice. But please do it in a safe manner and don't risk other peoples money.

[JaredR26]

@JaredR26 I don't think minority vs majority chain is a valid argument. The chain with the most amount of work can switch from day to day, even from hour to hour

93% of the hashrate is signaling, and they are not changing from day to day or hour to hour. 84% of the hashrate has signed the agreement to not switch day by day or hour by hour.

I don't think that the "chain making changes" is a valid argument. This also wasn't done in past hardforks anywhere in any ecosystem.

I don't think one can expect every fork to switch address schemes every hour,

No one is saying that, don't create strawmen. If the majority chain can add this at the activation blockheight, so can the minority chain.

Since segwit2x is forking into a new consensus, and everyone following this consensus must change their software,

Not all software must be changed. That's the whole issue with the SPV hardfork bits, and also with addresses, as existing addresses on the web would be invalidated.

Users staying with the current consensus can keep using what they are using now.

And will default to following the longest chain wherever possible.

[jrallison]

The proposer has contributed to and/or supported Core since the 2015 schism, as with nearly every other proposal like it in the past 2 months. If I had to guess, I would guess that you are not a neutral party in this issue and you know which vision you prefer and which fork you want to win.

I'm aware of the biases in this thread. I use bitcoin for a variety of reasons, so I have my own biases as well.

A piece of advice, Bitcoin isn't Core vs. NYA. There are many people using it for many different reasons. Ensuring safe changes to the network are front and center for most, I'd imagine.

Your arguments against "this is an unsafe change" seems to be repeating this notion that if everyone in the ecosystem hard forks, then your hard fork will be safer. You're not going to get everyone to hard fork, there is no centralized control... it's Bitcoin.

[JaredR26]

If you want to leave consensus, it's your choice. But please do it in a safe manner and don't risk other peoples money.

Core is the one leaving consensus.

[jrallison]

Core is the one leaving consensus.

Core isn't forking at the moment.