Topic: Pieter and Greg, Bech32, please - page 2. (Read 1057 times)

I am inclined to fully cheer many of the improvements.  I agree that being able to detect the location of typos is valuable.  I just hope we're not losing user friendliness to get this.

Having produced tens of thousands of Casascius coins, I don't think there's any question whether I've had experience using Bitcoin addresses, and I confirm I'm human


This is true if we're talking about the "data" portion -- the "prefix" portion seems to require a "1" as a separator.  What part did I miss that is so disappointing?  The casual user is going to just see that 1s and Ls both appear in addresses and, not being a BIP reader, will likely never be aware of the "separator" purpose, nor learn or detect or benefit from figuring out that 1s only appear before a data portion.  On the surface, adding this confusing pair looks like a step backwards.

If it were me, I'd have allowed the prefix to be opposite cased, e.g. BTCqw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4, both adding salience and obviating the need for a separator and making room for the T which I hope wouldn't be confused for currency just by adding a T (how many BTC could this sample test address be confused for in the maximally confusing case?  I couldn't tell at a glance).

If the 1 and the L could be gotten out of the set of valid characters (to appear anywhere in an address), I'd be far less motivated to put energy into suggesting the human element hasn't been cared for.  Couldn't b be put back in its place?  Does b really resemble some other character more than L resembles both I and 1 in many common fonts?  What font has a b that realistically be confused for another character?

The HRP and data delimiter needs to be a character which is outside of the character set-- this is because the HRP can contain characters both in and outside of the charset, so to find the boundary we need the last character of it to be outside of the set.  The delimiter must also must be alphanumeric to preserve single click copy in many environments (including browsers).  So this left us with using one of bio1, or changing the character set to be more visually confusing and getting a different option.  In the vast majority of contexts the prefix is completely fixed by the application usage, so there is no possibility of confusion in any case.  

Right, among the options it had that advantage and it was also the one that was least visually confusing.

This is what many people report, and even people that said they didn't mind it handled it much more slowly.  My general experience from when we stared on this was that people who said mixed case wasn't an issue changed their mind after actually trying to convey an address view spoken word or writing it down by hand with pencil and paper. ... Either they had never done it before or had done it infrequently enough that they'd already repressed the traumatic memories. I don't doubt that there are some odd people out there which never have any trouble with it, but I haven't encountered anyone yet who doesn't when actually tested on it.


the table and its use however can be one line of code.  I think one line of code is a pretty good trade-off  for improved error detection.  The base conversion for bech32 and checksum code are each easily 1/10th the code/size of base58 handling too. I think the cost of a little lookup table is easily paid for by improvements in other areas.

(The mapping is such that the most likely confused characters tend to result in only a single bit-flip and the code is designed so that it is slightly stronger in those cases than advertised).


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.

Bech32 is designed for human use and basically nothing else, the only consideration for QR codes is that all caps is also permitted.

For all your talk of human considerations you give a strong signal of having seldom actually used bitcoin addresses as a human.   1/3 type addresses are full of visually confusing characters and the case modulations are a pain to read and enter correctly.  In actual testing transfering bech32 addresses to another person is on the order of 5x faster with bech32 due to errors being made even in careful usage of base58-- more than the time itself transferring a base58 address is often insanely frustrating-- you read it, and ... nope, no idea where it's wrong, only that it's wrong -then you try reading the whole thing again and again and again.

Bech32 largely solves that both because it is MUCH easier to read correctly, less visually confusing, and because when you make just a single mistake it can tell you where it is.

First, Bitcoin invented this field and if you feel that its natural privileged from doing so is "political" then I really don't see a need to continue discussion with you.  If you don't want to put Bitcoin first that's your decision and not something I mind, but don't you dare demand that people who have more or less dedicated their life to it to do worse work on Bitcoin in order to facilitate whatever competing systems that you prefer.

Secondly, we actually made significant design considerations specifically to facilitate altcoins. Earlier versions of the design restricted the HRP to the same character set as the data, and so there was no character set that wouldn't have permitted many altcoins from using their favorite monikers (e.g. no LTC given our charset due to the use of L).  We wanted implementer of multicurrency software to be able to use the same code for many systems; while we're not going to degrade things for bitcoin we actually did go out of our way to design something that was very generic and inclusive-- even though doing so is probably not the best competitive approach for Bitcoin... it probably would have been better to set it up so altcoins would require incompatible code so software would be less likely to implement support for them. Too bad you're too blinded to see it.


I guess you missed this part of nullius' reply?

I sincerely hope you're right, bring on the Lightning, and I hope it's user friendly and meets the needs of most people, especially non technical people, and minimizes their demand on that 1MB of block space as much as possible.

My Bitcoin Porsche is almost 5 years old and I still thoroughly enjoy driving it.  Chocolate cake makes managing my weight a little hard but I'll enjoy that when I can too.  My heart will race for Bitcoin Core again when I see a credible solution to this fee problem.

Uh-huh.  Okay, I got it now—loud and clear.

Myself, I would “applaud” having free chocolate cake and a Porsche.  But there is a word for people who expect to consume precious resources without somehow paying for them.  The word is not “neurotypical”; the word is “retarded”.

Byzantine fault-tolerance is costly, and proportionately so as to the actual usage of the network.  Therefore, amongst “cryptocurrencies” thus far, the choices are these:  (0) Centralized, popular, and cheap.  (1) Decentralized, unpopular, and cheap.  (2) Decentralized, popular, and expensive.  Those, plus all similar variations except for decentralized, popular, and cheap.

Thus far, all Bitcoin competitors with low fees have either a relatively much lower demand for transactions (unpopular), actual or potential centralization, or both.  Bitcoin also had low fees when it was unpopular.  After Bitcoin beats down a few more attempts at centralizing hostile takeover (as it did last month, too), Lightning will see Bitcoin lead the way, yet again; but meanwhile, loudly wishing for “decentralized, popular, cheap” on-chain does no more good than my sincere wishes for a Porsche.  Right now.  I want, gimme!  The address is in my signature.

But surely, the average deadweight mass of gelded cud-chewers don’t much care about decentralization.  They’ll take Visa Platinum, Mastercard Platinum, or “Bitcoin Platinum With Ponies”; and it’s all the same to them.  They’ll also use Google and Facebook without a second thought, no matter how much you scream at them, “You are the product.”  They give never a thought to Cloudflare.  They want their dancing pigs; and they want that fast and cheap, the latter only being evaluated through the myopia which sees no hidden costs.  Insofar as I must deal with that type, the blissful slave, my objective is not to cater to them, but to persuade, cajole, or shock-prod them where I need them to go.

But of course, you’re not exactly new around here.  You knew all the foregoing—except perhaps that last, which is personal as to me.  For my part, I suppose that I learn something new every day.

As for this:


FYI, Bitcoin no longer has 1MB blocks:


HTH; after all, it’s still the Technical forum, no matter how much junk I trip over here nowadays.

Neurotypical users will probably applaud having the transaction fees back under $1 before they give accolades for typo correction.  Core will lead the way in most efficient usage of pixels in a QR code, while economic forces make winners of the alt coins that don’t charge $30 in fees to do a simple transaction.

I wonder what will become of the Core blockchain when the miners defect to a more profitable chain that is still useful for payments and never come back. They won’t come back until it’s profitable but that never happens because no one will buy Core coins while 1MB blocks are hours or days apart with the next difficulty adjustment suddenly becoming months away.  In such a scenario no transactions can confirm for anyone besides millionaires insensitive to astronomical fees they’ll pay in the absence of any other choice. And at that point, Bitcoin “led” the way becomes the more popular consensus.

Objectively, “neurotypical” users will be helped by an error correcting code which permits software to point out to them where they are likely to have made a mistake.  That alone makes worthwhile a switch away from addresses checksummed with truncated-double-SHA256, in my opinion.  Also, I can personally attest that a “neurotypical” user has serious difficulties with mixed-case pseudorandom strings.  That’s the sort of design which leaves me cursing at things made more for the convenience of computers, than for the safety and sanity of humans—cursing whilst I back up and try the damn thing again, in some use cases on try 3/3.

I have some pie-in-the-sky, 1/65536th-baked ideas about crossing identity-based encryption with privacy-preserving payment codes and (waves hands) to neuter the central authority.  Someday....  I think everybody serious in this space has dreams of “squaring the triangle”; at least it’s more stylish than trying to build perpetual motion machines or recursive compressors.

As for what you said about developers being “likely to prioritize having things fit neatly into binaries”—yes, I get it.  I hope you caught my self-directed sarcasm about ASCII offsets in a base32 alphabet.  Well, I think I can squeeze in a lookup table.  No, better yet:  I’ll grab sipa’s code, review it, and call it a day.  That way, the wetware gets its confusables carefully arranged for maximal error detection.  But for revenge, I shall still get my jollies by changing case with bit-twiddling 0x20, etc. instead of calling the appropriate C library functions.  Hah!  The warm, squishy anthropoid lusers will never even know what I just did there.

Bech32 is a huge UX improvement.  Most of BIP 173’s implicit motives and explicit rationales cater to human needs.  I have no doubt that Bech32 will make Bitcoin addresses easier (or at least, less painful) for the overwhelming majority of “neurotypical” users—especially for the legions of future newbies who have not been biased through being emotionally accustomed to old-style addresses.  As such, I don’t get your comment about altcoins.  Bitcoin leads the way here, again.

“Objective” has the clearest meaning  when there is only one single lens to look at things. Personally I prioritize usability for the world population of “neurotypical” users badly needing financial innovation over saving a few CPU cycles or memory bytes or key space in a place users don’t notice.

Developers are more likely to prioritize having things fit neatly into binaries.  That makes computers and developers happy and sometimes users too.  I am pretty comfortable with base32 strings myself with dev experience of my own. But if Bitcoin’s purpose is to be a coin for developers, so that other developers with UX awareness can tell the rest of Bitcoin’s story with their successful alt coins that actually deliver the functional comfortable cryptocurrency experience the world is waiting for, then Bitcoin can claim its rightful chapter in history as a solid success

By an “objective reason”, I meant something along the lines of:  “Truncated 32 bits of double-SHA256 is a bad choice for a checksum, because it has no error correction, relatively poor error detection, terrible performance (time cost)—overall, it’s a choice much inferior to a simple CRC-32.  Its only advantage here is that it’s a hammer you already have in your toolbox; the disadvantage thus is that everything starts to look like a nail.”  A significant technical flaw would certainly warrant some discussion.


True, that’s a particularly awful pair of confusables.  I’ve been thinking on what you said about that.  Fortunately, “1” (one) is not part of the Bech32 base32 alphabet and is never valid in the data part; therefore, I think perhaps there may be a special corner-case for error correction:  When the character “1” (one) is encountered in an invalid Bech32 string, in a position where substituting an “l” (ell) would produce a fully valid Bech32 string including a valid checksum (and only a single such substitution is required), then perhaps automatic error correction (or at least suggestion) should occur notwithstanding the specification’s statement that “implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the string an error might be found, without suggesting the correction to make.”

Of course, as you said in your original post, I would not expect users to remember (or even know) the distinction between a “separator” and a “‘data part’ base32 alphabet character”.  My idea here is that maybe implementers should consider autocorrecting this one specific case.  A similar case may apply where no separator at all is encountered, and a single substitution of a “1” (one) for an “l” (ell) would produce a fully valid Bech32 string.

Thoughts from devs/implementers/UX experts?  Should I perhaps mull a concise way to state this in a revision to BIP 173, or would that just be opening a can of worms with (infinitesimal) potential for sending funds to nonexistent addresses?

So as for ells and ones.

Obviously, in this scenario, there are some matters of taste.  I myself am accustomed to base32 identifiers, so it’s easy for me to take to another one.  I suppose that someday, those old-style addresses will be beyond the realm of nostalgia—more like museum-quality antiques; albeit functional ones, for the people with coins in really long-term cold storage.

For my part, I see Bech32 as a positive sign that Bitcoin continues to lead with innovation in a field it created, that of “cryptocurrencies”.  Bech32 already has some uptake amongst altcoins, at least those with a Segwit implementation.

I hope that Bech32 works out for you in your real-world usage, however you find most comfortable to case it.


Hey, I’ll admit to that, too!

I literally have no “objective” reason (is there truly such a thing?). Just my opinion.  Having a code contain 1s and lowercase Ls simultaneously by design is, in my opinion, an obvious UX nightmare that Satoshi did well to explicitly avoid and hardly needed to explain because the potential for confusion requires little such explanation.  And the fewer charts you have to memorize to understand cryptocurrency today, the better.  Again, my off-the-cuff opinion with zero research referenced because I think this is obvious.

Having two characters BC represent Bitcoin also feels political, as though it is an effort to pretend that there aren’t alt coins with significant merit.  If Bitcoin’s contribution to the world is a technical proof of concept of currency on a blockchain with a low priority on user experience so someone else can carry the win across the finish line, so be it — I’ve structured a few projects like that and still considered them valuable successes.

It is not too late to make the prefix 3 characters, the world at large has barely heard of this new address format let alone bought in to it.

I will be happy to use Bech32 if I need to.  I am happy it lets me print it in uppercase and that alone solves my issue with L and 1, and I trust that auto-substituting 0 vs O is an auto correction that UIs can safely and easily implement regardless of recommendations.   I am satisfied that in the long run, alt coins will satisfy the market demand for a quality user experience if and when the original project fails to.  I love Bitcoin (a feeling I will admit I am caught up in) and hate seeing us leave easy-to-solve pain points on the table as opportunities for alt coin teams to look brilliant for fixing.

casascius, with all due respect, I don’t see any argument here other than sentimental attachment to the appearance of old-style addresses, plus a few relatively minor quibbles about confusable characters.

I will address the latter first, since it is a technical issue.  Any selection of characters for such an application will always involve tradeoffs of excluding worse confusable pairs, whilst regrettably tolerating some less confusable pairs.  Of course, making that distinction cannot be what I’d call an exact science.  BIP 173 set forth its rationale on this point; do you have any objective reason to contradict the research it cites?

As for the “flavor”, as you put it, I don’t mean to be derogatory.  You yourself characterize it as a matter of “affection”.  But it’s just that.

A colourable argument might be here interjected on grounds of marketing.  But really, from the coldest marketing perspective, how many actual Bitcoin users do you propose to be attracted by the “look” of the addresses?  You speak rather derisively of “a whole legion of Bitcoiners who scan URI-less QR codes at PAL resolution with VHS cameras and 6502 processors are leading the charge to change Bitcoin so they never have to upgrade past the pre-Internet as they send their Bitcoins off a 64K floppy disk.”  But I think here, you have it backwards:  Persons fixated on the look of the address will be a marginal minority, frankly stuck in the past and resistant to technological improvements.  I suspect that unfortunately, most Bitcoin users care neither about the look of the address, nor about its technical functionality—in other words, they agree neither with you nor with me.  They scan QR codes, they think about money, and as most people generally, they contentedly chew their cud in the Coinbase corral.  The form and function of Bitcoin addresses is really a non-issue here.  I’m more worried about how many don’t care about decentralization, fungibility, permissionlessness, privacy—freedom.

I will meet you halfway in positing that the human-readable prefix “btc” would be better than “bc”, at the expense of an extra character which transmits no data.  The string “btc1” now carries some rotten baggage; but Bech32 antedates that wretched idiocy and will long outlive it, just as the same applies with its use of the “BCH” error detection algorithm which is its namesake.  “btc1” with the separator also seems an homage to the old-style P2PKH addresses; indeed, I have a tiny suspicion that the reasons for choosing “1” as a separator were not wholly technical.  That warms my heart, and might even mollify you a bit.  I suppose “bc1” sort of does that, too; and hey, it saves a character!  Of course, this is an issue only with the specification of Bech32 addresses for Bitcoin, and not with the Bech32 format itself.

Returning to technical issues:

I think you far underestimate the difficulties caused by mixed case, especially for persons accustomed to non-Latin writing systems—or for anybody with fingers for typing, plus a labile human central nervous system which cannot reliably process and transmit patternless pseudorandom data at all.  The human brain finds it easy to follow the patterns natural-language capitalization rules; to add capitalization to gibberish only adds the dimension of an extra variable to keep on the squishy wetware mental stack.  For your anecdote of being just fine and dandy with the mixed case, I will raise you my anecdote that I hate it, I can’t handle it—I find it absurdly frustrating and error-prone.  Surely an expert in human-computer interaction will weigh in here; do you wish to place bets (gentlemen’s wager) on whose side that evaluation will support?

Satoshi was a genius.  But let’s admit it:  He had a few quirks.  The propensity to use (truncated double-)SHA256 where inappropriate is one of them; and Bech32’s change of checksum removes one of those niggling little flaws which always irritated me amidst such an ingenious creation.  And that base58 you so adore—well, I love it not; and I doubt I’m alone there.  I think there are exactly three people in the world who are enamoured of base58 for use in a binary-to-ASCII encoding system; and now we have enumerated two of them, you and Satoshi.

I’ll admit, as a C programmer, I am a tiny bit annoyed by the Bech32 choice of alphabet.  It’s not in ASCII order!  The stupendous inconvenience of a lookup table is required for decoding, rather than simple arithmetic from offsets as in RFC4648 base32 alphabet!  Horrors!  Well, I do suppose that I, too, can be annoyed by Bech32’s kindly consideration of squishy humans and their errors.  I recognize that regrettably, I have just made what is perhaps overall the single most myopic anti-Bech32 argument ever yet proposed.

I will here “truncate” this flow of words, for I needn’t here (double-SHA256) rehash the rationale of Bech32 design choices.  BIP 173 already did that, and did so at least adequately to persuade me.  Well, it did more than that:  The Bech32 format is so superior technically that it made me realize, on a deeply personal level, just how excited I can be made by an address format.[1]  To be fair, I there mirror your pained nostalgia for the old format.  Also to be fair, I admit that I am odd.

Please give Bech32 a chance to grow on you a bit.  If you keep an open mind and try it for awhile without bias, I think it will win you over.

---

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.

casascius,

It is already too late. Bech32 is used in the wild and reversing it would make much more mess than keeping it. And I personally believe this is a much cleaner solution than the withdrawn BIP142 https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki (addresses starting with letters? Come on)

If you mess up "1" and lowercase "l", the address will be invalid, so no real danger with confusing them. Yes, this is probably not the best what could have been designed but everything else is an improvement.

And you know that you can use bech32 all capitals?

I'm writing this here knowing it doesn't belong here (surely some other forum is more proper) but the words are coming to me so here's as good a place as any to draft this.

Bech32, please don't do it as written.  At least, please consider the carbon-based units in the Bitcoin ecosystem.  Us, like you and me.  The ones that provide the emotional component necessary for Bitcoin to succeed.  Bitcoin is succeeding not for being technically good alone, it's also got to remain compelling and salient and friendly and intuitive.

Reading about Bech32 leads me to believe that a whole legion of Bitcoiners who scan URI-less QR codes at PAL resolution with VHS cameras and 6502 processors are leading the charge to change Bitcoin so they never have to upgrade past the pre-Internet as they send their Bitcoins off a 64K floppy disk.  Everyone I know with a solid grasp of the alphabet is fine with mixed upper and lower case, and every mobile phone that can run a Bitcoin client also scans QR codes much larger than a Bitcoin address, reliably, without exception.

The Base58 pattern with a fixed prefix is very visually distinct and a welcome salience cue for cryptocurrency.  Going lower case and totally trashing that visual distinction frustrates us like Coca Cola deciding to change the flavor forever without asking us.

Please save us from having to learn a whole new set of heuristics just to recognize what our string of ASCII-coded binary stands for.  The address string with an approximate known length starting with 1 or 3 has worked for us so far.  If we have to learn it all over again, can it be something we already know?  Why "BC" for Bitcoin?  Could we have capital "BTC" or "XBT" followed by mixed case data. Our mobile phones have enough pixels to accommodate this extra character and definitely so do our minds if it can save us from learning not just 3-letter, but now 2-letter acronyms for each cryptocurrency project.

Please give us an encoding that spares us the confusion of having the lowercase letter L and the number 1 all in the same code.  I'm sure I will remember whether addresses always contain O's versus zeroes, ones versus L's, but I feel awkward expecting others to.  It sounds like "ok, so that's a "B-C-one, but after that first one, addresses never have any more ones, it's always an L after that one one, and we do it this way so it's less confusing".

Please let us keep our mixed case.  Trust us, we've got capacity for it, and so do our QR code libraries and our printers and displays.  If we're speaking codes the phone, our friends can handle the words "capital" and "lowercase" before each letter just fine.  Changing that conversation to "well I think it's an L after the zero, not sure if that's a 1 after an o, where are my glasses, maybe try both?  It didn't work?"... I hope it's easy to see how this is actually more frustrating.

Yes, we'd love it if we get error correction just in case we make typos and screw things up.  We don't want to send our money to the nether nulls either.  It's just, there are other pitfalls impacting our affection and wallets with a much greater damage coefficient than 1 over 4 billion, so changing how addresses look doesn't reassure us or feel like progress, rather how it feels is it steepens our learning curve.

If you let us move forward with you on a new address format, while maintaining our beloved Base58 (our CPU's still love us and are happy with the long division and the extra work parsing the mixed case), could I ask one favor?  Would keeping mixed case shorten the code enough to make extra room to pretend (for the sake of error correction) that each character has 64 possible symbols?  We could dedicate another character or two to the checksum to make up for it.

If it did, could we pretty-please have "Bech58" that maintains our mixed case look?  58 is not a round square number, but we're Bitcoin, we have our style, and we have a few billion in market cap to be able to afford a few CPU cycles to make our b-58 shine and make people think of their one and only true love of Bitcoin (or at least about money) when they see beautiful mixed base58 as a string.

Pieter and Greg, I know you'll settle for no less than a perfect Bitcoin improvement proposal and you have my respect.  Thanks for listening.

Can someone who knows better than me where a plea like this belongs, either copy it there or link to it here from there?  Thanks