Change address version #35
Comments
|
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. |
|
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) |
|
why does bitcoin cash have p2sh but not segwit? |
|
Raison d'être for Bitcoin Cash is that they do not want Segwit. |
|
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. |
|
There is no way to deploy an address change safely in 2 days. |
|
Hi are we going to do this eventually? Users are going to potentially loose funds or be in awkward situations, if we dont. 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. |
|
If the core chain dies in the near future, maybe this will become a non-issue? |
|
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 |
|
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. |
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 Bitcoin-ABC#35
|
We are having far too many issues for this to not be considered urgently. Please do something about it |
|
@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? |
|
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. |
|
Sending Bitcoin Cash to SegWit addresses? How did they manage to do that? |
|
Yeah, let's close eyes and pretend this is not happening. |
|
@josephNLD - do you know a good way to check whether an address is supposed to be Bitcoin or Bitcoin Cash? |
|
@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. |
|
@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" ***@***.***> 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
<#35 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGZ8fO6emIAP46iH2xrzqQNrUMtevJ3ks5sfHGqgaJpZM4Olv0->
.
|
|
@axelay |
|
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. |
|
@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. |
|
Unpersuasive. URIs exist for reasons. |
|
I still don't think you understand. 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? |
|
@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? |
|
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. I agree with your practical problem, my suggestion is that each solve it in their own domain. Those that do so well, will thrive. |
|
Ok so tell me how to fix it efficiently as you seem to know - I am all ears |
|
@redpola 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 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 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 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. |
|
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. |
|
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. |
|
@deadalnix your comment wasn't clear I believe 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 ) |
|
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. |
|
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. |
|
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. |
|
FYI, see simple conversion (and BIP32 wallets) tool: https://github.com/Ayms/bitcoin-wallets#use---convert-bitcoin-addresses |
|
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. |
|
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 :) |
|
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. |
|
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 |
|
https://twitter.com/khannib/status/930223617744437253
https://twitter.com/khannib/status/931448049125249024
@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 |
|
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: 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? 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 ?) |
|
Need to sell BCH to old address. All exchanges use old addresses. Where can we find a tool to convert old address to new? |
|
I'd also suggest to gradually move away from prefix This is a short, crisp discussion on the matter: |
|
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. |
|
@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) |
|
This is up for converting from old to new: https://cashaddr.bitcoincash.org/ |
|
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 |
* Remove redirects from nginx.conf and use jekyll permalinks instead * Nits in nginx.conf
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!
The text was updated successfully, but these errors were encountered: