[Not-for-profit advertisement: I have an idea for a user education PR campaign to familiarize people with Bech32 addresses. But I cant do it alone! Those who are interested in helping smooth the way to full Segwit adoption should feel free to contact meespecially those in the webdesign, hosting, and graphical departments.]

Quote from: theymos on February 27, 2018, 12:31:18 PM

The best practice currently is to give people P2SH SegWit addresses when people are paying you, but to support/allow sending to bech32 addresses when you're paying people. bech32 addresses are strictly superior except for issues of backward-compatibility, so eventually everyone will switch over, but it'll probably take a few years; it shouldn't be a format war situation unless someone decides that they hate bech32 and come up with a totally new alternative.

First, I want to expand on why what I call Bravo Charlie addresses are strictly superior:

0. Bech32 addresses have error-correcting codes, which make them far more resilient against human mistakes typical when transcribing long pseudorandom strings. Together with a radix-32 alphabet designed based on scientific data about visual confusability of letters, the error-correction was extensively tested for increased usability of Bitcoin addresses by actual humans:

Quote from: gmaxwell on December 22, 2017, 06:31:11 AM

Quote from: nullius on December 21, 2017, 12:03:06 PM

1. My regards to Pieter Wuille and Greg Maxwell: I can tell that an excruciatingly detailed thought process about Bitcoin address formats went into that bit of engineering. Somebody stayed up in the dark wee hours, pondering the philosophy of Bitcoin address formats. Somebody aspired to consummate perfection in the art of Bitcoin address formats. Well, you are probably also odd. Coming from me, take that as a compliment.

Thanks, including a lot of testing with both people and machines, several CPU decades went into the design of the error correcting code... and in fact the techniques even required to be able to measure their performance are themselves novel and probably publishable innovations. Not to mention extensive review and redesign with many other similarly crazy people. We understood that introducing a new address format is a big step that can't be done often, and thought it would be appropriate and acceptable to really work hard on it.

1. Bech32 addresses are case-insensitive. This alone makes them far more usable than base58check for humans who sometimes do need to transcribe addresses by hand.

2. Using Bech32 addresses saves a small amount of block space (while helping blocks grow larger due to the BIP 141 weight unit calculation used by all Segwit transactions). By contrast, backward-compatible nested addresses (starting with a 3) actually result in use of more bytes of block spacealthough they still helps the network compared to non-Segwit, and you still save on fees, again due to the weight unit accounting. Quoting a simple explanation from Cores blog, with my notes added in green:

Quote from: Bitcoin Core

The segwit transaction formats (see BIP 141 - witness program) have the following impact when serialised:

Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the scriptPubKey, and the same number of witness bytes as P2PKH scriptSig. [Native Segwit for paying to a key hash, witness version 0. Bech32 addresses starting with bc1q. You want this. nullius]
Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the scriptPubKey, and the same number of witness bytes as P2SH scriptSig. [Native Segwit for paying to a script. It takes more space, due to a drastic increase in security level. Old-style 3-address multisig only has an 80-bit security level against malicious signers, such as an escrow scammer; native Segwit raises that to a 128-bit security level. nullius]
Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%), due to using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig than in P2PKH scriptPubKey, and the same number of witness bytes as P2PKH scriptSig. [This is the backward-compatible 3 address for P2WPKH. You still save on fees, because the weight of witness bytes is so much lower; but the transaction as a whole takes more blockchain space than non-Segwit 1 addresses! nullius]
Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due to using 24 bytes in scriptPubKey, 11 additional bytes in scriptSig compared to P2SH scriptPubKey, and the same number of witness bytes as P2SH scriptSig. [This is the backward-compatible 3 nested address for P2WSH. Is anybody actually using this? nullius]

3. Bech32 addresses are native Segwit. Nested-in-P2SH is a backward-compatibility hack, designed so that Segwit early-adopters can receive money from people who are slow to upgrade.

Wherefore...

Quote from: Kakmakr on February 26, 2018, 08:48:41 AM

A lot of people are moving over to SegWit now. The big question is, which implementation is going to be the standard in the future?

Easy answer: Native Segwit. Bech32. Bravo Charlie One means money. (bc1)

Quote from: Kakmakr on February 26, 2018, 08:48:41 AM

We currently have P2SH addresses or Bech32 addresses ::) Also looks like there are bech32 P2WSH addresses & bech32 P2WPKH addresses. Bloody confusing!

For ordinary end-user requirements in 99% of cases, all you really need to know is that the Segwit nested 3 addresses are backward-compatible so that people with obsolete software can send money to themwhereas native Segwit Bech32 is the Bitcoin address format of the future.

You dont need to worry about P2WSH vs. P2WPKH any more than you worried about P2SH (3) vs. P2PKH (1). Did that ever keep you up at night, wondering which address format to use? Of course not! You simply used P2PKH for 99% of end-user use cases, and P2SH for things like multisig.

Quote from: Kakmakr on February 26, 2018, 08:48:41 AM

This reminds me of the days when we had a VHS and Betamax videotape format war, way back then.

Not even remotely comparable.

I dont know why you think there be some competition. There isnt: The same people (Core) provided two different general types of Segwit addresses for different purposes.

I dont know why you think there be some sort of fragmentation of the market. There isnt: All Segwit addresses are Bitcoin addresses, and are network-compatible with each other! You can always receive money from anybody with any type of Segwit address; and if you have updated software, you yourself can use any type of Segwit address.

I dont know why you think there be some format war. Nested P2SH addresses complement Bech32 by helping ease Segwit adoption.

Did the same people make VHS and Betamax? No. Were they compatible with each other? No. Were they in competition with each other? Yes. The analogy fails on all points.

Quote from: Kakmakr on February 26, 2018, 08:48:41 AM
I find that even signing a message with a SegWit address is still a bit problematic, because different applications handle this differently, based on the format you used. ??? See this topic : https://bitcointalk.org/index.php?topic=2885058

IMO, applications such as Electrum which permit signing with Segwit addresses using their own ad hoc system are highly irresponsible.

There is not yet any standard for signing with Segwit addresses. Work is currently ongoing to create such a standard. It is being done thoughtfully, rather than just slapping something together.

Note that in the thread you linked, achow101 wrote (boldface added):

Quote from: achow101 on February 05, 2018, 04:38:12 PM
It is just that we are still working on creating a more generalized signing scheme that lets people sign with things like P2SH addresses (e.g. sign with a multisig address). There is simply no standard yet for signing with such scripts or with Segwit.

Note that you don't actually sign with an address. You sign with a public-private keypair and your wallet interprets it as an address. Your wallet could just as easily interpret it as a segwit address. We are working on creating something that actually specifies the address type, and more generally, allows signing with scripts.

In my own post on that thread, I linked to several explanatory mailing list posts as well as the pertinent Github issue. I suggest that you follow that (and bitcoin-dev) if you be interested in progress on this work.

Quote from: Kakmakr on February 26, 2018, 08:48:41 AM
Why are we making things so complicated or is this just a temporary solution to push SegWit quicker into mainstream use? Please share your experience and which implementation you used and why you chose to go that route.

I think youre the one who is overcomplicating things. Yes, the situation with exactly two general types of Segwit addresses (3 nested, and bc1 native) is indeed a temporary solution to push SegWit quicker into mainstream use. If Core had restricted Segwit to its native address format with no backward-compatibility option, then Segwit would probably never get adopted due to network effects! For a reasonable transition period, Segwit users do need to be able receive money from those who have not yet upgraded.

Quote from: Kakmakr on March 05, 2018, 07:05:15 AM
The different services should actually give you a choice, what you want to use and not what they want you to use. My local exchange is using P2SH SegWit addresses and Electrum use Bech32 and Ledger use P2SH SegWit addresses. Would it be too complicated to give people a choice between the different formats?

Let the customers decide what they want. Provide the research and information on the two formats and highlight the pros and cons and leave it to the customer to decide. ???

Choice? Except during a transition period, why should users be given a choice between the native Segwit format, and an obsolete format designed for transitional backward compatibility (which has significant technical disadvantages)?

Note: I strongly disagree with Electrums decision to hide the nested P2WPKH/P2SH format. (There is a workaround to create an Electrum wallet with this format; I have posted it several times, and can again if necessary.) The technical-debt argument Electrums author has stated (somewhere on Githublink not handy) is not valid, since Electrum supports it anyway. Meanwhile, Electrum users who dont jump through weird hoops are given the choice between either not using Segwit, or not being able to receive money from people (and major services!) who are not yet able to send to Bech32. Bad idea.

Quote from: FrueGreads on March 05, 2018, 05:39:06 PM
I understand the need for choice, and I agree with it, but at some point users need to be "pushed" into one direction. From what I've heard, the Bech32 are the most efficient ones in terms of memory use, and are a much better option than P2SH. The only reason most segwit adopters offered the P2SH option first, is because they are compatible with both native segwit and legacy addresses, making them perfect for a transitory period. But in the long run, what you really want is to start using the native segwit addresses (Bech32). For this reason I totally skipped the P2SH, and went straight to the Bech32.

I guess we will start seeing a lot of P2SH first, but in the end, we should all use Bech32.

Correct. In one my earliest posts here, I essentially called out 2018 as the year of transition to Bech32 (boldface added):

Quote from: nullius on December 16, 2017, 05:11:37 AM
Bech32 addresses are technically superior to old-style addresses; but they are not backward-compatible, so only people with Segwit support will be able to send you money. I myself hope to switch to Bech32 in perhaps 612 months. Future viewers of this post will see my signature showing an address which starts with bc.

Redux:

Quote from: nullius on December 24, 2017, 03:35:29 AM
Segwit, which activated 24th August 2017 at Block #481824, was a softfork. It still permits old-style transactions. [...] There are two kinds of Segwit addresses:

Backwards-compatible P2WPKH-nested-in-P2SH addresses, [...] There is no way to distinguish whether or not a 3 address is Segwit, just by looking at it. These addresses have some disadvantages, but one important advantage: Every Bitcoin client made in the past few years can send money to them.
Bech32 addresses, which I call Bravo Charlie One addresses because they always start with bc1. [...] But Bech32 has one temporary disadvantage: Only people who have upgraded to the newest software can send money to it. I want people to send me money, so Im still using nested P2SH; I hope to switch to Bech32 in about 612 months.

Meanwhile, since there is no way to tell that a P2SH address is Segwit, I took advantage of the fact that base32check allows the lowercase letter i to show off my passion for Segwit: 35segwitgLKnDi2kn7unNdETrZzHD2c5xh. Cost: 600 CPU-hours on a very slow laptop[/url]. (Usually, that is in my signature together with my bc1qnullnym address.)

(Bech32 forbids b, i, o, and the numeral 1 outside the HRP prefix and separator.)

Quote from: Kakmakr on March 06, 2018, 05:58:01 AM
I do not have a huge issue with services forcing people to use a specific format, but at one stage these services should decide which one should be the standard and go with that. We will never have a standard, if different services push different formats. This is why I am saying, let the people decide which format is the most popular and then transition towards that as a standard or default choice.

The market always decides what they want to support in the long run. I think these services are limiting themselves by not offering a choice. Let's say you prefer to use format "A" and you have to chose between service 1 that are using format A and service 2 that are using format B. You would then choose to use service 1, because they are using format A.

Why do you keep pretending as if there were some competition between these two types of Segwit addresses? There is no competition! The nested-in-P2SH formats are transitional. Bech32 is native Segwit. They have different purposes; but they are all Bitcoin addresses, and are fully network-compatible with each other.