Change address version

[prusnak]

I suggest to change the address version to something different, so it is obvious the address is a Bitcoin Cash address. (It can start with C for example). Don't forget to change also address version for P2SH!

[deadalnix]

Agreed. I have a plan to change the address format. Changing the address format is expensive, so I would like to investigate various other option than just changing the prefix before settling on something. I would also have to convince other in the space that this is a good address format.

[karelbilek]

Note that it can make some troubles with the backwards compatibility with the current addresses etc

If a person has some amount on an address with prefix 1, will they also have it on an address with a prefix C?

I think Litecoin solved it rather well in their P2SH addresses, since they accept both M and 3 addresses, but the default (in the new version, that they still didn't release, for several months now) is M

So they still accept payments with the 3-version, but the default address shown to user starts with M (again, in the version, that is still "release candidate" for several months now)

[snavsenv]

why does bitcoin cash have p2sh but not segwit?

[prusnak]

Raison d'être for Bitcoin Cash is that they do not want Segwit.

[prusnak]

What is the status of this? Tomorrow we are releasing a new firmware for TREZOR with Bitcoin Cash support and we are NOT going to change the address version later. Do you want to change the format or not? I suggest you do it now or never.

[deadalnix]

There is no way to deploy an address change safely in 2 days.

[SentinalBais]

Hi are we going to do this eventually?

Users are going to potentially loose funds or be in awkward situations, if we dont. There are many stackoverflow questions on accidentally sending eth to an etc address...

One of the reasons bitcoin cash is called bcash is to avoid user confusion. If the default bitcoin cash address format is different to bitcoin's then there is no danger to users anymore.

[jasonbcox]

If the core chain dies in the near future, maybe this will become a non-issue?

[SentinalBais]

jasonbcox, the only argument against this change is that 'it will move us further away from the bitcoin brand name or why should bitcoin cash change its the real bitcoin'

Both of these arguments are purely political and have no technical merit. If your pragmatic you will realize that there are two crypto currencies that share the same address prefix. This will only lead to user error and will require payment providers to recover funds for users and lead to increased costs.

look at this https://twitter.com/Wever50200940/status/895352403964416000 its already happening.

Frankly, if I was bitpay i would NOT add bitcoin cash support until this issue is resolved

[voisine]

We (breadwallet) are getting large numbers of support requests from people losing BCH by sending it to BTC only wallets and services. If you want to make BCH useable and safe for regular users, this needs to be corrected quickly.

I propose changing the address version byte to 28, which results in addresses with a prefix of "C". This can be backwards compatible with accepting BCH on legacy bitcoin addresses, since the same hashed pubkey can be represented either way.

[axelay]

We are having far too many issues for this to not be considered urgently. Please do something about it

[jasonbcox]

@SentinalBais I understand. I'm not trying to inject politics into the discussion. I was just considering the possibility that this could add technical debt that needs to be cleaned up later (should we support both address types in the mean time for other nodes to update?). With this in mind, developer time might be better spent elsewhere if the community can withstand the growing pains for the time being.

Trying to keep this technical, are the devs ok with adding a new address type ("C", say) and supporting both address types for some period of time? If only ABC makes this change, then wouldn't that fork from the network?

[prusnak]

Everyday people are sending Bitcoin to Bitcoin Cash addresses and vice versa. While this is not a problem for Bitcoin, because the coins can be recovered, it is FATAL for Bitcoin Cash users, when they send Bitcoin Cash to Bitcoin SegWit address. And this also happens.

It is sad, this could have been easily prevented, but developers decided to ignore my plea. And now, any transition to new format will be messy.

[josephNLD]

Sending Bitcoin Cash to SegWit addresses? How did they manage to do that? Seems more like the software creating such transactions needs to be fixed rather than the protocol. I recommend this issue be closed.

[prusnak]

Yeah, let's close eyes and pretend this is not happening.

[axelay]

@josephNLD - do you know a good way to check whether an address is supposed to be Bitcoin or Bitcoin Cash? On a form allowing user's input, there is no way to tell the difference - we have to rely on the user making sure the address they input is on the right chain. But no matter how many warnings you put up, there will still be cases where coins are sent from 1 chain to the other.

[jasonbcox]

@prusnak Wait, this is not indicated in the discussion above: Just where have you seen Bitcoin Cash sent to Segwit addresses? Please link a transaction where such a thing has occurred.

[karelbilek]

@prusnak talks about witness-inside-p2sh. P2sh addresses are the same in bcash and Bitcoin. But funds sent to those bcash p2sh addresses are now locked; unless you are a miner, in which case you can just take the funds.

On Sep 4, 2017 22:54, "Jason Cox" notifications@github.com wrote:

@prusnak https://github.com/prusnak Wait, this is not indicated in the discussion above: Just where have you seen Bitcoin Cash sent to Segwit addresses? Please link a transaction where such a thing has occurred.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Bitcoin-ABC/bitcoin-abc/issues/35#issuecomment-327032470, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGZ8fO6emIAP46iH2xrzqQNrUMtevJ3ks5sfHGqgaJpZM4Olv0- .

[josephNLD]

@axelay The concern is absurd. There's replay protection. "The user has to make sure the address is on the right chain." Happens exactly never, their software does this always. What the user has to do is identify the currency they are using, and select the right software. It is a branding issue, not a protocol issue. Fix the software for software branding issues, not the protocol.

[prusnak]

If your friend sends you the following address: 3ByFpfvJ1Ygv7BgvNwGyXg6GbvREm1Lhcu - you have no way of checking whether it is a valid Bitcoin Cash Multisig address or a Bitcoin SegWit address.

[axelay]

@josephNLD I guess you do not participate in the world of exchanges then - nor do you deal with user sending crypto currency out. @prusnak example is exactly right - if you give a form for the users to send out their coins, whether it is BTC or BCH, the address validation will still pass - no matter how clever you try to be. Same thing if they send their coins to us, I will give them an address so I can spot the funding but they can send BTC or BCH - no difference here. Only we have to manually recoup the "lost" coins as they are not on the same chain and credit user's account manually.

[josephNLD]

Unpersuasive. URIs exist for reasons. bitcoin:3ByFpfvJ1Ygv7BgvNwGyXg6GbvREm1Lhcu bitcoincash:3ByFpfvJ1Ygv7BgvNwGyXg6GbvREm1Lhcu Fix your softwares

[axelay]

I still don't think you understand. I run an exchange, we ask the user to give us their BTC or BCH address on a withdrawal form. Whatever they type in is up to them but we have had some users inputting the BTC address in the BCH withdrawal form - same goes for the BCH address in the BTC withdrawal form. How do I validate this then?

And it goes for the fundings as well - my QR codes are properly prefixed but some users send us coins from other exchanges and copy/paste the address I give them.

Do you understand?

[redpola]

@josephNLD Your argument seems to be that there are two ways to address this. Why not do both, to cover more use-cases, because people are losing money to this today?

[josephNLD]

I completely understand the issue. I have no confusion on the matter that users make mistakes when their software lets them.

I have sympathy for exchange support costs. It is the single biggest cost for all that provide even mediocre support. The reason it is the biggest cost is that the UX of most all exchanges are horrible, exchanges survive based on their market maker's liquidity and the degree to which the UX is designed to minimize support costs. Again, it is a software issue, a branding issue, and not a protocol issue. Fix it in the software. Problems ought be fixed in the layers best able to address them, this is not a problem with the protocol, and changing it is nothing more or less than a branding issue.

I agree with your practical problem, my suggestion is that each solve it in their own domain. Those that do so well, will thrive.

[axelay]

Ok so tell me how to fix it efficiently as you seem to know - I am all ears

[josephNLD]

@redpola There is not going to be a protocol change to fix your UX today, and you should realize also, maybe never. It may be the lowest priority item on anyone's hardfork list. https://en.bitcoin.it/wiki/Hardfork_Wishlist

Even though it might cost money to support users, and for that reason this particular issue might be of importance to some businesses, but it should be easy to recognize that it is not so much at all important to the protocol.

Businesses with issues might consider contributing to developers, and in that respect, being businesses, probably ought to do so with their OWN developers to improve their UX and reduce their OWN support costs. This helps you compete.

@Axelay Think creatively. Maybe you might even want to make a tool to let Users "Withdraw" their own miss-deposited money? It isn't as though you are hiring me to design for you, and I really have no responsibility to you to tell you how to fix your problems, but I hope my spending a few moments to help you recognize that you are not so powerless to do so is not wasted.

This is not a protocol problem, it is a UX problem, branding problem, and one best handled by the folks closest to the issue, the businesses with the issues themselves.

[SentinalBais]

@josephNLD This change will make it easier for wallets to solve @axelay issue easily.

Yes there are URIs, but every merchant that accepts bitcoin (eg bitpay ) does not use it.

The economic majority don't unanimously use URI for address so please lets fix this issue and handle BOTH payment use cases. I understand if everyone use URIs we would not have this issue but it is simply not the case

[voisine]

@josephNLD the version byte in the address is not part of the protocol. It exists specifically for this reason, to indicate to the sender's software what type of address it is to avoid loss of funds.

We will support the address version byte that I've proposed in breadwallet, and then also restrict sending BCH to bitcoin addresses to only be allowed when specified in a bitcoincash: URI (and also require "bitcoincash" for the network field of BIP70 payment protocol requests)

This will mean that most existing bitcoincash wallets and services will be unusable until the address version is widely adopted.

[NiKiZe]

@axelay if you have a input field for withdrawal address, wouldn't a requirement of bitcoin: or bitcoincash: help with the issue? (consider it being part of the address) And the same on deposit, only show it with the prefix, and never the address on it's own.

I'm not saying this is going to fix every issue, I'm just asking if it couldn't be used for now to at least mitgate the issue some. (and can we really say for sure that this won't "fix" the issue until after it has been tested?)

[axelay]

From experience, users will just copy/paste addresses from one exchange to another (or wallet) and unless they use an app, they will totally bypass the prefix - it may as well confuse the hell out of some users. Let's remember there is a vast majority of users jumping on the Crypto-bandwagon without knowing a thing and expect the system to handle things for them. Sadly in this present situation, it is not the case and we have many problems. Having a "tool" to recover the lost coins is not that easy sadly - when someone sends BTC to our BCH server, I have to export the private key from the BCH node then import it in a BTC node, wait for sync to be done and get the funds out - it's all time consuming.

However, with proper validation we would not even be in this situation.

The last thing we can do as exchanges is to completely blank the users by telling them "we told you to pay attention" - I know quite a few exchanges that did just that. But this is not an option for us.

[karelbilek]

Different address versions/prefixes for different altcoins exist for a reason

On Sep 5, 2017 09:42, "axelay" notifications@github.com wrote:

From experience, users will just copy/paste addresses from one exchange to another (or wallet) and unless they use an app, they will totally bypass the prefix - it may as well confuse the hell out of some users. Let's remember there is a vast majority of users jumping on the Crypto-bandwagon without knowing a thing and expect the system to handle things for them. Sadly in this present situation, it is not the case and we have many problems. Having a "tool" to recover the lost coins is not that easy sadly - when someone sends BTC to our BCH server, I have to export the private key from the BCH node then import it in a BTC node, wait for sync to be done and get the funds out - it's all time consuming.

However, with proper validation we would not even be in this situation.

The last thing we can do as exchanges is to completely blank the users by telling them "we told you to pay attention" - I know quite a few exchanges that did just that. But this is not an option for us.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Bitcoin-ABC/bitcoin-abc/issues/35#issuecomment-327110925, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGZ8fukDS7d7qbR9CO7GivQ6qxCzSMNks5sfQligaJpZM4Olv0- .

[voisine]

@josephNLD I think you must have responded to the wrong thread. Replay protection has nothing to do with the problem we're discussing. The problem is about people making BCH transactions on the BCH chain to a bitcoin-only receive address (or visa-versa)

[prusnak]

He is a troll, just ignore him. I am waiting for real developers to voice their opinion.

[prusnak]

Relevant: https://support.bitpay.com/hc/en-us/articles/115004671663

I think other wallets will follow the suit to use these address versions for your altcoin. It will be only beneficial if you get this fixed asap in your code to not cause even more mess than you caused already.

[SentinalBais]

so does this mean their wallet already implemented and address version change. So their wallets will only allow users to send funds to the new version of the address?

From what I understand the version field is not apart of the consensus layer so their transactions will not get blocked. Is this correct?

If this is the case all wallet makers should follow bitpays lead. @axelay

[axelay]

It's interesting but I fail to see how to get this widly adopted without a change in the server core. But it definitely need a closer look - thanks for pointing this out

[voisine]

@SentinalBais @axelay Yes, I spoke with Stephen from Bitpay and we'll be lobbying various other services and exchanges to support this.

[prusnak]

I was told that other Cash implementations (e.g. Unlimited) already implemented the change. If that is true, you should not hesitate and adapt it too ASAP.

[ta32]

@prusnak classic has implemented it also.

@darrenkis, this is change is a convention for formatting bitcoin cash addresses its not apart of the protocol. Its like equivalent to all wallets saying all bitcoin cash address must be colored 'red' or something. So the wallet ecosystem is sort of responsible for converging to a standard.

Sure there could have been better communication but this is how decentralized development works.

[voisine]

@ta32 that’s not how decentralized development works. The designers of BCH need to create a schelling point by making a semi-official recommendation for all the developers to standardize on.

[deadalnix]

Hi all,

I'd like to ensure you that this problem is taken seriously. As mentioned earlier, changing the address format is taxing on the ecosystem, so we'd like to avoid just changing the prefix, which, while it solve one immediate issue right now, will lead to the need to change address format down the road if new features are added (see for instance the necessity to add bech32 addresses for segwit). This is the reason why a simple prefix change wasn't the favored solution here.

There is work being done, mostly between XT, ABC and bitprim to get that sorted out and the solution is looking great. We'd also be happy to have other join the party if they wish to.

@ta32 I'd like to side with @voisine here. To make my point clearer, I'd like to take the example of another domain allowing permissionless innovation: the web. In the early days of the web, everybody was rolling out random crap and see what would stick or not. As a result, websites worked in one browser but not the other, and more generally, life was hell for both developers and users. Nowadays, things are done differently. For instance, the new crypto API ( https://www.w3.org/TR/payment-request/ ) you see that it is the result of the cooperation of Microsoft, Google, Facebook and Mozilla. They all worked together and proposed a solution to the world. People who used the web in the 90s or early 2000s and are using it nowadays knows that this change was a huge improvement for everybody involved.

An environment being permissionless doesn't means that being reckless has no consequences.

[prusnak]

The reality of things is that if you've done this very simple change 3 months ago like I proposed, there would not be thousands of Cash people sending their coins to wrong destinations and there would not be this mess of various Cash clients having different addresses.

While I agree with general idea of your comment, I am also able to recognize you are in a VERY different situation than W3C, which is drafting a not yet used standard so they are free to draft them however long they wish. But this is a entirely different story and this issue deserves your attention (and attention of other Cash developers) now.

[prusnak]

https://www.google.com/search?q=bitcoin+cash+sent+to+bitcoin+address

[ta32]

@deadalnix your comment wasn't clear Are you saying bitcoin abc will not change the prefix as a short term solution?

I believe bitcoin unlimited and classic have already done so... and considering it was a really simple change I dont see why its a problem. I dont think it adds technical debt.

I think wallet developers believe bitcoin-abc is the bitcoin cash reference client, so some are looking for this repository to make the prefix official. ( I disagree with this however )

If you have an alternate solution that is better I think the community needs a clear timeline, if its going to take 3-6 months its going hinder the adoption of bitcoin cash by service providers ( which is very important for its long term growth )

[deadalnix]

You are misinformed about bitcoin unlimited, they did not adopt this new prefix either. By the time you wrote "I believe" you should have known it was time for you to get more information about what's going on rather than suggesting a path forward. If everybody comes here to state what they believe just to be told it is incorrect, we aren't going to have a very high noise to signal ratio.

I know this situation is frustrating, but changing the address format involve a lot of people updating their code, a lot of user required to upgrade and so on. This is not something we are going to do repeatedly, so we are going to do it once, with a format that is extensible, so new features can fit in the format. We should have a finalized format in 2 to 3 weeks. Most of the code is ready, the only part that remains is to select some constants for the computation of the checksum.

[ta32]

sorry i was referring to prusnaks comment. ( I knew bitcoin classic did implement it )

Well 2-3 weeks is not a long time. If we going to have to wait another 3 months it would be too frustrating.

Thanks for making this clear.

[matiu]

Copay dev here. We are committed to follow whatever becomes the standard / official recommendation, but for the moment we really needed to differentiate the addresses to help our users, so we took @voisine proposal.

[Ayms]

FYI, see simple conversion (and BIP32 wallets) tool: https://github.com/Ayms/bitcoin-wallets#use---convert-bitcoin-addresses

[meshcollider]

I just want to leave this link here, to our cross-chain-recovery tag on Bitcoin.SE which is used to collect questions about coins sent to addresses on other chains:

https://bitcoin.stackexchange.com/questions/tagged/cross-chain-recovery

So many users are impacted by this.