If you are worried about one line of code in exchange for doing something right you probably have no business creating a Bitcoin node.  (in fact, the difference in practice should be zero lines of code-- it's just a question where the nonce for comparison is stored: globally or per-peer.).

In any case, using a consistent value would be bad for privacy allowing the correlation of a host across networks and time.

Nodes already know the prior transactions were valid they don't need to check them again.  They just need to track the currently unspent outputs, just as you are thinking.

The Bitcoin software can run with pruning that makes it forget old transactions.  With pruning the security and behavior is generally indistinguishable from other nodes-- but when running in that mode your node just can't help new nodes come up because they need to see the history and you don't have it.

See also Section 7 of the Bitcoin whitepaper.

I have almost 5000 posts on the forum, in many different subforums and subjects.  But only something like 13 posts in 2018, most in February. Like me, many other technical parties have stopped using the forum entirely or almost entirely. I don't think it's reasonable to that that I am active.  Usually I only post now when a journalist sees something on BCT and asks me to comment,  instead of comment to the journalist I prefer to just go reply to the the thread.

Your example is one of those in fact, the poster in question was running around with incorrect claims of vulnerabilities in Bitcoin.  I got asked.  I'm ashamed that my post looked anything like anonymint's to you but I'm also not surprised: As you note, you don't currently have the background to evaluate the technical content. So you're reading for tone.   If I write in a less than kind tone even when addressing someone who is themselves unkind, it's a mistake on my part which I regret.  But I hope-- and have reason to believe from the results-- that the good I contribute eclipses the crime of having a bit of humanity here and there.  Unfortunately, to you-- and you are not alone-- someone who does interesting technical work that makes a real difference and someone who strings together terms and disrupts discussions can look pretty similar.  It seems that many draw an equivalence among all people who say things that they don't understand,  and in doing so they do everyone including themselves a great disservice; you can probably understand more than you give yourself credit for, when you don't understand at least some of it is a failure on the speaker's part to make themselves understandable. Sometimes that failure is because they don't understand what they're saying themselves.

To some in shoes like yours, the constant and unrelenting anger in anonymint's posts make him feel even more credible.  Arguably, other more competent posters could win those people over by matching tone.  But most of us don't want to live like that,  we don't want to be king of the crapped up pool. We'd rather just go away, and-- in large-- we have.

Sometimes it's a question of venue-- if I'm writing in the technical subforum I'm usually not trying to address a particularly general audience... but if I'm not comprehensible to the audience I'm addressing it's because I'm making a mistake or because I don't fully understand what I'm talking about myself and so I can't (yet) explain it clearly (it happens from time to time...).  Please feel free to ask me to expand on any of my posts if one interests you but sounds like opaque jargon.


Just as a point of order, sub-forum mods on BCT don't really have much in the way of authority.  Mostly we have the technical ability to zot spammers and move around threads,  but forum norms and policies generally frown on using those tools in an especially editorial way. (Moreover, even if a subforum moderator can get away with it, it doesn't help much without the support of global mods and theymos to do things like ban users).  Generally, subforum mods have about the same clout they'd have as a similar non-mod long time community member.   I wouldn't be surprised if a respected technical contributor like me standing up and saying that anonymint's posting drives him off the forum had some impact-- otherwise I wouldn't have commented-- but thats about it, after all I've been telling people to hit [ignore] on anonymint for years, and he's still been here all this time. We don't, for example, have the ability to ban accounts from particular subforums.  If that had been up to me I would have done that with the tech subforum and anonymint years ago-- the people who find him disruptive are mostly in there and the people who don't are mostly elsewhere...

I just noticed that AnonyMint was banned again, sadly as a result of him posting under a new sock account.

I believe that, as much as any single person could possibly be, AnonyMint (and the forum's historical failure to get him under control) is responsible for a significant fraction of the technically competent people becoming largely inactive.

AnonyMint's posts are almost exclusively jargon-laden techno-babble.  His posts are angry and abusive while at the same time they often fail to even make syntactic sense when it comes to the technical content-- at least to anyone who knows what the words mean.  He relentlessly floods threads with his trademark nonsense and switches to slanderous personal attacks whenever someone disagrees with him.   If that were all there was to it the ignore button would be sufficient, but his multi-posting derails basically any thread he targets because if even a few people fail to ignore him they'll respond (usually disagreeing, sometimes just trying to figure out what the heck he means) and make it nearly impossible for productive discussion to continue. Worse, AnonyMint's abusive but "technical sounding" approach is moderately effective at mobilizing throngs of well meaning but ignorant people to his defense (especially ones who are interested in pumping altcoins and find Anonymit to be sufficient 'proof' for whatever they already wanted to believe). When mobilizing an ignorant mob fails he resorts to the use of copious alt accounts.

People who are really savvy with the technology have valuable time (as is the case for anyone with valuable skills).  It's a waste of that time to spend it in a place where there are decent odds of their efforts being buried under a mountain of abusive nonsense.   Even those few who don't find his dishonest practices extremely annoying are forced to admit that it's just a waste of time to be in the same venue as someone like that.

AnonyMint is not the only example of this sort of abusive ignorance that shows up on the forum, -- it's not uncommon for newbies who are used to being the smartest guy in whatever little pond they came from to show up and say they're going to "fix bitcoin" while calling everyone else an idiot for the couple months it takes for them to realize how little they actually know...  but most of these people are just ignorant and can be educated and they aren't especially relentless.  By comparison, AnonyMint's consistent conduct year after year is especially demoralizing. With some angry newbie there is a least the hope that you'll get through to them or that ignoring them will be sufficient.  With AnonyMint from the moment he takes interest in a thread the outcome is clear in advance-- he's going to post and rant until everyone gives up or flames out and it's never going to change.

I think the people concerned about AnonyMint's "free speech" in this thread are being duped into being pawns in AnonyMint's efforts to shut down the freedom of others to communicate and associate. AnonyMint is clearly free to post whatever he wants on his own site (and any other site that can stand him). You're free to discuss his "ideas" with him there, if they interest you.   But when the forum invites AnonyMint to post without restriction, other people aren't practically able to have the discussions they want to have-- he drowns them out and buries them under toxic stink. If a community can't choose topics and participants then anyone who wants can shut down a communities ability to communicate.

If this isn't obvious to you yet, consider a silly analogy:  I think we can all mostly agree that people generally ought to be able to operate their own bodies as they see fit, without other people restricting how they use them. But then we have a public pool that the community likes to use and since it's a public pool we all agree everyone ought to have equal access to it.  But then comes AnonyMint and for whatever reason he insists on using his autonomy over his bodily functions to deficate in the pool and refuses to cut it out.  Some people can't smell it and aren't worried about pathogens and don't mind. But a lot of people do mind and won't get in the crapped up water. So his "freedom" to use the pool without restriction on his conduct ultimately denies others the free use of the pool that they ought to be able to use. If the pool operator won't keep the crapper out, then people will go off to use other shit free pools... and leave the original one for people who like shitting in the pool and the few who don't mind it.

Reasonable people can usually disagree about exactly _where_ the line should be drawn. But the principle that sometimes you've got to set and enforce limits to create a space that people can actually enjoy should be something we all agree on.  In AnonyMint's case, I think almost everyone would agree his conduct has been consistently far over the line, but I think his abusive conspiracy theorizing rants strike a resonance in some people and blind them to how intolerable the guy actually is...

What you are describing here as "Proximity Premium" is normally called "progress". Normally we think of mining as working as a lottery: Your chance of finding the next block is just simply your proportion of the hashrate out of the total.  But in a system with progress things work more like a race: the fastest party wins more often (or even always, if there is a lot of progress). Lottery vs race is a near perfect analogy-- in a lottery your chance of winning on a ticket doesn't change because of your prior ticket, but in a race your chance of winning in this step depends critically on all the steps before it.

Progress can be introduced into mining in many different ways, -- including from things like bad POW designs that try to reduce variance by making mining incremental, or blocks simply taking non-zero time to spread and validate across the network -- but the end result is the same: Progress creates an insidious centralization pressure where the bigger miner actually gets a better return on investment.  Due to re-investment even small amounts of progress could conceivably completely centralize a system even absent other centralization pressures.

Progress is a lot more hard hitting than most people expect. You might look at 6 seconds of delay and wonder how could that matter against a 600 second block interval.  But because of the nature of poisson processes most blocks are found much closer to each other than 600 seconds.  We saw the direct effects of this in the network, when blocks started getting larger than 200k propagation times started getting upwards of 2 seconds and miners saw higher orphaning rates and consolidated onto fewer larger pools, even giving a single pool a super-majority share of the hash power for a little while.  After we invented and deployed new technology that made blocks propagate faster, the consolidation reversed.  Unfortunately, there is probably no amount of progress which is "safe" -- at best it's only small enough to be too small a centralization pressure to worry about compared to other issues, and the improved propagation requires cooperation -- if a large miner intentionally produces blocks with unrelayed transactions will immediately have the old slow propagation which will improve their own bottom line.  When it comes to security you have to build for the worst case, not just hope people will cooperate instead of doing whatever is best for themselves. So long as the difference between the worst case and typical is small there isn't much incentive to exploit it, for the moment it seems to be working.

Concern about progress isn't new-- It's been part of the regular understanding of the engineers working on Bitcoin for a long time-- and bitcoin's creator probably understood it too considering that he chose a 10 minute block interval (smaller numbers _look_ fine until you start trying to work out the effects of progress).

That is why I find it disappointing that A day ago you were claiming that there were no reasons to not radically increase block sizes and slandering all the engineers who've maintained Bitcoin its whole life. You have been more or less calling the people that built so much of what everyone uses malicious criminals, in post after post.

Today you've miraculous discovered that larger propagation delays result in progress which turns mining from a lottery into a race favoring larger miners-- Welcome to the state of competent Bitcoin development circa 2011. And thanks for the proof that you haven't even bothered to read any of the relevant discussions which you felt so easy about smearing people about...

What will you realize tomorrow?  Maybe that progress and variance are not one in the same and in fact almost any variance reduction proposal increases the potential for progress once you realize that participants will behave strategically instead of honestly. For a simple example of where making variance lower makes progress worse, say that you require that a block present 10000 POWs of 1/10000th the difficulty instead of one (your proposal basically does that, in fact): That is a system with very low variance (1/10000th) and almost perfect progress: If you had two miners with 30% hashpower that didn't share or only shared work with each other and four miners with 10%, the 10% miners would almost _never_ find a block. Again, not a new result: Low variance hashcash using multiple POW was described in the hashcash paper (section 6), and people have re-proposed it once or twice a year on BCT since the start. Maybe that if you don't bother researching you'll just rehash old and broken ideas and if you smear people you'll largely get ignored instead of getting responses that help you improve your own understanding...  Or maybe not, your posting history is littered with pumping your belief in scammer wright, after all.  

I think that is just kind of sad and very frustrating.  Even the idea of "fix"ing variance is somewhat confused on its face. Variance is utterly essential to the operation of the system, it _cannot_ converge without variance significantly greater than the communications diameter of the network: Imagine a toy example with a world wide network of nodes and two miners with equal hashrate, in a system with no variance they'll keep producing blocks at exactly the same time, so once the network forks once it'll never heal-- nodes will just follow the closest miner. The same holds when variance is too low rather than zero: you get long reorgs because far away nodes will only switch chain heads when a nearby miner in a tie gets unlucky enough to fall behind more than enough to overcome the communications delays, which happens only rarely if the variance is low.  This isn't speculative, e.g. there was an altcoin called "liquid bitcoin" (IIRC) with a fixed difficulty, once there was enough hashpower to make blocks fast it fragmented into hundreds of separate chains that were unable to heal and form a single consensus. Coupled with strategic behavior by miners (such as large miners delaying sharing their work), your proposed change would also create tremendous amount of progress (IOW centralization pressure)-- just like the example I gave above.

In spite of pages and pages of discussion no one has until now pointed any of this out to you, because almost no one technically competent will bother even reading your posts because you haven't bothered learning what you don't know and you spend a lot of energy making really nasty and unprofessional insults-- I only read any of it because your seemingly incorrect claims of "vulnerabilities" caught the attention of journalists and I was asked if you were full of it or not.

No information has been presented so far which supports this claim.   It was a reasonable question to ask if looking up an entry was expensive, if it were then it would be an issue. But it is not expensive it is exceptionally cheap.

In fact, sticking a loop that takes cs_main and does 200k lookups each time a network message is received seems to only increase CPU usage of my bitcoin node from 3% to 10%.  Maybe just maybe there is some crazy pathological request pattern that makes it meaningfully worse and which somehow doesn't also impact virtually every other message. Maybe. It's always possible. But that is just conjecture.  Most conjectures turn out to be untrue, talk is cheap. Needlessly insulting sanctimonious talk, doubly so.  Some people wonder why few technically competent frequent these forums anymore, but it isn't hard to see why-- especially when the abuse seems to come so often from parties whos posting history reveals that they're primarily interested in pumping some altcoin or another.


And then nodes that have very few blocks will get stuck. Congratulations your "fix" for a almost-certain-non-issue broke peers. Safely size limiting it without the risk of disruption probably requires changing the protocol so the requesting side knows to not make too large a request.

Why do you expect your hacker to be honest enough to use actual hashes? He can just use arbitrary low numbers.

If you had any idea which peers were sending "malicious messages" why would you not just block them completely?  ... Any kind of "block a peer when it does X which it could reasonably think was a fine thing to do" risk creating a network wide partitioning attack by potentially creating ways for attackers to trick nodes into getting themselves banned.

You might not be aware but reading a single block from disk and decoding into memory should take longer than a hundred thousand memory accesses takes.

Yes, and it was analyzed here, and the analysis says that it would be surprising if it were actually slow, so it isn't worth any further discussion unless someone  finds a reason to think otherwise, such as a test result.  

Looking up an entry is O(1) -- just a trivial hashing operation and one or two pointer chases.

So basically what you're saying is that you can make the node do a memory access per 32 bytes sent,  but virtually any network message also does that.  E.g. getblock <random number>.

Locators have no reason to be larger than O(log(blocks)), so indeed it's silly that you can send a big one... but I wouldn't expect it to be interesting. Alternatively, you could consider what is the difference between sending 100k at once vs 20 (a totally reasonable number) many times? Only a trivial amount of network overhead and perhaps a couple milliseconds of blocking other peers whos message handling would otherwise be interleaved.  If you benchmark it and find out that its significantly slower per byte sent then other arbitrary messages I'd be interested to hear... but without a benchmark I don't find this interesting enough to check myself.  

There are a billion and one things that are conjecturally slow, but most of them are not actually slow (and more than a few things that seem fast are actually slow).  Anyone can speculate, testing is what is actually valuable.

"infosec" password advice is given for contexts where the account can be cheaply recovered if the password is lost.  Not for cases where there will be very large monetary losses if its lost.  Infosec advice is also overly focused on physically proximal threats.  This is outmoded advice: anyone who has physical access to your computer can easily compromise you 1000 ways without the password, and there are a thousand times more attacks from attackers that have no physical access.

Your goal at the end of the day is to keep access to your bitcoins. This means you must balance risks. If you only care about the risk of theft, destroy your private keys now and no one will ever steal them...

Someone who can break into your home can hold you at gunpoint and get you to type in basically any password you know... if the attacker is in your home you probably have bigger problems then them finding a hidden seed.

Throwing completely substancesless insults at quality work in order to fool people who couldn't tell for themselves into thinking that you're brilliant seems to be a favorite pastime for folks who feel insecure about their lack of competence adequate enough to accomplish anything themselves.

Allow me to knock your socks off:

Say you have N people who each want to find a vanity tweak of their pubkeys which will roughly take M million tries to find.

You can find all N of them with just ~M million tries, instead of the N*M million tries if they were to do them themselves alone.

Here is how.  Each person has a pubkey P_i,   they all come up with uniformly random tweaks T_i.  They tweak their keys, and send these resulting public keys to the hashing server. They keep the tweak and original pubkey private.   They also send the string(s) they want to match. They stay connected.

The sever takes all the strings and compiles them into a single match expression (which can be matched in log() operations at worst, probably better).

Then the server sums all the tweaked pubkeys and grinds on it comparing the output with the omnibus matcher.

When it gets a hit  it then demands all clients except the one with the match to tell them the private keys for their tweaked keys (this reveals nothing about the original private key, since it's been tweaked).    It then sums up the tweak it found and everyone elses private keys and gives that to the lucky user.

Everyone remaining sends new tweaked pubkeys  (probably in the same message they sent their prior private keys).  They get summed and the process continues with the new basepoint.

If someone fails to send their private key, you kick them off and ban them and you lose that result because you cannot reconstruct the tweaks without everyone elses keys.

Implemented correctly this is completely secure.

You could even have the individual users perform their own grinding.  So if they all had computers of the same speed, they effectively get an N fold speedup in how fast they find solutions.

To discourage abuse you could require a new participant grind without submitting their own keys and patterns for a while... There found tweaks prove the work they did, once someone has done enough you can give them a token they can use to submit a pubkey and pattern(s) for matching, if that user fails to reveal, you ban it.  They can rejoin ... but they have to do free work to get a new code.

I haven't previously implemented it because the protocol minutia with tracking and banning and whatnot is a PITA and only the mathematical part is interesting to me.

You want this code:  https://github.com/bitcoin-core/secp256k1/pull/507  it will be astronomically faster than your current code.

I believe when I previously implemented the techniques in this code my result was faster than vanitygen on a GPU.

It could also be made faster still with some improvements.  E.g. it doesn't actually need to compute the y coordinate of the points, so several field multiplications could be avoided in the gej_to_ge batch conversion.   It could also avoid computing the scalar for any given point unless you found a match. (E.g. by splitting the scalar construction part into another function which you don't bother calling unless there is a match).


Another advantage of this code is that it is setup to allow an arbitrary base point.  This means you could use untrusted computers to search for you.

Sipa also has AVX2 8-way sha2 and ripemd160 that he might post somewhere if you asked.  An 8-way bech32 checksum generator should be really easy to do, though if your expression doesn't match on the final 6 characters you should avoid even running the checksum.

You have to connect to the outside world somehow... you could run your gateway node with pruning, then it would only use about 3GB space or so.

Querying it on an address wihch had funds returned no results.  The addrindex code there was written by Pieter as a quick lark, before he realized it was a bad idea and abandoned it.  Other people picked it up and patched it forward but made no effort to improve it or investigate the issues I encountered with it.

Generally it's my expectation that anyone who uses something like addrindex is eventually going to be forced to us a centralized service provider like blockchain.info once the resource costs of an unpruned address indexed full node is beyond what they can support.  (The fact that you struggled with running two nodes suggests that you're within a factor of two of that already).

In theory you can transfer the max-flow in a single go,  but software needs to support making payments on separate channels in order to do that atomically and people are working on that.   But usually atomiticity isn't required-- usually you can just make a couple of separate payments if you run into limits.

The standard protocol is a commit and reveal protocol as mentioned above with hashes.  The problem commit and reveal protocols have is that the last party to reveal can jam the process if he doesn't like the result.   In some contexts thats harmless, in others its fatal.

The hash the last block's ID approach can be biased by miners.  Without knowing what the the result would be used for you can't argue that they wouldn't do it... if they could make themselves win a 100 BTC lottery for sure, ... it would be totally reasonable to orphan and throw out blocks to pull it off.    The earlier proposal to use "the last 64 blocks" doesn't help, the last block is sufficient-- it already commits to all prior blocks anyways.

You can attempt to reduce the holdup issue in a commit and reveal protocol by using verifiable secret sharing.  For example: Alice, Bob, and Charley  generate secret values a, b, c and using ECC compute and publish points  aG, bG, cG   -- these are their commitments.   Then each party generates a new random value r and sends one of the other two parties r and the other party their secret-r, and those parties publish rG and (s-r)G.  So for example, Alice sends r to bob, and (a-r) to Charley.  Bob and Charley publish rG and (a-r)G, and each of them can add the values and check that they equal Alice's commitment because aG = rG + (a-r)G; but the players all still know nothing about each other's secrets. Once the sharing is done, people can start revealing their secrets.  Alice reveals a, Bob reveals b... Charley decides he doesn't like the result and falls offline, but now Alice and bob can reveal the shares of Charley's secret...  Whoever remains can compute H(a||b||c).  Of course, if Bob and Charley are co-conspirators they can abort as soon as they get Alice's shares if they don't like the result. This approach generalizes to any threshold of participants.

These sorts of ideas can be combined.

But which combinations are interesting depends on the application. For example,  one case I've thought a lot about is making random values that people in the future can be pretty confident weren't rigged.

Alice and Bob can agree on their terms and generates the a private key as a hash of the agreement terms and a random value sends a bitcoin to their own keys A and B in block 1000.   Then after block 1000 they sweep their coins and reveal their keys and your random number becomes  H(blockhash || a_private || b_private).   This would make it difficult for the miner to bias without knowing A and B's keys, letting them steal the coins. A and B couldn't easily restate their random values because they're commuted in the chain, etc.

Another idea which I've not seen implemented is to use a slow sequential function on the block hash. So e.g. your randomness involves H(blockhash)  but you make H in that case some function that takes 20 minutes to compute.   You can argue that a miner might throw out a block solution to bias a result-- but if he can't even tell the result for 20 minutes after finding the block that is much harder.  I understand that Ben Fisch  has been working on finding functions for H() in this example which are cheap to verify, so others can check the results of that 20 minutes of computation without doing 20 minutes of computation themselves.

Nullius and DannyHamilton are spot on.

It's sad that people are getting bamboozled by malicious disinformation on this subject.

The _exact_ same thing protects segwit outputs from being stolen by malicious miners as any other coin: Following the rules is part of what _defines_ mining.  A miner that steals an output hasn't mined as far as nodes are concerned, their blocks will simply be ignored (and the peers relaying them eventually banned).

Segwit is no different from any other consensus rule in this respect-- other than some were introduced later than others, but many have been introduced over time.

We didn't see these same sorts of malicious FUD with P2SH though it was exactly the same-- I guess because back then felons hadn't figured out how to monetize that sort of confusion.

Old versions are old, they have known reliability and performance issues. 0.13.2 is vulnerable to DOS attacks (plus potentially other security issues, but I don't recall for sure), and it isn't getting updated for other changes so it will far further behind over time.   I would recommend at a minimum that you setup two nodes-- one on current software, one running your special code-- and make the one with the custom code connect only to the current software.  This way it's shielded from abuse that it might not be able to handle and it's easy for you to upgrade the external node.


As an aside, that address index patch that was floating around gave rare false results for me.  I suspect that it could lose entries when there were reorgs, but I'm not sure if that was the cause or something else.

As achow noted, fee sniping is a long known concern. The first active countermeasures were deployed a couple years ago in the form of anti-sniping locktime use.  Fee backlog also looks like it will work just fine to stabilize incentives, as expected.

Unfortunately no fee sharing scheme has been shown to be incentive compatible under reasonable assumptions.   The problem is that users can pay miners via mechanism other than (and in additional) to any visible fees that would be shared via additional tx outputs, or completely out of band payments.  Miners have accepted payments in this manner since 2011, so it isn't theoretical.  Any fee sharing scheme would create a very strong incentive to accept alternative payment (which isn't shared) and for users to offer a portion of their fees as alternative payment.

Danny's #1 makes no sense to me-- no one cares about a satoshi difference, just specify the rounding in a particular way and be done with it. That is a one line of code point that no one would care about.

The appropriate consenusus rule change would be to allow coinbase transactions to spend outputs including other immature coinbase outputs. From that simple and generally useful change alone arbitrary fee forwarding or sharing schemes could be implemented in a compatible manner... but we're still left with none that appear even remotely strategically stable.

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.

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.

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.

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?