I am thrilled to see the interest in Bravo Charlie Addresses!  Spread the word, “Bravo Charlie One means money.”

I wrote it from “scratch”—well, not really.  At first, I simply glued together sipa’s reference bech32 code, Core’s secp256k1, luke-jr’s libbase58, and standard POSIX extended regular expressions.  Then due to build dependency problems on my airgap machine, I had to semi-rewrite it with OpenSSL secp256k1 and my own base58check encoder using OpenSSL bignums.  This was supposed to be what you might call an “little pastime project”, done on a whim.

To be absolutely clear, I do handle both Bech32 and P2SH-nested Segwit “3” addresses.  Right now, pattern-matching is done on either one or the other; that’s stupid.  I intend to change it to check the same trial key against different patterns for both, if the operator so desires.

The code is slow, partly because I do a real bruteforce search:  Read a new private key off /dev/urandom, try its corresponding public key, and throw it away if that doesn’t match.  I always somewhat distrusted vanity addresses; and this is the paranoid way to make them.  Partly also because I made no attempt to make it fast.  I will try to get you some useful benchmark numbers after I do some immediately planned improvements.  Moreover, although I paid careful attention to basic tests, I’ll want to test more and play with testnet coins before foisting my code on other people where a bug could lose Other People’s Money.

The precursor idea popped into my head when I observed that ChipMixer is still not using Segwit; thus, I had in the back of my mind to see how hard it would be to make bulk Segwit addresses on demand.  It’s trivial; and my code will churn out as many thousands of nested-P2SH or Bech32 addresses and matching private keys as you could want, lightning-fast.  (Of course, ordinary users should use an HD wallet!)  I was pushed to action when I hit a thread where somebody was criticizing the aesthetics of Bech32.  What better way to persuade that Bech32 is pretty, than to show off a sweet vanity address?  So, I whipped up my bulk address generator and tacked on a regex pattern loop function.

Note for Microsoft Windows users:  My vanity generator uses POSIX regular expressions and other standard Unix APIs; and I want to keep dependencies to a minimum, for my own usage.  Thus, I doubt there would ever be a version which could be compiled with MSVC.  But I think that mingw has regex support; so perhaps there may be hope.  I would not be able to test the resulting binaries myself; for I have no Windows in my home or office.  I may try to get this working, if I see signs of sufficient interest (viz., potential for tips).  I myself will build and test on FreeBSD and Linux, in that order.

---

Sundry reasons:

• I was scratching an itch.
• I needed a bulk address generator anyway.
• I wanted something small and light, with as few dependencies as practicable.
• vanitygen is AGPL.  As an advocate of liberal licensing and best of all, the public domain, I will avoid contributing my time and effort to a project whose code I can’t borrow without virally infecting my own codebase; GPL is a one-way street, and worst of all is AGPL.
• vanitygen appears to be abandonware, with accumulating pull requests and an otherwise-maintained fork which people don’t seem to be switching to.
• I do not have the requisite cryptanalytic expertise for evaluating the safety of the EC trick which vanitygen uses for speedup.  This is not to criticize vanitygen specifically:  I have significant general misgivings about vanity addresses; and anything other than fully random key selection makes me uncomfortable.
• I have no idea what it would take to make vanitygen use compressed public keys as mandatory for Segwit (one pull request is open since 2013, with a severe bug as noted in the comments), then add the other needed code for Segwit address generation.  (Aside:  Even if you were to desire to still use old-style addresses without the Segwit fee discount, use of uncompressed public keys is really throwing away your money on fees.)  Whereas I already know exactly how to create such an implementation myself—on a whim—which this was.
• I have never used vanitygen.  I first looked at its codebase a few minutes ago, to inform myself for an intelligent reply to you.  I didn’t actively choose not to patch a program I’ve never used; I independently wanted something, so I wrote it, and that’s that.

A reply to this:


...devolved to this:


Are you speculating, or do you have certain knowledge?  I asked a question, because I don’t know.  I nominally addressed my question to Vod, because I’ve seen him deeply involved in discussions of combatting abuse; and I inferred that perhaps, he may know something which I do not.  And I keep asking, because three weeks ago I wound up chasing my tail trying to work out a viable means of public-key auth login—which would help solve the problem of bruteforce login attempts, but would do nothing against spambots.[1]

I set forth a query clearly in the interrogative; and I laid out my reasoning for an educated hypothesis.  Whereas my question can only be answered by somebody who does actually know the precise nature of the problem which theymos ameliorated with the login CAPTCHA.  If you do know, please say; but if you don’t, then I can tell you, your guess isn’t nearly as good as mine is.

I have been repeatedly asking all month whether my hypothesis about the login CAPTCHA is correct.  There are exactly three valid answers:  “Yes”, “no”, and “no comment—that is sensitive operational security information which we will not tell to someone we don’t know and trust.”  Any of those would be fine—from someone who actually knows.  Whereas if you’re simply hashing out your own hypothesis, then this whole discussion is a waste of my time.

---

1. Any spambot which could log in and set up a client certificate for future logins, could also save a cookie for staying logged in.  Duh.  But I’d like to know for certain before I pour more time into the sorry state of public-key auth on the Web.  Browser vendors deprecated or even removed <keygen> while I wasn’t looking.  Only a minuscule fraction of users would be able to manually generate TLS certificate requests, or use alternatives such as SSH tunnels, OpenVPN, etc., etc.  I spent hours trying to figure out an administrator-friendly and user-friendly solution, with the goal of making a suggestion which might actually be implemented.  Then I realized, I shouldn’t bother trying to otherwise resolve the CAPTCHA’s purpose when I do not know its purpose with any degree of certainty.

---

Well, at least that wouldn’t make things worse; but from my perspective, it wouldn’t make things better, either!

[The following is based on recent discussions here, and is substantively cross-posted from the dev list so as to reach a wider audience.  I intend to follow up with an appropriately flavoured topic in the general user forum, and edit to add a link up here.]

I here record and expand an idea I had a few days ago on this forum about BIP 173 Bech32 addresses.  TL;DR abstract:

• The Bitcoin Bech32 address nickname:  “Bravo Charlie Addresses”.
• The Bitcoin Bech32 motto:  “Bravo Charlie One means money.”
• Bech32 would also be a superior human-facing format for key fingerprints for PGP, SSH, and even TLS.  There is an urgent general need for a specification which reduces the inherent pain of wetware in handling pseudorandom strings.

---

To help gain user familiarity with and acceptance of the error-correcting, case-insensitive Bitcoin addresses of the future, I propose a need for what I think marketers call “branding”.  The best branding is that which derives naturally from some intrinsic quality of a thing; wherefore I look to what may perhaps be a bit of serendipity in the specification.

I expect that in practical use, one of the great advantages of Bech32 addresses will be the relative ease of communicating them aloud—especially over the phone.  In similar circumstances, when trying to convey unusual names or pseudorandom strings, I’ve found radio alphabets to work well at their intended purpose.  And when reading Bech32 Bitcoin addresses in the most popular radio alphabet, they will always start with a catchy phrase:  “Bravo Charlie One”.

That’s memorable, $SEARCH-able, and yet also one of those unique, otherwise meaningless phrases which gets marketers excited.  Keeping to a word triplet, I hereby nominate for consideration as the official nickname for Bech32 Bitcoin use:  “Bravo Charlie Addresses”.  These are the Bitcoin addresses with the magic words, suitable for a motto:  “Bravo Charlie One means money.”  Add a logo à la Segwit’s, and raise user awareness of this exciting new technology!

Beyond the branding issue, recommendations for Bitcoin spelling-alphabet use in English and other languages may perhaps be a suitable matter for such standardization as would facilitate coherent user documentation.  I invite discussion.

Of course, this branding only applies directly to Bitcoin Bech32 addresses.  The BIP 173 authors were gracious to make the standard generally adaptable; and it has already seen some uptake amongst altcoins.  I myself am now contemplating how Bech32 would be a superior human-facing format for key fingerprints for PGP, SSH, and even TLS, with HRPs of “pgp”, “ssh”, “tls”, etc. and some appropriate means of embedding the key type just as “bc” embeds the witness version.  There is an urgent general need for a specification which reduces the inherent pain of wetware in handling pseudorandom strings; and I do think that anything which familiarizes users with Bech32 in a specific use will be beneficial to Bech32 adoption generally.

To celebrate, I created for myself a new Bravo Charlie Address which expresses that I am pleased:  Now, I have an error-correcting, case-insensitive address which can receive only genuine Bitcoin cash money.  Because “Bravo Charlie One means money.”


Here’s to the Bitcoin address format of the future!

Please reread what I said, as quoted above; I have edited the quote to put the key words in red.  If already building a spambot which opens web login sessions, it would be trivial to make it keep many different sessions in parallel.  Get them all logged in—perhaps via a scammy website which proxies the CAPTCHA, and offers real or imaginary freebies (free Bitcoin!) for completing CAPTCHAs.  Then, leave them logged in.

You incorrectly assume that a spammer must log in his sibyl accounts from the same IP address.  Spammers often have many IP addresses; and indeed, it would be easy to do away with account farmers if they always logged their zillions of accounts in and out from the same IP address.  Also, multiple accounts can be logged in from the same IP address.  Either way, there is no reason for a spambot to ever log out.

Since multiple users can be legitimately logged in from the same IP address, banning IP addresses for failed login attempts is also not a solution to bruteforcing.  If theymos did that, then it would be trivial for an attacker to effectually ban Tor users from login to bitcointalk.org by deliberately making many bad login attempts from every exit node.  Thus, I infer that theymos does not do this; and I assume the timeout you describe somehow works with cookies, or the like.  Granted, I could be wrong there.  It may simply be that nobody evil has thus far bothered to get Tor exits banned from attempted login.

Assuming a correlation between users and IP addresses is a common fallacy.  N.b., I have no idea how many users are currently logged into bitcointalk.org from the same IP address as I am using to post this right now.  I’m almost certainly not the only one; moreover, my connecting IP address frequently changes.  There are also reasons other than privacy why many users may share the same IP address:  Carrier-grade NAT due to IPv4 address exhaustion, corporate proxies, etc., etc.  —Also reasons why the same user may rapidly change IP addresses:  Mobile users....  There is not and never was any strong correlation between people and IP addresses; security systems which assume that tend to simultaneously lock out legitimate users, and fail to lock out malicious attackers.  Failure both ways.

---

Well, if you signed up via Tor, then you must have some Bitcoin; theymos charges a small anti-abuse fee for new account signup from Tor and other IP addresses which have high risk for abuse.  And if you didn’t sign up through Tor, then you are mixing Tor and non-Tor usage for the same account.  That’s a big privacy no-no.

If you use Tor, then you should use only Tor Browser for your web browser.  I actually dislike it, myself; but it has special privacy and antifingerprinting features, and also, it helps you blend into a crowd when you use the same browser as everybody else.  The technical term is “anonymity set”.  If you use a different browser with Tor, then you may still be more or less readily identifiable and/or trackable (web session linkage).  You could be the only person using Browser X in a crowd of two million people using Tor Browser through Tor exits.  If you want to use some privacy network other than Tor, I have no specific advice for you at this time.  But this is all off-topic.  If you desire a few further tips of where to learn about these things, feel free to ask your question in the Off-topic forum and PM me a link to your post.  Just don’t get sucked into the huge heaps of trash posted there—much of which is posted by spammers trying to up their post counts; that’s the kind of dirt which can rub off on a newbie, if you get involved with it.

Colorblind, as I told you in the other thread where you raised this, there is already an altcoin which does this.  Go there.  Or else, go to the Flat Earth thread.  Either way, understand that this will never happen in Bitcoin.  There are certain iron-clad, carved-in-stone, oath-bound-on-pain-of-death rules in Bitcoin, and this is one of them; you may as well suggest inflating the monetary base beyond 21 million bitcoins, or requiring KYC checks to transact Bitcoin, or making transactions reversible by an Appellate Court of Bitcoin which holds tx override keys (or perhaps via “the execution of an irregular state change” as decreed by the Grand Poobah in Chief).

I am not even remotely interested in further expounding on the technical reasons why this idea is a non-solution to a non-problem; for the idea itself is reprehensible.  You are advocating massive theft—and you are advocating the total destruction of Bitcoin.  That does not even deserve serious discussion.

---

Edit—P.S., one technical argument:  You should learn to spell “aging” before you write a proposal about it.  A respect for the simplest orthography is the handmaiden of sound monetary policy the basic honesty of not stealing people’s money.

This would (0) require Javascript (as reCAPTCHA does—but worse, IIRC this also requires asm.js/webasm which I disable even when enabling JS), and (1) have a drastically disparate impact on those using fast computers versus slow computers/netbooks/mobile devices.  It is also questionable whether it would answer the threat being staved off by the CAPTCHA.  Admittedly, it would work better against what I suspect the threat to be, rather than against spam.

Vod, do you know the actual purpose of the CAPTCHA?  Everybody seems to assume that it’s there to keep out spambots.[1]  My first hunch is that theymos has a problem with bruteforcing of luser passwords, resulting in stolen accounts.  You may perhaps know for certain, not as a matter of assumptions or speculation.

I would understand if theymos desires that such information not be disclosed.  But I ask because I have wanted to suggest some alternative solutions; and it’s difficult to know whether my ideas are even worth mentioning.

---

1. This common assumption simply does not make sense to me.  An account farmer could easily use human labour (self or others) to log bots into a large numbers of accounts with “stay logged in” checked, then let them stay logged in to make unlimited spam/nonsense/copypaste posts.  It would be trivial; all the bots would need to do is to keep their cookies.  I know this because I myself now stay logged in, on a credential apparently set to expire in the year 2023.  I have not filled out the CAPTCHA since 10 December.  Whereas a password bruteforcer would indeed be stymied by the CAPTCHA.  A bruteforcer would also be slowed down by a POW.  A spambot could complete the POW once, then stay logged in for years or until permabanned.

Tor user here.  Please see the thread I started after my 17-circuit-change login instance, documented with screenshots of various error messages; my conclusion thus far:


P.S., I suggest that you consider purchasing a Copper Membership.  Your Tor signup fee can be put toward the price; and it will let you embed images as a newbie, among other perqs.

Well, I suppose that different people will have differing comfort levels on that point; and it also sounds as if you have more practical experience with such than I do.  I know it drives me crazy, as well as effectually doubling the spoken length of the alphabetic parts.

Thanks again for the feedback.

Thanks for the feedback.  I agree; that’s easiest for me, too.

Now, how would you find that to read aloud to someone else using a radio alphabet?  Whether an official standard radio alphabet, or your own ad hoc choices of words to unambigously represent letters.  Please try it, by yourself or with a friend.  Also imagine what it would be like to read or hear this in word-letters over the phone, perhaps over a bad mobile or VoIP connection with some dropouts.

I’ve tried doing this aloud, though only to myself thus far.  The ease of reading these out without case distinction is why I nickname these “Bravo Charlie Addresses”, an idea I had earlier in this thread; we now intersect with a topic about which I’ve been preparing to otherwise post.


That won’t work so well with the old-style addresses.

Okay, wiseacre.  I cede to your superior knowledge of the world.  But then, I have a question for you:  Praytell, how do the Bitcoin developers get away with it?  Satoshi “always used Tor”, as do I; but most current Bitcoin developers have their legal names, photos, and physical locations easily discoverable by the police.  Please explain to me their elite capture-avoidance techniques which they use to stay out of prison whilst developing illegal currency.  They have nowhere to run, if it’s “illegal in every country in the world!!”

Somebody should also tip off the Winkevoss brothers so they can stay one step ahead of the heat.


Glad to hear it.


If it’s not decentralized, trustless, and permissionless, then it’s Paypal 2.0 (but so much slower and more expensive than the real Paypal).

Here is a good GUI idea, which I’ve had before for displaying hashes:  Subtly break the long pseudorandom-looking string into chunks using something between a hair-space (U+200A) and a punctuation space (U+2008).  The space should not be too large—just enough for subtle visual breakup of the string.  In my experience, the chunks should each be about four characters.  The particulars really depend on the display font, and also the alphabet of the “pseudorandom” string.

Of course, copy/paste of the string must not be affected.  The extra space is display formatting only, not the actual addition of characters to the string.

In the forum font, with very little typographic control of what I can post, how does this look to you?  (Warning:  I added actual Unicode U+2009 THIN SPACE; do not copypaste the display text, though the link URI is unaffected.)


Rebroken into evenly divisible, larger chunks:


With this address length, that can be done two different ways.  N.b. all Bitcoin address lengths can vary.


Which of those do you find easiest on the eyes?  I myself deem the four-character chunks to be visually optimal.  That also seems a de facto standard in printing account numbers, tracking numbers, and the like.

I used to have a set of LaTeX macros to do this for high-quality typesetting and deadtree printing of hashes; thus I can attest, it much enhances readability.  I think I may also have worked out a way to do it in HTML/CSS without any adding spaces on copypaste.

Additional implementation note:  Wallet GUIs should filter out any Unicode space-class characters from a pasted string, in case other software did this wrongly—or in case somebody added spacing characters by hand, as here.

Implementers, please do this!  I mean generally, not only for Bech32.

I think I see what you mean.  I got wrong what I said in my “nit”; but I now have another.  Please correct me if I messed up something else here; I think that breaking a keyhash found on blockchain would require the following steps, in this order:

0. It’s impossible to recover 256 bits of pseudorandom anything from 160 pigeonholes; so I will infer that to be, find any P0 of the many 256-bit preimages for a given RIPEMD160 hash.  With a quantum computer, consider that to be the equivalent of an 80-bit problem.  Not what I would call zero.

1. Then, find a string P1 which is a valid secp256k1 public key, and is a SHA256 preimage for the SHA256 image P0.  I will wave my hands around various factors which make the search easier by expanding the search set (compressed or uncompressed public keys double the possibilities—but only if the output is not for a Segwit address) or harder (need a valid secp256k1 pubkey, not an arbitrary bitstring).  For the reason you stated, count this as the equivalent of a 128-bit problem.

2. Wield the almighty Quantum Computer to break the public key—thus revealing a private key which can spend for a public key which SHA256 hashes to a bitstring which hashes to the RIPEMD160 hash specified in the Bitcoin output.  Breaking the public key would still not be free.  I don’t know how to quantify that in “bits of security”.

So—I see the equivalent of 208+x bits of quantum computer work.  Did I get it right here?


Even if they could, why bother to ever apply the fruits of that hypothetical research?  Endpoint security is so awful, and rubber hoses/$5 wrenches/long prison sentences are readily available.

That’s another point which should be well remembered by the people worried about hypothetical future post-quantum attacks on Bitcoin:  Malware, kidnappings, and similar attacks are the biggest vulnerability for the average user today.  Do you even know how to properly secure a computer against even the stupidest commodity s’kiddie coin stealer?  Do you brag about th size of your coin stash on Internet forums, under the doubly false presumption that both Internet posts and bitcoins be “anonymous”?  Don’t worry so much about threats which do not currently exist and may perhaps never exist, when shoot your own foot off every day.

You forgot the fearsome new technology of Quantum FUD®.  With Quantum FUD® technology, the quantum computer will use quantum tunnelling teleportation to sneak into your house, eat all the cookies you left out for Santa, spray-paint graffiti all over your walls, ravish your spouse, and then sit down at your computer and send all your bitcoins to 1BitcoinEaterAddressDontSendf59kuE.  But you will never even know it, because it will also use relativistic speed-of-light acceleration to compress you thinner than dollar bill, slow down your clocks, and produce a paradox where you become your own grandfather (“hello, Mom!”).

With Quantum FUD® technology, the quantum computer will rewrite the blockchain; and also, it will rewrite the history of the entire universe multiverse.

The quantum computer with Quantum FUD® technology is insidious and subtle.  It is dangerous and terrifying to behold.  It is also a rather interesting shade of mauve.

Now that I know the truth about Quantum FUD®, I am scared.  I will now stay away from Bitcoin.  Also, I will avoid computers, sunlight, and breathing.  Thank you for informing me about this horrific existential threat to the Bitcoin.

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


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.


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


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.

haltingprobability, thank you for your informative overview of the sitation.

A few nits:


0. Actually, that would be 160-bit equivalent security, yes?

1. As a general point, I will worry about disclosing Bitcoin public keys at the same time I start to worry about disclosing my long-term PGP public key.  (For those in the peanut gallery:  The latter would be entirely useless without public disclosure.)

There are excellent reasons to avoid address reuse; but this is not one of them.  I say this as a paranoid security nut:  The security of publicly disclosed public keys is just fine.  That is why they are called public keys.  The only exception I would here make is if you have coins which you intend to potentially leave in cold storage for decades.  Then, yes, you will want the extra security margin of the key being unpublished.  That’s not only a concern about quantum computers:  Unexpected cryptanalytic techniques could develop over the course of many years.  For cryptography which really needs to stand the test of time, reducing your security requirements to a hash is simply good security hygiene.  (For the same reason, I want to switch from the trust anchoring of my “nullius” nym from Ed25519 to Lamport signatures; I simply need to find or build a readily available, reasonably usable, long-term stable implementation.)

Three questions (not to beat a horse long dead):

0. How do you prevent malicious parties, especially malicious miners from gaming your system with spam attacks to raise the blocksize?  N.b. that a malicious miner with huge hashrate (such as Jihan) has relatively low cost for spam attacks, since any fees for the spam go back to him for blocks he himself mines.

1. What does this even solve?  A blocksize increase increases linearly.  But Bitcoin needs capacity increase by orders of magnitude—I think at least 10000x, to provide adequate room to grow in the next decade or so.  An 8MB or even a 32MB blocksize would promptly fill today, with no room for tomorrow.  If BCH had Bitcoin’s popularity and demand, then BCH would have high fees, too (and if I had cybernetic wings welded into my back...).  The problem as you state it is really one of scaling.  Linear blocksize increase is a non-solution to scaling.

2. How does your idea solve problems caused by increased blocksize, such as UTXO set growth, increased orphan rate, etc., etc.?  Blocks larger than 4MB would not be safe for the network.  With Segwit’s 4MB block weight limit, we already have the potential to approach that limit.  N.b. for those in the peanut gallery, increased disk use for a growing blockchain is the smallest problem with increased blocksize.


Most people don’t realize that competition to increase hashrate (thus difficulty) assures Bitcoin’s BFT security.  I noted this above.  If Satoshi would have been the only one mining all these years, what would now stop somebody from spinning up $100k in EC2 nodes, instantly grabbing 99.999999% of the global hashrate (forget a “51% attack”!), and arbitrarily rewriting the blockchain on whim?  To describe only one obvious and easy practical attack vector.

We don’t need for miners to consume less energy.  We need for them to consume more.  Part of the beauty of Bitcoin’s design is that the higher the total value of the network, and thus the higher its security needs, the competition and difficulty of mining automatically increases to adjust.  Satoshi’s home PC was an adequate miner when a bitcoin was worth 30¢.  Nowadays, anybody who could acquire ($$$) a majority of hashrate could steal a fortune—and worse, disrupt a market worth the current exchange eqivalent of $300+ billions; there would be all sorts of nefarious ways to profit from that.  We need for mining to be collectively expensive, prohibitively expensive from the perspective of anybody trying to acquire majority hashrate.

But that expense should never be centralized, which it is now; for then, that expense buys power....

---

Bingo.  And the long-term solution is to see serious competition in ASIC production.

How many people even realize that something like 70% of all hashpower is from ASICs produced by Bitcoin’s current most dangerous enemy?  Who currently accepts payment in their own pet scamcoin instead of Bitcoin, so you are coerced to help pump BCH if you want to buy from a supplier who in practice has something almost tantamount to a monopoly.  What an insulting dilemma for Bitcoin supporters.

I want to see stocking-stuffer ASIC toys which can be sold as a mass-market consumer item, and would each give (via a mining pool) about the same microincome as clicking ads on a “faucet” site.  Call that the ARM/Raspberry Pi level of ASIC.  One step up, I want to see ASICs as cheap and readily available as a commodity consumer CPU.  The equivalents of Celeron/i3/i5/i7 ASICS, for casual miners to moderate enthusiasts.  If ten million people each had an average of a measly 500 GH/s, the result would sum to 5 EH/s.  Current global hashrate is about 8.5 EH/s.  Jihan would cry.

Why do you want the same genesis block and the same network port?  There can be no good reason for this.


That’s an install process issue.  Further than that, I will feign ignorance because there is no %appdata% on my system.


So—you’re changing the monetary rules, but you want to keep the same network port?  This makes no sense, and it’s asking for trouble for yourself.

You need to change (at least) all the items I listed earlier.

In reply to these, and likely others earlier in the thread:



Smart thinking!  A day or two ago, I whipped up a quickie Segwit address generator with a simple regex search.  It can produce both P2WPKH-nested-in-P2SH and Bech32 addresses.  It’s quite trivial; it lacks vanitygen’s features, and probably also falls short in performance.  [Edit 2018-02-12:  segvan: Segwit vanity address & bulk address generator (Github).]

Some sample outputs from short patterns:

3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG  (^3NULL[0-9])

bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h (hahah; ^bc1qcash[0-9])

From earlier tests, WIF private key import was confirmed by me to work perfectly in Electrum:


The code is in C, Unix-only.  It’s fairly trivial; it essentially glues together Core’s secp256k1 library, luke-jr’s libbase58, and sipa’s reference Bech32 code.  It has almost no features; it won’t even try to tell you if the pattern you seek is impossible.  I’d intended to toss it out there somewhere for others to play with; but it devolved into a patchwork of #ifdefs with multiple different code paths, due to an build-time problem with dependencies.  It would require time and effort to clean up.

How great is the interest in this?

If you are creating an altcoin, you had better change the genesis block.  Why would you want or use Bitcoin’s genesis block, with an nTime of 1231006505 (2009-01-03 18:15:05Z)?  Also, you will need to change:

• The port number.
• The network magic.
• The block magic number.
• The address version prefix (very important; do you see all these threads of people who sent BCH to a Bitcoin address, or vice versa?).
• A bunch of other things I am not thinking of off the top of my head for you.  Do some research.

Of course, also you will need to change the name.


This is why you change the genesis block, the network magic, and various other parameters.  If you change nothing, then your “clone” client will promptly start following Bitcoin’s blockchain instead of yours, because Bitcoin will have (many orders of magnitude) higher total POW.


Say what?  I don’t even understand this question.  You should change the genesis block, Block 0; and if you don’t, then everything you generate from Block 1 onward will be different than Bitcoin.

So, I grabbed my shovel and started digging.  C’mon, folks.  Implausible as the melodramatic “long time Bitcoiner of 6 years” from a 30-post Jr. Member account did seem, it takes only one click to see that fonestar’s account was registered 2011-06-03; and a quick check of the blockchain shows that the address in his signature, 16bY6d2wisEZ78pU6UaYf6fedmN4fBhsfF, has been in use since 2013-03-14.  Only a spoon-sized shovel is required to dig up that much.

fonestar’s forum account was shows no posts from 2011 to 2014, and 2014 to December 2016, and December 2016 to December 2017 (with only one post each in 2011 and 2016).  That leaves the question:  Is the account controlled by the same person who registered it?  Of course, the only proof which could be had about the Bitcoin address would be a signature.

As for the account, my conclusion is yes, this seems to be the same individual.  And he’s a flake—surprise, surprise.  Worse than that:  You know those disaffected teenage losers who stop liking a band when it becomes popular?  That seems to sum up fonestar’s mentality.

Back in 2014, fonestar was snidely downtalking the “geezers and goldbugs” on Zerohedge—where by his own description, he was trolling:


He had a cheap gimmick of speaking of himself in the third person, as you can see.  It made him seem so super-cool.  No, wait:  It made him sound like a total whack job.

Thus, now that Bitcoin is popular and successful, it is understandable when fonestar says the following.  Evidently, Bitcoiners are the new “geezers and goldbugs” to him; and fonestar himself is now “the Energizer bunny of BCH trolls”:




(By the way, from that last, you can tell how wildly inaccurate fonestar’s information is about everything whatsoever.  Charlie Lee, 2017-01-06: “My Vision For SegWit And Lightning Networks On Litecoin And Bitcoin”  (“You’ve probably seen that I recently started advocating for SegWit to activate on Litecoin and Bitcoin.”))

---

First reply, and still the best one.  My initial reaction, exactly.