Well, thanks for looking at my source code!  At least at the top of the main .c file.  And yes, all strings with a suffix of “.onion” are automagically detected.  The bech32(1) tool does not know about any specific .onion sites, although I had to pick one for a manpage example.

If you like this particular feature, then you will be pleased to see the proposal I just made on tor-dev:

https://lists.torproject.org/pipermail/tor-dev/2017-December/012743.html

Bottom line up-front:  I ask a change which will likely require SQL database access.  Admin attention requested, please!

I have started a binge of wikignome minor edits to upgrade http links to https, where appropriate.  On the Main_Page, via Template:MainPage_FAQ, there is a link to http://en.wikipedia.org/wiki/Public-key_cryptography (plain http).  In place of that link, the source of Template:MainPage_FAQ says this:


A check of the Mediawiki Manual:Interwiki indicates that changing the target requires either editing the SQL of the wiki’s database, or appropriately using an Interwiki extension if one is installed.  Obviously, this tiny fix is far above my access level.

It is good that once the Interwiki link is fixed, it will automagically fix all links using that format.  After Interwiki links are made https, I will then go around changing hardcoded Wikipedia links to the Interwiki format.

Thanks!

---

Edit:  Other Interwikis also need to be fixed; e.g. in the Main_Page itself, this also outputs a plain http link:


Somebody with appropriate access should upgrade them all to https, please.

@MeshCollider, @Taras:  Based on the quality of requests being made here, I suggest editing Taras’ original post from 2015-04-15T23:29:34Z to add the following note:


With that being on page 45, I myself only saw it by happenstance.  Of course, I also consider that to be no more than common sense.  Who would make a post with just a username?  What’s the point?

Edit:  Based on the profusion of one-post newbies who apparently created a Bitcoin Forum account solely to request Wiki edit privileges, I also suggest indicating that requests will be more likely granted for those with at least a modicum of reputational history.  Not necessarily a forum posting history:  Reference to a well-established blog, open-source contributions, mailing list posts, Reddit user profile, Wikipedia edit history, etc. would serve the same purpose.  If spammers can create a new wiki account, they can create a new forum account, too.

~~~~ Nullius (Talk | contribs)

Add to this:  3. Secure, reliable agreement on a reasonably high-precision network time runs into the very same “General” (hah) problem which mining is intended to solve.  Indeed, off-the-cuff, I can think of some constructions which may perhaps maybe could be used to replace mining—if we had secure, reliable high-precision network time agreement.  (And if I had wings, and if all cows were identical and spherical...)


No one should; but you know, somebody will (and just did).  I think there’s a rule somewhere that if you provide a variable value, somebody will (ab)use it for purposes neither foreseen nor supported by the design.  I will now wait for someone to use the nonce in some way which requires meaning it does not have.

Why the hell does the Bitcoin Development & Technical Forum look like this?


I have a better idea for a thread!  “Lightning Network vs. Genital Herpes”.

Or maybe, “Lightning Network vs. Involuntary Coprophagy”.

Or worst of all, “Lightning Network vs. JPMorgan” (ewww!).

Really, what is this obsession with comparing an excellent new Bitcoin technology with disgusting, useless things which have nothing to do with Bitcoin?  It does not even make sense.

Why are you performing modular arithmetic on wordlists, when computers think in bits?  N.b. that you will break the checksum this way.  BIP 39 stuffs 4–8 checksum bits into the last word; how many, depends on the length of the seed.  I presume you will want means to check that your seed_b is recorded correctly, without access to your seed_a or your original seed (which I will call seed_0).

Also, Electrum does not generate BIP 39 seeds.  You are mixing two different standards.  Off the top of my head, I don’t know whether Electrum uses the same English-language wordlist by default.  But I do know that Electrum’s competing Seed Version System was designed to be fully wordlist-independent, which makes wordlist-arithmetic an even worse idea.

I suggest you XOR two seed-sized values drawn off /dev/urandom, then encode the results into BIP 39 seeds.  You can do all of this except the XOR using dd(1) and easyseed(1), a secure BIP 39 seed generator which I so happen to have published yesterday (forum thread).  easyseed(1) can take a file as input, or read from stdin.  Producing the bitwise XOR of two equally-sized files is a trivial “hello, world” jobs in C, and probably in Python, too.  Also, this could be done in memory without touching disk with a tiny bit of modification to easyseed(1); or, just use a memory disk and be sure to wipe it when you’re done.

Well, that is if you want to do the scheme you said.  As HCP pointed out, SSS is really the right tool for the job here.  Your splitting scheme is secure, on condition that you never XOR the same values with anything else (see “pad reuse”).  But it severely reduces availability.  Using SSS and transforming its output to words through a secure mnemonic scheme would be much safer.  I have been mental-whiteboarding a tool based on SSS, mnemonic phrases, and some other tricks for exactly these kinds of scenarios, though it may be awhile before I actually write it.

---

I am not a cryptographer, experienced or otherwise.  But that sounds fine to me—with the killer caveat that your “key” will need to have as many bits as an independent seed, so why bother?

A better scheme may be to use a secret master seed, seed_0, run it through a KDF (as will be done anyway when your BIP39 seed is turned into a BIP32 HD wallet), and use the KDF to generate two independent seeds:  seed_1 for your real treasure cave, and seed_2 the “decoy”.  BIP39 simply takes a bag of bits as input; so you can still use easyseed(1) to turn your seed_2 “decoy” into a string of words, write it on a yellow sticky note, and “hide” it somewhere that bad guys will be allowed to find it after they begin to torture you (so it’ll be convincing) but before they torture you too much (what is your personal tolerance for being hit with a $5 wrench?).  Meanwhile, keep the words for seed_0 secret—not only that, but keep its existence secret!; and it can be used to recover both other “seeds”.

---

WRONG WRONG WRONG WRONG WRONG.  As another person already told you:

The god of Bitcoin has no mercy.

21000000 is a number sacred unto the god of Bitcoin, and beloved in his eyes.  Never shall there be more than twenty-one million bitcoins.

The god of Bitcoin grants unto you full power over yourself:  No king, no priest, no judge, no senate, and no army can command or countermand your decree over your own bitcoins, as signed with the sacred mark of your private keys.

The god of Bitcoin demands that you take full responsibility for yourself:  For it is a law of Nature and Bitcoin that power and responsibility are as two sides of the same coin.

The god of Bitcoin commands, you shall keep safe your private keys.  An ye lose your private keys, the god of Bitcoin shall curse ye.  An ye let your private keys be stolen, the god of Bitcoin shall bless the thief and curse ye.

The god of Bitcoin demands obedience to the divine Law of Consensus.  The damned who hardfork without consensus are renegades, abjurers of holiness, rapine oath-breakers, frauds, sowers of discord, and traitors, who shall be consigned damnatio memoriae with their chains to eternal poverty within the depths of Tartarus, where all hashes are broken and all bits are made nothing.

For their service in the unending sacred task of Byzantine fault-tolerant transaction ordering, miners are blessed with riches, yet cursed to eternal struggle against each other.  The god of Bitcoin hungers for hashes, and shall devour lightning and worlds to secure the transactional ordering of the blockchain.

For his judges and executioners, the god of Bitcoin appoints full nodes.  Full nodes execute the will of the god of Bitcoin upon the network.  His legions thus shall cast into the alt darkness all who dare violate the communion of Holy Consensus.

We of the Bitcult Faith gather in the sacrament of the Consensus, in worship of the Bitcoin, in homage to the memory of the prophet who was our forerunner, Satoshi Nakamoto.

I was pleased, when I saw this:


Pleased, yes; yet I was also confused, for this high praise came from someone who 44 minutes earlier in the same thread had said, “nullius has the intention to commit sin and fraud”.  I had taken that seemingly grave accusation with a grain of salt, for reason that that its source lacked credibility:  Dorkie had previously accused theymos of being part of an “inside job” hacking forum accounts—replete with a Bible quote, to warn theymos about Judgment Day.

So why now should I have bestowed on me such an ode of hagiography as I wished to frame and hang on my wall?


Scrolling back through the same thread, I suddenly felt as if a vision and a calling were decrypted before my eyes:


Lo!  Unwittingly as if possessed, I had acted in loyal service of the new money god that is Bitcoin!  ’Twas for that, the Divine Bitcoin lavished me with this compliment as a reward:


A reward—and a guiding light, showing me to my true calling.  I now see it all so clearly, yea:

I am called to devote myself to the sacraments of Bitcoin Divine.  Bitcoin of holy name, whose prophet was Satoshi, whose coming answered the prayers of the cypherpunks.  Bitcoin, who keeps the world ledger of all souls’ wealth, has commanded me that my “sole objective is to facilitate the mass adoption of Bitcoin.”

Bitcoin has called, and with joy do I answer.

---

• This is a self-moderated thread.
• As the exalted Leader of this cult, I shall pass judgment on posts:
  
  • I will delete any post which offends the god of Bitcoin.
  • I will delete any post which offends me personally.
  • I will offend any post which I deem stupid, illiterate, lacking in sufficient substance to justify its forum existence, and/or lacking in sufficient substance to justify its author’s mortal existence.
• The sole exception to said rules:  At my discretion, a post which fails to meet Cult standards may be spared by me—solely for the purpose that I may shower it with derision, and humiliate its author.
• The standards of the Bitcult shall be unapologetically elitist—aristocratic, in the original sense of the term.  Just as is Bitcoin.

I shall take liberties in editing my own posts, including this one, for the exclusive purpose of polishing and perfecting the scripture of the Cult.  I also may lock and unlock this topic as I please.  Most importantly, as a cult leader, I have the prerogative of taking advantage of my adoring followers financially (and the attractive female followers in other ways).

All hail the god of Bitcoin.

You’re right.  It is a problem.  (I will make a little edit to my original post.)

I will keep that clause in my own code; as copyright holder, I could re-license it in response to such adverse events as you describe.  But for large-scale collaborative projects such as Core itself, such a solution is obviously impracticable.

Projects with centrally controlled development typically have a trademark, restricted on terms similar to what I describe.  For but one of many examples, Firefox.  You can hardfork it all you want, but not use the Firefox name and logo.  Whence my little idea.

In a situation where persons with horrid ulterior motives attempt hostile takeover of a project from a myriad of angles—repeatedly, for years—it seems self-defeating to avail to such persons the technological improvements of which they have demonstrated themselves incapable.  It is a political problem—by the etymological definition of that word, a people problem; and people problems cannot be solved solely by technical solutions.  I look to use every tool at my disposal, on strictly pragmatic grounds.  Perhaps may there be another way, on similar lines?

I have released an initial version of the easyseed(1) utility for secure generation of BIP 39 mnemonic phrases, BIP 39 seeds, and BIP 32 master extended private keys (“xprv”).  As any worthwhile software, it comes replete with a manpage, q.v.  It generates mnemonic phrases in these languages and writing systems:

• Chinese (Simplified) (汉语)
• Chinese (Traditional) (漢語)
• English [default]
• French (Français)
• Italian (Italiano)
• Japanese (日本語)
• Korean (한국어)
• Spanish (Español)

My original motivation for writing this was that I needed a lightweight, reliable BIP 39 mnemonic phrase generator with easily auditable sources and minimal dependencies for use on a stripped-down airgap machine.  The source code is concise, easy to read, and lovingly commented; it can be readily understood by anybody with a basic knowledge of the C programming language.  Its only external dependencies are cc(1), make(1), and libcrypto.

Now that it’s written, easyseed(1) is also the first necessary component for my campaign to urge that users stop using saved webpages to generate their Bitcoin magic bits.  What kind of an airgap machine has a web browser installed, anyway?  But most importantly, as a rule of thumb, Javascript code cannot reliably acquire proper entropy for generating random numbers.  This is a persistent general problem, and specifically subject to extended fretting by the author[1] of the most popular BIP39 webpage.

easyseed(1) reads bits straight off /dev/urandom, or from user-provided keymat.  Gathering and processing of entropy is properly the kernel’s job.  My userland utility will let the kernel do its job.  Since it’s written in C, easyseed(1) can reliably obtain kernel-provided randomness on every Unix/Linux platform in about two lines of code (open(2), read(2), plus error checks)—rather than cooking up some tortuous “random” scheme which may or may not perhaps probably work sort-of.

This is a beta-quality initial release.  It is not yet feature-complete:  In particular, I have code partly written to add support for all languages which have wordlists in the Bitcoin BIP repository (currently Chinese (Simplified and Traditional), French, Italian, Japanese, Korean, and Spanish, in addition to the current English). — Done!  This is now approaching release candidate status, almost ready for Version 1.

Licensing includes a Bitcoin Consensus Clause, to prevent use by scamcoin pretenders.

I am here opening a Bitcoin Forum thread for discussion of this utility; over time, I will edit and update this post as appropriate.

---

1. Though that is not nearly in the same league as boneheaded absurdity from ignorant developers who confuse multiple distinct meanings of the word “entropy”.  pointbiz: “Perhaps more entropy can be gathered using techniques used on Panopticlick”.  #facepalm  cantonbecker: “I like this idea”.  pointbiz: “I used all the easy techniques from Panopticlick to gather entropy. [...] I added up the low and high entropy bits and my personal results are 34.3 to 42.8 bits of entropy.”  Oh dear heavens, are you using this to generate keymat for Bitcoin!?  Some people should be enjoined with a permanent restraining order forbidding that they ever approach within one hundred metres of crypto-related code.

I have released an initial version of the bech32(1) utility for encoding and decoding of BIP 173 Bech32 strings and Bitcoin “Bravo Charlie Addresses” (“bc1”).  As any worthwhile software, it comes replete with a manpage (text), q.v.

As part of its initial feature set, bech32(1) has special handling for RFC 7686 .onion special-use domain names; it detects such a name, and transcodes the RFC 4648 Base32 to and from Bech32 with an HRP of “onion”.  For Bitcoin “Bravo Charlie” addresses, bech32(1) takes and gives the witness version and the hexadecimal-coded octets of the witness program.  Otherwise, for the most part, it encodes and decodes hexadecimal data with user-provided HRPs.  I intend to add special interpretation of “pgp1” with a concept I call “PGP Descriptors”; but I need to spec that out first.

Some usage examples from the manpage:


Licensing includes a Bitcoin Consensus Clause, to prevent use by scamcoin pretenders.

This is an alpha-quality initial release.  The code is still a bit messy; it needs test vectors, which seem insufficiently specified; features and the finer details of behaviour may be a bit in flux.  However, the basic user interface should be considered stable.  I am here opening a Bitcoin Forum thread for discussion of this utility; over time, I will edit and update this post as appropriate.

Today, I released the bech32(1) and easyseed(1) utilities; and I have been preparing to release more little Bitcoin gadgets.

When it came to the question of licensing, my gut instinct was to instead disclaim copyright and release the code to the public domain.  (The public domain is not a license, “CC0” confusion to the contrary notwithstanding.)  However, several real-world problems stopped me from so doing.  One is the persistent ills caused by imposters who fork Bitcoin code whilst stealing the trust engendered by the Bitcoin name.

Therefore, I released the code under an open-source license with some special clauses.  The clause hereto pertinent is what I call the Bitcoin Consensus Clause, which requires that derivative works with functionality related to digital money (so-called “cryptocurrency”) must either fully adhere to consensus rules fully compatible with Bitcoin Core, or use a name which does not contain the word “Bitcoin”.  I bashed this out in a few minutes, and didn’t yet spend any time tightening up the legalese; but the wording is clear on its face.

I do wish that Core itself had added such a clause to their license.  Why don’t they?  Has this ever been discussed?  If so, I have not seen it.  [Edited:  DannyHamilton pointed out the obvious problem.  Duh.]

Obviously, my intent in this particular clause is not to cause problems for honest altcoins.  By “honest”, I mean an altcoin which at least has the common decency to make its own name, genesis block, network and block magic numbers, etc.—otherwise stated, an altcoin which stands or falls on its own merits and does not pretend to be Bitcoin.

My general desire is that people should copy and use my code freely in both commercial and noncommercial projects.  But I find revolting the idea that my code could be abused by or for a scamcoin which pretends to be Bitcoin.  Now, as long as there exists an idiotic copyright/licensing régime, it is illegal for my code to abused in such a way.  I don’t mind being pragmatic about that.

Wow.  What an exquisitely disgusting combination of threats and insults.  After that, I don’t care how you were allegedly scammed; if I were administrator of this forum, I would now permaban you and never give you any information, ever.

You also insult the intelligence of the reader.  I’ve never even heard of a jurisdiction where service of original process could be effectuated via e-mail.  Moreover, you are conflating the idea of a civil lawsuit filed and served by you, with some nonsensical insinuation about criminal matters (“withholding information on a fugitive”).  Do you think we’re stupid?  What kind of scam are you trying to pull?

For those who did not check post history, I also note that you already posted the same garbage 53 minutes, 12 seconds before:


...as to which you already received adequate reply:


Now if you don’t like the “boys club [sic]” as you call it, I suggest that you put on your big-man pants and go have teatime, or whatever you imagine big men do.

There is a new twist to our Cloudflare problem:


That’s the message which will be seen when security-conscious users try to visit the Bitcoin Forum whilst using a new anti-MITM Firefox add-on by “cypherpunks”.  (It also works on Tor Browser—as you can see.)  A whitelist function is available.  I will henceforth be surfing with that; based on what he’s said, theymos may appreciate the suggestion to do likewise.

I noticed that theymos’ well-said complaint about Cloudflare is quoted in the sidebar of the extension’s homepage.  Hmmm.



See also Tor Bug #18361, Tor Browser Bug #24351 (reported by me), Debian Bug #831835, Firefox Focus (mobile) Issue #1743, Mozilla Bug #1426618, and likely others.  People are beginning to wake up and realize exactly this:

So-called “Bitcoin Cash” is a rip-off which changes just enough to cause trouble, while keeping just enough the same so as to cause more trouble.  You should not look to it for guidance; if you’re making an altcoin, change the port number (among many other things) as I told you in one of the many other threads you’ve started.  You don’t want to be a rip-off, right?

P.S., myapple, please keep your closely related questions on the same subject matter within one topic, rather than spreading many redundant topics with minor variations of the same questions.

---

I think that’s hilarious, in the sense that people who run that junk deserve any mischief it may cause them.  So, not only will it make users lose money due to the identical address format:  It will also clobber your Bitcoin installation?  I am asking.  I wouldn’t know.

[citation needed]

That’s a mighty big claim you assert.  Excluding buggy software with bad PRNGs, keys specially calculated to be “found” by LBC or the like, and other non-random situations, address collision is as good as impossible.  I’d bet all my money on it—actually, I more or less am!  As a practical matter, you are free to take my money if you can find one of the approximately 2^96 colliding keys for one of my long-term storage addresses.

As for the rest of this thread:  Worry about quantum computers is ridiculous when quantum computers do not exist.  (Excluding toy research implementations—which don’t actually do anything useful, and may never.)  If you want to put coins in deep storage for the next few decades, then don’t reveal the public key—just in case.  If you are one of the few developers who deals with long-term planning, get up to speed on PQ crypto.  Otherwise, this is a total non-issue for present-day usage of Bitcoin.

I am gratified to see the community interest in Bravo Charlie Addresses!  I’ll reply soon; meanwhile, for fun, here is the embryonic form of an idea which I call PGP Descriptors:


This is off-the-cuff; and I do NOT want to unleash it into the wild unless/until I think it over, and at least draw up a proposed specification.  Those who may be curious about the extra octets I included should see references 0, 1, 2.

Now, let’s sauté some onions with the rich flavour of Bech32’s error-correcting code:


Bech32 is awesome.

There is no such thing as “the mempool”.  Thus, you have tried to build a lofty tower on a wholly nonexistent foundation.

Each node has a mempool, consisting of unconfirmed transactions it so happens to have heard of through Bitcoin’s gossip protocol.  Each node’s mempool is different from the others.

Correcting this single error in thinking about Bitcoin can correct many other errors, too.

Spinning around what achow101 correctly explained:  We already have a “coordinated ordered transaction mempool”, as you call it.  Our “coordinated ordered transaction mempool” is called the blockchain.  Transactions are “coordinated” and “ordered” by the blockchain, through the very same “confirmation” process as you attempt to shortcut.  What you are really trying to do is to invent a replacement for the whole proof-of-work mining system; and obviously, you have not done that.

P.S., it is also impossible to descramble eggs.

Expanding on what you say:  The network itself has no notion of addresses; addresses are only a human interface feature.  Transactions involving Segwit addresses starting with a “3” are P2WPKH-nested-in-P2SH (Pay To Witness Public Key Hash nested in Pay To Script Hash), paid to the hash of a script consisting of OP_0 followed by the push of a witness keyhash (0x0014<20-byte hash>).  Bech32 addresses permit use of native Segwit tranactions, but are not backward-compatible.  An address starting with a “3” may or may not be a Segwit address; there is no way to tell, just by looking at it; it’s simply an ordinary P2SH address, which is why old clients can send money to it.

(I know that you know this; I’m filling in for others.  Good call in your reply.)

---

Segwit is an excellent technology which activated in Bitcoin on 2017-08-24 with Block #481824.  Bitcoin already has Segwit.  The misleadingly misnamed “Segwit2X” is not Segwit and not Bitcoin.

---

The link you give is not to the Segwit mailing list.  It’s to the mailing list of a hostile takeover attempt which has nothing to do with Segwit, and nothing to do with Bitcoin.

Bitcoin no longer has a block size limit.  Segwit replaces the block size limit with a block weight limit, set to 4000000 bytes:

I have no idea.  I’m a C programmer; and I prefer to write code in vi(1).  Not “Vim”.  nvi.

The best language for writing Bitcoin-related code is C the language at which you yourself most excel.  Well, as long as it’s not COBOL, MUMPS, or BF, I suppose.


There is a common misconception that miners provide the security of the network.  This is patently false.  Miners have exactly one job:  To provide Byzantine fault-tolerant ordering of transactions, thus preventing double-spends.  It is a valuable and resource-intensive job; and that is why they get paid for it.  But it is still only one function in a machine with many moving parts.

This ACM Queue article provides an excellent overview of how Bitcoin fits together against the backdrop of decades of academic research.  As its centre, it explains how Satoshi Nakamoto repurposed Adam Back’s HashCash to create the first-ever practical implementation of a Byzantine fault-tolerant decentralized database with excellent Sybil resistance.  That is the purpose of mining, and its only purpose.

Validation security is provided by full nodes.  Each individual full node provides validation security for its owner; and all full nodes collectively enforce the consensus rule validation security of the entire network.  Thus here as everywhere else, Bitcoin aligns the individual’s selfish interest with the common good:  People who want the highest security will run a full node to secure themselves, and thus help secure everybody else, also.

In the scenario you describe, I do expect that hashing and signature validation would catch the errors; and the block containing corrupted transactions would be discarded by full nodes as if it had never existed.  A full node does not blindly follow “the longest chain”, as you may have heard:  Rather, a full node follows the independently validated and fully valid chain with the highest total proof-of-work.

This also applies to malicious mining of deliberately corrupted transactions, attempted thefts, ridiculously huge blocks, etc.  Sometimes you may see nonsensical FUD claiming that miners could seize money by planting theft transactions in blocks, e.g. by ignoring Segwit validation rules; no, they would get exactly the same result as if they filled blocks with the output of /dev/random.


I have not been following development of those lately, so I can’t say.

If you are interested in smart contracts, you may appreciate a peek at current R&D which may potentially someday become the future of Bitcoin smart contracts:  Simplicity (PDF).  Powerfully expressive smart contracts written with in a formally verifiable DSL, running on a formally verified VM, would have none of the exploding clown car disasters inevitably resulting from the stupidity of bolting a Turing-complete VM onto a blockchain.


Tools depend on what job you need done; and I don’t really know any good tutorials off the top of my head.  But here are some educational links:

• Most important link, Bitcoin’s equivalent of the Internet RFCs: https://github.com/bitcoin/bips (well, that and the Core source code!)
• https://en.bitcoin.it/wiki/Category:Technical (unfortunately, many articles are out of date with respect to new technologies such as Segwit)
• https://bitcoin.org/en/bitcoin-for-developers
• The archives of this forum, the Bitcoin Forum.  Some of the leading Bitcoin devs used to make frequent, extensive posts before the S/N ratio plummeted a few years ago.  Also, of course, Satoshi was here before he disappeared.  (To be clear, this is the original Bitcoin Forum previously hosted on bitcoin.org; it replaced a Sourceforge forum.)

HTH.