New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change address version #35

Closed
prusnak opened this Issue Jul 27, 2017 · 63 comments

Comments

@prusnak
Contributor

prusnak commented Jul 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@deadalnix

deadalnix Jul 27, 2017

Contributor

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.

Contributor

deadalnix commented Jul 27, 2017

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.

@karel-3d

This comment has been minimized.

Show comment
Hide comment
@karel-3d

karel-3d Jul 27, 2017

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)

karel-3d commented Jul 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@snavsenv

snavsenv Jul 30, 2017

why does bitcoin cash have p2sh but not segwit?

snavsenv commented Jul 30, 2017

why does bitcoin cash have p2sh but not segwit?

@prusnak

This comment has been minimized.

Show comment
Hide comment
@prusnak

prusnak Jul 30, 2017

Contributor

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

Contributor

prusnak commented Jul 30, 2017

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

@prusnak

This comment has been minimized.

Show comment
Hide comment
@prusnak

prusnak Jul 30, 2017

Contributor

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.

Contributor

prusnak commented Jul 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@deadalnix

deadalnix Jul 30, 2017

Contributor

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

Contributor

deadalnix commented Jul 30, 2017

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

@SentinalBais

This comment has been minimized.

Show comment
Hide comment
@SentinalBais

SentinalBais Aug 7, 2017

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.

SentinalBais commented Aug 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jasonbcox

jasonbcox Aug 8, 2017

Collaborator

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

Collaborator

jasonbcox commented Aug 8, 2017

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

@SentinalBais

This comment has been minimized.

Show comment
Hide comment
@SentinalBais

SentinalBais Aug 11, 2017

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

SentinalBais commented Aug 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@voisine

voisine Aug 21, 2017

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.

voisine commented Aug 21, 2017

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.

voisine added a commit to voisine/bitcoin-abc that referenced this issue Aug 21, 2017

Update chainparams.cpp
Change the mainnet p2pkh address version prefix to 28 (addresses start with "C"), and the p2sh version to 40 (addresses start with "H")

resolves issue #35
@axelay

This comment has been minimized.

Show comment
Hide comment
@axelay

axelay Aug 25, 2017

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

axelay commented Aug 25, 2017

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

@jasonbcox

This comment has been minimized.

Show comment
Hide comment
@jasonbcox

jasonbcox Sep 3, 2017

Collaborator

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

Collaborator

jasonbcox commented Sep 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@prusnak

prusnak Sep 4, 2017

Contributor

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.

Contributor

prusnak commented Sep 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@josephNLD

josephNLD Sep 4, 2017

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.

josephNLD commented Sep 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@prusnak

prusnak Sep 4, 2017

Contributor

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

Contributor

prusnak commented Sep 4, 2017

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

@axelay

This comment has been minimized.

Show comment
Hide comment
@axelay

axelay Sep 4, 2017

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

axelay commented Sep 4, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jasonbcox

jasonbcox Sep 4, 2017

Collaborator

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

Collaborator

jasonbcox commented Sep 4, 2017

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

@karel-3d

This comment has been minimized.

Show comment
Hide comment
@karel-3d

karel-3d Sep 4, 2017

karel-3d commented Sep 4, 2017

@josephNLD

This comment has been minimized.

Show comment
Hide comment
@josephNLD

josephNLD Sep 4, 2017

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

josephNLD commented Sep 4, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@prusnak

prusnak Sep 4, 2017

Contributor

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.

Contributor

prusnak commented Sep 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@axelay

axelay Sep 4, 2017

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

axelay commented Sep 4, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@josephNLD

josephNLD Sep 4, 2017

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

josephNLD commented Sep 4, 2017

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

@axelay

This comment has been minimized.

Show comment
Hide comment
@axelay

axelay Sep 4, 2017

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?

axelay commented Sep 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@redpola

redpola Sep 4, 2017

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

redpola commented Sep 4, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@josephNLD

josephNLD Sep 4, 2017

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.

josephNLD commented Sep 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@axelay

axelay Sep 4, 2017

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

axelay commented Sep 4, 2017

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

@josephNLD

This comment has been minimized.

Show comment
Hide comment
@josephNLD

josephNLD Sep 5, 2017

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

josephNLD commented Sep 5, 2017

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

@prusnak

This comment has been minimized.

Show comment
Hide comment
@prusnak

prusnak Oct 5, 2017

Contributor
Contributor

prusnak commented Oct 5, 2017

@ta32

This comment has been minimized.

Show comment
Hide comment
@ta32

ta32 Oct 5, 2017

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

ta32 commented Oct 5, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@voisine

voisine Oct 6, 2017

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

voisine commented Oct 6, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@deadalnix

deadalnix Oct 6, 2017

Contributor

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.

Contributor

deadalnix commented Oct 6, 2017

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.

@Bitcoin-ABC Bitcoin-ABC deleted a comment from darrenkis Oct 6, 2017

@prusnak

This comment has been minimized.

Show comment
Hide comment
@prusnak

prusnak Oct 6, 2017

Contributor

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.

Contributor

prusnak commented Oct 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
Contributor

prusnak commented Oct 6, 2017

@Bitcoin-ABC Bitcoin-ABC deleted a comment from NxtChg Oct 6, 2017

@Bitcoin-ABC Bitcoin-ABC deleted a comment from axelay Oct 6, 2017

@ta32

This comment has been minimized.

Show comment
Hide comment
@ta32

ta32 Oct 6, 2017

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

ta32 commented Oct 6, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@deadalnix

deadalnix Oct 6, 2017

Contributor

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.

Contributor

deadalnix commented Oct 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ta32

ta32 Oct 7, 2017

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.

ta32 commented Oct 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@matiu

matiu Oct 19, 2017

Contributor

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.

Contributor

matiu commented Oct 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Ayms

Ayms commented Oct 30, 2017

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

@MeshCollider

This comment has been minimized.

Show comment
Hide comment
@MeshCollider

MeshCollider Nov 12, 2017

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.

MeshCollider commented Nov 12, 2017

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.

@ta32

This comment has been minimized.

Show comment
Hide comment
@ta32

ta32 Nov 12, 2017

I would have preferred bitpays solution even before the DAA HF. Its very easy to make this mistake when making shapeshift transactions. Your refund address is a bitcoin address and your deposit is a bitcoin cash address. I hope this issue is the next priority after the DAA HF :)

ta32 commented Nov 12, 2017

I would have preferred bitpays solution even before the DAA HF. Its very easy to make this mistake when making shapeshift transactions. Your refund address is a bitcoin address and your deposit is a bitcoin cash address. I hope this issue is the next priority after the DAA HF :)

@deadalnix

This comment has been minimized.

Show comment
Hide comment
Contributor

deadalnix commented Nov 15, 2017

@prusnak

This comment has been minimized.

Show comment
Hide comment
@prusnak

prusnak Nov 15, 2017

Contributor

I strongly recommend to suppress the urge to invent new things and just use bip-0173 with no modifications. This will cost extra engineering efforts in the whole ecosystem and for no obvious good reason.

Contributor

prusnak commented Nov 15, 2017

I strongly recommend to suppress the urge to invent new things and just use bip-0173 with no modifications. This will cost extra engineering efforts in the whole ecosystem and for no obvious good reason.

@rubensayshi

This comment has been minimized.

Show comment
Hide comment
@rubensayshi

rubensayshi Nov 16, 2017

Contributor

strongly agree with @prusnak, most bitcoin libs have or are adding bip173 support, it will be much easier for wallet devs to implement if it matches bip173 completely

Contributor

rubensayshi commented Nov 16, 2017

strongly agree with @prusnak, most bitcoin libs have or are adding bip173 support, it will be much easier for wallet devs to implement if it matches bip173 completely

@rubensayshi

This comment has been minimized.

Show comment
Hide comment
@rubensayshi

rubensayshi Nov 17, 2017

Contributor

https://twitter.com/khannib/status/930223617744437253

Antoine Le Calvez @khannib
As of right now, there has been at least 478 BCH ($644k) sent by mistake to SegWit addresses. Contact your local miner if you want to recover your funds :)

https://twitter.com/khannib/status/931448049125249024

Antoine Le Calvez @khannib
https://blockchair.com/bitcoin-cash/address/3DutBysquuSbQxYA6EEq3m8VBQDBqa55mw becomes the first SegWit address whose funds were recovered (100 BCH), I trust @btccom_official to do the right thing and return them to their original owner. (Remains 443 BCH to claim).

@deadalnix it's time to act, this will only get worse over time, between now, this being released, being adopted and the old addresses being deprecated it will already be much worse probably, the longer the delay in getting the ball rolling to fix it the bigger the amount of BCH lost will become

Contributor

rubensayshi commented Nov 17, 2017

https://twitter.com/khannib/status/930223617744437253

Antoine Le Calvez @khannib
As of right now, there has been at least 478 BCH ($644k) sent by mistake to SegWit addresses. Contact your local miner if you want to recover your funds :)

https://twitter.com/khannib/status/931448049125249024

Antoine Le Calvez @khannib
https://blockchair.com/bitcoin-cash/address/3DutBysquuSbQxYA6EEq3m8VBQDBqa55mw becomes the first SegWit address whose funds were recovered (100 BCH), I trust @btccom_official to do the right thing and return them to their original owner. (Remains 443 BCH to claim).

@deadalnix it's time to act, this will only get worse over time, between now, this being released, being adopted and the old addresses being deprecated it will already be much worse probably, the longer the delay in getting the ball rolling to fix it the bigger the amount of BCH lost will become

@ta32

This comment has been minimized.

Show comment
Hide comment
@ta32

ta32 Nov 17, 2017

This change is not a protocol change, its a client level change on how addresses are represented. The timeline should be up to the wallet providers

As it stands there two ways of doing this:
support the old address format but give a warning, and support the new address format (once safely implemented - i believe next version of bitcoin cash). Then remove support for the old address once most of the ecosystem have moved to it. (Jan 14th @deadalnix https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-November/000472.html)

or only support the new address format.

Users needed this feature months ago, why do we have to wait till January if this feature is ready soon?
If there is anything wallet providers can do to protect users from mistake now, they should do it as quickly and safely as possible. @prusnak @voisine

In this instance we dont need wait for the "reference client" due to the layer at which this change is being done. We only need consensus on the implementation. ( I think we have this ?)

ta32 commented Nov 17, 2017

This change is not a protocol change, its a client level change on how addresses are represented. The timeline should be up to the wallet providers

As it stands there two ways of doing this:
support the old address format but give a warning, and support the new address format (once safely implemented - i believe next version of bitcoin cash). Then remove support for the old address once most of the ecosystem have moved to it. (Jan 14th @deadalnix https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-November/000472.html)

or only support the new address format.

Users needed this feature months ago, why do we have to wait till January if this feature is ready soon?
If there is anything wallet providers can do to protect users from mistake now, they should do it as quickly and safely as possible. @prusnak @voisine

In this instance we dont need wait for the "reference client" due to the layer at which this change is being done. We only need consensus on the implementation. ( I think we have this ?)

@RussianSwiss

This comment has been minimized.

Show comment
Hide comment
@RussianSwiss

RussianSwiss Nov 22, 2017

Need to sell BCH to old address. All exchanges use old addresses.

Where can we find a tool to convert old address to new?

bitpay/copay#7236

RussianSwiss commented Nov 22, 2017

Need to sell BCH to old address. All exchanges use old addresses.

Where can we find a tool to convert old address to new?

bitpay/copay#7236

@lacksfish

This comment has been minimized.

Show comment
Hide comment
@lacksfish

lacksfish Dec 7, 2017

I'd also suggest to gradually move away from prefix 1 for P2PKH and from 3 for P2SH.
Litecoin managed to pull it of moving from 3 -> M for P2SH

This is a short, crisp discussion on the matter:
litecoin-project/litecoin#179

lacksfish commented Dec 7, 2017

I'd also suggest to gradually move away from prefix 1 for P2PKH and from 3 for P2SH.
Litecoin managed to pull it of moving from 3 -> M for P2SH

This is a short, crisp discussion on the matter:
litecoin-project/litecoin#179

@rubensayshi

This comment has been minimized.

Show comment
Hide comment
@rubensayshi

rubensayshi Dec 18, 2017

Contributor

https://www.yours.org/content/january-14-2018---bitcoin-cash-change-the-address-day--d946c3dad317/

seems there's been progress on this discussion (and decision been made) through other channels than github.

at this point i'll take any change that avoids the confusion that is currently haunting users.

@prusnak

Contributor

rubensayshi commented Dec 18, 2017

https://www.yours.org/content/january-14-2018---bitcoin-cash-change-the-address-day--d946c3dad317/

seems there's been progress on this discussion (and decision been made) through other channels than github.

at this point i'll take any change that avoids the confusion that is currently haunting users.

@prusnak

@abrkn

This comment has been minimized.

Show comment
Hide comment
@abrkn

abrkn commented Jan 11, 2018

@Ayms

This comment has been minimized.

Show comment
Hide comment
@Ayms

Ayms Jan 11, 2018

@abrkn I think that I will implement the new address format in node for https://github.com/Ayms/bitcoin-transactions, even if not mandatory, when this is live (and/or clear, somme comments here can still give some doubts)

Ayms commented Jan 11, 2018

@abrkn I think that I will implement the new address format in node for https://github.com/Ayms/bitcoin-transactions, even if not mandatory, when this is live (and/or clear, somme comments here can still give some doubts)

@schancel

This comment has been minimized.

Show comment
Hide comment
@schancel

schancel Jan 11, 2018

Contributor

This is up for converting from old to new: https://cashaddr.bitcoincash.org/

Contributor

schancel commented Jan 11, 2018

This is up for converting from old to new: https://cashaddr.bitcoincash.org/

@schancel schancel closed this Jan 11, 2018

@Ayms

This comment has been minimized.

Show comment
Hide comment
@Ayms

Ayms Jan 18, 2018

FYI https://github.com/Ayms/cashaddress the difference with other js implementation is that it does not require any external module and is just a simple small file/code

Ayms commented Jan 18, 2018

FYI https://github.com/Ayms/cashaddress the difference with other js implementation is that it does not require any external module and is just a simple small file/code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment