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]

[JaredR26]

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.

[betawaffle]

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.

[jrallison]

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.

[JaredR26]

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.

[JaredR26]

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.

[betawaffle]

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.

[JaredR26]

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.

[betawaffle]

Ignoring ~99.9% of the users because of a loud vocal minority is a very bad idea.

Yet that is what you are doing.

[JaredR26]

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.

[jrallison]

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.

[betawaffle]

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.

[JaredR26]

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.

[betawaffle]

invalidating their transactions entirely

You wouldn't be invalidating their transactions!

[JaredR26]

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.

[JaredR26]

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.

[jrallison]

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.

[betawaffle]

@JaredR26 So you'll be fine if people try to sell their legacy bitcoin and wind up losing them on both chains?

[JaredR26]

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]

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

[betawaffle]

How is that a straw man? It will happen to people.

[betawaffle]

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.

[CosmicHemorroid]

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

[JaredR26]

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?

[jrallison]

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?

[JaredR26]

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.

[jrallison]

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?

[JaredR26]

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.

[betawaffle]

The wallet and seeds are 100% compatible.

They are also 100% compatible with Dogecoin...

[jheathco]

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

[JaredR26]

They are also 100% compatible with Dogecoin...

Different genesis block, ecosystem, and address prefix byte.

[sturles]

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

[JaredR26]

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.

[c4flash]

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.

[JaredR26]

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.

[jprupp]

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.

[jameshilliard]

@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]

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

[jprupp]

@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?

[sturles]

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

[NiKiZe]

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)

[jprupp]

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

[JaredR26]

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.

[jameshilliard]

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

[jprupp]

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.

[Pheromon]

@sturles

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

[JaredR26]

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

https://vote.bitcoin.com/arguments/if-non-core-hard-fork-wins-major-holders-will-sell-btc-driving-price-into-the-ground

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.

[AllanDoensen]

@jameshillard

I have yet to see any solid evidence that a majority of users intend to support bitcoin2x.

You need to look more then.

[rodasmith]

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.

[JaredR26]

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?

[jameshilliard]

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

https://vote.bitcoin.com/arguments/if-non-core-hard-fork-wins-major-holders-will-sell-btc-driving-price-into-the-ground

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.