Copy disabled (too large)
Download .txt
Showing preview only (15,693K chars total). Download the full file to get everything.
Repository: bitcoin/bips
Branch: master
Commit: 2778442c21ce
Files: 385
Total size: 14.9 MB
Directory structure:
gitextract_ant9xgmu/
├── .gitattributes
├── .github/
│ └── workflows/
│ └── github-action-checks.yml
├── .gitignore
├── .typos.toml
├── CONTRIBUTING.md
├── README.mediawiki
├── bip-0001.mediawiki
├── bip-0002.mediawiki
├── bip-0003.md
├── bip-0008/
│ ├── assignments.mediawiki
│ └── states.dot
├── bip-0008.mediawiki
├── bip-0009/
│ ├── assignments.mediawiki
│ └── states.gv
├── bip-0009.mediawiki
├── bip-0010.mediawiki
├── bip-0011.mediawiki
├── bip-0012.mediawiki
├── bip-0013.mediawiki
├── bip-0014.mediawiki
├── bip-0015.mediawiki
├── bip-0016/
│ └── qa.mediawiki
├── bip-0016.mediawiki
├── bip-0017.mediawiki
├── bip-0018.mediawiki
├── bip-0019.mediawiki
├── bip-0020.mediawiki
├── bip-0021.mediawiki
├── bip-0022.mediawiki
├── bip-0023.mediawiki
├── bip-0030.mediawiki
├── bip-0031.mediawiki
├── bip-0032.mediawiki
├── bip-0033.mediawiki
├── bip-0034.mediawiki
├── bip-0035.mediawiki
├── bip-0036.mediawiki
├── bip-0037.mediawiki
├── bip-0038.mediawiki
├── bip-0039/
│ ├── bip-0039-wordlists.md
│ ├── chinese_simplified.txt
│ ├── chinese_traditional.txt
│ ├── czech.txt
│ ├── english.txt
│ ├── french.txt
│ ├── italian.txt
│ ├── japanese.txt
│ ├── korean.txt
│ ├── portuguese.txt
│ └── spanish.txt
├── bip-0039.mediawiki
├── bip-0042.mediawiki
├── bip-0043.mediawiki
├── bip-0044.mediawiki
├── bip-0045.mediawiki
├── bip-0046.mediawiki
├── bip-0047.mediawiki
├── bip-0048.mediawiki
├── bip-0049.mediawiki
├── bip-0050.mediawiki
├── bip-0052.mediawiki
├── bip-0053/
│ ├── 64byte-tx-mainnet.txt
│ └── non-standard-hashlock-utxos.txt
├── bip-0053.mediawiki
├── bip-0054/
│ └── test_vectors/
│ ├── README.md
│ ├── coinbases.json
│ ├── sigops.json
│ ├── timestamps.json
│ └── txsize.json
├── bip-0054.md
├── bip-0060.mediawiki
├── bip-0061.mediawiki
├── bip-0062.mediawiki
├── bip-0064.mediawiki
├── bip-0065.mediawiki
├── bip-0066.mediawiki
├── bip-0067.mediawiki
├── bip-0068.mediawiki
├── bip-0069/
│ └── bip-0069_examples.py
├── bip-0069.mediawiki
├── bip-0070/
│ ├── extensions.mediawiki
│ └── paymentrequest.proto
├── bip-0070.mediawiki
├── bip-0071.mediawiki
├── bip-0072.mediawiki
├── bip-0073.mediawiki
├── bip-0074.mediawiki
├── bip-0075/
│ └── paymentrequest.proto
├── bip-0075.mediawiki
├── bip-0077.md
├── bip-0078.mediawiki
├── bip-0079.mediawiki
├── bip-0080.mediawiki
├── bip-0081.mediawiki
├── bip-0083.mediawiki
├── bip-0084.mediawiki
├── bip-0085.mediawiki
├── bip-0086.mediawiki
├── bip-0087.mediawiki
├── bip-0088.mediawiki
├── bip-0089/
│ ├── bip32.py
│ ├── descriptor.py
│ ├── reference.py
│ ├── secp256k1lab/
│ │ ├── COPYING
│ │ ├── __init__.py
│ │ ├── bip340.py
│ │ ├── ecdh.py
│ │ ├── keys.py
│ │ ├── py.typed
│ │ ├── secp256k1.py
│ │ └── util.py
│ └── vectors/
│ ├── blind_challenge_gen_vectors.json
│ ├── blind_nonce_gen_vectors.json
│ ├── blind_sign_and_verify_vectors.json
│ ├── change_output_verification_vectors.json
│ ├── compute_bip32_tweak_vectors.json
│ ├── delegator_sign_vectors.json
│ ├── input_verification_vectors.json
│ └── unblind_signature_vectors.json
├── bip-0089.mediawiki
├── bip-0090.mediawiki
├── bip-0091.mediawiki
├── bip-0093.mediawiki
├── bip-0094.mediawiki
├── bip-0098/
│ ├── build.sh
│ ├── node-variants.dot
│ ├── skip-skip.dot
│ ├── traversal-example.dot
│ └── unbalanced-hash-tree.dot
├── bip-0098.mediawiki
├── bip-0099.mediawiki
├── bip-0100.mediawiki
├── bip-0101.mediawiki
├── bip-0102.mediawiki
├── bip-0103.mediawiki
├── bip-0104.mediawiki
├── bip-0105.mediawiki
├── bip-0106.mediawiki
├── bip-0107.mediawiki
├── bip-0109.mediawiki
├── bip-0110.mediawiki
├── bip-0111.mediawiki
├── bip-0112.mediawiki
├── bip-0113.mediawiki
├── bip-0114.mediawiki
├── bip-0115.mediawiki
├── bip-0116.mediawiki
├── bip-0117.mediawiki
├── bip-0118.mediawiki
├── bip-0119/
│ ├── simulation.py
│ └── vectors/
│ ├── ctvhash.json
│ ├── tx_invalid.json
│ └── tx_valid.json
├── bip-0119.mediawiki
├── bip-0120.mediawiki
├── bip-0121.mediawiki
├── bip-0122.mediawiki
├── bip-0123.mediawiki
├── bip-0124.mediawiki
├── bip-0125.mediawiki
├── bip-0126.mediawiki
├── bip-0127.mediawiki
├── bip-0128.mediawiki
├── bip-0129.mediawiki
├── bip-0130.mediawiki
├── bip-0131.mediawiki
├── bip-0132.mediawiki
├── bip-0133.mediawiki
├── bip-0134.mediawiki
├── bip-0135.mediawiki
├── bip-0136.mediawiki
├── bip-0137.mediawiki
├── bip-0140.mediawiki
├── bip-0141.mediawiki
├── bip-0142.mediawiki
├── bip-0143.mediawiki
├── bip-0144.mediawiki
├── bip-0145.mediawiki
├── bip-0146.mediawiki
├── bip-0147.mediawiki
├── bip-0148.mediawiki
├── bip-0149.mediawiki
├── bip-0150.mediawiki
├── bip-0151.mediawiki
├── bip-0152.mediawiki
├── bip-0154.mediawiki
├── bip-0155.mediawiki
├── bip-0156/
│ └── bitcoin.conf
├── bip-0156.mediawiki
├── bip-0157.mediawiki
├── bip-0158/
│ ├── gentestvectors.go
│ ├── go.mod
│ ├── go.sum
│ └── testnet-19.json
├── bip-0158.mediawiki
├── bip-0159.mediawiki
├── bip-0171.mediawiki
├── bip-0172.mediawiki
├── bip-0173.mediawiki
├── bip-0174/
│ ├── build.sh
│ ├── coinjoin-workflow.tex
│ └── multisig-workflow.tex
├── bip-0174.mediawiki
├── bip-0175.mediawiki
├── bip-0176.mediawiki
├── bip-0177.mediawiki
├── bip-0178.mediawiki
├── bip-0179.mediawiki
├── bip-0180.mediawiki
├── bip-0197.mediawiki
├── bip-0199.mediawiki
├── bip-0300/
│ └── images.txt
├── bip-0300.mediawiki
├── bip-0301.mediawiki
├── bip-0310.mediawiki
├── bip-0320.mediawiki
├── bip-0321.mediawiki
├── bip-0322.mediawiki
├── bip-0324/
│ ├── ellswift_decode_test_vectors.csv
│ ├── gen_test_vectors.py
│ ├── message_type_ids.md
│ ├── packet_encoding_test_vectors.csv
│ ├── reference.py
│ ├── run_test_vectors.py
│ ├── secp256k1_test_vectors.py
│ ├── test_sage_decoding.py
│ └── xswiftec_inv_test_vectors.csv
├── bip-0324.mediawiki
├── bip-0325.mediawiki
├── bip-0326.mediawiki
├── bip-0327/
│ ├── gen_vectors_helper.py
│ ├── reference.py
│ ├── tests.sh
│ └── vectors/
│ ├── det_sign_vectors.json
│ ├── key_agg_vectors.json
│ ├── key_sort_vectors.json
│ ├── nonce_agg_vectors.json
│ ├── nonce_gen_vectors.json
│ ├── sig_agg_vectors.json
│ ├── sign_verify_vectors.json
│ └── tweak_vectors.json
├── bip-0327.mediawiki
├── bip-0328/
│ ├── _base58.py
│ ├── _common.py
│ ├── _xpub.py
│ ├── reference.py
│ └── vectors.json
├── bip-0328.mediawiki
├── bip-0329.mediawiki
├── bip-0330/
│ └── minisketch.py
├── bip-0330.mediawiki
├── bip-0331.mediawiki
├── bip-0337.mediawiki
├── bip-0338.mediawiki
├── bip-0339.mediawiki
├── bip-0340/
│ ├── LICENSE
│ ├── reference.py
│ ├── test-vectors.csv
│ └── test-vectors.py
├── bip-0340.mediawiki
├── bip-0341/
│ └── wallet-test-vectors.json
├── bip-0341.mediawiki
├── bip-0342.mediawiki
├── bip-0343.mediawiki
├── bip-0345/
│ └── vaults.drawio
├── bip-0345.mediawiki
├── bip-0346/
│ └── ref-impl/
│ ├── Cargo.toml
│ ├── src/
│ │ └── main.rs
│ └── txhash_vectors.json
├── bip-0346.md
├── bip-0347.mediawiki
├── bip-0348.md
├── bip-0349.md
├── bip-0350.mediawiki
├── bip-0351.mediawiki
├── bip-0352/
│ ├── bech32m.py
│ ├── bitcoin_utils.py
│ ├── reference.py
│ ├── ripemd160.py
│ ├── secp256k1lab/
│ │ ├── .github/
│ │ │ └── workflows/
│ │ │ └── main.yml
│ │ ├── .python-version
│ │ ├── CHANGELOG.md
│ │ ├── COPYING
│ │ ├── README.md
│ │ ├── pyproject.toml
│ │ └── src/
│ │ └── secp256k1lab/
│ │ ├── __init__.py
│ │ ├── bip340.py
│ │ ├── ecdh.py
│ │ ├── keys.py
│ │ ├── py.typed
│ │ ├── secp256k1.py
│ │ └── util.py
│ └── send_and_receive_test_vectors.json
├── bip-0352.mediawiki
├── bip-0353.mediawiki
├── bip-0360/
│ └── ref-impl/
│ ├── .gitignore
│ ├── common/
│ │ ├── tests/
│ │ │ └── data/
│ │ │ ├── p2mr_construction.json
│ │ │ └── p2mr_pqc_construction.json
│ │ └── utils/
│ │ ├── signet_miner_loop.sh
│ │ └── workshop/
│ │ ├── Dockerfile.bcli
│ │ ├── Dockerfile.full
│ │ └── bip360-workshop.drawio
│ ├── js/
│ │ ├── .gitignore
│ │ ├── README.adoc
│ │ ├── package.json
│ │ ├── src/
│ │ │ ├── p2mr-example.ts
│ │ │ └── test-npm-pqc-package.js
│ │ └── tsconfig.json
│ ├── python/
│ │ └── .gitignore
│ └── rust/
│ ├── .cargo/
│ │ └── config.toml
│ ├── Cargo.toml
│ ├── README.md
│ ├── docs/
│ │ ├── development_notes.adoc
│ │ ├── p2mr-end-to-end.adoc
│ │ ├── p2mr-signet-workshop.adoc
│ │ ├── p2tr-end-to-end.adoc
│ │ ├── quantum_root_tap_tree.txt
│ │ └── stack_element_size_performance_tests.adoc
│ ├── examples/
│ │ ├── p2mr-end-to-end.sh
│ │ ├── p2mr_construction.rs
│ │ ├── p2mr_spend.rs
│ │ ├── p2tr_construction.rs
│ │ ├── p2tr_spend.rs
│ │ ├── schnorr_example.rs
│ │ └── slh_dsa_verification_example.rs
│ ├── src/
│ │ ├── bin/
│ │ │ └── slh_dsa_key_gen.rs
│ │ ├── data_structures.rs
│ │ ├── error.rs
│ │ └── lib.rs
│ └── tests/
│ ├── p2mr_construction.rs
│ ├── p2mr_pqc_construction.rs
│ └── p2mr_spend.rs
├── bip-0360.mediawiki
├── bip-0370.mediawiki
├── bip-0371.mediawiki
├── bip-0372.mediawiki
├── bip-0373.mediawiki
├── bip-0374/
│ ├── gen_test_vectors.py
│ ├── reference.py
│ ├── run_test_vectors.py
│ ├── secp256k1lab/
│ │ ├── .github/
│ │ │ └── workflows/
│ │ │ └── main.yml
│ │ ├── .python-version
│ │ ├── CHANGELOG.md
│ │ ├── COPYING
│ │ ├── README.md
│ │ ├── pyproject.toml
│ │ └── src/
│ │ └── secp256k1lab/
│ │ ├── __init__.py
│ │ ├── bip340.py
│ │ ├── ecdh.py
│ │ ├── keys.py
│ │ ├── py.typed
│ │ ├── secp256k1.py
│ │ └── util.py
│ ├── test_vectors_generate_proof.csv
│ └── test_vectors_verify_proof.csv
├── bip-0374.mediawiki
├── bip-0375.mediawiki
├── bip-0379.md
├── bip-0380.mediawiki
├── bip-0381.mediawiki
├── bip-0382.mediawiki
├── bip-0383.mediawiki
├── bip-0384.mediawiki
├── bip-0385.mediawiki
├── bip-0386.mediawiki
├── bip-0387.mediawiki
├── bip-0388/
│ └── wallet_policies.py
├── bip-0388.mediawiki
├── bip-0389.mediawiki
├── bip-0390.mediawiki
├── bip-0392.mediawiki
├── bip-0431.mediawiki
├── bip-0433.mediawiki
├── bip-0434.md
├── bip-0442.md
├── bip-0443.mediawiki
├── bip-0446/
│ ├── README.md
│ ├── basics.json
│ └── script_assets_test.json
├── bip-0446.md
├── bip-0448.md
└── scripts/
├── buildtable.pl
├── diffcheck.expected
├── diffcheck.sh
└── link-format-chk.sh
================================================
FILE CONTENTS
================================================
================================================
FILE: .gitattributes
================================================
*.mediawiki linguist-detectable
================================================
FILE: .github/workflows/github-action-checks.yml
================================================
name: GitHub Actions Check
run-name: ${{ github.actor }} Checks 🚀
on: [push, pull_request]
jobs:
Link-Format-Checks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- run: scripts/link-format-chk.sh
Build-Table-Checks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- run: scripts/buildtable.pl >/tmp/table.mediawiki || exit 1
Diff-Checks:
name: "Diff Checks (fails until number assignment)"
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
with:
fetch-depth: 2
- run: scripts/diffcheck.sh
Typo-Checks:
name: "Typo Checks"
runs-on: ubuntu-latest
steps:
- name: Checkout Actions Repository
uses: actions/checkout@v5
- name: Check spelling
uses: crate-ci/typos@master
================================================
FILE: .gitignore
================================================
bip-0174/coinjoin-workflow.aux
bip-0174/coinjoin-workflow.log
bip-0174/coinjoin-workflow.pdf
bip-0174/multisig-workflow.aux
bip-0174/multisig-workflow.log
bip-0174/multisig-workflow.pdf
================================================
FILE: .typos.toml
================================================
[default]
extend-ignore-re = [
# NOTE: use here for regex patterns
"xpub.*",
"xprv.*",
"3.*", # address
"5.*", # address
"private_key .*",
"privkey .*",
"tt.*", # <tt> tags
"code.*", # <code> tags
"\\w*<sub>", # prefix for <sub> tags
"OP_SUCCESSx|\\d+",
"pay.*",
"ser.*",
"prefix.*",
"value: .*",
"pqNTRUsign",
"Strnad",
]
[default.extend-words]
# NOTE: use here for false-positives
anc = "anc"
PSBT = "PSBT"
ser = "ser"
# Names
Atack = "Atack"
Falke = "Falke"
Meni = "Meni"
Ono = "Ono"
[files]
extend-exclude = [
"/*/*.csv",
"/*.d*",
"/*/*.d*",
"/*/*.go",
"/*/*.json",
"/*/*/*.json",
"/*/*.mod",
"/*/*.proto",
"/*/*.py",
"scripts",
"/*/*.s*",
"/*/*.t*",
]
================================================
FILE: CONTRIBUTING.md
================================================
# Contributing Guidelines
Apart from following [BIP 2](./bip-0002.mediawiki),
we do CI checks to ensure that the proposed BIPs do not have common typos.
These checks are done using [`typos`](https://github.com/crate-ci/typos).
To check for typos locally,
install [`typos`](https://github.com/crate-ci/typos)
and then run in the root directory:
```bash
typos
```
================================================
FILE: README.mediawiki
================================================
People wishing to submit a BIP should first describe their idea to the [https://groups.google.com/g/bitcoindev 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 <em>not</em> 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-0003.md|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: [https://en.bitcoin.it/wiki/Economic_majority economic majority]).
{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
!Number
!Layer
!Title
!Owner
!Type
!Status
|- style="background-color: #ffcfcf"
| [[bip-0001.mediawiki|1]]
|
| BIP Purpose and Guidelines
| Amir Taaki
| Process
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0002.mediawiki|2]]
|
| BIP process, revised
| Luke Dashjr
| Process
| Closed
|- style="background-color: #cfffcf"
| [[bip-0003.md|3]]
|
| Updated BIP Process
| Murch
| Process
| Deployed
|-
| [[bip-0008.mediawiki|8]]
|
| Version bits with lock-in by height
| Shaolin Fry, Luke Dashjr
| Informational
| Draft
|- style="background-color: #cfffcf"
| [[bip-0009.mediawiki|9]]
|
| Version bits with timeout and delay
| Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
| Informational
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0010.mediawiki|10]]
| Applications
| Multi-Sig Transaction Distribution
| Alan Reiner
| Informational
| Closed
|- style="background-color: #cfffcf"
| [[bip-0011.mediawiki|11]]
| Applications
| M-of-N Standard Transactions
| Gavin Andresen
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0012.mediawiki|12]]
| Consensus (soft fork)
| OP_EVAL
| Gavin Andresen
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0013.mediawiki|13]]
| Applications
| Address Format for pay-to-script-hash
| Gavin Andresen
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0014.mediawiki|14]]
| Peer Services
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0015.mediawiki|15]]
| Applications
| Aliases
| Amir Taaki
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0016.mediawiki|16]]
| Consensus (soft fork)
| Pay to Script Hash
| Gavin Andresen
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0017.mediawiki|17]]
| Consensus (soft fork)
| OP_CHECKHASHVERIFY (CHV)
| Luke Dashjr
| Specification
| Closed
|- style="background-color: #ffffcf"
| [[bip-0018.mediawiki|18]]
| Consensus (soft fork)
| hashScriptCheck
| Luke Dashjr
| Specification
| Complete
|- style="background-color: #ffcfcf"
| [[bip-0019.mediawiki|19]]
| Applications
| M-of-N Standard Transactions (Low SigOp)
| Luke Dashjr
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0020.mediawiki|20]]
| Applications
| URI Scheme
| Luke Dashjr
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0021.mediawiki|21]]
| Applications
| URI Scheme
| Nils Schneider, Matt Corallo
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0022.mediawiki|22]]
| API/RPC
| getblocktemplate - Fundamentals
| Luke Dashjr
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0023.mediawiki|23]]
| API/RPC
| getblocktemplate - Pooled Mining
| Luke Dashjr
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0030.mediawiki|30]]
| Consensus (soft fork)
| Duplicate transactions
| Pieter Wuille
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0031.mediawiki|31]]
| Peer Services
| Pong message
| Mike Hearn
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0032.mediawiki|32]]
| Applications
| Hierarchical Deterministic Wallets
| Pieter Wuille
| Informational
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0033.mediawiki|33]]
| Peer Services
| Stratized Nodes
| Amir Taaki
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0034.mediawiki|34]]
| Consensus (soft fork)
| Block v2, Height in Coinbase
| Gavin Andresen
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0035.mediawiki|35]]
| Peer Services
| mempool message
| Jeff Garzik
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0036.mediawiki|36]]
| Peer Services
| Custom Services
| Stefan Thomas
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0037.mediawiki|37]]
| Peer Services
| Connection Bloom filtering
| Mike Hearn, Matt Corallo
| Specification
| Deployed
|-
| [[bip-0038.mediawiki|38]]
| Applications
| Passphrase-protected private key
| Mike Caldwell, Aaron Voisine
| Specification
| Draft
|- style="background-color: #cfffcf"
| [[bip-0039.mediawiki|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
|- style="background-color: #cfffcf"
| [[bip-0042.mediawiki|42]]
| Consensus (soft fork)
| A finite monetary supply for Bitcoin
| Pieter Wuille
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0043.mediawiki|43]]
| Applications
| Purpose Field for Deterministic Wallets
| Marek Palatinus, Pavol Rusnak
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0044.mediawiki|44]]
| Applications
| Multi-Account Hierarchy for Deterministic Wallets
| Marek Palatinus, Pavol Rusnak
| Specification
| Deployed
|- style="background-color: #ffffcf"
| [[bip-0045.mediawiki|45]]
| Applications
| Structure for Deterministic P2SH Multisignature Wallets
| Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia
| Specification
| Complete
|-
| [[bip-0046.mediawiki|46]]
| Applications
| Address Scheme for Timelocked Fidelity Bonds
| Chris Belcher, Thebora Kompanioni
| Specification
| Draft
|- style="background-color: #cfffcf"
| [[bip-0047.mediawiki|47]]
| Applications
| Reusable Payment Codes for Hierarchical Deterministic Wallets
| Justus Ranvier
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0048.mediawiki|48]]
| Applications
| Multi-Script Hierarchy for Multi-Sig Wallets
| Fontaine
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0049.mediawiki|49]]
| Applications
| Derivation scheme for P2WPKH-nested-in-P2SH based accounts
| Daniel Weigl
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0050.mediawiki|50]]
|
| March 2013 Chain Fork Post-Mortem
| Gavin Andresen
| Informational
| Deployed
|-
| [[bip-0052.mediawiki|52]]
| Consensus (hard fork)
| Durable, Low Energy Bitcoin PoW
| Michael Dubrovsky, Bogdan Penkovsky
| Specification
| Draft
|-
| [[bip-0053.mediawiki|53]]
| Consensus (soft fork)
| Disallow 64-byte transactions
| Chris Stewart
| Specification
| Draft
|-
| [[bip-0054.md|54]]
| Consensus (soft fork)
| Consensus Cleanup
| Antoine Poinsot, Matt Corallo
| Specification
| Draft
|- style="background-color: #ffcfcf"
| [[bip-0060.mediawiki|60]]
| Peer Services
| Fixed Length "version" Message (Relay-Transactions Field)
| Amir Taaki
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0061.mediawiki|61]]
| Peer Services
| Reject P2P message
| Gavin Andresen
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0062.mediawiki|62]]
| Consensus (soft fork)
| Dealing with malleability
| Pieter Wuille
| Specification
| Closed
|-
| 63
| Applications
| Stealth Addresses
| Peter Todd
| Standard
| BIP number allocated
|- style="background-color: #ffcfcf"
| [[bip-0064.mediawiki|64]]
| Peer Services
| getutxo message
| Mike Hearn
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0065.mediawiki|65]]
| Consensus (soft fork)
| OP_CHECKLOCKTIMEVERIFY
| Peter Todd
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0066.mediawiki|66]]
| Consensus (soft fork)
| Strict DER signatures
| Pieter Wuille
| Specification
| Deployed
|- style="background-color: #ffffcf"
| [[bip-0067.mediawiki|67]]
| Applications
| Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
| Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
| Specification
| Complete
|- style="background-color: #cfffcf"
| [[bip-0068.mediawiki|68]]
| Consensus (soft fork)
| Relative lock-time using consensus-enforced sequence numbers
| Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona
| Specification
| Deployed
|- style="background-color: #ffffcf"
| [[bip-0069.mediawiki|69]]
| Applications
| Lexicographical Indexing of Transaction Inputs and Outputs
| Kristov Atlas
| Informational
| Complete
|- style="background-color: #cfffcf"
| [[bip-0070.mediawiki|70]]
| Applications
| Payment Protocol
| Gavin Andresen, Mike Hearn
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0071.mediawiki|71]]
| Applications
| Payment Protocol MIME types
| Gavin Andresen
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0072.mediawiki|72]]
| Applications
| bitcoin: uri extensions for Payment Protocol
| Gavin Andresen
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0073.mediawiki|73]]
| Applications
| Use "Accept" header for response type negotiation with Payment Request URLs
| Stephen Pair
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0074.mediawiki|74]]
| Applications
| Allow zero value OP_RETURN in Payment Protocol
| Toby Padilla
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0075.mediawiki|75]]
| Applications
| Out of Band Address Exchange using Payment Protocol Encryption
| Justin Newton, Matt David, Aaron Voisine, James MacWhyte
| Specification
| Deployed
|-
| [[bip-0077.md|77]]
| Applications
| Async Payjoin
| Dan Gould, Yuval Kogman
| Specification
| Draft
|-
| [[bip-0078.mediawiki|78]]
| Applications
| A Simple Payjoin Proposal
| Nicolas Dorier
| Specification
| Draft
|- style="background-color: #ffcfcf"
| [[bip-0079.mediawiki|79]]
| Applications
| Bustapay :: a practical coinjoin protocol
| Ryan Havar
| Informational
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0080.mediawiki|80]]
|
| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
| Justus Ranvier, Jimmy Song
| Informational
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0081.mediawiki|81]]
|
| Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
| Justus Ranvier, Jimmy Song
| Informational
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0083.mediawiki|83]]
| Applications
| Dynamic Hierarchical Deterministic Key Trees
| Eric Lombrozo
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0084.mediawiki|84]]
| Applications
| Derivation scheme for P2WPKH based accounts
| Pavol Rusnak
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0085.mediawiki|85]]
| Applications
| Deterministic Entropy From BIP32 Keychains
| Ethan Kosakovsky, Aneesh Karve
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0086.mediawiki|86]]
| Applications
| Key Derivation for Single Key P2TR Outputs
| Ava Chow
| Specification
| Deployed
|- style="background-color: #ffffcf"
| [[bip-0087.mediawiki|87]]
| Applications
| Hierarchy for Deterministic Multisig Wallets
| Robert Spigler
| Specification
| Complete
|- style="background-color: #ffffcf"
| [[bip-0088.mediawiki|88]]
| Applications
| Hierarchical Deterministic Path Templates
| Dmitry Petukhov
| Informational
| Complete
|-
| [[bip-0089.mediawiki|89]]
| Applications
| Chain Code Delegation
| Jesse Posner, Jurvis Tan
| Specification
| Draft
|- style="background-color: #cfffcf"
| [[bip-0090.mediawiki|90]]
|
| Buried Deployments
| Suhas Daftuar
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0091.mediawiki|91]]
| Consensus (soft fork)
| Reduced threshold Segwit MASF
| James Hilliard
| Specification
| Deployed
|-
| [[bip-0093.mediawiki|93]]
| Applications
| codex32: Checksummed SSSS-aware BIP32 seeds
| Leon Olsson Curr, Pearlwort Sneed, Andrew Poelstra
| Informational
| Draft
|- style="background-color: #cfffcf"
| [[bip-0094.mediawiki|94]]
| Applications
| Testnet 4
| Fabian Jahr
| Specification
| Deployed
|-
| [[bip-0098.mediawiki|98]]
| Consensus (soft fork)
| Fast Merkle Trees
| Mark Friedenbach, Kalle Alm, BtcDrak
| Specification
| Draft
|- style="background-color: #ffcfcf"
| [[bip-0099.mediawiki|99]]
|
| Motivation and deployment of consensus rule changes ([soft/hard]forks)
| Jorge Timón
| Informational
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0100.mediawiki|100]]
| Consensus (hard fork)
| Dynamic maximum block size by miner vote
| Jeff Garzik, Tom Harding, Dagur Valberg Johannsson
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0101.mediawiki|101]]
| Consensus (hard fork)
| Increase maximum block size
| Gavin Andresen
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0102.mediawiki|102]]
| Consensus (hard fork)
| Block size increase to 2MB
| Jeff Garzik
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0103.mediawiki|103]]
| Consensus (hard fork)
| Block size following technological growth
| Pieter Wuille
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0104.mediawiki|104]]
| Consensus (hard fork)
| 'Block75' - Max block size like difficulty
| t.khan
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0105.mediawiki|105]]
| Consensus (hard fork)
| Consensus based block size retargeting algorithm
| BtcDrak
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0106.mediawiki|106]]
| Consensus (hard fork)
| Dynamically Controlled Bitcoin Block Size Max Cap
| Upal Chakraborty
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0107.mediawiki|107]]
| Consensus (hard fork)
| Dynamic limit on the block size
| Washington Y. Sanchez
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0109.mediawiki|109]]
| Consensus (hard fork)
| Two million byte size limit with sigop and sighash limits
| Gavin Andresen
| Specification
| Closed
|-
| [[bip-0110.mediawiki|110]]
| Consensus (soft fork)
| Reduced Data Temporary Softfork
| Dathon Ohm
| Specification
| Draft
|- style="background-color: #cfffcf"
| [[bip-0111.mediawiki|111]]
| Peer Services
| NODE_BLOOM service bit
| Matt Corallo, Peter Todd
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0112.mediawiki|112]]
| Consensus (soft fork)
| CHECKSEQUENCEVERIFY
| BtcDrak, Mark Friedenbach, Eric Lombrozo
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0113.mediawiki|113]]
| Consensus (soft fork)
| Median time-past as endpoint for lock-time calculations
| Thomas Kerin, Mark Friedenbach
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0114.mediawiki|114]]
| Consensus (soft fork)
| Merkelized Abstract Syntax Tree
| Johnson Lau
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0115.mediawiki|115]]
| Consensus (soft fork)
| Generic anti-replay protection using Script
| Luke Dashjr
| Specification
| Closed
|-
| [[bip-0116.mediawiki|116]]
| Consensus (soft fork)
| MERKLEBRANCHVERIFY
| Mark Friedenbach, Kalle Alm, BtcDrak
| Specification
| Draft
|-
| [[bip-0117.mediawiki|117]]
| Consensus (soft fork)
| Tail Call Execution Semantics
| Mark Friedenbach, Kalle Alm, BtcDrak
| Specification
| Draft
|-
| [[bip-0118.mediawiki|118]]
| Consensus (soft fork)
| SIGHASH_ANYPREVOUT for Taproot Scripts
| Christian Decker, Anthony Towns
| Specification
| Draft
|-
| [[bip-0119.mediawiki|119]]
| Consensus (soft fork)
| CHECKTEMPLATEVERIFY
| Jeremy Rubin
| Specification
| Draft
|- style="background-color: #ffcfcf"
| [[bip-0120.mediawiki|120]]
| Applications
| Proof of Payment
| Kalle Rosenbaum
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0121.mediawiki|121]]
| Applications
| Proof of Payment URI scheme
| Kalle Rosenbaum
| Specification
| Closed
|-
| [[bip-0122.mediawiki|122]]
| Applications
| URI scheme for Blockchain references / exploration
| Marco Pontello
| Specification
| Draft
|- style="background-color: #cfffcf"
| [[bip-0123.mediawiki|123]]
|
| BIP Classification
| Eric Lombrozo
| Process
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0124.mediawiki|124]]
| Applications
| Hierarchical Deterministic Script Templates
| Eric Lombrozo, William Swanson
| Informational
| Closed
|- style="background-color: #cfffcf"
| [[bip-0125.mediawiki|125]]
| Applications
| Opt-in Full Replace-by-Fee Signaling
| David A. Harding, Peter Todd
| Specification
| Deployed
|-
| [[bip-0126.mediawiki|126]]
|
| Best Practices for Heterogeneous Input Script Transactions
| Kristov Atlas
| Informational
| Draft
|-
| [[bip-0127.mediawiki|127]]
| Applications
| Simple Proof-of-Reserves Transactions
| Steven Roose
| Specification
| Draft
|-
| [[bip-0128.mediawiki|128]]
| Applications
| Timelock-Recovery Storage Format
| Oren Z
| Specification
| Draft
|- style="background-color: #ffffcf"
| [[bip-0129.mediawiki|129]]
| Applications
| Bitcoin Secure Multisig Setup (BSMS)
| Hugo Nguyen, Peter Gray, Marko Bencun, Aaron Chen, Rodolfo Novak
| Specification
| Complete
|- style="background-color: #cfffcf"
| [[bip-0130.mediawiki|130]]
| Peer Services
| sendheaders message
| Suhas Daftuar
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0131.mediawiki|131]]
| Consensus (hard fork)
| "Coalescing Transaction" Specification (wildcard inputs)
| Chris Priest
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0132.mediawiki|132]]
|
| Committee-based BIP Acceptance Process
| Andy Chase
| Process
| Closed
|- style="background-color: #cfffcf"
| [[bip-0133.mediawiki|133]]
| Peer Services
| feefilter message
| Alex Morcos
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0134.mediawiki|134]]
| Consensus (hard fork)
| Flexible Transactions
| Tom Zander
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0135.mediawiki|135]]
|
| Generalized version bits voting
| Sancho Panza
| Informational
| Closed
|-
| [[bip-0136.mediawiki|136]]
| Applications
| Bech32 Encoded Tx Position References
| Велеслав, Jonas Schnelli, Daniel Pape
| Informational
| Draft
|- style="background-color: #cfffcf"
| [[bip-0137.mediawiki|137]]
| Applications
| Signatures of Messages using Private Keys
| Christopher Gilliard
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0140.mediawiki|140]]
| Consensus (soft fork)
| Normalized TXID
| Christian Decker
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0141.mediawiki|141]]
| Consensus (soft fork)
| Segregated Witness (Consensus layer)
| Eric Lombrozo, Johnson Lau, Pieter Wuille
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0142.mediawiki|142]]
| Applications
| Address Format for Segregated Witness
| Johnson Lau
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0143.mediawiki|143]]
| Consensus (soft fork)
| Transaction Signature Verification for Version 0 Witness Program
| Johnson Lau, Pieter Wuille
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0144.mediawiki|144]]
| Peer Services
| Segregated Witness (Peer Services)
| Eric Lombrozo, Pieter Wuille
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0145.mediawiki|145]]
| API/RPC
| getblocktemplate Updates for Segregated Witness
| Luke Dashjr
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0146.mediawiki|146]]
| Consensus (soft fork)
| Dealing with signature encoding malleability
| Johnson Lau, Pieter Wuille
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0147.mediawiki|147]]
| Consensus (soft fork)
| Dealing with dummy stack element malleability
| Johnson Lau
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0148.mediawiki|148]]
| Consensus (soft fork)
| Mandatory activation of segwit deployment
| Shaolin Fry
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0149.mediawiki|149]]
| Consensus (soft fork)
| Segregated Witness (second deployment)
| Shaolin Fry
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0150.mediawiki|150]]
| Peer Services
| Peer Authentication
| Jonas Schnelli
| Specification
| Closed
|- style="background-color: #ffcfcf"
| [[bip-0151.mediawiki|151]]
| Peer Services
| Peer-to-Peer Communication Encryption
| Jonas Schnelli
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0152.mediawiki|152]]
| Peer Services
| Compact Block Relay
| Matt Corallo
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0154.mediawiki|154]]
| Peer Services
| Rate Limiting via peer specified challenges
| Karl-Johan Alm
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0155.mediawiki|155]]
| Peer Services
| addrv2 message
| Wladimir J. van der Laan
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0156.mediawiki|156]]
| Peer Services
| Dandelion - Privacy Enhancing Routing
| Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod Viswanath
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0157.mediawiki|157]]
| Peer Services
| Client Side Block Filtering
| Olaoluwa Osuntokun, Alex Akselrod, Jim Posen
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0158.mediawiki|158]]
| Peer Services
| Compact Block Filters for Light Clients
| Olaoluwa Osuntokun, Alex Akselrod
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0159.mediawiki|159]]
| Peer Services
| NODE_NETWORK_LIMITED service bit
| Jonas Schnelli
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0171.mediawiki|171]]
| Applications
| Currency/exchange rate information API
| Luke Dashjr
| Specification
| Closed
|-
| [[bip-0172.mediawiki|172]]
| Applications
| Define Bitcoin Subunits as Satoshis
| OceanSlim
| Informational
| Draft
|- style="background-color: #cfffcf"
| [[bip-0173.mediawiki|173]]
| Applications
| Base32 address format for native v0-16 witness outputs
| Pieter Wuille, Greg Maxwell
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0174.mediawiki|174]]
| Applications
| Partially Signed Bitcoin Transaction Format
| Ava Chow
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0175.mediawiki|175]]
| Applications
| Pay to Contract Protocol
| Omar Shibli, Nicholas Gregory
| Informational
| Closed
|-
| [[bip-0176.mediawiki|176]]
|
| Bits Denomination
| Jimmy Song
| Informational
| Draft
|-
| [[bip-0177.mediawiki|177]]
|
| Redefine Bitcoin's Base Unit
| John Carvalho
| Informational
| Draft
|-
| [[bip-0178.mediawiki|178]]
| Applications
| Version Extended WIF
| Karl-Johan Alm
| Specification
| Draft
|-
| [[bip-0179.mediawiki|179]]
|
| Name for payment recipient identifiers
| Emil Engler, Luke Dashjr
| Informational
| Draft
|- style="background-color: #ffcfcf"
| [[bip-0180.mediawiki|180]]
| Peer Services
| Block size/weight fraud proof
| Luke Dashjr
| Specification
| Closed
|-
| [[bip-0197.mediawiki|197]]
| Applications
| Hashed Time-Locked Collateral Contract
| Matthew Black, Tony Cai
| Specification
| Draft
|- style="background-color: #ffcfcf"
| [[bip-0199.mediawiki|199]]
| Applications
| Hashed Time-Locked Contract transactions
| Sean Bowe, Daira Hopwood
| Specification
| Closed
|-
| [[bip-0300.mediawiki|300]]
| Consensus (soft fork)
| Hashrate Escrows (Consensus layer)
| Paul Sztorc, CryptAxe
| Specification
| Draft
|-
| [[bip-0301.mediawiki|301]]
| Consensus (soft fork)
| Blind Merged Mining (Consensus layer)
| Paul Sztorc, CryptAxe
| Specification
| Draft
|-
| [[bip-0310.mediawiki|310]]
| Applications
| Stratum protocol extensions
| Pavel Moravec, Jan Čapek
| Informational
| Draft
|-
| [[bip-0320.mediawiki|320]]
|
| nVersion bits for general purpose use
| BtcDrak
| Specification
| Draft
|- style="background-color: #ffffcf"
| [[bip-0321.mediawiki|321]]
| Applications
| URI Scheme
| Matt Corallo
| Specification
| Complete
|-
| [[bip-0322.mediawiki|322]]
| Applications
| Generic Signed Message Format
| Karl-Johan Alm
| Specification
| Draft
|- style="background-color: #cfffcf"
| [[bip-0324.mediawiki|324]]
| Peer Services
| Version 2 P2P Encrypted Transport Protocol
| Dhruv Mehta, Tim Ruffing, Jonas Schnelli, Pieter Wuille
| Specification
| Deployed
|- style="background-color: #ffffcf"
| [[bip-0325.mediawiki|325]]
| Applications
| Signet
| Karl-Johan Alm, Anthony Towns
| Specification
| Complete
|-
| [[bip-0326.mediawiki|326]]
| Applications
| Anti-fee-sniping in taproot transactions
| Chris Belcher
| Informational
| Draft
|- style="background-color: #cfffcf"
| [[bip-0327.mediawiki|327]]
|
| MuSig2 for BIP340-compatible Multi-Signatures
| Jonas Nick, Tim Ruffing, Elliott Jin
| Informational
| Deployed
|- style="background-color: #ffffcf"
| [[bip-0328.mediawiki|328]]
| Applications
| Derivation Scheme for MuSig2 Aggregate Keys
| Ava Chow
| Informational
| Complete
|-
| [[bip-0329.mediawiki|329]]
| Applications
| Wallet Labels Export Format
| Craig Raw
| Informational
| Draft
|-
| [[bip-0330.mediawiki|330]]
| Peer Services
| Transaction announcements reconciliation
| Gleb Naumenko, Pieter Wuille
| Specification
| Draft
|-
| [[bip-0331.mediawiki|331]]
| Peer Services
| Ancestor Package Relay
| Gloria Zhao
| Specification
| Draft
|-
| [[bip-0337.mediawiki|337]]
| API/RPC
| Compressed Transactions
| Tom Briar
| Specification
| Draft
|- style="background-color: #ffcfcf"
| [[bip-0338.mediawiki|338]]
| Peer Services
| Disable transaction relay message
| Suhas Daftuar
| Specification
| Closed
|- style="background-color: #cfffcf"
| [[bip-0339.mediawiki|339]]
| Peer Services
| WTXID-based transaction relay
| Suhas Daftuar
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0340.mediawiki|340]]
|
| Schnorr Signatures for secp256k1
| Pieter Wuille, Jonas Nick, Tim Ruffing
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0341.mediawiki|341]]
| Consensus (soft fork)
| Taproot: SegWit version 1 spending rules
| Pieter Wuille, Jonas Nick, Anthony Towns
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0342.mediawiki|342]]
| Consensus (soft fork)
| Validation of Taproot Scripts
| Pieter Wuille, Jonas Nick, Anthony Towns
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0343.mediawiki|343]]
| Consensus (soft fork)
| Mandatory activation of taproot deployment
| Shinobius, Michael Folkson
| Specification
| Deployed
|- style="background-color: #ffcfcf"
| [[bip-0345.mediawiki|345]]
| Consensus (soft fork)
| OP_VAULT
| James O'Beirne, Greg Sanders
| Specification
| Closed
|-
| [[bip-0346.md|346]]
| Consensus (soft fork)
| OP_TXHASH
| Steven Roose, Brandon Black
| Specification
| Draft
|- style="background-color: #ffffcf"
| [[bip-0347.mediawiki|347]]
| Consensus (soft fork)
| OP_CAT in Tapscript
| Ethan Heilman, Armin Sabouri
| Specification
| Complete
|-
| [[bip-0348.md|348]]
| Consensus (soft fork)
| CHECKSIGFROMSTACK
| Brandon Black, Jeremy Rubin
| Specification
| Draft
|-
| [[bip-0349.md|349]]
| Consensus (soft fork)
| OP_INTERNALKEY
| Brandon Black, Jeremy Rubin
| Specification
| Draft
|- style="background-color: #cfffcf"
| [[bip-0350.mediawiki|350]]
| Applications
| Bech32m format for v1+ witness addresses
| Pieter Wuille
| Specification
| Deployed
|-
| [[bip-0351.mediawiki|351]]
| Applications
| Private Payments
| Alfred Hodler, Clark Moody
| Informational
| Draft
|- style="background-color: #ffffcf"
| [[bip-0352.mediawiki|352]]
| Applications
| Silent Payments
| josibake, Ruben Somsen, Sebastian Falbesoner
| Specification
| Complete
|- style="background-color: #ffffcf"
| [[bip-0353.mediawiki|353]]
| Applications
| DNS Payment Instructions
| Matt Corallo, Bastien Teinturier
| Specification
| Complete
|-
| [[bip-0360.mediawiki|360]]
| Consensus (soft fork)
| Pay-to-Merkle-Root (P2MR)
| Hunter Beast, Ethan Heilman, Isabel Foxen Duke
| Specification
| Draft
|- style="background-color: #cfffcf"
| [[bip-0370.mediawiki|370]]
| Applications
| PSBT Version 2
| Ava Chow
| Specification
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0371.mediawiki|371]]
| Applications
| Taproot Fields for PSBT
| Ava Chow
| Specification
| Deployed
|-
| [[bip-0372.mediawiki|372]]
| Applications
| Pay-to-contract tweak fields for PSBT
| Maxim Orlovsky
| Specification
| Draft
|- style="background-color: #ffffcf"
| [[bip-0373.mediawiki|373]]
| Applications
| MuSig2 PSBT Fields
| Ava Chow
| Specification
| Complete
|-
| [[bip-0374.mediawiki|374]]
| Applications
| Discrete Log Equality Proofs
| Andrew Toth, Ruben Somsen, Sebastian Falbesoner
| Specification
| Draft
|-
| [[bip-0375.mediawiki|375]]
| Applications
| Sending Silent Payments with PSBTs
| Andrew Toth, Ava Chow, josibake
| Specification
| Draft
|-
| [[bip-0379.md|379]]
| Applications
| Miniscript
| Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Antoine Poinsot, Ava Chow
| Informational
| Draft
|- style="background-color: #cfffcf"
| [[bip-0380.mediawiki|380]]
| Applications
| Output Script Descriptors General Operation
| Pieter Wuille, Ava Chow
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0381.mediawiki|381]]
| Applications
| Non-Segwit Output Script Descriptors
| Pieter Wuille, Ava Chow
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0382.mediawiki|382]]
| Applications
| Segwit Output Script Descriptors
| Pieter Wuille, Ava Chow
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0383.mediawiki|383]]
| Applications
| Multisig Output Script Descriptors
| Pieter Wuille, Ava Chow
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0384.mediawiki|384]]
| Applications
| combo() Output Script Descriptors
| Pieter Wuille, Ava Chow
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0385.mediawiki|385]]
| Applications
| raw() and addr() Output Script Descriptors
| Pieter Wuille, Ava Chow
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0386.mediawiki|386]]
| Applications
| tr() Output Script Descriptors
| Pieter Wuille, Ava Chow
| Informational
| Deployed
|- style="background-color: #cfffcf"
| [[bip-0387.mediawiki|387]]
| Applications
| Tapscript Multisig Output Script Descriptors
| Pieter Wuille, Ava Chow
| Informational
| Deployed
|- style="background-color: #ffffcf"
| [[bip-0388.mediawiki|388]]
| Applications
| Wallet Policies for Descriptor Wallets
| Salvatore Ingala
| Specification
| Complete
|-
| [[bip-0389.mediawiki|389]]
| Applications
| Multipath Descriptor Key Expressions
| Ava Chow
| Informational
| Draft
|-
| [[bip-0390.mediawiki|390]]
| Applications
| musig() Descriptor Key Expression
| Ava Chow
| Informational
| Draft
|-
| [[bip-0392.mediawiki|392]]
| Applications
| Silent Payment Output Script Descriptors
| Craig Raw
| Specification
| Draft
|-
| [[bip-0431.mediawiki|431]]
| Applications
| Topology Restrictions for Pinning
| Gloria Zhao
| Informational
| Draft
|-
| [[bip-0433.mediawiki|433]]
| Applications
| Pay to Anchor (P2A)
| Gregory Sanders
| Informational
| Draft
|-
| [[bip-0434.md|434]]
| Peer Services
| Peer Feature Negotiation
| Anthony Towns
| Specification
| Draft
|-
| [[bip-0442.md|442]]
| Consensus (soft fork)
| OP_PAIRCOMMIT
| moonsettler, Brandon Black
| Specification
| Draft
|-
| [[bip-0443.mediawiki|443]]
| Consensus (soft fork)
| OP_CHECKCONTRACTVERIFY
| Salvatore Ingala
| Specification
| Draft
|-
| [[bip-0446.md|446]]
| Consensus (soft fork)
| OP_TEMPLATEHASH
| Gregory Sanders, Antoine Poinsot, Steven Roose
| Specification
| Draft
|-
| [[bip-0448.md|448]]
| Consensus (soft fork)
| Taproot-native (Re)bindable Transactions
| Gregory Sanders, Antoine Poinsot, Steven Roose
| Specification
| Draft
|}
<!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! -->
================================================
FILE: bip-0001.mediawiki
================================================
<pre>
BIP: 1
Title: BIP Purpose and Guidelines
Authors: Amir Taaki <genjix@riseup.net>
Status: Closed
Type: Process
Assigned: 2011-09-19
Proposed-Replacement: 2
</pre>
==What is a BIP?==
BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.
We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.
Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
==BIP Types==
There are three kinds of BIP:
* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational BIPs or follow their advice.
* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
==BIP Work Flow==
The BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development & Technical Discussion] forum) is the best way to go about this.
Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need standardisation between multiple projects; these don't need a BIP and should be injected into the relevant Bitcoin development work flow with a patch submission to the applicable Bitcoin issue tracker.
Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.
It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.
The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & Workflow]]. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad.
Authors MUST NOT self assign BIP numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject.
If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the BIPs git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
The BIP author may update the Draft as necessary in the git repository. Updates to drafts may also be submitted by the author as pull requests.
Standards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final.
Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final".
A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status.
A BIP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.
BIPs can also be superseded by a different BIP, rendering the original obsolete. This is intended for Informational BIPs, where version 2 of an API can replace version 1.
The possible paths of the status of BIPs are as follows:
<img src=bip-0001/process.png></img>
Some Informational and Process BIPs may also have a status of "Active" if they are never meant to be completed. E.g. BIP 1 (this BIP).
==What belongs in a successful BIP?==
Each BIP should have the following parts:
* Preamble -- RFC 822 style headers containing meta-data about the BIP, including the BIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.
* Abstract -- a short (~200 word) description of the technical issue being addressed.
* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License.
* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin).
* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the BIP solves. BIP submissions without sufficient motivation may be rejected outright.
* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
* The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
* Backwards Compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities. BIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
* Reference Implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.
* The final implementation must include test code and documentation appropriate for the Bitcoin protocol.
==BIP Formats and Templates==
BIPs should be written in mediawiki or markdown format.
===BIP Header Preamble===
Each BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
<pre>
BIP: <BIP number>
Title: <BIP title>
Author: <list of authors' real names and optionally, email addrs>
* Discussions-To: <email address>
Status: <Draft | Active | Accepted | Deferred | Rejected |
Withdrawn | Final | Superseded>
Type: <Standards Track | Informational | Process>
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
* Post-History: <dates of postings to bitcoin mailing list>
* Replaces: <BIP number>
* Superseded-By: <BIP number>
* Resolution: <url>
</pre>
The Author header lists the names, and optionally the email addresses of all the authors/owners of the BIP. The format of the Author header value must be
Random J. User <address@dom.ain>
if the email address is included, and just
Random J. User
if the address is not given.
If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.
Note: The Resolution header is required for Standards Track BIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the BIP is made.
While a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists.
The Type header specifies the type of BIP: Standards Track, Informational, or Process.
The Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.
BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on.
BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete.
===Auxiliary Files===
BIPs may include auxiliary files such as diagrams. Image files should be included in a subdirectory for that BIP. Auxiliary files must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png").
==Transferring BIP Ownership==
It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.
If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
==BIP Editors==
The current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]].
==BIP Editor Responsibilities & Workflow==
The BIP editor subscribes to the Bitcoin development mailing list. All BIP-related correspondence should be sent (or CC'd) to luke_bipeditor@dashjr.org.
For each new BIP that comes in an editor does the following:
* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
* The title should accurately describe the content.
* Edit the BIP for language (spelling, grammar, sentence structure, etc.), markup (for reST BIPs), code style (examples should match BIP 8 & 7).
If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
Once the BIP is ready for the repository it should be submitted as a "pull request" to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub where it may get further feedback.
The BIP editor will:
* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141) in the pull request comments.
* Merge the pull request when the author is ready (allowing some time for further peer review).
* List the BIP in [[README.mediawiki]]
* Send email back to the BIP author with next steps (post to bitcoin-dev mailing list).
The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
==History==
This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the BIP editors or the Bitcoin development mailing list.
==Changelog==
10 Oct 2015 - Added clarifications about submission process and BIP number assignment.
01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc.
================================================
FILE: bip-0002.mediawiki
================================================
<pre>
BIP: 2
Title: BIP process, revised
Authors: Luke Dashjr <luke+bip@dashjr.org>
Status: Closed
Type: Process
Assigned: 2016-02-03
License: BSD-2-Clause OR OPUBL-1.0
Replaces: 1
Proposed-Replacement: 3
</pre>
==Abstract==
A Bitcoin Improvement Proposal (BIP) is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.
We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.
Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
This particular BIP replaces BIP 1 with a more well-defined and clear process.
==Copyright==
This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
==BIP workflow==
The BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able.
Small enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a BIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker.
Additionally, many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons.
The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression.
After investigating past work, the best way to proceed is by posting about the new idea to the [https://groups.google.com/g/bitcoindev Bitcoin development mailing list].
Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time.
Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick).
It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used.
Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://groups.google.com/g/bitcoindev Bitcoin development mailing list].
This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal.
Following a discussion, the proposal should be submitted to the [https://github.com/bitcoin/bips BIPs git repository] as a pull request.
This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until an editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers).
BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.
It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.
When the BIP draft is complete, a BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository.
The BIP editors will not unreasonably reject a BIP.
Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.
For a BIP to be accepted it must meet certain minimum criteria.
It must be a clear and complete description of the proposed enhancement.
The enhancement must represent a net improvement.
The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
The BIP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests.
===Transferring BIP Ownership===
It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.
If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editors. If the original author doesn't respond to email in a timely manner, the BIP editors will make a unilateral decision (it's not like such decisions can't be reversed :).
===BIP Editors===
The current BIP editors are:
* Bryan Bishop ([[mailto:kanzure@gmail.com|kanzure@gmail.com]])
* Jon Atack ([[mailto:jon@atack.com|jon@atack.com]])
* Luke Dashjr ([[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]])
* Mark "Murch" Erhardt ([[mailto:murch@murch.one|murch@murch.one]])
* Olaoluwa Osuntokun ([[mailto:laolu32@gmail.com|laolu32@gmail.com]])
* Ruben Somsen ([[mailto:rsomsen@gmail.com|rsomsen@gmail.com]])
===BIP Editor Responsibilities & Workflow===
The BIP editors subscribe to the Bitcoin development mailing list.
Off-list BIP-related correspondence should be sent (or CC'd) to the BIP editors.
For each new BIP that comes in an editor does the following:
* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
* The title should accurately describe the content.
* The BIP draft must have been sent to the Bitcoin development mailing list for discussion.
* Motivation and backward compatibility (when applicable) must be addressed.
* The defined Layer header must be correctly assigned for the given specification.
* Licensing terms must be acceptable for BIPs.
If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
Once the BIP is ready for the repository it should be submitted as a "pull request" to the [https://github.com/bitcoin/bips BIPs git repository] where it may get further feedback.
The BIP editor will:
* Assign a BIP number in the pull request.
* Merge the pull request when it is ready.
* List the BIP in [[README.mediawiki]]
The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and update BIP headers as appropriate.
BIP editors may also, at their option, unilaterally make and merge strictly-editorial changes to BIPs, such as correcting misspellings, fixing broken links, etc.
==BIP format and structure==
===Specification===
BIPs should be written in mediawiki or markdown format.
Each BIP should have the following parts:
* Preamble -- Headers containing metadata about the BIP ([[#BIP header preamble|see below]]).
* Abstract -- A short (~200 word) description of the technical issue being addressed.
* Copyright -- The BIP must be explicitly licensed under acceptable copyright terms ([[#BIP licensing|see below]]).
* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms.
* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the BIP solves.
* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
* Backwards compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities.
* Reference implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Bitcoin protocol.
====BIP header preamble====
Each BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
<pre>
BIP: <BIP number, or "?" before being assigned>
* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
Title: <BIP title; maximum 44 characters>
Author: <list of authors' real names and email addrs>
* Discussions-To: <email address>
* Comments-Summary: <summary tone>
Comments-URI: <links to wiki page for comments>
Status: <Draft | Active | Proposed | Deferred | Rejected |
Withdrawn | Final | Replaced | Obsolete>
Type: <Standards Track | Informational | Process>
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
License: <abbreviation for approved license(s)>
* License-Code: <abbreviation for code under different approved license(s)>
* Post-History: <dates of postings to bitcoin mailing list, or link to thread in mailing list archive>
* Requires: <BIP number(s)>
* Replaces: <BIP number>
* Superseded-By: <BIP number>
</pre>
The Layer header (only for Standards Track BIPs) documents which layer of Bitcoin the BIP applies to.
See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
The Author header lists the names and email addresses of all the authors/owners of the BIP.
The format of the Author header value must be
Random J. User <address@dom.ain>
If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.
While a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists.
The Type header specifies the type of BIP: Standards Track, Informational, or Process.
The Created header records the date that the BIP was assigned a number, while Post-History is used to record when new versions of the BIP are posted to bitcoin mailing lists.
Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.
Post-History is permitted to be a link to a specific thread in a mailing list archive.
BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on.
BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete.
====Auxiliary Files====
BIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that BIP, or must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png").
==BIP types==
There are three kinds of BIP:
* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. Standards Track BIPs consist of two parts, a design document and a reference implementation.
* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational BIPs or follow their advice.
* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
==BIP status field==
===Specification===
The typical paths of the status of BIPs are as follows:
<img src="bip-0002/process.png"></img>
Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
A BIP editor may also change the status to Deferred when no progress is being made on the BIP.
A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.
A Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
A process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.
====Progression to Final status====
A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork might have majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month.
API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications.
Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/bitcoin-wallet/bitcoin-wallet/blob/master/wallet/README.specs.md Bitcoin Wallet for Android's wallet/README.specs.md file].
These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.
===Rationale===
Why is this necessary at all?
* BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. As a result, many BIPs with significant real-world use have been left as Draft or Proposed status longer than appropriate. By giving objective criteria to judge the progression of BIPs, this proposal aims to help keep the Status accurate and up-to-date.
How is the entire Bitcoin economy defined by people selling goods/services and holders?
* For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price.
Why aren't <x> included in the economy?
* Some entities may, to some degree, also be involved in offering goods and/or services in exchange for bitcoins, thus in that capacity (but not their capacity as <x>) be involved in the economy.
* Miners are not included in the economy, because they merely *rely on* others to sell/spend their otherwise-worthless mined produce. Therefore, they must accept everyone else's direction in deciding the consensus rules.
* Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges.
* Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not.
But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision?
* This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to force others to use it. The BIP process does not aim to be a kind of forceful "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards, which people may voluntarily adopt or not. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
What if a single merchant wishes to block a hard-fork?
* This BIP addresses only the progression of the BIP Status field, not the deployment of the hard-fork (or any other change) itself.
* Regardless, one shop cannot operate in a vacuum: if they are indeed alone, they will soon find themselves no longer selling in exchange for bitcoin payments, as nobody else would exist willing to use the previous blockchain to pay them. If they are no longer selling, they cease to meet the criteria herein which enables their veto.
How about a small number of merchants (maybe only two) who sell products to each other?
* In this scenario, it would seem the previous Bitcoin is alive and working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP.
How can economic agreement veto a soft-fork?
* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork.
What happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later?
* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork.
What is the ideal percentage of listening nodes needed to adopt peer services proposals?
* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.
Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer BIPs, before they become Final?
* If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed.
* Even if there are only two projects rather than more, some standard coordination between them exists.
What if a BIP is proposed that only makes sense for a single specific project?
* The BIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a BIP in the first place.
==BIP comments==
===Specification===
Each BIP should, in its preamble, link to a public wiki page with a summary tone of the comments on that page.
Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page.
The comments page should generally only be used to post final comments for a completed BIP.
If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "Comments" namespace.
For example, the link for BIP 1 will be https://github.com/bitcoin/bips/wiki/Comments:BIP-0001 .
Comments posted to this wiki should use the following format:
<Your opinion> --<Your name>, <Date of posting, as YYYY-MM-DD>
BIPs may also choose to list a second forum for BIP comments, in addition to the BIPs wiki.
In this case, the second forum's URI should be listed below the primary wiki's URI.
After some time, the BIP itself may be updated with a summary tone of the comments.
Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances and other summaries may be used as needed:
* No comments yet.
* Unanimously Recommended for implementation
* Unanimously Discourage for implementation
* Mostly Recommended for implementation, with some Discouragement
* Mostly Discouraged for implementation, with some Recommendation
For example, the preamble to BIP 1 might be updated to include the line:
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
https://some-other-wiki.org/BIP_1_Comments
These fields must follow the "Discussions-To" header defined in BIP 1 (if that header is not present, it should follow the position where it would be present; generally this is immediately above the Status header).
To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
===Rationale===
What is the purpose of BIP comments?
* Various BIPs have been adopted (the criteria required for "Final" Status) despite being considered generally inadvisable. Some presently regard BIPs as a "good idea" simply by virtue of them being assigned a BIP number. Due to the low barrier of entry for submission of new BIPs, it seems advisable for a way for reviewers to express their opinions on them in a way that is consumable to the public without needing to review the entire development discussion.
Will BIP comments be censored or limited to particular participants/"experts"?
* Participants should freely refrain from commenting outside of their area of knowledge or expertise. However, comments should not be censored, and participation should be open to the public.
==BIP licensing==
===Specification===
New BIPs may be accepted with the following licenses. Each new BIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below.
For example, a preamble might include the following License header:
License: BSD-2-Clause
GNU-All-Permissive
In this case, the BIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement.
It is also possible to license source code differently from the BIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
For example, a preamble specifying the optional License-Code header might look like:
License: BSD-2-Clause
GNU-All-Permissive
License-Code: GPL-2.0+
In this case, the code in the BIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer.
If the code were to be available under *only* version 2 exactly, the "+" symbol should be removed from the license abbreviation.
For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent).
License-Code: GPL-2.0 # This refers to GPL v2.0 *only*, no later license versions are acceptable.
License-Code: GPL-2.0+ # This refers to GPL v2.0 *or later*.
License-Code: GPL-3.0 # This refers to GPL v3.0 *only*, no later license versions are acceptable.
License-Code: GPL-3.0+ # This refers to GPL v3.0 *or later*.
In the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term "Complex". In all cases, details of the licensing terms must be provided in the Copyright section of the BIP.
BIPs are not required to be *exclusively* licensed under approved terms, and may also be licensed under unacceptable licenses *in addition to* at least one acceptable license.
In this case, only the acceptable license(s) should be listed in the License and License-Code headers.
====Recommended licenses====
* BSD-2-Clause: [https://opensource.org/license/BSD-2-Clause OSI-approved BSD 2-clause license]
* BSD-3-Clause: [https://opensource.org/license/BSD-3-Clause OSI-approved BSD 3-clause license]
* CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
* FSFAP: [https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html FSF All Permissive License]
In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
====Not recommended, but acceptable licenses====
* Apache-2.0: [https://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
* BSL-1.0: [https://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
* CC-BY-4.0: [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
* CC-BY-SA-4.0: [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
* MIT: [https://opensource.org/license/MIT The MIT License]
* AGPL-3.0+: [https://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
* FDL-1.3: [https://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3]
* GPL-2.0+: [https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
* LGPL-2.1+: [https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
====Not acceptable licenses====
All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal unless a later BIP extends this one to add them.
However, BIPs predating the acceptance of this BIP were allowed under other terms, and should use these abbreviation when no other license is granted:
* OPUBL-1.0: [https://opencontent.org/openpub/ Open Publication License, version 1.0]
* PD: Released into the public domain
===Rationale===
BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient?
* The OPUBL-1.0 is generally regarded as obsolete, and not a license suitable for new publications.
* Many are unfamiliar with the OPUBL-1.0 terms, and may just prefer to use the public domain rather than license under uncertain terms.
* The OPUBL-1.0 license terms allowed for the author to prevent publication and derived works, which was widely considered inappropriate for Bitcoin standards.
* Public domain is not universally recognised as a legitimate action, thus it is inadvisable.
Why are there software licenses included?
* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.
* Despite this, not all software licenses would be acceptable for content included in BIPs.
Why is Public Domain no longer acceptable for new BIPs?
* In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the BIP simply copyrighted with no redistribution or modification allowed at all.
==Changes from BIP 1==
* Acceptable licenses are entirely rechosen, allowing a wide variety of open licenses, while prohibiting the problematic older choices.
* Accepted Status has been renamed to Proposed.
* An implementation is now required (when applicable) before BIPs can proceed to Proposed Status.
* BIP Comments are newly introduced.
* The License preamble headers have been added.
* The Layer header is included from BIP 123.
* Non-image auxiliary files are permitted in the bip-XXXX subdirectory.
* Email addresses are now required for authors.
* The Post-History header may be provided as a link instead of a simple date.
* The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions.
==See Also==
* [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]
* [[bip-0123.mediawiki|BIP 123: BIP Classification]]
* [https://tools.ietf.org/html/rfc7282 RFC 7282: On Consensus and Humming in the IETF]
================================================
FILE: bip-0003.md
================================================
```
BIP: 3
Title: Updated BIP Process
Authors: Murch <murch@murch.one>
Status: Deployed
Type: Process
Assigned: 2025-01-09
License: BSD-2-Clause
Discussion: https://github.com/murchandamus/bips/pull/2
https://gnusha.org/pi/bitcoindev/59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de/#t
Version: 1.4.0
Requires: 123
Replaces: 2
```
## Abstract
This _Bitcoin Improvement Proposal (BIP)_ provides information about the preparation of BIPs and policies relating to
the publication of BIPs. It replaces [BIP 2](bip-0002.mediawiki) with a streamlined process, and may be amended to
address the evolving needs of the BIP process.
## Motivation
BIP 2 was written in 2016.
This BIP revisits aspects of the BIP 2 process
that did not achieve broad adoption, reduces the judgment calls assigned to the BIP Editor role, delineates the
BIP types more clearly, and generalizes the BIP process to fit the community’s use of the repository.
## Fundamentals
### What is a BIP?
BIPs are improvement proposals for Bitcoin. The main topic is information and technologies that support and expand the utility of the Bitcoin
currency. Most BIPs provide a concise, self-contained, technical description of one new concept, feature, or standard.
Some BIPs describe processes, implementation guidelines, best practices, incident reports (e.g.,
[BIP 50](bip-0050.mediawiki)), or other information relevant to the Bitcoin community. However, any topics related to
the Bitcoin protocol, peer-to-peer network, and client software may be acceptable.
BIPs are intended to be a means for proposing new protocol features, coordinating client standards, and
documenting design decisions that have gone into implementations. BIPs may be submitted by anyone, provided the
content is of high quality, e.g., does not waste the community’s time.
The scope of the BIPs
repository is limited to BIPs that do not oppose the fundamental principle that Bitcoin constitutes a peer-to-peer
electronic cash system for the Bitcoin currency.
### BIP Ownership
Each BIP is primarily owned by its authors and represents the authors’ opinion or recommendation. The authors are
expected to foster discussion, address feedback and dissenting opinions, and, if applicable, advance the adoption of
their proposal within the Bitcoin community. As a BIP progresses through the workflow, it becomes increasingly
co-owned by the Bitcoin community.
#### Authors and Deputies
Authors may want additional help with the BIP process after writing an initial draft. In that case, they may assign
one or more Deputies to their BIP. Deputies are stand-in owners of a BIP who were not involved in writing the
document. They support the authors in advancing the proposal, or act as a point of contact for the BIP in the absence of the
authors. Deputies may perform the role of Authors for any aspect of the BIP process unless overruled by an Author.
Deputies share ownership of the BIP at the discretion of the Authors.
### What is the Significance of BIPs?
BIPs do not define what Bitcoin is: individual BIPs do not represent Bitcoin community consensus or a general
recommendation for implementation. A BIP represents a personal recommendation by the BIP authors to the Bitcoin
community. Some BIPs may never be adopted. Some BIPs may be adopted by one or more Bitcoin clients or other related
software. Some may even end up changing the consensus rules that the Bitcoin ecosystem jointly enforces.
### What is the Purpose of the BIPs Repository?
The [BIPs repository](https://github.com/bitcoin/bips/) serves as a publication medium and archive for mature proposals.
Through its high visibility, it facilitates the community-wide consideration of BIPs and provides a well-established
source to retrieve the latest version of any BIP. The repository transparently records all changes to each BIP and
allows any community member to retain a complete copy of the archive easily.
The BIPs repository neither tracks community sentiment[^acceptance] nor ecosystem adoption[^adoption] of BIPs beyond
the brief overview provided via the BIP status (see [Workflow](#workflow) below).
Proposals are published in this repository if they are on-topic and fulfill the editorial criteria.
No formal or informal decision body governs Bitcoin development or decides adoption of BIPs.
## BIP Format and Structure
### Specification
Authors may choose to submit BIPs in MediaWiki or Markdown[^markdown] format.
Each BIP must have a _Preamble_, an _Abstract_, a _Copyright_, and a _Motivation_ section. Authors should consider all issues in the
following list and address each as appropriate.
* Preamble — Headers containing metadata about the BIP (see the section [BIP Header Preamble](#bip-header-preamble)
below).
* Abstract — A short description of the issue being addressed.
* Motivation — Why is this BIP being written? Clearly explain how the existing situation presents a problem and why the proposed idea resolves the
issue or improves upon the current situation.
* Specification — The technical specification should describe the syntax and semantics of any new feature. The
specification should be detailed enough to enable any Bitcoin project to create an interoperable implementation.
* Rationale — The rationale fleshes out the specification by describing what inspired the design and why particular
design decisions were made. It should describe related work and alternate designs that were considered. The rationale
should record relevant objections or important concerns that were raised and addressed as this proposal was developed.
* Backward Compatibility — Any BIP that introduces incompatibilities must include a section describing these incompatibilities and their severity as well as provide instructions on how
implementers and users should deal with these incompatibilities.
* Reference Implementation — Where applicable, a reference implementation, test vectors, and documentation must be
finished before the BIP can be given the status "Complete". Test vectors must be provided in the BIP or
as auxiliary files (see [Auxiliary Files](#auxiliary-files)) under an acceptable license. The reference implementation
can be provided in the BIP, as an auxiliary file, or per linking another code reference that is expected to remain
available permanently such as a pull request, a dedicated branch, a new repository, or similar.
* Changelog — A section to track modifications to a BIP after reaching Complete status.
* Copyright — The BIP must be placed under an acceptable license (see [BIP Licensing](#bip-licensing) below).
#### BIP Header Preamble
Each BIP must begin with an [RFC 822-style header preamble](https://www.w3.org/Protocols/rfc822/). The headers must
appear in the following order. Headers marked with "\*" are optional. All other headers are required.
##### Overview
```
BIP: <BIP number, or "?" before assignment>
* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
Title: <BIP title (≤ 50 characters)>
Authors: <Authors’ names and email addresses>
* Deputies: <Deputies’ names and email addresses>
Status: <Draft | Complete | Deployed | Closed>
Type: <Specification | Informational | Process>
Assigned: <Date of number assignment (yyyy-mm-dd), or "?" before assignment>
License: <SPDX License Expression>
* Discussion: <Noteworthy discussion threads in "yyyy-mm-dd: URL" format>
* Version: <MAJOR.MINOR.PATCH>
* Requires: <BIP number(s)>
* Replaces: <BIP number(s)>
* Proposed-Replacement: <BIP number(s)>
```
##### Header Descriptions
* BIP — The assigned number of the BIP (without leading zeros). Please use "?" before a number has been assigned by the BIP Editors.
* Layer — The layer of Bitcoin the BIP applies to using the BIP classification defined in [BIP 123](bip-0123.mediawiki).
* Authors — The names (or pseudonyms) and email addresses of all authors of the BIP. The format of each authors header
value must be
Random J. User <address@dom.ain>
Multiple authors are recorded on separate lines:
Authors: Random J. User <address@dom.ain>
Anata Sample <anata@domain.example>
* Deputies — Additional owners of the BIP that are not authors. The Deputies header uses the same format as the
Authors header. See the [BIP Ownership](#bip-ownership) section above.
* Status — The stage of the workflow of the proposal. See the [Workflow](#workflow) section below.
* Type — See the [BIP Types](#bip-types) section below for a description of the three BIP types.
* Assigned – The date a BIP was assigned its number. Please use "?" before a number has been assigned by the BIP Editors.
* License — The License header specifies SPDX License Expressions describing the terms under which the
BIP and its auxiliary files are available. See the [BIP Licensing](#bip-licensing) section below.
* Discussion — The Discussion header points the audience to relevant discussions of the BIP, e.g., the mailing list
thread in which the idea for the BIP was discussed, a thread where a new version of the BIP was presented, or relevant
discussion threads on other platforms. Entries take the format "yyyy-mm-dd: URL", e.g., `2009-01-09:
https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html`, using the date and URL of the start of the
conversation. Multiple discussions should be listed on separate lines.
* Version — The current version number of this BIP. See the [Changelog](#changelog-section-and-version-header) section below.
* Requires — A list of existing BIPs the new proposal depends on. If multiple BIPs
are required, they should be listed in one line separated by a comma and space (e.g., "1, 2").
* Replaces[^proposes-to-replace] — BIP authors may put the numbers of one or more prior BIPs in the Replaces header to recommend that their
BIP succeeds, supersedes, or renders obsolete those prior BIPs.
* Proposed-Replacement[^superseded-by-proposed-replacement] — When a later BIP indicates that it intends to supersede an
existing BIP, the later BIP’s number is added to the Proposed-Replacement header of the existing BIP to indicate the
potential successor BIP.
#### Auxiliary Files
BIPs may include auxiliary files such as diagrams and source code. Auxiliary files must be included in a subdirectory
for that BIP named `bip-XXXX`, where "XXXX" is the BIP number zero-padded to four digits. File names in the subdirectory
do not need to adhere to a specific convention.
### BIP Types
* A **Specification BIP** defines a set of technical rules describing a new feature or affecting the interoperability of implementations. The
distinguishing characteristic of a Specification BIP is that it can be implemented, and implementations can be compliant with
it. Specification BIPs must have a Specification section, must have a Backward Compatibility section (if incompatibilities are introduced), and can only be advanced to Complete after they contain or refer to a reference implementation and test vectors.
* An **Informational BIP** describes a Bitcoin design issue, or provides general guidelines or other information to the
Bitcoin community.
* A **Process BIP** describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process
BIPs are like Specification BIPs, but apply to topics other than the Bitcoin protocol and Bitcoin implementations.
They often require community consensus and are typically binding for the corresponding process. Examples include
procedures, guidelines, and changes to decision-making processes such as the BIP process.
## Workflow
The BIP process starts with a new idea for Bitcoin. Each potential BIP must have authors—people who write the BIP,
gather feedback, shepherd the discussion in the appropriate forums, and finally recommend a mature proposal to the
community.
### Ideation
After having an idea, the authors should evaluate whether it meets the criteria to become a BIP, as described in this
BIP. The idea must be of interest to the broader community or relevant to multiple software projects. Minor improvements
and matters concerning only a single project usually do not require standardization and should instead be brought up directly to
the relevant project.
The authors should first research whether their idea has been considered before. Ideas in Bitcoin are often rediscovered,
and prior related discussions may inform the authors of the issues that may arise in its progression. After some investigation,
the novelty and viability of the idea should be tested by posting a new, dedicated thread about the idea to the [Bitcoin Development Mailing
List](https://groups.google.com/g/bitcoindev). Prior correspondence can be found in the [mailing list
archive](https://gnusha.org/pi/bitcoindev/).
It is recommended that authors establish before or at the start of working on a draft whether their idea may be of
interest to the Bitcoin community.
Authors should avoid opening a pull request with a BIP draft out of the blue.
Vetting an idea publicly before investing time and effort to formally describe the idea is meant to save time for both the authors and
the community. Not only may someone point out relevant discussion topics that were missed in the authors’
research, or that an idea is guaranteed to be rejected based on prior discussions, but describing an idea publicly also
tests whether it is of interest to more people beside the authors.
As a first sketch of the proposal is taking shape, the authors should present it to the [Bitcoin Development Mailing
List](https://groups.google.com/g/bitcoindev). This gives the authors a chance to collect initial feedback and address
fundamental concerns. If the authors wish to work in public on the proposal at this stage, it is recommended that they
open a pull request against one of their forks of the BIPs repository instead of the main BIPs repository.
It is recommended that complicated proposals be split into separate BIPs that each focus on a specific component of the
overall proposal.
### Progression through BIP Statuses
The following sections refer to BIP Status field values. The BIP Status field is defined in the Header Preamble
specification above.
#### Draft
After fleshing out the proposal further and ensuring that it is of high quality and properly formatted, the authors
should open a pull request to the [BIPs repository](https://github.com/bitcoin/bips). The document must adhere to the
formatting requirements specified above and should be provided as a file named with a working title of the form
"bip-title.[md|mediawiki]". Only BIP Editors may assign BIP numbers. Until one has done so, authors should refer to their
BIP by name only.
BIPs that (1) adhere to the formatting requirements, (2) are on-topic, and (3) have materially progressed beyond the
ideation phase, e.g., by generating substantial public discussion and commentary from diverse contributors, by
independent Bitcoin projects working on adopting the proposal, or by the authors working for an extended period toward
improving the proposal based on community feedback, will be assigned a number by a BIP Editor. A number may be
considered assigned only after it has been publicly announced in the pull request by a BIP Editor. The BIP Editors should
not assign a number when they perceive a proposal being met with lack of interest: number assignment facilitates the
distributed discussion of ideas, but before a proposal garners some interest in the Bitcoin community, there is no need
to refer to it by a number.
Proposals are also not ready for number assignment if they duplicate efforts, disregard formatting rules, are too
unfocused or too broad, fail to provide proper motivation, fail to address backward compatibility where necessary, or
fail to specify the feature clearly and comprehensively. Reviewers and BIP Editors should provide guidance on how the
proposal may be improved to progress toward readiness. Pull requests that are proposing off-topic ideas or
have stopped making progress may be closed.
When the proposal is ready and has been assigned a number, a BIP Editor will merge it into the BIPs repository. After the
BIP has been merged to the repository, its main focus should no longer shift significantly, even while the authors may
continue to update the proposal as necessary. Updates to merged documents by the authors should also be submitted as
pull requests.
#### Complete[^complete]
When the authors have concluded all planned work on their proposal, are confident that their BIP represents a net
improvement, is clear, comprehensive, and is
ready for adoption by the Bitcoin community, they may update the BIP’s status to Complete to indicate that they
recommend adoption, implementation, or deployment of the BIP. Where applicable, the authors must ensure that any
proposed specification is solid, not unduly complicated, and definitive. Specification BIPs must come with or refer to a working reference implementation and comprehensive test vectors before they can be moved to Complete. Subsequently, the BIP’s content should only be
adjusted in minor details, e.g., to improve language, clarify ambiguities, backfill omissions in the specification, add
test vectors for edge cases, or address other issues discovered as the BIP is being adopted.
A Complete BIP can only move to Deployed or Closed. Any necessary changes to the specification should be minimal and
interfere as little as possible with ongoing adoption. If a Complete BIP is found to need substantial functional
changes, it may be preferable to move it to Closed[^new-BIP], and to start a new BIP with the changes instead.
Otherwise, it could cause confusion as to what being compliant with the BIP means.
A BIP may remain in the Complete status indefinitely unless its authors or deputies decide to move it to Closed or it is advanced to
Deployed.
Complete is the final status for most successful Informational BIPs.
#### Deployed
A Complete BIP should only be moved to Deployed once it is settled: after its approach has solidified, its
Specification has been put through its paces, feedback from early adopters has been processed, and amendments to the BIP have stopped.
Then, a BIP may be advanced to Deployed upon request by any community member with evidence[^evidence] that
the BIP is in active use. Convincing evidence includes for example: an established project having deployed support
for the BIP in mainnet software releases, a soft fork proposal’s activation criteria having been met on the network, or
rough consensus for the BIP having been demonstrated.
Once Deployed, the BIP is considered final.
Any modifications to the BIP beyond bug fixes, other minor amendments, additions to the test vectors, or editorial
changes should be avoided.
Any breaking changes to the BIP’s Specification should be proposed as a new separate BIP.[^new-BIP]
##### Process BIPs
A Process BIP may change status from Complete to Deployed when it achieves rough consensus on the Bitcoin Development Mailing List. A
proposal is said to have rough consensus if its advancement has been open to discussion on the mailing list for at least
one month, the discussion achieved meaningful engagement, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections
may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be
given in such circumstances. Deployed Process BIPs may be modified indefinitely as long as a proposed modification has
rough consensus per the same criteria.[^living-documents]
#### Closed[^closed]
A BIP that is of historical interest only, and is not being actively worked on, promoted or in active use, should be
marked as Closed. The reason for moving the
proposal to (or from) Closed should be recorded in the Changelog section in the same commit that updates the status.
BIPs do not get deleted, they are retained even after being updated to Closed.
Transitions involving the Closed state are:
##### Draft ↦ Closed
BIP authors may decide on their own to change their BIP’s status from Draft to Closed. If a Draft BIP stops making
progress, sees accumulated feedback unaddressed, or otherwise appears stalled for a year, anyone may propose the BIP
status be updated to Closed. The BIP is then updated to Closed unless the authors assert that they intend to continue work within four weeks of being contacted.
##### Complete ↦ Closed
BIPs that had attained the Complete status, i.e., that had been recommended for adoption, may be moved to Closed per the
authors’ announcement to the Bitcoin Development Mailing List[^bip-announcements-to-list]. However, if someone volunteers to adopt the proposal
within four weeks, they become the BIP's author or deputy (see [Transferring BIP Ownership](#transferring-bip-ownership) below), and the BIP will
remain Complete instead.
##### Deployed ↦ Closed
A BIP may evolve from Deployed to Closed when it is no longer in active use. Any community member may initiate this
Status update by announcing it to the mailing list[^bip-announcements-to-list], and proceed if no objections have been raised for four weeks.
##### Closed ↦ Draft
The Closed status is generally intended to be a final status for BIPs,
and if BIP authors decide to make another attempt at a previously Closed BIP, it is generally recommended to create a new
proposal. (Obviously, the authors may borrow any amount of inspiration or actual text from any prior BIPs as licensing
permits.) The authors should take special care to address the issues that caused the prior attempt’s abandonment. Even
if the prior attempt had been assigned a number, the new BIP will generally be assigned a distinct number. However, if it is
obvious that the new attempt directly continues work on the same idea, it may be reasonable to return the
Closed BIP to Draft status.
### Changelog Section and Version Header
To help implementers understand updates to a BIP, any changes after it has reached Complete must be tracked with version,
date, and description in a Changelog section sorted by most recent version first. The version number is inspired by semantic versioning (MAJOR.MINOR.PATCH).
The MAJOR version is incremented if changes to the BIP’s Specification are introduced that are incompatible with prior
versions (which should be rare after a BIP is Complete, and only happen in well-grounded exceptional cases to a BIP that
is Deployed). The MINOR version is incremented whenever the specification of the BIP is changed or extended in a
backward-compatible way. The PATCH version is incremented for other changes to the BIP that are noteworthy (bug fixes,
test vectors, important clarifications, etc.). Version 1.0.0 is used to label the promotion to
Complete. A Changelog section may be introduced during the Draft phase to record significant changes (using versions 0.x.y).
Example:
> __Changelog__
>
> * __2.0.0__ (2025-01-22):
> * Introduce a breaking change in the specification to fix a bug.
> * __1.1.0__ (2025-01-17):
> * Add a backward compatible extension to the BIP.
> * __1.0.1__ (2025-01-15):
> * Clarify an edge case and add corresponding test vectors.
> * __1.0.0__ (2025-01-14):
> * Complete planned work on the BIP.
After a BIP receives a Changelog, the
Preamble must indicate the latest version in the Version header. The Changelog highlights revisions to BIPs to human readers. A single
BIP shall not recommend more than one variant of an idea at the same time. A different or
competing variant of an existing BIP must be published as a separate BIP.
### Adoption of Proposals
The BIPs repository does not track the sentiment on proposals and does not track the adoption of BIPs beyond whether they
are in active use or not. It is not intended for BIPs to list additional implementations beyond the reference
implementation: the BIPs repository is not a signpost where to find implementations.[^OtherImplementations] After a BIP
is advanced to Complete, it is up to the Bitcoin community to evaluate, adopt, ignore, or reject a BIP. Individual
Bitcoin projects are encouraged to publish a list of BIPs they implement. A good example of this at the time of writing
this BIP can be observed in Bitcoin Core’s [doc/bips.md](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md)
file.
### Transferring BIP Ownership
It occasionally becomes necessary to transfer ownership of BIPs to new owners. In general, it would be preferable to
retain the original authors of the transferred BIP, but that is up to the original authors. A good reason to transfer
ownership is because the original authors no longer have the time or interest in updating it or following through with
the BIP process, or are unreachable or unresponsive. A bad reason
to transfer ownership is because someone doesn't agree with the direction of the BIP. The community tries to build
consensus around a BIP, but if that's not possible, rather than fighting over control, the dissenters should supply a
competing BIP.
If someone is interested in assuming ownership of a BIP, they should send an email asking to take over, addressed to the
original authors, the BIP Editors, and the Bitcoin Development Mailing List[^bip-announcements-to-list]. If the authors are unreachable or do not respond in a timely
manner (e.g., four weeks), the BIP Editors will make a unilateral decision whether to appoint the applicants as
[Authors or Deputies](#authors-and-deputies) (which may be amended should the original authors make a delayed reappearance).
## BIP Licensing
The Bitcoin project develops a global peer-to-peer digital cash system. Open standards are indispensable for continued
interoperability. Open standards reduce friction, and encourage anybody and everyone to contribute, compete, and
innovate on a level playing field. Only freely licensed contributions are accepted to the BIPs repository.
### Specification
Each new BIP must specify in two ways under which license terms it is made available. First, it must specify an [SPDX
License Expression](https://spdx.dev/ids/) in the License field in the preamble. Second, it must include a matching
Copyright section, possibly providing further details on licensing.
For example, a preamble might include the following License header:
License: CC0-1.0 OR MIT
In this case, the BIP (including all auxiliary files) is made available under the terms of both CC0 1.0 Universal as well as the
MIT License, and anyone may modify and redistribute it provided they comply with the terms of
*either* license, at their option. In other words, the license list is an "OR choice", not an "AND also" requirement. See the [SPDX
documentation](https://spdx.dev/ids/) and the [SPDX License List](https://spdx.org/licenses/) for further details.
Wherever different from those specified in the License header, an auxiliary file or directory should specify the license terms under which it is made available as is common in
software (e.g., with a [`SPDX-License-Identifier: <SPDX License Expression>` comment](https://spdx.dev/ids/),
a license header, or a LICENSE/COPYING file). Such exceptions should also be mentioned in the Copyright section. It is recommended to make any test vectors available
under CC0-1.0 or FSFAP in addition to any other licenses to allow anyone to copy test vectors into their
implementations without introducing license hindrances.
A few BIP2-era BIPs (98, 116, 117, 330, 340) have a no longer used "License-Code" header indicating the license terms applicable to auxiliary source code files. For such cases, please refer to BIP2.
It is recommended that source code included in a BIP (whether within the text or in auxiliary files) be licensed under the same license terms as the project it
is proposed to modify, if any. For example, changes intended for Bitcoin Core would ideally be licensed (also) under the MIT
License.
In all cases, details of the licensing terms must be provided in the Copyright section of the BIP.
#### Acceptable Licenses[^licenses]
Each new BIP must be made available under at least one acceptable license as listed below. BIPs are not required to be
*exclusively* licensed under approved terms, and may also be licensed under other licenses *in addition to* at least one
acceptable license.
In other words, a new BIP must specify an SPDX License Expression that is either "L" or equivalent to "L OR E" for some
acceptable license L from the following list and another SPDX License Expression E.
* BSD-2-Clause: [BSD 2-Clause License](https://opensource.org/license/BSD-2-Clause)
* BSD-3-Clause: [BSD 3-Clause License](https://opensource.org/license/BSD-3-Clause)
* CC0-1.0: [CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)
* FSFAP: [FSF All Permissive License](https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html)
* CC-BY-4.0: [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/)
* MIT: [The MIT License](https://opensource.org/license/MIT)
* MIT-0: [MIT No Attribution License](https://opensource.org/license/MIT-0)
* Apache-2.0: [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0)
* BSL-1.0: [Boost Software License 1.0](https://www.boost.org/LICENSE_1_0.txt)
#### Not Acceptable Licenses
All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal.
However, BIPs predating this proposal were accepted under other terms, and should use one of the following identifiers.
* LicenseRef-PD: Placed into the public domain
* OPUBL-1.0: [Open Publication License 1.0](https://opencontent.org/openpub/)
## BIP Editors
The current BIP Editors are:
* Bryan Bishop ([kanzure@gmail.com](mailto:kanzure@gmail.com))
* Jon Atack ([jon@atack.com](mailto:jon@atack.com))
* Luke Dashjr ([luke_bipeditor@dashjr.org](mailto:luke_bipeditor@dashjr.org))
* Mark "Murch" Erhardt ([murch@murch.one](mailto:murch@murch.one))
* Olaoluwa Osuntokun ([laolu32@gmail.com](mailto:laolu32@gmail.com))
* Ruben Somsen ([rsomsen@gmail.com](mailto:rsomsen@gmail.com))
### BIP Editor Responsibilities and Workflow
The BIP Editors subscribe to the Bitcoin Development Mailing List and watch the [BIPs
repository](https://github.com/bitcoin/bips).
When either a new BIP idea or an early draft is submitted to the mailing list, BIP Editors or other community members should comment in regard
to:
* Novelty of the idea
* Viability, utility, and relevance of the concept
* Readiness of the proposal
* On-topic for the Bitcoin community
Discussion in pull request comments can often be hard to follow as feedback gets marked as resolved when it is addressed
by authors. Substantive discussion of ideas may be more accessible to a broader audience on the mailing list, where it
is also more likely to be retained by the community memory.
If the BIP needs more work, an editor should ensure that constructive, actionable feedback is provided to the authors
for revision. Once the BIP is ready it should be submitted as a "pull request" to the [BIPs
repository](https://github.com/bitcoin/bips) where it may get further feedback.
For each new BIP pull request that comes in, an editor checks the following:
* The idea has been previously proposed to the Bitcoin Development Mailing List and discussed there
* The described idea is on-topic for the repository
* A draft of the BIP by one of the authors has been previously discussed on the Bitcoin Development Mailing List
* Title accurately describes the content
* Proposal is of general interest and/or pertains to more than one Bitcoin project/implementation
* Document is properly formatted
* Licensing terms are acceptable
* Motivation, Rationale, and Backward Compatibility have been addressed
* Specification provides sufficient detail for implementation
* The defined Layer and Type headers must be correctly assigned for the given specification
* The BIP is ready: it is comprehensible, technically feasible and sound, and all aspects are addressed as necessary
Editors do NOT evaluate whether the proposal is likely to be adopted.
Then, a BIP Editor will:
* Assign a BIP number in the pull request
* Ensure that the BIP is listed in the [README](README.mediawiki)
* Merge the pull request when it is ready
The BIP Editors are intended to fulfill administrative and editorial responsibilities. The BIP Editors monitor BIP
changes, and update BIP headers as appropriate.
BIP Editors may also, at their option, unilaterally make and merge strictly editorial changes to BIPs, such as
correcting misspellings, mending grammar mistakes, fixing broken links, etc. as long as they do not change the meaning or conflict with the
original intent of the authors. Such a change must be recorded in the Changelog if it’s noteworthy per the criteria
mentioned in the [Changelog](#changelog) section.
## Backward Compatibility
### Changes from BIP 2
#### Workflow
- Status field values are reduced from nine to four:
- Deferred, Obsolete, Rejected, Replaced, and Withdrawn are gathered up into Closed.[^closed]
- Final and Active are collapsed into Deployed.
- Proposed is renamed to Complete.
- The remaining statuses are Draft, Complete, Deployed, and Closed.
- The comment system is abolished.[^comments]
- A BIP in Draft or Complete status may no longer be closed solely on grounds of not making progress for three years.[^rejection]
- A BIP in Draft status may be updated to Closed status if it appears to have stopped making progress for at least a
year and its authors do not assert within four weeks of being contacted that they intend to continue working on it.
- Complete BIPs can only be moved to Closed by its authors and may remain in Complete indefinitely.
- A Changelog section is introduced to track significant changes to BIPs after they have reached the Complete status.
- Process BIPs are living documents that do not ossify and may be modified indefinitely.
- Some judgment calls previously required from BIP Editors are reassigned either to the BIP authors or the repository’s
audience.
#### BIP Format
- The Standards Track type is superseded by the similar Specification type.[^standard-track]
- Many sections are declared optional; it is up to the authors and reviewers to judge whether all relevant topics have
been comprehensively addressed and which topics require a designated section to do so.
- "Other Implementations" sections are discouraged.[^OtherImplementations]
- Auxiliary files are only permitted in the corresponding BIP’s subdirectory, as no one used the alternative of labeling
them with the BIP number.
- Tracking of community consensus and adoption is out of scope for the BIPs repository, except to determine
whether a BIP is in active use for the move into or out of the Deployed status.
- The distinction between recommended and acceptable licenses was dropped.
- Most licenses that have not been used in the BIP process have been dropped from the list of acceptable licenses.
#### Preamble
- "Comments-URI" and "Comments-Summary" headers are dropped from the preamble.[^comments]
- The "Superseded-By" header is replaced with the "Proposed-Replacement" header.
- The "Post-History" header is replaced with the "Discussion" header.
- The optional "Version" header is introduced.
- The "Discussions-To" header is dropped, as it has never been used in any BIP.
- The "License-Code" header has been sunset, as it was used by only five BIPs (98, 116, 117, 330, 340) and created more ambiguity than clarity.
- The "Created" header is renamed to "Assigned", as the header’s value is the date of number assignment.[^assigned]
- Introduce Deputies and optional "Deputies" header.
- The BIP "Title" header may now contain up to 50 characters (increased from 44 in BIP 2).
- The "Layer" header is optional for Specification BIPs or Informational BIPs, as it does not make sense for all BIPs.[^layer]
- Rename the "Author" field to "Authors".
### Updates to Existing BIPs should this BIP be Activated
#### Previous BIP Process
This BIP replaces BIP 2 as the guideline for the BIP process.
#### BIP Types
Standards Track BIPs and eligible Informational BIPs are assigned the Specification type. The Standards Track type is
considered obsolete. Specification BIPs use the Layer header rules specified in [BIP 123](bip-0123.mediawiki).
#### Comments
The Comments-URI and Comments-Summary headers should be removed from all BIPs whose comment page in the wiki is empty.
For existing BIPs whose comment page has content, BIP Authors may keep both headers or remove both headers at their
discretion. It is recommended that existing wiki pages are not modified due to the activation of this BIP.
#### Status Field
After the activation of this BIP, the Status fields of existing BIPs that do not fit the specification in this BIP are
updated to the corresponding values prescribed in this BIP. BIPs that have had Draft status for extended periods will be
moved to Complete or Deployed as applicable in collaboration with their authors. The authors of incomplete Draft BIPs
will be contacted to learn whether the BIPs are still in progress toward Complete, and will otherwise be updated to
Closed as described in the [Workflow](#workflow) section above.
#### Authors Header
The Author header is replaced with the Authors header in all BIPs.
#### Discussion Header
The Post-History header is replaced with the Discussion header in all BIPs.
#### Proposed-Replacement Header
The Superseded-By header is replaced with the Proposed-Replacement header in all BIPs.
#### Licenses
Existing BIPs retain their license terms unchanged.
The License and License-Code headers of BIPs are updated to express those terms using SPDX License Expressions.
## Changelog
* __1.4.0__ (2025-12-09):
* Revert AI guidance, add Changelog section, broaden reference implementation formats, move Type header responsibility to authors, other editorial changes
* __1.3.1__ (2025-11-10):
* Reiterate that numbers are assigned by BIP Editors in pull requests
* __1.3.0__ (2025-10-22):
* Restrict use of AI/LLM tools, require original work.
* __1.2.1__ (2025-09-19):
* Clarify that idea should be discussed on dedicated mailing list thread
* __1.2.0__ (2025-09-19):
* Rename Created header to Assigned to clarify that it holds the date of number assignment
* __1.1.0__ (2025-07-18):
* Switch to SPDX License Expressions, drop License-Code header, and make editorial changes to BIP Licensing section.
* __1.0.1__ (2025-06-27):
* Improve description of acceptance, purpose of the BIPs repository, when Draft BIPs can be closed due to not
making progress, and make other minor improvements to phrasing.
* __1.0.0__ (2025-03-18):
* Complete planned work and move to Proposed.
## Copyright
This BIP is licensed under the [BSD-2-Clause License](https://opensource.org/licenses/BSD-2-Clause). Some content was
adapted from [BIP 2](bip-0002.mediawiki) which was also licensed under the BSD-2-Clause.
## Related Work
- [BIP 1: BIP Purpose and Guidelines](bip-0001.mediawiki)
- [BIP 2: BIP Process, revised](bip-0002.mediawiki)
- [BIP 123: BIP Classification](bip-0123.mediawiki)
- [RFC 822: Standard for ARPA Internet Text Messages](https://datatracker.ietf.org/doc/html/rfc822)
- [RFC 2223: Instructions to RFC Authors](https://datatracker.ietf.org/doc/html/rfc2223)
- [RFC 7282: On Consensus and Humming in the IETF](https://tools.ietf.org/html/rfc7282)
## Acknowledgements
We thank AJ Towns, Jon Atack, Jonas Nick, Larry Ruane, Pieter Wuille, Tim Ruffing, and others for their review,
feedback, and helpful comments.
## Rationale
[^assigned]: **Why was the Created header renamed to Assigned?**
Both BIP 1 and BIP 2 described the Created header as "date created on" in the preamble template, but followed that
up with "Created header records the date that the BIP was assigned a number" as the description of the field. This
has frequently led to confusion, with authors using the date of opening the pull request, the date they started
writing their proposal, the date of number assignment (as prescribed), or various other dates. Aligning the name of
the header and the text in the preamble template with the descriptions will reduce the confusion.
[^standard-track]: **Why was the Specification type introduced?**
The definitions of Informational and Standards Track BIPs caused some confusion in the past. Due to Informational
BIPs being described as optional, Standards Track BIPs were sometimes misunderstood to be generally recommended.
This has led to a number of BIPs that propose new features affecting interoperability of implementations being
assigned the Informational type. The situation is remedied by introducing a new _Specification BIP_ type that is
inclusive of any BIPs that can be implemented and affect interoperability of Bitcoin applications. Since all BIPs
are individual recommendations by the authors (even if some may eventually achieve endorsement by the majority of
the community), the prior reminder that Informational BIPs are optional is dropped.
[^comments]: **Why were comments, Comments-URI, and Comments-Summary removed from the process?**
The comments feature saw insignificant adoption. Few BIPs received any comments and barely any more than two with
only a handful of contributors commenting at all. This led to many situations in which one or two comments ended up
dominating the comment summary. While some of those comments may have been representative of broadly held opinions,
it also overstated the importance of individual comments directly in the Preamble of BIPs. As collecting feedback in
this accessible fashion failed, the new process puts the burden back on the audience to make their own evaluation.
[^layer]: **Why is the layer header now permitted for other BIP types?**
The layer header had already been used by many Informational BIPs, so the rule that it is only available to
Standards Track BIPs is dropped.
[^OtherImplementations]: **What is the issue with "Other Implementations" sections in BIPs?**
In the past, some BIPs had "Other Implementations" sections that caused frequent change requests to existing BIPs.
This put a burden on the BIP authors and BIP Editors, and frequently led to lingering pull requests due to the corresponding BIPs’
authors no longer participating in the process. Many of these alternative implementations eventually became
unmaintained or were low-quality to begin with. Therefore, "Other Implementations" sections are heavily discouraged.
[^complete]: **Why was the Proposed status renamed to Complete?**
Some reviewers of this BIP raised that in a process which outlines the workflow of Bitcoin Improvement _Proposals_
using "Proposed" as a status field value was overloading the term: clearly _proposals_ are proposed at all stages of
the process. "Complete" expresses that the authors have concluded planned work on all parts of the proposal and are
ready to recommend their BIP for adoption. The term "ready" was also considered, but considered too subjective.
[^rejection]: **Why can proposals remain in Draft or Complete indefinitely?**
The automatic 3-year timeout of BIPs has led to some disagreement in the past and seems unnecessary in cases where
the authors remain active in the community and still consider their idea worth pursuing. On the other hand,
Draft proposals that appear stale may be closed after only one year, which should achieve the main goal of
the original rule by limiting the effort and attention spent on proposals that never reach Complete.
[^closed]: **Why was the Closed Status introduced?**
The Closed Status provides value to the audience by indicating which documents are only of historical significance.
Previously, the process had Deferred, Obsolete, Rejected, Replaced, and Withdrawn, which all meant some flavor of
"work has stopped on this." The many statuses complicated the process, may have contributed to process fatigue, and
may have resulted in BIPs’ statuses not being maintained well. The author of this BIP feels that all of the
aforementioned can be represented by _Closed_ without significantly impacting the information quality of the
overview table. Where the many Status variants provided minuscule additional information, the simplification is more
valuable and the Changelog section now collects specific details.
[^acceptance]: **When is a BIP "accepted"?**
Many standards processes such as the PEPs or the IETF have a mechanism for a proposal to be formally accepted by
some council or committee. The BIP Process does not have such a decision body. Bitcoin development and "acceptance"
of BIPs emerges from the participation of stakeholders across the ecosystem, and refers to some vague notion of community
interest and support for a proposal.
BIP 2 had made an attempt to gather community feedback into comment summaries in BIPs directly. Given the low
participation and corresponding low information quality of the summaries that resulted from that feature, this BIP
instead intends to leave the evaluation of BIPs to the reviewers and users.
[^adoption]: **Why does the BIPs repository no longer track adoption?**
In the past, some BIPs maintained lists of projects that had implemented the BIP. These lists generated
noise for subscribers of the repository, often listed implementations of questionable quality, and quickly
grew outdated, therefore providing little value. The repository no longer tracks which projects have implemented
BIPs. Instead, it is recommended that projects publish a list of the BIPs they implement.
[^markdown]: **Which flavor of Markdown is allowed?**
The author of this proposal has no opinion on Markdown flavors, but recommends that proposals stick to the basic
Markdown syntax features commonly shared across Markdown dialects.
[^living-documents]: **Why are Process BIPs living documents?**
In the past years, the existing BIPs process has not always provided a clear approach to all situations. For
example, the content of BIP 2 appears to have been penned especially with fork proposals in mind. It seems clear
that Bitcoin development will evolve in many surprising ways in the future. Instead of mandating the effort of
writing a new process document every time new situations arise, it seems preferable to allow the process to adapt to
the concerns of the future in specific aspects. Therefore, Process BIPs are defined as living documents that remain
open to amendment. If a Process BIP requires large modifications or even a complete overhaul, a new BIP should be
preferred.
[^new-BIP]: **Why should the specification of an implemented BIP no longer be changed?**
After a Complete or Deployed BIP has been deployed by one or more implementations, breaking changes to the
specification could lead to a situation where multiple "compliant" implementations fail at being interoperable,
because they implemented different versions of the same BIP. Therefore, even changes to the specification of
Complete BIPs should be avoided, but Deployed BIPs should never be subject to breaking changes to their
specification.
[^bip-announcements-to-list]: **Why are some BIP status changes announced to the mailing list?**
The BIPs repository does not and cannot track who might be interested in or has deployed a BIP. While concerns were
raised that making announcements to the Bitcoin Developer Mailing List would introduce unnecessary noise, our
rationale is that 1) moving Complete and Deployed BIPs to the Closed status will be a rare occurrence, 2) status
updates will usually not generate a lot of discussion, 3) while the mailing list should preferably only used for
getting review for new BIPs, it is the only channel available to us that can be considered a public announcement to
the audience of the BIPs repository: even if the authors, implementers, or other parties interested in a BIP do not
see the announcement themselves, they may be made aware by someone that does see it.
[^superseded-by-proposed-replacement]: **Why is Superseded-By replaced with Proposed-Replacement?**
Reviewers asked who should get to decide whether a BIP is superseded in case of a disagreement among the authors of
the original BIP, the authors of the new BIP, the editors, or the community? This is addressed by making the
"Replaces" header part of the recommendation of the authors of the new document, and replacing the "Superseded-By"
header with the "Proposed-Replacement" header that lists any proposals that recommend replacing the original document.
[^proposes-to-replace]: **Why was "Replaces" retained instead of changing it to "Proposes-to-Replace"?**
When one BIP proposes to supersede another, it is on the original BIP where things get complicated. The BIP is an
author document, but depending on its progress through the workflow, it may meanwhile be co-owned by the community. Who may decide
whether the original document should endorse a potential replacement BIP? Is it the original authors, the authors of the new
proposal, the BIP Editors, some sort of community process, or a mix of all of the above?
On the new BIP these problems don’t exist in the same manner. As it is freshly written, it is wholly owned by its
authors. The community is not yet invested and the original BIP’s authors do not have a privileged role
in determining the content of the new BIP. The authors of the new BIP can unilaterally recommend that it be
considered a replacement for a prior BIP. From there, the community can evaluate the proposal and adopt or
reject it, thus establishing whether it is successful in superseding the original or not.
[^evidence]: **How is evidence for advancing to Deployed evaluated?**
Whether evidence is deemed convincing to move a BIP to Deployed is up to the BIP Editors and Bitcoin community.
Running a single instance of a personal fork of a software project might be rejected, while a small software project with
dozens of users may be sufficient. The main point of the Deployed status is to indicate that changes to the BIP
could negatively impact users of projects that have already implemented support.
[^licenses]: **Why were some licenses dropped?**
Among the 141 BIPs with licenses in the repository, only nine licenses have ever been used to license BIPs
(although, some BIPs were made available under more than one license) and only one license has been used to license
code:
Licenses used:
* BSD-2-Clause: 55
* PD: 42
* CC0-1.0: 23
* BSD-3-Clause: 19
* OPUBL-1.0: 5
* CC-BY-SA-4.0: 4
* FSFAP: 3
* MIT: 2
* CC-BY-4.0: 1
License-Code used (previous BIP2 format):
* BSD-2-Clause: 1
* CC0-1.0: 1
* MIT: 5
The following previously acceptable licenses were retained per request of reviewers, even though they have so far
never been used in the BIPs process:
* Apache-2.0: [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0)
* BSL-1.0: [Boost Software License 1.0](https://www.boost.org/LICENSE_1_0.txt)
The following previously acceptable licenses have never been used in the BIPs Process and have been dropped:
* AGPL-3.0+: [GNU Affero General Public License (AGPL) 3](https://www.gnu.org/licenses/agpl-3.0.en.html)
* FDL-1.3: [GNU Free Documentation License 1.3](https://www.gnu.org/licenses/fdl-1.3.en.html)
* GPL-2.0+: [GNU General Public License (GPL) 2 or newer](https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html)
* LGPL-2.1+: [GNU Lesser General Public License (LGPL) 2.1 or newer](https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html)
Why are software licenses included?
* Some BIPs, in particular those concerning the consensus layer, may include literal code in the BIP itself which
may not be available under the license terms the authors wish to use for the BIP.
* The author of this BIP has been provided with a learned opinion indicating that software licenses are perfectly
acceptable for licensing "human code" i.e., text as well as Markdown or MediaWiki code.
Why is CC-BY-SA-4.0 no longer acceptable for new BIPs?
* Specification BIPs are required to have a Reference Implementation and Test Vectors to be advanced to Complete. As
the BIPs repository is aiming to make proposals easily adoptable, the intention is for the reference
implementation and test vectors to be as accessible as possible. Copyleft licenses may introduce friction here,
and therefore CC-BY-SA-4.0 (and the GPL-flavors) is no longer considered acceptable for new BIPs. As mentioned
above, existing BIPs will retain their original licensing.
Why are Open Publication License and Public Domain no longer acceptable for new BIPs?
* Public domain is not universally recognised as a legitimate action, thus it is inadvisable.
* The Open Publication License is generally regarded as obsolete, and not a license suitable for new publications.
================================================
FILE: bip-0008/assignments.mediawiki
================================================
==Deployments==
List of deployments.
State can be defined, active, failed. Dates are in UTC.
================================================
FILE: bip-0008/states.dot
================================================
digraph {
rankdir=TD;
node [style="rounded,filled,bold", shape=box, fixedsize=true, width=1.5, fontname="Arial"];
edge [weight = 100];
"DEFINED" -> "STARTED" [label="height >= start_height"];
"STARTED" -> "MUST_SIGNAL" [label="height + 2016 >= timeoutheight AND lockinontimeout"];
"STARTED" -> "FAILED" [label="height >= timeoutheight\nAND\nNOT lockinontimeout"];
"LOCKED_IN" -> "ACTIVE" [label="height >= minimum_activation_height"];
"LOCKED_IN":se -> "LOCKED_IN":ne [label="height < minimum_activation_height"];
"MUST_SIGNAL" -> "LOCKED_IN" [label="always"];
edge [weight = 1];
"STARTED" -> "LOCKED_IN" [label="height < timeoutheight\nAND\nthreshold reached"];
"FAILED" -> "LOCKED_IN" [style=invis];
"DEFINED":sw -> "DEFINED":nw;
"STARTED":sw -> "STARTED":nw;
"ACTIVE":sw -> "ACTIVE":nw;
"FAILED":sw -> "FAILED":nw;
"STARTED" [fillcolor="#a0a0ff"];
"MUST_SIGNAL" [fillcolor="#a0a0ff"];
"LOCKED_IN" [fillcolor="#ffffa0"];
"ACTIVE" [fillcolor="#a0ffa0"];
"FAILED" [fillcolor="#ffa0a0"];
{ rank=same; "STARTED" "MUST_SIGNAL" }
{ rank=same; "FAILED" "LOCKED_IN" }
{ rank=sink; "ACTIVE" }
}
================================================
FILE: bip-0008.mediawiki
================================================
<pre>
BIP: 8
Title: Version bits with lock-in by height
Authors: Shaolin Fry <shaolinfry@protonmail.ch>
Luke Dashjr <luke+bip@dashjr.org>
Status: Draft
Type: Informational
Assigned: 2017-02-01
License: BSD-3-Clause OR CC0-1.0
</pre>
==Abstract==
This document specifies an alternative to [[bip-0009.mediawiki|BIP9]] that corrects for a number of perceived mistakes.
Block heights are used for start and timeout rather than POSIX timestamps.
It additionally introduces an activation parameter that can guarantee activation of backward-compatible changes (further called "soft forks").
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
==Motivation==
BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide optional flag day activation after a reasonable time, as well as for accelerated activation by majority of hash rate before the flag date.
Due to using timestamps rather than block heights, it was found to be a risk that a sudden loss of significant hashrate could interfere with a late activation.
Block time is somewhat unreliable and may be intentionally or unintentionally inaccurate, so thresholds based on block time are not ideal. Secondly, BIP9 specified triggers based on the first retarget after a given time, which is non-intuitive. Since each new block must increase the height by one, thresholds based on block height are much more reliable and intuitive and can be calculated exactly for difficulty retarget.
==Specification==
===Parameters===
Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier.
# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
# The '''startheight''' specifies the height of the first block at which the bit gains its meaning.
# The '''timeoutheight''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is considered failed on all descendants of the block.
# The '''threshold''' specifies the minimum number of block per retarget period which indicate lock-in of the soft fork during the subsequent period.
# The '''minimum_activation_height''' specifies the height of the first block at which the soft fork is allowed to become active.
# The '''lockinontimeout''' boolean if set to true, blocks are required to signal in the final period, ensuring the soft fork has locked in by timeoutheight.
===Selection guidelines===
The following guidelines are suggested for selecting these parameters for a soft fork:
# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
# '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes.
# '''startheight''' should be set to some block height in the future. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after software with parameters is expected to be released. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state.
# '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
# '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet.
# '''minimum_activation_height''' should be set to several retarget periods in the future if the '''startheight''' is to be very soon after software with parameters is expected to be released. '''minimum_activation_height''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. This allows more time to be spent in the LOCKED_IN state so that nodes can upgrade. This may be set to 0 to have the LOCKED_IN state be a single retarget period.
# '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
A later deployment using the same bit is possible as long as the startheight is after the previous one's
timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
'''startheight''', '''timeoutheight''', and '''minimum_activation_height''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4032 blocks (2 retarget intervals) after '''startheight'''.
===States===
With each block and soft fork, we associate a deployment state. The possible states are:
# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
# '''STARTED''' for blocks at or beyond the startheight.
# '''MUST_SIGNAL''' for one retarget period prior to the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is true.
# '''LOCKED_IN''' for at least one retarget period after the first retarget period with STARTED (or MUST_SIGNAL) blocks of which at least threshold have the associated bit set in nVersion. A soft fork remains in LOCKED_IN until at least '''minimum_activation_height''' is reached.
# '''ACTIVE''' for all blocks after the LOCKED_IN state.
# '''FAILED''' for all blocks after the timeoutheight if LOCKED_IN is not reached.
===Bit flags===
The nVersion block header field is to be interpreted as a 32-bit little-endian integer (as present), and bits are selected within this integer as values (1 << N) where N is the bit number.
Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be
001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available.
This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those
for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011).
When a block nVersion does not have top bits 001, it is treated as if all
bits are 0 for the purposes of deployments.
Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on consensus rules.
===New consensus rules===
The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget period have already failed to signal, any further blocks that fail to signal are invalid.
===State transitions===
<img src="bip-0008/states.png" align="middle"></img>
Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight'''.
Regardless of the value of '''lockinontimeout''', if LOCKED_IN is reached, ACTIVE will be reached either one retarget period later, or at '''minimum_activation_height''', whichever comes later.
The genesis block has state DEFINED for each deployment, by definition.
State GetStateForBlock(block) {
if (block.height == 0) {
return DEFINED;
}
All blocks within a retarget period have the same state. This means that if
floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for every
deployment.
if ((block.height % 2016) != 0) {
return GetStateForBlock(block.parent);
}
Otherwise, the next state depends on the previous state:
switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {
We remain in the initial state until we reach the start block height.
case DEFINED:
if (block.height >= startheight) {
return STARTED;
}
return DEFINED;
After a period in the STARTED state, we tally the bits set,
and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
version numbers.
If the threshold hasn't been met, lockinontimeout is true, and we are at the last period before the timeout, then we transition to MUST_SIGNAL.
If the threshold hasn't been met and we reach the timeout, we transition directly to FAILED.
Note that a block's state never depends on its own nVersion; only on that of its ancestors.
case STARTED:
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
++count;
}
}
if (count >= threshold) {
return LOCKED_IN;
} else if (lockinontimeout && block.height + 2016 >= timeoutheight) {
return MUST_SIGNAL;
} else if (block.height >= timeoutheight) {
return FAILED;
}
return STARTED;
If we have finished a period of MUST_SIGNAL, we transition directly to LOCKED_IN.
case MUST_SIGNAL:
return LOCKED_IN;
After at least one retarget period of LOCKED_IN, we automatically transition to ACTIVE if the minimum activation height is reached. Otherwise LOCKED_IN continues.
case LOCKED_IN:
if (block.height >= minimum_activation_height) {
return ACTIVE;
} else {
return LOCKED_IN;
}
And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached.
case ACTIVE:
return ACTIVE;
case FAILED:
return FAILED;
}
}
'''Implementation'''
It should be noted that the states are maintained along block chain
branches, but may need recomputation when a reorganization happens.
Given that the state for a specific block/deployment combination is completely determined by its ancestry before the
current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)),
it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016
block, indexed by its parent.
===Mandatory signalling===
Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal as required. For example:
if (GetStateForBlock(block) == MUST_SIGNAL) {
int nonsignal = 0;
walk = block;
while (true) {
if ((walk.nVersion & 0xE0000000) != 0x20000000 || ((walk.nVersion >> bit) & 1) != 1) {
++nonsignal;
if (nonsignal > 2016 - threshold) {
return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal");
}
}
if (walk.nHeight % 2016 == 0) {
// checked every block in this retarget period
break;
}
walk = walk.parent;
}
}
Implementations should be careful not to ban peers that send blocks that are invalid due to not signalling (or blocks that build on those blocks), as that would allow an incompatible chain that is only briefly longer than the compliant chain to cause a split of the p2p network. If that occurred, nodes that have not set ''lockinontimeout'' may not see new blocks in the compliant chain, and thus not reorg to it at the point when it has more work, and would thus not be following the valid chain with the most work.
Implementations with ''lockinontimeout'' set to true may potentially follow a lower work chain than nodes with ''lockinontimeout'' set to false for an extended period. In order for this not to result in a net split nodes with ''lockinontimeout'' set to true, those nodes may need to preferentially connect to each other. Deployments proposing that implementations set ''lockinontimeout'' to true should either use parameters that do not risk there being a higher work alternative chain, or specify a mechanism for implementations that support the deployment to preferentially peer with each other.
===Warning mechanism===
To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state).
===getblocktemplate changes===
The template request Object is extended to include a new item:
{| class="wikitable"
!colspan=4| template request
|-
! Key !! Required !! Type !! Description
|-
| rules || No || Array of Strings || list of supported softfork deployments, by name
|}
The template Object is also extended:
{| class="wikitable"
!colspan=4| template
|-
! Key !! Required !! Type !! Description
|-
| rules || Yes || Array of Strings || list of softfork deployments, by name, that are active state
|-
| vbavailable || Yes || Object || set of pending, supported softfork deployments; each uses the softfork name as the key, and the softfork bit as its value
|-
| vbrequired || No || Number || bit mask of softfork deployment version bits the server requires enabled in submissions
|}
The "version" key of the template is retained, and used to indicate the server's preference of deployments.
If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF].
Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired".
Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL state, to ensure blocks produced are valid.
Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.
Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113.
If a client does not understand a rule without the prefix, it may use it unmodified for mining.
On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction).
A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified.
=== Reference implementation ===
https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip8
==Contrasted with BIP 9==
* The '''lockinontimeout''' flag is added, providing a way to guarantee transition to LOCKED_IN.
* Block heights are used for the deployment monotonic clock, rather than median-time-past.
==Backwards compatibility==
BIP8 and BIP9 deployments should not share concurrent active deployment bits. Nodes that only implement BIP9 will not activate a BIP8 soft fork if hashpower threshold is not reached by '''timeoutheight''', however, those nodes will still accept the blocks generated by activated nodes.
==Deployments==
A living list of deployment proposals can be found [[bip-0008/assignments.mediawiki|here]].
==References==
[[bip-0009.mediawiki|BIP9]]
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html Mailing list discussion]
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.
================================================
FILE: bip-0009/assignments.mediawiki
================================================
==Deployments==
List of proposed deployments.
State can be defined, active, failed. Dates are in UTC.
{| class="wikitable sortable"
! Name
! Bit
! Mainnet Start
! Mainnet Expire
! Mainnet State
! Testnet Start
! Testnet Expire
! Testnet State
! BIPs
|-
| csv
| 0
| 2016-05-01 00:00:00
| 2017-05-01 00:00:00
| active since #419328
| 2016-03-01 00:00:00
| 2017-05-01 00:00:00
| active since #770112
| [[/bip-0068.mediawiki|68]], [[/bip-0112.mediawiki|112]], [[/bip-0113.mediawiki|113]]
|-
| segwit
| 1
| 2016-11-15 00:00:00
| 2017-11-15 00:00:00
| active since #481824
| 2016-05-01 00:00:00
| 2017-05-01 00:00:00
| active since #834624
| [[/bip-0141.mediawiki|141]], [[/bip-0143.mediawiki|143]], [[/bip-0147.mediawiki|147]]
|}
================================================
FILE: bip-0009/states.gv
================================================
/* There are many ways to compile this, but one of them is:
*
* $ dot -Tpng states.gv -o states.png
*/
digraph {
/* States. */
DEFINED; FAILED; STARTED; LOCKED_IN; ACTIVE;
/* Relationships between states, labeled where applicable. */
DEFINED -> DEFINED;
DEFINED -> FAILED [label = "timeout ≤ MTP"];
DEFINED -> STARTED [label = "starttime ≤ MTP < timeout"];
FAILED -> FAILED;
STARTED -> STARTED;
STARTED -> FAILED [label = "timeout ≤ MTP"];
STARTED -> LOCKED_IN [label = "(MTP < timeout) AND (threshold reached)"];
LOCKED_IN -> ACTIVE [label = "Always"];
ACTIVE -> ACTIVE;
/* Visualization hack to unclutter output. */
nodesep = 1.2;
}
================================================
FILE: bip-0009.mediawiki
================================================
<pre>
BIP: 9
Title: Version bits with timeout and delay
Authors: Pieter Wuille <pieter.wuille@gmail.com>
Peter Todd <pete@petertodd.org>
Greg Maxwell <greg@xiph.org>
Rusty Russell <rusty@rustcorp.com.au>
Status: Deployed
Type: Informational
Assigned: 2015-10-04
License: PD
</pre>
==Abstract==
This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.
==Motivation==
[[bip-0034.mediawiki|BIP 34]] introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.
In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in [[bip-0066.mediawiki|BIP 66]] and [[bip-0065.mediawiki|BIP 65]], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.
==Specification==
Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
# The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning.
# The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
===Selection guidelines===
The following guidelines are suggested for selecting these parameters for a soft fork:
# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name.
# '''bit''' should be selected such that no two concurrent softforks use the same bit.
# '''starttime''' should be set to some date in the future, approximately one month after a software release date including the soft fork. This allows for some release delays, while preventing triggers as a result of parties running pre-release software.
# '''timeout''' should be 1 year (31536000 seconds) after starttime.
A later deployment using the same bit is possible as long as the starttime is after the previous one's
timeout or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
===States===
With each block and soft fork, we associate a deployment state. The possible states are:
# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
# '''STARTED''' for blocks past the starttime.
# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion.
# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
# '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached.
===Bit flags===
The nVersion block header field is to be interpreted as a 32-bit little-endian integer (as present), and bits are selected within this integer as values (1 << N) where N is the bit number.
Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be
001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available.
This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those
for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011).
When a block nVersion does not have top bits 001, it is treated as if all
bits are 0 for the purposes of deployments.
Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on
consensus rules.
===New consensus rules===
The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
===State transitions===
<img src="bip-0009/states.png" align="middle"></img>
The genesis block has state DEFINED for each deployment, by definition.
State GetStateForBlock(block) {
if (block.height == 0) {
return DEFINED;
}
All blocks within a retarget period have the same state. This means that if
floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for every
deployment.
if ((block.height % 2016) != 0) {
return GetStateForBlock(block.parent);
}
Otherwise, the next state depends on the previous state:
switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {
We remain in the initial state until either we pass the start time or the timeout. GetMedianTimePast in the code below
refers to the median nTime of a block and its 10 predecessors. The expression GetMedianTimePast(block.parent) is
referred to as MTP in the diagram above, and is treated as a monotonic clock defined by the chain.
case DEFINED:
if (GetMedianTimePast(block.parent) >= timeout) {
return FAILED;
}
if (GetMedianTimePast(block.parent) >= starttime) {
return STARTED;
}
return DEFINED;
After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set,
and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016).
The transition to FAILED takes precedence, as otherwise an ambiguity can arise.
There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.
Note that a block's state never depends on its own nVersion; only on that of its ancestors.
case STARTED:
if (GetMedianTimePast(block.parent) >= timeout) {
return FAILED;
}
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
count++;
}
}
if (count >= threshold) {
return LOCKED_IN;
}
return STARTED;
After a retarget period of LOCKED_IN, we automatically transition to ACTIVE.
case LOCKED_IN:
return ACTIVE;
And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached.
case ACTIVE:
return ACTIVE;
case FAILED:
return FAILED;
}
}
'''Implementation'''
It should be noted that the states are maintained along block chain
branches, but may need recomputation when a reorganization happens.
Given that the state for a specific block/deployment combination is completely determined by its ancestry before the
current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)),
it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016
block, indexed by its parent.
===Warning mechanism===
To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state).
===getblocktemplate changes===
The template request Object is extended to include a new item:
{| class="wikitable"
!colspan=4| template request
|-
! Key !! Required !! Type !! Description
|-
| rules || No || Array of Strings || list of supported softfork deployments, by name
|}
The template Object is also extended:
{| class="wikitable"
!colspan=4| template
|-
! Key !! Required !! Type !! Description
|-
| rules || Yes || Array of Strings || list of softfork deployments, by name, that are active state
|-
| vbavailable || Yes || Object || set of pending, supported softfork deployments; each uses the softfork name as the key, and the softfork bit as its value
|-
| vbrequired || No || Number || bit mask of softfork deployment version bits the server requires enabled in submissions
|}
The "version" key of the template is retained, and used to indicate the server's preference of deployments.
If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF].
Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired".
Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.
Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs [[bip-0016.mediawiki|16]], [[bip-0065.mediawiki|65]], [[bip-0066.mediawiki|66]], [[bip-0068.mediawiki|68]], [[bip-0112.mediawiki|112]], and [[bip-0113.mediawiki|113]].
If a client does not understand a rule without the prefix, it may use it unmodified for mining.
On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be [[bip-0034.mediawiki|BIP 34]] (because it modifies coinbase construction) and [[bip-0141.mediawiki|141]] (since it modifies the txid hashing and adds a commitment to the generation transaction).
A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified.
==Support for future changes==
The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account.
'''Modified thresholds'''
The 1916 threshold (based on BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
'''Conflicting soft forks'''
At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.
'''Multi-stage soft forks'''
Soft forks right now are typically treated as booleans: they go from an inactive to an active state in blocks. Perhaps at some point there is demand for a change that has a larger number of stages, with additional validation rules that get enabled one by one. The above mechanism can be adapted to support this, by interpreting a combination of bits as an integer, rather than as isolated bits. The warning system is compatible with this, as (nVersion & ~nExpectedVersion) will always be non-zero for increasing integers.
== Rationale ==
The failure timeout allows eventual reuse of bits even if a soft fork was
never activated, so it's clear that the new use of the bit refers to a
new BIP. It's deliberately very coarse-grained, to take into account
reasonable development and deployment delays. There are unlikely to be
enough failed proposals to cause a bit shortage.
The fallow period at the conclusion of a soft fork attempt allows some
detection of buggy clients, and allows time for warnings and software
upgrades for successful soft forks.
==Deployments==
A living list of deployment proposals can be found [[bip-0009/assignments.mediawiki|here]].
==Copyright==
This document is placed in the public domain.
================================================
FILE: bip-0010.mediawiki
================================================
<pre>
BIP: 10
Layer: Applications
Title: Multi-Sig Transaction Distribution
Authors: Alan Reiner <etotheipi@gmail.com>
Status: Closed
Type: Informational
Assigned: 2011-10-28
</pre>
A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the proposed transaction and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction.
This BIP describes a way standardize the encoding of proposal transactions, to assist with signature collection and broadcast (which includes regular, 1-of-1 transactions requiring signatures from an offline computer). The goal is to encourage a standard that guarantees interoperability of all programs that implement it.
==Motivation==
The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection.
In addition to providing a general encoding scheme for transaction signing/collection, it does not require the signing device to hold any blockchain information (all information needed for verification and signing is part of the encoding). This enables the existence of very lightweight devices that can be used for signing since they do not need the blockchain -- only a minimal set of Bitcoin tools and an ECDSA module. Therefore, BIP 0010 has benefit beyond just multi-signature transactions.
==Specification==
This BIP proposes the following process, with terms in quotes referring to recommended terminology that should be encouraged across all implementations.
# One party will initiate this process by creating a "Distribution Proposal", which could be abbreviated DP, or TxDP
# The user creating the TxDP (the preparer) will create the transaction as they would like to see it spent, but with blank TxIn scripts (where the signatures scripts will eventually go).
# The proposed transaction will be spending a set of unspent TxOuts available in the blockchain. The full transactions containing these TxOuts will be serialized and included, as well. This so that the values of the TxIns can be verified before signing (the prev-tx-hash is part of the data being signed, but the value is not). By including the full tx, the signing party can verify that the tx matches the OutPoint hash, and then verify input values, all without any access to the blockchain.
# The TxDP will have an "DP ID" or "Unsigned ID" which is the hash of the proposed transaction with blanked scripts, in Base58. This is a specific naming convention to make sure it is not confused with the actual transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID.
# The TxDP will have a potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it.
# Identical TxDP objects with different signatures can be easily combined. This allows one party to send out all the requests for signatures at once, and combine them all when they are received (instead of having to "pass it around".
# For cases where the TxDP might be put into a file or sent via email, it should use .txdp or .btcdp suffix
Anyone adopting BIP 0010 for multi-sig transactions will use the following format (without indentation):
<pre>
'-----BEGIN-TRANSACTION-TXDPID-------'
("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
(serializedTxListInHex_Line1)
(serializedTxListInHex_Line2)
(serializedTxListInHex_Line3)
...
("_TXINPUT_") (00) (InputValue)
("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
(SigHexRemainingLines)
("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
(SigHexRemainingLines)
("_TXINPUT_") (01) (InputValue)
("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
(SigHexRemainingLines)
("_TXINPUT_") (02) (InputValue)
'-------END-TRANSACTION-TXDPID-------'
</pre>
The following is an example TxDP from Armory, produced while running on the test network. Its DPID is 3fX59xPj:
</pre>
-----BEGIN-TRANSACTION-3fX59xPj-------------------------------------------------
_TXDIST_fabfb5da_3fX59xPj_00a0
010000000292807c8e70a28c687daea2998d6273d074e56fa8a55a0b10556974cf2b526e61000000
0000ffffffffe3c1ee0711611b01af3dee55b1484f0d6b65d17dce4eff0e6e06242e6cf457e10000
000000ffffffff02b0feea0b000000001976a91457996661391fa4e95bed27d7e8fe47f47cb8e428
88ac00a0acb9030000001976a914dc504e07b1107110f601fb679dd3f56cee9ff71e88ac00000000
0100000001eb626e4f73d88f415a8e8cb32b8d73eed47aa1039d0ed2f013abdc741ce6828c010000
008c493046022100b0da540e4924518f8989a9da798ca2d9e761b69a173b8cc41a3e3e3c6d77cd50
022100ecfa61730e58005338420516744ef680428dcfc05022dec70a851365c8575b190141042dc5
be3afa5887aee4a377032ed014361b0b9b61eb3ea6b8a8821bfe13ee4b65cd25d9630e4f227a53e8
bf637f85452c9981bcbd64ef77e22ce97b0f547c783effffffff0200d6117e030000001976a914cf
f580fd243f64f0ad7bf69faf41c0bf42d86d8988ac00205fa0120000001976a9148d573ef6984fd9
f8847d420001f7ac49b222a24988ac000000000100000001f2782db40ae147398a31cff9c7cc3423
014a073a92e463741244330cc304168f000000008c493046022100c9311b9eef0cc69219cb96838f
dd621530a80c46269a00dccc66498bc03ccf7a0221003742ee652a0a76fd28ad81aa73bb7f7a0a6a
81850af58f62d9a184d10e5eec30014104f815e8ef4cad584e04974889d7636e8933803d2e72991d
b5288c9e953c2465533905f98b7b688898c7c1f0708f2e49f0dd0abc06859ffed5144e8a1018a4e8
63ffffffff02008c8647000000001976a914d4e211215967f8e3744693bf85f47eb4ee9567fc88ac
603d4e95010000001976a914e9a6b50901c1969d2b0fd43a3ccfa3fef3291efe88ac00000000
_TXINPUT_00_150.00000000
_SIG_mzUYGfqGpyXmppYpmWJ31Y4zTxR4ZCod22_00_008c
4930460221007699967c3ec09d072599558d2e7082fae0820206b63aa66afea124634ed11a080221
0003346f7e963e645ecae2855026dc7332eb7237012539b34cd441c3cef97fbd4d01410497d5e1a0
0e1db90e893d1f2e547e2ee83b5d6bf4ddaa3d514e6dc2d94b6bcb5a72be1fcec766b8c382502caa
9ec09fe478bad07d3f38ff47b2eb42e681c384cc
_TXINPUT_01_12.00000000
_SIG_mzvaN8JUhHLz3Gdec1zBRxs5rNaYLQnbD1_01_008c
49304602210081554f8b08a1ad8caa69e34f4794d54952dac7c5efcf2afe080985d6bd5b00770221
00dea20ca3dbae1d15ec61bec57b4b8062e7d7c47614aba032c5a32f651f471cfd014104c30936d2
456298a566aa76fefeab8a7cb7a91e8a936a11757c911b4c669f0434d12ab0936fc13986b156156f
9b389ed244bbb580112be07dbe23949a4764dffb
-------END-TRANSACTION-3fX59xPj-------------------------------------------------
</pre>
In this transaction, there are two inputs, one of 150 BTC and the other of 12 BTC. This transaction combines 162 BTC to create two outputs, one of 160 BTC, one 1.9995 BTC, and a tx fee of 0.0005. In this TxDP, both inputs have been signed, and thus could broadcast immediately.
The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpreted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP.
A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _SIG_ lines between serializations, though it is not the recommended method for combining TxDPs.
== Reference Implementation ==
This proposal was implemented and tested in the older versions of ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Implementation can be found in https://github.com/etotheipi/BitcoinArmory/blob/v0.91-beta/armoryengine/Transaction.py under the class PyTxDistProposal. However, as of version 0.92 released in July 2014, Armory no longer uses this proposal for offline wallet transaction signing and has moved on to a new format.
================================================
FILE: bip-0011.mediawiki
================================================
<pre>
BIP: 11
Layer: Applications
Title: M-of-N Standard Transactions
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2011-10-18
Discussion: 2011-10-02
</pre>
==Abstract==
This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type.
==Motivation==
Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature.
A couple of motivating use cases:
* A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business.
* Three-party escrow (buyer, seller, and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).<br />If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP.
==Specification==
A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks:
m {pubkey}...{pubkey} n OP_CHECKMULTISIG
But only for n less than or equal to 3.
OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig:
OP_0 ...signatures...
(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).
The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accommodate 3-signature transactions, this will be increased to 500 bytes.
==Rationale==
OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases.
One argument against using OP_CHECKMULTISIG is that old clients and miners count it as "20 sigops" for purposes of computing how many signature operations are in a block, and there is a hard limit of 20,000 sigops per block-- meaning a maximum of 1,000 multisig transactions per block. Creating multisig transactions using multiple OP_CHECKSIG operations allows more of them per block.
The counter-argument is that these new multi-signature transactions will be used in combination with OP_EVAL (see the OP_EVAL BIP), and '''will''' be counted accurately. And in any case, as transaction volume rises the hard-coded maximum block size will have to be addressed, and the rules for counting number-of-signature-operations-in-a-block can be addressed at that time.
A weaker argument is OP_CHECKMULTISIG should not be used because it pops one too many items off the stack during validation. Adding an extra OP_0 placeholder to the scriptSig adds only 1 byte to the transaction, and any alternative that avoids OP_CHECKMULTISIG adds at least several bytes of opcodes.
==Implementation==
OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type.
https://github.com/gavinandresen/bitcoin-git/tree/77f21f1583deb89bf3fffe80fe9b181fedb1dd60
== Post History ==
* [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal]
================================================
FILE: bip-0012.mediawiki
================================================
<pre>
BIP: 12
Layer: Consensus (soft fork)
Title: OP_EVAL
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Closed
Type: Specification
Assigned: 2011-10-18
</pre>
==Abstract==
This BIP describes a new opcode (OP_EVAL) for the [https://en.bitcoin.it/wiki/Script Bitcoin scripting system], and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them.
==Motivation==
Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions in a way that is backwards-compatible for old clients and miners.
==Specification==
OP_EVAL will re-define the existing OP_NOP1 opcode, and will function as follows:
* When executed during transaction verification, pops the item from the top of the stack, deserializes it, and executes the resulting script.
* If there is no item on the top of the stack or the item is not a valid script then transaction validation fails.
* If there are any OP_CODESEPARATORs in the deserialized script then transaction validation fails.
* If there are any OP_EVALs in the deserialized script they are also executed, but recursion is limited to a depth of 2.
* Transaction verification must fail if interpreting OP_EVAL as a no-op would cause the verification to fail.
A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks is also defined:
DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL
Which is redeemed by a standard scriptSig:
...signatures... {serialized script}
Transactions that redeem standard OP_EVAL scriptPubKeys are only considered standard if the ''serialized script'' is, itself, one of the standard transaction types.
==Rationale==
OP_EVAL allows the receiver of bitcoins to specify how they can be spent when they are spent, instead of requiring the sender of the bitcoins to know the details of how the bitcoins may be redeemed. The sender only needs to know the hash of the ''serialized script'', and one new type of bitcoin address can be used to fund arbitrarily complex transactions.
If ''serialized script'' is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver.
The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilities.
That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure.
There is a 1-confirmation attack on old clients that interpret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is:
# Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients.
# Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim.
# Attacker manages to mine a block that contains both transactions. If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block.
The attack is expensive because it requires the attacker create a block that they know will be invalidated. It is difficult because bitcoin businesses should not accept 1-confirmation transactions for higher-value transactions.
==Backwards Compatibility==
Surprisingly, because OP_EVAL redefines the OP_NOP1 opcode, standard OP_EVAL transactions will validate with old clients and miners. They will check only that the ''serialized script'' hashes to the correct value; the OP_EVAL will be interpreted as a no-op, and as long as the hash is correct the transaction will be considered valid (no signature checking will be done by old clients and miners).
Old clients will ignore OP_EVAL transactions and transactions that depend on them until they are put into a block by either an old miner that includes non-standard transactions in its blocks or by a new miner.
Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases:
# An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners.
# An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners.
For case (1), new clients and miners will be coded to interpret OP_EVAL as a no-op until February 1, 2012. Before then, miners will be asked to put the string "OP_EVAL" in blocks that they produce so that hashing power that supports the new opcode can be gauged. If less than 50% of miners accept the change as of January 15, 2012 the rollout will be postponed until more than 50% of hashing power supports OP_EVAL (the rollout will be rejected if it becomes clear that a majority of hashing power will not be achieved).
For case (2), new clients and miners will be written to make sure that transactions involving OP_EVAL are valid if OP_EVAL is interpreted as a no-op.
Example of a transaction that must fail for both old and new miners/clients:
scriptSig: {serialized OP_11}
scriptPubKey: OP_EVAL OP_11 OP_EQUAL
==Reference Implementation==
https://github.com/gavinandresen/bitcoin-git/tree/77f21f1583deb89bf3fffe80fe9b181fedb1dd60
==See Also==
https://bitcointalk.org/index.php?topic=46538
"Bitcoin Address 01" BIP
M-of-N Multisignature Transactions BIP 11
================================================
FILE: bip-0013.mediawiki
================================================
<pre>
BIP: 13
Layer: Applications
Title: Address Format for pay-to-script-hash
Authors: Gavin Andresen <gavinandresen@gmail.com>
Status: Deployed
Type: Specification
Assigned: 2011-10-18
</pre>
==Abstract==
This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin.
In essence, an address encoded under this proposal represents the encoded hash of a [https://en.bitcoin.it/wiki/Script script], rather than the encoded hash of an ECDSA public key.
==Motivation==
Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet security services.
==Specification==
The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [https://en.bitcoin.it/Base58Check_encoding Base58Check encoding]):
base58-encode: [one-byte version][20-byte hash][4-byte checksum]
Version byte is 5 for a main-network address, 196 for a testnet address.
The 20-byte hash is the hash of the script that will be used to redeem the coins.
And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and hash.
==Rationale==
One criticism is that bitcoin addresses should be deprecated in favor of a more user-friendly mechanism for payments, and that this will just encourage continued use of a poorly designed mechanism.
Another criticism is that bitcoin addresses are inherently insecure because there is no identity information tied to them; if you only have a bitcoin address, how can you be certain that you're paying who or what you think you're paying?
Furthermore, truncating SHA256 is not an optimal checksum; there are much better error-detecting algorithms. If we are introducing a new form of Bitcoin address, then perhaps a better algorithm should be used.
This is one piece of the simplest path to a more secure bitcoin infrastructure. It is not intended to solve all of bitcoin's usability or security issues, but to be an incremental improvement over what exists today. A future BIP or BIPs should propose more user-friendly mechanisms for making payments, or for verifying that you're sending a payment to the Free Software Foundation and not Joe Random Hacker.
Assuming that typing in bitcoin addresses manually will become increasingly rare in the future, and given that the existing checksum method for bitcoin addresses seems to work "well enough" in practice and has already been implemented multiple times, the Author believes no change to the checksum algorithm is necessary.
The leading version bytes are chosen so that, after base58 encoding, the leading character is consistent: for the main network, byte 5 becomes the character '3'. For the testnet, byte 196 is encoded into '2'.
==Backwards Compatibility==
This proposal is not backwards compatible, but it fails gracefully-- if an older implementation is given one of these new bitcoin addresses, it will report the address as invalid and will refuse to create a transaction.
==Reference Implementation==
See base58.
gitextract_ant9xgmu/
├── .gitattributes
├── .github/
│ └── workflows/
│ └── github-action-checks.yml
├── .gitignore
├── .typos.toml
├── CONTRIBUTING.md
├── README.mediawiki
├── bip-0001.mediawiki
├── bip-0002.mediawiki
├── bip-0003.md
├── bip-0008/
│ ├── assignments.mediawiki
│ └── states.dot
├── bip-0008.mediawiki
├── bip-0009/
│ ├── assignments.mediawiki
│ └── states.gv
├── bip-0009.mediawiki
├── bip-0010.mediawiki
├── bip-0011.mediawiki
├── bip-0012.mediawiki
├── bip-0013.mediawiki
├── bip-0014.mediawiki
├── bip-0015.mediawiki
├── bip-0016/
│ └── qa.mediawiki
├── bip-0016.mediawiki
├── bip-0017.mediawiki
├── bip-0018.mediawiki
├── bip-0019.mediawiki
├── bip-0020.mediawiki
├── bip-0021.mediawiki
├── bip-0022.mediawiki
├── bip-0023.mediawiki
├── bip-0030.mediawiki
├── bip-0031.mediawiki
├── bip-0032.mediawiki
├── bip-0033.mediawiki
├── bip-0034.mediawiki
├── bip-0035.mediawiki
├── bip-0036.mediawiki
├── bip-0037.mediawiki
├── bip-0038.mediawiki
├── bip-0039/
│ ├── bip-0039-wordlists.md
│ ├── chinese_simplified.txt
│ ├── chinese_traditional.txt
│ ├── czech.txt
│ ├── english.txt
│ ├── french.txt
│ ├── italian.txt
│ ├── japanese.txt
│ ├── korean.txt
│ ├── portuguese.txt
│ └── spanish.txt
├── bip-0039.mediawiki
├── bip-0042.mediawiki
├── bip-0043.mediawiki
├── bip-0044.mediawiki
├── bip-0045.mediawiki
├── bip-0046.mediawiki
├── bip-0047.mediawiki
├── bip-0048.mediawiki
├── bip-0049.mediawiki
├── bip-0050.mediawiki
├── bip-0052.mediawiki
├── bip-0053/
│ ├── 64byte-tx-mainnet.txt
│ └── non-standard-hashlock-utxos.txt
├── bip-0053.mediawiki
├── bip-0054/
│ └── test_vectors/
│ ├── README.md
│ ├── coinbases.json
│ ├── sigops.json
│ ├── timestamps.json
│ └── txsize.json
├── bip-0054.md
├── bip-0060.mediawiki
├── bip-0061.mediawiki
├── bip-0062.mediawiki
├── bip-0064.mediawiki
├── bip-0065.mediawiki
├── bip-0066.mediawiki
├── bip-0067.mediawiki
├── bip-0068.mediawiki
├── bip-0069/
│ └── bip-0069_examples.py
├── bip-0069.mediawiki
├── bip-0070/
│ ├── extensions.mediawiki
│ └── paymentrequest.proto
├── bip-0070.mediawiki
├── bip-0071.mediawiki
├── bip-0072.mediawiki
├── bip-0073.mediawiki
├── bip-0074.mediawiki
├── bip-0075/
│ └── paymentrequest.proto
├── bip-0075.mediawiki
├── bip-0077.md
├── bip-0078.mediawiki
├── bip-0079.mediawiki
├── bip-0080.mediawiki
├── bip-0081.mediawiki
├── bip-0083.mediawiki
├── bip-0084.mediawiki
├── bip-0085.mediawiki
├── bip-0086.mediawiki
├── bip-0087.mediawiki
├── bip-0088.mediawiki
├── bip-0089/
│ ├── bip32.py
│ ├── descriptor.py
│ ├── reference.py
│ ├── secp256k1lab/
│ │ ├── COPYING
│ │ ├── __init__.py
│ │ ├── bip340.py
│ │ ├── ecdh.py
│ │ ├── keys.py
│ │ ├── py.typed
│ │ ├── secp256k1.py
│ │ └── util.py
│ └── vectors/
│ ├── blind_challenge_gen_vectors.json
│ ├── blind_nonce_gen_vectors.json
│ ├── blind_sign_and_verify_vectors.json
│ ├── change_output_verification_vectors.json
│ ├── compute_bip32_tweak_vectors.json
│ ├── delegator_sign_vectors.json
│ ├── input_verification_vectors.json
│ └── unblind_signature_vectors.json
├── bip-0089.mediawiki
├── bip-0090.mediawiki
├── bip-0091.mediawiki
├── bip-0093.mediawiki
├── bip-0094.mediawiki
├── bip-0098/
│ ├── build.sh
│ ├── node-variants.dot
│ ├── skip-skip.dot
│ ├── traversal-example.dot
│ └── unbalanced-hash-tree.dot
├── bip-0098.mediawiki
├── bip-0099.mediawiki
├── bip-0100.mediawiki
├── bip-0101.mediawiki
├── bip-0102.mediawiki
├── bip-0103.mediawiki
├── bip-0104.mediawiki
├── bip-0105.mediawiki
├── bip-0106.mediawiki
├── bip-0107.mediawiki
├── bip-0109.mediawiki
├── bip-0110.mediawiki
├── bip-0111.mediawiki
├── bip-0112.mediawiki
├── bip-0113.mediawiki
├── bip-0114.mediawiki
├── bip-0115.mediawiki
├── bip-0116.mediawiki
├── bip-0117.mediawiki
├── bip-0118.mediawiki
├── bip-0119/
│ ├── simulation.py
│ └── vectors/
│ ├── ctvhash.json
│ ├── tx_invalid.json
│ └── tx_valid.json
├── bip-0119.mediawiki
├── bip-0120.mediawiki
├── bip-0121.mediawiki
├── bip-0122.mediawiki
├── bip-0123.mediawiki
├── bip-0124.mediawiki
├── bip-0125.mediawiki
├── bip-0126.mediawiki
├── bip-0127.mediawiki
├── bip-0128.mediawiki
├── bip-0129.mediawiki
├── bip-0130.mediawiki
├── bip-0131.mediawiki
├── bip-0132.mediawiki
├── bip-0133.mediawiki
├── bip-0134.mediawiki
├── bip-0135.mediawiki
├── bip-0136.mediawiki
├── bip-0137.mediawiki
├── bip-0140.mediawiki
├── bip-0141.mediawiki
├── bip-0142.mediawiki
├── bip-0143.mediawiki
├── bip-0144.mediawiki
├── bip-0145.mediawiki
├── bip-0146.mediawiki
├── bip-0147.mediawiki
├── bip-0148.mediawiki
├── bip-0149.mediawiki
├── bip-0150.mediawiki
├── bip-0151.mediawiki
├── bip-0152.mediawiki
├── bip-0154.mediawiki
├── bip-0155.mediawiki
├── bip-0156/
│ └── bitcoin.conf
├── bip-0156.mediawiki
├── bip-0157.mediawiki
├── bip-0158/
│ ├── gentestvectors.go
│ ├── go.mod
│ ├── go.sum
│ └── testnet-19.json
├── bip-0158.mediawiki
├── bip-0159.mediawiki
├── bip-0171.mediawiki
├── bip-0172.mediawiki
├── bip-0173.mediawiki
├── bip-0174/
│ ├── build.sh
│ ├── coinjoin-workflow.tex
│ └── multisig-workflow.tex
├── bip-0174.mediawiki
├── bip-0175.mediawiki
├── bip-0176.mediawiki
├── bip-0177.mediawiki
├── bip-0178.mediawiki
├── bip-0179.mediawiki
├── bip-0180.mediawiki
├── bip-0197.mediawiki
├── bip-0199.mediawiki
├── bip-0300/
│ └── images.txt
├── bip-0300.mediawiki
├── bip-0301.mediawiki
├── bip-0310.mediawiki
├── bip-0320.mediawiki
├── bip-0321.mediawiki
├── bip-0322.mediawiki
├── bip-0324/
│ ├── ellswift_decode_test_vectors.csv
│ ├── gen_test_vectors.py
│ ├── message_type_ids.md
│ ├── packet_encoding_test_vectors.csv
│ ├── reference.py
│ ├── run_test_vectors.py
│ ├── secp256k1_test_vectors.py
│ ├── test_sage_decoding.py
│ └── xswiftec_inv_test_vectors.csv
├── bip-0324.mediawiki
├── bip-0325.mediawiki
├── bip-0326.mediawiki
├── bip-0327/
│ ├── gen_vectors_helper.py
│ ├── reference.py
│ ├── tests.sh
│ └── vectors/
│ ├── det_sign_vectors.json
│ ├── key_agg_vectors.json
│ ├── key_sort_vectors.json
│ ├── nonce_agg_vectors.json
│ ├── nonce_gen_vectors.json
│ ├── sig_agg_vectors.json
│ ├── sign_verify_vectors.json
│ └── tweak_vectors.json
├── bip-0327.mediawiki
├── bip-0328/
│ ├── _base58.py
│ ├── _common.py
│ ├── _xpub.py
│ ├── reference.py
│ └── vectors.json
├── bip-0328.mediawiki
├── bip-0329.mediawiki
├── bip-0330/
│ └── minisketch.py
├── bip-0330.mediawiki
├── bip-0331.mediawiki
├── bip-0337.mediawiki
├── bip-0338.mediawiki
├── bip-0339.mediawiki
├── bip-0340/
│ ├── LICENSE
│ ├── reference.py
│ ├── test-vectors.csv
│ └── test-vectors.py
├── bip-0340.mediawiki
├── bip-0341/
│ └── wallet-test-vectors.json
├── bip-0341.mediawiki
├── bip-0342.mediawiki
├── bip-0343.mediawiki
├── bip-0345/
│ └── vaults.drawio
├── bip-0345.mediawiki
├── bip-0346/
│ └── ref-impl/
│ ├── Cargo.toml
│ ├── src/
│ │ └── main.rs
│ └── txhash_vectors.json
├── bip-0346.md
├── bip-0347.mediawiki
├── bip-0348.md
├── bip-0349.md
├── bip-0350.mediawiki
├── bip-0351.mediawiki
├── bip-0352/
│ ├── bech32m.py
│ ├── bitcoin_utils.py
│ ├── reference.py
│ ├── ripemd160.py
│ ├── secp256k1lab/
│ │ ├── .github/
│ │ │ └── workflows/
│ │ │ └── main.yml
│ │ ├── .python-version
│ │ ├── CHANGELOG.md
│ │ ├── COPYING
│ │ ├── README.md
│ │ ├── pyproject.toml
│ │ └── src/
│ │ └── secp256k1lab/
│ │ ├── __init__.py
│ │ ├── bip340.py
│ │ ├── ecdh.py
│ │ ├── keys.py
│ │ ├── py.typed
│ │ ├── secp256k1.py
│ │ └── util.py
│ └── send_and_receive_test_vectors.json
├── bip-0352.mediawiki
├── bip-0353.mediawiki
├── bip-0360/
│ └── ref-impl/
│ ├── .gitignore
│ ├── common/
│ │ ├── tests/
│ │ │ └── data/
│ │ │ ├── p2mr_construction.json
│ │ │ └── p2mr_pqc_construction.json
│ │ └── utils/
│ │ ├── signet_miner_loop.sh
│ │ └── workshop/
│ │ ├── Dockerfile.bcli
│ │ ├── Dockerfile.full
│ │ └── bip360-workshop.drawio
│ ├── js/
│ │ ├── .gitignore
│ │ ├── README.adoc
│ │ ├── package.json
│ │ ├── src/
│ │ │ ├── p2mr-example.ts
│ │ │ └── test-npm-pqc-package.js
│ │ └── tsconfig.json
│ ├── python/
│ │ └── .gitignore
│ └── rust/
│ ├── .cargo/
│ │ └── config.toml
│ ├── Cargo.toml
│ ├── README.md
│ ├── docs/
│ │ ├── development_notes.adoc
│ │ ├── p2mr-end-to-end.adoc
│ │ ├── p2mr-signet-workshop.adoc
│ │ ├── p2tr-end-to-end.adoc
│ │ ├── quantum_root_tap_tree.txt
│ │ └── stack_element_size_performance_tests.adoc
│ ├── examples/
│ │ ├── p2mr-end-to-end.sh
│ │ ├── p2mr_construction.rs
│ │ ├── p2mr_spend.rs
│ │ ├── p2tr_construction.rs
│ │ ├── p2tr_spend.rs
│ │ ├── schnorr_example.rs
│ │ └── slh_dsa_verification_example.rs
│ ├── src/
│ │ ├── bin/
│ │ │ └── slh_dsa_key_gen.rs
│ │ ├── data_structures.rs
│ │ ├── error.rs
│ │ └── lib.rs
│ └── tests/
│ ├── p2mr_construction.rs
│ ├── p2mr_pqc_construction.rs
│ └── p2mr_spend.rs
├── bip-0360.mediawiki
├── bip-0370.mediawiki
├── bip-0371.mediawiki
├── bip-0372.mediawiki
├── bip-0373.mediawiki
├── bip-0374/
│ ├── gen_test_vectors.py
│ ├── reference.py
│ ├── run_test_vectors.py
│ ├── secp256k1lab/
│ │ ├── .github/
│ │ │ └── workflows/
│ │ │ └── main.yml
│ │ ├── .python-version
│ │ ├── CHANGELOG.md
│ │ ├── COPYING
│ │ ├── README.md
│ │ ├── pyproject.toml
│ │ └── src/
│ │ └── secp256k1lab/
│ │ ├── __init__.py
│ │ ├── bip340.py
│ │ ├── ecdh.py
│ │ ├── keys.py
│ │ ├── py.typed
│ │ ├── secp256k1.py
│ │ └── util.py
│ ├── test_vectors_generate_proof.csv
│ └── test_vectors_verify_proof.csv
├── bip-0374.mediawiki
├── bip-0375.mediawiki
├── bip-0379.md
├── bip-0380.mediawiki
├── bip-0381.mediawiki
├── bip-0382.mediawiki
├── bip-0383.mediawiki
├── bip-0384.mediawiki
├── bip-0385.mediawiki
├── bip-0386.mediawiki
├── bip-0387.mediawiki
├── bip-0388/
│ └── wallet_policies.py
├── bip-0388.mediawiki
├── bip-0389.mediawiki
├── bip-0390.mediawiki
├── bip-0392.mediawiki
├── bip-0431.mediawiki
├── bip-0433.mediawiki
├── bip-0434.md
├── bip-0442.md
├── bip-0443.mediawiki
├── bip-0446/
│ ├── README.md
│ ├── basics.json
│ └── script_assets_test.json
├── bip-0446.md
├── bip-0448.md
└── scripts/
├── buildtable.pl
├── diffcheck.expected
├── diffcheck.sh
└── link-format-chk.sh
SYMBOL INDEX (735 symbols across 57 files)
FILE: bip-0069/bip-0069_examples.py
function bytearr_cmp (line 6) | def bytearr_cmp(barr1, barr2):
function input_cmp (line 23) | def input_cmp(input_tuple1, input_tuple2):
function sort_inputs (line 36) | def sort_inputs(input_tuples):
function print_inputs (line 39) | def print_inputs(ordered_input_tuples):
function output_cmp (line 48) | def output_cmp(output_tuple1, output_tuple2):
function sort_outputs (line 57) | def sort_outputs(output_tuples):
function print_outputs (line 60) | def print_outputs(ordered_output_tuples):
function main (line 68) | def main():
FILE: bip-0089/bip32.py
function int_to_bytes (line 14) | def int_to_bytes(value: int, length: int) -> bytes:
function bytes_to_int (line 18) | def bytes_to_int(data: bytes) -> int:
function compress_point (line 21) | def compress_point(point: GE) -> bytes:
function decompress_point (line 27) | def decompress_point(data: bytes) -> GE:
function apply_tweak_to_public (line 30) | def apply_tweak_to_public(base_public: bytes, tweak: int) -> bytes:
function apply_tweak_to_secret (line 38) | def apply_tweak_to_secret(base_secret: int, tweak: int) -> int:
function decode_path (line 43) | def decode_path(path_elements: Sequence[object]) -> List[int]:
function _hash160 (line 63) | def _hash160(data: bytes) -> bytes:
class ExtendedPublicKey (line 68) | class ExtendedPublicKey:
method fingerprint (line 75) | def fingerprint(self) -> bytes:
method derive_child (line 78) | def derive_child(self, index: int) -> Tuple[int, "ExtendedPublicKey"]:
function derive_public_child (line 90) | def derive_public_child(parent_point: GE, chain_code: bytes, index: int)...
function parse_path (line 106) | def parse_path(path: str) -> List[int]:
function parse_extended_public_key (line 122) | def parse_extended_public_key(data: Mapping[str, object]) -> ExtendedPub...
function build_extended_public_key (line 153) | def build_extended_public_key(
FILE: bip-0089/descriptor.py
class SortedMultiDescriptorTemplate (line 10) | class SortedMultiDescriptorTemplate:
method witness_script (line 15) | def witness_script(self, tweaked_keys: Sequence[bytes]) -> bytes:
function _op_n (line 37) | def _op_n(value: int) -> int:
FILE: bip-0089/reference.py
function xbytes (line 35) | def xbytes(P: GE) -> bytes:
function cbytes (line 38) | def cbytes(P: GE) -> bytes:
function cpoint (line 41) | def cpoint(x: bytes) -> GE:
function tweak_ctx_init (line 48) | def tweak_ctx_init(pk: PlainPk) -> TweakContext:
function apply_tweak (line 56) | def apply_tweak(tweak_ctx: TweakContext, tweak: bytes, is_xonly: bool) -...
function individual_pk (line 76) | def individual_pk(seckey: bytes) -> PlainPk:
function bytes_xor (line 79) | def bytes_xor(a: bytes, b: bytes) -> bytes:
function tagged_hash (line 84) | def tagged_hash(tag: str, msg: bytes, hash_func: HashFunc = hashlib.sha2...
function nonce_hash (line 88) | def nonce_hash(rand: bytes, pk: PlainPk, extra_in: bytes) -> bytes:
function blind_nonce_gen_internal (line 97) | def blind_nonce_gen_internal(rand_: bytes, sk: Optional[bytes], pk: Opti...
function blind_nonce_gen (line 115) | def blind_nonce_gen(sk: Optional[bytes], pk: Optional[PlainPk], extra_in...
function blind_factor_hash (line 128) | def blind_factor_hash(rand: bytes, cpk: PlainPk, blindpubnonce: bytes, m...
function blind_challenge_gen_internal (line 141) | def blind_challenge_gen_internal(rand: bytes, msg: bytes, blindpubnonce:...
function blind_challenge_gen (line 175) | def blind_challenge_gen(msg: bytes, blindpubnonce: bytes, pk: PlainPk, t...
function blind_sign (line 179) | def blind_sign(sk: bytes, blindchallenge: bytes, blindsecnonce: bytearra...
function verify_blind_signature (line 205) | def verify_blind_signature(pk: PlainPk, blindpubnonce: bytes, blindchall...
function pubkey_and_tweak (line 219) | def pubkey_and_tweak(pk: PlainPk, tweaks: List[bytes], is_xonly: List[bo...
function get_session_values (line 228) | def get_session_values(session_ctx: SessionContext) -> Tuple[GE, Scalar,...
function unblind_signature (line 236) | def unblind_signature(session_ctx: SessionContext, blindsignature: bytes...
function hx (line 247) | def hx(s: str) -> bytes:
function fromhex_all (line 250) | def fromhex_all(l): # noqa: E741
function get_error_details (line 254) | def get_error_details(tc):
function assert_raises (line 264) | def assert_raises(exc_cls, fn, pred):
function build_session_ctx (line 273) | def build_session_ctx(obj):
function test_blind_nonce_gen_vectors (line 282) | def test_blind_nonce_gen_vectors():
function test_blind_challenge_gen_vectors (line 313) | def test_blind_challenge_gen_vectors():
function test_blind_sign_and_verify_vectors (line 390) | def test_blind_sign_and_verify_vectors():
function test_unblind_signature_vectors (line 481) | def test_unblind_signature_vectors():
function test_sign_and_verify_random (line 520) | def test_sign_and_verify_random(iters: int) -> None:
function compute_bip32_tweak (line 546) | def compute_bip32_tweak(xpub: ExtendedPublicKey, path: Sequence[int]) ->...
function input_verification (line 557) | def input_verification(
function change_output_verification (line 571) | def change_output_verification(
function _verify_tweaked_descriptor (line 585) | def _verify_tweaked_descriptor(
function delegator_sign (line 610) | def delegator_sign(
function test_compute_tweak_vectors (line 621) | def test_compute_tweak_vectors() -> None:
function test_delegator_sign_vectors (line 677) | def test_delegator_sign_vectors() -> None:
function test_input_verification_vectors (line 708) | def test_input_verification_vectors() -> None:
function test_change_output_verification_vectors (line 731) | def test_change_output_verification_vectors() -> None:
function parse_tweak_map (line 753) | def parse_tweak_map(raw: Mapping[str, object]) -> Dict[bytes, int]:
function resolve_error_spec (line 763) | def resolve_error_spec(raw: object) -> Tuple[type[Exception], Optional[s...
FILE: bip-0089/secp256k1lab/bip340.py
function pubkey_gen (line 8) | def pubkey_gen(seckey: bytes) -> bytes:
function schnorr_sign (line 17) | def schnorr_sign(
function schnorr_verify (line 51) | def schnorr_verify(
FILE: bip-0089/secp256k1lab/ecdh.py
function ecdh_compressed_in_raw_out (line 6) | def ecdh_compressed_in_raw_out(seckey: bytes, pubkey: bytes) -> GE:
function ecdh_libsecp256k1 (line 13) | def ecdh_libsecp256k1(seckey: bytes, pubkey: bytes) -> bytes:
FILE: bip-0089/secp256k1lab/keys.py
function pubkey_gen_plain (line 9) | def pubkey_gen_plain(seckey: bytes) -> bytes:
FILE: bip-0089/secp256k1lab/secp256k1.py
class APrimeFE (line 22) | class APrimeFE:
method __init__ (line 31) | def __init__(self, a: int | Self = 0, b: int | Self = 1) -> None:
method __add__ (line 52) | def __add__(self, a: int | Self) -> Self:
method __radd__ (line 60) | def __radd__(self, a: int) -> Self:
method sum (line 65) | def sum(cls, *es: Self) -> Self:
method __sub__ (line 71) | def __sub__(self, a: int | Self) -> Self:
method __rsub__ (line 79) | def __rsub__(self, a: int) -> Self:
method __mul__ (line 83) | def __mul__(self, a: int | Self) -> Self:
method __rmul__ (line 91) | def __rmul__(self, a: int) -> Self:
method __truediv__ (line 95) | def __truediv__(self, a: int | Self) -> Self:
method __pow__ (line 101) | def __pow__(self, a: int) -> Self:
method __neg__ (line 105) | def __neg__(self) -> Self:
method __int__ (line 109) | def __int__(self) -> int:
method sqrt (line 116) | def sqrt(self) -> Self | None:
method is_square (line 120) | def is_square(self) -> bool:
method is_even (line 125) | def is_even(self) -> bool:
method __eq__ (line 129) | def __eq__(self, a: object) -> bool:
method to_bytes (line 137) | def to_bytes(self) -> bytes:
method from_int_checked (line 142) | def from_int_checked(cls, v: int) -> Self:
method from_int_wrapping (line 149) | def from_int_wrapping(cls, v: int) -> Self:
method from_bytes_checked (line 154) | def from_bytes_checked(cls, b: bytes) -> Self:
method from_bytes_wrapping (line 160) | def from_bytes_wrapping(cls, b: bytes) -> Self:
method __str__ (line 165) | def __str__(self) -> str:
method __repr__ (line 169) | def __repr__(self) -> str:
class FE (line 174) | class FE(APrimeFE):
method sqrt (line 177) | def sqrt(self) -> Self | None:
class Scalar (line 195) | class Scalar(APrimeFE):
method from_int_nonzero_checked (line 200) | def from_int_nonzero_checked(cls, v: int) -> Self:
method from_bytes_nonzero_checked (line 207) | def from_bytes_nonzero_checked(cls, b: bytes) -> Self:
class GE (line 213) | class GE:
method infinity (line 238) | def infinity(self) -> bool:
method x (line 243) | def x(self) -> FE:
method y (line 249) | def y(self) -> FE:
method __init__ (line 254) | def __init__(self, x: int | FE | None = None, y: int | FE | None = Non...
method __add__ (line 271) | def __add__(self, a: GE) -> GE:
method sum (line 295) | def sum(*ps: GE) -> GE:
method batch_mul (line 302) | def batch_mul(*aps: tuple[Scalar, GE]) -> GE:
method __rmul__ (line 321) | def __rmul__(self, a: int | Scalar) -> GE:
method __neg__ (line 327) | def __neg__(self) -> GE:
method __sub__ (line 333) | def __sub__(self, a: GE) -> GE:
method __eq__ (line 337) | def __eq__(self, a: object) -> bool:
method has_even_y (line 343) | def has_even_y(self) -> bool:
method to_bytes_compressed (line 348) | def to_bytes_compressed(self) -> bytes:
method to_bytes_compressed_with_infinity (line 353) | def to_bytes_compressed_with_infinity(self) -> bytes:
method to_bytes_uncompressed (line 359) | def to_bytes_uncompressed(self) -> bytes:
method to_bytes_xonly (line 364) | def to_bytes_xonly(self) -> bytes:
method lift_x (line 370) | def lift_x(x: int | FE) -> GE:
method from_bytes_compressed (line 380) | def from_bytes_compressed(b: bytes) -> GE:
method from_bytes_compressed_with_infinity (line 392) | def from_bytes_compressed_with_infinity(b: bytes) -> GE:
method from_bytes_uncompressed (line 400) | def from_bytes_uncompressed(b: bytes) -> GE:
method from_bytes (line 412) | def from_bytes(b: bytes) -> GE:
method from_bytes_xonly (line 421) | def from_bytes_xonly(b: bytes) -> GE:
method is_valid_x (line 429) | def is_valid_x(x: int | FE) -> bool:
method __str__ (line 433) | def __str__(self) -> str:
method __repr__ (line 439) | def __repr__(self) -> str:
method __hash__ (line 445) | def __hash__(self) -> int:
class FastGEMul (line 456) | class FastGEMul:
method __init__ (line 468) | def __init__(self, p: GE) -> None:
method mul (line 474) | def mul(self, a: Scalar | int) -> GE:
FILE: bip-0089/secp256k1lab/util.py
function tagged_hash (line 6) | def tagged_hash(tag: str, msg: bytes) -> bytes:
function bytes_from_int (line 11) | def bytes_from_int(x: int) -> bytes:
function xor_bytes (line 15) | def xor_bytes(b0: bytes, b1: bytes) -> bytes:
function int_from_bytes (line 19) | def int_from_bytes(b: bytes) -> int:
function hash_sha256 (line 23) | def hash_sha256(b: bytes) -> bytes:
FILE: bip-0119/simulation.py
function get_rate (line 20) | def get_rate(phase):
function normal (line 26) | def normal():
function compressed (line 46) | def compressed(rate_multiplier = 1):
function make_patch_spines_invisible (line 79) | def make_patch_spines_invisible(ax):
FILE: bip-0158/gentestvectors.go
constant fp (line 50) | fp = 19
type testBlockCase (line 53) | type testBlockCase struct
type JSONTestWriter (line 58) | type JSONTestWriter struct
method WriteComment (line 67) | func (w *JSONTestWriter) WriteComment(comment string) error {
method WriteTestCase (line 71) | func (w *JSONTestWriter) WriteTestCase(row []interface{}) error {
method Close (line 92) | func (w *JSONTestWriter) Close() error {
function NewJSONTestWriter (line 63) | func NewJSONTestWriter(writer io.Writer) *JSONTestWriter {
function fetchPrevOutputScripts (line 101) | func fetchPrevOutputScripts(client *rpcclient.Client, block *wire.MsgBlo...
function main (line 139) | func main() {
FILE: bip-0324/gen_test_vectors.py
function xswiftec_flagged (line 26) | def xswiftec_flagged(u, t, simplified=False):
function ellswift_create_deterministic (line 58) | def ellswift_create_deterministic(seed, features):
function ellswift_decode_flagged (line 108) | def ellswift_decode_flagged(ellswift, simplified=False):
function random_fe_int (line 120) | def random_fe_int(_, seed, i, p):
function random_fe_int_high (line 125) | def random_fe_int_high(_, seed, i, p):
function fn_of (line 130) | def fn_of(p_in, fn):
function tuple_expand (line 139) | def tuple_expand(out, tuplespec, prio, seed=None, cnt=1):
function gen_ellswift_decode_cases (line 175) | def gen_ellswift_decode_cases(seed, simplified=False):
function gen_all_ellswift_decode_vectors (line 214) | def gen_all_ellswift_decode_vectors(fil):
function xswiftec_inv_flagged (line 223) | def xswiftec_inv_flagged(x, u, case):
function xswiftec_inv_combo_flagged (line 272) | def xswiftec_inv_combo_flagged(x, u):
function gen_all_xswiftec_inv_vectors (line 284) | def gen_all_xswiftec_inv_vectors(fil):
function gen_packet_encoding_vector (line 330) | def gen_packet_encoding_vector(case):
function gen_all_packet_encoding_vectors (line 375) | def gen_all_packet_encoding_vectors(fil):
FILE: bip-0324/reference.py
function TaggedHash (line 10) | def TaggedHash(tag, data):
function hmac_sha256 (line 19) | def hmac_sha256(key, data):
function hkdf_sha256 (line 23) | def hkdf_sha256(length, ikm, salt, info):
function modinv (line 37) | def modinv(a, n):
class FE (line 59) | class FE:
method __init__ (line 67) | def __init__(self, a=0, b=1):
method __add__ (line 86) | def __add__(self, a):
method __radd__ (line 92) | def __radd__(self, a):
method __sub__ (line 96) | def __sub__(self, a):
method __rsub__ (line 102) | def __rsub__(self, a):
method __mul__ (line 106) | def __mul__(self, a):
method __rmul__ (line 112) | def __rmul__(self, a):
method __truediv__ (line 116) | def __truediv__(self, a):
method __rtruediv__ (line 120) | def __rtruediv__(self, a):
method __pow__ (line 124) | def __pow__(self, a):
method __neg__ (line 128) | def __neg__(self):
method __int__ (line 132) | def __int__(self):
method sqrt (line 139) | def sqrt(self):
method sqrts (line 158) | def sqrts(self):
method cbrts (line 173) | def cbrts(self):
method is_square (line 193) | def is_square(self):
method __eq__ (line 212) | def __eq__(self, a):
method to_bytes (line 218) | def to_bytes(self):
method from_bytes (line 223) | def from_bytes(b):
method __str__ (line 230) | def __str__(self):
method __repr__ (line 234) | def __repr__(self):
class GE (line 240) | class GE:
method __init__ (line 248) | def __init__(self, x, y):
method double (line 256) | def double(self):
method __add__ (line 263) | def __add__(self, a):
method __radd__ (line 280) | def __radd__(self, a):
method __mul__ (line 285) | def __mul__(self, a):
method __rmul__ (line 295) | def __rmul__(self, a):
method lift_x (line 300) | def lift_x(x):
method is_valid_x (line 308) | def is_valid_x(x):
method __str__ (line 312) | def __str__(self):
method __repr__ (line 316) | def __repr__(self):
function xswiftec (line 329) | def xswiftec(u, t):
function xswiftec_inv (line 344) | def xswiftec_inv(x, u, case):
function xelligatorswift (line 372) | def xelligatorswift(x):
function ellswift_create (line 381) | def ellswift_create():
function ellswift_decode (line 387) | def ellswift_decode(ellswift):
function ellswift_ecdh_xonly (line 393) | def ellswift_ecdh_xonly(pubkey_theirs, privkey):
class Poly1305 (line 401) | class Poly1305:
method __init__ (line 405) | def __init__(self, key):
method add (line 410) | def add(self, msg, length=None, pad=False):
method tag (line 419) | def tag(self):
function rotl32 (line 432) | def rotl32(v, bits):
function chacha20_doubleround (line 436) | def chacha20_doubleround(s):
function chacha20_block (line 451) | def chacha20_block(key, nonce, cnt):
function aead_chacha20_poly1305_encrypt (line 477) | def aead_chacha20_poly1305_encrypt(key, nonce, aad, plaintext):
function aead_chacha20_poly1305_decrypt (line 492) | def aead_chacha20_poly1305_decrypt(key, nonce, aad, ciphertext):
class FSChaCha20Poly1305 (line 515) | class FSChaCha20Poly1305:
method __init__ (line 518) | def __init__(self, initial_key):
method crypt (line 522) | def crypt(self, aad, text, is_decrypt):
method encrypt (line 539) | def encrypt(self, aad, plaintext):
method decrypt (line 543) | def decrypt(self, aad, ciphertext):
class FSChaCha20 (line 548) | class FSChaCha20:
method __init__ (line 551) | def __init__(self, initial_key):
method get_keystream_bytes (line 557) | def get_keystream_bytes(self, nbytes):
method crypt (line 568) | def crypt(self, chunk):
method encrypt (line 578) | def encrypt(self, chunk):
method decrypt (line 582) | def decrypt(self, chunk):
function v2_ecdh (line 589) | def v2_ecdh(priv, ellswift_theirs, ellswift_ours, initiating):
function initialize_v2_transport (line 605) | def initialize_v2_transport(ecdh_secret, initiating):
function v2_enc_packet (line 641) | def v2_enc_packet(peer, contents, aad=b'', ignore=False):
FILE: bip-0324/secp256k1_test_vectors.py
function format_int (line 11) | def format_int(v):
function format_fe (line 17) | def format_fe(fe):
function output_xswiftec_inv_cases (line 23) | def output_xswiftec_inv_cases():
function output_ellswift_decode_cases (line 38) | def output_ellswift_decode_cases():
FILE: bip-0324/test_sage_decoding.py
function ellswift_decode_sage (line 36) | def ellswift_decode_sage(ellswift):
FILE: bip-0327/gen_vectors_helper.py
function gen_key_agg_vectors (line 3) | def gen_key_agg_vectors():
function check_sign_verify_vectors (line 18) | def check_sign_verify_vectors():
function check_tweak_vectors (line 46) | def check_tweak_vectors():
function sig_agg_vectors (line 67) | def sig_agg_vectors():
FILE: bip-0327/reference.py
function tagged_hash (line 28) | def tagged_hash(tag: str, msg: bytes) -> bytes:
function is_infinite (line 32) | def is_infinite(P: Optional[Point]) -> bool:
function x (line 35) | def x(P: Point) -> int:
function y (line 39) | def y(P: Point) -> int:
function point_add (line 43) | def point_add(P1: Optional[Point], P2: Optional[Point]) -> Optional[Point]:
function point_mul (line 57) | def point_mul(P: Optional[Point], n: int) -> Optional[Point]:
function bytes_from_int (line 65) | def bytes_from_int(x: int) -> bytes:
function lift_x (line 68) | def lift_x(b: bytes) -> Optional[Point]:
function int_from_bytes (line 78) | def int_from_bytes(b: bytes) -> int:
function has_even_y (line 81) | def has_even_y(P: Point) -> bool:
function schnorr_verify (line 85) | def schnorr_verify(msg: bytes, pubkey: bytes, sig: bytes) -> bool:
class InvalidContributionError (line 125) | class InvalidContributionError(Exception):
method __init__ (line 126) | def __init__(self, signer, contrib):
function xbytes (line 133) | def xbytes(P: Point) -> bytes:
function cbytes (line 136) | def cbytes(P: Point) -> bytes:
function cbytes_ext (line 140) | def cbytes_ext(P: Optional[Point]) -> bytes:
function point_negate (line 146) | def point_negate(P: Optional[Point]) -> Optional[Point]:
function cpoint (line 151) | def cpoint(x: bytes) -> Point:
function cpoint_ext (line 166) | def cpoint_ext(x: bytes) -> Optional[Point]:
function individual_pk (line 173) | def individual_pk(seckey: bytes) -> PlainPk:
function key_sort (line 181) | def key_sort(pubkeys: List[PlainPk]) -> List[PlainPk]:
function get_xonly_pk (line 189) | def get_xonly_pk(keyagg_ctx: KeyAggContext) -> XonlyPk:
function key_agg (line 193) | def key_agg(pubkeys: List[PlainPk]) -> KeyAggContext:
function hash_keys (line 210) | def hash_keys(pubkeys: List[PlainPk]) -> bytes:
function get_second_key (line 213) | def get_second_key(pubkeys: List[PlainPk]) -> PlainPk:
function key_agg_coeff (line 220) | def key_agg_coeff(pubkeys: List[PlainPk], pk_: PlainPk) -> int:
function key_agg_coeff_internal (line 224) | def key_agg_coeff_internal(pubkeys: List[PlainPk], pk_: PlainPk, pk2: Pl...
function apply_tweak (line 230) | def apply_tweak(keyagg_ctx: KeyAggContext, tweak: bytes, is_xonly: bool)...
function bytes_xor (line 248) | def bytes_xor(a: bytes, b: bytes) -> bytes:
function nonce_hash (line 251) | def nonce_hash(rand: bytes, pk: PlainPk, aggpk: XonlyPk, i: int, msg_pre...
function nonce_gen_internal (line 264) | def nonce_gen_internal(rand_: bytes, sk: Optional[bytes], pk: PlainPk, a...
function nonce_gen (line 292) | def nonce_gen(sk: Optional[bytes], pk: PlainPk, aggpk: Optional[XonlyPk]...
function nonce_agg (line 300) | def nonce_agg(pubnonces: List[bytes]) -> bytes:
function key_agg_and_tweak (line 320) | def key_agg_and_tweak(pubkeys: List[PlainPk], tweaks: List[bytes], is_xo...
function get_session_values (line 329) | def get_session_values(session_ctx: SessionContext) -> Tuple[Point, int,...
function get_session_key_agg_coeff (line 345) | def get_session_key_agg_coeff(session_ctx: SessionContext, P: Point) -> ...
function sign (line 352) | def sign(secnonce: bytearray, sk: bytes, session_ctx: SessionContext) ->...
function det_nonce_hash (line 387) | def det_nonce_hash(sk_: bytes, aggothernonce: bytes, aggpk: bytes, msg: ...
function deterministic_sign (line 397) | def deterministic_sign(sk: bytes, aggothernonce: bytes, pubkeys: List[Pl...
function partial_sig_verify (line 424) | def partial_sig_verify(psig: bytes, pubnonces: List[bytes], pubkeys: Lis...
function partial_sig_verify_internal (line 433) | def partial_sig_verify_internal(psig: bytes, pubnonce: bytes, pk: bytes,...
function partial_sig_agg (line 448) | def partial_sig_agg(psigs: List[bytes], session_ctx: SessionContext) -> ...
function fromhex_all (line 468) | def fromhex_all(l):
function assert_raises (line 472) | def assert_raises(exception, try_fn, except_fn):
function get_error_details (line 484) | def get_error_details(test_case):
function test_key_sort_vectors (line 499) | def test_key_sort_vectors() -> None:
function test_key_agg_vectors (line 508) | def test_key_agg_vectors() -> None:
function test_nonce_gen_vectors (line 532) | def test_nonce_gen_vectors() -> None:
function test_nonce_agg_vectors (line 559) | def test_nonce_agg_vectors() -> None:
function test_sign_verify_vectors (line 577) | def test_sign_verify_vectors() -> None:
function test_tweak_vectors (line 660) | def test_tweak_vectors() -> None:
function test_det_sign_vectors (line 717) | def test_det_sign_vectors() -> None:
function test_sig_agg_vectors (line 764) | def test_sig_agg_vectors() -> None:
function test_sign_and_verify_random (line 813) | def test_sign_and_verify_random(iters: int) -> None:
FILE: bip-0328/_base58.py
function encode (line 24) | def encode(b: bytes) -> str:
function decode (line 52) | def decode(s: str) -> bytes:
function decode_check (line 86) | def decode_check(s: str) -> bytes:
function encode_check (line 101) | def encode_check(b: bytes) -> str:
function get_xpub_fingerprint (line 106) | def get_xpub_fingerprint(s: str) -> bytes:
function get_xpub_fingerprint_hex (line 117) | def get_xpub_fingerprint_hex(xpub: str) -> str:
function to_address (line 128) | def to_address(b: bytes, version: bytes) -> str:
function xpub_to_pub_hex (line 142) | def xpub_to_pub_hex(xpub: str) -> str:
function xpub_to_xonly_pub_hex (line 154) | def xpub_to_xonly_pub_hex(xpub: str) -> str:
function xpub_main_2_test (line 166) | def xpub_main_2_test(xpub: str) -> str:
FILE: bip-0328/_common.py
function sha256 (line 8) | def sha256(s: bytes) -> bytes:
function ripemd160 (line 18) | def ripemd160(s: bytes) -> bytes:
function hash256 (line 28) | def hash256(s: bytes) -> bytes:
function hash160 (line 40) | def hash160(s: bytes) -> bytes:
FILE: bip-0328/_xpub.py
function H_ (line 38) | def H_(x: int) -> int:
function is_hardened (line 44) | def is_hardened(i: int) -> bool:
function point_add (line 51) | def point_add(p1: Point, p2: Point) -> Point:
function point_mul (line 66) | def point_mul(p: Point, n: int) -> Point:
function deserialize_point (line 75) | def deserialize_point(b: bytes) -> Point:
function bytes_to_point (line 83) | def bytes_to_point(point_bytes: bytes) -> Point:
function point_to_bytes (line 91) | def point_to_bytes(p: Point) -> bytes:
class ExtendedKey (line 99) | class ExtendedKey(object):
method __init__ (line 109) | def __init__(self, version: bytes, depth: int, parent_fingerprint: byt...
method deserialize (line 130) | def deserialize(cls, xpub: str) -> 'ExtendedKey':
method from_bytes (line 140) | def from_bytes(cls, data: bytes) -> 'ExtendedKey':
method serialize (line 164) | def serialize(self) -> bytes:
method to_string (line 180) | def to_string(self) -> str:
method get_printable_dict (line 190) | def get_printable_dict(self) -> Dict[str, object]:
method derive_pub (line 208) | def derive_pub(self, i: int) -> 'ExtendedKey':
method derive_pub_path (line 235) | def derive_pub_path(self, path: Sequence[int]) -> 'ExtendedKey':
FILE: bip-0328/reference.py
function aggregate_to_xpub (line 13) | def aggregate_to_xpub(aggregate: bytes) -> ExtendedKey:
function test_aggregate_to_xpub (line 16) | def test_aggregate_to_xpub():
FILE: bip-0330/minisketch.py
function mul2 (line 10) | def mul2(x):
function mul (line 14) | def mul(x, y):
function sketch (line 24) | def sketch(shortids, capacity):
function inv (line 36) | def inv(x):
function berlekamp_massey (line 44) | def berlekamp_massey(s):
function poly_monic (line 66) | def poly_monic(p):
function poly_divmod (line 73) | def poly_divmod(m, p):
function poly_gcd (line 87) | def poly_gcd(a, b):
function poly_sqr (line 99) | def poly_sqr(p):
function poly_trace (line 103) | def poly_trace(m, a):
function find_roots_inner (line 114) | def find_roots_inner(p, a):
function find_roots (line 133) | def find_roots(p):
function decode (line 147) | def decode(sketch):
FILE: bip-0340/reference.py
function tagged_hash (line 24) | def tagged_hash(tag: str, msg: bytes) -> bytes:
function is_infinite (line 28) | def is_infinite(P: Optional[Point]) -> bool:
function x (line 31) | def x(P: Point) -> int:
function y (line 35) | def y(P: Point) -> int:
function point_add (line 39) | def point_add(P1: Optional[Point], P2: Optional[Point]) -> Optional[Point]:
function point_mul (line 53) | def point_mul(P: Optional[Point], n: int) -> Optional[Point]:
function bytes_from_int (line 61) | def bytes_from_int(x: int) -> bytes:
function bytes_from_point (line 64) | def bytes_from_point(P: Point) -> bytes:
function xor_bytes (line 67) | def xor_bytes(b0: bytes, b1: bytes) -> bytes:
function lift_x (line 70) | def lift_x(x: int) -> Optional[Point]:
function int_from_bytes (line 79) | def int_from_bytes(b: bytes) -> int:
function hash_sha256 (line 82) | def hash_sha256(b: bytes) -> bytes:
function has_even_y (line 85) | def has_even_y(P: Point) -> bool:
function pubkey_gen (line 89) | def pubkey_gen(seckey: bytes) -> bytes:
function schnorr_sign (line 97) | def schnorr_sign(msg: bytes, seckey: bytes, aux_rand: bytes) -> bytes:
function schnorr_verify (line 120) | def schnorr_verify(msg: bytes, pubkey: bytes, sig: bytes) -> bool:
function test_vectors (line 146) | def test_vectors() -> bool:
function pretty (line 201) | def pretty(v: Any) -> Any:
function debug_print_vars (line 210) | def debug_print_vars() -> None:
FILE: bip-0340/test-vectors.py
function is_square (line 4) | def is_square(x):
function has_square_y (line 7) | def has_square_y(P):
function vector0 (line 12) | def vector0():
function vector1 (line 42) | def vector1():
function vector2 (line 55) | def vector2():
function vector3 (line 73) | def vector3():
function insecure_schnorr_sign_fixed_nonce (line 90) | def insecure_schnorr_sign_fixed_nonce(msg, seckey0, k):
function vector4 (line 103) | def vector4():
function vector5 (line 115) | def vector5():
function vector6 (line 128) | def vector6():
function vector7 (line 140) | def vector7():
function vector8 (line 147) | def vector8():
function bytes_from_point_inf0 (line 154) | def bytes_from_point_inf0(P):
function vector9 (line 159) | def vector9():
function bytes_from_point_inf1 (line 173) | def bytes_from_point_inf1(P):
function vector10 (line 178) | def vector10():
function vector11 (line 195) | def vector11():
function vector12 (line 210) | def vector12():
function vector13 (line 223) | def vector13():
function vector14 (line 238) | def vector14():
function varlen_vector (line 253) | def varlen_vector(msg_int):
function bytes_to_hex (line 290) | def bytes_to_hex(seckey, pubkey, aux_rand, msg, sig, result, comment):
function print_csv (line 295) | def print_csv(vectors):
FILE: bip-0346/ref-impl/src/main.rs
constant TXFS_VERSION (line 6) | pub const TXFS_VERSION: u8 = 1 << 0;
constant TXFS_LOCKTIME (line 7) | pub const TXFS_LOCKTIME: u8 = 1 << 1;
constant TXFS_CURRENT_INPUT_IDX (line 8) | pub const TXFS_CURRENT_INPUT_IDX: u8 = 1 << 2;
constant TXFS_CURRENT_INPUT_CONTROL_BLOCK (line 9) | pub const TXFS_CURRENT_INPUT_CONTROL_BLOCK: u8 = 1 << 3;
constant TXFS_CURRENT_INPUT_SPENTSCRIPT (line 10) | pub const TXFS_CURRENT_INPUT_SPENTSCRIPT: u8 = 1 << 4;
constant TXFS_CURRENT_INPUT_LAST_CODESEPARATOR_POS (line 11) | pub const TXFS_CURRENT_INPUT_LAST_CODESEPARATOR_POS: u8 = 1 << 5;
constant TXFS_CURRENT_INPUT_TAPROOT_ANNEX (line 12) | pub const TXFS_CURRENT_INPUT_TAPROOT_ANNEX: u8 = 1 << 6;
constant TXFS_CONTROL (line 13) | pub const TXFS_CONTROL: u8 = 1 << 7;
constant TXFS_INPUTS_PREVOUTS (line 15) | pub const TXFS_INPUTS_PREVOUTS: u8 = 1 << 0;
constant TXFS_INPUTS_SEQUENCES (line 16) | pub const TXFS_INPUTS_SEQUENCES: u8 = 1 << 1;
constant TXFS_INPUTS_SCRIPTSIGS (line 17) | pub const TXFS_INPUTS_SCRIPTSIGS: u8 = 1 << 2;
constant TXFS_INPUTS_PREV_SCRIPTPUBKEYS (line 18) | pub const TXFS_INPUTS_PREV_SCRIPTPUBKEYS: u8 = 1 << 3;
constant TXFS_INPUTS_PREV_VALUES (line 19) | pub const TXFS_INPUTS_PREV_VALUES: u8 = 1 << 4;
constant TXFS_INPUTS_TAPROOT_ANNEXES (line 20) | pub const TXFS_INPUTS_TAPROOT_ANNEXES: u8 = 1 << 5;
constant TXFS_OUTPUTS_SCRIPTPUBKEYS (line 21) | pub const TXFS_OUTPUTS_SCRIPTPUBKEYS: u8 = 1 << 6;
constant TXFS_OUTPUTS_VALUES (line 22) | pub const TXFS_OUTPUTS_VALUES: u8 = 1 << 7;
constant TXFS_INPUTS_ALL (line 24) | pub const TXFS_INPUTS_ALL: u8 = TXFS_INPUTS_PREVOUTS
constant TXFS_OUTPUTS_ALL (line 30) | pub const TXFS_OUTPUTS_ALL: u8 = TXFS_OUTPUTS_SCRIPTPUBKEYS | TXFS_OUTPU...
constant TXFS_INOUT_NUMBER (line 32) | pub const TXFS_INOUT_NUMBER: u8 = 1 << 7;
constant TXFS_INOUT_SELECTION_NONE (line 33) | pub const TXFS_INOUT_SELECTION_NONE: u8 = 0x00;
constant TXFS_INOUT_SELECTION_CURRENT (line 34) | pub const TXFS_INOUT_SELECTION_CURRENT: u8 = 0x40;
constant TXFS_INOUT_SELECTION_ALL (line 35) | pub const TXFS_INOUT_SELECTION_ALL: u8 = 0x3f;
constant TXFS_INOUT_SELECTION_MODE (line 36) | pub const TXFS_INOUT_SELECTION_MODE: u8 = 1 << 6;
constant TXFS_INOUT_LEADING_SIZE (line 37) | pub const TXFS_INOUT_LEADING_SIZE: u8 = 1 << 5;
constant TXFS_INOUT_INDIVIDUAL_MODE (line 38) | pub const TXFS_INOUT_INDIVIDUAL_MODE: u8 = 1 << 5;
constant TXFS_INOUT_SELECTION_MASK (line 39) | pub const TXFS_INOUT_SELECTION_MASK: u8 = 0xff ^ (1 << 7) ^ (1 << 6) ^ (...
constant TXFS_SPECIAL_TEMPLATE (line 42) | pub const TXFS_SPECIAL_TEMPLATE: [u8; 4] = [
constant SHA256_EMPTY (line 49) | const SHA256_EMPTY: sha256::Hash = sha256::Hash::const_hash(&[]);
function read_i7 (line 53) | fn read_i7(input: u8) -> i8 {
function read_i15 (line 64) | fn read_i15(input: u16) -> i16 {
function convert_short_txfs (line 73) | fn convert_short_txfs(txfs: u8) -> Result<[u8; 4], &'static str> {
function parse_inout_selection (line 113) | fn parse_inout_selection(
function calculate_txhash (line 195) | pub fn calculate_txhash(
function test_vector_tx (line 407) | fn test_vector_tx() -> (Transaction, Vec<TxOut>) {
type TestCase (line 499) | struct TestCase {
type TestVector (line 506) | struct TestVector {
function generate_vectors (line 513) | fn generate_vectors() -> Vec<TestCase> {
function write_vector_file (line 671) | pub fn write_vector_file(path: impl AsRef<std::path::Path>) {
function main (line 691) | fn main() {
FILE: bip-0352/bech32m.py
class Encoding (line 26) | class Encoding(Enum):
function bech32_polymod (line 34) | def bech32_polymod(values):
function bech32_hrp_expand (line 46) | def bech32_hrp_expand(hrp):
function bech32_verify_checksum (line 51) | def bech32_verify_checksum(hrp, data):
function bech32_create_checksum (line 60) | def bech32_create_checksum(hrp, data, spec):
function bech32_encode (line 68) | def bech32_encode(hrp, data, spec):
function bech32_decode (line 73) | def bech32_decode(bech):
function convertbits (line 93) | def convertbits(data, frombits, tobits, pad=True):
function decode (line 116) | def decode(hrp, addr):
function encode (line 129) | def encode(hrp, witver, witprog):
FILE: bip-0352/bitcoin_utils.py
function from_hex (line 9) | def from_hex(hex_string):
function ser_uint32 (line 14) | def ser_uint32(u: int) -> bytes:
function ser_uint256 (line 18) | def ser_uint256(u):
function deser_uint256 (line 22) | def deser_uint256(f):
function deser_txid (line 26) | def deser_txid(txid: str):
function deser_compact_size (line 34) | def deser_compact_size(f: BytesIO):
function deser_string (line 51) | def deser_string(f: BytesIO):
function deser_string_vector (line 56) | def deser_string_vector(f: BytesIO):
class COutPoint (line 65) | class COutPoint:
method __init__ (line 68) | def __init__(self, hash=b"", n=0,):
method serialize (line 72) | def serialize(self):
method deserialize (line 78) | def deserialize(self, f):
class VinInfo (line 83) | class VinInfo:
method __init__ (line 86) | def __init__(self, outpoint=None, scriptSig=b"", txinwitness=None, pre...
class CScriptWitness (line 103) | class CScriptWitness:
method __init__ (line 106) | def __init__(self):
method is_null (line 110) | def is_null(self):
class CTxInWitness (line 116) | class CTxInWitness:
method __init__ (line 119) | def __init__(self):
method deserialize (line 122) | def deserialize(self, f: BytesIO):
method is_null (line 126) | def is_null(self):
function hash160 (line 130) | def hash160(s: Union[bytes, bytearray]) -> bytes:
function is_p2tr (line 134) | def is_p2tr(spk: bytes) -> bool:
function is_p2wpkh (line 141) | def is_p2wpkh(spk: bytes) -> bool:
function is_p2sh (line 148) | def is_p2sh(spk: bytes) -> bool:
function is_p2pkh (line 155) | def is_p2pkh(spk: bytes) -> bool:
FILE: bip-0352/reference.py
function get_pubkey_from_input (line 37) | def get_pubkey_from_input(vin: VinInfo) -> GE:
function get_input_hash (line 95) | def get_input_hash(outpoints: List[COutPoint], sum_input_pubkeys: GE) ->...
function encode_silent_payment_address (line 101) | def encode_silent_payment_address(B_scan: GE, B_m: GE, hrp: str = "tsp",...
function generate_label (line 106) | def generate_label(b_scan: Scalar, m: int) -> Scalar:
function create_labeled_silent_payment_address (line 110) | def create_labeled_silent_payment_address(b_scan: Scalar, B_spend: GE, m...
function decode_silent_payment_address (line 118) | def decode_silent_payment_address(address: str, hrp: str = "tsp") -> Tup...
function create_outputs (line 128) | def create_outputs(input_priv_keys: List[Tuple[Scalar, bool]], outpoints...
function scanning (line 180) | def scanning(b_scan: Scalar, B_spend: GE, A_sum: GE, input_hash: bytes, ...
FILE: bip-0352/ripemd160.py
function fi (line 51) | def fi(x, y, z, i):
function rol (line 67) | def rol(x, i):
function compress (line 72) | def compress(h0, h1, h2, h3, h4, block):
function ripemd160 (line 95) | def ripemd160(data):
class TestFrameworkKey (line 112) | class TestFrameworkKey(unittest.TestCase):
method test_ripemd160 (line 113) | def test_ripemd160(self):
FILE: bip-0352/secp256k1lab/src/secp256k1lab/bip340.py
function pubkey_gen (line 8) | def pubkey_gen(seckey: bytes) -> bytes:
function schnorr_sign (line 17) | def schnorr_sign(
function schnorr_verify (line 51) | def schnorr_verify(
FILE: bip-0352/secp256k1lab/src/secp256k1lab/ecdh.py
function ecdh_compressed_in_raw_out (line 6) | def ecdh_compressed_in_raw_out(seckey: bytes, pubkey: bytes) -> GE:
function ecdh_libsecp256k1 (line 13) | def ecdh_libsecp256k1(seckey: bytes, pubkey: bytes) -> bytes:
FILE: bip-0352/secp256k1lab/src/secp256k1lab/keys.py
function pubkey_gen_plain (line 9) | def pubkey_gen_plain(seckey: bytes) -> bytes:
FILE: bip-0352/secp256k1lab/src/secp256k1lab/secp256k1.py
class APrimeFE (line 19) | class APrimeFE:
method __init__ (line 28) | def __init__(self, a=0, b=1):
method __add__ (line 47) | def __add__(self, a):
method __radd__ (line 55) | def __radd__(self, a):
method sum (line 63) | def sum(cls, *es):
method __sub__ (line 69) | def __sub__(self, a):
method __rsub__ (line 77) | def __rsub__(self, a):
method __mul__ (line 81) | def __mul__(self, a):
method __rmul__ (line 89) | def __rmul__(self, a):
method __truediv__ (line 93) | def __truediv__(self, a):
method __pow__ (line 99) | def __pow__(self, a):
method __neg__ (line 103) | def __neg__(self):
method __int__ (line 107) | def __int__(self):
method sqrt (line 114) | def sqrt(self):
method is_square (line 118) | def is_square(self):
method is_even (line 123) | def is_even(self):
method __eq__ (line 127) | def __eq__(self, a):
method to_bytes (line 133) | def to_bytes(self):
method from_int_checked (line 138) | def from_int_checked(cls, v):
method from_int_wrapping (line 145) | def from_int_wrapping(cls, v):
method from_bytes_checked (line 150) | def from_bytes_checked(cls, b):
method from_bytes_wrapping (line 156) | def from_bytes_wrapping(cls, b):
method __str__ (line 161) | def __str__(self):
method __repr__ (line 165) | def __repr__(self):
class FE (line 170) | class FE(APrimeFE):
method sqrt (line 173) | def sqrt(self):
class Scalar (line 191) | class Scalar(APrimeFE):
class GE (line 196) | class GE:
method infinity (line 221) | def infinity(self):
method x (line 226) | def x(self):
method y (line 232) | def y(self):
method __init__ (line 237) | def __init__(self, x=None, y=None):
method __add__ (line 252) | def __add__(self, a):
method sum (line 276) | def sum(*ps):
method batch_mul (line 283) | def batch_mul(*aps):
method __rmul__ (line 302) | def __rmul__(self, a):
method __neg__ (line 308) | def __neg__(self):
method __sub__ (line 314) | def __sub__(self, a):
method __eq__ (line 318) | def __eq__(self, a):
method has_even_y (line 322) | def has_even_y(self):
method to_bytes_compressed (line 327) | def to_bytes_compressed(self):
method to_bytes_compressed_with_infinity (line 332) | def to_bytes_compressed_with_infinity(self):
method to_bytes_uncompressed (line 338) | def to_bytes_uncompressed(self):
method to_bytes_xonly (line 343) | def to_bytes_xonly(self):
method lift_x (line 349) | def lift_x(x):
method from_bytes_compressed (line 359) | def from_bytes_compressed(b):
method from_bytes_uncompressed (line 371) | def from_bytes_uncompressed(b):
method from_bytes (line 383) | def from_bytes(b):
method from_bytes_xonly (line 392) | def from_bytes_xonly(b):
method is_valid_x (line 400) | def is_valid_x(x):
method __str__ (line 404) | def __str__(self):
method __repr__ (line 410) | def __repr__(self):
method __hash__ (line 416) | def __hash__(self):
class FastGEMul (line 427) | class FastGEMul:
method __init__ (line 439) | def __init__(self, p):
method mul (line 445) | def mul(self, a):
FILE: bip-0352/secp256k1lab/src/secp256k1lab/util.py
function tagged_hash (line 6) | def tagged_hash(tag: str, msg: bytes) -> bytes:
function bytes_from_int (line 11) | def bytes_from_int(x: int) -> bytes:
function xor_bytes (line 15) | def xor_bytes(b0: bytes, b1: bytes) -> bytes:
function int_from_bytes (line 19) | def int_from_bytes(b: bytes) -> int:
function hash_sha256 (line 23) | def hash_sha256(b: bytes) -> bytes:
FILE: bip-0360/ref-impl/js/src/p2mr-example.ts
function signAndVerify (line 20) | function signAndVerify(
function example1_simpleScriptTree (line 43) | function example1_simpleScriptTree() {
function example2_multiLeafScriptTree (line 86) | function example2_multiLeafScriptTree() {
function example3_fromHashAndRedeem (line 150) | function example3_fromHashAndRedeem() {
FILE: bip-0360/ref-impl/js/src/test-npm-pqc-package.js
function generateRandomBytes (line 33) | function generateRandomBytes(length) {
function testAlgorithm (line 41) | async function testAlgorithm(algorithm, name) {
function runTests (line 142) | async function runTests() {
FILE: bip-0360/ref-impl/rust/examples/p2mr_construction.rs
function main (line 7) | fn main() -> ConstructionReturn {
FILE: bip-0360/ref-impl/rust/examples/p2mr_spend.rs
function main (line 8) | fn main() -> SpendDetails {
FILE: bip-0360/ref-impl/rust/examples/p2tr_construction.rs
function main (line 5) | fn main() -> ConstructionReturn {
FILE: bip-0360/ref-impl/rust/examples/p2tr_spend.rs
function main (line 8) | fn main() -> SpendDetails {
FILE: bip-0360/ref-impl/rust/examples/schnorr_example.rs
function main (line 18) | fn main() {
FILE: bip-0360/ref-impl/rust/examples/slh_dsa_verification_example.rs
function main (line 11) | fn main() {
function get_random_bytes (line 73) | fn get_random_bytes(size: usize) -> Vec<u8> {
FILE: bip-0360/ref-impl/rust/src/bin/slh_dsa_key_gen.rs
function main (line 9) | fn main() {
function get_random_bytes (line 29) | fn get_random_bytes(size: usize) -> Vec<u8> {
FILE: bip-0360/ref-impl/rust/src/data_structures.rs
type LeafScriptType (line 11) | pub enum LeafScriptType {
method uses_slh_dsa (line 26) | pub fn uses_slh_dsa(&self) -> bool {
method uses_schnorr (line 31) | pub fn uses_schnorr(&self) -> bool {
method requires_both (line 36) | pub fn requires_both(&self) -> bool {
method uses_mixed (line 41) | pub fn uses_mixed(&self) -> bool {
method is_not_applicable (line 46) | pub fn is_not_applicable(&self) -> bool {
method to_string (line 51) | pub fn to_string(&self) -> String {
method from_string (line 62) | pub fn from_string(s: &str) -> Self {
type TestVectors (line 74) | pub struct TestVectors {
method deserialize (line 83) | fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
type TestVector (line 110) | pub struct TestVector {
type TestVectorGiven (line 119) | pub struct TestVectorGiven {
type TestVectorIntermediary (line 136) | pub struct TestVectorIntermediary {
type TestVectorExpected (line 147) | pub struct TestVectorExpected {
type TVScriptLeaf (line 164) | pub struct TVScriptLeaf {
type TVScriptTree (line 173) | pub enum TVScriptTree {
method deserialize (line 187) | fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
method traverse_with_depth (line 222) | pub fn traverse_with_depth<F: FnMut(&TVScriptTree, u8, Direction)>(&se...
method traverse_with_right_subtree_first (line 248) | pub fn traverse_with_right_subtree_first<F: FnMut(&TVScriptTree, u8, D...
type Direction (line 214) | pub enum Direction {
method fmt (line 265) | fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
type ScriptTreeHashCache (line 274) | pub struct ScriptTreeHashCache {
method new (line 280) | pub fn new() -> Self {
method set_leaf_hash (line 287) | pub fn set_leaf_hash(&mut self, branch_id: u8, direction: Direction, h...
method set_branch_hash (line 293) | pub fn set_branch_hash(&mut self, branch_id: u8, hash: String) {
function serialize_hex (line 298) | fn serialize_hex<S>(bytes: &Vec<u8>, s: S) -> Result<S::Ok, S::Error>
function deserialize_hex (line 305) | fn deserialize_hex<'de, D>(d: D) -> Result<Vec<u8>, D::Error>
type SpendDetails (line 314) | pub struct SpendDetails {
method report (line 328) | fn report(self) -> std::process::ExitCode {
type UtxoReturn (line 339) | pub struct UtxoReturn {
method report (line 347) | fn report(self) -> std::process::ExitCode {
type TaptreeReturn (line 358) | pub struct TaptreeReturn {
method report (line 368) | fn report(self) -> std::process::ExitCode {
type ConstructionReturn (line 379) | pub struct ConstructionReturn {
method report (line 385) | fn report(self) -> std::process::ExitCode {
type UnifiedKeypair (line 397) | pub enum UnifiedKeypair {
method new_schnorr (line 537) | pub fn new_schnorr(secret_key: SecretKey, public_key: XOnlyPublicKey) ...
method new_slh_dsa (line 542) | pub fn new_slh_dsa(keypair: KeyPair) -> Self {
method secret_key_bytes (line 547) | pub fn secret_key_bytes(&self) -> Vec<u8> {
method public_key_bytes (line 555) | pub fn public_key_bytes(&self) -> Vec<u8> {
method algorithm (line 563) | pub fn algorithm(&self) -> &'static str {
method is_schnorr (line 571) | pub fn is_schnorr(&self) -> bool {
method is_slh_dsa (line 576) | pub fn is_slh_dsa(&self) -> bool {
method as_schnorr (line 581) | pub fn as_schnorr(&self) -> Option<(&SecretKey, &XOnlyPublicKey)> {
method as_slh_dsa (line 589) | pub fn as_slh_dsa(&self) -> Option<&KeyPair> {
type MultiKeypair (line 404) | pub struct MultiKeypair {
method new_schnorr_only (line 411) | pub fn new_schnorr_only(schnorr_keypair: UnifiedKeypair) -> Self {
method new_slh_dsa_only (line 419) | pub fn new_slh_dsa_only(slh_dsa_keypair: UnifiedKeypair) -> Self {
method new_combined (line 427) | pub fn new_combined(schnorr_keypair: UnifiedKeypair, slh_dsa_keypair: ...
method secret_key_bytes (line 435) | pub fn secret_key_bytes(&self) -> Vec<Vec<u8>> {
method public_key_bytes (line 447) | pub fn public_key_bytes(&self) -> Vec<Vec<u8>> {
method has_schnorr (line 459) | pub fn has_schnorr(&self) -> bool {
method has_slh_dsa (line 464) | pub fn has_slh_dsa(&self) -> bool {
method schnorr_keypair (line 469) | pub fn schnorr_keypair(&self) -> Option<&UnifiedKeypair> {
method slh_dsa_keypair (line 474) | pub fn slh_dsa_keypair(&self) -> Option<&UnifiedKeypair> {
type MixedLeafInfo (line 482) | pub struct MixedLeafInfo {
method new_schnorr (line 495) | pub fn new_schnorr(leaf_index: u32, keypairs: MultiKeypair, script: Ve...
method new_slh_dsa (line 505) | pub fn new_slh_dsa(leaf_index: u32, keypairs: MultiKeypair, script: Ve...
method new_combined (line 515) | pub fn new_combined(leaf_index: u32, keypairs: MultiKeypair, script: V...
method secret_key_bytes (line 525) | pub fn secret_key_bytes(&self) -> Vec<Vec<u8>> {
method public_key_bytes (line 530) | pub fn public_key_bytes(&self) -> Vec<Vec<u8>> {
FILE: bip-0360/ref-impl/rust/src/error.rs
type P2MRError (line 4) | pub enum P2MRError {
FILE: bip-0360/ref-impl/rust/src/lib.rs
function create_huffman_tree (line 43) | fn create_huffman_tree(leaf_script_type: LeafScriptType) -> (Vec<(u32, S...
function tap_tree_lock_type (line 178) | pub fn tap_tree_lock_type() -> LeafScriptType {
function create_p2mr_multi_leaf_taptree (line 197) | pub fn create_p2mr_multi_leaf_taptree() -> TaptreeReturn {
function create_p2tr_multi_leaf_taptree (line 254) | pub fn create_p2tr_multi_leaf_taptree(p2tr_internal_pubkey_hex: String) ...
function get_bitcoin_network (line 313) | pub fn get_bitcoin_network() -> Network {
function create_p2mr_utxo (line 332) | pub fn create_p2mr_utxo(merkle_root_hex: String) -> UtxoReturn {
function pay_to_p2wpkh_tx (line 359) | pub fn pay_to_p2wpkh_tx(
function create_p2tr_utxo (line 538) | pub fn create_p2tr_utxo(merkle_root_hex: String, internal_pubkey_hex: St...
function tagged_hash (line 573) | pub fn tagged_hash(tag: &str, data: &[u8]) -> String {
function serialize_script (line 588) | pub fn serialize_script(script: &Vec<u8>) -> Vec<u8> {
function compact_size (line 600) | fn compact_size(n: u64) -> Vec<u8> {
function acquire_schnorr_keypair (line 618) | pub fn acquire_schnorr_keypair() -> UnifiedKeypair {
function verify_schnorr_signature_via_bytes (line 638) | pub fn verify_schnorr_signature_via_bytes(signature: &[u8], message: &[u...
function verify_slh_dsa_via_bytes (line 651) | pub fn verify_slh_dsa_via_bytes(signature: &[u8], message: &[u8], pubkey...
function verify_schnorr_signature (line 669) | pub fn verify_schnorr_signature(mut signature: Signature, message: Messa...
function verify_taproot_commitment (line 696) | pub fn verify_taproot_commitment(control_block_hex: String, output_key: ...
function acquire_slh_dsa_keypair (line 704) | fn acquire_slh_dsa_keypair() -> UnifiedKeypair {
function get_random_bytes (line 717) | fn get_random_bytes(size: usize) -> Vec<u8> {
FILE: bip-0360/ref-impl/rust/tests/p2mr_construction.rs
function test_p2tr_using_v2_witness_version_error (line 34) | fn test_p2tr_using_v2_witness_version_error() {
function test_p2mr_missing_leaf_script_tree_error (line 47) | fn test_p2mr_missing_leaf_script_tree_error() {
function test_p2mr_single_leaf_script_tree (line 60) | fn test_p2mr_single_leaf_script_tree() {
function test_p2mr_different_version_leaves (line 69) | fn test_p2mr_different_version_leaves() {
function test_p2mr_simple_lightning_contract (line 79) | fn test_p2mr_simple_lightning_contract() {
function test_p2mr_two_leaf_same_version (line 89) | fn test_p2mr_two_leaf_same_version() {
function test_p2mr_three_leaf_complex (line 99) | fn test_p2mr_three_leaf_complex() {
function test_p2mr_three_leaf_alternative (line 109) | fn test_p2mr_three_leaf_alternative() {
function process_test_vector_p2tr (line 118) | fn process_test_vector_p2tr(test_vector: &TestVector) -> anyhow::Result<...
function process_test_vector_p2mr (line 127) | fn process_test_vector_p2mr(test_vector: &TestVector) -> anyhow::Result<...
FILE: bip-0360/ref-impl/rust/tests/p2mr_pqc_construction.rs
function test_p2mr_pqc_missing_leaf_script_tree_error (line 34) | fn test_p2mr_pqc_missing_leaf_script_tree_error() {
function test_p2mr_pqc_single_leaf_script_tree (line 47) | fn test_p2mr_pqc_single_leaf_script_tree() {
function test_p2mr_pqc_different_version_leaves (line 56) | fn test_p2mr_pqc_different_version_leaves() {
function test_p2mr_pqc_simple_lightning_contract (line 66) | fn test_p2mr_pqc_simple_lightning_contract() {
function test_p2mr_pqc_two_leaf_same_version (line 76) | fn test_p2mr_pqc_two_leaf_same_version() {
function test_p2mr_pqc_three_leaf_complex (line 86) | fn test_p2mr_pqc_three_leaf_complex() {
function test_p2mr_pqc_three_leaf_alternative (line 96) | fn test_p2mr_pqc_three_leaf_alternative() {
function process_test_vector_p2mr (line 105) | fn process_test_vector_p2mr(test_vector: &TestVector) -> anyhow::Result<...
FILE: bip-0360/ref-impl/rust/tests/p2mr_spend.rs
function test_script_path_spend_simple (line 14) | fn test_script_path_spend_simple() {
function test_script_path_spend_signatures (line 44) | fn test_script_path_spend_signatures() {
FILE: bip-0374/gen_test_vectors.py
function random_scalar_int (line 20) | def random_scalar_int(vector_i, purpose):
function random_bytes (line 25) | def random_bytes(vector_i, purpose):
function create_test_vector_data (line 30) | def create_test_vector_data(vector_i):
function gen_all_generate_proof_vectors (line 49) | def gen_all_generate_proof_vectors(f):
function gen_all_verify_proof_vectors (line 80) | def gen_all_verify_proof_vectors(f):
FILE: bip-0374/reference.py
function dleq_challenge (line 21) | def dleq_challenge(
function dleq_generate_proof (line 42) | def dleq_generate_proof(
function dleq_verify_proof (line 72) | def dleq_verify_proof(
class DLEQTests (line 93) | class DLEQTests(unittest.TestCase):
method test_dleq (line 94) | def test_dleq(self):
FILE: bip-0374/secp256k1lab/src/secp256k1lab/bip340.py
function pubkey_gen (line 8) | def pubkey_gen(seckey: bytes) -> bytes:
function schnorr_sign (line 17) | def schnorr_sign(
function schnorr_verify (line 51) | def schnorr_verify(
FILE: bip-0374/secp256k1lab/src/secp256k1lab/ecdh.py
function ecdh_compressed_in_raw_out (line 6) | def ecdh_compressed_in_raw_out(seckey: bytes, pubkey: bytes) -> GE:
function ecdh_libsecp256k1 (line 13) | def ecdh_libsecp256k1(seckey: bytes, pubkey: bytes) -> bytes:
FILE: bip-0374/secp256k1lab/src/secp256k1lab/keys.py
function pubkey_gen_plain (line 9) | def pubkey_gen_plain(seckey: bytes) -> bytes:
FILE: bip-0374/secp256k1lab/src/secp256k1lab/secp256k1.py
class APrimeFE (line 19) | class APrimeFE:
method __init__ (line 28) | def __init__(self, a=0, b=1):
method __add__ (line 47) | def __add__(self, a):
method __radd__ (line 55) | def __radd__(self, a):
method sum (line 63) | def sum(cls, *es):
method __sub__ (line 69) | def __sub__(self, a):
method __rsub__ (line 77) | def __rsub__(self, a):
method __mul__ (line 81) | def __mul__(self, a):
method __rmul__ (line 89) | def __rmul__(self, a):
method __truediv__ (line 93) | def __truediv__(self, a):
method __pow__ (line 99) | def __pow__(self, a):
method __neg__ (line 103) | def __neg__(self):
method __int__ (line 107) | def __int__(self):
method sqrt (line 114) | def sqrt(self):
method is_square (line 118) | def is_square(self):
method is_even (line 123) | def is_even(self):
method __eq__ (line 127) | def __eq__(self, a):
method to_bytes (line 133) | def to_bytes(self):
method from_int_checked (line 138) | def from_int_checked(cls, v):
method from_int_wrapping (line 145) | def from_int_wrapping(cls, v):
method from_bytes_checked (line 150) | def from_bytes_checked(cls, b):
method from_bytes_wrapping (line 156) | def from_bytes_wrapping(cls, b):
method __str__ (line 161) | def __str__(self):
method __repr__ (line 165) | def __repr__(self):
class FE (line 170) | class FE(APrimeFE):
method sqrt (line 173) | def sqrt(self):
class Scalar (line 191) | class Scalar(APrimeFE):
class GE (line 196) | class GE:
method infinity (line 221) | def infinity(self):
method x (line 226) | def x(self):
method y (line 232) | def y(self):
method __init__ (line 237) | def __init__(self, x=None, y=None):
method __add__ (line 252) | def __add__(self, a):
method sum (line 276) | def sum(*ps):
method batch_mul (line 283) | def batch_mul(*aps):
method __rmul__ (line 302) | def __rmul__(self, a):
method __neg__ (line 308) | def __neg__(self):
method __sub__ (line 314) | def __sub__(self, a):
method __eq__ (line 318) | def __eq__(self, a):
method has_even_y (line 322) | def has_even_y(self):
method to_bytes_compressed (line 327) | def to_bytes_compressed(self):
method to_bytes_compressed_with_infinity (line 332) | def to_bytes_compressed_with_infinity(self):
method to_bytes_uncompressed (line 338) | def to_bytes_uncompressed(self):
method to_bytes_xonly (line 343) | def to_bytes_xonly(self):
method lift_x (line 349) | def lift_x(x):
method from_bytes_compressed (line 359) | def from_bytes_compressed(b):
method from_bytes_uncompressed (line 371) | def from_bytes_uncompressed(b):
method from_bytes (line 383) | def from_bytes(b):
method from_bytes_xonly (line 392) | def from_bytes_xonly(b):
method is_valid_x (line 400) | def is_valid_x(x):
method __str__ (line 404) | def __str__(self):
method __repr__ (line 410) | def __repr__(self):
method __hash__ (line 416) | def __hash__(self):
class FastGEMul (line 427) | class FastGEMul:
method __init__ (line 439) | def __init__(self, p):
method mul (line 445) | def mul(self, a):
FILE: bip-0374/secp256k1lab/src/secp256k1lab/util.py
function tagged_hash (line 6) | def tagged_hash(tag: str, msg: bytes) -> bytes:
function bytes_from_int (line 11) | def bytes_from_int(x: int) -> bytes:
function xor_bytes (line 15) | def xor_bytes(b0: bytes, b1: bytes) -> bytes:
function int_from_bytes (line 19) | def int_from_bytes(b: bytes) -> int:
function hash_sha256 (line 23) | def hash_sha256(b: bytes) -> bytes:
FILE: bip-0388/wallet_policies.py
function find_all (line 6) | def find_all(text: str, pattern: str, start: int = 0) -> Generator[int, ...
function find_first (line 16) | def find_first(text: str, start_pos: int, patterns: Iterable[str]) -> int:
function find_key_end_position (line 23) | def find_key_end_position(desc: str, start_pos: int) -> int:
class WalletPolicy (line 47) | class WalletPolicy(object):
method __init__ (line 52) | def __init__(self, descriptor_template: str, keys_info: List[str]):
method to_descriptor (line 56) | def to_descriptor(self) -> str:
method from_descriptor (line 76) | def from_descriptor(cls, descriptor: str) -> 'WalletPolicy':
Copy disabled (too large)
Download .json
Condensed preview — 385 files, each showing path, character count, and a content snippet. Download the .json file for the full structured content (15,886K chars).
[
{
"path": ".gitattributes",
"chars": 32,
"preview": "*.mediawiki linguist-detectable\n"
},
{
"path": ".github/workflows/github-action-checks.yml",
"chars": 827,
"preview": "name: GitHub Actions Check\nrun-name: ${{ github.actor }} Checks 🚀\non: [push, pull_request]\njobs:\n Link-Format-Checks:\n "
},
{
"path": ".gitignore",
"chars": 186,
"preview": "bip-0174/coinjoin-workflow.aux\nbip-0174/coinjoin-workflow.log\nbip-0174/coinjoin-workflow.pdf\nbip-0174/multisig-workflow."
},
{
"path": ".typos.toml",
"chars": 775,
"preview": "[default]\nextend-ignore-re = [\n # NOTE: use here for regex patterns\n \"xpub.*\",\n \"xprv.*\",\n \"3.*\", # address\n"
},
{
"path": "CONTRIBUTING.md",
"chars": 364,
"preview": "# Contributing Guidelines\n\nApart from following [BIP 2](./bip-0002.mediawiki),\nwe do CI checks to ensure that the propos"
},
{
"path": "README.mediawiki",
"chars": 33416,
"preview": "People wishing to submit a BIP should first describe their idea to the [https://groups.google.com/g/bitcoindev bitcoinde"
},
{
"path": "bip-0001.mediawiki",
"chars": 16470,
"preview": "<pre>\n BIP: 1\n Title: BIP Purpose and Guidelines\n Authors: Amir Taaki <genjix@riseup.net>\n Status: Closed\n Type: Pr"
},
{
"path": "bip-0002.mediawiki",
"chars": 35098,
"preview": "<pre>\n BIP: 2\n Title: BIP process, revised\n Authors: Luke Dashjr <luke+bip@dashjr.org>\n Status: Closed\n Type: Proce"
},
{
"path": "bip-0003.md",
"chars": 53697,
"preview": "```\n BIP: 3\n Title: Updated BIP Process\n Authors: Murch <murch@murch.one>\n Status: Deployed\n Type: Process\n Assign"
},
{
"path": "bip-0008/assignments.mediawiki",
"chars": 96,
"preview": "==Deployments==\n\nList of deployments.\n\nState can be defined, active, failed. Dates are in UTC.\n\n"
},
{
"path": "bip-0008/states.dot",
"chars": 1145,
"preview": "digraph {\n rankdir=TD;\n\n node [style=\"rounded,filled,bold\", shape=box, fixedsize=true, width=1.5, fontname=\"Arial\"];\n\n"
},
{
"path": "bip-0008.mediawiki",
"chars": 17548,
"preview": "<pre>\n BIP: 8\n Title: Version bits with lock-in by height\n Authors: Shaolin Fry <shaolinfry@protonmail.ch>\n "
},
{
"path": "bip-0009/assignments.mediawiki",
"chars": 728,
"preview": "==Deployments==\n\nList of proposed deployments.\n\nState can be defined, active, failed. Dates are in UTC.\n\n{| class=\"wikit"
},
{
"path": "bip-0009/states.gv",
"chars": 680,
"preview": "/* There are many ways to compile this, but one of them is:\n *\n * $ dot -Tpng states.gv -o states.png\n */\ndigraph "
},
{
"path": "bip-0009.mediawiki",
"chars": 14054,
"preview": "<pre>\n BIP: 9\n Title: Version bits with timeout and delay\n Authors: Pieter Wuille <pieter.wuille@gmail.com>\n "
},
{
"path": "bip-0010.mediawiki",
"chars": 9039,
"preview": "<pre>\n BIP: 10\n Layer: Applications\n Title: Multi-Sig Transaction Distribution\n Authors: Alan Reiner <etotheipi@gmai"
},
{
"path": "bip-0011.mediawiki",
"chars": 4249,
"preview": "<pre>\n BIP: 11\n Layer: Applications\n Title: M-of-N Standard Transactions\n Authors: Gavin Andresen <gavinandresen@gma"
},
{
"path": "bip-0012.mediawiki",
"chars": 5918,
"preview": "<pre>\n BIP: 12\n Layer: Consensus (soft fork)\n Title: OP_EVAL\n Authors: Gavin Andresen <gavinandresen@gmail.com>\n St"
},
{
"path": "bip-0013.mediawiki",
"chars": 3576,
"preview": "<pre>\n BIP: 13\n Layer: Applications\n Title: Address Format for pay-to-script-hash\n Authors: Gavin Andresen <gavinand"
},
{
"path": "bip-0014.mediawiki",
"chars": 7153,
"preview": "<pre>\n BIP: 14\n Layer: Peer Services\n Title: Protocol Version and User Agent\n Authors: Amir Taaki <genjix@riseup.net"
},
{
"path": "bip-0015.mediawiki",
"chars": 19073,
"preview": "<pre>\n BIP: 15\n Layer: Applications\n Title: Aliases\n Authors: Amir Taaki <genjix@riseup.net>\n Status: Closed\n Type"
},
{
"path": "bip-0016/qa.mediawiki",
"chars": 8789,
"preview": "This page is a Quality Assurance test plan for [[../bip-0016.mediawiki|BIP 16]]. If you see a test missing, please add "
},
{
"path": "bip-0016.mediawiki",
"chars": 8795,
"preview": "<pre>\n BIP: 16\n Layer: Consensus (soft fork)\n Title: Pay to Script Hash\n Authors: Gavin Andresen <gavinandresen@gmai"
},
{
"path": "bip-0017.mediawiki",
"chars": 7060,
"preview": "<pre>\n BIP: 17\n Layer: Consensus (soft fork)\n Title: OP_CHECKHASHVERIFY (CHV)\n Authors: Luke Dashjr <luke+bip17@dash"
},
{
"path": "bip-0018.mediawiki",
"chars": 8801,
"preview": "<pre>\n BIP: 18\n Layer: Consensus (soft fork)\n Title: hashScriptCheck\n Authors: Luke Dashjr <luke+bip17@dashjr.org>\n "
},
{
"path": "bip-0019.mediawiki",
"chars": 3801,
"preview": "<pre>\n BIP: 19\n Layer: Applications\n Title: M-of-N Standard Transactions (Low SigOp)\n Authors: Luke Dashjr <luke+bip"
},
{
"path": "bip-0020.mediawiki",
"chars": 8907,
"preview": "<pre>\n BIP: 20\n Layer: Applications\n Title: URI Scheme\n Authors: Luke Dashjr <luke+bip@dashjr.org>\n Status: Closed\n"
},
{
"path": "bip-0021.mediawiki",
"chars": 6831,
"preview": "<pre>\n BIP: 21\n Layer: Applications\n Title: URI Scheme\n Authors: Nils Schneider <nils.schneider@gmail.com>\n "
},
{
"path": "bip-0022.mediawiki",
"chars": 12549,
"preview": "<pre>\n BIP: 22\n Layer: API/RPC\n Title: getblocktemplate - Fundamentals\n Authors: Luke Dashjr <luke+bip22@dashjr.org>"
},
{
"path": "bip-0023.mediawiki",
"chars": 13830,
"preview": "<pre>\n BIP: 23\n Layer: API/RPC\n Title: getblocktemplate - Pooled Mining\n Authors: Luke Dashjr <luke+bip22@dashjr.org"
},
{
"path": "bip-0030.mediawiki",
"chars": 4262,
"preview": "<pre>\n BIP: 30\n Layer: Consensus (soft fork)\n Title: Duplicate transactions\n Authors: Pieter Wuille <pieter.wuille@g"
},
{
"path": "bip-0031.mediawiki",
"chars": 2789,
"preview": "<pre>\n BIP: 31\n Layer: Peer Services\n Title: Pong message\n Authors: Mike Hearn <hearn@google.com>\n Status: Deployed"
},
{
"path": "bip-0032.mediawiki",
"chars": 28012,
"preview": "RECENT CHANGES:\n* (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage)\n* "
},
{
"path": "bip-0033.mediawiki",
"chars": 6697,
"preview": "<pre>\n BIP: 33\n Layer: Peer Services\n Title: Stratized Nodes\n Authors: Amir Taaki <genjix@riseup.net>\n Status: Clos"
},
{
"path": "bip-0034.mediawiki",
"chars": 2135,
"preview": "<pre>\n BIP: 34\n Layer: Consensus (soft fork)\n Title: Block v2, Height in Coinbase\n Authors: Gavin Andresen <gavinand"
},
{
"path": "bip-0035.mediawiki",
"chars": 1678,
"preview": "<pre>\n BIP: 35\n Layer: Peer Services\n Title: mempool message\n Authors: Jeff Garzik <jgarzik@exmulti.com>\n Status: D"
},
{
"path": "bip-0036.mediawiki",
"chars": 10044,
"preview": "<pre>\n BIP: 36\n Layer: Peer Services\n Title: Custom Services\n Authors: Stefan Thomas <justmoon@members.fsf.org>\n St"
},
{
"path": "bip-0037.mediawiki",
"chars": 17637,
"preview": "<pre>\n BIP: 37\n Layer: Peer Services\n Title: Connection Bloom filtering\n Authors: Mike Hearn <hearn@google.com>\n "
},
{
"path": "bip-0038.mediawiki",
"chars": 31664,
"preview": "<pre>\n BIP: 38\n Layer: Applications\n Title: Passphrase-protected private key\n Authors: Mike Caldwell <mcaldwell@swip"
},
{
"path": "bip-0039/bip-0039-wordlists.md",
"chars": 6407,
"preview": "# Wordlists\n\n* [English](english.txt)\n* [Japanese](japanese.txt)\n* [Korean](korean.txt)\n* [Spanish](spanish.txt)\n* [Chin"
},
{
"path": "bip-0039/chinese_simplified.txt",
"chars": 4096,
"preview": "的\n一\n是\n在\n不\n了\n有\n和\n人\n这\n中\n大\n为\n上\n个\n国\n我\n以\n要\n他\n时\n来\n用\n们\n生\n到\n作\n地\n于\n出\n就\n分\n对\n成\n会\n可\n主\n发\n年\n动\n同\n工\n也\n能\n下\n过\n子\n说\n产\n种\n面\n而\n方\n后\n多\n定\n行\n学\n法\n所\n"
},
{
"path": "bip-0039/chinese_traditional.txt",
"chars": 4096,
"preview": "的\n一\n是\n在\n不\n了\n有\n和\n人\n這\n中\n大\n為\n上\n個\n國\n我\n以\n要\n他\n時\n來\n用\n們\n生\n到\n作\n地\n於\n出\n就\n分\n對\n成\n會\n可\n主\n發\n年\n動\n同\n工\n也\n能\n下\n過\n子\n說\n產\n種\n面\n而\n方\n後\n多\n定\n行\n學\n法\n所\n"
},
{
"path": "bip-0039/czech.txt",
"chars": 14945,
"preview": "abdikace\nabeceda\nadresa\nagrese\nakce\naktovka\nalej\nalkohol\namputace\nananas\nandulka\nanekdota\nanketa\nantika\nanulovat\narcha\na"
},
{
"path": "bip-0039/english.txt",
"chars": 13116,
"preview": "abandon\nability\nable\nabout\nabove\nabsent\nabsorb\nabstract\nabsurd\nabuse\naccess\naccident\naccount\naccuse\nachieve\nacid\nacousti"
},
{
"path": "bip-0039/french.txt",
"chars": 16389,
"preview": "abaisser\nabandon\nabdiquer\nabeille\nabolir\naborder\naboutir\naboyer\nabrasif\nabreuver\nabriter\nabroger\nabrupt\nabsence\nabsolu\na"
},
{
"path": "bip-0039/italian.txt",
"chars": 16033,
"preview": "abaco\nabbaglio\nabbinato\nabete\nabisso\nabolire\nabrasivo\nabrogato\naccadere\naccenno\naccusato\nacetone\nachille\nacido\nacqua\nacr"
},
{
"path": "bip-0039/japanese.txt",
"chars": 10173,
"preview": "あいこくしん\nあいさつ\nあいだ\nあおぞら\nあかちゃん\nあきる\nあけがた\nあける\nあこがれる\nあさい\nあさひ\nあしあと\nあじわう\nあずかる\nあずき\nあそぶ\nあたえる\nあたためる\nあたりまえ\nあたる\nあつい\nあつかう\nあっしゅく"
},
{
"path": "bip-0039/korean.txt",
"chars": 13976,
"preview": "가격\n가끔\n가난\n가능\n가득\n가르침\n가뭄\n가방\n가상\n가슴\n가운데\n가을\n가이드\n가입\n가장\n가정\n가족\n가죽\n각오\nᄀ"
},
{
"path": "bip-0039/portuguese.txt",
"chars": 15671,
"preview": "abacate\nabaixo\nabalar\nabater\nabduzir\nabelha\naberto\nabismo\nabotoar\nabranger\nabreviar\nabrigar\nabrupto\nabsinto\nabsoluto\nabs"
},
{
"path": "bip-0039/spanish.txt",
"chars": 13659,
"preview": "ábaco\nabdomen\nabeja\nabierto\nabogado\nabono\naborto\nabrazo\nabrir\nabuelo\nabuso\nacabar\nacademia\nacceso\nacción\naceite\nacelga"
},
{
"path": "bip-0039.mediawiki",
"chars": 5668,
"preview": "<pre>\n BIP: 39\n Layer: Applications\n Title: Mnemonic code for generating deterministic keys\n Authors: Marek Palatinu"
},
{
"path": "bip-0042.mediawiki",
"chars": 4473,
"preview": "<pre>\n BIP: 42\n Layer: Consensus (soft fork)\n Title: A finite monetary supply for Bitcoin\n Authors: Pieter Wuille <p"
},
{
"path": "bip-0043.mediawiki",
"chars": 2437,
"preview": "<pre>\n BIP: 43\n Layer: Applications\n Title: Purpose Field for Deterministic Wallets\n Authors: Marek Palatinus <slush"
},
{
"path": "bip-0044.mediawiki",
"chars": 6710,
"preview": "<pre>\n BIP: 44\n Layer: Applications\n Title: Multi-Account Hierarchy for Deterministic Wallets\n Authors: Marek Palati"
},
{
"path": "bip-0045.mediawiki",
"chars": 9546,
"preview": "<pre>\n BIP: 45\n Layer: Applications\n Title: Structure for Deterministic P2SH Multisignature Wallets\n Authors: Manuel"
},
{
"path": "bip-0046.mediawiki",
"chars": 13497,
"preview": "<pre>\n BIP: 46\n Layer: Applications\n Title: Address Scheme for Timelocked Fidelity Bonds\n Authors: Chris Belcher <be"
},
{
"path": "bip-0047.mediawiki",
"chars": 22884,
"preview": "RECENT CHANGES:\n* (15 Feb 2021) Finalize specification\n* (28 Sep 2017) Adjust text to match test vectors\n* (19 Apr 2016)"
},
{
"path": "bip-0048.mediawiki",
"chars": 6245,
"preview": "<pre>\n BIP: 48\n Layer: Applications\n Title: Multi-Script Hierarchy for Multi-Sig Wallets\n Authors: Fontaine <dentond"
},
{
"path": "bip-0049.mediawiki",
"chars": 5546,
"preview": "<pre>\n BIP: 49\n Layer: Applications\n Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts\n Authors: Dan"
},
{
"path": "bip-0050.mediawiki",
"chars": 6714,
"preview": "<pre>\n BIP: 50\n Title: March 2013 Chain Fork Post-Mortem\n Authors: Gavin Andresen <gavinandresen@gmail.com>\n Status:"
},
{
"path": "bip-0052.mediawiki",
"chars": 22695,
"preview": "<pre>\n BIP: 52\n Layer: Consensus (hard fork)\n Title: Durable, Low Energy Bitcoin PoW\n Authors: Michael Dubrovsky <mi"
},
{
"path": "bip-0053/64byte-tx-mainnet.txt",
"chars": 324,
"preview": "892f44a49de6f5b212cdbea514d09e692d9fed5d897f37bcef14bd0eedebf193\nbbf71454857438c6dfd64c0d92a7c5360a8d8d57c9202f5806449e5"
},
{
"path": "bip-0053/non-standard-hashlock-utxos.txt",
"chars": 401,
"preview": "af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d:0\nfaf8989ed87c5a667a1ead813aea718727e01767c124193297eaf"
},
{
"path": "bip-0053.mediawiki",
"chars": 12210,
"preview": "<pre>\n BIP: 53\n Layer: Consensus (soft fork)\n Title: Disallow 64-byte transactions\n Authors: Chris Stewart <stewart."
},
{
"path": "bip-0054/test_vectors/README.md",
"chars": 6102,
"preview": "## BIP54 test vectors\n\nThis folder contains a set of test vectors for each mitigation introduced in the BIP. This docume"
},
{
"path": "bip-0054/test_vectors/coinbases.json",
"chars": 17660,
"preview": "[\n {\n \"block_chain\": [\n \"0100000000000000000000000000000000000000000000000000000000000000000000003b"
},
{
"path": "bip-0054/test_vectors/sigops.json",
"chars": 5381795,
"preview": "[\n {\n \"spent_outputs\": [\n \"0000000000000000e9210376539063f5f2b617d6a6651884d5df9d39ea0ea9c014058cdb"
},
{
"path": "bip-0054/test_vectors/timestamps.json",
"chars": 4260090,
"preview": "[\n {\n \"header_chain\": [\n \"0100000000000000000000000000000000000000000000000000000000000000000000003"
},
{
"path": "bip-0054/test_vectors/txsize.json",
"chars": 3383,
"preview": "[\n {\n \"tx\": \"0200000001827da3d85a6547d6b03662d2cb86982d655a6f390547285a3bf9ec9f28e0c8831500000000ffffffff01000"
},
{
"path": "bip-0054.md",
"chars": 16853,
"preview": "```\n BIP: 54\n Layer: Consensus (soft fork)\n Title: Consensus Cleanup\n Authors: Antoine Poinsot <mail@antoinep.com>\n "
},
{
"path": "bip-0060.mediawiki",
"chars": 4458,
"preview": "<pre>\n BIP: 60\n Layer: Peer Services\n Title: Fixed Length \"version\" Message (Relay-Transactions Field)\n Authors: Ami"
},
{
"path": "bip-0061.mediawiki",
"chars": 4686,
"preview": "<pre>\n BIP: 61\n Layer: Peer Services\n Title: Reject P2P message\n Authors: Gavin Andresen <gavinandresen@gmail.com>\n "
},
{
"path": "bip-0062.mediawiki",
"chars": 10783,
"preview": "'''NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.''"
},
{
"path": "bip-0064.mediawiki",
"chars": 5140,
"preview": "<pre>\n BIP: 64\n Layer: Peer Services\n Title: getutxo message\n Authors: Mike Hearn <hearn@vinumeris.com>\n Status: Cl"
},
{
"path": "bip-0065.mediawiki",
"chars": 13054,
"preview": "<pre>\n BIP: 65\n Layer: Consensus (soft fork)\n Title: OP_CHECKLOCKTIMEVERIFY\n Authors: Peter Todd <pete@petertodd.org"
},
{
"path": "bip-0066.mediawiki",
"chars": 8151,
"preview": "<pre>\n BIP: 66\n Layer: Consensus (soft fork)\n Title: Strict DER signatures\n Authors: Pieter Wuille <pieter.wuille@gm"
},
{
"path": "bip-0067.mediawiki",
"chars": 8682,
"preview": "<pre>\n BIP: 67\n Layer: Applications\n Title: Deterministic Pay-to-script-hash multi-signature addresses through public"
},
{
"path": "bip-0068.mediawiki",
"chars": 14052,
"preview": "<pre>\n BIP: 68\n Layer: Consensus (soft fork)\n Title: Relative lock-time using consensus-enforced sequence numbers\n A"
},
{
"path": "bip-0069/bip-0069_examples.py",
"chars": 8384,
"preview": "#!/usr/bin/env python3\nimport binascii\nfrom functools import cmp_to_key\n\n#returns -1 if barr1 is less, 1 if barr1 is gre"
},
{
"path": "bip-0069.mediawiki",
"chars": 11813,
"preview": "<pre>\n BIP: 69\n Layer: Applications\n Title: Lexicographical Indexing of Transaction Inputs and Outputs\n Authors: Kri"
},
{
"path": "bip-0070/extensions.mediawiki",
"chars": 249,
"preview": "==BIP70 Extensions==\n\nAdd your extension below using tags starting at 1000 and submit a pull-req.\n\n{|\n| Field Number || "
},
{
"path": "bip-0070/paymentrequest.proto",
"chars": 2366,
"preview": "//\n// Simple Bitcoin Payment Protocol messages\n//\n// Use fields 1000+ for extensions;\n// to avoid conflicts, register ex"
},
{
"path": "bip-0070.mediawiki",
"chars": 16210,
"preview": "<pre>\n BIP: 70\n Layer: Applications\n Title: Payment Protocol\n Authors: Gavin Andresen <gavinandresen@gmail.com>\n "
},
{
"path": "bip-0071.mediawiki",
"chars": 1075,
"preview": "<pre>\n BIP: 71\n Layer: Applications\n Title: Payment Protocol MIME types\n Authors: Gavin Andresen <gavinandresen@gmai"
},
{
"path": "bip-0072.mediawiki",
"chars": 2397,
"preview": "<pre>\n BIP: 72\n Layer: Applications\n Title: bitcoin: uri extensions for Payment Protocol\n Authors: Gavin Andresen <g"
},
{
"path": "bip-0073.mediawiki",
"chars": 4024,
"preview": "<pre>\n BIP: 73\n Layer: Applications\n Title: Use \"Accept\" header for response type negotiation with Payment Request UR"
},
{
"path": "bip-0074.mediawiki",
"chars": 6141,
"preview": "<pre>\n BIP: 74\n Layer: Applications\n Title: Allow zero value OP_RETURN in Payment Protocol\n Authors: Toby Padilla <t"
},
{
"path": "bip-0075/paymentrequest.proto",
"chars": 5247,
"preview": "//\n// Simple Bitcoin Payment Protocol messages\n//\n// Use fields 1000+ for extensions;\n// to avoid conflicts, register ex"
},
{
"path": "bip-0075.mediawiki",
"chars": 29805,
"preview": "<pre>\n BIP: 75\n Layer: Applications\n Title: Out of Band Address Exchange using Payment Protocol Encryption\n Authors:"
},
{
"path": "bip-0077.md",
"chars": 36635,
"preview": "```\n BIP: 77\n Layer: Applications\n Title: Async Payjoin\n Authors: Dan Gould <d@ngould.dev>\n Yuval Kogman <"
},
{
"path": "bip-0078.mediawiki",
"chars": 40234,
"preview": "<pre>\n BIP: 78\n Layer: Applications\n Title: A Simple Payjoin Proposal\n Authors: Nicolas Dorier <nicolas.dorier@gmail"
},
{
"path": "bip-0079.mediawiki",
"chars": 11776,
"preview": "<pre>\n BIP: 79\n Layer: Applications\n Title: Bustapay :: a practical coinjoin protocol\n Authors: Ryan Havar <rhavar@p"
},
{
"path": "bip-0080.mediawiki",
"chars": 2941,
"preview": "<pre>\n BIP: 80\n Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets\n Authors: Justus Ranvier "
},
{
"path": "bip-0081.mediawiki",
"chars": 2769,
"preview": "<pre>\n BIP: 81\n Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets\n Authors: Justus Ranvier <jus"
},
{
"path": "bip-0083.mediawiki",
"chars": 5309,
"preview": "<pre>\n BIP: 83\n Layer: Applications\n Title: Dynamic Hierarchical Deterministic Key Trees\n Authors: Eric Lombrozo <er"
},
{
"path": "bip-0084.mediawiki",
"chars": 4648,
"preview": "<pre>\n BIP: 84\n Layer: Applications\n Title: Derivation scheme for P2WPKH based accounts\n Authors: Pavol Rusnak <stic"
},
{
"path": "bip-0085.mediawiki",
"chars": 21006,
"preview": "<pre>\n BIP: 85\n Layer: Applications\n Title: Deterministic Entropy From BIP32 Keychains\n Authors: Ethan Kosakovsky <e"
},
{
"path": "bip-0086.mediawiki",
"chars": 5896,
"preview": "<pre>\n BIP: 86\n Layer: Applications\n Title: Key Derivation for Single Key P2TR Outputs\n Authors: Ava Chow <me@achow1"
},
{
"path": "bip-0087.mediawiki",
"chars": 11646,
"preview": "<pre>\n BIP: 87\n Layer: Applications\n Title: Hierarchy for Deterministic Multisig Wallets\n Authors: Robert Spigler <R"
},
{
"path": "bip-0088.mediawiki",
"chars": 14141,
"preview": "<pre>\n BIP: 88\n Layer: Applications\n Title: Hierarchical Deterministic Path Templates\n Authors: Dmitry Petukhov <dp@"
},
{
"path": "bip-0089/bip32.py",
"chars": 5504,
"preview": "\"\"\"BIP32 helpers for the CCD reference implementation.\"\"\"\n\nfrom __future__ import annotations\n\nfrom dataclasses import d"
},
{
"path": "bip-0089/descriptor.py",
"chars": 1389,
"preview": "\"\"\"Helpers for working with minimal SortedMulti descriptor templates.\"\"\"\n\nfrom __future__ import annotations\n\nfrom datac"
},
{
"path": "bip-0089/reference.py",
"chars": 30624,
"preview": "# BIPXXX reference implementation\n#\n# WARNING: This implementation is for demonstration purposes only and _not_ to\n# be "
},
{
"path": "bip-0089/secp256k1lab/COPYING",
"chars": 1190,
"preview": "The MIT License (MIT)\n\nCopyright (c) 2009-2024 The Bitcoin Core developers\nCopyright (c) 2009-2024 Bitcoin Developers\nCo"
},
{
"path": "bip-0089/secp256k1lab/__init__.py",
"chars": 0,
"preview": ""
},
{
"path": "bip-0089/secp256k1lab/bip340.py",
"chars": 2492,
"preview": "# The following functions are based on the BIP 340 reference implementation:\n# https://github.com/bitcoin/bips/blob/mast"
},
{
"path": "bip-0089/secp256k1lab/ecdh.py",
"chars": 522,
"preview": "import hashlib\n\nfrom .secp256k1 import GE, Scalar\n\n\ndef ecdh_compressed_in_raw_out(seckey: bytes, pubkey: bytes) -> GE:\n"
},
{
"path": "bip-0089/secp256k1lab/keys.py",
"chars": 548,
"preview": "from .secp256k1 import GE, G\nfrom .util import int_from_bytes\n\n# The following function is based on the BIP 327 referenc"
},
{
"path": "bip-0089/secp256k1lab/py.typed",
"chars": 0,
"preview": ""
},
{
"path": "bip-0089/secp256k1lab/secp256k1.py",
"chars": 17423,
"preview": "# Copyright (c) 2022-2023 The Bitcoin Core developers\n# Distributed under the MIT software license, see the accompanying"
},
{
"path": "bip-0089/secp256k1lab/util.py",
"chars": 645,
"preview": "import hashlib\n\n\n# This implementation can be sped up by storing the midstate after hashing\n# tag_hash instead of rehash"
},
{
"path": "bip-0089/vectors/blind_challenge_gen_vectors.json",
"chars": 2467,
"preview": "{\n \"test_cases\": [\n {\n \"rand\": \"92950940B9C21B956D2950EA4C2CBD966D5DCF32517D2419636C3B434E7E7243\",\n \"msg\":"
},
{
"path": "bip-0089/vectors/blind_nonce_gen_vectors.json",
"chars": 1087,
"preview": "{\n \"test_cases\": [\n {\n \"rand_\": \"0F6166D1645791EAD551572348A43CA9293E02CF0ED32B17EA5E1AEC6BC41931\",\n \"sk\":"
},
{
"path": "bip-0089/vectors/blind_sign_and_verify_vectors.json",
"chars": 3028,
"preview": "{\n \"valid_test_cases\": [\n {\n \"sk\": \"E4E64DB308215A81F1F41969624B9A6265D50F479BA6789E40190027AC6C72A8\",\n \"p"
},
{
"path": "bip-0089/vectors/change_output_verification_vectors.json",
"chars": 3049,
"preview": "{\n \"test_cases\": [\n {\n \"comment\": \"Change output verification 2-of-3 (path [1,5])\",\n \"expected\": true,\n "
},
{
"path": "bip-0089/vectors/compute_bip32_tweak_vectors.json",
"chars": 995,
"preview": "{\n \"xpub\": {\n \"compressed\": \"0296928602758150d2b4a8a253451b887625b94ab0a91f801f1408cb33b9cf0f83\",\n \"chain_code\": "
},
{
"path": "bip-0089/vectors/delegator_sign_vectors.json",
"chars": 517,
"preview": "{\n \"test_cases\": [\n {\n \"comment\": \"Delegator signing with provided CCD tweak over arbitrary message\",\n \"ba"
},
{
"path": "bip-0089/vectors/input_verification_vectors.json",
"chars": 3071,
"preview": "{\n \"test_cases\": [\n {\n \"comment\": \"Input verification for wsh(sortedmulti) 2-of-3 (path [0,5])\",\n \"expecte"
},
{
"path": "bip-0089/vectors/unblind_signature_vectors.json",
"chars": 3552,
"preview": "{\n \"valid_test_cases\": [\n {\n \"session_ctx\": {\n \"pk\": \"03A1B69A6C047657AA6A0DF9ED43E5B0CA75097260F0650486"
},
{
"path": "bip-0089.mediawiki",
"chars": 31298,
"preview": "<pre>\n BIP: 89\n Layer: Applications\n Title: Chain Code Delegation\n Authors: Jesse Posner <jesse@vora.io>\n "
},
{
"path": "bip-0090.mediawiki",
"chars": 6318,
"preview": "<pre>\n BIP: 90\n Title: Buried Deployments\n Authors: Suhas Daftuar <sdaftuar@chaincode.com>\n Comments-Summary: Mostly"
},
{
"path": "bip-0091.mediawiki",
"chars": 6634,
"preview": "<pre>\n BIP: 91\n Layer: Consensus (soft fork)\n Title: Reduced threshold Segwit MASF\n Authors: James Hilliard <james.h"
},
{
"path": "bip-0093.mediawiki",
"chars": 42208,
"preview": "<pre>\n BIP: 93\n Layer: Applications\n Title: codex32: Checksummed SSSS-aware BIP32 seeds\n Authors: Leon Olsson Curr a"
},
{
"path": "bip-0094.mediawiki",
"chars": 10706,
"preview": "<pre>\n BIP: 94\n Layer: Applications\n Title: Testnet 4\n Authors: Fabian Jahr <fjahr@protonmail.com>\n Status: Deploye"
},
{
"path": "bip-0098/build.sh",
"chars": 221,
"preview": "#!/bin/sh\n\ndot -Tpng -o node-variants.png node-variants.dot\ndot -Tpng -o skip-skip.png skip-skip.dot\ndot -Tpng -o traver"
},
{
"path": "bip-0098/node-variants.dot",
"chars": 1485,
"preview": "digraph G {\n row1 [shape=none, label=\"\"]\n\n A [label=\"000\"]\n A -> Al [label=\"L\"]\n Al [label=\"VERIFY\"]\n A -> Ar [labe"
},
{
"path": "bip-0098/skip-skip.dot",
"chars": 115,
"preview": "digraph G {\n A [label=\"???\"]\n A -> Al [label=\"L\"]\n Al [label=\"SKIP\"]\n A -> Ar [label=\"R\"]\n Ar [label=\"SKIP\"]\n}"
},
{
"path": "bip-0098/traversal-example.dot",
"chars": 471,
"preview": "digraph G {\n a [label=\"A\\n101\"]\n a -> b\n a -> c\n\n b [label=\"B\\n111\"]\n b -> s0\n s0 [label=\"SKIP\\n0x00...\"]\n b -> d"
},
{
"path": "bip-0098/unbalanced-hash-tree.dot",
"chars": 186,
"preview": "digraph G {\n 0 [label=\"Root\\nH(A || H(B || C))\"]\n 0 -> A\n A [label=\"A\\nskip\"]\n 0 -> 1\n 1 [label=\"Node\\nH(B || C)\"]\n"
},
{
"path": "bip-0098.mediawiki",
"chars": 19931,
"preview": "<pre>\n BIP: 98\n Layer: Consensus (soft fork)\n Title: Fast Merkle Trees\n Authors: Mark Friedenbach <mark@friedenbach."
},
{
"path": "bip-0099.mediawiki",
"chars": 18587,
"preview": "<pre>\n BIP: 99\n Title: Motivation and deployment of consensus rule changes ([soft/hard]forks)\n Authors: Jorge Timón <"
},
{
"path": "bip-0100.mediawiki",
"chars": 5551,
"preview": "<pre>\n BIP: 100\n Layer: Consensus (hard fork)\n Title: Dynamic maximum block size by miner vote\n Authors: Jeff Garzik"
},
{
"path": "bip-0101.mediawiki",
"chars": 10151,
"preview": "<pre>\n BIP: 101\n Layer: Consensus (hard fork)\n Title: Increase maximum block size\n Authors: Gavin Andresen <gavinand"
},
{
"path": "bip-0102.mediawiki",
"chars": 1240,
"preview": "<pre>\n BIP: 102\n Layer: Consensus (hard fork)\n Title: Block size increase to 2MB\n Authors: Jeff Garzik <jgarzik@gmai"
},
{
"path": "bip-0103.mediawiki",
"chars": 6101,
"preview": "<pre>\n BIP: 103\n Layer: Consensus (hard fork)\n Title: Block size following technological growth\n Authors: Pieter Wui"
},
{
"path": "bip-0104.mediawiki",
"chars": 4725,
"preview": "<pre>\n BIP: 104\n Layer: Consensus (hard fork)\n Title: 'Block75' - Max block size like difficulty\n Authors: t.khan <t"
},
{
"path": "bip-0105.mediawiki",
"chars": 4122,
"preview": "<pre>\n BIP: 105\n Layer: Consensus (hard fork)\n Title: Consensus based block size retargeting algorithm\n Authors: Btc"
},
{
"path": "bip-0106.mediawiki",
"chars": 5448,
"preview": "<pre>\n BIP: 106\n Layer: Consensus (hard fork)\n Title: Dynamically Controlled Bitcoin Block Size Max Cap\n Authors: Up"
},
{
"path": "bip-0107.mediawiki",
"chars": 5960,
"preview": "<pre>\n BIP: 107\n Layer: Consensus (hard fork)\n Title: Dynamic limit on the block size\n Authors: Washington Y. Sanche"
},
{
"path": "bip-0109.mediawiki",
"chars": 4585,
"preview": "<pre>\n BIP: 109\n Layer: Consensus (hard fork)\n Title: Two million byte size limit with sigop and sighash limits\n Aut"
},
{
"path": "bip-0110.mediawiki",
"chars": 28437,
"preview": "<pre>\n BIP: 110\n Layer: Consensus (soft fork)\n Title: Reduced Data Temporary Softfork\n Authors: Dathon Ohm <dathonoh"
},
{
"path": "bip-0111.mediawiki",
"chars": 3369,
"preview": "<pre>\n BIP: 111\n Layer: Peer Services\n Title: NODE_BLOOM service bit\n Authors: Matt Corallo <bip111@bluematt.me>\n "
},
{
"path": "bip-0112.mediawiki",
"chars": 16727,
"preview": "<pre>\n BIP: 112\n Layer: Consensus (soft fork)\n Title: CHECKSEQUENCEVERIFY\n Authors: BtcDrak <btcdrak@gmail.com>\n "
},
{
"path": "bip-0113.mediawiki",
"chars": 4656,
"preview": "<pre>\n BIP: 113\n Layer: Consensus (soft fork)\n Title: Median time-past as endpoint for lock-time calculations\n Autho"
},
{
"path": "bip-0114.mediawiki",
"chars": 23538,
"preview": "<pre>\n BIP: 114\n Layer: Consensus (soft fork)\n Title: Merkelized Abstract Syntax Tree\n Authors: Johnson Lau <jl2012@"
},
{
"path": "bip-0115.mediawiki",
"chars": 7458,
"preview": "<pre>\n BIP: 115\n Layer: Consensus (soft fork)\n Title: Generic anti-replay protection using Script\n Authors: Luke Das"
},
{
"path": "bip-0116.mediawiki",
"chars": 11648,
"preview": "<pre>\n BIP: 116\n Layer: Consensus (soft fork)\n Title: MERKLEBRANCHVERIFY\n Authors: Mark Friedenbach <mark@friedenbac"
},
{
"path": "bip-0117.mediawiki",
"chars": 15298,
"preview": "<pre>\n BIP: 117\n Layer: Consensus (soft fork)\n Title: Tail Call Execution Semantics\n Authors: Mark Friedenbach <mark"
},
{
"path": "bip-0118.mediawiki",
"chars": 20418,
"preview": "<pre>\n BIP: 118\n Layer: Consensus (soft fork)\n Title: SIGHASH_ANYPREVOUT for Taproot Scripts\n Authors: Christian Dec"
},
{
"path": "bip-0119/simulation.py",
"chars": 5128,
"preview": "#!/usr/bin/python3\nimport numpy as np\nimport matplotlib.pyplot as plt\nPHASES = 15\nPHASE_LENGTH = 144\nSAMPLES = PHASE_LEN"
},
{
"path": "bip-0119/vectors/ctvhash.json",
"chars": 709085,
"preview": "[\n \"{\\\"hex_tx\\\":string (hex tx), \\\"spend_index\\\":[number], \\\"result\\\": [string (hex hash)]}\",\n {\n \"desc\": {"
},
{
"path": "bip-0119/vectors/tx_invalid.json",
"chars": 13953,
"preview": "[\n[\"The following are deserialized transactions which are invalid.\"],\n[\"They are in the form\"],\n[\"[[[prevout hash, prevo"
},
{
"path": "bip-0119/vectors/tx_valid.json",
"chars": 17412,
"preview": "[\n[\"The following are deserialized transactions which are valid.\"],\n[\"They are in the form\"],\n[\"[[[prevout hash, prevout"
},
{
"path": "bip-0119.mediawiki",
"chars": 36469,
"preview": "<pre>\n BIP: 119\n Layer: Consensus (soft fork)\n Title: CHECKTEMPLATEVERIFY\n Authors: Jeremy Rubin <j@rubin.io>\n Stat"
},
{
"path": "bip-0120.mediawiki",
"chars": 9429,
"preview": "<pre>\n BIP: 120\n Layer: Applications\n Title: Proof of Payment\n Authors: Kalle Rosenbaum <kalle@rosenbaum.se>\n Statu"
},
{
"path": "bip-0121.mediawiki",
"chars": 6051,
"preview": "<pre>\n BIP: 121\n Layer: Applications\n Title: Proof of Payment URI scheme\n Authors: Kalle Rosenbaum <kalle@rosenbaum."
},
{
"path": "bip-0122.mediawiki",
"chars": 4564,
"preview": "<pre>\n BIP: 122\n Layer: Applications\n Title: URI scheme for Blockchain references / exploration\n Authors: Marco Pont"
},
{
"path": "bip-0123.mediawiki",
"chars": 16019,
"preview": "<pre>\n BIP: 123\n Title: BIP Classification\n Authors: Eric Lombrozo <elombrozo@gmail.com>\n Status: Deployed\n Type: P"
},
{
"path": "bip-0124.mediawiki",
"chars": 5912,
"preview": "<pre>\n BIP: 124\n Layer: Applications\n Title: Hierarchical Deterministic Script Templates\n Authors: Eric Lombrozo <er"
},
{
"path": "bip-0125.mediawiki",
"chars": 9569,
"preview": "<pre>\n BIP: 125\n Layer: Applications\n Title: Opt-in Full Replace-by-Fee Signaling\n Authors: David A. Harding <dave@d"
},
{
"path": "bip-0126.mediawiki",
"chars": 7743,
"preview": "<pre>\n BIP: 126\n Title: Best Practices for Heterogeneous Input Script Transactions\n Authors: Kristov Atlas <kristov@o"
},
{
"path": "bip-0127.mediawiki",
"chars": 10658,
"preview": "\n<pre>\n BIP: 127\n Layer: Applications\n Title: Simple Proof-of-Reserves Transactions\n Authors: Steven Roose <steven@s"
},
{
"path": "bip-0128.mediawiki",
"chars": 18845,
"preview": "<pre>\n BIP: 128\n Layer: Applications\n Title: Timelock-Recovery Storage Format\n Authors: Oren Z <orenz0@protonmail.co"
},
{
"path": "bip-0129.mediawiki",
"chars": 40680,
"preview": "<pre>\n BIP: 129\n Layer: Applications\n Title: Bitcoin Secure Multisig Setup (BSMS)\n Authors: Hugo Nguyen <hugo@nunchu"
},
{
"path": "bip-0130.mediawiki",
"chars": 2683,
"preview": "<pre>\n BIP: 130\n Layer: Peer Services\n Title: sendheaders message\n Authors: Suhas Daftuar <sdaftuar@chaincode.com>\n "
},
{
"path": "bip-0131.mediawiki",
"chars": 4939,
"preview": "<pre>\n BIP: 131\n Layer: Consensus (hard fork)\n Title: \"Coalescing Transaction\" Specification (wildcard inputs)\n Auth"
},
{
"path": "bip-0132.mediawiki",
"chars": 8574,
"preview": "<pre>\n BIP: 132\n Title: Committee-based BIP Acceptance Process\n Authors: Andy Chase <theandychase@gmail.com>\n Status"
},
{
"path": "bip-0133.mediawiki",
"chars": 3985,
"preview": "<pre>\n BIP: 133\n Layer: Peer Services\n Title: feefilter message\n Authors: Alex Morcos <morcos@chaincode.com>\n Statu"
},
{
"path": "bip-0134.mediawiki",
"chars": 12367,
"preview": "<pre>\n BIP: 134\n Layer: Consensus (hard fork)\n Title: Flexible Transactions\n Authors: Tom Zander <tomz@freedommail.c"
},
{
"path": "bip-0135.mediawiki",
"chars": 17906,
"preview": "<pre>\n BIP: 135\n Title: Generalized version bits voting\n Authors: Sancho Panza <sanch0panza@protonmail.com>\n Status:"
},
{
"path": "bip-0136.mediawiki",
"chars": 30648,
"preview": "<pre>\n BIP: 136\n Layer: Applications\n Title: Bech32 Encoded Tx Position References\n Authors: Велеслав <veleslav.bips"
},
{
"path": "bip-0137.mediawiki",
"chars": 9444,
"preview": "<pre>\n BIP: 137\n Layer: Applications\n Title: Signatures of Messages using Private Keys\n Authors: Christopher Gilliar"
},
{
"path": "bip-0140.mediawiki",
"chars": 14931,
"preview": "<pre>\n BIP: 140\n Layer: Consensus (soft fork)\n Title: Normalized TXID\n Authors: Christian Decker <decker.christian@g"
},
{
"path": "bip-0141.mediawiki",
"chars": 26304,
"preview": "<pre>\n BIP: 141\n Layer: Consensus (soft fork)\n Title: Segregated Witness (Consensus layer)\n Authors: Eric Lombrozo <"
},
{
"path": "bip-0142.mediawiki",
"chars": 5820,
"preview": "<pre>\n BIP: 142\n Layer: Applications\n Title: Address Format for Segregated Witness\n Authors: Johnson Lau <jl2012@xbt"
},
{
"path": "bip-0143.mediawiki",
"chars": 57747,
"preview": "<pre>\n BIP: 143\n Layer: Consensus (soft fork)\n Title: Transaction Signature Verification for Version 0 Witness Progra"
},
{
"path": "bip-0144.mediawiki",
"chars": 5204,
"preview": "<pre>\n BIP: 144\n Layer: Peer Services\n Title: Segregated Witness (Peer Services)\n Authors: Eric Lombrozo <elombrozo@"
},
{
"path": "bip-0145.mediawiki",
"chars": 5934,
"preview": "<pre>\n BIP: 145\n Layer: API/RPC\n Title: getblocktemplate Updates for Segregated Witness\n Authors: Luke Dashjr <luke+"
},
{
"path": "bip-0146.mediawiki",
"chars": 7111,
"preview": "<pre>\n BIP: 146\n Layer: Consensus (soft fork)\n Title: Dealing with signature encoding malleability\n Authors: Johnson"
},
{
"path": "bip-0147.mediawiki",
"chars": 3587,
"preview": "<pre>\n BIP: 147\n Layer: Consensus (soft fork)\n Title: Dealing with dummy stack element malleability\n Authors: Johnso"
},
{
"path": "bip-0148.mediawiki",
"chars": 4224,
"preview": "<pre>\n BIP: 148\n Layer: Consensus (soft fork)\n Title: Mandatory activation of segwit deployment\n Authors: Shaolin Fr"
},
{
"path": "bip-0149.mediawiki",
"chars": 2601,
"preview": "<pre>\n BIP: 149\n Layer: Consensus (soft fork)\n Title: Segregated Witness (second deployment)\n Authors: Shaolin Fry <"
},
{
"path": "bip-0150.mediawiki",
"chars": 10628,
"preview": "<pre>\n BIP: 150\n Layer: Peer Services\n Title: Peer Authentication\n Authors: Jonas Schnelli <dev@jonasschnelli.ch>\n "
},
{
"path": "bip-0151.mediawiki",
"chars": 10331,
"preview": "<pre>\n BIP: 151\n Layer: Peer Services\n Title: Peer-to-Peer Communication Encryption\n Authors: Jonas Schnelli <dev@jo"
},
{
"path": "bip-0152.mediawiki",
"chars": 31006,
"preview": "<pre>\n BIP: 152\n Layer: Peer Services\n Title: Compact Block Relay\n Authors: Matt Corallo <bip152@bluematt.me>\n Comm"
},
{
"path": "bip-0154.mediawiki",
"chars": 30585,
"preview": "<pre>\n BIP: 154\n Layer: Peer Services\n Title: Rate Limiting via peer specified challenges\n Authors: Karl-Johan Alm <"
},
{
"path": "bip-0155.mediawiki",
"chars": 8892,
"preview": "<pre>\n BIP: 155\n Layer: Peer Services\n Title: addrv2 message\n Authors: Wladimir J. van der Laan <laanwj@gmail.com>\n "
},
{
"path": "bip-0156/bitcoin.conf",
"chars": 999,
"preview": "regtest=1 # Run this node on its own independent test network\ndebug=net # Enable network debug logs\n"
},
{
"path": "bip-0156.mediawiki",
"chars": 17320,
"preview": "<pre>\n BIP: 156\n Layer: Peer Services\n Title: Dandelion - Privacy Enhancing Routing\n Authors: Brad Denby <bdenby@cmu"
},
{
"path": "bip-0157.mediawiki",
"chars": 21050,
"preview": "<pre>\n BIP: 157\n Layer: Peer Services\n Title: Client Side Block Filtering\n Authors: Olaoluwa Osuntokun <laolu32@gmai"
},
{
"path": "bip-0158/gentestvectors.go",
"chars": 7196,
"preview": "// This program connects to your local btcd and generates test vectors for\n// 5 blocks and collision space sizes of 1-32"
},
{
"path": "bip-0158/go.mod",
"chars": 213,
"preview": "module github.com/bitcoin/bips/bip-0158\n\nrequire (\n\tgithub.com/btcsuite/btcd v0.0.0-20190115013929-ed77733ec07d\n\tgithub."
},
{
"path": "bip-0158/go.sum",
"chars": 5337,
"preview": "github.com/aead/siphash v1.0.1 h1:FwHfE/T45KPKYuuSAKyyvE+oPWcaQ+CUmFW0bPlM+kg=\ngithub.com/aead/siphash v1.0.1/go.mod h1:"
},
{
"path": "bip-0158/testnet-19.json",
"chars": 17816,
"preview": "[\n[\"Block Height,Block Hash,Block,[Prev Output Scripts for Block],Previous Basic Header,Basic Filter,Basic Header,Notes\""
},
{
"path": "bip-0158.mediawiki",
"chars": 16770,
"preview": "<pre>\n BIP: 158\n Layer: Peer Services\n Title: Compact Block Filters for Light Clients\n Authors: Olaoluwa Osuntokun <"
},
{
"path": "bip-0159.mediawiki",
"chars": 3359,
"preview": "<pre>\n BIP: 159\n Layer: Peer Services\n Title: NODE_NETWORK_LIMITED service bit\n Authors: Jonas Schnelli <dev@jonassc"
},
{
"path": "bip-0171.mediawiki",
"chars": 13036,
"preview": "<pre>\n BIP: 171\n Layer: Applications\n Title: Currency/exchange rate information API\n Authors: Luke Dashjr <luke+bip@"
},
{
"path": "bip-0172.mediawiki",
"chars": 8107,
"preview": "<pre>\n BIP: 172\n Layer: Applications\n Title: Define Bitcoin Subunits as Satoshis\n Authors: OceanSlim <oceanslim@gmx."
},
{
"path": "bip-0173.mediawiki",
"chars": 20799,
"preview": "<pre>\n BIP: 173\n Layer: Applications\n Title: Base32 address format for native v0-16 witness outputs\n Authors: Pieter"
},
{
"path": "bip-0174/build.sh",
"chars": 368,
"preview": "#!/bin/bash\n\npdflatex -output-format=pdf coinjoin-workflow.tex && \\\ninkscape --with-gui --export-text-to-path \\\n --expo"
}
]
// ... and 185 more files (download for full content)
About this extraction
This page contains the full source code of the bitcoin/bips GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 385 files (14.9 MB), approximately 3.9M tokens, and a symbol index with 735 extracted functions, classes, methods, constants, and types. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.