HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
bitcoin
bips
Wikitext2013–2026
bitcoin / bips

bips

Bitcoin Improvement Proposals

Finance & Commerce
Explore on GitHubRead Hacker News discussions
104Distinct people
124Mentions
0Explicit recommenders
11KGitHub stars
REPOSITORY AT A GLANCE

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

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:23:53 PM 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.

0510152013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 15 mentions; 0 submissions, 15 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 17 mentions; 0 submissions, 17 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 13 mentions; 0 submissions, 13 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments. Incomplete calendar period.2026*

* 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
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC303
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC1019
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC808
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC909
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC12111
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC1019
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC707
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC15015
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC17017
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC13013
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC606
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC716
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC312
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC413

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 GitHub

What Hacker News says

12 sources
nullz·Dec 12, 2017
There was an unintentional fork on August 15, 2010, when "[an] attacker exploited [an] integer overflow bug that permitted an attacker to create several billion bitcoins". [source][0] There was an unintentional fork on March 12, 2013 caused by previously disallowed number of tx inputs (?) as resolved by [BIP50][1]. [0]: https://blog.blockchain.com/2016/02/26/a-brief-history-of-bi... [1]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi...
In Who’s Afraid of Bitcoin? The Futures Traders Going Short
rothbardrand·Oct 24, 2017
Bitcoin has layers. One of the layers people don't understand is the layer called "core". The creators of bitcoin were cypherpunks and so they had a decade before bitcoin existed where people worked out how such a system would work. Those cypherpunks became core. While people think of bitcoin as the software, or the network or the white paper, what it really is, is a collection of engineers (you have to trust the engineers to trust the software and network and ultimately money) that is very diverse, and a genuine meritocracy. Since bitcoin attracted a lot of libertarians and wanna-be-I-think-I-am-libertarians its relatively easy to say "core is the new evil overlords! a monopoly!" when the reality is that core is a large number of people who don't agree on a lot of stuff and have developed a process of reaching consensus. So, unfortuna
Read the rest
tely, some uneducated non-engineer felon like Roger Ver can spread a lot of claims about core and those get believed despite core people explaining patiently in engineering terms why the claims are false (eg: big blocks are not free scaling, segwit is more efficient, etc.) Non-engineers simply cannot understand the technology arguments and so they are manipulatable via social engineering, which in this case is literally legions of paid shills (http://birds.bitcoin.com is the attackers site where shills get paid.) That's the layer that's under attack now- because the powers that be want to control bitcoin and they can't beat the software, they can't beat the hash power, but they think they can maybe beat the people. (And in Ver's case, he shills BCH to keep its price up while unloading it to get more BTC.) Actually that twitter account is one that I've seen many times before, and I would not consider him someone who understand how bitcoin works. He seems to be an engineer who has taken a superficial look and then fallen sway to propaganda. This is the thing about bitcoin, there are layers. Here's some of the layers: 1. "Bitcoin is internet money" 2. A block chain is a chain of database entries 3. I understand what Proof of work is 4. I understand how economic incentives work in bitcoin 5. I understand why PoW will always be better than PoS 6. I understand why ethereum can never work (ultimately) 7. Now I really understand the economic incentives 8. Now I understand bitcoin Of course this is more than a little tongue in cheek. The white paper can be found here: https://bitcoin.org/en/bitcoin-paper But a lot of the standards are found here (in various levels of adoption)... this bit is really relevant for wallets: https://github.com/bitcoin/bips#readme Read the white paper at least once before holding any bitcoin. And then re-read it at least 5 times one the course of 2 years. It has layers and you will come to understand them over time. Reading Mastering Bitcoin I understand is really useful too. (I got thrown into the deep end of btcd so I didn't have that luxury)
In Bitcoin Pioneer Says New Coin to Work on Multiple Blockchains
nikcub·Sep 18, 2017
> Is there a good overview of the types of wallets, their architecture and evolution? A wallet is a userland abstraction where it groups together all of your keypairs. With each keypair (ECDSA) you have a public and private key. The address is derived from a hash and encoding of the public key. The private key is used to sign a script that unlocks the transaction outputs you have access to. For this reason, your balance is also a userland abstraction. A balance is the sum of all the outputs you have the ability to unlock by signing the input. Whats important to understand about transactions is that you need to spend the entire input. If you have 10 coin sitting in an output and want to send 7 to someone, you need to structure the transaction so that the 3 change goes back to you as well The way fees work is that the miner picks up any dif
Read the rest
ference between the outputs and the input, for ex. 10 input => output 1 = 7btc to address1 (recipient) => output 2 = 2.9btc to address2 (change) => diff 0.1 btc transaction fee You now have a balance of 0 in your input address, and you're left with 2.9btc in your change address which will become the input on your next transaction There is no reason why the change address cannot be the same as the input, but it means a loss of privacy since you can then see the 2.9 btc was change, thus output1 was the recipient, and you link the future transaction back to yourself as well. If you then want to send 11 coin to someone, you can combine other inputs: 2.9btc input => output 1 = 11btc to address3 (recipient) 10btc input => output 2 = 1.89btc to address4 (change) => diff 0.1 btc transaction fee This is how wallet identification works as described in the OP - you can assume that any inputs shared in a transaction are from the same owner since they were signed together. If you parse the blockchain and continue grouping common inputs like that you end up with a graph of wallets. Sometimes it only requires a single transaction to group together entire clusters - especially if you're using wallet software that selects inputs to use in sequence, doesn't create change correctly, or if you sweep all your smaller and smaller inputs into an aggregate address What the original wallets did, and what OP explains, is they would pre-generate the next 100 keypairs and add them to the end of the list, and with each transaction that requires change it would move the pointer for next change address up one All of your addresses start as either receive addresses, or as change addresses, and end up becoming your balance addresses until they are spent To backup these wallets you had to backup every key pair, which is why most modern wallets use deterministic keys usually derived from a mneumonic. HD wallets use a master key pair, where the private key is usually derived from a mneumonic. That key pair is then used to generate the key chains that are used as receive and change addresses. It means you only need to backup your master keypair or your master mnemonic and can then generate and check all the key chains The new wallet format is defined in bip32 [0] while the mnemonic to generate seeds is defined in bip39[1] - which you can test using a browser client app[2] (don't store coin using these - generate them securely) Most wallets now support these deterministic wallets, including bitcoin core The three main wallet types are full node, thin node (SPV) or web wallet You can run a full node with Bitcoin Core[3] or Bcoin[4] (a Javascript implementation) - both support pruning the blockchain at a specified block height The most popular SPV clients are Electrum[5] cross-platform, breadwallet for ios/android[6]. SPV uses block headers and peer queries (sometimes using bloom filters for privacy) to query your unspent transaction outputs and to verify transactions (there are variations of the architecture). The bcoin project also allows you to run an SPV client in the browser or via node (i'm really starting to like this project - they were the first to implement p2p authentication and encryption which is specified in bip150/bip151) Electrum supports Trezor and hardware wallets, multisig wallets, 2FA wallets and have their own mnumonic and deterministic wallet format (but it also just involves saving a seed for the master key) Web wallets store your wallet (usually) encrypted on their server and then unpack and decrypt in your browser client, then making HTTP API queries to verify transactions, get your unspents, broadcast transactions etc. The most popular are Blockchain.info[7] (disclaimer: I worked for them) and GreenAddress[8] - you can use blockchain.info via a tor hidden service at blockchainbdgpzk.onion Good ways of getting started if you're more interested in the tech is Electrum (web wallets tend to obfusacte a lot of what is going on to make them easy to use), a full node with Bitcoin Core or running bcoin - and running them on testnet so you can build and broadcast your own transactions without fear of losing funds (the scripting language has also evolved a lot). The other Javascript lib you can use to create transactions is bitcoinjs-lib[9] - there are libs available for deterministic wallets and some good transaction/script abstractions. [0] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi... [1] https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi... [2] https://iancoleman.github.io/bip39/ [3] https://bitcoincore.org/ [4] https://github.com/bcoin-org/bcoin [5] https://electrum.org/ [6] https://breadwallet.com/ [7] https://blockchain.info/wallet/#/home [8] https://greenaddress.it/en/ [9] https://github.com/bitcoinjs/bitcoinjs-lib
In How the Bitcoins Were Stolen from Mt. Gox [video]

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.