Pieter and Greg, Bech32, please

[casascius]

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

[PVminer]

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?

[nullius]

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]

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.

[nullius]

I literally have no “objective” reason (is there truly such a thing?). Just my opinion.

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.

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.

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.

I love Bitcoin (a feeling I will admit I am caught up in)

Hey, I’ll admit to that, too!

[casascius]

“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

[nullius]

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

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.

[casascius]

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.

...

As such, I don’t get your comment about altcoins.  Bitcoin leads the way here, again.

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.

[nullius]

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.

...

As such, I don’t get your comment about altcoins.  Bitcoin leads the way here, again.

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.

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:

[...blah...] Core [...] 1MB blocks [...blah, blah...]

FYI, Bitcoin no longer has 1MB blocks:

Code:

/** The maximum allowed weight for a block, see BIP 141 (network rule) */
static const unsigned int MAX_BLOCK_WEIGHT = 4000000;

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

[casascius]

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.

[gmaxwell]

At least, please consider the carbon-based units in the Bitcoin ecosystem.  Us, like you and me.

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.

The Base58 pattern with a fixed prefix is very visually distinct

BC is considerably more visually distinct; and it's something the Bitcoin network can stick with-- presumably forever.

cue for cryptocurrency

Some of the most popular alternative cryptocurrencies do not use base58, including Ethereum-- it uses hex.

trashing that visual distinction

Any new scheme would need to use a different prefix apart from 1 and 3, and would get confused with other cryptocurrencies.  Morever, other cryptocurrencies squat 1 and 3  (bcash and litcoin p2sh for example) and, in fact, will falsely accept Bitcoin addresses and vice versa with disastrous consequences.

string with an approximate known length starting with 1 or 3 has worked for us so far.

It cannot be that, and even if it were, those values are now ambiguous.

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.

BC is self explanatory, BTC gets confused with currency units and amounts, and it's longer-- more tying, more room for errors.

but now 2-letter acronyms for each cryptocurrency project.

The HRP can be any length, there doesn't need to be any such 2-letter.

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

We did, the character set does not include "1", "b", "i", or "o"; which is the unique selection which minimizes the number of visually confusing pairs, at least given the NIST visual confusion data we had available to us at the time. ..-- I find it really disappointing that you wrote this long complaint without knowing even this....

A few weeks after publishing BIP173's draft it some academic paper came out where they generated the visual/typing confusion data that I really wanted at the start but which no one had; -- but by then people had wildly started deploying it, even before it had been extensively reviewed... this seems to be a reoccurring problem in Bitcoin.  I haven't rerun the optimizer with the new data, I really really doubt it would reject different characters (the new data is pretty similar) but the permutation might have been somewhat different with it.

Please let us keep our mixed case.  Trust us, we've got capacity for it,

I don't trust, I verify and the mixed case results in worse than a 2x slowdown sharing addresses between humans even when no errors are made, and it greatly increases the number of errors made too.

my glasses, maybe try both?  It didn't work?"... I hope it's easy to see how this is actually more frustrating.

Mature software will tell you _exactly_ where such errors are located, especially if they involve a charset mistake, but even errors beyond that. There should be very little hunt and peck with BECH32, and in my experience there isn't any at all.

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.

Your entire post seems to be motivated by a profound confusion about why this was motivated.  A new address format was _required_ for native segwit outputs, avoiding a new one isn't possible.   Given that we needed a new one we wanted to make it as user friendly as possible, and actually studied user behavior to achieve this.

Incidentally, the 1:2^32 odds of falsely sending to a wrong address is greatly increased by the many retries when people mess up base58 addresses and make speculative corrections... but bech32 wasn't designed to improve the detection of wrong strings (in fact, it only achieves 1:2^30 protection against totally random correct-charset strings) but instead designed to be more pleasant to use by being able to hint where errors are located and not degrade on retry.

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

embedded systems trying to implement bignum libraries for base conversion certainly don't "love" it. (though this can be avoided with even more complex code).

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.

No, it doesn't work that way, and the mixed case is a massive slowdown in actual use by humans.  Of course, computers don't care-- but computers don't care -- the addresses are for human friendlyness, not for computers.

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.

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.

on that 1MB of block space

I guess you missed this part of nullius' reply?

FYI, Bitcoin no longer has 1MB blocks:

[gmaxwell]

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

seems an homage to the old-style P2PKH addresses

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

that I hate it, I can’t handle it—I find it absurdly frustrating and error-prone.

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.

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

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

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.

[casascius]

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

We did, the character set does not include "1", "b", "i", or "o"; which is the unique selection which minimizes the number of visually confusing pairs, at least given the NIST visual confusion data we had available to us at the time. ..-- I find it really disappointing that you wrote this long complaint without knowing even this....

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?

[casascius]

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.

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.

What???  Let's not continue discussing it then.  I don't own any alt coins other than ones I acquired incidentally, like physical litecoins and some XRP from a giveaway and whatever has been bestowed upon me from forks.  I refused all efforts to persuade me to make physical altcoins of any kind.  Let's assume my loyalty is to Bitcoin Core and I'm interested in its success.  My effort in asking for your attention might make more sense.

If you feel you have earned the privilege of shortening the letter T out of BTC to keep it from being worse, then I'm just going to agree with you, because I've done nothing to earn the privilege to be the one who decides which is better or whether to take it out.

Secondly, we actually made significant design considerations specifically to facilitate altcoins ... Too bad you're too blinded to see it.

assuming, of course, that I'm an altcoin pusher.  If I felt that "BC" was political and I was wrong, then I made a guess and I was wrong.  Bitcoin Cash having the same initials is an unfortunate coincidence that might make such a wrong guess seem reasonable.  I would have wanted to see BTCxxxx instead of bc1xxxx but it's your proposal and not mine.  I am indeed a bit blind, that's why 1 and L's are so problematic for people like me sometimes.

on that 1MB of block space

I guess you missed this part of nullius' reply?

no, I saw it.  He already knows I probably mean with witness data excluded and the difference isn't going to round the current fee back to any level that makes it reasonable to give someone some bitcoin rather than an altcoin to play with or test cryptocurrency for the first time.

I am sorry that popping up with "constructive criticism" out of the blue without much in the way of reintroduction or community engagement probably seems more confrontational in the absence of regular positive contributions to the project's development.  I'm actually sad because I'm embarrassed to be explaining $30 transaction fees to people and no way to avoid them other than switching to altcoins or trusting in scalability solutions still not ready for prime time, so I'm motivated to show up and whine a little about the factor common to both issues: the plausible appearance of neglect to basic user experience.  I accept that the risk with my approach is that my input will likely be completely disregarded, and I appreciate that you've paid what seems like quality attention to what I felt was worth saying.

[gmaxwell]

Bitcoin Cash

Bitmain didn't come up with Bitcoin cash until months after this specification was done, and didn't make the name public until even later... if there was any intention of confusion there it could only have been on the part of bitmain and their contractors.  Similarly, B2X named themselves BTC1 long after.  Unfortunately we cant do anything about altcoins using intentionally confusing names and labels.

BTCxxxx instead of bc1xxxx

Last character of the HRP has to be completely out of the data charset. making it all case sensitive would reintroduce the mixed case errors (though not as bad if it was only the first chars, but just as you complained: special rules don't help the users if they don't know them)... and then you can't do things like have it optionally in all caps which is nice in some contexts, and can be pretty visually attractive too.

I am sorry that popping up with "constructive criticism" out of the blue without much in the way of reintroduction or community engagement probably seems more confrontational in the absence of regular positive contributions to the project's development.

Yes, there certainly was that effect, I was really kind of gut punched by your post and was sort of thinking you'd turned into a bcash shill -- acknowledging it absolves it.  I'm sorry for being a bit quick to judge there. Don't be a stranger.

[casascius]

.

I am sorry that popping up with "constructive criticism" out of the blue without much in the way of reintroduction or community engagement probably seems more confrontational in the absence of regular positive contributions to the project's development.

Yes, there certainly was that effect, I was really kind of gut punched by your post and was sort of thinking you'd turned into a bcash shill -- acknowledging it absolves it.  I'm sorry for being a bit quick to judge there. Don't be a stranger.

Yeah. It feels to me like that’s what I did and that’s not what I wanted.  I am sorry for that.

If you can change l to a b, and let the prefix part be valid when capitalized while the data part is lowercase, and maybe put the T in the BC prefix (so as to not encourage 2-letter currency codes), you will have my enthusiasm even if the 1 remains a separator.

[nullius]

casascius, I wrote my below conclusion before I stepped away for awhile (and gmaxwell showed up).  I didn’t post it, because I wanted to first cook up a vanity address to add some “wow”; unfortunately that’s not done, per below.  But I’m glad to see that things seem to be coming together here.

gmaxwell, sorry, I should have made clear that I’ve read BIP 173 and assumed familiarity therewith.  Otherwise, I would have mentioned the NIST data, instead of obliquely referring to “the research it cites”.  I do appreciate your explanations of the Bech32 rationales, with tantalizing hints of what went on behind the scenes of that production.  Also I hope you caught my sarcasm, which can oft be dry as liquid helium; of course I’m not seriously complaining about the look-up table!

I suggest that perhaps, you should perhaps list to your rationales that Bech32 addresses can be read off efficiently and unambiguously with with standard radio alphabets.  In similar circumstances, I find this can be indispensable for communicating over the phone.  The version zero witness for my money is Bravo Charlie One Quebec...  It may also be wise to rebrand them with a nickname as Bravo Charlie One Addresses (or simply “Bravo Charlie Addresses”, to avoid confusion with version zero so-called “1-addresses”; the word triplet also sounds snappier).


Unfortunately, I stepped out of the discussion just when it picked up.  Real life seized me away, after my attempt to find something suitably impressive for casascius hit an unfortunate snag of GNU Autohell; but I now have an airgapped CPU grinding away.  The following are just some quick tests.  Nested P2WPKH-in-P2SH and Bech32, a direct comparison:  Ain’t Bech32 pretty?

Segwit addresses are sexy!
(Typo correction:  Of course, that should be “imported from WIF”.
I pray that the god of prepositions not smite me.)

N.b. that I am in general leery of vanity addresses.  They do restrict the keyspace, at least theoretically; and by grabbing human focus with a false impression of readability, they’re tantamount to an invitation to spoofing.  But being flesh and blood, I also understand the attraction (and the marketing angle).  I also realize that due to the error correction, Bech32 strings don’t have the same uniform distribution properties as the old addresses (gmaxwell, please correct me if I’m wrong there!); from this perspective, I think that’s actually a benefit.

Also, ever since this discussion started, the idea of writing Bech32 in uppercase has been growing on me.  Directly compared, which looks better to you, casascius?  For that matter, which would be more pleasing when engraved in shiny metal?

bc1qnym7k9hfl77zgrstcrjhphm0llne5j4w0m3fuu
BC1QNYM7K9HFL77ZGRSTCRJHPHM0LLNE5J4W0M3FUU

no, I saw it.  He already knows I probably mean with witness data excluded and the difference isn't going to round the current fee back to any level that makes it reasonable to give someone some bitcoin rather than an altcoin to play with or test cryptocurrency for the first time.

Actually, I didn’t know what you meant beyond your words; and I’ve spent so much time lately shooting down the “still stuck with 1MB blocks” myth on this forum that I keep that code snippet (plus a formatted piece of BIP 141) ready for copypaste.

I think the biggest help for users right now is to get them using Segwit addresses.  I’ve been trying.  I’ve been handing out explanations of how to generate backward-compatible P2SH-nested addresses on the m/49'/0'/0' derivation path with Electrum 3 (so as to actually receive money while people slowly upgrade), launching my flamethrower at anti-Segwit agitprop and FUD which is so stupid that it would be comical if it weren’t so disgusting, and above all:  Shouting at the top of my lungs about how people can discount their own fees right now by using Segwit addresses.

All those people crying to you about fees—do their addresses start with a “1”?

You’re passionate about Bitcoin, casascius, and you’re passionate about users.  For the individual, so much of the current fee pain can be assuaged immediately by simply moving away from “1-addresses”—and when everybody gets onboard, the whole network will benefit as the effectual block capacity grows to Segwit’s potential.  Bitcoin is always that way:  Aligning the common good with the selfish interest of each individual, so that the latter pushes the former.  People still using 1-addresses are hurting the network; and in paying higher fees, they are suffering the natural consequences of their disproportionate capacity impact on the community.  If your transactions weigh more, byte for byte, then you pay for it!  I suggest that pushing Segwit adoption would be a good means to act on your desire to engage and help people who are struggling with fees, and also to do good for the health of the network.

First, Bitcoin invented this field

Damn straight.  (Your sig, too.)

Satoshi’s Bitcoin was real run-and-gun cypherpunk code.  AFAIK, the initial versions were not even portable between platforms.  “Cypherpunks write code”; and the important part is that he encapsulated his brilliant idea in a functioning public alpha about two months after announcing his paper.  Talk is cheap; action can change the world.

Of course that was not the end, but only the beginning.  Satoshi jump-started the movement of cryptography-based digital currency after the very idea had been then moribund for a decade—conference talks and idle dreams notwithstanding.  And he did more:  Whether or not foresaw his own results, he created ex nihilo a social organism of a kind which has never before existed.

One of my own secret dreams is to hack up some code implementing a brilliant idea no one else had, then let people such as gmaxwell and sipa pour “a lot of testing with both people and machines, several CPU decades” into some small area where I personally happen to lack perfectly omniscient expertise.  For now, I can keep dreaming.

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.

Well, enjoy your Bitcoin Porsche and a small slice of cake.  We’re in for a wild ride—but when has it not been?  Someday, a few old men will look back on the Coin Wars back around ’15–18.  I’m not overconfident of what they’ll remember; but I am confident, nevertheless.

I happen to like Core, but they are not Bitcoin.  They provide only the necessary prerequisite:  Reliable software which can keep safe the exchange value equivalent of hundreds of billions of dollars in value throughout the Bitcoin ecosystem.  Beyond that, you ought know as well as anybody that code alone can’t solve people problems.

Bitcoin is a sociological phenomenon.  Now we see the latest battle in an ongoing political war.  What fights for Bitcoin is—Bitcoin.  The thing is running headless, just as it’s supposed to do.  Bitcoinum nullius est.  It’s a decentralized social organism which belongs to nobody, with nobody in control.  It derives its value from its nature as such.  It fends off enemies by the power of multitudes who believe in it—and the many who have much to lose—many of whom are otherwise enemies with each other; all of whom agree on only one thing, Bitcoin.  Core (as L. cor) could stop the heart of Bitcoin by caving in, or ceasing technological improvements.  But this is beyond Core, you, me, or anybody else involved.

For Bitcoin owns; it is not owned.  I don’t mean the monetary component, in the sense of people who are owned by their wealth.  I refer to the sociological phenomenon.  Bitcoin owns.  You know what I mean.  Each and all of you know exactly what I mean.

[cellard]

Personally, and I may be weird, but I find easier to discern shapes if there is variety of caps on and off, a string of all caps off seems to same-ish to me.

As far as actually trying to memorize things... who does that? I just look at the first 3 or 4 characters of the address, and look at the last 3 or 4  characters of the address, when I paste the address in the "send" section of a wallet, when im about to send, mostly to confirm that im not infected with these type of malware that pastes an attacker's address instead of yours. So looking at the first and last couple of characters gets the job done for me at least (which is why I think caps on and off make it easier to stop any differences). I don't think a sophisticated way to only change characters in the middle of the address where most people don't look at is possible, or is it? because that would be a hell of a malware.

Anyway, im ok with both formats. The one that starts with 3 sucks, bech32 is better and the bc1 distinction is easy to spot and easy to discern from legacy addresses. BTCxx ... not sure about that one, the 1 is a good looking separator to me, if there is no 1, something seems missing.

btc1 would be cool too, but that's 4 characters...

Overall im not sure. I think bc1 should do the job just fine. I just hope trolls don't start a campaign to tell noobs how "bc1" is the new bcash format address or something (looks like bcash side enjoys making things confusing otherwise they would have choosen their own address format since day 1)

[nullius]

I just look at the first 3 or 4 characters of the address, and look at the last 3 or 4  characters of the address, when I paste the address in the "send" section of a wallet, when im about to send, mostly to confirm that im not infected with these type of malware that pastes an attacker's address instead of yours. So looking at the first and last couple of characters gets the job done for me at least (which is why I think caps on and off make it easier to stop any differences). I don't think a sophisticated way to only change characters in the middle of the address where most people don't look at is possible, or is it? because that would be a hell of a malware.

This is an interesting UX observation.  I would guess that it’s a not uncommon practice.

That may or may not be a reasonable heuristic for defending against malware generally seen in the wild; I wouldn’t know either way, since I prefer simply to not be infected by malware which could anyway open my wallet, steal all my funds, and then encrypt and ransom all my files.  But even under the best assumptions, it should not be considered a reliable technique.  For a targeted attack, if I don’t get my maths wrong, generating a “vanity address” which matches the first and last four characters of a specific address should require about 58^7 ≈ 2^41 work.  (The 7 is because the initial character is fixed.  Actually, I think I see a stupid bug in what I just said; but it’s unimportant to fix.  You get the point.)

Anyway, im ok with both formats. The one that starts with 3 sucks, bech32 is better and the bc1 distinction is easy to spot and easy to discern from legacy addresses.

I’m glad to hear it!  Bravo Charlie addresses are the future.  As for the address with “3”, well—that’s nothing new; it’s simply an old-style address with a version byte of 0x05, indicating a P2SH address which in this case happens to have the script hash for a Segwit P2WPKH script (0x0014<key_hash>).  The 0x05 makes the address consistently start with a “3” due to the vagaries of Bitcoin’s base58 encoding.  Old-style addresses which start with a “1” have a version byte of 0x00, followed by the key hash.  Both old-style addresses then end with a 32-bit checksum of truncated double-SHA256, and then the whole thing is base58-encoded.

I just hope trolls don't start a campaign to tell noobs how "bc1" is the new bcash format address or something (looks like bcash side enjoys making things confusing otherwise they would have choosen their own address format since day 1)

Well, sometimes, I “troll” back.  Behold my new Bech32 vanity tip address!

bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h

I made that yesterday, in preparation for some Bech32 advocacy which I have not yet posted.  I enjoy the fact that you can only send real money to this, not those fake scamcoins which are making awful news lately.  You know.  The forked-up b-trash which sadistically inflicts on users a circumstance which will foreseeably cause loss of funds, per all the threads on this forum crying, “Help!  I sent BTC to a BCH address!” or vice versa.  My Bech32 “cash” address will create no problems here.  It is only for genuine Bitcoin cash.

[vapourminer]

Personally, and I may be weird, but I find easier to discern shapes if there is variety of caps on and off, a string of all caps off seems to same-ish to me.

As far as actually trying to memorize things... who does that? I just look at the first 3 or 4 characters of the address, and look at the last 3 or 4  characters of the address, when I paste the address in the "send" section of a wallet, when im about to send, mostly to confirm that im not infected with these type of malware that pastes an attacker's address instead of yours. So looking at the first and last couple of characters gets the job done for me at least (which is why I think caps on and off make it easier to stop any differences). I don't think a sophisticated way to only change characters in the middle of the address where most people don't look at is possible, or is it? because that would be a hell of a malware.

i am the same, its easier to read the address with mixed case as i find its easier to visually break it into "chunks" of 3-5 characters i can check. these chunks can be anywhere in the address, as its pretty much wherever patterns catch my eye. i check several of these "chunks" before sending.

all uppercase just looks like one big.. well, something. but its actually harder to read and check for me.