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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:17:07 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.

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

10 sources
verroq·Dec 13, 2014
Haha, I had the same idea. The since (valid) transactions are passed freely to all nodes in the Bitcoin network, one can just use the network as a signed messaging platform. You don't need to query blockchain.info, all you need is a Bitcoin client that listens for incoming transactions. I've been writing an implementation on and off for a while now. The general idea is as follows: The botnet client connects to "n" Bitcoin nodes. If the same transaction is relayed by ceil(n/2) nodes, then we say that transaction is "confirmed" and examines the transaction to see if it's sent from botmaster's address (in fact we don't even have to use the botmaster's address, with BIP-0032 (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...), we can use related public keys) You don't even have to use transactions ("tx" messages), you can use th
Read the rest
e block messages if you are willing to tolerate an (on average) 10 minute delay, this would drastically reduce the network traffic sent/received by the botnet client. But these guys forced my hand, so I suppose I'll have to release what I have so far. The current botcoin client (c++11 with boost::asio) connects to the network, and gets transactions. Data extraction from transactions is unfinished. The current problem I'm working on is making sure that people cannot easily scan the Blockchain to look for c&c transactions. This can easily be done by encrypting the messages with a client specific key. However, I would like to have perfect forward secrecy, that is, suppose a sample client was obtained by researchers, past c&c messages should not be able to be decrypted (otherwise the blockchain contains a log of all of your C&C messages). [link redacted]
In A Novel Approach For Computer Worm Control Using Decentralized Data Structures
marcell·Jul 31, 2014
While I am not too familiar with how Stellar/Ripple work, I assume they are sending an un-encrypted version of your Stellar private key, or perhaps the equivalent of a bitcoin master private key [1]. I say un-encrypted based on their claim that the code + username can be used to gain access; typically sites will encrypt the recovery code with your password. Based on this, I conjecture that they decided in favor of usability in the usability-security tradeoff. [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...
In Stellar
sickpig·Jul 27, 2014
Ok now I got what you meant. thanks for the explanation. Having said that your consideration about "on line nature" applies also to my mastercard in almost all the shops I usually buy stuff be it on line or off line. Without me providing the OTP and the payment processor verifying it I can't buy anything. A little bit OT but worthy IMHO. There are quite a few SPV (1) client implementations that remove the need to have all the blockchain stored locally. The things are moving even further in these field with the implementation of the payment protocol (2) (1) http://bitcoin.stackexchange.com/questions/4649/what-is-an-s... (2) https://github.com/bitcoin/bips/blob/master/bip-0070.mediawi...
In Why Killing Cash is Key to MasterCard’s Competitive Strategy
contingencies·Jun 17, 2014
Last night, at the city-that-shall-not-be-named Bitcoin meetup, we specifically discussed this sort of BIP, and I raised the opinion which was initially posted in response to Gavin's support for BIP70, which is that the last thing Bitcoin needs is more complexity. Fundamentally, Bitcoin is trying to be a settlement network and an asset and a UI and a platform for developing future financial services and now a half-baked business-oriented transaction layer on top of the settlement network. Unix philosophy[1] says this is insane, and as someone involved with one of the largest exchanges, I'm inclined to agree. Most of this stuff boils down to using Bitcoin to try to solve things it's not well-suited to solving, eg. instant payment. I mean .. adding X.509 & SSL[2] to Bitcoin clients to 'simplify' payments? Really? Do you guys have any idea w
Read the rest
hat that does to an implementation's risk model? [1] http://en.wikipedia.org/wiki/Unix_philosophy [2] https://github.com/bitcoin/bips/blob/master/bip-0070.mediawi...
In Show HN: Instant confirmation via Bitcoin payment protocol
wfn·May 24, 2014
This is BIP-level stuff only, but fwiw BIP 0011 (https://github.com/bitcoin/bips/blob/master/bip-0011.mediawi...) is kind of interesting. It would thence (uh, can i use that word this way?) be possible to e.g. implement three-party escrow using 2-of-3 signatures (second bullet point under Motivation, etc.) Two signatures would be enough to conduct a fund transfer from buyer to seller. If either buyer or seller defects (or there's some kind of a problem), there'll be <=1 signature present. The third mediating/escrow party would then choose whether to place their own signature or not (thereby validating or nullifying the transaction, accordingly.) iirc there's also some BIP-level stuff (or an idea to implement it using bitcoin Script, anyway) to have things like NashX[1] work within bitcoin. Basically a Nash equilibrium based transaction sc
Read the rest
heme with no human 'escrow' party required - everything is formalized. If either the buyer or the seller fails (i.e.: if any of the two report 'failure'), all funds are burnt (e.g. sent to some provably bogus bitcoin address, whatnot.) Both parties have to chime in so that the risk is distributed accordingly/appropriately. There are nuances and gotchas here to be had, of course. [1]: http://nashx.com/HowItWorks
In Chancecoin: a decentralized casino built on top of Bitcoin
ewillbefull·Jan 4, 2014
> and that simultaneously raised the number of transactions allowed in a block so that more could be processed Source? I don't believe the hard limit in blocks has ever been changed; bitcoin's devs are currently struggling to convince people to let them do it. The soft limit will NOT cause hard forks. The only reason that fork happened was an unknown limit that existed with one database in one version and which didn't exist with an improved database in another version. It was a bug. Here's an evaluation of the chainfork: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi...
In Zynga Links Up With Bitpay For a Bitcoin Payment Test in Web Games

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.