Bech32 adoption wiki page added tracking for wallets and services supporting Bech32m and P2TR addresses.
Bitcoin Core started to support Bech32m since v0.21.1 and P2TR will be supported from v22.0.
Electrum is supporting Bech32m addresses since 4.1.0.
Wasabi wallet is planning support for both Bech32m and P2TR with NBitcoin.
Trezor Hardware wallet is planning support for both Bech32m and P2TR.
BTCPay Server is planning P2PTR invoices and Bech32m withdrawal addresses.
Full information: https://en.bitcoin.it/wiki/Bech32_adoption
Topic: [LIST] Bech32 Bitcoin addresses Not supported (Read 753 times)
Trezor wallet is now supporting Bech32 addresses with their new Trezor Suite that can downloaded as software or used as web version, and Bech32 worked before with Electrum wallet so I am removing Trezor wallet from the list.
Why they should not adapt to support all the bitcoin addresses. This will create worries and confusions when doing transactions because you have to make sure that the wallet supports from the wallet you are using specifically bech32 bitcoin address. So far, a wallet I known good to supoort bitcoin address like bech32 is the mycelium wallet but then again you have to familiarize the different wallet addresses in mycelium being classiffied in the option of the bitcoin wallet address.
Armory wallet has a board here and the main developer (goatpig) is active here, so why don't you raise the topic of supporting bech32 addresses with him?
Even better, you can implement it yourself since it's open-source software any maybe he'll merge your contribution.
Even better, you can implement it yourself since it's open-source software any maybe he'll merge your contribution.
Binance exchange is now finally supporting segwit bech32 address format so I am removing them from the list, and I am hoping other services/wallets will follow them soon.
Quote
Fellow Binancians,
Binance has launched Segregated Witness (SegWit) support for Bitcoin (BTC) deposits (withdrawals are already supported). By selecting the BTC (SegWit) network, users can transfer funds to a SegWit (bech32) address.
https://www.binance.com/en/support/announcement/0fee417cefff41a8a8fbfeaf23d0ae01?ref=JLI1VBLABinance has launched Segregated Witness (SegWit) support for Bitcoin (BTC) deposits (withdrawals are already supported). By selecting the BTC (SegWit) network, users can transfer funds to a SegWit (bech32) address.
Why cutting off anyone
Correct, I talked with Chipmixer and for now they don't have any intention of using Bech32 address format.
One more website to look for Bech32 stats as well as other stats is txstats.com
This is the list of wallets and services that DO NOT support bech32 bc1 address format, so I won't add Exodus for now, but in future I plan to add separate list of popular services supporting bc1
As 50% of transactions are segwit, ChipMixer would be more private if nobody knows which address format it is using. For now, everyone can know for sure that 50% of the transactions are not CM chips.
Correct, I talked with Chipmixer and for now they don't have any intention of using Bech32 address format.
One more website to look for Bech32 stats as well as other stats is txstats.com
You should add Exodus wallet. They give bc1 address and also allow the creation. They also give legacy wallet address. So their wallet feature is ok.
This is the list of wallets and services that DO NOT support bech32 bc1 address format, so I won't add Exodus for now, but in future I plan to add separate list of popular services supporting bc1
There are many bitcoin wallets and mostly suported bech32 addresses. Mycelium is one which supported this kind of wallet that could enable you to send and receive bech 32 wallet addresses. If you wish OP to add those wallets that support the bech32 addresses then check these different wallets in this thread For your ready reference on bitcoin wallet posted by @erikoy.
As for ChipMixer, I believe they have very good reasons not to implement Bech32 yet:
I'm not sure I follow that logic. The anonymity from using ChipMixer does not rely on an attacker not being able to tell an output came from ChipMixer. Indeed, it is trivial to identity a ChipMixer output, given their characteristic funding transactions with 50 outputs of 0.016 BTC, or similar. It is therefore irrelevant if an output is legacy or Bech32 - it can easily be identified as a ChipMixer output either way. Rather, the anonymity comes from being unable to link these outputs to any inputs due to the time travel funding structure and set chip size.I've made some lists counting currently funded addresses in chips-size.
All addresses:
1 mBTC: 268782
2 mBTC: 69499
4 mBTC: 32541
8 mBTC: 16476
16 mBTC: 8782
32 mBTC: 4378
64 mBTC: 1940
128 mBTC: 1469
256 mBTC: 726
500 mBTC: 39785
512 mBTC: 616
1000 mBTC: 86705
1024 mBTC: 446
2048 mBTC: 93
4096 mBTC: 134
8192 mBTC: 32
Only addresses starting with 1:
1 mBTC: 216475
2 mBTC: 52087
4 mBTC: 24640
8 mBTC: 12498
16 mBTC: 6626
32 mBTC: 3485
64 mBTC: 1700
128 mBTC: 1318
256 mBTC: 658
500 mBTC: 19436
512 mBTC: 592
1000 mBTC: 52094
1024 mBTC: 435
2048 mBTC: 88
4096 mBTC: 132
8192 mBTC: 31
Only addresses starting with 3:
1 mBTC: 39821
2 mBTC: 13391
4 mBTC: 6801
8 mBTC: 3297
16 mBTC: 1944
32 mBTC: 781
64 mBTC: 209
128 mBTC: 119
256 mBTC: 58
500 mBTC: 14684
512 mBTC: 22
1000 mBTC: 27670
1024 mBTC: 7
2048 mBTC: 5
4096 mBTC: 2
8192 mBTC: 1
Only addresses starting with bc1:
1 mBTC: 12450
2 mBTC: 4016
4 mBTC: 1099
8 mBTC: 679
16 mBTC: 211
32 mBTC: 112
64 mBTC: 31
128 mBTC: 32
256 mBTC: 10
500 mBTC: 5665
512 mBTC: 2
1000 mBTC: 6940
1024 mBTC: 4
2048 mBTC: 0
4096 mBTC: 0
8192 mBTC: 0
Only weird addresses (anything with a "-" in it):
1 mBTC: 36
2 mBTC: 5
4 mBTC: 1
8 mBTC: 2
16 mBTC: 1
32 mBTC: 0
64 mBTC: 0
128 mBTC: 0
256 mBTC: 0
500 mBTC: 0
512 mBTC: 0
1000 mBTC: 1
1024 mBTC: 0
2048 mBTC: 0
4096 mBTC: 0
8192 mBTC: 0
Notes:
I'm using data from October 24 because of bandwidth problems
I only check the total balance, some addresses may have received funds several times.
Binance as a big exchange should consider adding bc1 address to their exchange. I don't know why they make it look impossible.
You should add Exodus wallet. They give bc1 address and also allow the creation. They also give legacy wallet address. So their wallet feature is ok.
You should add Exodus wallet. They give bc1 address and also allow the creation. They also give legacy wallet address. So their wallet feature is ok.
If ChipMixer were to, in practice, exclude users who haven't upgraded to Bech32-compatible wallets, how would that affect the anonymity set of the overall service? Would it matter, in your opinion?
The anonymity set would undoubtedly reduce, but even if it didn't, I wouldn't want to cut off some users from the service, particularly users who are using custodial wallets and are in the greatest need of privacy improving services. Even if they only offered legacy addresses for inputs, I can't see any real reason the chips for withdrawal aren't SegWit.When you say an output could easily be identified as a CM output, I assume you are talking strictly in terms of an heuristic analysis, and not necessarily in terms of blockchain analysis, correct? That is to say, if I merged and split my own outputs exactly as I have observed ChipMixer doing and then sent you some of those chips, you would assume they came from ChipMixer.
Probably. I don't really care where my bitcoin come from, so I don't really pay much attention. If you sent me an exact chip value, and I went back one transaction and saw a "classic" ChipMixer funding structure, then yeah, personally I would probably just assume it was from ChipMixer and not look any deeper. I'm sure that if I was interested and probed a bit deeper though I could figure it out, though. 
As it turns out, Bech32 only represents 3.5% of the network if measured by number of UTXOs, or 4.6% if measured by the number of BTC stored. From a privacy perspective, it seems reasonable for ChipMixer to continue holding off.
Segwit adoption is quite larger than this.
I made this topic about it, where I made a few charts.
I used blockchair data from LoyceV csv file.
This chart is the witness_count/transaction_count ratio.
As witness_count is the number of transactions in the block containing witness information, we can easily calculate the segwit adoption per block.
As the chart would become too noise with adoption per block, I calculate the adoption per month (witness_count per month / transaction count per month)
This is the result. Nearly 50% of transactions are segwit.
As 50% of transactions are segwit, ChipMixer would be more private if nobody knows which address format it is using. For now, everyone can know for sure that 50% of the transactions are not CM chips.
As for ChipMixer, I believe they have very good reasons not to implement Bech32 yet:
I'm not sure I follow that logic. The anonymity from using ChipMixer does not rely on an attacker not being able to tell an output came from ChipMixer. Indeed, it is trivial to identity a ChipMixer output, given their characteristic funding transactions with 50 outputs of 0.016 BTC, or similar. It is therefore irrelevant if an output is legacy or Bech32 - it can easily be identified as a ChipMixer output either way. Rather, the anonymity comes from being unable to link these outputs to any inputs due to the time travel funding structure and set chip size.Thanks for pointing that out. I may have been approaching this question from the wrong angle.
Two questions for you:
If ChipMixer were to, in practice, exclude users who haven't upgraded to Bech32-compatible wallets, how would that affect the anonymity set of the overall service? Would it matter, in your opinion?
When you say an output could easily be identified as a CM output, I assume you are talking strictly in terms of an heuristic analysis, and not necessarily in terms of blockchain analysis, correct? That is to say, if I merged and split my own outputs exactly as I have observed ChipMixer doing and then sent you some of those chips, you would assume they came from ChipMixer.
One update today.
Bisq exchange is now officially supporting Bech32 addresses so I am removing them from my lazy list.
Others will follow sooner or later
Bisq exchange is now officially supporting Bech32 addresses so I am removing them from my lazy list.
Others will follow sooner or later
Quote
SegWit addresses to fund and withdraw from your Bisq wallet
NOTE: Although it's now finally possible to transfer out of Bisq to Bech32 wallets, do not expect any fee savings just yet, because all Bisq trading transactions still happen against P2PKH addresses. This change will be shipped in one of the next releases.
Source information: https://github.com/bisq-network/bisq/releases/tag/v1.4.2 NOTE: Although it's now finally possible to transfer out of Bisq to Bech32 wallets, do not expect any fee savings just yet, because all Bisq trading transactions still happen against P2PKH addresses. This change will be shipped in one of the next releases.
As for ChipMixer, I believe they have very good reasons not to implement Bech32 yet:
I'm not sure I follow that logic. The anonymity from using ChipMixer does not rely on an attacker not being able to tell an output came from ChipMixer. Indeed, it is trivial to identity a ChipMixer output, given their characteristic funding transactions with 50 outputs of 0.016 BTC, or similar. It is therefore irrelevant if an output is legacy or Bech32 - it can easily be identified as a ChipMixer output either way. Rather, the anonymity comes from being unable to link these outputs to any inputs due to the time travel funding structure and set chip size.I for one would personally like ChipMixer to upgrade to native Segwit outputs at least, even if they keep legacy deposit addresses to maintain compatibility with other services.
Please correct me if I'm missing something though.
Trezor also supports receiving/sending from bech32 addresses with their new app and web wallet Trezor Suite:
https://suite.trezor.io/
https://suite.trezor.io/
I'm surprised to see Blockstream Green and Casa on the list. Fortunately, they will both likely be deploying Bech32 address generation in the not-so-distant future. At least, that's my interpretation of this and this.
As for ChipMixer, I believe they have very good reasons not to implement Bech32 yet:
As it turns out, Bech32 only represents 3.5% of the network if measured by number of UTXOs, or 4.6% if measured by the number of BTC stored. From a privacy perspective, it seems reasonable for ChipMixer to continue holding off.
As for ChipMixer, I believe they have very good reasons not to implement Bech32 yet:
I've always assumed it was due to the slow network adoption of Segwit. Until a few months ago, Segwit transactions comprised significantly less than 50% of transactions on the network. Moving all of Chipmixer's activity to Segwit would have therefore compromised its anonymity set. Best to use the most common form of Bitcoin address, right?
Now that Segwit adoption is hovering in the 50-60% range, the transition is more justifiable. (To be fair, I'm not sure about the proportion of bech32 vs. wrapped P2SH usage, though.)
Now that Segwit adoption is hovering in the 50-60% range, the transition is more justifiable. (To be fair, I'm not sure about the proportion of bech32 vs. wrapped P2SH usage, though.)
As it turns out, Bech32 only represents 3.5% of the network if measured by number of UTXOs, or 4.6% if measured by the number of BTC stored. From a privacy perspective, it seems reasonable for ChipMixer to continue holding off.
Hello dkbit98, someone tried to send me some coin from the exchange "Uphold" https://uphold.com/en-us/ I didn't know about. The site refused and said my Bech32 address was invalid. After some research, it turns out Uphold only supports P2PKH and P2SH addresses, so you can add it to your table with two red "no".
Than you for providing feedback about Uphold and it is now added to unsupported list.
I also added Betfury casino because I received report that is not supporting Bech32 address format.
You can post more submissions with proof.
I do not know about trust wallet.
Trust wallet supports bech32 for both sending and receiving bitcoin, i specifically think its for the iOS wallet users. The article below was published on 18th June 2020, so definitely Android users should be able to use Bech32 by now.Quote
All Trust Wallet users on iOS will now have access to ... you to send and receive Bitcoin through Bech32 (bc1) addresses... Android users should receive this functionality in the coming 2-3 weeks.
https://community.trustwallet.com/t/all-trust-wallet-users-on-ios-will-now-have-access-to-bitcoin-btc-in-their-multi-coin-crypto-wallet/34960I think OP should add trust wallet in the list above.
Hello dkbit98, someone tried to send me some coin from the exchange "Uphold" https://uphold.com/en-us/ I didn't know about. The site refused and said my Bech32 address was invalid. After some research, it turns out Uphold only supports P2PKH and P2SH addresses, so you can add it to your table with two red "no".
i'm curious if there is any data to support this, i thought it plateaued a while ago.
Sure there is, and if you look you will see I posted Bech32 statistics link in first post.there is an interesting jump in the chart if we look at the past year statistics in February where it goes from 410kBTC to 590kBTC, it is as if some whale(s) decided to move a lot of coins to bech32 addresses in one day (2020-02-03).
I don't remember where I've read it but someone recommended that we create new wallet for every transaction to be made. And this is for security reasons because for every transaction the public key of the address is exposed.
As Charles-Tim has said, it is a new address which is recommended. When you send a transaction, the individual public key for that address is exposed, which is a theoretical security risk in the future once elliptic curve multiplication becomes vulnerable. The other addresses in that wallet are unaffected.When it comes to exchanges though, there is another reason why a new address for each deposit is important - privacy. If i know you own address X, and I see you deposit coins to an address owned by an exchange, then I can reasonably assume that every other deposit to that address is from you, and I can use thelst knowledge to link a lot of your addresses and a lot of your coins.
...
Thanks for the correction, I gained a lot from your post above. I am a bit bad to anything related transactions, all because I looked for book to read about it in details and I have not found a perfect one. You can just play around this tool (https://bitcoindata.science/bitcoin-fee-size-calculator.html) I made to confirm everything o_e_l_e_o said about inputs, vbytes, transaction vsize, etc
I will make use of the tool, I believed I can learn from the write up found under the tool too. Thanks. Isn't coinomi and trust wallet among them? I have used these two for awhile already.
I don't remember where I've read it but someone recommended that we create new wallet for every transaction to be made. And this is for security reasons because for every transaction the public key of the address is exposed. This could be too much of a security measure I suppose but it must have been a good practice and there are exchanges that I see allowing users to generate addresses. Is there any of them that has plans for this?
Coinomi support segwit, I do not know about trust wallet. Exchanges that users can generate new address, if using nested segwit like HitBtc, it will continuing generating nested segwit, and if it is generating legacy address, it will continue generating legacy address. I do not think that is an issue if you can still use segwit to pay into the exchange, exchange fee rate is very high because most of the fee is not for miners but the exchanges themselves.
Isn't coinomi and trust wallet among them? I have used these two for awhile already.
I don't remember where I've read it but someone recommended that we create new wallet for every transaction to be made. And this is for security reasons because for every transaction the public key of the address is exposed. This could be too much of a security measure I suppose but it must have been a good practice and there are exchanges that I see allowing users to generate addresses. Is there any of them that has plans for this?
Excellent initiative, shame on them. May their potential users think twice before going for a service or wallet that will make them spend more.
There are some similar lists in the Bitcoin wikis.
There are some similar lists in the Bitcoin wikis.
It's like O positive blood. Bech32 is the universal sender.
O negative is the universal donor. 
While we're sort of naming and shaming, might I suggest also we promote services that do? This might encourage other services to then look at their competitors to see what works and how it's implemented. Might even get people to reach out and cooperate.
Let me commend Fairlay here for being bech32 supporting since at least 2019, both for sending and withdrawing.
And because I've just used them, Freebitco.in supports bech32 withdrawals.
You can ALWAYS send from a bech32 to any Bitcoin address. It's like O positive blood. Bech32 is the universal sender.
Let me commend Fairlay here for being bech32 supporting since at least 2019, both for sending and withdrawing.
And because I've just used them, Freebitco.in supports bech32 withdrawals.
But you can still send from bech32 address to your Binance wallet right? That's what my question is about. Hence why I found the receive part to be a bit confusing.
You can ALWAYS send from a bech32 to any Bitcoin address. It's like O positive blood. Bech32 is the universal sender.
You can send from Binance exchange to Bech32 wallet address, but you can't generate Bech32 address on Binance and that means you can't receive.
But you can still send from bech32 address to your Binance wallet right? That's what my question is about. Hence why I found the receive part to be a bit confusing.Please correct me if I am wrong but I think Trezor hardware wallet now supports Bech32 and Coinbase exchange also, but I will have to double check everything from that list and update.
The list is about the web wallet and not the HW itself, you can click the X/V part for more details. As for Coinbase it's probably outdated since the last update is on April 2019. It might be interesting to expand the list by adding which online/Bitcoin casinos support native segwit withdrawals and which don't. I am afraid that many still haven't added support for Bech32. I am more curious about those who support it.
I can say for sure that FortuneJack doesn't. I withdrew some money from there a few nights ago, and Bech32 addresses are not recognized as valid.
I can say for sure that FortuneJack doesn't. I withdrew some money from there a few nights ago, and Bech32 addresses are not recognized as valid.
Yes, I added other Services section and I will slowly add more websites and casinos that don't support Bech32 addresses, but I will need help from other gambling members for that. I will try to keep this topic updated, but if you notice any updates or changes please post in this topic.
FortuneJack will now be added to the list.
I also added Roobet casino because I know they only support creating oldest format BTC address P2PKH, but I am not sure in withdrawing to Bech32 is supported.
It might be interesting to expand the list by adding which online/Bitcoin casinos support native segwit withdrawals and which don't. I am afraid that many still haven't added support for Bech32. I am more curious about those who support it.
I can say for sure that FortuneJack doesn't. I withdrew some money from there a few nights ago, and Bech32 addresses are not recognized as valid.
I can say for sure that FortuneJack doesn't. I withdrew some money from there a few nights ago, and Bech32 addresses are not recognized as valid.
Please correct me if I am wrong but I think Trezor hardware wallet now supports Bech32 and Coinbase exchange also, but I will have to double check everything from that list and update.
Trezor hardware wallet already supports bech32 address format in its firmware if you use Electrum.
However, there is still lack of functionallity in its native software (Trezor Wallet)
Quote
Trezor with Bech32 addresses
Trezor already implemented Bech32 addresses in its firmware, it is possible to send funds to Bech32 addresses using Trezor Wallet. Receiving is possible using Electrum with native segwit (P2WPKH) option.
source: https://wiki.trezor.io/Bech32 Trezor already implemented Bech32 addresses in its firmware, it is possible to send funds to Bech32 addresses using Trezor Wallet. Receiving is possible using Electrum with native segwit (P2WPKH) option.
For everyone who asked for Bech32 stats before, here is one screenshot, and you can find stats for all other address formats also:
https://txstats.com/dashboard/db/bech32-statistics?orgId=1
Please correct me if I am wrong but I think Trezor hardware wallet now supports Bech32 and Coinbase exchange also, but I will have to double check everything from that list and update.
You can send from Binance exchange to Bech32 wallet address, but you can't generate Bech32 address on Binance and that means you can't receive.
https://txstats.com/dashboard/db/bech32-statistics?orgId=1
Here's another source that covers more services: https://bitcoinops.org/en/compatibility/.
I'm a bit confused by the Create/Receive part. At first I kinda get the impression that the transaction made from the bech32 address won't show up on those services, but I vaguely remember that I used a bech32 address to send some Bitcoin to Binance a while back. Can anybody confirm this? Or does that part mean the ability to generate a bech32 receiving address only?
Thanks for posting one more source, but I think it is also a bit outdated.I'm a bit confused by the Create/Receive part. At first I kinda get the impression that the transaction made from the bech32 address won't show up on those services, but I vaguely remember that I used a bech32 address to send some Bitcoin to Binance a while back. Can anybody confirm this? Or does that part mean the ability to generate a bech32 receiving address only?
Please correct me if I am wrong but I think Trezor hardware wallet now supports Bech32 and Coinbase exchange also, but I will have to double check everything from that list and update.
You can send from Binance exchange to Bech32 wallet address, but you can't generate Bech32 address on Binance and that means you can't receive.
Here's another source that covers more services: https://bitcoinops.org/en/compatibility/.
I'm a bit confused by the Create/Receive part. At first I kinda get the impression that the transaction made from the bech32 address won't show up on those services, but I vaguely remember that I used a bech32 address to send some Bitcoin to Binance a while back. Can anybody confirm this? Or does that part mean the ability to generate a bech32 receiving address only?
I'm a bit confused by the Create/Receive part. At first I kinda get the impression that the transaction made from the bech32 address won't show up on those services, but I vaguely remember that I used a bech32 address to send some Bitcoin to Binance a while back. Can anybody confirm this? Or does that part mean the ability to generate a bech32 receiving address only?
pooya87 is very right, legacy and nested segwit calculate transaction fee in size which is in satoshi/byte, but native segwit calculates fee in weight which is in satoshi/vbytes.
That's not right. All transaction types should be measured in virtual bytes, but only purely legacy transactions will have identical values in both bytes and virtual bytes.The weight of the transaction makes the fee in native segwit to be reduced than in nested segwit and legacy.
Nested segwit still has a lower fee than legacy, just not as low as native segwit.Secondly, if you are sending from native segwit address to non-native segwit address, the transaction fee will still be high, the only time the fee will be low is when you are sending from native segwit address to native segwit addresses.
Again, that's not right. An input contributes much more to the transaction size than an output. Using segwit inputs will still save a great deal of fees, regardless of what type of outputs you are sending to.You can just play around this tool I made to confirm everything o_e_l_e_o said about inputs, vbytes, transaction vsize, etc
You can just enter the number of inputs/outputs, address format, etc and you will see how it works and how much you can save on fees by ypgrading to p2sh-segwit or bech-32.
Are all the problems technical (lazy exchanges and wallets,) or did Bech32 addresses have some problems as there was no specific standard for signing the message.
I can't speak for the centralized exchanges (and since some centralized exchanges have implemented it without issue then there is no good reason the others cannot also), but for Bisq there are issues regarding the bitcoinj library. They are being actively worked on: https://github.com/bisq-network/proposals/issues/226pooya87 is very right, legacy and nested segwit calculate transaction fee in size which is in satoshi/byte, but native segwit calculates fee in weight which is in satoshi/vbytes.
That's not right. All transaction types should be measured in virtual bytes, but only purely legacy transactions will have identical values in both bytes and virtual bytes.The weight of the transaction makes the fee in native segwit to be reduced than in nested segwit and legacy.
Nested segwit still has a lower fee than legacy, just not as low as native segwit.Secondly, if you are sending from native segwit address to non-native segwit address, the transaction fee will still be high, the only time the fee will be low is when you are sending from native segwit address to native segwit addresses.
Again, that's not right. An input contributes much more to the transaction size than an output. Using segwit inputs will still save a great deal of fees, regardless of what type of outputs you are sending to. Quote
Native Segwit adoption is on the rise
i'm curious if there is any data to support this, i thought it plateaued a while ago.I made a quick google search and found something herE:
https://transactionfee.info/charts/payments-spending-segwit/
Segwit adoption is still growing. In January 2020 there was 60% adoption, now we have 66%.
it is natural that growth will be slower from now on, as most transactions are already done by segwit. It was easy to jump from 10 to 20%, but it will be much harder to jump from 66-76%. But we are doing fine I guess.
Thank you for explanations.
Thank you for noticing that Breadwallet now supports bech32.
I corrected and removed it from the list.
For now you will know wallet is supporting Bech32 if it's not on this list
This is explanation Chipmixer gave to me:
i'm curious if there is any data to support this, i thought it plateaued a while ago.
Sure there is, and if you look you will see I posted Bech32 statistics link in first post.Bread wallet fully supports bech32 since 2018 according to their tweet https://twitter.com/BRDHQ/status/1063513088069173249
Another post from reddit that uses the same wiki source proves it https://www.reddit.com/r/Bitcoin/comments/ba1l79/switch_to_bech32_native_segwit_wallets_this_is/
Kinda weird that Jameson Lopp talks about native segwit yet his Casa wallet doesn't fully support it. Is he waiting for Taproot and Schnorr based on this tweet https://twitter.com/lopp/status/1261323165726380036
Yes it is weird his Casa wallet is still on the list Another post from reddit that uses the same wiki source proves it https://www.reddit.com/r/Bitcoin/comments/ba1l79/switch_to_bech32_native_segwit_wallets_this_is/
Kinda weird that Jameson Lopp talks about native segwit yet his Casa wallet doesn't fully support it. Is he waiting for Taproot and Schnorr based on this tweet https://twitter.com/lopp/status/1261323165726380036
Thank you for noticing that Breadwallet now supports bech32.
I corrected and removed it from the list.
I will advice you to also list the wallets that are supoorting native segwit addresses to be included, because the wallet people will be looking for are the ones that support native segwit, and going through your topic can make them easily identify wallets that support native segwit.
I was thinking of making that list, but maybe later.For now you will know wallet is supporting Bech32 if it's not on this list
Are all the problems technical (lazy exchanges and wallets,) or did Bech32 addresses have some problems as there was no specific standard for signing the message.
Also, not updating does not mean that they are lazy, but they may not want that, as many of these platforms promote altcoins, and therefore it is in their interest to keep fees slightly high so that there is a logical reason for using altcoins.
If Bech32 addresses have some problems, then Legacy and Segwit addresses also have their own problems and excuses like altcoins is not good enough, but sure, some services just don't want to support Bech32 for various reasons and to me it looks a bit lazy Also, not updating does not mean that they are lazy, but they may not want that, as many of these platforms promote altcoins, and therefore it is in their interest to keep fees slightly high so that there is a logical reason for using altcoins.
This is explanation Chipmixer gave to me:
Quote
We are not supporting Bech32.
We are aware of advantages it gives but we support customers that use old wallets.
Deposit address is legacy address. Chip address is legacy address.
You can send Bech32 -> legacy, receive chips and sweep them to Bech32 address.
We are aware of advantages it gives but we support customers that use old wallets.
Deposit address is legacy address. Chip address is legacy address.
You can send Bech32 -> legacy, receive chips and sweep them to Bech32 address.
pooya87 is very right, legacy and nested segwit calculate transaction fee in size which is in satoshi/byte, but native segwit calculates fee in weight which is in satoshi/vbytes. The weight of the transaction makes the fee in native segwit to be reduced than in nested segwit and legacy.
Secondly, if you are sending from native segwit address to non-native segwit address, the transaction fee will still be high, the only time the fee will be low is when you are sending from native segwit address to native segwit addresses.
Secondly, if you are sending from native segwit address to non-native segwit address, the transaction fee will still be high, the only time the fee will be low is when you are sending from native segwit address to native segwit addresses.
I will list and keep updated here all lazy exchanges and wallets and other services not (fully) supporting Bech32:
I will advice you to also list the wallets that are supoorting native segwit addresses to be included, because the wallet people will be looking for are the ones that support native segwit, and going through your topic can make them easily identify wallets that support native segwit. 
Are all the problems technical (lazy exchanges and wallets,) or did Bech32 addresses have some problems as there was no specific standard for signing the message.
Also, not updating does not mean that they are lazy, but they may not want that, as many of these platforms promote altcoins, and therefore it is in their interest to keep fees slightly high so that there is a logical reason for using altcoins.
Also, not updating does not mean that they are lazy, but they may not want that, as many of these platforms promote altcoins, and therefore it is in their interest to keep fees slightly high so that there is a logical reason for using altcoins.
According to the source you provided, exchanges don't seem interested in SegWit implementation. It is not surprising at all since almost all the centralized exchanges make money on trading and listing shitcoins, especially they prefer the trendy ones such as DeFI scams, ICO scams and the like. Their motto is "I love bitcoin, buy my shitcoin". They want us to gamble on thousands of useless cryptocurrencies. Bitcoin is merely bait, that is why everything exchanges offer regarding bitcoin will likely remain obsolete, inadequate and undeveloped.
Bread wallet fully supports bech32 since 2018 according to their tweet https://twitter.com/BRDHQ/status/1063513088069173249
Another post from reddit that uses the same wiki source proves it https://www.reddit.com/r/Bitcoin/comments/ba1l79/switch_to_bech32_native_segwit_wallets_this_is/
Kinda weird that Jameson Lopp talks about native segwit yet his Casa wallet doesn't fully support it. Is he waiting for Taproot and Schnorr based on this tweet https://twitter.com/lopp/status/1261323165726380036
Quote
SegWit support has arrived to BRD
As you know we are building for the future. As of today, BRD fully supports native SegWit (Bech32).
As you know we are building for the future. As of today, BRD fully supports native SegWit (Bech32).
Another post from reddit that uses the same wiki source proves it https://www.reddit.com/r/Bitcoin/comments/ba1l79/switch_to_bech32_native_segwit_wallets_this_is/
Kinda weird that Jameson Lopp talks about native segwit yet his Casa wallet doesn't fully support it. Is he waiting for Taproot and Schnorr based on this tweet https://twitter.com/lopp/status/1261323165726380036
Bech32 or Native Segwit addresses (starting with bc1) are getting more popular and growing in numbers every day because of smaller size and cheaper fees for transactions.
you are thinking of "weight" not "size". SegWit transaction sizes can be bigger compared to legacy ones and specifically be a lot bigger when the nested SegWit is used instead of native ones. but since fees are calculated based on weight and SegWit transactions have lower weight in comparison, you end up paying less fee.Quote
Native Segwit adoption is on the rise
i'm curious if there is any data to support this, i thought it plateaued a while ago.Quote
and many wallets and exchanges are supporting it, but not all of them.
at this point any tools or services that don't support a useful feature that was added to the protocol 3.5 years ago should be considered insecure to use because it means they are either incompetent to upgrade their system even after all this time or they are malicious and don't want to upgrade.
Bech32 or Native Segwit addresses (starting with bc1) are getting more popular and growing in numbers every day because of smaller size and cheaper fees for transactions. (Full Bech32 stats HERE.)
Native Segwit adoption is on the rise and many wallets and exchanges are supporting it, but not all of them.
I will list and keep updated here all (lazy) exchanges and wallets and other services not (fully) supporting Bech32:
Native Segwit adoption is on the rise and many wallets and exchanges are supporting it, but not all of them.
I will list and keep updated here all (lazy) exchanges and wallets and other services not (fully) supporting Bech32:
| | | Wallet
Jump to:
|