BIP361: Post Quantum Migration and Legacy Signature Sunset#1895
Conversation
| | 3 years after BIP-360 implementation. | ||
| |- | ||
| | B | ||
| | At a predetermined block height, nodes reject transactions that rely on ECDSA/Schnorr keys. |
There was a problem hiding this comment.
I'd be interested an expanded rationale for the approach of rejecting transactions that rely on ECDSA/Schnorr keys vs freezing quantum vulnerable outputs.
Bitcoin's current signatures (ECDSA/Schnorr) will be a tantalizing target: any UTXO that has ever exposed its public key on-chain (roughly 25 % of all bitcoin) could be stolen by a cryptographically relevant quantum computer.
The approach you propose would definitely prevent more thief long term. What is the delta between this and freezing all quantum vulnerable outputs in terms of vulnerable bitcoins?
Is the mechanism to determine if a transaction is reject, if OP_CHECKSIG appears in the script?
If someone did a Schnorr CHECKSIG and a PQ signature CHECKSIG_ML, would that be rejected? Probably right, that would be the more simple check.
There was a problem hiding this comment.
Added more details to say reject any of the checksig opcodes. I suppose the logic could be "reject all checksig opcodes unless there is also a checksig_ml opcode" if we felt like someone might footgun their funds.
There was a problem hiding this comment.
That's a good approach since you can still have Schnorr OP_CHECKSIG tapscripts in tapleafs without breaking OP_CHECKSIG_ML tapscripts.
This would break OP_CAT based covenants since they use OP_CHECKSIG in a quantum safe way to verify the txhash of the transaction on the stack. This suggests that if we want OP_CAT, we probably also want OP_PUSH_TXHASH so that people don't use OP_CHECKSIG for covenants.
Not necessarily. Operating quantum computers costs a lot. For example no one will run computations if it costs 100M to break 50M worth UTXO. Of course with technological and algorithmic improvements the cost of breaking a key will go down. But as costs go down each quantum-computer owner is faced with dillema, they:
Due to game-theory we can expect quantum-computer-owners to go for option 1. They won't go for option 2, because they don't know if other players will also go for option 2. It introduces race-to-the-bottom dynamics between competing players in which cost-to-break-UTXO approaches value-of-the-UTXO. Does it seem similar to something? Yeah, bitcoin mining in which average-cost-to-mine-one-bitcoin approaches value-of-one-bitcoin. Quantum UTXO hacking can be framed as another parallel process of proof-of-work mining, but with the quantum-computers instead of SHA hashing chips. And as such I don't think it is something to deem negative. |
If the threat were real (super-positional whether it is or not), that is the incentive. Forced movement is a non-starter, ones desire to quantum-proof their key does not impart a responsibility on anyone else. |
|
No one can be forced to move their coins to quantum safe signature schemes. On the flip side, no one can be forced to accept coins from quantum vulnerable signature schemes. |
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Thanks, this looks great for a first showing. There are a few minor editorial details I noticed, and one aspect regarding BIP 360 (which I see that Ethan also pointed out).
If you receive abandoned coins that you suspect were stolen by QC, you can burn them. No one is forced to honor them. You're not afraid people will be forced to accept coins, but that they will happily accept them. This undermines your previous argument. This is not a technical BIP, it's a vanity one trying to impose a view on the market.
A functional QC would effectively be a winner-take-all coins, candidates in the running to have it already have access to a material number of coins (Google, Microsoft have countless passwords emails 2FA to custodial platforms and password managers containing seeds, backdoored OS's, softkeyboards... etc). A QC could also sign for any software distribution as it could bitcoin keys, enabling untold new backdoors into systems. There's no change to Bitcoin that can protect Bitcoin from a QC threat (hoax) because Bitcoin is not the only link in the chain. |
Quantum sweeping does not generate consensus, it only funds quantum. Quantum computing isn't bad in itself, it will advance material science far beyond what can be done with classical supercomputers. But it's a mess for everyone if it ends up crashing crypto in the process, so it's better to close as much of the surface of attack as possible to make sure we don't end up with wicked incentives. |
There is no way to know, those transactions are indistinguishable from legit ones, the attacker is literally signing with your private key.
A functional CRQC will be expensive ($1B-$10B) and only break a finite number of keys per year, it's not infinitely powerful which means that their use will be driven by incentives. The Bitcoin community must decide if they want to be the exit liquidity of quantum computing companies. This BIP proposes a way to reduce the surface of attack as much as possible.
A lot of links in the chain have started upgrading. |
|
I read about your BIP on CoinDesk. It's mind-blowing and thank you for leading the way. Post-quantum migration should be pro-active rather than reactive. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
|
Please keep the comments focused on technical review -- thank you. |
There was a problem hiding this comment.
'''Phase A''': Disallows sending of any funds to quantum-vulnerable locking scripts…
'''Phase B''': Renders ECDSA/Schnorr spends invalid, preventing all spending of funds in quantum-vulnerable UTXOs.
This BIP is hostile for the Bitcoin community and the entire Bitcoin network because it is saying that you can't spend in the future non-quantum compatible funds.
I think @jlopp also need a disclamer, see: https://qb.tc/team
Simultaneously, this BIP is hostile for quantum capable adversaries because it is saying that you can't steal bitcoin with your fancy computer.
When I wrote my initial essay 4 months ago I was not collaborating with anyone. This BIP is a continuation of those same ideas I came up with independently. |
NOTE: As a miner starting in November of 2013 who has invested more into the ecosystem than most... When I invested in the QBTC team (Great team all Bitcoiners by the way) it was because we agreed with Lopp essay and we reached out to collaborate. Q-day is coming sir and Lopp proposal is the best I have seen and should be supported. |
|
Openly saying that we can't spend in the future non-quantum compatible funds, is hostile for the Bitcoin community and the Bitcoin network! If I have Bitcoin from 2011, I will not able to spend it in the future or receive Bitcoin to my address? |
|
I've attempted to remove the ad hominem and replies to it. @1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw, there's no need to repeat the same argument. Let's keep discussion here focused on technical review of the BIP itself. |
|
@jonatack he proposed nothing technical in nature. He just want us to not able to spend our Bitcoins in the future. I find not a single technical proposal in this BIP draft. |
False. In the event that quantum computers become a reasonable threat, I want people not to be able to spend their coins in a manner that is indistinguishable from quantum theft. As such, I want spending restricted so that it requires a quantum safe cryptographic proof accompanying it. |
|
You don't have to restrict any spending! That is just absurd. You should instead just propose hybrid addresses that are quantum resistant and also backwards compatible with ECDSA. I also don't understand what is this rush. You seem like someone who very much would like to enforce on us the "spending restriction". Quantum computers would need ≥ 1 million physical qubits and this must be logical qubits (error-corrected). We are very-very far from any quantum computer that would pose a threat to Bitcoin. Estimates suggest this kind of quantum computers would exist after the year of 2040. So don't need to rush and block transactions now just because you're afraid of imaginary quantum computers. |
This BIP has no intention of addressing the separate issue of what post quantum cryptographic scheme to implement.
This BIP has no intention of addressing the separate issue of when to implement a post quantum cryptographic scheme. This BIP only addresses the migration and incentives issues that arrive AFTER those questions have been resolved. In short, it sounds like you have not comprehended the actual timeline and preconditions of activating this BIP. |
|
You're free to propose a BIP to compete with BIP-360 and then we'd evaluate how it would affect the need for this BIP. |
|
I strongly consider it. |
|
@jlopp Will send it now to the mailing list before opening a new PR. |
jlopp
force-pushed
the
quantum_migration
branch
from
e706bf7 to
de293ff
Compare
|
Made the requested changes though I'm not clear on how to resolve the current failing diff check. |
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Thanks for the update. I think I see what the issue is and pushed the fix.
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Given that proposals can be further developed in Draft stage and this is predominantly a proposed outline how to further react to the quantum thread, would you perceive your document to be ready for publication?
Yes, I think it's pretty well baked for now. The 2 outstanding issues are going to need a lot of time for R & D.
|
@SHAKE256: The Bitcoin Improvement Proposals repository is a publication medium to put proposals forth to the Bitcoin community. This document is a recommendation by Lopp et al to the community. My assessment is that this document is nearing sufficient maturity to be published in Draft status to the repository. Neither number assignment nor publication should be construed as endorsement by the BIP Editors. Publication does not convey anything about the community sentiment or likelihood of ecosystem adoption either. It simply means that it’s on-topic; and its publication serves to facilitate community consideration. It’s not clear to me what conflict of interest you perceive. I’m not, nor have I ever been, paid by Jameson, I do not financially benefit from adoption of this proposal. I do not have any stake in any pro- or anti-quantum computing ventures. In fact, I don’t think that the quantum threat is going to substantiate at all in the next few decades. However, it still seems pertinent that these ideas be discussed as others obviously are already concerned about quantum threats. If you have any arguments why you think this is not on-topic or not ready, or would like to raise specific issues concerning the content of the proposal that have been insufficiently addressed, those might be relevant regarding its readiness for publication—just thinking that it shouldn’t be adopted is not. Your style reminds me of two other accounts that posted here before: https://github.com/1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw and https://github.com/21btc12VnSa25vj8pWh2wvBScs16Hx. Would you happen to be the same person? |
jonatack
left a comment
jonatack
left a comment
There was a problem hiding this comment.
A quick look. I didn't yet review carefully the Deployment section (and code), nor consider edge/failure cases in general.
|
@SHAKE256 I understand some of your points, e.g., that this in some ways seems more a blog post than a technical BIP (and the "fail to upgrade and you will certainly lose access to your funds" aspect seems potentially controversial). However, please keep your comments focused here on technical review. I've "hidden" some of them, but they are still viewable. It isn't helpful to repeat them. Rather, it would add more value to omit further personal and/or blanket criticism in favor of specific comments to improve here. |
I think that aspect could be clearer in this draft (at least, to me), but apart from clarity I believe it's not a blocker in terms of BIPs process as specified in BIP 3. |
There was a problem hiding this comment.
Since this proposal is not implementable before the PQ-signature scheme is proposed that this document relies on, it was turned into an Informational BIP outlining a proposed roadmap to tackle the Quantum thread. Similarly, the Deployment parameters seem a bit out of place, as the prerequisites for Deployment have not been met. The remaining content of the document seems sufficiently mature to be published in Draft status.
Note that advancing a proposal to "Complete" requires that all planned work is concluded, so this proposal would not be able to advance to Complete or start its Deployment until the PQ-signature scheme substantiates. Once the prerequisites are met and the proposal becomes implementable, I would recommend that either this proposal be updated to add Deployment parameters and turned into a Specification BIP, or another BIP be added that specifies the Deployment parameters for this proposal.
At this time however, the presence Deployment parameters doesn’t make sense to me.
Jameson Lopp (Casa CTO) authored BIP-361 (PR #1895), which ties legacy-signature sunset rules to supply inflation guardrails. Active since July 2025. First Bitcoin Core contributor to frame quantum migration as both a cryptographic AND monetary policy question. Source: bitcoin/bips#1895
jlopp
force-pushed
the
quantum_migration
branch
from
caebc9e to
ac52ed0
Compare
|
Fair enough; removed deployment section since it isn't actionable. |
conduition
left a comment
conduition
left a comment
There was a problem hiding this comment.
In spirit, I like this, but i suspect many will not. The paragraphs explaining motivation are mostly valid, but the technical solution proposed is not fully thought-out or researched yet.
Namely:
- No flexibility. To activate restrictive soft-forks based solely on block height or real-world time discards many variables, and commits us all to a path we may want to change later.
- No rescue paths. The proposal confiscates coins and doesn't propose any concrete way to rescue them, even when such methods are actively researched and known to exist 1 2. Any such rescue paths implemented after this proposal would require a hard fork.
- No technical details. Terms are not defined and exact conditions for what is and is not allowed aren't spec'd out. 90% of the BIP's word-count is the "motivation", "benefits", and "rationale" sections. The technical spec is barren. It's hard to give a 👍 or 👎 without knowing what you're ACKing.
As a first draft it's not a bad start, but there's a long way to go. Structurally I think it'd be smarter to separate this proposal into two independent BIPs:
- To restrict sending to legacy address formats.
- To restrict spending from "EC-reliant" addresses.
Both ideas have merit but lumping them together does disservice to both because they need not activate simultaneously.
Footnotes
| | Permitted sends are from legacy scripts to PQ scripts. | ||
| | Everyone holding or accepting BTC. | ||
| | 160,000 blocks (~3 years) after BIP-361 activation. |
There was a problem hiding this comment.
By enforcing a rule like this in consensus, we would permanently disable sending to anything but P2MR. In the contingency that CRQCs never materialize, it'd be nice to be able to return to P2TR, and this rule would prevent that. We'd have to create an entirely new address format to duplicate P2TR.
I think there's an argument to be made that sending to legacy addresses should eventually become non-standard in mempool policy, but to enforce it in consensus seems too heavy-handed and inflexible to me. It accommodates only the most severe perspective: that CRQCs are inevitable and imminent. Personally, I agree with that perspective, but not everyone does.
There was a problem hiding this comment.
Last I checked, P2MR still uses ECDSA and doesn't support any PQ signature schemes.
I don't see much point in a standardness rule given how easy it is to pay miners out of band to prioritize nonstandard transactions these days.
There was a problem hiding this comment.
Last I checked, P2MR still uses ECDSA and doesn't support any PQ signature schemes.
P2MR is a hash-based PQ-safe address format, it does not specify how coins are locked/unlocked in script. When/if it is activated, it will be alongside another BIP (currently being drafted) which will enable verifying sigs for at least one PQ cryptosystem in consensus.
I don't see much point in a standardness rule given how easy it is to pay miners out of band to prioritize nonstandard transactions these days.
I believe you wrote the motivation yourself in this BIP:
By disallowing new spends to quantum vulnerable script types, we minimize the attack surface with each new UTXO. Upgrades to Bitcoin have historically taken many years; this will hasten and speed up the adoption of new quantum resistant script types.
There is no reason why this rule would need to be enforced by consensus, since it is not immediately security-critical if bypassed. Anyone who willfully bypasses it is doing so only at minor risk to herself. There's no need for the network to coddle people willing to pay mining pools to risk losing money.
This is the same reasoning why sending to non-standard segwit versions, or using OP_SUCCESS codes, etc, is considered non-standard in policy. There's no good reason to do it, and even if you do you'd only be losing your own money. But we don't want to disable it in consensus because we might need those tools someday.
| | 160,000 blocks (~3 years) after BIP-361 activation. | ||
| |- | ||
| | B | ||
| | At a predetermined block height, nodes reject transactions that rely on ECDSA/Schnorr keys. |
There was a problem hiding this comment.
What does "rely on" mean? What about hybrid addresses which blend PQC and ECC?
Also, if this rule goes into consensus unqualified with no rescue protocol to back it up, this would amount to mass confiscation and rescuing those coins would require a hard-fork. I don't think you'll ever get consensus on this.
There was a problem hiding this comment.
I thought about this for a while over the past year and don't think it makes much sense to go too far down the rabbit hole of complex script evaluation. Seems cleaner to just halt verification if an ECC opcode is seen.
Thanks to MAST, wallet devs should be able to construct a variety of spend paths and not have to have a single spend path that requires multiple signature schemes.
There was a problem hiding this comment.
Seems cleaner to just halt verification if an ECC opcode is seen.
That would rule out rescue protocols, confiscates hybrid ECC+PQC scripts, and doesn't cover taproot key-spending.
My personal expectation for how this would work is this: When the verifier encounters a BIP340 or ECDSA signature that they must verify, they do so, but then they also enter a follow-up verification step which checks whatever extra rescue protocol condition, e.g. validating the opening of a commit/reveal protocol, or the proof of a ZK-STARK, pulling the necessary metadata from a new transaction or block field. Fail if the associated rescue proof is not found, or is invalid.
| | 2 years after Phase A activation. | ||
| |- | ||
| | C | ||
| | Users with frozen quantum vulnerable funds and a HD wallet seed phrase can construct a quantum safe proof to recover funds. |
There was a problem hiding this comment.
This is the single most critical piece of any confiscatory Q-day-freezing proposal. This BIP is incomplete without it IMO.
Rather than writing out a deprecation timeline that depends on TBD cryptography, maybe it'd be better to research that TBD cryptography first and then write a proposal based on what you can confirm to be feasible? I'd be happy to help with this.
There was a problem hiding this comment.
Agreed, this is where R&D is needed and it greatly increases likelihood of more people finding the proposal to be acceptable. Draft BIPs aren't set in stone, so I expect 361 to continue to evolve much like 360 did.
|
|
||
| 2. Allow throttled theft of coins, which leads to RBF battles and ultimately miners subsidizing their revenue from quantum recovered coins. | ||
|
|
||
| 3. Allow no one to steal vulnerable coins. |
There was a problem hiding this comment.
You forgot the 4th option: Restrict legacy spending conditions to rule out quantum theft but still permit authentic spending.
There was a problem hiding this comment.
Doesn't that fall under number 3? Prevent theft by only permitting authentic spends.
|
|
||
| '''Minimizes loss of access to funds ''' | ||
|
|
||
| Submitting a zero knowledge proof of possession of a BIP-39 seed phrase corresponding to a public key hash or script hash would provide a trustless means for legacy outputs to be spent in a quantum resistant manner, even after the sunset. |
There was a problem hiding this comment.
I really want to dispell the myth of this folklore technique: that we can prove knowledge of a BIP39 seed that derives a pubkey in order to spend coins. That would be absurdly difficult to scale.
To prove derivation from BIP39 seed all the way to receiving pubkey, you'd have to execute PBKDF2 in an arithmetic circuit. That alone would probably take hours or days to prove with current technology, and then you'd need to also run at least 6 instances of HMAC-SHA512 and a point multiplication inside the circuit on top of that. The resulting proof size will be measured in megabytes and who knows how long it'd take to prove/verify.
Much more efficient is to prove knowledge of BIP32 xpriv that derives a given xpriv, like @Roasbeef built recently, and let the verifier recompute the rest. This gives a ZK proof which takes only a few seconds to generate, a few milliseconds to verify, and will be much more compact (a few hundred KB). It also can be reused across multiple UTXOs in a wallet (or even across BIP44 accounts), whereas the folklore method requires a separate ZK proof for each distinct receiving address. Furthermore, a BIP32 proof applies to more wallet types, like LND, SLIP39, or electrum, or multisig wallets, while the folklore technique only works for single-signer BIP39 wallets.
There was a problem hiding this comment.
Great; I'm not a cryptographer - anything that achieves the similar goal is fine by me.
There was a problem hiding this comment.
@conduition would you like to open a PR to update that sentence?
| | Users who failed to migrate funds before Phase B. | ||
| | TBD pending research, demand, and consensus. | ||
| |} | ||
|
|
There was a problem hiding this comment.
The spec section is really short. Everything else is justification. More details are needed.
There was a problem hiding this comment.
Right, it's far from a spec, just an initial draft of the direction we're headed.
|
Apologies for reviewing a merged PR. I'm not sure where else I should have put these comments |
This comment was marked as low quality.
This comment was marked as low quality.
|
@conduition: Given that this repository has no issues, your only alternative would be to write to the mailing list or to open a PR to change this BIP. In so far, this is a good spot to leave review comments. @DimiH2025 and others: Technical review is welcome, but please stay focused on that. |
|
@jlopp I think it would be good to address the open feedback, e.g. #1895 (comment), #1895 (comment), and the feedback above by @conduition. (Update: thanks!) |
This comment was marked as low quality.
This comment was marked as low quality.
ghost
mentioned this pull request
* Update bip-0116.mediawiki * bip54: clarify sigops counting, borrow bip16 language * bip-0054: update forward compat section with Bitcoin Core v30 The BIP 54 sigops limit was made a standardness rules in Bitcoin Core 30.0. * bip-0054: correct link typo in test vectors README * BIP53: Clarify wording around implementation complexity Co-authored-by: Chris Stewart <[email protected]> * BIP53: Use different notation for txids and tx-bytes * BIP-390: allow musig() under rawtr() * Add BIP433 Pay to Anchor (P2A) * bip-373: Fix GLOBAL_XPUB key name and clean up compressed vs x-only note (bitcoin#2007) * bip-373: Fix GLOBAL_XPUB key name and clean up compressed vs x-only note * add requires * Revert "BIP3: add guidance on originality, quality, LLMs" This reverts commit d083ce5. * bip3: Broaden reference implementation formats Based on Luke Dashjr’s b46e819 * bip3: Clarify editor assignment of BIP numbers Adopted from: https://github.com/bitcoin/bips/pull/2037/commits/a399d0791d173510badd3cbf954be547c3d347e4k Co-authored-by: [email protected] * bip3: Avoid implying BIP editors must reply to every ML post Co-authored-by: Luke Dashjr <[email protected]> * bip3: Clarify that draft needs to be discussed on ML * bip-0003: Move Type header responsibility to the author(s) * bip-0003: Changes from BIP 2: Make it match actual spec * bip3: Fix capitalization and drop footnote * bip3: Avoid onus * bip3: Add and backfill Changelog section The Version header is omitted at this time, as it is not permitted under BIP 2. * bip3: Require technical soundness Co-authored-by: [email protected] * bip3: Do not waste community’s time Co-authored-by: [email protected] * bip-325: document signet minimum difficulty This was implicit in the genesis block's nbits value, but better to be clearer. * Update gentestvectors.go * BIP-322: fix proof-of-funds inputs wording * BIP93: terminology, typo, and phrasing fixups (bitcoin#2052) * Change master seed to secret in most places, ''t'' to ''k'' and other term fixes * Replace deleted linebreak, delete vestigal oxford commas * errors->random errors, fix newlines, vector5: secret seed->codex32 secret reduced the heading level of checksum and error correction to make the table of contents easier to parse. Moved Master seed Encoding to be below Unshared Secret. * BIP93: change codex32 characters to bech32 characters * Fix hrp length off by 1 bug. Refactor validity condition to read easier. * BIP-337: fix incorrect reference in Input Data Outpoint row (bitcoin#2053) * BIP-337: fix incorrect reference in Input Data Outpoint row * Fix typo in BIP 337 * BIP-310: fix version-rolling.min-bit-count parameter spec * CI: commit README.mediawiki delta from script to git (bitcoin#2063) Use a hardcoded delta rather than requiring the delta to never change, so that it can be changed deliberately when desired without breaking CI. Also avoids the need to checkout the previous commit, so no longer changes the repository state. * BIP-327: correct DeterministicSign pubnonce and key length (bitcoin#2071) Co-authored-by: lisenokdonbassenok <[email protected]> * process: Activate BIP3, close BIP2 * process: Update README to match BIP3 * process: Clarify handling of controversial BIPs It is preferable to close PRs over having them stuck in controversy limbo indefinitely. * process: Proposed ↦ Complete Amend CI script to new statuses and update existing status field values in table and BIPs. ``` sed -z -i 's/Status: Proposed/Status: Complete/' bip-0*.md sed -z -i 's/Status: Proposed/Status: Complete/' bip-0*.mediawiki sed -i 's/| Proposed/| Complete/' README.mediawiki ``` * process: Final/Active ↦ Deployed ``` sed -z -i 's/Status: Active/Status: Deployed/' bip-0*.md sed -z -i 's/Status: Active/Status: Deployed/' bip-0*.mediawiki sed -z -i 's/Status: Final/Status: Deployed/' bip-0*.md sed -z -i 's/Status: Final/Status: Deployed/' bip-0*.mediawiki sed -i 's/| Active/| Deployed/' README.mediawiki sed -i 's/| Final/| Deployed/' README.mediawiki ``` * process: Deferred/Obsolete/Rejected/Replaced/Withdrawn ↦ Closed ``` sed -z -i 's/Status: Deferred/Status: Closed/' bip-0*.md sed -z -i 's/Status: Deferred/Status: Closed/' bip-0*.mediawiki sed -z -i 's/Status: Obsolete/Status: Closed/' bip-0*.md sed -z -i 's/Status: Obsolete/Status: Closed/' bip-0*.mediawiki sed -z -i 's/Status: Rejected/Status: Closed/' bip-0*.md sed -z -i 's/Status: Rejected/Status: Closed/' bip-0*.mediawiki sed -z -i 's/Status: Replaced/Status: Closed/' bip-0*.md sed -z -i 's/Status: Replaced/Status: Closed/' bip-0*.mediawiki sed -z -i 's/Status: Withdrawn/Status: Closed/' bip-0*.md sed -z -i 's/Status: Withdrawn/Status: Closed/' bip-0*.mediawiki ``` ``` sed -i 's/| Deferred/| Closed/' README.mediawiki sed -i 's/| Obsolete/| Closed/' README.mediawiki sed -i 's/| Rejected/| Closed/' README.mediawiki sed -i 's/| Replaced/| Closed/' README.mediawiki sed -i 's/| Withdrawn/| Closed/' README.mediawiki ``` * process: Superseded-By ↦ Proposed-Replacement sed -z -i 's/Superseded-By: /Proposed-Replacement: /' bip-0*.md sed -z -i 's/Superseded-By: /Proposed-Replacement: /' bip-0*.mediawiki * process: Standards Track ↦ Specification ``` sed -z -i 's/Type: Standards Track/Type: Specification/' bip-0*.md sed -z -i 's/Type: Standards Track/Type: Specification/' bip-0*.mediawiki ``` After the scripted changes, the changes to BIP-40, BIP-41, and BIP-63 were undone, because it breaks CI. These three BIPs only exist conceptually and their proposal documents are missing which causes changes to them ot break the CI. I defer the changes to these BIPs to a separate pull request to get CI to pass. * BIP135: Move discussion to correct header * process: Post-History ↦ Discussion Also line up with additional items in the lines below. ``` sed -i -z 's/ Post-History: / Discussion: /' bip-0*.md sed -i -z 's/ Post-History: / Discussion: /' bip-0*.mediawiki ``` * process: Remove Comments-URI and -Summary ``` sed -i '0,/Comments-Summary/{/Comments-Summary/d}' bip-0*md sed -i '0,/Comments-Summary/{/Comments-Summary/d}' bip-0*mediawiki sed -i '0,/Comments-URI/{/Comments-URI/d}' bip-0*md sed -i '0,/Comments-URI/{/Comments-URI/d}' bip-0*mediawiki ``` Then reset the BIPs with non-empty comment wikis: - bip-0037.mediawiki - bip-0038.mediawiki - bip-0039.mediawiki - bip-0042.mediawiki - bip-0044.mediawiki - bip-0047.mediawiki - bip-0049.mediawiki - bip-0060.mediawiki - bip-0061.mediawiki - bip-0074.mediawiki - bip-0075.mediawiki - bip-0077.md - bip-0084.mediawiki - bip-0090.mediawiki - bip-0118.mediawiki - bip-0125.mediawiki - bip-0150.mediawiki - bip-0151.mediawiki - bip-0152.mediawiki - bip-0171.mediawiki - bip-0172.mediawiki - bip-0173.mediawiki - bip-0174.mediawiki - bip-0176.mediawiki - bip-0178.mediawiki - bip-0199.mediawiki - bip-0322.mediawiki - bip-0340.mediawiki - bip-0341.mediawiki * process: Author ↦ Authors ``` sed -z -i 's/Author: /Authors: /' bip-0*.md sed -z -i 's/Author: /Authors: /' bip-0*.mediawiki ``` Also align correctly in case of multiple authors. * process: Allow Deputies header * process: Increase title limit * process: Update license check * BIP372: Drop redundant Discussions-To Header BIP2 states that the Discussions-To header should only be used if the proposal was discussed somewhere else beside the Bitcoin Developer Mailing List. Therefore, the only use of the Discussions-To header in the repository is unnecessary and can be removed before the header is abolished. * process: Drop unused Discussions-To Header * editor: Remove outdated comment from README table * Allow `Version` field in checks as per BIP 3 * process: Created ↦ Assigned ``` sed -z -i 's/Created: /Assigned: /' bip-0*.md sed -z -i 's/Created: /Assigned: /' bip-0*.mediawiki ``` * Convert licenses to SPDX codes * bip134: Remove wrong License header The Copyright section specifies additional conditions, so the License header is not correct (or at least misleading). So let's just remove it. This is pragmatic because the field was only added as part of the activation of BIP 2 anyway, and there are other old BIPs with a License header. * bip2: Use correct SPDX license ids in the text See https://spdx.org/licenses/ * process: Use "official" SPDX identifiers See https://spdx.org/licenses/ * process: Fix up license sections to match preamble Co-authored-by: Jon Atack <[email protected]> * process: Backfill missing Version headers …for BIPs that have a Changelog section that mentions a version. BIP 1 and BIP 340 have Changelog sections, but do not define versions. * BIP77: Change sequence diagrams to text format (bitcoin#2064) Updated sequence diagrams to use text format instead of mermaid syntax. I cargo cult'd the RFC Rules: > “How are images handled for the plain text version of an RFC?” > The RFC Editor will accept both ASCII art and SVG. If only ASCII art is provided, it will be included in all publication formats. If ASCII art and SVG are both provided, ASCII art will be included in the plain text, and SVG in all other outputs. A note indicating alternative artwork is available is strongly advised. If only SVG is provided, a URI will be included in the plain-text publication format pointing to the HTML version. All artwork and figures should have a complete written description to support assisted reader technology. see: https://www.rfc-editor.org/rse/format-faq/ Since BIPs don't publish html/pdf renders, ASCII art seems like the right choice to render everywhere. Since normative prose is already provided, I chose not to include a written description of the diagrams to support assisted reader tech. * README edits * BIP174: Specify PSBT_IN_PREVIOUS_TXID serialization order (bitcoin#2001) * specify PSBT_IN_PREVIOUS_TXID serialization order * fix: remove ambiguous use of endianness language * Squashed 'bip-0374/secp256k1lab/' content from commit 44dc4bd git-subtree-dir: bip-0374/secp256k1lab git-subtree-split: 44dc4bd893b8f03e621585e3bf255253e0e0fbfb * BIP-374: avoid using sys.path[0] to find current working directory This approach is incompatible with the sys.path extension approach in the next commit which is used to to find the vendored copy of secp256k1lab, so use __file__ instead which works as well. * BIP-374: replace secp256k1.py with vendored copy of secp256k1lab * BIP-374: use `tagged_hash` and `xor_bytes` routines from secp256k1lab * BIP-374: mention secp256k1lab in BIP text * BIP434: p2p feature negotiation * BIP324: Add Version header and Changelog section * BIP14: Backfill discussion URLs * Add BIP-346: OP_TXHASH * BIP324: supporting 1 byte message type ids means supporting the equivalent 12 byte ASCII message types * BIP324: define message_length * BIP 324: Add auxiliary file tracking assignments of one-byte message type IDs * BIP324, BIP183: Add utreexo's p2pv2 message type ids * BIP324, BIP434: Assign message type id for "feature" message * BIP 434: fix license inconsistency * BIP 89: Chain Code Delegation for Private Collaborative Custody (bitcoin#2004) * Add Chaincode Delegation BIP * Update license to BSD-3-Clause and expand blinded signing documentation * Address initial PR comments * Update with BIP number assignment * Fix delegator_sign test vector * Upgrade secp256k1lab and add license file - Upgrade vendored secp256k1lab to commit a265da1 (adds type annotations) - Add COPYING file to satisfy MIT license requirements - Document secp256k1lab commit reference in BIP text * Fix type checker and linter issues in reference implementation - Fix TweakContext to use Scalar types for gacc/tacc - Replace HashFunction enum with Callable type alias - Fix bytearray to bytes conversion in blind_sign - Move imports to top of file - Fix boolean comparison style (use 'not' instead of '== False') - Add proper type annotations and casts for dict handling - Remove unused imports and type ignore comments * Address PR review comments on terminology and clarity - Add intro explaining delegation naming (chain code is delegated, not signing authority) - Reorder terminology to list Delegator before Delegatee - Replace "quorum" with clearer "can co-sign for UTXOs" language - Clarify derivation constraints in terms of delegatee's extended key - Rename "Delegatee Signing" section to "Signing Modes" - Fix "delegatee can apply" to "delegator can produce" (line 112) - Replace undefined "caller" with "delegatee" (line 173) - Clarify "Change outputs" to "Tweaks for change outputs" (line 98) - Add note that message is separate from CCD bundle - Add note on application-specific verification (addresses, amounts) - Add transition sentence clarifying non-concurrent protocol scope * Add changelog entry for 0.1.3 * Fix header: use Authors (plural) for multiple authors * Fix BIP header format for CI compliance - Change Type from 'Standards Track' to 'Specification' (valid type) - Change 'Created' to 'Assigned' (correct field name per BIP format) - Change 'Post-History' to 'Discussion' (recognized field in buildtable.pl) * Apply suggestion from @murchandamus --------- Co-authored-by: Jesse Posner <[email protected]> * Escape pipe character in markdown table (bitcoin#2095) * BIP 110: Reduced Data Temporary Softfork (bitcoin#2017) * Reduced Data Temporary Softfork * BIP-RDTS: update and expand according to PR feedback * BIP-RDTS: minor updates to wording to address feedback * Address PR comments: update Reference Implementation and Deployment * Address PR comments: Clarify deployment name and bit * Address PR comments: Update BIP number, creation date, and README entry * Address @murchandamus X comment: Add activation threshold * Address PR comments: Update to BIP-3; clarify rationale and deployment * Address PR comments: Clarify scriptPubKey limit rationale and LOCKED_IN behavior * BIP360: Pay to Merkle Root (P2MR) (bitcoin#1670) Review comments and assistance by: Armin Sabouri <[email protected]> D++ <[email protected]> Jameson Lopp <[email protected]> jbride <[email protected]> Joey Yandle <[email protected]> Jon Atack <[email protected]> Jonas Nick <[email protected]> Kyle Crews <[email protected]> Mark "Murch" Erhardt <[email protected]> notmike-5 <[email protected]> Vojtěch Strnad <[email protected]> Co-authored-by: Ethan Heilman <[email protected]> Co-authored-by: Isabel Foxen Duke <[email protected]> * BIP85: fix typo in byte value (bitcoin#2100) * BIP352: Add Sebastian Falbesoner as Author * BIP128: Timelock-Recovery Storage Format (bitcoin#2068) * new bip: timelock recovery storage format * Comparison with Script-Based Wallets * Type is Specification Co-authored-by: Mark "Murch" Erhardt <[email protected]> * Change Authors to a single Author Co-authored-by: Mark "Murch" Erhardt <[email protected]> * Replace OP_VAULT mention with OP_CHECKCONTRACTVERIFY * Only the Alert Transaction needs to be non-malleable * Adding discussion link * limiting the transactions weight This is important in order to prevent users from creating recovery-plans that are hard to propagate. * Explain anchor-addresses * fix typo Co-authored-by: Mark "Murch" Erhardt <[email protected]> * add surname initial to author name * Explain unintentional initiation of rrecovery-plan. * limit alert_inputs length to 2439 * updating bip number to 128 * rename to bip-0128.mediawiki * BIP 128: Timelock-Recovery storage format * fix field order, change title to uppercase * Making plugin_version optional Relevant only in wallets where the feature is implemented via a plugin. * Removing mainnet Irrelevant. Obviously a monitoring service for mainnet should verify that the addresses are on mainnet. * BIP-117: add missing BIP8 reference (bitcoin#2080) * bip-0044: add Requires header for BIP32 and BIP43 (bitcoin#2072) * BIP-383: remove extra stray </tt> (bitcoin#2061) * BIP129: Add Requires header (bitcoin#2019) * BIP20,21: add Superseded-By and Replaces headers (bitcoin#1984) * BIP-174: port public key terminology from BIP 373 (bitcoin#2085) The changes are ported from PR 1705 so that the same public key terminology is reflected in BIP 174 as well. Please refer this other PR for more details. * BIP-352: introduce per-group recipient limit K_max (=2323) In theory this is a backwards incompatible protocol change. Practically, no existing Silent Payments wallets out there supports sending to such a high quantity of recipients (not even in terms of _total_ number of recipients), so the K_max limit should be safe to introduce, without any negative effects in the wallet ecosystem. * BIP-352: test vectors: allow specifying repeated recipients for sending Introduce an optional "count" field for recipient objects. Also update the documentation of the fields. * BIP-352: test vectors: allow to check found output count for receiving Introduce an optional "n_outputs" field as alternative to the detailed "outputs" objects (the field was already specified, but not used so far). Also update the documentation of the fields. * BIP-352: add test vector for exceeding K_max limit [sender side] Test case: as the (only) recipient group contains 2324 addresses and thus exceeds the K_max limit by one, sending fails. Can be tested by `$ ./bip-0352/reference.py ./bip-0352/send_and_receive_test_vectors.json` * BIP-352: add test vector for exceeding K_max limit [receiver side] Test case: even though there are 2324 outputs targeted to the recipient, only 2323 are found due to the introduced K_max limit. Any implementation following the new BIP protocol rule wouldn't create such a transaction in the first place, but an attacker might do. Can be tested by `$ ./bip-0352/reference.py ./bip-0352/send_and_receive_test_vectors.json` * bip347: Complete OP_CAT (bitcoin#2090) * OP_CAT to BIP 0003 format, add usecase * draft --> complete * Update bip-0347.mediawiki Co-authored-by: Mark "Murch" Erhardt <[email protected]> * BIP347: Update table entry to complete * Fix breaking test * Add test vectors --------- Co-authored-by: Mark "Murch" Erhardt <[email protected]> * Merge pull request bitcoin#2110 from casey/fix-readme-link Fix mailing list link in readme * Squashed 'bip-0352/secp256k1lab/' content from commit 44dc4bd git-subtree-dir: bip-0352/secp256k1lab git-subtree-split: 44dc4bd893b8f03e621585e3bf255253e0e0fbfb * BIP-352: take use of vendored secp256k1lab for reference implementation This allows to remove secp256k1.py and replace the secp256k1-specific parts in the reference implementation. Replacement guide: * ECKey -> Scalar * ECKey.set(seckey_bytes) -> Scalar.from_bytes_checked(seckey_bytes) * seckey.get_pubkey() -> seckey * G * seckey.get_bytes() -> seckey.to_bytes() * seckey.add(tweak_bytes) -> seckey + Scalar.from_bytes_checked(tweak_bytes) * seckey.negate() -> seckey = -seckey * seckey.sign_schnorr -> schnorr_sign(..., seckey.to_bytes(), ...) * ECPubKey -> GE * ECPubKey.set(pubkey_bytes) -> GE.from_bytes_{xonly,compressed}(pubkey_bytes) * pubkey.get_y() % 2 == 0 -> pubkey.has_even_y() * pubkey.get_bytes(False) -> pubkey.to_bytes_compressed() * pubkey.get_bytes() -> pubkey.to_bytes_xonly() * not pubkey.valid -> pubkey.infinity * pubkey.verify_schnorr -> schnorr_verify(..., pubkey.to_bytes_xonly(), ...) * TaggedHash -> tagged_hash * hashlib.sha256(preimage).digest() -> hash_sha256(preimage) * BIP442: OP_PAIRCOMMIT (bitcoin#1699) * Add: PAIRCOMMIT * New revision with Brandon Black * Fix: Authors and spelling merklize * Fix: header * Rework based on feedback from PR 1699 commit ae69991 Author: moonsettler <[email protected]> Date: Tue Sep 23 02:23:43 2025 +0200 Update references commit 6adcb4e Author: moonsettler <[email protected]> Date: Tue Sep 23 02:15:14 2025 +0200 General computation simplify wording commit 2f911cb Author: moonsettler <[email protected]> Date: Tue Sep 23 01:36:41 2025 +0200 Rework based on feedback from PR 1699 * More readeable scripts & fix footnotes * Format and readability improvements * Update general computation section * THIKCS cost compare * Reference BIP-446 * Standard -> Specification Co-authored-by: Mark "Murch" Erhardt <[email protected]> * Update header to BIP-3 compatible Co-authored-by: Mark "Murch" Erhardt <[email protected]> * Add: Post-History * Update Cost comparison table * Post-History -> Discussion Co-authored-by: Mark "Murch" Erhardt <[email protected]> * bip119: fix stack[-1] -> self.stack[-1] in pseudocode The execute_bip_119 pseudocode references `stack[-1]` on line 74 instead of `self.stack[-1]`, inconsistent with all other stack references in the function. The C++ reference implementation correctly uses `stack.back()` throughout. * BIP 370: remove redundant field inclusion comment in OUT_SCRIPT description There are already "Requiring inclusion" / "Requiring exclusion" columns that specify that. * BIP-110: Clarify rule 2 witness stack element exclusions * BIP-110: Update deployment section with EXPIRED state; add GBT subsection to specification * BIP392: Silent Payment Output Script Descriptors (bitcoin#2047) * Add sp() output descriptor format for BIP352 Silent Payments * Update headers and remove space after comma in descriptors * Add label ranges with examples * Update with assigned number and adjust preamble for BIP3 * BIP392: Add table entry to README * Add two argument key expression form and remove birthday and label arguments * Add BIP392 sp() descriptor to BIP380 script expressions table * Add sp() descriptor to BIP390 allowed expressions and add musig() example to BIP392 * Add changelog and version header to BIP390 * BIP32: edits by ddustin for clarity (picks up PR785) (bitcoin#1903) Co-authored-by: Dusty Daemon <[email protected]> Co-authored-by: Pieter Wuille <[email protected]> Co-authored-by: Murch <[email protected]> * BIP-352: mention secp256k1lab in BIP text also fix a small grammar nit (s/are provided/is provided/) * bip54: reword "potentially executed" language in sigops limit specification The paragraph in its entirety is already unambiguous that all signature-checking operations *present* in the Script (as opposed to *executed*) are counted. However i received feedback that the "potentially executed" language in the first sentence of this paragraph may be confusing. This is because it is in theory possible to have a more accurate upper bound by analyzing the possible spending paths and use the maximum number of signature-checking operations in either to check against the limit. This commit rewords the first sentence to use the word "present" to be extra-clear before even describing how the accounting is performed in later sentences. * bip54: expand on rationale for non-final coinbase nSequence Making sure that the coinbase is timelocked is a neat simplification in reasoning about duplicates, but it has caused some confusions. For instance here: https://gnusha.org/pi/bitcoindev/[email protected]/ Fix this by explicitly stating the implications. * bip54: update sigops test vectors following Inquisition review This is a batch update to the tests vectors for the limit on legacy signature-checking operations introduced in BIP 54, following feedack received on the Bitcoin Inquisition PR and from Chris Stewart's implementation in Bitcoin-S. * bip54: move comment as first element in txsize test vectors This is part of feedback received during the Bitcoin Inquisition PR review. * bip54: make test vectors POSIX-compliant (newline at EOF) This was pointed out during the Bitcoin Inquisition PR review * bip54: restructure timestamp test vectors into a tree The test vectors were initially designed to maximally simple, which led to much redundancy. That was probably too close to one extreme on the spectrum between simplicity and efficiency. Here we shave off 20k lines by simply representing the header chains as a tree instead of list of lists by duplicating all common headers. * bip54: add another transaction size test case Ariard mentioned he would like to see a test case for a 64-byte transaction spending a Taproot output with an annex. I took the opportunity to also make the output be an OP_RETURN with a 2-byte push, as another semi-realistic transaction. * BIP-128: exact specification for the checksum calculation (bitcoin#2121) * Add BIP446: OP_TEMPLATEHASH, BIP448: Taproot-native (Re)bindable Transactions (bitcoin#1974) Co-authored-by: Antoine Poinsot <[email protected]> * BIP-174: mark PSBT_GLOBAL_VERSION as required for v2 * BIP-375: Add bitcoin test framework as dependency - deps/bitcoin_test * Squashed 'bip-0375/deps/secp256k1lab/' content from commit 44dc4bd git-subtree-dir: bip-0375/deps/secp256k1lab git-subtree-split: 44dc4bd893b8f03e621585e3bf255253e0e0fbfb * BIP442: Update reference links (bitcoin#2129) * Varops: Two BIPs for Script Restoration: varops calculations and tapleaf version (0xc2). Special thanks to Murch for teaching me mediawiki, and so much great formatting and clarity advice. Signed-off-by: Rusty Russell <[email protected]> * script restoration: fix MUL cost to account to round up B to word boundary. Julian points out that the implementation does this, which improves accuracy for the case of small B (since the term is multiplied: for normal OP_ADD etc we don't bother, since the difference is very bounded). Signed-off-by: Rusty Russell <[email protected]> * BIP 440, 441: official numbers, into README.mediawiki and renamed. Signed-off-by: Rusty Russell <[email protected]> * BIP-375: add test vector file * BIP-375: add BIP375PSBT extension classes BIP375PSBT (a PSBT subclass that deserializes into BIP375PSBTMap instances) BIP375PSBTMap (a PSBTMap subclass with BIP-375 field access helpers) * BIP-375: add test_runner and validate PSBT structure Implement psbt structure checks Add test_runner.py for processing test vectors * BIP-375: add ecdh coverage validation Add deps/dleq.py (Adapted from bip-0374/reference.py) Extract pubkey from PSBT inputs - PSBT_IN_BIP32_DERIVATION - PSBT_IN_WITNESS_UTXO for P2TR Add script type helpers - bip352 input eligibility helpers * BIP-375: add input eligibility validation Verify segwit version >1 not used if silent payment outputs present (bip352) Verify SIGHASH_ALL requirement * BIP-375: add output scripts validation Add support for computing bip352 output scripts Extract ECDH shares and public key from PSBT and aggregate both if necessary Refactor validate_ecdh_coverage to use collect_input_ecdh_and_pubkey * BIP-375: update documentation Update Test Vectors section Add README.md to explain validation tooling and dependencies * BIP-370: add invalid test vector for PSBT_IN_REQUIRED_HEIGHT_LOCKTIME of 0 * BIP-370: add invalid test vector for PSBT_GLOBAL_UNSIGNED_TX in PSBTv2 * BIP-370: add invalid test vector for missing PSBT_GLOBAL_TX_VERSION in PSBTv2 * BIP-375: address review feedback correctly label witness_utxo vs non_witness_utxo key in supplementary inputs Summary of test vector changes: removed test: - psbt structure: empty PSBT_OUT_SCRIPT field when sending to non-sp output modified test: - ecdh coverage: only one ineligible P2SH multisig input when PSBT_OUT_SCRIPT set for sp output - can finalize: one P2PKH input single-signer - can finalize: two inputs using per-input ECDH shares - only eligible inputs contribute shares (P2SH excluded) added test: - can finalize: two inputs using global ECDH share - only eligible inputs contribute shares (P2SH excluded) * BIP-375: clarify eligible input restriction in Signer text * BIP-375: clarify eligible inputs restriction in Computing the Output Scripts text * BIP-375: skip ineligible inputs when combining ecdh shares add fake ecdh share and dleq proof to P2SH input for valid test: two inputs using per-input ECDH shares - only eligible inputs contribute shares (P2SH excluded) remove unused return string from is_input_eligible * Merge pull request bitcoin#2099 from craigraw/descriptorannotations BIP393: Output Script Descriptor Annotations * BIP-352: warn against stopping scan due to wallet policy filtering (bitcoin#2134) Adds a warning to the "if no matches are found, stop" scanning step. Without it, wallet developers may be tempted to apply policy filtering (e.g. dust) before deciding to continue, causing subsequent outputs for the same sender to be missed. * BIP-375: fix label byte order used by labelhash Test vectors with labels now use big-endian byte order instead of little-endian, matching BIP-352 specification Summary of test vector changes: - psbt structure: missing PSBT_OUT_SP_V0_INFO field when PSBT_OUT_SP_V0_LABEL set - can finalize: one P2WPKH input / two mixed outputs - labeled sp output and BIP 32 change - can finalize: two sp outputs - output 0 uses label=3 / output 1 uses label=1 * BIP-0322: add format clarification table This commit adds a table that clarifies what script types are compatible with what signing variant and also makes more clear what the exact format for the signatures of the different variants are. * BIP-0322: clarify scriptSig on to_sign for legacy transactions Before this commit it was not clear that non-native SegWit outputs (e.g. P2PKH or P2SH-P2WPKH) only work if the correct scriptSig is provided. This then also makes it more clear why P2SH-P2WPKH outputs are NOT supported by the "simple" variant. * BIP-0322: turn test vectors into JSON, add more This commit turns the existing test vectors into a JSON and then adds more test cases covering the most common script types. * BIP376: Spending Silent Payment outputs with PSBTs (bitcoin#2089) * BIP174: Deduplicate global type definitions * BIP174: Deduplicate input type definitions * BIP174: Deduplicate per-output type definitions * 174: Add changelog and version number * BIP361: Post Quantum Migration and Legacy Signature Sunset (bitcoin#1895) * BIP-361 * bip361: Fix background color * address feedback * bip174: Explain BIP2 status in Changelog * bip388: Amend assignment date BIP3 clarified the content of the ambiguous Created header and renamed it to Assigned. BIP388 was assigned per bitcoin#1389 (review) on 2023-12-26. The prior "Created:" field content was moved to a Changelog entry. * bip388: Add missing Version header, rename Changelog * bip174: Fix relative paths to other BIPs * BIP-352: add test vector for edge case - input key intermediate sum zero Exercises [A, -A, A] input key pattern where the intermediate sum hits zero after the first two keys, but the final sum is non-zero. Implementations that validate after each pairwise addition (rather than summing all keys first) will incorrectly reject this case. * BIP-352: update changelog and correct typo Add patch version 1.1.1 to Changelog Remove extra leading double-quote in CoinJoin ref name * BIP-375: add changelog section Add Changelog section Begin with version 0.1.0 as this BIP is Draft phase * Corrections to BIP-0361 on rescue protocols * Fix BIP32 links and consistency Co-authored-by: Jon Atack <[email protected]> * BIP-0322: wrap long lines at 100 characters This re-formats the document for easier editing and diff viewing. Wiki syntax is weird for lists and line wraps break them. Simple lists were changed to <ul> or <ol> tags but complex lists remain as they are to not bloat the diff too much. * BIP-0322: small semantic and formatting fixes This fixes small inconsistencies or incomplete definitions based on previous, already merged changes. * BIP-0322: reference btcd implementation * BIP-0322: update motivation, clarify Proof of Funds purpose This addresses two discussion items: - The list of UTXOs should not be interpreted as a "proof that no other UTXOs for an address exist". - The BIP only addresses "signer receives funds with the address" and not "signer sent a previous transaction" use case. * BIP-0322: clarify terminology used Since the term "signature" can be pretty overloaded dependin on the context, we clarify what it actually means in this BIP. * BIP-0322: encode finalized PSBT for Proof of Funds This commit proposes a fix for the problem that an offline verifier previously was not able to even verify the witness stack of additional inputs. By providing the full finalized PSBT, a verifier has all the input data necessary to run the script through the validation engine. We require the PSBT to be finalized to make sure it contains the final script witness or final script sig but no extra potentially privacy-sensitive fields. The Non-Witness and Witness UTXO fields are explicitly allowed for finalized PSBTs, which makes the format perfect for the use case. * BIP-0322: add prefix to message signature * Fix broken BIP 3 reference in bip-0347 and bip-0360 changelogs Both BIPs added a changelog entry on 2026-01-23 referencing the updated BIP Process meta-BIP with the wrong form: - bip-0360.mediawiki:404 rendered `[[bip-0003.mediawiki|BIP 003]]`, but the actual file is `bip-0003.md`. The MediaWiki link therefore failed to resolve to the BIP 3 page on the bitcoin/bips GitHub wiki render and on the bips.dev / bip339 style mirrors — readers of the bip-0360 changelog landed on a 404. - bip-0347.mediawiki:170 wrote the same reference as bare text `BIP 003` with no link at all, so readers of bip-0347 had no way to navigate to the BIP 3 they were meant to follow. Rewrite both entries to use the canonical form `[[bip-0003.md|BIP 3]]`: - `bip-0003.md` matches the actual filename. - `BIP 3` matches the display text convention the README (line 40) and every other BIP in this repository already use when linking to bip-0003 — "BIP 003" with the three-digit zero-pad appears nowhere else in the repo for any BIP and is not part of the display style described in BIP 2. Also drops the trailing whitespace on the bip-0347 line while we are there (the `typos` CI tolerates it but it is inconsistent with every other line in the same changelog block). * Merge pull request bitcoin#1548 from seedhammer/master BIP391: Binary Output Descriptors * BIP-0329: Add spscan label type for labelling silent payments wallets (bitcoin#2149) * Add spscan label type * minor edits * Fix broken anchor links * BIP22: fix anchor links * BIP23: Fix anchor links * BIP342: Fix anchor links * Fix other broken anchors Used the following `sed` command and manually verified the unstaged changes. Special cases that were not committed included external links to Wikipedia which are case-sensitive, links specific lines in code, a link to a title with a slash that had to be cleaned up, and links to citations on the BIP repository that contain an underscore. ``` sed -E -i ' s/(\[\[[^][]*#)([^]|]*)(\||\]\])/\1\L\2\E\3/g :again s/(\[\[[^][]*#)([^]|]*)([: _]+)([^]|]*)(\||\]\])/\1\2-\4\5/g t again ' bip-0*mediawiki ``` * Eliminate remaining "user-content" anchor links * BIP451: Dust UTXO Disposal Protocol (bitcoin#2150) * Add draft BIP for dust utxo disposal protocol * Assign number 451, update preamble, rename BIP file, and add entry to README table * Small edits * Change title, abstract, motivation to focus on dust attack UTXOs * Simpify dust selection section * Add batching to address consolidation rules * Fix core version in privacy preservation * Fix table units * Add confirmed utxo rationale * Revert title back to original * Change output to always be OP_RETURN ash * BIP-0174+BIP-0322: describe PSBT based signing This commit proposes a new PSBT input field type for transporting the message to be signed to different signers in a multisig signing use case. * BIP-0322: update test vectors This commit updates the test vectors to reflect all the changes in the previous commits and also introduces new test vectors for the Proof of Funds variant. * BIP-0322: add guggero as deputy * BIP-0322: remove comments, add discussion links As described in BIP-0003, the comments section is no longer required. Instead we add all relevant discussions. * README+BIP-0322: add changelog, mark Complete * BIP 54: grammar improvements (bitcoin#2151) * bip54: Clarify deployment cost wording * bip54: Clarify merkle tree wording * bip54: Clarify sigops wording * bip54: Clarify timewarp wording * bip54: Clarify miner preparation cost wording * BIP352: Fix recipients typing in create_outputs to List[Dict[str, str]] * BIP352: fix Any typing `any` is a built-in logic function but not a valid type hint Instead, use `Any`, the special construct from the typing module that informs static analysis tools. * BIP352: complete return type annotations in bitcoin_utils The serialization helpers in bip-0352/bitcoin_utils.py were partially typed: ser_uint32, hash160, is_p2tr, is_p2wpkh, is_p2sh and is_p2pkh already declare argument and return types, but the surrounding from_hex / ser_uint256 / deser_uint256 / deser_txid / deser_compact_size / deser_string / deser_string_vector helpers omit them. Annotate the missing return types (and fill in the obvious argument types) so the file is consistent and so static analysis can flow types through callers in reference.py. No behavior changes. * bip-0054: spell out in more places that 64 bytes is for witness-stripped size * Add BIP323: 24 nVersion bits for general purpose use (bitcoin#2116) * BIP-0322: change role to author, add required BIPs * BIP-0322: link to later sections for clarity * BIP-0322: clarify sighash flag for P2TR * Fix bip322 link in bip174 type registry * BIP-0322: grammar and readability touchup Co-authored-by: Jon Atack <[email protected]> * bip-0054: clarify rationale for invalidating 64-byte txs As Eric points out on the mailing list: 1. the rationale section should mention and address the "seam" objection directly rather than burying it in a footnote; 2. the full node consensus split issue should not be used as sole rationale for invalidating 64-byte txs (but it's fair to point out it's fixed as a nice to have byproduct). ML thread: https://gnusha.org/pi/bitcoindev/[email protected]/T/#md66e252f0748f4ef7569d5e15d42631e12b66c0b, * bip-0054: state explicitly fake inclusion proofs only concern SPV verifier * nit fixes * bip-0054: less redundancy in 64-byte rationale, move caching risk to footnote * bip-0054: disambiguate use of "mitigation" Jon pointed that i use "mitigation" to refer both to the items of this BIP, and for the existing workarounds to make SPV verifiers safe in the presence of 64-byte txs. This commit rephrases the latter usage. * bip-0054: add a footnote with known workarounds for SPV verifiers --------- Signed-off-by: Rusty Russell <[email protected]> Co-authored-by: Bashmunta <[email protected]> Co-authored-by: Mark "Murch" Erhardt <[email protected]> Co-authored-by: Greg Sanders <[email protected]> Co-authored-by: Jon Atack <[email protected]> Co-authored-by: Antoine Poinsot <[email protected]> Co-authored-by: Hodlinator <[email protected]> Co-authored-by: Chris Stewart <[email protected]> Co-authored-by: yyhrnk <[email protected]> Co-authored-by: Galoretka <[email protected]> Co-authored-by: Luke Dashjr <[email protected]> Co-authored-by: Anthony Towns <[email protected]> Co-authored-by: maradini77 <[email protected]> Co-authored-by: kurahin <[email protected]> Co-authored-by: Ben Westgate <[email protected]> Co-authored-by: VolodymyrBg <[email protected]> Co-authored-by: lisenokdonbassenok <[email protected]> Co-authored-by: Tim Ruffing <[email protected]> Co-authored-by: Olaoluwa Osuntokun <[email protected]> Co-authored-by: Yuval Kogman <[email protected]> Co-authored-by: Dan Gould <[email protected]> Co-authored-by: Jack D <[email protected]> Co-authored-by: Sebastian Falbesoner <[email protected]> Co-authored-by: Steven Roose <[email protected]> Co-authored-by: Jurvis Tan <[email protected]> Co-authored-by: Jesse Posner <[email protected]> Co-authored-by: Paul Miller <[email protected]> Co-authored-by: Dathon Ohm <[email protected]> Co-authored-by: Hunter Beast <[email protected]> Co-authored-by: Ethan Heilman <[email protected]> Co-authored-by: Isabel Foxen Duke <[email protected]> Co-authored-by: YoCheng <[email protected]> Co-authored-by: Oren <[email protected]> Co-authored-by: MoNyAvA <[email protected]> Co-authored-by: Mohammad Eglil <[email protected]> Co-authored-by: rkrux <[email protected]> Co-authored-by: Casey Rodarmor <[email protected]> Co-authored-by: moonsettler <[email protected]> Co-authored-by: Andreas Schjønhaug <[email protected]> Co-authored-by: craigraw <[email protected]> Co-authored-by: Dusty Daemon <[email protected]> Co-authored-by: Pieter Wuille <[email protected]> Co-authored-by: macgyver13 <[email protected]> Co-authored-by: Rusty Russell <[email protected]> Co-authored-by: Andrew Toth <[email protected]> Co-authored-by: Oghenovo Usiwoma <[email protected]> Co-authored-by: Oli <[email protected]> Co-authored-by: nymius <[email protected]> Co-authored-by: Ava Chow <[email protected]> Co-authored-by: Jameson Lopp <[email protected]> Co-authored-by: conduition <[email protected]> Co-authored-by: boskodev790 <[email protected]> Co-authored-by: SeedHammer <[email protected]> Co-authored-by: bubb1es71 <[email protected]> Co-authored-by: nervana21 <[email protected]> Co-authored-by: Snezhkko <[email protected]> Co-authored-by: omipheo <[email protected]> Co-authored-by: Matt Corallo <[email protected]> Co-authored-by: Armin Sabouri <[email protected]> Co-authored-by: scgbckbone <[email protected]>
16 participants
Initial draft of a proposal for how to incentivize migration to post quantum cryptography and safeguard the ecosystem from unnecessary inflation of the circulating supply and the economic turmoil likely to accompany such an event.