There are a number of ways to achieve consensus, rawtxapp is right in general that many decentralized parties need to agree. For Taproot in particular, it uses BIP 8 (see https://github.com/bitcoin/bips/blob/master/bip-0008.mediawi... and https://github.com/bitcoin/bips/blob/master/bip-0343.mediawi... and more generally https://bitcoinmagazine.com/technical/bip-8-bip-9-or-modern-...) with LockinOnTimeout=true. The effect of this is that miners cannot block the upgrade so long as the (eventual) majority of nodes wishes to have the upgrade, they can only hurry things along and mostly protect the minority of older clients who have yet to upgrade.
In Taproot, Bitcoin’s long-anticipated upgrade, has activatedbitcoin
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:02:05 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
17 sourcesI'll second looking into layer 2 projects.
Most of the new blockchains constantly being spun up are little more than schemes to make the founders rich. Even if the stacks are technically cleaner and nicer to work with, it's really hard to imagine any new blockchain bringing anything significant enough to the table to overcome network effects of established leaders. Specifically be wary of coins like Solana, Cardano, and maybe even Ethereum, which Gary Gensler of the SEC has indicated are probably all unregistered securities and he looks to be gearing up to come after them.
I'm in the bitcoin only, simple, rock solid foundation with complexity built in higher layers camp, so I'll mention a couple of interesting things going on.
The taproot softfork was recently approved by the network and will go live on mainnet next month. Read up here, h
Read the rest
ttps://blog.keys.casa/what-is-taproot-bitcoin-upgrade/.
The lightning network is starting to get some real momentum after years of development. People are using it in unexpected ways, like building an e2e encrypted chat network (https://sphinx.chat/) that piggybacks on the network, or the LNURL-auth protocol (https://xn--57h.bigsun.xyz/lnurl-auth.html) that allows websites to provide persistent user accounts that are authenticated with a user's lightning wallet and require no other personal information. There's recently been some proposals (e.g. https://github.com/JohnLaw2/btc-iids/blob/main/iids14.pdf) to do some magic to stuff a truly massive amount of scaling within the limited bitcoin blocksize.
Protocol changes needed for trustless drivechains/sidechains seems to be gaining traction, https://github.com/bitcoin/bips/blob/master/bip-0300.mediawi.... The Rootstock sidechain will potentially bring the ethereum virtual machine to bitcoin as a sidechain.
I know Ethereum also has some interesting layer 2 work, but I'm not as familiar with what's happening since I don't personally buy into the fat, complex base layer approach, the much more centralized nature of the network and development, nor the planned transition to proof of stake.
I wouldn't necessarily agree that Bitcoin can't scale the number of raw users with something like LN. In fact, LN allows Bitcoin to reach a _wider array_ of users that may be priced out of doing routine transactions on the base chain. Excited to continue to see how the situation in El Salvador develops, as we now have our patient zero in the form of an entire country!
It is the case however that either scaling ceiling or costs prevent everyone from possibly _creating_ a root UTXO eventually. In this direction I'm excited about concepts like multi-party channels that allow users to conjointly share a UTXO and perform off-chain transactions using it. Another very powerful upgrade on the horizon for Bitcoin are the various flavors of covenants like BIP-119, that'll allow us to do things like open 100k Lightning channels in a single on chain
Read the rest
transaction, in an irrevocable manner.
LSATs are interesting for start ups, as they allow for a lot of new experimentation w.r.t business models and pricing. Most say SaaS start ups typically allow for a free trial, then force users directly onto a subscription payment. Combined with the open nature of Bitcoin (anyone around the world can use it), LSATs and LN allows developers and entrepreneurs to potentially capture some of the user base that drops off after the free trial by advertising an in-between tier: stream the payment as you go.
Services like bitclouds.sh capture this spirit, as you just need to top off your account (zero log in, zero sign up, just sats) and you gain access to a VPS you can access. Sure you don't want to do anything very sensitivity in a instance like this, but it's perfect for running CI tests, building containers, etc.
The natural progression of LSAT powered bitclouds.sh-like services is a sort of programmatically driven distributed Function-as-a-Service network, wherein agents of the network are able to programmatically gain access to various computational resource or services all without being locked into any particular platform or having to be worried that a data leak will expose all their private information. So stuff like robots renting VPS space (payments streamed by the minute over LN) to be able to transcode some captured video to submit to a mechanical turk-like job listing.
[1]: https://www.bitclouds.sh/
[2]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawi...
I can't quite follow what you're thinking.
The bitcoin transaction format has numerous points of intentional forward compatibility: Fields, flags, bits, etc. which intentionally have no effect at this time but which could be further restricted in the future in order to create functionality. Examples include future transaction version numbers and future script version numbers.
Use of these forward compatibility features is "non-standard" which means that unmodified software will not relay, mine, or display-while-unconfirmed transactions which use them. But if they happen to show up inside blocks, they'll be accepted.
This protects these fields for future use. Otherwise, some software would start randomly setting them (e.g. due to programming mistakes or confusion) and then these systems would catch fire when later the fields were given a
Read the rest
defined meaning.
This article is about output with version 1 instead of version 0. Currently v1 is defined to have no effect. At block 709632 (in November roughly) that will change and v1 will have a meaning defined by BIP-341 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawi...).
No, presumably I mean 95% of the hashrate which is the only thing that is measurable on-chain.
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawi...
https://github.com/bitcoin/bips/blob/master/bip-0091.mediawi...
In Ethereum London Mainnet AnnouncementI don't think you understand software like you think you do. Those protocol rules do exist, and yes cryptography is involved, obviously, but those rules exist because the miners all agree on it, see: BIP2: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawi...
I.e. These rules CHANGE, and since they change(and have changed in the past) if you can convince a majority, you can change the rules to be whatever you want.
Also see: https://en.bitcoin.it/wiki/Economic_majority
Which is exactly what I said. If I have 51% of mining I can make BTC do whatever I want, but that doesn't mean the majority(or any) of the exchanges will accept it, which is basically what the above is saying.
Also see: https://en.bitcoin.it/wiki/Bitcoin_is_not_ruled_by_miners
Again, what they are saying is what I've said, they just put flowery language around it
Read the rest
saying, see, miners can't do EVEYRTHING, which isn't technically true, but practically true. Miners can technically do whatever the hell they want, assuming they have the majority, but that doesn't mean exchanges like Coinbase will accept it and exchange the BTC for USD.
so what I said above is generally and technically true, see my other comment in this thread as well, where I said it would be a giant mess and likely ruin BTC forever if someone ever did execute a 51% attack. So there is little incentive(financial or otherwise) to do so.
The closest real-life example we have(that I'm aware of) is the BTC cash stuff, where it hard-forked and became it's own crypto currency because they couldn't get a majority to agree, but enough agreed to fork themselves.
Bitcoin incorporated Compact Blocks which similar improves average case behavior.
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawi...
Things like thinblocks or compact blocks only help on average. Bitcoin must be robust for worst case.
In An analysis of Bitcoin's throughput bottlenecksAre you looking for technical papers on how they work or practical blog posts on what you can do with them?
For both Bitcoin and Etherium the original white papers do not paint a full picture of the state of each cryptocurrency. Here are a few links I recently read on both BTC and ETH:
Bitcoin Wiki: https://en.bitcoin.it/wiki/Main_Page
Bitcoin BIPs: https://github.com/bitcoin/bips
Etherium Website: https://ethereum.org/ (it has a lot of information spread all over it)
ETH2 Beacon Chain Blog Post: https://ethos.dev/beacon-chain/
There's a lot more literature that you can find via Google but it's spread out all over the place.
In Ask HN: What are the resources for curated insights on Bitcoin, Ethereum etc.?Crypto wallets may use BIP39 protocol, it might be close to a 'standard'?
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...
Edit: 2048 English wordlist is here https://github.com/bitcoin/bips/blob/master/bip-0039/english...
In What3Words – The AlgorithmBIP-39, uses 2048 words, and can all be distinguished from each other using the first four characters of each word.
This is used to encode raw binary entropy, but adapting it to arbitrary amounts of data is straightforward. For padding I would suggest either pre-encoding length at the start or using classic block cipher padding (https://en.wikipedia.org/wiki/Padding_(cryptography) )
See for BIP-39, wordlists under a folder https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...
In Representing SHA-256 Hashes as Avatars> Just ask that bitcoin and other switch to PoS! It will not be immediate, so the current investments in hardware can be repaid, and there will be no value lost.
Miners almost certainly won't see it that way. "Oh so now you say that I can recoup my capital investment until 12/31/2024? Great, I will happily sign blocks that mark a transition to proof-of-stake." Miners would fork the coin at best. Or, rather, this new proof-of-stake coin would be considered the 'fork'.
Serious design changes should be proposed via the process. For bitcoin, that's BIP [1]. This is just wishful thinking. Someone who proposes a 'ban' and not a design change is not genuinely motivated to supporting a decentralized currency.
Why transition bitcoin at all? Just endorse PoS coins and if they're truly superior then they will take on more value and people w
Read the rest
ill naturally transition. Metcalfe's law is difficult to overcome. However, the value should be apparent in an overall decrease of the network's CAPEX+OPEX.
[1] https://github.com/bitcoin/bips/blob/master/README.mediawiki
This is basically a mechanism that would allow for a honeytrap on steroids. https://blog.finjan.com/honeytokens-used-to-track-cybercrimi...
> that would require keeping track of bogus submissions
You don't have to keep track of the submissions because you can generate them with a reversible algorithm. Basically use a word list method https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi... but have the list be entirely people's names (or generated from a corpus of known accounts and something like https://github.com/minimaxir/textgenrnn to make them harder to spot)
> generating new data for each company where you create an account.
yes https://arxiv.org/abs/2006.15794
Basically treating the data from various email honeypots as a "Numbers station" but instead of using it to prime encryption keys, you use it as a form of steganograp
Read the rest
hy. To do this entirely anonymously, the next step would be to publish on a public blockchain or anonymous service so that the owner's device (that generated the emails originally) can uploaded a signed statement that proves they were the phone pwned and who the offending app was.
A similar idea seems baked into a couple of crypto initiatives https://coincentral.com/sentinel-protocol/ but fundamentally we're talking about an anonymous reputation system modeled after how swarms operate to gossip risk.
It would be necessarily stochastic in nature because you'd be depending on the 3rd parties to send emails a bit at a time, but if you get a deluge of phones all reporting the same app, you can assume fairly confidently that app has been compromised. Punishment (Brand reputation, sanctions by app store) for being compromised would encourage better security.
This could (and would need to be) operated at the hardware level and orchestrated by the OS, and OS provider. This is the kind of thing apple and google could do as part of their privacy initiatives around "differential privacy" https://venturebeat.com/2019/12/21/ai-has-a-privacy-problem-...
What, you think that deep learning chip on your phone is there to make cute avatars?
Further interesting reading related to bitcoin and general cryptography-
Length extension attack: https://en.m.wikipedia.org/wiki/Length_extension_attack
Fast Merkel trees: https://github.com/bitcoin/bips/blob/master/bip-0098.mediawi...
In What is the difference between a second preimage attack and a collision attack?> The community killed scripting because it was antithetical to the thing that makes money in BTC: trust. The constant flow of n00bs coming in who got their transactions reversed by OP codes and said "BUT I THOUGHT BITCOIN TRANSACTIONS WERE IRREVERSIBLE!!?!?!!?!?!1111" was eroding trust in the ecosystem.
I never heard of all of this having happened. To my knowledge Bitcoin's scripting language was not trimmed, it was in fact extended over the years by various BIPs [1].
What's your source for these statements?
[1] https://github.com/bitcoin/bips
In Smart contracts on BitcoinShowing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.