Fork address versions
rodasmith opened this issue · comments
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]
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.
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.
Giving users a choice of chains is clearly better than accidentally losing money.
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.
@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.
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.
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?
@JaredR26 Please take your politics elsewhere.
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.
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.
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.... ???
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.
@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.
is not a valid hash of a public key
If you can prove that, please do.
Not that particular one, but here you go:
https://blog.openbazaar.org/proof-of-burn-and-reputation-pledges/
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.
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.
These are essentially the same thing.
wrong
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.
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.
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.
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.
@JaredR26 stop with your bizarre tirades, conspiracy theories and trolling.
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.
@CosmicHemorroid Not the place for personal attacks. Please do it somewhere else.
What about the children? Won't anyone think of the children?
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.
@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."
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.
@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.
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.
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.
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.
The other has been blocking progress
Only your version of progress.
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.
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.
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.
Strong ACK
This would ensure that many people won't lose coins accidentially.
ensure no proposals have any inherent adoption advantages over any others.
How could you possibly do that?
both competing visions need to fork to do that
That isn't true.
@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.
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.
@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.
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.
overwhelming consensus reached by the rest of the community
Miners and businesses are not "the rest of the community".
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 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.
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.
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.
Core is the one leaving consensus.
Core isn't forking at the moment.
Miners and businesses are not "the rest of the community".
Moderators of /r/bitcoin and the holdover programmers that didn't quit in late 2015 are not "the rest of the community" either.
This also wasn't done in past hardforks anywhere in any ecosystem.
Most if not all forks of bitcoin have changed the address format/version.
Moderators of /r/bitcoin and the holdover programmers that didn't quit in late 2015 are not "the rest of the community" either.
Correct. The "rest of the community" would be the users.
AThere are many people using it for many different reasons.
We agree here, at least. I wish more people would realize this.
Your arguments against "this is an unsafe change" seems to be repeating this notion that if everyone in the ecosystem hard forks
That's one of the two arguments and it is based on the assumption that the legacy chain will stop entirely. Mathematically and based upon the game theory that Bitcoin is built upon, that is highly likely if 93% of the hashrate leaves instantly; Bitcoin does not have a difficulty adjustment algorithm to survive such an event.
The other argument relates to the two competing visions. The markets should have been given this choice in a clean and fair manner a year ago. They weren't then, but they can be given this choice now.
Most if not all forks of bitcoin have changed the address format/version.
Name one hardfork in any major coin that has rejected previous address formats/versions as is requested here.
Name one hardfork in any major coin that has rejected previous address formats/versions as is requested here.
Practically every one of the thousands of altcoins.
Correct. The "rest of the community" would be the users.
The vast majority of the users are not involved in the scaling debate in any way. By some estimates, Bitcoin has almost 2 million users by now. User polls on twitter - which generally indicate a preference for on-chain scaling - get at most 6000 votes. Ignoring ~99.9% of the users because of a loud vocal minority is a very bad idea.
Ergo, a clean and fair split between the competing visions of what Bitcoin "is" is the best way to go.
Ignoring ~99.9% of the users because of a loud vocal minority is a very bad idea.
Yet that is what you are doing.
Practically every one of the thousands of altcoins.
So your comparison point is coins that start from a different genesis block and ruleset entirely and share no history?
Sorry, not convincing.
Both sides can make this change, or neither side can do it.
The vast majority of the users are not involved in the scaling debate in any way. By some estimates, Bitcoin has almost 2 million users by now. User polls on twitter - which generally indicate a preference for on-chain scaling - get at most 6000 votes. Ignoring ~99.9% of the users because of a loud vocal minority is a very bad idea.
Did you just make my point for me? Proposing and making unsafe changes to the network directly impacts those 2 million users. It's irresponsible.
that start from a different genesis block and ruleset entirely
You seem to be missing the point of this change entirely. It is to make it clear to users and software which chain they are interacting with. That applies to altcoins and any other kind of hard fork.
Proposing and making unsafe changes to the network directly impacts those 2 million users.
Like putting all existing Bitcoin addresses onto the minority chain and/or invalidating their transactions entirely?
No, that is the behavior that would hurt those 2 million users.
invalidating their transactions entirely
You wouldn't be invalidating their transactions!
It is to make it clear to users and software which chain they are interacting with. That applies to altcoins and any other kind of hard fork.
This change breaks compatibility with existing clients, software, transactions, and published addresses that would not be broken otherwise.
If such a drastic change is required, the minority chain can do it simultaneously or unilaterally.
You wouldn't be invalidating their transactions!
Did you not read the proposal?
Nodes only relay "standard" transactions, so the definition of "standard transaction" in the 2X chain should be updated to use the forked address version.
The transactions wouldn't work any longer unless manually included by a miner. That's not an acceptable change to foist upon the ecosystem.
Like putting all existing Bitcoin addresses onto the minority chain and/or invalidating their transactions entirely? No, that is the behavior that would hurt those 2 million users.
You wouldn't be.
The other argument relates to the two competing visions. The markets should have been given this choice in a clean and fair manner a year ago. They weren't then, but they can be given this choice now.
So you want to give users a choice. That's awesome. Now give them that choice by letting them decide what chain to transact on. So far btc1 doesn't.
@JaredR26 So you'll be fine if people try to sell their legacy bitcoin and wind up losing them on both chains?
You wouldn't be.
Their transactions would not be relayed and would be effectively disabled.
As the BTC1 team has repeatedly said, BTC1 will not be making changes that breaks compatibility with clients or existing software unnecessarily. This could be added as an optional feature at most.
@JaredR26 So you'll be fine if people try to sell their legacy bitcoin and wind up losing them on both chains?
Straw man argument. Come on, you're better than that.
Given the trade-offs of breaking compatibility and breaking all existing addresses and large amounts of unrelated software, that is absolutely less bad than users making mistakes that they may be able to recover from with assistance from the exchanges. The exchanges will have compatible private keys on each fork that can be manually used to recover from the mistakes and/or can automate this process if it becomes common, which is also unlikely.
The best course of action is a clean fork with the markets fairly deciding between Bitcoin's competing visions. While we can't have that, we should strive to get as close as we can.
How is that a straw man? It will happen to people.
The exchanges will have compatible private keys on each fork that can be manually used to recover
Exchanges didn't do so for Bitcoin Cash.
@JaredR26 "The best course of action is a clean fork with the markets fairly deciding between Bitcoin's competing visions." We just had a fork and the market has decided.
Exchanges didn't do so for Bitcoin Cash.
So things that take quite a bit of time and effort weren't done yet in the mad dash since BCC forked off less than 5 business days ago?
You don't say... Shocking, really! How could that be?
So things that take quite a bit of time and effort weren't done yet in the mad dash since BCC forked off less than 5 business days ago?
You don't say... Shocking, really! How could that be?
So the NYA signees have informed all major exchanges and gotten assurances all exchanges will be prepared in time?
So the NYA signees have informed all major exchanges and gotten assurances all exchanges be prepared in time?
I don't know, and if Coinbase's example is anything to look at, it seems unlikely that they would implement this as an automated process prior to even seeing if the legacy chain is viable. Such interruptions derail other critical priority for their development teams and delay critical things like stability and performance improvements. And if the legacy chain winds up not being viable, it might be wasted effort. That said, 3 months gives them some time to work on this, and BCC provides an example of why it may be needed, so it does seem like several exchanges could implement features like this to handle all future forks cleaner.
Exchanges are able to speak for themselves publicly and/or here about what they want to see; They were not hesitant to do so when BU was increasing in popularity. So your idea in that statement isn't bad, but I think the way you worded it is decidedly accusatory and undoubtedly will be pointed to by others in the future seeking to make this project look bad.
So your idea in that statement isn't bad, but I think the way you worded it is decidedly accusatory and undoubtedly will be pointed to by others in the future seeking to make this project look bad.
You specifically stated: "The exchanges will have compatible private keys on each fork that can be manually used to recover from the mistakes"
I was hoping to clarify how you knew that to be a fact. Did you just make it up? How can I gain confidence in this project?
You specifically stated: "The exchanges will have compatible private keys on each fork that can be manually used to recover from the mistakes"
I was hoping to clarify how you knew that to be a fact. Did you just make it up? How can I gain confidence in this project?
The wallet and seeds are 100% compatible. All that remains is what they do with those files internally.
The wallet and seeds are 100% compatible.
They are also 100% compatible with Dogecoin...
It seems clear that repeated attempts to break existing wallets, while under the guise of protecting user funds from potential double-spends, are more likely attempts by one chain to gain a significant advantage on the other via the grandfathering of users and wallets after the fork.
It's going to be an impossible sell for one chain to force the other to implement this unilaterally. I agree with @JaredR26 that this must be done on both chains if it's going to gain any sort of support considering the vast majority of hashing power is signaling s2x.
NACK
They are also 100% compatible with Dogecoin...
Different genesis block, ecosystem, and address prefix byte.
@JaredR26 As everyone who have been in cryptocurrency for more than a week know very well, the hashrate and what miners are mining at a given moment can change in a very short notice depending on which coin is the most profitable to mine, and so can the chain with the most work. Miners can be false signaling, as some miners have done with previous soft forks. We don't know anything before it happens. BTC1 plans to fork away from the consensus enforced by almost all current bitcoin nodes, just like Bitcoin ABC did a week ago, and that's all we know to be certain.
I have been running an exchange/broker since 2010, and depend on BTC1 to fork in a responsible way. Otherwise the new fork will be impossible to support. I have thousands of customers running their own Bitcoin Core nodes for security, privacy and improving the network (I have recommended to run a full node since I started doing this), and and can't imagine I will be able to make them all switch in short notice. I have decided to test btc1 to see if there are any issues before I chose whether to support it or not, but currently I can't even start it due to a segfault when loading my wallet. See issue #103.
To support segwit2x I depend on a responsible clean fork, and I assume the exchanges which signed the NY agreement expect the same responsible behavior that I do. (And working software, of course.)
and what miners are mining at a given moment can change in a very short notice depending on which coin is the most profitable to mine
This is not historically true with signaling in this debate. Very nearly the same mining farms signaling for classic and XT 2 years ago are the ones supporting bigger blocks now.
Miners who have signed an agreement historically have not defected from that agreement, or else Classic would not be a dead project today, and miner support for blocksize increases has been stronger than the alternative across the board for the last 12 months.
We don't know anything before it happens. BTC1 plans to fork away from the consensus enforced by almost all current bitcoin nodes, just like Bitcoin ABC did a week ago, and that's all we know to be certain.
We do know for certain that 84% of the hashrate and over 50% of the businesses by volume have signed a compromise agreement, and that one small group of developers have historically and currently refused all compromises.
and can't imagine I will be able to make them all switch in short notice.
Users are rational, you won't need to do anything. Their choices would be between a chain that gets almost no blocks and can't process transactions and has a rather illogical backing/justification, and one that requires a simple software change and is immediately usable just like the old coin.
but currently I can't even start it due to a segfault when loading my wallet. See issue #103.
And someone is helping you
To support segwit2x I depend on a responsible clean fork,
It doesn't sound like you actually want to support segwit2x, or else you'd have a response for why the majority chain should be invalidating all existing addresses in the wild by refusing to relay them, or why the competing development team can't implement the same changes they demand of this project.
Making changes to Core software to accommodate forkers sets a terrible precedent. It's forkers' responsibility to fork off gracefully and unambiguously. Cannot stay on the same blockchain and fork off too. Forks mutually exclude each other; that's the very definition of a fork.
Making changes to Core software to accommodate forkers sets a terrible precedent.
The supermajority doing things that benefit the superminority sets a terrible precedent.
It's forkers' responsibility to fork off gracefully and unambiguously.
We are, there is no need for the supermajority to break compatibility to support a minority's vision.
Forks mutually exclude each other; that's the very definition of a fork.
Forks enable free market competition so that the best solutions can help all of Bitcoin move forward. Breaking compatibility changes the competition. And breaking compatibility when evidence indicates there will be no competing fork that is even viable without a PoW change or difficulty hardfork just adds more work onto every other related software project needlessly.
And breaking compatibility when evidence indicates there will be no competing fork that is even viable without a PoW change or difficulty hardfork just adds more work onto every other related software project needlessly.
Exactly, this is the point. Right now you may be able to get compatible by doing nothing or changing one or two constants in the code. Everything else keeps working.
@JaredR26 I get that you want to coerce users into following a fork that they don't want to follow, but many others are strongly opposed to these sorts of tactics. I think you greatly underestimate the amount of users who will refuse to transact on the Bitcoin 2X chain(other than to dump their B2X coins) on principal alone. Even though I don't support BCash I do think they did a reasonably good at ensuring that users wouldn't accidentally spend coins on the wrong chain, this is something that I think should in general be done for all hard-forks(the technical details of how this is accomplished may differ). If a fork chain has to rely on tactics such as exploiting validation weaknesses in the SPV security model in order to get users then that should be an indication that the HF is probably not a good idea.
@JaredR26 I get that you want to coerce users
This is a lie. I don't want to force anyone to do anything. If there are to be two coins, I want an even playing field between two competing visions of what Bitcoin "Is."
And I think you might be referring to segwit's coercive softfork here, not btc1.
into following a fork that they don't want to follow
There's no evidence that anything but a vocal minority don't want to follow segwit2x. Prove me wrong if you have evidence.
I think you greatly underestimate the amount of users who will refuse to transact on the Bitcoin 2X chain
And I think you greatly overestimate how much people are willing to bet their money and lock up usability based on philosophical considerations. They will just go to the usable coin.
Even though I don't support BCash I do think they did a reasonably good at ensuring that users wouldn't accidentally spend coins on the wrong chain
They were in the extreme minority, almost un-measurably so. So they did as they had to do.
If a fork chain has to rely on tactics such as exploiting validation weaknesses in the SPV security model
The only thing exploitative would be the default Bitcoin ruleset favoring Core's blockade for 2 years when what is needed is a free market decision. If the default ruleset included some expiration or other kind of growth, the last 2 years would have gone very differently.
SPV clients are not affected by blocksize; There was and is no reason for them to refuse to follow a blocksize increase that is the longest chain.
this is something that I think should in general be done for all hard-forks
As I've said repeatedly, if this is truly the goal, it can easily be done simultaneously by the two competing development teams, or else all possible changes can be opt-in for existing software. It would appear that this isn't the goal, the goal is to coerce users the opposite way by default, like was planned/done with Segwit.
@jameshilliard there is no 2X chain or 2X coins. There is Bitcoin. This upgrade has as much consensus as you could expect from a distributed network, which is about 90% of the measurable hashrate and the largest economic players, including wallets and exchanges that represent a majority of network users as measured by transaction volume. There is a smaller vocal group that opposes this and is willing to do absolutely anything in pursuit of their goals, and for that reason this upgrade was delayed, but it is now happening. Focus on how we will handle it in a way that does not cause any amount of avoidable damage. The code is out there and the machine has been set in motion. How will you handle it? Will you keep rehashing the same set of arguments that have been spoken for the last three years or will you try something different?
@JaredR26 I already explained why I don't think hashrate is relevant. Please see my previous comments. All the signalling you mention failed to activate anything, so we will never know whether it was real or fake.
Regarding which version is the fork, and which is the original chain, the second main point of the NY agreement, after activating segwit, is:
- Activate a 2 MB hard fork within six months
Segwit2x is the hard fork. EOD.
It 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
Deployment of a safe solution must mean a clean split where users don't end up double spending on two chains by accident. Here is where the signatories must stick to the agreement and communicate with the community to find workable solutions for design and deployment, or otherwise I think it will be seen as a breach of the agreement by both miners, wallets and exchanges.
Most of my users running their own nodes, do that because I recommended it for security and privacy. They don't even know what a block is, and they have become used to slow confirmations by now.
To everyone that thinks that the 2x part of this project won't fly: How will it work with only ~7% of current hashrate and 864 blocks to go until retarget? Will that miniority chain even be viable in any way? Even with the possible 20% will it be usable?
Now to the technical part of this ,,, upgrading possible millions of wallets that otherwise might already expect to follow Segwit2x with a new address version simply won't happen.
There is currently only a few thousand full nodes that has a 1MB block limit and won't follow Segwit2x (core), there is a couple of thousand full nodes that will follow the longest chain (BU/Classic) and then there is an unknown number of other temporary clients that will just follow the "longest chain". So all in all, there is only a minority of the nodes that actually care about the blocksize.
Read the NYA agreement again, it has two points, activate Segwit and upgrade to 2MB blocks, anything outside of that should not happen here.
For another technical point, adding block size limitation as an consensus rule was a bad idea, alternatively it was a bad implementation of SPV to not care about the blocksize (you can pick any one of those, but that can't be blamed on this project or the agreement that it is following)
@NiKiZe I correct you here:
For another technical point, adding block size limitation as an consensus rule was a bad idea, alternatively it was a bad implementation of SPV to not care about the blocksize (you can pick any one of those, but that can't be blamed on this project or the agreement that it is following)
Some SPV clients will count the transactions in a Merkle Block and reject it if the number is larger that that allowed by the maximum block size constant. Not all SPV clients have this rule. I coauthored an SPV client that has that rule (Haskoin). If you have an SPV client, make sure that it will work with 2MB blocks, it is not guaranteed, but it should not be hard to fix if it doesn't.
Deployment of a safe solution must mean a clean split where users don't end up double spending on two chains by accident.
I disagree. Deployment in a safe manner means breaking the least amount of existing software stacks and user experiences necessary, and providing opt-in mechanisms for coin splits and prevention of wrong-chain transactions.
Existing addresses are in the wild, and must be relayed as valid transactions post-fork. To do otherwise would be the reckless and unsafe behavior.
@JaredR26 I already explained why I don't think hashrate is relevant. Please see my previous comments.
And I already answered you.
All the signalling you mention failed to activate anything, so we will never know whether it was real or fake.
I disagree with the "signaling is meaningless" line that has been touted on /r/bitcoin whenever signaling didn't agree with their agenda. Signaling indicates support, as does to a lesser extent polls, especially if the poll is non-sybilable like vote.bitcoin.com.
Most of my users running their own nodes, do that because I recommended it for security and privacy
Upgrading software when you don't have an intertwined software stack around it is trivial.
They don't even know what a block is, and they have become used to slow confirmations by now.
And what will you say when they find out about Ethereum's fast confirmations and lower fees from someone else, and will no longer be your customer period?
None of that is convincing. Upgrading single clients is easy, upgrading related stacks and changing addresses across the entire web, even hard-coded payout addresses, is not easy. You are advocating for the dangerous unsafe route.
This is a lie. I don't want to force anyone to do anything. If there are to be two coins, I want an even playing field between two competing visions of what Bitcoin "Is."
So you want to make it difficult for users to decide which coin they are using?
And I think you might be referring to segwit's coercive softfork here, not btc1.
Segwit is implemented in a way that makes it an opt-in feature as much as possible, users who don't want to use it don't have to.
There's no evidence that anything but a vocal minority doesn't want to follow segwit2x. Prove me wrong if you have evidence.
Maybe you're new to a lot of this but it should be pretty obvious, to start with segwit2x has been rejected by the vast majority of the technical community(not just core-devs).
And I think you greatly overestimate how much people are willing to bet their money and lock up usability base on philosophical considerations. They will just go to the usable coin.
You're making a lot of unsubstantiated assumptions here in regards to useability.
They were in the extreme minority, almost un-measurably so. So they did as they had to do.
I don't see how being a minority or majority has anything to do with it, core proposed HF's such as spoonnet have also taken this issue into consideration.
SPV clients are not affected by blocksize; There was and is no reason for them to refuse to follow a blocksize increase that is the longest chain.
This is a well known vulnerability in their security model, it's not a feature.
there is no 2X chain or 2X coins. There is Bitcoin.
A HF would create 2 chains, and thus 2 separate coins, what they are called in the end is not all that important as long as it's clear which chain is which.
There is a smaller vocal group that opposes this and is willing to do absolutely anything in pursuit of their goals, and for that reason this upgrade was delayed, but it is now happening.
I have yet to see any solid evidence that a majority of users intend to support bitcoin2x.
Focus on how we will handle it in a way that does not cause any amount of avoidable damage.
I've made many suggestions already on how to reduce the damage and risk of funds loss by users accidentally transacting on the wrong chain. If there are funds losses they will almost certainly be the result of this project rejecting those suggestions.
To everyone that thinks that the 2x part of this project won't fly: How will it work with only ~7% of current hashrate and 864 blocks to go until retarget? Will that miniority chain even be viable in any way? Even with the possible 20% will it be usable?
Hashpower largely follows markets, so if B2X is valued less than BTC then miners will likely mine BTC.
Deployment in a safe manner means breaking the least amount of existing software stacks and user experiences necessary, and providing opt-in mechanisms for coin splits and prevention of wrong-chain transactions.
Protection should be opt-out not opt-in otherwise users may unknowingly have their transactions replayed(see ETH/ETC split for an example of what happens when replay protection is opt-in only).
Protection should be opt-out not opt-in otherwise users may unknowingly have their transactions replayed(see ETH/ETC split for an example of what happens when replay protection is opt-in only).
The best form of protection is Bitcoin Core starts preparing a version of its software with 2MB blocks and releases it widely. Then we are all in the same chain and the upgrade goes smoothly. We did the same when the UASF came, even when SegWit was already part of the NYA, we sped up adoption and avoided forking the chain unnecessarily. You should be there convincing your friends to do the same now with the hard fork. The clock is ticking.
I already explained why I don't think hashrate is relevant
If you think hashrate is not relevant please use NXT or another PoS coin: this is Bitcoin, and hashrate is as much relevant as it can be.
Thanks
So you want to make it difficult for users to decide which coin they are using?
My preference would be for everyone to have to decide clearly with no default choices possible. Otherwise, opt-in options that don't break compatibility are fine, and if done on both sides then there would be no trouble and the few users who care which thing they are using can choose to do so. Barring that, the best option is for an even playing field between two competing visions, as should have been done a more than year ago.
Segwit is implemented in a way that makes it an opt-in feature as much as possible, users who don't want to use it don't have to.
So you're telling me that there's a command line flag that will disable segwit transactions in Bitcoin core??
That's only true if they are ok with paying higher fees comparatively for doing so, and if they change their software to do so, and even if they do those things the previous anyone-can-spend transactions have had their meaning changed entirely, and non-segwit clients have lost the ability to validate transactions. Meanwhile, Segwit has the discount in the wrong place such that it doesn't actually encourage UTXO reduction, what it actually encourages is signature-heavy transactions, but that couldn't be avoided as a soft-fork.
Changing the addressing entirely should be an optional feature, there is no reason to make those transactions not relay.
but it should be pretty obvious, to start with segwit2x has been rejected by the vast majority of the technical community(not just core-devs).
I disagree. It was only rejected by those in the community who stuck around after 2 years of scaling BS and censorship. It was only rejected by the very people who have blocked all competing proposals to date.
You're making a lot of unsubstantiated assumptions here in regards to useability.
No, I substantiated it earlier. If segwit-only has 7% of the network hashrate, for 6 months the transactions per day will be limited to only just under ~35,000, down from the current ~200,000+. That's FAR less usable.
This is a well known vulnerability in their security model, it's not a feature.
I and others disagree. SPV nodes are unaffected by the blocksize limit by design. There is no reason for them to be affected by changes to it.
what they are called in the end is not all that important as long as it's clear which chain is which.
The few people who care can choose which chain easily. The people who don't care can simply upgrade and continue using Bitcoin unimpeded. This is the safest approach, not one that makes their lives much more difficult.
I have yet to see any solid evidence that a majority of users intend to support bitcoin2x.
https://vote.bitcoin.com/arguments/block-size-limit-should-be-increased-to-8-mb-as-soon-as-possible
If there are funds losses they will almost certainly be the result of this project rejecting those suggestions.
Not any more than they are a result of Core, including yourself, not implementing those same suggestions.
Hashpower largely follows markets, so if B2X is valued less than BTC then miners will likely mine BTC.
Chains that stop getting blocks don't have a price, and several exchanges have already indicated segwit2x support. Segwit-only will be lucky if it has a market at all, much less the superior value for an extended period of time.
Meanwhile, users follow usable chains. The vast majority of users don't care for either philosophy, they just want a usable Bitcoin.
Protection should be opt-out not opt-in otherwise users may unknowingly have their transactions replayed
Protection should be opt-in, as the vast majority of users do not care which chain is what, they simply want to transact and have their coins be received in a timely fashion for a low fee.
(see ETH/ETC split for an example of what happens when replay protection is opt-in only).
You mean the coins that have obliterated over 50% of Bitcoin's market share since January? I'd say they're doing just fine.
@jameshillard
I have yet to see any solid evidence that a majority of users intend to support bitcoin2x.
You need to look more then.
BCH showed that hodlers want to convert 2X coins into BTC. If this project tries to prevent them from doing that by forking the network, refusing to implement replay protection, and hijacking BTC addresses, then I doubt it will be viable for longer than one difficulty adjustment on the other chain even without a PoW change. Don't try to force users onto your coin. If it is good enough to survive on its own without coercion, then prove it by not coercing users to use it unknowingly.
Don't try to force users onto your coin.
Don't try to force users onto your coin.
Both chains can implement these changes. If the other development group chooses not to implement the very things they request of this group, that's on them.
BCH showed that hodlers want to convert 2X coins into BTC.
Is that why the price went up 50% today, and another big exchange enabled trading?
Regardless, most exchanges have already indicated support for segwit2x, and none have indicated support for the legacy chain. If the legacy chain only has 7% of the hashrate, it is highly likely that that 7% will very quickly abandon the chain as many users do so, which makes it impossible for the legacy chain to ever reach the first difficulty adjustment at all.
If it is good enough to survive on its own without coercion, then prove it by not coercing users to use it unknowingly.
Funny that that logic applied to segwit indicates that segwit would never have activated or been used if not for segwit2x's compromise... But I guess you wouldn't want to use that logic on things you support, would you?
Otherwise, opt-in options that don't break compatibility are fine, and if done on both sides then there would be no trouble and the few users who care which thing they are using can choose to do so.
When designing security critical systems one should design them to fail safe, that's a big reason why one should design the fork so that individuals do not accidentally spend or accept coins on an unintended chain.
So you're telling me that there's a command line flag that will disable segwit transactions in Bitcoin core??
If you don't generate a segwit address then you won't send transactions using segwit, since segwit is backwards compatible you can of course still receive transactions from users who have upgraded.
That's only true if they are ok with paying higher fees comparatively for doing so
Obviously one has to update and use a feature to receive most of the benefits from it.
Meanwhile, Segwit has the discount in the wrong place such that it doesn't actually encourage UTXO reduction, what it actually encourages is signature-heavy transactions, but that couldn't be avoided as a soft-fork.
Signature heavy transactions require much less network resources per byte since they don't impact the UTXO set and can be pruned. UTXO growth is actually a much bigger problem than blockchain size growth.
It was only rejected by those in the community who stuck around after 2 years of scaling BS and censorship. It was only rejected by the very people who have blocked all competing proposals to date.
That the technical community has advocated against a number of bad proposals such as BIP101 and BIP109 is a good thing. Ultimately the choice will be up to users though.
No, I substantiated it earlier. If segwit-only has 7% of the network hashrate, for 6 months the transactions per day will be limited to only just under ~35,000, down from the current ~200,000+. That's FAR less usable.
You're making the assumption that the BTC chain will only have 7% of hashpower and the B2X chain will have 93%, since hashpower largely follows markets this is not a safe assumption to make.
https://vote.bitcoin.com/arguments/block-size-limit-should-be-increased-to-8-mb-as-soon-as-possible
I wouldn't link to a site like bitcoin.com that has a very obvious selection bias to support your claim.
Not any more than they are a result of Core, including yourself, not implementing and implementing those same suggestions.
Core proposed HF's like spoonnet took into account those protections. For technical reasons the side implementing the HF needs to deploy these protections.
Protection should be opt-in, as the vast majority of users do not care which chain is what, they simply want to transact and have their coins be received in a timely fashion for a low fee.
This has proven to be very dangerous with ETH/ETC, maybe it's an inability for some people to think adversarial but I really don't see how the evidence that opt-in is dangerous can be ignored.
You mean the coins that have obliterated over 50% of Bitcoin's market share since January? I'd say they're doing just fine.
I don't see how one can justify loss of funds with this sort of rational. It's a proven fact that there were funds losses due to opt-in only replay protection for the ETH/ETC split. Many in the ethereum community were pushing the exact same narrative you are now, the narrative that there will only be one chain. One should design security sensitive systems like bitcoin to handle worst case scenarios, not for best case ones.