Topic: SegWit, Industry standard for the future? (Read 594 times)

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.

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.

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.

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.



 

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.
 

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


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.

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


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

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

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


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


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


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.


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.

Quote from: Kakmakr on February 26, 2018, 03: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://bitcointalksearch.org/topic/about-possibility-to-sign-messages-in-segwit-address-in-future-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, 11:38:12 AM

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, 03: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 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.

---

Quote from: Kakmakr on March 05, 2018, 02: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 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.

---

Quote from: FrueGreads on March 05, 2018, 12: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, 12: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 6–12 months.  Future viewers of this post will see my signature showing an address which starts with “bc”.

Redux:

Quote from: nullius on December 23, 2017, 10:35:29 PM

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

---

Quote from: Kakmakr on March 06, 2018, 12: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.