> This reminds me, does anyone here know how to get PGP paper keys that use only english words e.g. "brunch pineapple house crow ..."?
maybe BIP39? (afaik it's used for paper keys in bitcoin-adjacent things)
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...
In Sequoia PGP 1.0 Released: The Seedling Is a Saplingbitcoin
bips
Wikitext2013–2026
bitcoin / bips
bips
Bitcoin Improvement Proposals
104Distinct people
124Mentions
0Explicit recommenders
11KGitHub stars
What to know before exploring
What it is
Bitcoin Improvement Proposals
GitHub
Where it is used
- Ledger Wallet (Ledger Live) — Ledger Wallet uses the BIP32, BIP39 and BIP44 standards to manage seeds and derivation paths for generating keys and addresses. Source
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- bcoin-org/bcoin · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:56:20 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year124 dated mentions
Observed mentions: 2013-12-10 19:15:46 UTC to 2026-09-13 15:23:25 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 12 | 1 | 11 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 15 | 0 | 15 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 17 | 0 | 17 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 1 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
People wishing to submit a BIP should first describe their idea to the bitcoindev@googlegroups.com
mailing list to gather feedback on viability and community interest before working on a
formal description. Please open a pull request to this repository only when substantial progress on the draft has been
made, preferably when the draft is nearing completion. Authors do not assign a number to their own proposal.
After a proposal meets the editorial criteria, a BIP Editor will assign a number to it and publish the proposal by
merging the pull request to the repository. Please see BIP 3: Updated BIP Process for the full process.
The BIPs repository serves as a publication medium and archive. Having a BIP published here indicates that the proposal
is in scope and has met other formal criteria for this repository, but does not indicate that it is a good idea, has
community consensus, or that it is about to be adopted. The BIP Editors are expected to be liberal with publishing BIPs
and to try not to be too involved in decision-making on behalf of the community. Beyond the formal criteria, evaluation of
the proposals is left to the audience of the repository. When a proposal is controversial and it cannot be agreed upon
whether it should be published, the conservative option will always be preferred: the proposal will be closed.
Those proposing and opposing changes should consider that ultimately acceptance and adoption rests with the Bitcoin
users (see also: economic majority).
Number
Layer
Title
Owner
Type
Status
1
BIP Purpose and Guidelines
Amir Taaki
Process
Closed
2
BIP process, revised
Luke Dashjr
Process
Closed
3
Updated BIP Process
Murch
Process
Deployed
8
Version bits with lock-in by height
Shaolin Fry, Luke Dashjr
Informational
Complete
9
Version bits with timeout and delay
Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
Informational
Deployed
10
Applications
Multi-Sig Transaction Distribution
Alan Reiner
Informational
Closed
11
Applications
M-of-N Standard Transactions
Gavin Andresen
Specification
Deployed
12
Consensus (soft fork)
OP_EVAL
Gavin Andresen
Specification
Closed
13
Applications
Address Format for pay-to-script-hash
Gavin Andresen
Specification
Deployed
14
Peer Services
Protocol Version and User Agent
Amir Taaki, Patrick Strateman
Specification
Deployed
15
Applications
Aliases
Amir Taaki
Specification
Closed
16
Consensus (soft fork)
Pay to Script Hash
Gavin Andresen
Specification
Deployed
17
Consensus (soft fork)
OP_CHECKHASHVERIFY (CHV)
Luke Dashjr
Specification
Closed
18
Consensus (soft fork)
hashScriptCheck
Luke Dashjr
Specification
Complete
19
Applications
M-of-N Standard Transactions (Low SigOp)
Luke Dashjr
Specification
Closed
20
Applications
URI Scheme
Luke Dashjr
Specification
Closed
21
Applications
URI Scheme
Nils Schneider, Matt Corallo
Specification
Closed
22
API/RPC
getblocktemplate - Fundamentals
Luke Dashjr
Specification
Deployed
23
API/RPC
getblocktemplate - Pooled Mining
Luke Dashjr
Specification
Deployed
30
Consensus (soft fork)
Duplicate transactions
Pieter Wuille
Specification
Deployed
31
Peer Services
Pong message
Mike Hearn
Specification
Deployed
32
Applications
Hierarchical Deterministic Wallets
Pieter Wuille
Informational
Deployed
33
Peer Services
Stratized Nodes
Amir Taaki
Specification
Closed
34
Consensus (soft fork)
Block v2, Height in Coinbase
Gavin Andresen
Specification
Deployed
35
Peer Services
mempool message
Jeff Garzik
Specification
Deployed
36
Peer Services
Custom Services
Stefan Thomas
Specification
Closed
37
Peer Services
Connection Bloom filtering
Mike Hearn, Matt Corallo
Specification
Deployed
38
Applications
Passphrase-protected private key
Mike Caldwell, Aaron Voisine
Specification
Deployed
39
Applications
Mnemonic code for generating deterministic keys
Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe
Specification
Deployed
40
API/RPC
Stratum wire protocol
Marek Palatinus
Standard
BIP number allocated
41
API/RPC
Stratum mining protocol
Marek Palatinus
Standard
BIP number allocated
42
Consensus (soft fork)
A finite monetary supply for Bitcoin
Pieter Wuille
Specification
Deployed
43
Applications
Purpose Field for Deterministic Wallets
Marek Palatinus, Pavol Rusnak
Specification
Deployed
44
Applications
Multi-Account Hierarchy for Deterministic Wallets
Marek Palatinus, Pavol Rusnak
Specification
Deployed
45
Applications
Structure for Deterministic P2SH Multisignature Wallets
Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia
Specification
Complete
46
Applications
Address Scheme for Timelocked Fidelity Bonds
Chris Belcher, Thebora Kompanioni
Specification
Draft
47
Applications
Reusable Payment Codes for Hierarchical Deterministic Wallets
Justus Ranvier
Specification
Deployed
48
Applications
Multi-Script Hierarchy for Multi-Sig Wallets
Fontaine
Specification
Deployed
49
Applications
Derivation scheme for P2WPKH-nested-in-P2SH based accounts
Daniel Weigl
Specification
Deployed
50
March 2013 Chain Fork Post-Mortem
Gavin Andresen
Informational
Deployed
52
Consensus (hard fork)
Durable, Low Energy Bitcoin PoW
Michael Dubrovsky, Bogdan Penkovsky
Specification
Closed
53
Consensus (soft fork)
Disallow 64-byte transactions
Chris Stewart
Specification
Draft
54
Consensus (soft fork)
Consensus Cleanup
Antoine Poinsot, Matt Corallo
Specification
Complete
60
Peer Services
Fixed Length "version" Message (Relay-Transactions Field)
Amir Taaki
Specification
Closed
61
Peer Services
Reject P2P message
Gavin Andresen
Specification
Deployed
62
Consensus (soft fork)
Dealing with malleability
Pieter Wuille
Specification
Closed
63
Applications
Stealth Addresses
Peter Todd
Standard
BIP number allocated
64
Peer Services
getutxo message
Mike Hearn
Specifi
Read the full README on GitHubWhat Hacker News says
15 sourceshttps://www.monperrus.net/martin/perfect-ocr-digital-data
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...
In The Base58 Encoding SchemeIt's also relevant to the topic because some of the issues its discussing relate to how over full inputs are validated.
Do you reduce the 255 mod 24 to decide if the time is acceptable, or do you just reject anything over 23 as unreasonable... or maybe you only reject larger than 99 (because two digits is enough) but from 23 and 99 you reduce mod 24.
In many kinds of programs it isn't too critical exactly how you handle unreasonable inputs. Garbage in Garbage out. In consensus systems, however, any difference in behaviour can be a fatal vulnerability.
Some might find the motivation section of Bitcoin's BIP340 informative: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawi...
Or this earlier publication: https://slowli.github.io/ed25519-quirks/ (which has more explanation for the S value related issues that the parent article m
Read the rest
ostly skips over-- but lacks the breadth and the amazing illustration of the incompatibility train-wreak).
> Base58 isn't suitable for general purpose encoding though as its performance degrades exponentially based on the length of the input.
Only with an absurdly naive implementation.
Base conversion with arbitrary (and even mixed) base can be done in entirely linear time.
Base58 doesn't work that great for a wide collection of uses because the mixed case makes it extremely slow for e.g. spoken use.
More modern Bitcoin addresses use BECH32 (https://github.com/bitcoin/bips/blob/master/bip-0173.mediawi... a base 32-scheme whos characters and permutation were selected via machine optimization against a confusion matrix, in order to minimize the number of bit errors made by human transcription. It incorporates an error correcting scheme that adds 6 extra characters and guarantees detecting up-to 4 substitutions or transpositions (or 5 substituti
Read the rest
ons if they're all hamming-1 errors, such as q vs g, z vs 2, u vs v, etc.).
«Bitcoin does not»
This statement betrays you have not paid attention to the numerous improvements made to the Bitcoin infrastructure over the last 11 years: wallets, nodes, exchanges, payment processors, vaults, blockchain upgrades, basically all the BIPs https://github.com/bitcoin/bips : segwit, P2SH, lightning, M-of-N keys, deterministic wallets, etc. Using Bitcoin in 2020 is nothing at all like it was in 2009.
In Bitcoin is more like ham radio than the early internetBIP39 (https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...) mnemonics are the industry standard for deriving keys. If you use enough words (the standard will not let you use less than 12), then you are completely fine.
In Bitcoin is more like ham radio than the early internetI'm thinking what would be the purpose or added value of a separate "public spec" document (which would require a significant maintenance effort) when you already have [1] a healthy Github (or Gitlab) project governance going on, [2] Bitcoin feature proposal process.
[1] https://github.com/bitcoin/bitcoin/projects
[2] https://github.com/bitcoin/bips
When you upgrade your Bitcoin node software, the act of the upgrading is you casting your Yes vote for the changes introduced in that version. The BIPs etc. can help you understand these, but if you want to be 100% diligent, the only fully authoritative source is the state of (the code sources in) the git repo as referenced by the commit hash in the Bitcoin software you are upgrading to.
In Ask HN: Why isnt there a public spec for Bitcoin core?Base58 has certain issues (lowercase-uppercase ambiguity) which is why we now have https://github.com/bitcoin/bips/blob/master/bip-0173.mediawi...
In Updating the Git protocol for SHA-256This might be true for a service with a basic setup of providing the same address for deposits. If they did it the right way, they would provide a unique address each time. Such a list of addresses is only known to the key holder unless they were to share it.
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...
In JPMorgan Extends Banking Services to Bitcoin ExchangesThe page lists "Coinbase Transaction" in the quantity 7.15968084 BTC.
The coinbase transaction is the first one listed in the block. It has no explicit payer, and can be valued up to/including the sum of:
- the block's aggregate transaction fees
- the block subsidy (6.25 BTC starting with block 630,000 today)
There's some technically detailed information on coinbase transaction/money stock edge cases that have occurred over the years here:
https://bitcoin.stackexchange.com/a/38998
Also see this discussion of a jaw-dropping miscalculation of the block subsidy (even though dated April 1, it's for real):
https://github.com/bitcoin/bips/blob/master/bip-0042.mediawi...
In Bitcoin Halving Just OccuredIt is being worked on:
https://github.com/bitcoin/bips/blob/master/bip-0151.mediawi...
In Erlay: Bandwidth-efficient Bitcoin transaction relay protocolSee also Bech32 which includes error correction and detection:
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawi...
> Why not use an existing character set like RFC3548 or z-base-32? The character set is chosen to minimize ambiguity according to this visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.
In Show HN: Base24 binary-to-text encoding for humansThe fungability/tainted coins/traceability problem is potentially solved with the recent Taproot Schnorr signatures proposals. BIP340, BIP341, BIP342. You guys don't seriously think we would sit around and let the man crush bitcoin because of "tainted coins" do you :]
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawi...
In A 96 Bitcoin ransom payment ends up on BitfinexMemorize it in the form of a BIP-39 mnemonic[1]. 12 words are enough to encode 128 bits of entropy and a 4 bit checksum.
[1] https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...
In DEA seized father’s life savings at airport without alleging any crime occurredIt is another untruthful claim.
The original design document for compact blocks is was published (and last modified) on Dec 25, 2015. https://people.xiph.org/~greg/efficient.block.xfer.txt
The earliest work for Bitcoin Unlimited's "Thin Blocks" was on Jan 10th 2016: https://bitco.in/forum/threads/buip010-passed-xtreme-thinblo...
Both were motivated by an earlier effort by Bitcoin developers Matt Corallo and Pieter Wuille, https://buildingbitcoin.org/bitcoin-dev/log-2013-12-27.html#... (which Pieter had implemented, but was found to not work so well, https://buildingbitcoin.org/bitcoin-dev/log-2013-12-28.html#...).
The fact that in Bitcoin we took the time to fully think through, write a clear and complete specification https://github.com/bitcoin/bips/blob/master/bip-0152.mediawi... , and thoroughly test and review the implementation befo
Read the rest
re deploying it while BU has been occasionally abused by the BU organization and their supporters to dishonestly claim that compact blocks came later (or were somehow derived) from their work.
Users on the sidelines were easily deceived by this marketing because BU rushed their implementation into production while Bitcoin took a more deliberative process.
BU's "thinblocks" implementation was, in fact, severely flawed both due to an implementation vulnerability that resulted in almost every BU node on the network being crashed near simultaniously, and due to a design error introduced because BU's "chief scientist" strongly believed that it was computationally intractable to produce a collision in the first 64-bit of transaction IDs (a sha2 hash), even though one can be computed on a fast desktop computer in seconds.
In fact, Bitcoin Cash developers went so far as to attempt to block the deployment of compact blocks by falsely claiming that it would somehow "disrupt the network": https://www.reddit.com/r/btc/comments/4xkqbk/core_intends_to... (It didn't.)
So the history is that: Bitcoin developers proposed and tested an idea for faster block propagation using filters and found it lacking. Later, it came up again as a possible way to mitigate segwit's bandwidth increase, so I wrote a design to address the known issues and we started working on implementing it. A few weeks later BU developers picked up the old work and started improving it. Within a couple months they had it deployed it in public and announced 'mission accomplished', but their deployment was unspecified and ultimately faulty. As a result of those issues and the superior relay latency of compact blocks thinblocks was replaced in the Bitcoin Cash network with the protocol from Bitcoin.
There is no common protocol feature in BU's xthinblocks that wasn't also in Bitcoin's original work that inspired both efforts. There could have been no influence on compact blocks' design by xthinblocks because it would have been physically impossible for there to be due to causality. That hasn't seemed to stop BU developers and people like you from repeating this lie.
Cheers.