This is why in my own post above, I specified, “with working random number generators”.  This is imperative for any cryptographic software of any kind; if you do not have a working CSPRNG, where the CS stands for Cryptographically Secure, then you have nothing else, either.


In my preferred kernel (FreeBSD), as of last time I read those portions of the code, the entropy harvester does not feed the PRNG an estimate of more than 1–2 bits of entropy for any hardware event.  I am of the school of thought that entropy estimation as a concept is problematic at best; but if and when it must be done, it must be done conservatively.

Estimating 10 bits of entropy off a single instance of any microsecond timer event seems suicidal to me.  Among other problems, this translates to an assumption that all precision below one millisecond in the timing of that event be completely unpredictable in all circumstances—even to unprivileged code running on the same CPU as handles the interrupt!

DannyHamilton is right:  The acquisition of cryptographically secure randomness is not only an expert domain, but a specialist expert domain which invokes both maths and physics.  Even professional mathematicians who are not cryptographers will probably get this wrong.  Almost all working programmers will get it wrong.  Once upon a time, the individual entrusted to maintain Debian’s vendored OpenSSL got it very, very wrong—causing a spectacular blow-up of most cryptography involving Debian systems from 2006–08.  Conventional wisdom gets an awful lot wrong.  There is a high probability (hah!) that you will get it wrong, too.

Worst of all, there is no certain means to prove that you got it right.  Statistical tests can easily demonstrate that a given bag of bits is not random; but no test can prove that one is.  Passing the DieHard suite (or similar) does not mean that your numbers are sufficiently random for cryptographic purposes.  The only way to be sure is to possess a deep theoretical knowledge matched by practical knowledge of real-world cryptanalytic attacks which target insufficiency of entropy.


Don’t take any chances with your randomness!

On Unix or Linux, read() off /dev/urandom; or use whatever special nonportable APIs may be offered to obtain randomness directly from the kernel (getrandom(), a special sysctl, etc.).  On other platforms, find the equivalent.  If writing a web application, use getRandomValues() (for most any current browser) or, if feasible, the generateKey method; then, pray to whatever gods you believe in that the browser is not too stupid.


Do not roll your own.  Do not conflate distinct meanings of the overloaded word “entropy”, then gather “entropy” the same measurements as taken by Panopticlick (!) (!!) (for Bitcoin!).  Also, do not roll your own using C’s rand(), e.g.:


Let that horror be a lesson.  For unless you have considerable specialist expertise, you cannot rely on your results being any better.  And I repeat:  If you do not have a working Cryptographically Secure PRNG, then you have nothing else, either.

Quotable.

For the benefit of any newbies reading this—and I mean, people who do not brag about development knowledge or experience, and have never even read the Wikipedia article on RSA—the answer is:  No, RSA is not based on a curve.  RSA is not elliptic-curve cryptography.  RSA is based on the RSA problem, which is closely related to (but not identical with) the problem of factoring large integers.  Elliptic curve cryptography such as Bitcoin’s secp256k1 is based on the elliptic curve discrete logarithm problem (ECDLP).  Bitcoin does not use RSA anywhere for any purpose whatsoever.


After decades of disdain on my part, I finally understand why people use the term “LOL”.  Did you just try to use a PGP public key fingerprint as an RSA key?  Why yes, it seems you did (or at least, you claimed to).

That is a 160-bit SHA-1 hash, calculated as specified by RFC 4880 § 12.2.  Depending on how those bits hashed out, you perhaps may only have slightly more luck finding in it a minuscule RSA modulus plus public exponent than you would using RSA-512 to generate Bitcoin keys.

Thanks, pebwindkraft.  Why yes, I think all the major BSDs have a strong manpage culture.  I myself have much benefitted from that, and I have been inculcuated with it along the way.

I was there speaking to my annoyance at code only “documented” by wikis, webpages, or (for libraries) the output of Doxygen.  If software lacks reasonably complete usage documentation which can be quickly referenced at the tty by typing `man xxx`, without firing up a web browser or even being online, then that severely impairs its usability.

From the producer end, it sometimes occurs that when writing a manpage, I realize that I am documenting a wish for what the program should do, not what it actually does.  Then, I change the code to bring it in line with the manpage.  This happened repeatedly with easyseed.  Different levels of thought are required respectively for writing code, and explaining its external features in natural language.  Exercising both improves the code.

I do believe that the code itself is a form of documentation; and I love reading well-written C code.  For those who wish to modify the code, the code itself documents what it does; and code comments explain why, when that is nonobvious or based on some external specification.  Written specifications are certainly needed for that teamwork you mention; and I judge specifications based on whether or not I need to refer to existing code to implement from spec.  The manpage is most of all for those who wish to use the results; and ultimately, it is the results that count.


I hope that you find this utility useful for your Bech32 encoding needs.  Please don’t hesitate to inquire with any questions or suggestions.

(Nothing worth replying to.)


Oh, please.  Just because you’re stupid, don’t assume that I am—or that I was born yesterday.

(And I must ask, why do you post literally an average of 20 times per day on the Bitcoin Forum if you so loathe it?  Why yes, this forum is for Bitcoin development.)

But just in case any observer has any doubt about your transparent, juvenile excuse:  About 50 minutes after you started this thread, you posted substantially the same question in a different thread explicitly titled “Elliptic curve point of R” amidst discussion of secp256k1 (archive; red colour is added to highlight in the following):


Thus in the world according to Anti-Cen, RSA is explicitly “based on” a “curve”.

I should also note, anybody who uses 512-bit RSA for any purpose whatsoever is a moron.  512-bit RSA is breakable, not only in theory but as repeatedly demonstrated in reality.

Now, a clarification for those reading this:


Here, you are replying to your own words which you directed at me on 2018-01-02 11:36:57.  Don’t put words in my mouth.

I quoted you with proper attribution in the post to which you replied.  But you habitually strip attribution from quotes; and it is evident that you here confused yourself.

Regardless—really, regardless—I will handily admit that the question of how to use 512-bit RSA objects for Bitcoin secp25k1 ECDSA keys does indeed go over my head.  Whoosh.

---

You edited your post immediately after you posted it.  Following is the original version; I replied to the latest version I have seen.  Please be advised that I am archiving this thread.  (Edit:  Thus far, snapshots at web.archive.org: 0, 1, 2, 3 and archive.is: 0, 1, 2, 3.)

Now shoo, go away.

Anti-Cen tries to use 512-bit RSA for Bitcoin keys (archive) (again!).  I suggest that his credibility on any technical topic whatsoever is absolutely zero.


And for sure, explanation of how 512-bit RSA is used in the Lightning Network because Bitcoin developers are ignorant doofuses who lack Anti-Cen’s deep experiential knowledge of distributed databases.

(Your suggestion is excellent, pebwindkraft, as would be known to anybody who knows how to successfully argue a point in a persuasive manner—instead of just starting pointless arguments everywhere.)

Theoreticians call this “possible”, because it is indeed possible in theory.  But your question cannot be adequately answered without focusing on the probability:  The precise reason why it is theoretically “possible” is that there is a nonzero probability.  To understand what that means requires discussing probabilities.

Humans generally have a problem grasping large numbers.  That is why comparisons are given, such as to the estimated number of atoms in the observable universe.  Otherwise, the reader may fail to grasp that the number is not only large:⁰  It is astronomically, unthinkably huge.

On a much smaller scale, this is also the failing which causes many people to buy lottery tickets—whereas a typical large-jackpot lottery typically has on the order of 10⁸ combinations.  N.b. that 10⁷⁷ is 10⁶⁹ times bigger than 10⁸.  This difference is itself so vast that it is difficult to explain in understandable terms.

The size of these numbers is why I must draw an important distinction:  Theoretically, it is possible for two people with working random number generators to pick the same keys.  However, in real-world, practical terms, such a thing is impossible.  The aforestated “nonzero probability” is so close to zero that we can safely ignore it.

Aside:

Terminology note:  You refer to 256-bit numbers.  Such numbers indeed have “64 hexadecimal” digits; but computers handle them in binary, that is to say, in bits. 

Also, you refer to a “seed”; I presume that you refer to Bitcoin’s private keys, which are 256-bit numbers.  A BIP 32 seed is 512 bits in total.

Most Bitcoin addresses (excepting the new P2WSH) have “only” 160 bits of substantial information.  Thus there are “only” on the order of 10⁴⁸ potential addresses of each other type (P2PKH, P2WPKH, P2SH).  That is still an astronomically large number.

If one billion Bitcoin users each generated one million addresses per second for the next thousand years, that would only come to on the order of 10²⁵ addresses.  Granted, at that point, the probability of a birthday collision in the 10⁴⁸ address space would be non-negligible.  I may consider that a long-term worry when there exist one billion Bitcoin users, each generating one million addresses per second—day and night.

---

0. My apologies to mathematicians who consider “huge” to start with Graham’s Number.  This discussion pertains to numbers so puny that they can be written in exponential notation.

Folks, I know that you desire to be helpful in “Development & Technical Discussion”; but please look at who is posting here.

After literally over 900 posts mostly bashing Bitcoin whilst boasting of his superior technical knowledge and extensive development experience, Anti-Cen has—tried to use RSA for Bitcoin.  512-bit RSA, at that (!).

---

Edit:  And he has done so in multiple threads, including one explicitly titled “Elliptic curve point of R”:

End edit.

---

He has now gone from flaunting arrogant ignorance to self-satirizing it.  As if it were not enough to posit that CPUs were useful for Bitcoin mining, which has not been the case for over half a decade:

Apologies for the delayed reply.  Any luck with getting it to compile on your platform?

Nonsense.  What DannyHamilton described is not only a well-known “best practice”, but also the actual and longstanding current practice of numerous Bitcoin businesses, both large and small.  Assigning one address per transaction is also the only practical, reliable means of tracking payments and matching payments to transactions; thus, a Bitcoin address works out perfectly as a quasi invoice number—or even an actual invoice number.

I emphasize that this is the common and customary usage.  Forget about discussing your qualifications as a developer:  If you have not seen this as a customer, such reveals that you have rarely if ever used Bitcoin at all.


Years of the real-world experience of actual businesses flatly contradict your supposition.

What happens if a partial payment is received?  Whatever happens according to the payee’s usual handling of partly-paid invoices—that’s what.  Using one address per transaction makes it easier to track and account for partial payments.


With your reference to “(HD)”, you are confusing the BIP 32 seed with a Bitcoin private key.  From a single seed, a BIP 32 HD wallet can generate up to 2,147,483,648 hardened or non-hardened private-key/address pairs per derivation path.  That’s over two billion addresses.

At the current rate of transactions per day, it would take about 25–35 years for the entire Bitcoin network to process 2,147,483,648 transactions.  If you had somehow anachronistically created an HD wallet when Bitcoin was first released in January 2009, and every Bitcoin transaction ever made had been spent to you with a new address for each one, then you would have still only used a fraction of your addresses.

Still worried about running out of addresses in your HD wallet?


So, if Bitcoin does not provide a privacy suit of armour without special measures, you recommend walking around naked?  (Moreover, given some effort and skill, Bitcoin can be plenty private.)


For a lightweight solution, Electrum provides easy merchant features which even the dullest developer should be able to get working and integrate with a shopcart and accounting backend.  It automatically provides a new address for each payment request, and serves up fancy auto-generated payment request pages with QR codes.  For security, it works fine with a cold wallet (no webserver access to funds).  If you can set up a webserver and a basic shopcart package, then you are capable of doing this, too.

Making this work with Core is not exactly rocket science, either.

Estimating the global average hashrate nowadays at around 8 EH/s (≈ 2⁶³ H/s), Bitcoin miners collectively do on the order of 2⁶⁴ work literally every two seconds.  That is, all miners in the world put together.  To do 2¹²⁸ work would still take them more than one trillion years (l(2^65)/(365.2425*86400))/l(10) ≈ 12.07).  To do 2²⁵⁶ work—forget about it.  What’s 2¹²⁸ × 1 trillion years?

Adding one bit doubles the amount of work needed to bruteforce.  Doubling the number of bits squares the amount of work needed to bruteforce.  To bruteforce 64 bits of key is within the reach of distributed computing, or powerful entities with supercomputers.  To bruteforce 128 bits is humanly impossible, and likely always will be.  Since it is theoretically possible, cryptographers prefer the term “computationally infeasible” to “impossible”.

---

Your report stats as of September 2017 provide one of the reasons why I know to heed your advice on this topic. <g>


Too true.  The Earth is not flat, no compressor can reduce the length of all strings, and Segwit does not remove signatures.  But if somebody has resources to push an agenda, we can repeat ourselves all day and still be drowned out.  Moreover, there must be another line between spiking urban myths in embryonic form, and dutifully replying to nonsense which no reasonably intelligent person would find credible.  Perhaps patterns should be developed of providing brief pointers to concise sources of good information, à la the Usenet “read the FAQ section x.y.z” response.


Well, that is a matter of tact; and I suppose we have a difference of style, perhaps even a difference of opinion.  “In real life”, I am formally courteous to a fault; and I have patience, when I deem fit.  But also “in real life”, I am scathingly sarcastic and active-aggressive in giving short shrift to nonsense.  I am not simply a “keyboard warrior”.  I will call a spade a spade.  I hurt people’s feelings, if they deserve it—not people who make occasional dumb mistakes, as does everybody (including me), but those who are blatantly wrong, incorrigible, ineducable.  And I respect those who do similarly.

Some of the leading Core developers are oft criticized for some alleged lack of “niceness”, usually as perceived by people who are wrong.  To me, that shows only that they are strong, self-confident, and uncompromising.  I also don’t mind seeing djb more or less outright call his colleagues idiots in published papers; sometimes, they are idiots.  Though I am not a Linux fan, I do respect the Torvalds management style.  Yes, I am an unabashed elitist.

So as for authors—and so too as for readers.  Perhaps readers who need diplomatic saccharine are not worth convincing.  A reader who sincerely desires knowledge will care only if I be correct, not whether I have been “nice” in pointing out something wrong; whereas a reader who rejects knowledge due to lack of “niceness” to a third party in the discussion is not worthy of my time, anyway.  That is my opinion.

(Etymological side note:  The word “nice” once upon a time meant “foolish, stupid”.  I find that most fitting, a delicious historical irony.)


Good call.  I’ll take this up further, if it gets split or moved; and otherwise, I’ll fully understand if you don’t.  I don’t know any means of splitting a topic.  This thread has already spawned an offshoot in Meta, q.v., to which it may be suitable to move posts from here; and I don’t mind editing and splitting out my above reply to TechPriest, if necessary.

From my perspective, following are a few tips for intelligent newbies who wish to help keep the forum clean.

The zeroth rule is, give a damn.  I recently reported a year-old copypaste spam.  As seen in the archive, the post immediately after it quoted the spam in its entirety, then replied, “Oh, that's just spamming, man.”  If he successfully identified it as “spamming”, then why did this this person (a “brainwallet”-pusher, by the way) not click the handy “Report to moderator” link?

Sometimes, it is a judgment call.  When I’m unsure, I sometimes reply to a borderline nonsense post (or just ignore it) when I should probably report it.  But if you know that something is spam, please do the right thing.

Use of the report system has been and continues to be a learning process for me.  I started out reporting flagrant spam.  Then I added no-substance posts by apparent account farmers, and reporting of misplaced topics.  More recently, I upgraded to targeting copypasters for permaban.  As you gain experience, you will likely follow some similar trajectory of your own.

Particularly when starting out, reading more than I write has been a useful habit—here as everywhere.  I have carefully experimented with different strategies to raise bad posts to moderator attention, for maximal impact with best use of my time and theirs.  Along the way, tips from Legendaries have been of great assistance; as such, I must thank DannyHamilton for his recent discussion with me, which inspired this post.

Ultimately, as in any endeavour, there is no substitute for experience.  For your hundredth report, you will be faster on the draw and surer in your aim than for your tenth; and I have no doubt, I will learn much more before I make my thousandth report.

The security of exposed Bitcoin public keys is just fine for general usage.  They cannot be hacked.  Answer to the thread’s subject line:  “A million billion trillion zillion years.”  But there is a different, unrelated reason to avoid address reuse:  Privacy.  Avoiding address reuse gives you a modicum of privacy.  That at least makes Chainalysis work for their pay.  Re-using addresses makes transaction linkage trivial, child’s play.

A public key is called a “public key”, because it is secure when exposed in public.  I publish my PGP public keys (and if I didn’t, PGP would be useless).  I am not worried about that.  Each and every time you connect to an https website secured by TLS, the server’s public key is exposed to you—and your symmetric session key is derived from a key-agreement process based on the hardness of the same DLP as is the fundamental basis of most widely-used public-key cryptography other than RSA.  I am not worried about that, either!  Likewise, I am not worried about the security of my Bitcoin public keys.

---

Those concerned about bad randomness causing leaked secret key bits need to read RFC 6979:


Core’s secp256k1 library uses this deterministic, “derandomized” DSA.

I don’t know if Core v0.15.1 uses that library for signing, as of yet; and I am too lazy to grep sources at the moment.  I know that older versions used this library only for verification, where it beat OpenSSL 5–10x in performance.  Does somebody else know off-hand?

If your wallet does not use deterministic ECDSA signing, then—well, I suggest that you should switch software.  This should now be considered a baseline “best practice”.

Of course, if your platform’s RNG is broken, then you have other problems.  Big, bad problems.  But with RFC 6979 signing, leakage of ECDSA private key bits will not be one of them.

---

I argue that even mentioning public-key security in the context of address reuse is a terrible disservice to Bitcoin.  To anybody who do not understand the nuanced technical discussion, it FUDs Bitcoin security for no good reason.  In ordinary circumstances, there is one, and only one excellent reason to avoid address reuse:  Making transaction linking less easy.

I call myself “paranoid”; and there is only one use case in which I would be concerned about exposing the public key:  Long-term storage of funds for decades.  Yes, in that case, I want the extra security of reducing my attack surface to the Hash160.  That will guard against unforeseen cryptanalytic breakthroughs, hypothetical quantum computers, ECDSA-cracking unicorns, the arrival of superintelligent space aliens on Earth, etc.  So if I make a cold-storage address for my grandkids’ inheritance, I will keep the public key secret, and sleep 3.1337% more quietly at night.  I am just that paranoid.

N.b. that using a new address for every transaction does not by itself provide good privacy.  Blockchain analysis heuristics can link transactions with high reliability, even if addresses are not reused.  It is only the most basic privacy measure, as well as being the prerequisite for all better privacy measures.  For this reason alone, avoiding address reuse is very important.

---

This must be emphasized at every opportunity.  When you use a Segwit address, you are helping the network by using less of a globally shared resource for your transactions; in BIP 141 terms, your transactions have less “weight”.  Fees are calculated by weight.  Therefore, when you use a Segwit address, you get a huge discount on fees.

---

The aptly-named “bitfools” appears to be trolling with voluminous spew of patent nonsense.  Newbies, don’t believe anything he says.  Just ignore.  It is all 100% incorrect.  Sheer idiocy.

Thanks for the advice.

My report stats currently say, “You have reported 144 posts with 100% accuracy”.  That is counting only since 1 December 2017, when I started to actively engage with the forum.  I am trying to help clean up the trash.

Yes, the mods do an heroic job.  In Meta, I have repeatedly likened their task to “emptying a landfill with a spoon—while the garbage trucks keep rolling in”.  I appreciate their efforts.


The question is, where should the line be drawn?  I generally applaud this forum’s policy of erring to the side of letting people express their opinions freely.  However, forums dissolve in noise when it is not required that opinions be at least moderately intelligent and plausibly well-expressed.

When considering horrible advice, linking to a trojan coin-stealer download is definitely over the line.  But what about when somebody advocates “brainwallets”?  I have seen you and gmaxwell respond to that with devastating efficacy!  Per what you say, the discussion must be had such that newbies can see the argument, and learn why brainwallets are an unequivocally bad idea.  Shilling for BCH?  That’s bad advice, insofar as it misleads newbies to a fraudulent fake Bitcoin; and it is simply offtopic on a Bitcoin forum.  In Meta, I have joined those (unsuccessfully) advocating that BCH shilling should be delete-on-sight.  (Lauda also had a good idea of negative-trusting BCH shills, which I would do if my trust rating carried any weight.)  The babble of “bitfools”?  That’s a tough call.  Bizarre, essentially substance-free nonsense does not belong on a technical discussion forum.  But if it is here, then somebody does need to step up and point out the stupidity—without any attempt to soften and sugar-coat the response with undeserved niceness.


Thanks.  I aim to raise the S/N ratio and not lower it, though sometimes I will flame away on a stupid thread which anyway refuses to die.  I do hope that the educational value of my post here exceeded the problems inherent in replying substantively to a troll, rather than ignoring it or brushing it off with a one-line “you’re an idiot—100% incorrect” reply.

Thanks for the tip.  Well, I suppose that IHBT.  I’ve been working to cultivate the habit of pausing when I see something inexplicably ridiculous, and glancing through post history before I hit the “reply” button.  I will try to do better with that in the future.

Untrue.  All of my computers have only “100% legit” software installed, because all of my computers run 100% open-source.

Not that I give a damn about copyrights for my personal usage.  I simply refuse to touch any software as for which I cannot read and modify the source code.  And, yes:  I am one of the few people who actually uses the source, rather than only navel-gazing and pontificating about it.  In practical use, having the full sources available has saved me from many problems which would otherwise have left me helpless.  (I also scrupulously observe copyrights/licenses for any code I build upon, so as to not cause trouble for other people who use my code.)

“bitfools”, username checks out.  You have no idea what you are talking about.

I don’t have a problem with newbies and non-experts who simply lack knowledge.  Nobody is omnicient.  But I have a big problem with fools who spout off stuff and nonsense self-evidently made up on the spot, and pass that off as “knowledge”.  If you don’t know, then say you don’t know—or shut up.  Each and every conclusion in your post was substantially incorrect.


No, it doesn’t.  Hex strings are only alternative representations of a binary value.  BIP 39 mnemonic phrases are also an encoding of a binary value (although that value is not used directly to create the binary seed).  In all these cases, they represent large integers.


In Bitcoin, private keys are 256 bits.  2²⁵⁶ ≈ 1.16×10⁷⁷; therefore, 256-bit numbers written in decimal require up to 78 digits.  Valid values for a Bitcoin private key include those from 0x1 (decimal 1; 1 digit) to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140.  If I did not make a dumb mistake, in decimal that latter equals 115792089237316195423570985008687907852837564279074904382606316063022768341312.  That number has 78 digits; count them.


How the hell is the block number relevant to this discussion?  No keys or address values are ever generated from the block number.  Moreover, half the digits of a value are half the digits; it makes no difference whether it is the first half or the last half.  To try all combinations of 502xxx requires 1000 guesses, 000–999; to check all combinations from xxx800 also requires 1000 guesses, 000–999.  (And if bruteforcing random values, on average you will only need to try 50% before you hit the right one.)

On the same principle, if you have half the bits of a 256-bit private key, it does not matter whether it be the first half, the last half, or some part in between (just as long as you know the offset).


Say what?  Hexadecimal (base16) values, and also the base58 values in WIF, only encode values which the computer decodes and handles in binary (base2, bits).


No, you cannot bruteforce 10–23 words of a BIP39 passphrase “super quick”.  It does not matter if you know the “algo”.  The “ALGO” is secure even if you know it.  If you know “just 1 or 2” words, then the work required to bruteforce the rest will range from 2¹¹⁰ to 2²⁵³.  There is nothing “super quick” about that!

Now, in the spirit of OP’s original question about knowing half the desired value:

Each word of a BIP 39 seed encodes 11 bits of randomness—except for the last word, which contains the lowest-orer bits of randomness plus a checksum value.  If you know the first 6 words of a 12-word seed, that means you know 66 bits of a 128-bit random value—slightly more than half.  Bruteforcing the rest will require 2⁶² work (128 - 66 = 62).  That can certainly be done by those with powerful compute clusters or through distributed computing; but it is not a task which could be considered “super quick”.

If you know the first 12 words of a 24-word seed, that means you know 12*11 = 132 bits of a 256-bit random value.  Bruteforcing the rest would require 2¹²⁴ work, which is infeasible even with a supercomputer.

I have thus far ignored the checksum bits.  In a 24-word phrase, all 24 words together represent a 264-bit value representing 256 bits of randomness, plus an 8-bit checksum; a 12-word seed represents 128 bits of randomness plus a 4-bit checksum.  By “exploiting” the checksum to discard values which do not match, you effectually remove the checksum; thus you can avoid running the results through 2048-iteration PBKDF2-SHA512, followed by the further hashing and EC maths required to generate addresses to check against.  I know I have not explained this well—I simply note it parenthetically, so as to not forget the checksum.  It’s not really relevant to this discussion.

By the way, this makes no sense whatsoever:  “Most of what ppl see in BTC is hex 'hashed' data, but when you talk key or seed then normally your talking the real deal, most dev's on BTC to prefer to hide this stuff from the user on theory he's too stupid to be trusted with his own data,”  Well, you are too stupid to be trusted with anything.

That’s funny.  UTF-8 is my pet analogy for Segwit; I have been intending to post about this.  UTF-8 is a brilliant, elegant hack which expands chars [:blocks] from 1 to 4 [:million] bytes, while maintaining backward compatibility with old-style 1-byte ASCII.  It has a theoretical upper limit of a 32-bit codespace (with 6 bytes), but we really get a 21-bit codespace.

Sorry, Core:  Segwit is not as awe-inspiring as UTF-8.  UTF-8 is one of my favourite all-time most brilliant hacks ever.  But Segwit deserves to be compared.

IIRC, Pike (or was it Thompson?) sketched the original UTF-8 spec on a restaurant napkin.


bech32 compilation/porting discussion is continued on its thread.  The MSVC compile should mostly but not entirely work, I think.

As for easyseed:  In addition to the POSIX getopt(3) interface and BSD-style <err.h> (also available on Linux), easyseed needs random numbers.  It read(2)s off /dev/urandom.  So it would need a suitable replacement from Microsoft CryptoAPI/CNG.  A quick search reveals CryptGenRandom() or BCryptGenRandom()?  If you use Windows Vista (and others?), just make sure you don’t inadvertently get bits from Dual_EC_DRBG. <g>

I think that this should probably work, mostly.  For its “user interface”, the utility uses POSIX getopt(3) functionality, and also the BSD-style <err.h> (also available on Linux).  I don’t know to deal with that on Windows.  Otherwise, it is just STDC.

I myself can’t test MSVC compilation; for I have no Windows in my house.  Please let me know what results you get.

Should there be indicators of demand, I may try to produce Windows binaries with mingw. 

If you need to replace anything with code from WIN32, I strongly suggest that you #define WIN32_LEAN_AND_MEAN.  I seem to vaguely also remember some define for Unicode, but I don’t remember what it is.  If somebody comes up with Windows/MSVC compat code, I may try to abstract that into a separate file.  I will not clutter main files with #ifdefed Windows code, or Windows “decorations”; I was recently trying to audit a simple cross-platform library where every function is “decorated” with DLLEXPORT, and that junk makes code unreadable.

That paradox hit me faster than the speed of light; and my Quantum FUD® got entangled in the superposition of impossibilities.

---

(@Vigme86, I began writing you a reply earlier; may do later, time permitting.  Your setup sounds decent; good luck with your long-term holding.)

[Edit again:  Raize, that was the post of the thread.  I’d intended to reply before, to simply say:  Well said.]

This blocked a post.  I will try again, and edit if it’s still blocked.

Edit:  This is persistently blocking a particular post.  It is a very long post, which I spent much time writing in a text editor.  It contains a modest snippet of C code in BBcode code tags.  Other than that, I cannot imagine what trigger this is hitting.