SegWit, Industry standard for the future?

[Kakmakr]

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. 

[1715365249]

1715365249

[1715365249]

1715365249

[1715365249]

1715365249

[1715365249]

1715365249

[FrueGreads]

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.  

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. The core wallet apparently gives you a P2SH by default, so this should contribute for people to use that one more often. I would say that if you can, you should go for Bech32, since this might speed up the process.

As for coinbase I'm quite curious as well, and I still don't know if they are already using segwit or not. If they are, they are probably using the P2SH ones.

[Kakmakr]

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.  

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. The core wallet apparently gives you a P2SH by default, so this should contribute for people to use that one more often. I would say that if you can, you should go for Bech32, since this might speed up the process.

As for coinbase I'm quite curious as well, and I still don't know if they are already using segwit or not. If they are, they are probably using the P2SH ones.

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.

[nullius]

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

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:

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 space—although 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 Core’s blog, with my notes added in green:

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

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)

We currently have P2SH addresses <The ones starting with a 3 and backward compatible to non-SegWit wallets> or Bech32 addresses <Starting with bc1>  ::)  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 them—whereas native Segwit Bech32 is the Bitcoin address format of the future.

You don’t 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.

This reminds me of the days when we had a VHS and Betamax videotape format war, way back then. <I feel so old now>

Not even remotely comparable.

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

I don’t know why you think there be some sort of fragmentation of the market.  There isn’t:  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 don’t 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.

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

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.

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 you’re 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.

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 Electrum’s 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 Electrum’s author has stated (somewhere on Github—link not handy) is not valid, since Electrum supports it anyway.  Meanwhile, Electrum users who don’t 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.

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

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 6–12 months.  Future viewers of this post will see my signature showing an address which starts with “bc”.

Redux:

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 I’m still using nested P2SH; I hope to switch to Bech32 in about 6–12 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.)

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.

[GregoryPorter]

I think it's temporary and was probably implemented slightly quicker than the devs may have wanted due to the increased demand and work load over Xmas. Transaction congestion needed to be eased. Although long term a new solution will need to be found segwit is a needed aid even when operating in the way it does at the moment

[nullius]

I think it's temporary and was probably implemented slightly quicker than the devs may have wanted due to the increased demand and work load over Xmas. Transaction congestion needed to be eased. Although long term a new solution will need to be found segwit is a needed aid even when operating in the way it does at the moment

This is what happens when you do what is politely called “making stuff up as you go along”, or more commonly referred to as pulling it out of your—nostrils.  You should not spread misinformation like this.

A two-phased migration to Segwit was planned at least as far back as 2015.  After playing around with `git blame` on various parts of BIP 141, I finally just grabbed this early pre-BIP draft from the year 2015:

https://github.com/bitcoin/bips/blob/a208f3de00a7a79cf5cdc1731b6f7d166e799e37/bip-codeshark-jl2012-segwit.mediawiki

Wallets will be able to migrate in two phases:

P2SH compatibility

Witness programs are hashed to 256 bit "redeemscripts" which are then hashed to 160 bit P2SH. This format is fully compatible with currently existing wallets that support P2SH. Upgraded wallets will be able to send and receive to and from older wallets without any problems.

Native outputs

Witness programs are hashed to a 256 bit output. This format will not be compatible with older wallets but will require less block space and will have better security due to increased collision resistance.

(Note:  Do NOT rely on this document for any technical information about Segwit.  It is an early draft, presented for historical purposes only.  Much has changed.  Refer to the final BIP 141 for technical information on the Segwit consensus layer.)

Were I to dig further, I could find the original bitcoin-dev discussion of native Segwit vs. nested-in-P2SH.

Segwit was designed thoughtfully, carefully, through the close cooperation of several of the best Bitcoin developers in the world.  It could and should have been deployed much earlier than its eventual activation date of 24 August 2017.  Segwit was delayed, and the whole Bitcoin network suffered detriment, because a canaille of world-class scammers spread malicious disinformation—the latter being backed up by patent ignorance such as you have here displayed.

It is outrageous for you to suggest that anything in the design of Segwit was slapped together “due to the increased demand and work load over Xmas” (!).  Moreover, what you say implies that Core has the amazing ability to travel in time:  After several years of design and development, the consensus layer was activated 24 August 2017; yet due to demand “over Xmas”, they tossed out some temporary quick-fix?  That itself shows how much you know whereof you speak (i.e. NULL).

[Anti-Cen]

This is what happens when you do what is politely called “making stuff up as you go along”, or more commonly referred to as pulling it out of your—nostrils.  You should not spread misinformation like this.

Stop being so rude all the time nullius and try picking on someone you own size like me or did you miss your invitation and don't have control
over this thread so that you can delete what you don't like ?

You keep going off like you are part of a bitcoin plunge protection team and you are on a hair trigger and like to dish it out but run for
mummy when confronted with a few technical truths.

A bit of file compression, chucking it (signatures) to a second files won't keep a 286 on the shelves for much longer no more than doubling the block size
so why are you getting your knickers in such a twist about it and need to resort to name calling.

I see lots of wasted potential with you but your are out to score cheap points and need to give it a rest because your scaring everyone off
and unlike segwit I like to call a byte a byte and not some fictional made up vByte, comes in eight bits it does you know.

Note:  Do NOT rely on this document for any technical information about Segwit.  It is an early draft, presented for historical purposes only.

 

So really white papers and documents are not worth bum paper in effect is what you are saying.

Segwit was designed thoughtfully, carefully, through the close cooperation of several of the best Bitcoin developers in the world

The same "best Bitcoin developers in the world" that did not know that Bitcoin "on-block" would never scale like eight years ago
and now they bring us "off-block" with lightning.

Tell me dear chap, have you ever come across the term "The Butters is too thick" and solutions to obvious problems here does not
impress me too much and your alto-ego can forget the off-topic button because I am not buying it.

[Anti-Cen]

I think it's temporary and was probably implemented slightly quicker than the devs may have wanted due to the increased demand and work load over Xmas. Transaction congestion needed to be eased. Although long term a new solution will need to be found segwit is a needed aid even when operating in the way it does at the moment

Hi Newbie

Yes I agree and see you are being polite but it does not work around here and the bitcoin development team was facing open rebellion in
it rakes unless it got off it's bottom and did something about the miners charging $55 (donation fee) just to store 250 bytes of data
in the block-chain and giving excuses about why just didn't cut it.

Unfortunately you bumped into a member of the waiting committee but not all of us are like that around here and we don't mind debates that
are based on bits or bytes, we are developers after all, says it on the forum title.



 

[amishmanish]

I think it's temporary and was probably implemented slightly quicker than the devs may have wanted due to the increased demand and work load over Xmas. Transaction congestion needed to be eased. Although long term a new solution will need to be found segwit is a needed aid even when operating in the way it does at the moment

Hi Newbie

Yes I agree and see you are being polite but it does not work around here and the bitcoin development team was facing open rebellion in
it rakes unless it got off it's bottom and did something about the miners charging $55 (donation fee) just to store 250 bytes of data
in the block-chain and giving excuses about why just didn't cut it.

Unfortunately you bumped into a member of the waiting committee but not all of us are like that around here and we don't mind debates that
are based on bits or bytes, we are developers after all, says it on the forum title.
 

Dear Newbie, Please don't think that someone who spouts easy to understand conspiracy theories is better than someone who gives you harder to understand technical information.

The reprimand you got is because this forum has a severe problem of newbies coming in and posting all sort of opinions as facts, especially in the technical threads. Members like nullius, who put lot of effort and knowledge into their posts try to discourage such behavior.

You are intelligent enough to make your own decision as to who to believe. If you are the kind who is not intimidated by competence and don't necessarily feel an inferiority-complex because other people know more, then you will enjoy learning from the people here.
A suggestion: Whenever you find people who put effort and share knowledge in their posts, try to check their post history out. It'll take you to interesting places.

[Anti-Cen]

Dear Newbie, Please don't think that someone who spouts easy to understand conspiracy theories...............

Another member of the waiting committee pops his head in but he's not technical really or he would understand the
reasons for avoiding breaking backwards comparability when code on servers needs changing that broke existing
wallets and everyone needed to get new segwit addresses.

[Clara.Wilfred]

I think this could be equated to the clunky user interfaces we saw when the internet first popped up. I think in time consensus will be reached of which software we choose to implement and we will progress.