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.


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


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

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.

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

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


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


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.

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.


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.

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.

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


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.

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?

Just a note in case anyone was watching the address: three weeks back the outputs to this address were consolidated in order to take advantage of low fees on the network and to simplify sweeps of further bitcoin spinoffs (as signing for 65 inputs is a bit of a burden); the consolidated funds were moved back to the same address, minus a nominal amount of fee (about 2sat/byte).

The overcomplete representation reduces the number of carries needed between limbs, so it makes the operations faster.  The fe_add should already be more or less optimal when written in C-- it's a trivial function in part because it doesn't need to handle any carrying at all.

It's possible that some other representation might be faster yet, esp if using SIMD.

Not so, WRT Gavin: http://laanwj.github.io/2016/05/06/hostility-scams-and-moving-forward.html   AFAIK similar applies to Jgarzik. (Too bad, I wish it hadn't been removed years ago so that it could be removed now with a public condemnation of his ICO scam)

wtf.

Block 1 has a timestamp of 2009-01-09 02:54:25.   The announcement of Bitcoin's release is timestamped Thu Jan 8 14:27:40 EST 2009, which is more than 7 hours before block 1.


Please fix your post before we have to endure more years of people repeating unsupported speculation and outright untruths about the history of Bitcoin.

You have no idea which if any other blocks he mined, -- the only reason you think you do is due to garbage "scholarship" like your own that can't even manage to compare two dates.

::sigh::  People think weird stuff.   The paper does not talk about Bitcoin integration in any detail, as it is massively premature for that.


But adding a new script system is a softfork, it's always been a softfork. It's pretty much the most softforky thing you can imagine, and moreover it's already been done before!  P2SH replaced Script with a nested copy of Script..  In that case the nested thing was the same as the outer thing, but there was no technical reason it couldn't have been different.

Thanks for actually being thoughtful, though I think it is a little more subtle than you suggest:  BIP148 would have been backwards compatible IF and Only if hashrate became compatible with it.  The people arguing that it was compatible were not, I think, trying in any way to be dishonest but rather were pretty convinced that hashrate would be compatible with it when it activated (regardless of this view being justified) and to whatever extent they had doubts any failure they would attribute to hashrate not doing what it was supposed to do (regardless of this view being justified...).

I think this is an unreasonable risk and to this day I don't understand why quite a few other people thought it was an acceptable one.  But, on the other hand, they were right that hashpower would (effectively) go along with it.

Every other point I agree with, in particular your comments on the timeline of it.  I think though that I would conclude that they took a gamble and won, elsewhere we might applaud them with tremendous foresight as we often do for people successful primarily through chance...   OTOH, what they were gambling with was the safety and stability of a shared resource that we all count on...

The intervention of 2x unfortunately substantially eliminated one of the main payoffs proponents of BIP148 probably anticipated:  Rejecting the notion that miner forced capacity hardforks were something we needed to respond to on an immediate basis, thus allowing us to make more progress with less drama.  Maybe we'll be there after November.

I think the thing we should worry about isn't recriminations about BIP148 but what are reasonable expectations for consensus upgrades to Bitcoin.  I don't think it's reasonable to expect them to happen, generally, on a time frame of less than years.  It certainly isn't the case for internet infrastructure protocols like BGP, which are easier to upgrade than Bitcoin...  If a chance is well understood and widely supported, then sure Bitcoin can deploy them faster, but I think our base expectation should be years.   I think this is the fundamental disconnect that fed a lot of fuel to the short timeframe of BIP148.

I wonder why Jeff Garzik would tell such a transparent lie.  It only seems like a legit answer if you don't know how things work. Although he has locked the discussion there so no one else can point this out, nothing stops us from discussing it over here.

All his nodes continue to send subver: "Satoshi:1.15.0"  to everything that connects to them, trivially identifying them.  A a result his change has no privacy gain what-so-ever and serves exclusively to undermine the anti-partitioning logic in the Bitcoin node software; leaving users open to unwanted connections that reduce their safety and reliability. This fact couldn't have been missed, especially since the explicitly cited "Bitcoin Classic" identified itself exclusively via subver.

[FWIW, because I'm calling Jeff out on a serious breach of ethics here I think it's important that he have an opportunity to respond, so I am also emailing him a link to this discussion. Edit: Done]

Actually, BIP91 predated that NYA entirely and was written as a tool for miners to avoid a BIP148 introduced split.

BTC1 adopted it (with some prodding by its author) and also kept its signaling the same, forever obfuscating the activation.  All of the miners I've spoken to were running segsignal (BIP91) and not 2x.

Were never involved with the "NYA" at all.

It's like your neighbors making a deal among themselves to divide up your home and assets... and now people are calling you out for reneging on an agreement that you never agreed to!

But in one sense it is the weakest possible support short of outright opposition.

It is effectively saying "we will do whatever other people do"...  So if you have a dispute between two groups, one saying "We'll do what other people do" and another group saying "We absolutely positively will not do thing-B but will instead do thing-A"  ... what do you think is going to happen?

In the presence of a considerable part of the community that won't follow B2X under almost any condition bc.i's statement is not really all that supportive.

It's something that blockchain claims but I am fairly confident that it has no basis in reality. They base the claim on how many transactions are submitted through their API, but many people pick up random transactions from the network and submit it to their API because it has, at times, been the only way to make transactions reliably display on their site, because their nodes are sometimes down.  Transactions generated by their wallet have been historically distinctive in a number of ways-- they are not generating anywhere near that number of transactions on the network.

"To enjoy freedom we have to control ourselves."

Unfortunately the propensity for people to run off and deploy things without review and discussion with drive a mixture of low quality defacto standards and less inclusive and transparent design work.

Complaining about it a bit is a tool for progress, reminding people to control themselves.  No one need control the behavior of others.

Unfortunately the suggestion isn't timely-- it was made after several parties had publicly deployed BIP173*.  It also has a number of unanswered questions (range and resolution, how do you address that you can't go backwards from a SPK to an expiration...).

I think it's a good idea in general, but I think it will need to wait for the future.

* We seem to have a minor problem in the ecosystem with people aggressively deploying unreviewed draft proposals.

In terms of just getting it across, I'm pretty sure we've got this. (obviously I'm not going to post all the details because that would needlessly escalate the cat and mouse.)  I'm aware of at least three radically different bypass mechanisms that are already in place (none of which involve anything as pedestrian as VPNs or Tor, though both these things exists and will also help bridge Bitcoin and and out of china).  Fortunately, Bitcoin's ongoing bandwidth requirements are relatively low and this opens many options.

But getting around a firewall is only one problem... if Bitcoin is banned in china it will be much harder for people to use it there even if they technically can.  This would be unfortunate.  Especially on top of the already near total absence of nodes in china. (last I checked there were only about 50 externally reachable actual nodes).

FWIW early termination has been used by miners since at least 2010.

Libsecp256k1 works fine with no dependencies at all.  You're having dependency issues because you're bypassing the build system and doing something horrible.  Read the fine instructions.  Otherwise it's like drilling into someone's head and then complaining that you have to provide infrastructure to keep the blood circulating or they stop being able to give you advice.

> mbedTLS will build without any external dependencies, it has its own MPI functions and supports secp256k1 primitives

And is probably not even remotely constant time for it and is probably also super slow...

Other people already had. I was clarifying the innovation point and nothing else.


What "decrease"?.... on state of the art hardware at both times the initial sync of Bitcoin increased by 50% in the last 6 months.  This has a material impact on people's willingness to run nodes-- an uncompensated act which is essential for Bitcoin's survival as a secure decentralized system.

Twice the space doesn't mean one half fees, it means almost zero fees against the same demand. Half the fees would generally be achieved by a few percent more capacity.


A spammer must pay the fee of each transaction they displace for every block they displace it. Increases in blocksize in excess of demand just radically reduce their costs by resulting in very low fees.  A lager block never lowers the price to displace a transaction for a spammer.

The best prior research we had showed that 2 to 4MB was the largest arguably safe amount even while ignoring safty margins, state attacks, initial synchronization, etc.   2X is _NOT_ 2MB, it is 4 to 8MB.

We do in terms of _real_ technological development, but not fake marketing crap... and not at the expense of stability and security.

Compare, Bitcoin moving to innovative second generation error protected addresses w/ BIP173  vs  ethereum still behind bitcoin 0.1 without a strong safe to use address system.

Or ethereum validation being so slow that its impractical to sync-up a full node anymore, pushing almost all eth users onto SPV-like security for their initial sync, while Bitcoin sync tx/s speed is orders of magnitude faster and keeps getting faster.

This (non-technical) topic has been moved to Bitcoin Discussion.

https://bitcointalk.org/index.php?topic=2206674.0

BCH already incorporates part of segwit-- BIP143, the segwit signature scheme they've just renamed it "safesigs" and present it like it's their own brilliant invention. They're working on merging BIP173 (the error protected base32 addresses we created) but renaming it "cashaddress"... Sense a pattern here?

They've been going on about 'flextrans' which contains exactly the same design feature about segwit that they've thrown so much "not Satoshi's vision" mud about-- that new transactions don't commit to past signatures (a necessary criteria for fixing malleability).

They've gone on about "schnorr signatures" but their implementation there is just our prior abandoned code with the copyright headings removed and their own names added.

Don't make the mistake that honesty or technical merit are even considerations in their marketing. For all it matters for their marketing there is no u-turn so long as they don't admit it.  If you can tell that they are full of crap you aren't in the bcash target audience.

Now the interesting point is that 2Xcoin is going after the same unsophisticated audience, splitting that market.