├── .gitattributes ├── .github └── workflows │ └── github-action-checks.yml ├── .gitignore ├── .typos.toml ├── CONTRIBUTING.md ├── README.mediawiki ├── bip-0001.mediawiki ├── bip-0001 └── process.png ├── bip-0002.mediawiki ├── bip-0002 ├── process.png └── process.svg ├── bip-0003.md ├── bip-0003 └── status-diagram.png ├── bip-0008.mediawiki ├── bip-0008 ├── assignments.mediawiki ├── states.dot ├── states.png └── states.svg ├── bip-0009.mediawiki ├── bip-0009 ├── assignments.mediawiki ├── states.gv └── states.png ├── bip-0010.mediawiki ├── bip-0011.mediawiki ├── bip-0012.mediawiki ├── bip-0013.mediawiki ├── bip-0014.mediawiki ├── bip-0015.mediawiki ├── bip-0016.mediawiki ├── bip-0016 └── qa.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-0032 └── derivation.png ├── bip-0033.mediawiki ├── bip-0034.mediawiki ├── bip-0035.mediawiki ├── bip-0036.mediawiki ├── bip-0037.mediawiki ├── bip-0038.mediawiki ├── bip-0039.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-0042.mediawiki ├── bip-0042 └── inflation.png ├── bip-0043.mediawiki ├── bip-0044.mediawiki ├── bip-0045.mediawiki ├── bip-0046.mediawiki ├── bip-0047.mediawiki ├── bip-0047 ├── reusable_payment_codes-01.png ├── reusable_payment_codes-02.png ├── reusable_payment_codes-03.png ├── reusable_payment_codes-04.png ├── reusable_payment_codes-05.png └── reusable_payment_codes-06.png ├── bip-0048.mediawiki ├── bip-0049.mediawiki ├── bip-0050.mediawiki ├── bip-0052.mediawiki ├── bip-0052 ├── btc_energy-small.png ├── btc_energy.png ├── emusk_tweet.png ├── optical_chip.png ├── optminer.png ├── sim1.png ├── sim2.png └── sim3.png ├── bip-0053.mediawiki ├── bip-0053 ├── 2-BitcoinMerkle.pdf ├── 64byte-tx-mainnet.txt └── non-standard-hashlock-utxos.txt ├── 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-0068 └── encoding.png ├── bip-0069.mediawiki ├── bip-0069 └── bip-0069_examples.py ├── bip-0070.mediawiki ├── bip-0070 ├── Protocol_Sequence.png ├── extensions.mediawiki └── paymentrequest.proto ├── bip-0071.mediawiki ├── bip-0072.mediawiki ├── bip-0073.mediawiki ├── bip-0073 ├── a.png └── b.png ├── bip-0074.mediawiki ├── bip-0075.mediawiki ├── bip-0075 ├── bip70-extension.png ├── encrypted-invoice-request-process.png ├── invoice-request-process.png ├── mobile-sf-encrypted-ir-without-payment.png ├── mobile-sf-ir-with-payment.png ├── mobile-sf-ir-without-payment.png └── paymentrequest.proto ├── 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-0090.mediawiki ├── bip-0091.mediawiki ├── bip-0093.mediawiki ├── bip-0094.mediawiki ├── bip-0098.mediawiki ├── bip-0098 ├── build.sh ├── node-variants.dot ├── node-variants.png ├── skip-skip.dot ├── skip-skip.png ├── traversal-example.dot ├── traversal-example.png ├── unbalanced-hash-tree.dot └── unbalanced-hash-tree.png ├── 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-0111.mediawiki ├── bip-0112.mediawiki ├── bip-0113.mediawiki ├── bip-0114.mediawiki ├── bip-0114 └── mastexample.png ├── bip-0115.mediawiki ├── bip-0116.mediawiki ├── bip-0117.mediawiki ├── bip-0118.mediawiki ├── bip-0119.mediawiki ├── bip-0119 ├── fifty.png ├── five.png ├── nic.svg ├── pooledcoshv.png ├── simulation.py ├── states.svg ├── vaultanim.gif ├── vaults.svg └── vectors │ ├── ctvhash.json │ ├── tx_invalid.json │ └── tx_valid.json ├── bip-0120.mediawiki ├── bip-0121.mediawiki ├── bip-0122.mediawiki ├── bip-0122 └── chainid.png ├── bip-0123.mediawiki ├── bip-0124.mediawiki ├── bip-0125.mediawiki ├── bip-0126.mediawiki ├── bip-0127.mediawiki ├── bip-0129.mediawiki ├── bip-0130.mediawiki ├── bip-0131.mediawiki ├── bip-0132.mediawiki ├── bip-0133.mediawiki ├── bip-0134.mediawiki ├── bip-0135.mediawiki ├── bip-0135 ├── bip-0135-states-small.png ├── bip-0135-states.png └── bip-0135-states.svg ├── bip-0136.mediawiki ├── bip-0137.mediawiki ├── bip-0140.mediawiki ├── bip-0141.mediawiki ├── bip-0142.mediawiki ├── bip-0143.mediawiki ├── bip-0144.mediawiki ├── bip-0144 └── witnesstx.png ├── 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-0152 └── protocol-flow.png ├── bip-0154.mediawiki ├── bip-0155.mediawiki ├── bip-0156.mediawiki ├── bip-0156 ├── 1-dandelion.png ├── 2-attack.png ├── 3-attack-plot.png ├── 4-dandelion-plot.png ├── bitcoin.conf ├── dandelion-debug-logs-example.pdf └── dandelion-reference-documentation.pdf ├── bip-0157.mediawiki ├── bip-0158.mediawiki ├── bip-0158 ├── gentestvectors.go ├── go.mod ├── go.sum └── testnet-19.json ├── bip-0159.mediawiki ├── bip-0171.mediawiki ├── bip-0172.mediawiki ├── bip-0173.mediawiki ├── bip-0174.mediawiki ├── bip-0174 ├── build.sh ├── coinjoin-workflow.svg ├── coinjoin-workflow.tex ├── multisig-workflow.svg └── multisig-workflow.tex ├── 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.mediawiki ├── bip-0300 ├── images.txt ├── m1-cli.png └── m1-gui.jpg ├── bip-0301.mediawiki ├── bip-0310.mediawiki ├── bip-0320.mediawiki ├── bip-0321.mediawiki ├── bip-0322.mediawiki ├── bip-0324.mediawiki ├── bip-0324 ├── ellswift_decode_test_vectors.csv ├── garbage_terminator.png ├── gen_test_vectors.py ├── 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-0325.mediawiki ├── bip-0326.mediawiki ├── bip-0327.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-0328.mediawiki ├── bip-0328 ├── _base58.py ├── _bip327.py ├── _common.py ├── _xpub.py ├── reference.py └── vectors.json ├── bip-0329.mediawiki ├── bip-0330.mediawiki ├── bip-0330 ├── minisketch.py └── recon_scheme_merged.png ├── bip-0331.mediawiki ├── bip-0331 ├── no_package_info.png ├── orphan_handling_flow.png ├── package_cpfp_flow.png ├── package_erlay.png ├── package_info_only.png ├── sender_init_future_version.png └── version_negotiation.png ├── bip-0337.mediawiki ├── bip-0338.mediawiki ├── bip-0339.mediawiki ├── bip-0340.mediawiki ├── bip-0340 ├── LICENSE ├── reference.py ├── test-vectors.csv └── test-vectors.py ├── bip-0341.mediawiki ├── bip-0341 ├── tree.png └── wallet-test-vectors.json ├── bip-0342.mediawiki ├── bip-0343.mediawiki ├── bip-0345.mediawiki ├── bip-0345 ├── opvault.drawio.png ├── vaults-Basic.png ├── vaults.drawio └── withdrawal-comparison.drawio.png ├── bip-0347.mediawiki ├── bip-0348.md ├── bip-0349.md ├── bip-0350.mediawiki ├── bip-0351.mediawiki ├── bip-0352.mediawiki ├── bip-0352 ├── bech32m.py ├── bitcoin_utils.py ├── reference.py ├── ripemd160.py ├── scan_data_downloader_per_month.png ├── secp256k1.py └── send_and_receive_test_vectors.json ├── bip-0353.mediawiki ├── bip-0370.mediawiki ├── bip-0371.mediawiki ├── bip-0372.mediawiki ├── bip-0373.mediawiki ├── bip-0374.mediawiki ├── bip-0374 ├── gen_test_vectors.py ├── reference.py ├── run_test_vectors.py ├── secp256k1.py ├── test_vectors_generate_proof.csv └── test_vectors_verify_proof.csv ├── 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.mediawiki ├── bip-0388 └── wallet_policies.py ├── bip-0389.mediawiki ├── bip-0390.mediawiki ├── bip-0431.mediawiki ├── bip-0443.mediawiki ├── bip-0443 ├── amount_example_1.png ├── amount_example_2.png ├── amount_example_3.png └── amount_example_4.png └── scripts ├── buildtable.pl ├── diffcheck.sh └── link-format-chk.sh /.gitattributes: -------------------------------------------------------------------------------- 1 | *.mediawiki linguist-detectable 2 | -------------------------------------------------------------------------------- /.github/workflows/github-action-checks.yml: -------------------------------------------------------------------------------- 1 | name: GitHub Actions Check 2 | run-name: ${{ github.actor }} Checks 🚀 3 | on: [push, pull_request] 4 | jobs: 5 | Link-Format-Checks: 6 | runs-on: ubuntu-latest 7 | steps: 8 | - uses: actions/checkout@v4 9 | - run: scripts/link-format-chk.sh 10 | Build-Table-Checks: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/checkout@v4 14 | - run: scripts/buildtable.pl >/tmp/table.mediawiki || exit 1 15 | Diff-Checks: 16 | name: "Diff Checks (fails until number assignment)" 17 | runs-on: ubuntu-latest 18 | steps: 19 | - uses: actions/checkout@v4 20 | with: 21 | fetch-depth: 2 22 | - run: scripts/diffcheck.sh 23 | Typo-Checks: 24 | name: "Typo Checks" 25 | runs-on: ubuntu-latest 26 | steps: 27 | - name: Checkout Actions Repository 28 | uses: actions/checkout@v4 29 | 30 | - name: Check spelling 31 | uses: crate-ci/typos@master 32 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | bip-0174/coinjoin-workflow.aux 2 | bip-0174/coinjoin-workflow.log 3 | bip-0174/coinjoin-workflow.pdf 4 | bip-0174/multisig-workflow.aux 5 | bip-0174/multisig-workflow.log 6 | bip-0174/multisig-workflow.pdf 7 | -------------------------------------------------------------------------------- /.typos.toml: -------------------------------------------------------------------------------- 1 | [default] 2 | extend-ignore-re = [ 3 | # NOTE: use here for regex patterns 4 | "xpub.*", 5 | "xprv.*", 6 | "3.*", # address 7 | "5.*", # address 8 | "private_key .*", 9 | "privkey .*", 10 | "tt.*", # tags 11 | "code.*", # tags 12 | "\\w*", # prefix for tags 13 | "OP_SUCCESSx|\\d+", 14 | "pay.*", 15 | "ser.*", 16 | "prefix.*", 17 | "value: .*", 18 | ] 19 | 20 | [default.extend-words] 21 | # NOTE: use here for false-positives 22 | anc = "anc" 23 | PSBT = "PSBT" 24 | ser = "ser" 25 | # Names 26 | Atack = "Atack" 27 | Meni = "Meni" 28 | Ono = "Ono" 29 | 30 | [files] 31 | extend-exclude = [ 32 | "/*/*.csv", 33 | "/*.d*", 34 | "/*/*.d*", 35 | "/*/*.go", 36 | "/*/*.json", 37 | "/*/*/*.json", 38 | "/*/*.mod", 39 | "/*/*.proto", 40 | "/*/*.py", 41 | "scripts", 42 | "/*/*.s*", 43 | "/*/*.t*", 44 | ] 45 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing Guidelines 2 | 3 | Apart from following [BIP 2](./bip-0002.mediawiki), 4 | we do CI checks to ensure that the proposed BIPs do not have common typos. 5 | These checks are done using [`typos`](https://github.com/crate-ci/typos). 6 | To check for typos locally, 7 | install [`typos`](https://github.com/crate-ci/typos) 8 | and then run in the root directory: 9 | 10 | ```bash 11 | typos 12 | ``` 13 | -------------------------------------------------------------------------------- /bip-0001/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0001/process.png -------------------------------------------------------------------------------- /bip-0002/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0002/process.png -------------------------------------------------------------------------------- /bip-0002/process.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | Draft 26 | 27 | 28 | Proposed 29 | 30 | 31 | Final/Active 32 | 33 | 34 | Replaced 35 | 36 | 37 | 38 | Rejected 39 | 40 | 41 | 42 | 43 | Withdrawn 44 | 45 | 46 | 47 | Deferred 48 | 49 | 50 | 51 | 52 | Obsolete 53 | 54 | -------------------------------------------------------------------------------- /bip-0003/status-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0003/status-diagram.png -------------------------------------------------------------------------------- /bip-0008/assignments.mediawiki: -------------------------------------------------------------------------------- 1 | ==Deployments== 2 | 3 | List of deployments. 4 | 5 | State can be defined, active, failed. Dates are in UTC. 6 | 7 | -------------------------------------------------------------------------------- /bip-0008/states.dot: -------------------------------------------------------------------------------- 1 | digraph { 2 | rankdir=TD; 3 | 4 | node [style="rounded,filled,bold", shape=box, fixedsize=true, width=1.5, fontname="Arial"]; 5 | 6 | edge [weight = 100]; 7 | "DEFINED" -> "STARTED" [label="height >= start_height"]; 8 | "STARTED" -> "MUST_SIGNAL" [label="height + 2016 >= timeoutheight AND lockinontimeout"]; 9 | "STARTED" -> "FAILED" [label="height >= timeoutheight\nAND\nNOT lockinontimeout"]; 10 | "LOCKED_IN" -> "ACTIVE" [label="height >= minimum_activation_height"]; 11 | "LOCKED_IN":se -> "LOCKED_IN":ne [label="height < minimum_activation_height"]; 12 | "MUST_SIGNAL" -> "LOCKED_IN" [label="always"]; 13 | 14 | edge [weight = 1]; 15 | "STARTED" -> "LOCKED_IN" [label="height < timeoutheight\nAND\nthreshold reached"]; 16 | 17 | "FAILED" -> "LOCKED_IN" [style=invis]; 18 | 19 | "DEFINED":sw -> "DEFINED":nw; 20 | "STARTED":sw -> "STARTED":nw; 21 | "ACTIVE":sw -> "ACTIVE":nw; 22 | "FAILED":sw -> "FAILED":nw; 23 | 24 | "STARTED" [fillcolor="#a0a0ff"]; 25 | "MUST_SIGNAL" [fillcolor="#a0a0ff"]; 26 | "LOCKED_IN" [fillcolor="#ffffa0"]; 27 | "ACTIVE" [fillcolor="#a0ffa0"]; 28 | "FAILED" [fillcolor="#ffa0a0"]; 29 | 30 | { rank=same; "STARTED" "MUST_SIGNAL" } 31 | { rank=same; "FAILED" "LOCKED_IN" } 32 | { rank=sink; "ACTIVE" } 33 | } 34 | 35 | 36 | -------------------------------------------------------------------------------- /bip-0008/states.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0008/states.png -------------------------------------------------------------------------------- /bip-0009/assignments.mediawiki: -------------------------------------------------------------------------------- 1 | ==Deployments== 2 | 3 | List of proposed deployments. 4 | 5 | State can be defined, active, failed. Dates are in UTC. 6 | 7 | {| class="wikitable sortable" 8 | ! Name 9 | ! Bit 10 | ! Mainnet Start 11 | ! Mainnet Expire 12 | ! Mainnet State 13 | ! Testnet Start 14 | ! Testnet Expire 15 | ! Testnet State 16 | ! BIPs 17 | |- 18 | | csv 19 | | 0 20 | | 2016-05-01 00:00:00 21 | | 2017-05-01 00:00:00 22 | | active since #419328 23 | | 2016-03-01 00:00:00 24 | | 2017-05-01 00:00:00 25 | | active since #770112 26 | | [[/bip-0068.mediawiki|68]], [[/bip-0112.mediawiki|112]], [[/bip-0113.mediawiki|113]] 27 | |- 28 | | segwit 29 | | 1 30 | | 2016-11-15 00:00:00 31 | | 2017-11-15 00:00:00 32 | | active since #481824 33 | | 2016-05-01 00:00:00 34 | | 2017-05-01 00:00:00 35 | | active since #834624 36 | | [[/bip-0141.mediawiki|141]], [[/bip-0143.mediawiki|143]], [[/bip-0147.mediawiki|147]] 37 | |} 38 | -------------------------------------------------------------------------------- /bip-0009/states.gv: -------------------------------------------------------------------------------- 1 | /* There are many ways to compile this, but one of them is: 2 | * 3 | * $ dot -Tpng states.gv -o states.png 4 | */ 5 | digraph { 6 | /* States. */ 7 | DEFINED; FAILED; STARTED; LOCKED_IN; ACTIVE; 8 | 9 | /* Relationships between states, labeled where applicable. */ 10 | DEFINED -> DEFINED; 11 | DEFINED -> FAILED [label = "timeout ≤ MTP"]; 12 | DEFINED -> STARTED [label = "starttime ≤ MTP < timeout"]; 13 | FAILED -> FAILED; 14 | STARTED -> STARTED; 15 | STARTED -> FAILED [label = "timeout ≤ MTP"]; 16 | STARTED -> LOCKED_IN [label = "(MTP < timeout) AND (threshold reached)"]; 17 | LOCKED_IN -> ACTIVE [label = "Always"]; 18 | ACTIVE -> ACTIVE; 19 | 20 | /* Visualization hack to unclutter output. */ 21 | nodesep = 1.2; 22 | } 23 | -------------------------------------------------------------------------------- /bip-0009/states.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0009/states.png -------------------------------------------------------------------------------- /bip-0011.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 11
 3 |   Layer: Applications
 4 |   Title: M-of-N Standard Transactions
 5 |   Author: Gavin Andresen 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0011
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2011-10-18
11 |   Post-History: 2011-10-02
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type. 17 | 18 | ==Motivation== 19 | 20 | Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. 21 | 22 | A couple of motivating use cases: 23 | 24 | * 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. 25 | 26 | * 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).
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. 27 | 28 | ==Specification== 29 | 30 | A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks: 31 | 32 | m {pubkey}...{pubkey} n OP_CHECKMULTISIG 33 | 34 | But only for n less than or equal to 3. 35 | 36 | OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig: 37 | OP_0 ...signatures... 38 | 39 | (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). 40 | 41 | 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. 42 | 43 | ==Rationale== 44 | 45 | OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases. 46 | 47 | 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. 48 | 49 | 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. 50 | 51 | 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. 52 | 53 | ==Implementation== 54 | 55 | OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type. 56 | 57 | https://github.com/gavinandresen/bitcoin-git/tree/77f21f1583deb89bf3fffe80fe9b181fedb1dd60 58 | 59 | == Post History == 60 | 61 | * [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal] 62 | -------------------------------------------------------------------------------- /bip-0013.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 13
 3 |   Layer: Applications
 4 |   Title: Address Format for pay-to-script-hash
 5 |   Author: Gavin Andresen 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0013
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2011-10-18
11 |
12 | 13 | ==Abstract== 14 | 15 | 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. 16 | 17 | 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. 18 | 19 | ==Motivation== 20 | 21 | Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet security services. 22 | 23 | ==Specification== 24 | 25 | The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [https://en.bitcoin.it/Base58Check_encoding Base58Check encoding]): 26 | 27 | base58-encode: [one-byte version][20-byte hash][4-byte checksum] 28 | 29 | Version byte is 5 for a main-network address, 196 for a testnet address. 30 | The 20-byte hash is the hash of the script that will be used to redeem the coins. 31 | And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and hash. 32 | 33 | ==Rationale== 34 | 35 | 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. 36 | 37 | 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? 38 | 39 | 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. 40 | 41 | 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. 42 | 43 | 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. 44 | 45 | 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'. 46 | 47 | ==Backwards Compatibility== 48 | 49 | 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. 50 | 51 | ==Reference Implementation== 52 | 53 | See base58.cpp/base58.h at https://github.com/bitcoin/bitcoin/tree/master/src 54 | 55 | ==See Also== 56 | 57 | * [[bip-0012.mediawiki|BIP 12: OP_EVAL, the original P2SH design]] 58 | * [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]] 59 | * [[bip-0017.mediawiki|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]] 60 | -------------------------------------------------------------------------------- /bip-0019.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 19
 3 |   Layer: Applications
 4 |   Title: M-of-N Standard Transactions (Low SigOp)
 5 |   Author: Luke Dashjr 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0019
 8 |   Status: Rejected
 9 |   Type: Standards Track
10 |   Created: 2012-01-30
11 |   License: BSD-2-Clause
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications. 17 | 18 | ==Copyright== 19 | 20 | This BIP is licensed under the BSD 2-clause license. 21 | 22 | ==Motivation== 23 | 24 | Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. 25 | 26 | A couple of motivating use cases: 27 | 28 | * 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. 29 | 30 | * 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).
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. 31 | 32 | ==Specification== 33 | 34 | Two new standard transaction types (scriptPubKey) that are relayed by clients and included in mined blocks. 35 | 36 | N-of-N (all signatures required): 37 | 38 | ( {pubkey} OP_CHECKSIGVERIFY )*n 39 | 40 | N-of-M (some signatures required): 41 | 42 | {pubkey} OP_CHECKSIG ( OP_SWAP {pubkey} OP_CHECKSIG OP_ADD )*(n-1) n OP_EQUAL 43 | 44 | But only for n less than or equal to 3. 45 | 46 | These transactions are redeemed using a standard scriptSig: 47 | ...signatures... 48 | 49 | 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. 50 | 51 | ===Templates=== 52 | scriptPubKey: 53 | 54 | {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY 55 | 56 | {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY 57 | 58 | {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL 59 | 60 | {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL 61 | 62 | scriptSig: 63 | 64 | ...signatures... up to 500 bytes 65 | 66 | ==Rationale== 67 | 68 | OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases. 69 | This is already specified in [[bip-0011.mediawiki|BIP 0011]]. 70 | However, each OP_CHECKMULTISIG counts toward the block limit as 20 sigops, which only allows 1000 total multisig transactions in a block. 71 | Using OP_CHECKSIG only counts as 1 per signature, so can scale better. 72 | 73 | ==Implementation== 74 | 75 | All used operations are already supported by old clients and miners as a non-standard transaction type. 76 | -------------------------------------------------------------------------------- /bip-0030.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 30
 3 |   Layer: Consensus (soft fork)
 4 |   Title: Duplicate transactions
 5 |   Author: Pieter Wuille 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0030
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2012-02-22
11 |   License: BSD-2-Clause
12 |
13 | 14 | ==Abstract== 15 | This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementation has with them. 16 | 17 | ==Copyright== 18 | 19 | This BIP is licensed under the 2-clause BSD license. 20 | 21 | ==Motivation== 22 | So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. This is not true; in particular coinbases are easy to duplicate, and by building on duplicate coinbases, duplicate normal transactions are possible as well. Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network. 23 | 24 | ==Specification== 25 | To counter this problem, the following network rule is introduced: 26 | *Blocks are not allowed to contain a transaction whose identifier matches that of an earlier, not-fully-spent transaction in the same chain. 27 | 28 | This rule initially applied to all blocks whose timestamp is after March 15, 2012, 00:00 UTC (testnet: February 20, 2012 00:00 UTC). It was later extended by Commit [https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514 Apply BIP30 checks to all blocks except the two historic violations.] to apply to all blocks except the two historic blocks at heights 91842 and 91880 on the main chain that had to be grandfathered in. 29 | 30 | ==Rationale== 31 | Whatever solution is used, the following law must be obeyed to guarantee sane behaviour: the set of usable 32 | transactions outputs must not be modified by adding blocks to the chain and removing them again. This happens during 33 | a reorganisation, and the current Bitcoin reference implementation does not obey this law in case the temporarily 34 | added blocks contain a duplicate transaction. 35 | 36 | There are several potential solutions to this problem: 37 | #Guarantee that all coinbases are unique, making duplicate transactions very hard to create. 38 | #Remember previous remaining outputs of a given transaction identifier, in case a new transaction with the same identifier is added. 39 | #Only allow duplicate transactions in case the previous instance of the transaction had no spendable outputs left. Removing a block from the chain can then safely reset the removed transaction's outputs to nothing. 40 | 41 | The first option is probably the most complete one, as it also guarantees transaction identifiers are unique. However, implementing it requires several changes that need to be accepted throughout the network. Furthermore, it does not prevent duplicate transactions based on earlier duplicate coinbases. The second option is impossible to implement in a forward-compatible way, as it potentially renders currently-invalid blocks valid. In this document we choose for the third option, because it only requires a trivial change. 42 | 43 | Fully-spent transactions are allowed to be duplicated in order not to hinder pruning at some point in the future. Not allowing any transaction to be duplicated would require evidence to be kept for each transaction ever made. 44 | 45 | ==Backward compatibility== 46 | The addition of this rule only makes some previously-valid blocks invalid. This implies that if the rule is implemented by a supermajority of miners, it is not possible to fork the block chain in a permanent way between nodes with and without the new rule. 47 | 48 | ==Implementation== 49 | A patch for the reference client can be found on https://github.com/sipa/bitcoin/tree/nooverwritetx 50 | 51 | This BIP was implemented in Commit [https://github.com/bitcoin/bitcoin/commit/a206b0ea12eb4606b93323268fc81a4f1f952531 Do not allow overwriting unspent transactions (BIP 30)] 52 | There have been additional commits to refine the implementation of this BIP. 53 | 54 | ==Acknowledgements== 55 | Thanks to Russell O'Connor for finding and demonstrating this problem, and helping test the patch. 56 | -------------------------------------------------------------------------------- /bip-0031.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 31
 3 |   Layer: Peer Services
 4 |   Title: Pong message
 5 |   Author: Mike Hearn 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0031
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2012-04-11
11 |
12 | 13 | ==Abstract== 14 | 15 | This document describes a trivial protocol extension that makes it easier for clients to detect dead peer connections. 16 | 17 | ==Motivation== 18 | 19 | Today there are a few network related problems that can degrade the Bitcoin user experience: 20 | 21 | 1) Some Bitcoin clients run on platforms that can go to sleep and essentially stop running at any time without warning. Notably, this is very common on both mobiles and laptops (shut the lid). When the system comes back, TCP connections that existed before the sleep still exist but may no longer function correctly, eg, because the IP address has changed, or because the remote peer went away or the connection was timed out by some other system. Currently it can often take a while to notice this has happened. 22 | 23 | 2) The reference Satoshi client is largely single threaded and when placed under heavy load (e.g., because it is downloading the block chain) becomes very slow to respond to network messages. There's no easy way to detect this has occurred, especially if you are just passively waiting for broadcasts from that peer. A way to detect overloaded remote peers and avoid them would both help balance load and provide a better, more responsive system. 24 | 25 | 3) When downloading large data structures like the block chain it is efficient to choose a peer that is near to you network-wise, in order to reduce load on often congested trans-national links and ensure lower latency. Currently it is difficult to measure the latency to a remote peer so clients don't bother, and instead just select a random peer to download from. 26 | 27 | All of these can be solved by a backwards compatible protocol modification. 28 | 29 | ==Specification== 30 | 31 | When the protocol version as negotiated in the "ver" message is greater than 60000, the "ping" message must contain a uint64 field called "nonce". A peer sending "ping" should set the nonce to a random value, and it is then echoed back by the recipient in a new "pong" message that also contains a single uint64 field. 32 | 33 | In this way, the client can send a ping and measure the time taken to receive the corresponding pong. If a client sends two pings before hearing back the first pong, the responses can be distinguished using the nonce. If the client chooses to never overlap pings in this way it should simply set the nonce value to zero. 34 | 35 | ==Backward compatibility== 36 | 37 | Clients must opt-in to the new feature by advertising a protocol version > 60000. Clients with older protocol versions are not expected to provide a nonce in the ping message and will not be sent a pong. 38 | 39 | ==Implementation== 40 | 41 | https://github.com/bitcoin/bitcoin/pull/932/files 42 | -------------------------------------------------------------------------------- /bip-0032/derivation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0032/derivation.png -------------------------------------------------------------------------------- /bip-0034.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 34
 3 |   Layer: Consensus (soft fork)
 4 |   Title: Block v2, Height in Coinbase
 5 |   Author: Gavin Andresen 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0034
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2012-07-06
11 |
12 | 13 | ==Abstract== 14 | 15 | Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique value is added to newly produced coinbase transactions, and blocks are updated to version 2. 16 | 17 | ==Motivation== 18 | 19 | # Clarify and exercise the mechanism whereby the bitcoin network collectively consents to upgrade transaction or block binary structures, rules and behaviors. 20 | # Enforce block and transaction uniqueness, and assist unconnected block validation. 21 | 22 | ==Specification== 23 | 24 | # Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them). 25 | # Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "minimally encoded serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 223-1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0). 26 | # 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100) 27 | # 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100) 28 | 29 | ==Backward compatibility== 30 | 31 | All older clients are compatible with this change. Users and merchants should not be impacted. Miners are strongly recommended to upgrade to version 2 blocks. Once 95% of the miners have upgraded to version 2, the remainder will be orphaned if they fail to upgrade. 32 | 33 | ==Implementation== 34 | 35 | https://github.com/bitcoin/bitcoin/pull/1526 36 | 37 | ==Result== 38 | 39 | Block number 227,835 (timestamp 2013-03-24 15:49:13 GMT) was the last version 1 block. 40 | -------------------------------------------------------------------------------- /bip-0035.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 35
 3 |   Layer: Peer Services
 4 |   Title: mempool message
 5 |   Author: Jeff Garzik 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0035
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2012-08-16
11 |
12 | 13 | ==Abstract== 14 | 15 | Make a network node's transaction memory pool accessible via a new "mempool" message. Extend the existing "getdata" message behavior to permit accessing the transaction memory pool. 16 | 17 | ==Motivation== 18 | 19 | Several use cases make it desirable to expose a network node's transaction memory pool: 20 | # SPV clients, wishing to obtain zero-confirmation transactions sent or received. 21 | # Miners, to avoid missing lucrative fees, downloading existing network transactions after a restart. 22 | # Remote network diagnostics. 23 | 24 | ==Specification== 25 | 26 | # The mempool message is defined as an empty message where pchCommand == "mempool" 27 | # Upon receipt of a "mempool" message, the node will respond with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool, if any. 28 | # The typical node behavior in response to an "inv" is "getdata". However, the reference Satoshi implementation ignores requests for transaction hashes outside that which is recently relayed. To support "mempool", an implementation must extend its "getdata" message support to querying the memory pool. 29 | # Feature discovery is enabled by checking two "version" message attributes: 30 | ## Protocol version >= 60002 31 | ## NODE_NETWORK bit set in nServices 32 | 33 | Note that existing implementations drop "inv" messages with a vector size > 50000. 34 | 35 | ==Backward compatibility== 36 | 37 | Older clients remain 100% compatible and interoperable after this change. 38 | 39 | ==Implementation== 40 | 41 | https://github.com/bitcoin/bitcoin/pull/1641 42 | -------------------------------------------------------------------------------- /bip-0042.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 42
 3 |   Layer: Consensus (soft fork)
 4 |   Title: A finite monetary supply for Bitcoin
 5 |   Author: Pieter Wuille 
 6 |   Comments-Summary: Unanimously Recommended for implementation
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2014-04-01
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillennium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years. 17 | 18 | This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. 19 | 20 | To combat this, this document proposes a controversial change: making Bitcoin's monetary supply finite. 21 | 22 | ==Details== 23 | 24 | As is well known, Satoshi was a master programmer whose knowledge of C++ was surpassed only by his knowledge of Japanese culture. The code below: 25 | 26 | int64_t nSubsidy = 50 * COIN; 27 | // Subsidy is cut in half every 210,000 blocks 28 | // which will occur approximately every 4 years. 29 | nSubsidy >>= (nHeight / 210000); 30 | 31 | is carefully written to rely on undefined behaviour in the C++ specification - perhaps so it can be hardware accelerated in future. 32 | 33 | The block number is divided by 210000 (the "apparent" subsidy halving interval in blocks), and the result is used as input for a binary shift, applied to the original payout (50 BTC), expressed in base units. Thanks to the new-goldmine interval being exactly 64 times the halving interval, and 64 being the size in bits of the currency datatype, the cycle repeats itself every 64 halvings on all currently supported platforms. 34 | 35 | Despite the nice showoff of underhanded programming skills - we want Bitcoin to be well-specified. Otherwise, we're clearly in for a bumpy ride: 36 | 37 | 38 | 39 | Note that several other programming languages do not exhibit this behaviour, making new implementations likely to be slower and generally more bogus than Bitcoin Core. For example, Python unexpectedly returns 0 when shifting an integer beyond its size. 40 | 41 | ==Other solutions== 42 | 43 | ===Floating-point approximation=== 44 | 45 | An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript. 46 | 47 | ===Truncation=== 48 | 49 | An alternative solution would be to represent the total number of bitcoins as a string: 50 | 51 | "21000000000000000000000" 52 | 53 | and then use string manipulation to remove the rightmost zero every 4 years, give or take a leap-year: 54 | 55 | strSubsidy = strSubsidy.substr(0, strSubsidy.size() - 2); 56 | 57 | This style relies less heavily on clever C++ and is more familiar to the Core Dev Team who are primarily PHP programmers. 58 | 59 | ==Proposal== 60 | 61 | Instead, how about we stop thinking about long term issues when we'll all be dead (barring near lightspeed travel, cryogenic revival, or other technology— like cryptocurrency— which only exists in science fiction). 62 | 63 | A softfork (see BIP16, BIP34, BIP62) will take place on april 1st 2214, permanently setting the subsidy to zero. The result of this will be that the total currency supply will be limited to 42 halfmillion (including the genesis coinbase output, which is not actually spendable). 64 | 65 | ==Implementation== 66 | 67 | An implementation for the reference client can be found on https://github.com/bitcoin/bitcoin/pull/3842 . 68 | 69 | ==Compatibility== 70 | 71 | Given the moderate time frame over which this change is to be implemented, we expect all miners to choose to screw themselves and deploy this change before 2214. 72 | 73 | If they don't, and a minority remains on the old code base, a fork may occur. Essentially, they'll be mining fool's gold after that time. 74 | 75 | ==Acknowledgements== 76 | 77 | Thanks to Gregory Maxwell for proposing this solution, and to Mike Hearn for insights into web development. Also thanks to "ditto-b" on github to implement a prototype ahead of time. 78 | 79 | ==Copyright== 80 | 81 | This document is placed in the public domain. 82 | -------------------------------------------------------------------------------- /bip-0042/inflation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0042/inflation.png -------------------------------------------------------------------------------- /bip-0043.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 43
 3 |   Layer: Applications
 4 |   Title: Purpose Field for Deterministic Wallets
 5 |   Author: Marek Palatinus 
 6 |           Pavol Rusnak 
 7 |   Comments-Summary: No comments yet.
 8 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0043
 9 |   Status: Final
10 |   Type: Standards Track
11 |   Created: 2014-04-24
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP introduces a "Purpose Field" for use in deterministic wallets 17 | based on algorithm described in BIP-0032 (BIP32 from now on). 18 | 19 | ==Motivation== 20 | 21 | Although Hierarchical Deterministic Wallet structure as described by BIP32 22 | is an important step in user experience and security of the cryptocoin wallets, 23 | the BIP32 specification offers implementers too many degrees of freedom. 24 | Multiple implementations may claim they are BIP32 compatible, but in fact 25 | they can produce wallets with different logical structures making them 26 | non-interoperable. This situation unfortunately renders "BIP32 compatible" 27 | statement rather useless. 28 | 29 | 30 | ==Purpose== 31 | 32 | We propose the first level of BIP32 tree structure to be used as "purpose". 33 | This purpose determines the further structure beneath this node. 34 | 35 | 
36 | m / purpose' / *
37 |
38 | 39 | Apostrophe indicates that BIP32 hardened derivation is used. 40 | 41 | We encourage different schemes to apply for assigning a separate BIP number 42 | and use the same number for purpose field, so addresses won't be generated 43 | from overlapping BIP32 spaces. 44 | 45 | Purpose codes from 10001 to 19999 are reserved for [[https://github.com/satoshilabs/slips|SLIPs]]. 46 | 47 | Example: Scheme described in BIP44 should use 44' (or 0x8000002C) as purpose. 48 | 49 | Note that m / 0' / * is already taken by BIP32 (default account), which 50 | preceded this BIP. 51 | 52 | Not all wallets may want to support the full range of features and possibilities 53 | described in these BIPs. Instead of choosing arbitrary subset of defined features 54 | and calling themselves BIPxx compatible, we suggest that software which needs 55 | only a limited structure should describe such structure in another BIP and use 56 | different "purpose" value. 57 | 58 | 59 | ==Node serialization== 60 | 61 | Because this scheme can be used to generate nodes for more cryptocurrencies 62 | at once, or even something totally unrelated to cryptocurrencies, there's no 63 | point in using a special version magic described in section "Serialization 64 | format" of BIP32. We suggest to use always 0x0488B21E for public and 0x0488ADE4 65 | for private nodes (leading to prefixes "xpub" and "xprv" respectively). 66 | 67 | ==Reference== 68 | 69 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 70 | -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0047/reusable_payment_codes-01.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0047/reusable_payment_codes-02.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0047/reusable_payment_codes-03.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0047/reusable_payment_codes-04.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0047/reusable_payment_codes-05.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-06.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0047/reusable_payment_codes-06.png -------------------------------------------------------------------------------- /bip-0052/btc_energy-small.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0052/btc_energy-small.png -------------------------------------------------------------------------------- /bip-0052/btc_energy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0052/btc_energy.png -------------------------------------------------------------------------------- /bip-0052/emusk_tweet.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0052/emusk_tweet.png -------------------------------------------------------------------------------- /bip-0052/optical_chip.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0052/optical_chip.png -------------------------------------------------------------------------------- /bip-0052/optminer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0052/optminer.png -------------------------------------------------------------------------------- /bip-0052/sim1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0052/sim1.png -------------------------------------------------------------------------------- /bip-0052/sim2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0052/sim2.png -------------------------------------------------------------------------------- /bip-0052/sim3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0052/sim3.png -------------------------------------------------------------------------------- /bip-0053/2-BitcoinMerkle.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0053/2-BitcoinMerkle.pdf -------------------------------------------------------------------------------- /bip-0053/64byte-tx-mainnet.txt: -------------------------------------------------------------------------------- 1 | 892f44a49de6f5b212cdbea514d09e692d9fed5d897f37bcef14bd0eedebf193 2 | bbf71454857438c6dfd64c0d92a7c5360a8d8d57c9202f5806449e5b0d26b848 3 | 6713d61a83e3d095582211ea8d6db452ac7561e863decba7c4046fb9f6d88aa0 4 | 7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612 5 | 5302e01dc4b7e34314a34c7c3347107e612b9524be684d388cd4d2ca35ff1ec9 -------------------------------------------------------------------------------- /bip-0053/non-standard-hashlock-utxos.txt: -------------------------------------------------------------------------------- 1 | af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d:0 2 | faf8989ed87c5a667a1ead813aea718727e01767c124193297eaf409ff4645e5:1 3 | c4b46c5d88327d7af6254820562327c5f11b6ee5449da04b7cfd3710b48b6f55:0 4 | 702c36851ed202495c2bec1dd0cefb448b50fafd3a5cdd5058c18ca53fc2c3d1:0 5 | 6f8a70aac37786b1f619d40250b8bca1a1f6da487146a7e81091f611068a23ef:0 6 | fb01987b540ec286973aac248fab643de82813af452d958056fee8de9f4535ab:0 -------------------------------------------------------------------------------- /bip-0060.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 60
 3 |   Layer: Peer Services
 4 |   Title: Fixed Length "version" Message (Relay-Transactions Field)
 5 |   Author: Amir Taaki 
 6 |   Comments-Summary: Discouraged for implementation (one person)
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0060
 8 |   Status: Rejected
 9 |   Type: Standards Track
10 |   Created: 2013-06-16
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | [[BIP 0037]] introduced a new flag to version messages which says whether to relay new transaction messages to that node. 17 | 18 | The protocol version was upgraded to 70001, and the (now accepted) BIP 0037 became implemented. 19 | 20 | The implementation is problematic because the RelayTransactions flag is an optional part of the version message stream. 21 | 22 | ==Motivation== 23 | 24 | One property of Bitcoin messages is their fixed number of fields. This keeps the format simple and easily understood. Adding optional fields to messages will cause deserialisation issues when other fields come after the optional one. 25 | 26 | As an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict adherence to standard messages with field length compliance with every protocol version. 27 | 28 | Another property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader. 29 | 30 | ==Specification== 31 | === version === 32 | 33 | When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version. 34 | 35 | Payload: 36 | 37 | {|class="wikitable" 38 | ! Field Size !! Description !! Data type !! Comments 39 | |- 40 | | 4 || version || int32_t || Identifies protocol version being used by the node 41 | |- 42 | | 8 || services || uint64_t || bitfield of features to be enabled for this connection 43 | |- 44 | | 8 || timestamp || int64_t || standard UNIX timestamp in seconds 45 | |- 46 | | 26 || addr_recv || net_addr || The network address of the node receiving this message 47 | |- 48 | |colspan="4"| version >= 106 49 | |- 50 | | 26 || addr_from || net_addr || The network address of the node emitting this message 51 | |- 52 | | 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self. 53 | |- 54 | | ? || user_agent || var_str || [[bip-0014.mediawiki|User Agent]] (0x00 if string is 0 bytes long) 55 | |- 56 | | 4 || start_height || int32_t || The last block received by the emitting node 57 | |- 58 | | 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[bip-0037.mediawiki|BIP 0037]], since version >= 70001 59 | |} 60 | 61 | A "verack" packet shall be sent if the version packet was accepted. 62 | 63 | The following services are currently assigned: 64 | 65 | {|class="wikitable" 66 | ! Value !! Name !! Description 67 | |- 68 | | 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers. 69 | |} 70 | 71 | === Code Updates === 72 | 73 | fRelayTx is added to the PushMessage() call inside PushVersion() (net.cpp) 74 | 75 | 
76 | void CNode::PushVersion()
77 | {
78 |     /// when NTP implemented, change to just nTime = GetAdjustedTime()
79 |     int64 nTime = (fInbound ? GetAdjustedTime() : GetTime());
80 |     CAddress addrYou = (addr.IsRoutable() && !IsProxy(addr) ? addr : CAddress(CService("0.0.0.0",0)));
81 |     CAddress addrMe = GetLocalAddress(&addr);
82 |     RAND_bytes((unsigned char*)&nLocalHostNonce, sizeof(nLocalHostNonce));
83 |     printf("send version message: version %d, blocks=%d, us=%s, them=%s, peer=%s\n", PROTOCOL_VERSION, nBestHeight, addrMe.ToString().c_str(), addrYou.ToString().c_str(), addr.ToString().c_str());
84 |     PushMessage("version", PROTOCOL_VERSION, nLocalServices, nTime, addrYou, addrMe,
85 |                 nLocalHostNonce, FormatSubVersion(CLIENT_NAME, CLIENT_VERSION, std::vector()),
86 |                 nBestHeight, true);
87 | }
88 |
89 | 90 | Additionally the protocol version is increased from 70001 to 70002. 91 | 92 | ==Copyright== 93 | 94 | This document is placed in the public domain. 95 | -------------------------------------------------------------------------------- /bip-0068/encoding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0068/encoding.png -------------------------------------------------------------------------------- /bip-0070/Protocol_Sequence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0070/Protocol_Sequence.png -------------------------------------------------------------------------------- /bip-0070/extensions.mediawiki: -------------------------------------------------------------------------------- 1 | ==BIP70 Extensions== 2 | 3 | Add your extension below using tags starting at 1000 and submit a pull-req. 4 | 5 | {| 6 | | Field Number || Extension Name || Field Name || Description 7 | |- 8 | | 1000 || [[https://example.com|(unassigned)]] || (unassigned) || (unassigned) 9 | |} 10 | -------------------------------------------------------------------------------- /bip-0070/paymentrequest.proto: -------------------------------------------------------------------------------- 1 | // 2 | // Simple Bitcoin Payment Protocol messages 3 | // 4 | // Use fields 1000+ for extensions; 5 | // to avoid conflicts, register extensions via pull-req at 6 | // https://github.com/bitcoin/bips/blob/master/bip-0070/extensions.mediawiki 7 | // 8 | 9 | package payments; 10 | option java_package = "org.bitcoin.protocols.payments"; 11 | option java_outer_classname = "Protos"; 12 | 13 | // Generalized form of "send payment to this/these bitcoin addresses" 14 | message Output { 15 | optional uint64 amount = 1 [default = 0]; // amount is integer-number-of-satoshis 16 | required bytes script = 2; // usually one of the standard Script forms 17 | } 18 | message PaymentDetails { 19 | optional string network = 1 [default = "main"]; // "main" or "test" 20 | repeated Output outputs = 2; // Where payment should be sent 21 | required uint64 time = 3; // Timestamp; when payment request created 22 | optional uint64 expires = 4; // Timestamp; when this request should be considered invalid 23 | optional string memo = 5; // Human-readable description of request for the customer 24 | optional string payment_url = 6; // URL to send Payment and get PaymentACK 25 | optional bytes merchant_data = 7; // Arbitrary data to include in the Payment message 26 | } 27 | message PaymentRequest { 28 | optional uint32 payment_details_version = 1 [default = 1]; 29 | optional string pki_type = 2 [default = "none"]; // none / x509+sha256 / x509+sha1 30 | optional bytes pki_data = 3; // depends on pki_type 31 | required bytes serialized_payment_details = 4; // PaymentDetails 32 | optional bytes signature = 5; // pki-dependent signature 33 | } 34 | message X509Certificates { 35 | repeated bytes certificate = 1; // DER-encoded X.509 certificate chain 36 | } 37 | message Payment { 38 | optional bytes merchant_data = 1; // From PaymentDetails.merchant_data 39 | repeated bytes transactions = 2; // Signed transactions that satisfy PaymentDetails.outputs 40 | repeated Output refund_to = 3; // Where to send refunds, if a refund is necessary 41 | optional string memo = 4; // Human-readable message for the merchant 42 | } 43 | message PaymentACK { 44 | required Payment payment = 1; // Payment message that triggered this ACK 45 | optional string memo = 2; // human-readable message for customer 46 | } 47 | -------------------------------------------------------------------------------- /bip-0071.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 71
 3 |   Layer: Applications
 4 |   Title: Payment Protocol MIME types
 5 |   Author: Gavin Andresen 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0071
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2013-07-29
11 |
12 | 13 | ==Abstract== 14 | 15 | This BIP defines a MIME (RFC 2046) Media Type for Bitcoin payment 16 | request messages. 17 | 18 | ==Motivation== 19 | 20 | Wallet or server software that sends payment protocol messages over 21 | email or http should follow Internet standards for properly 22 | encapsulating the messages. 23 | 24 | ==Specification== 25 | 26 | The Media Type (Content-Type in HTML/email headers) for bitcoin 27 | protocol messages shall be: 28 | 29 | {| 30 | | Message || Type/Subtype 31 | |- 32 | | PaymentRequest || application/bitcoin-paymentrequest 33 | |- 34 | | Payment || application/bitcoin-payment 35 | |- 36 | | PaymentACK || application/bitcoin-paymentack 37 | |} 38 | 39 | Payment protocol messages are encoded in binary. 40 | 41 | ==Example== 42 | 43 | A web server generating a PaymentRequest message to initiate the 44 | payment protocol would precede the binary message data with the 45 | following headers: 46 | 
47 | Content-Type: application/bitcoin-paymentrequest
48 | Content-Transfer-Encoding: binary
49 |
50 | -------------------------------------------------------------------------------- /bip-0072.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 72
 3 |   Layer: Applications
 4 |   Title: bitcoin: uri extensions for Payment Protocol
 5 |   Author: Gavin Andresen 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0072
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2013-07-29
11 |
12 | 13 | ==Abstract== 14 | 15 | This BIP describes an extension to the bitcoin: URI scheme (BIP 21) to 16 | support the payment protocol (BIP 70). 17 | 18 | ==Motivation== 19 | 20 | Allow users to click on a link in a web page or email to initiate the 21 | payment protocol, while being backwards-compatible with existing 22 | bitcoin wallets. 23 | 24 | ==Specification== 25 | 26 | The bitcoin: URI scheme is extended with an additional, optional 27 | "r" parameter, whose value is a URL from which a PaymentRequest 28 | message should be fetched (characters not allowed within the scope 29 | of a query parameter must be percent-encoded as described in RFC 3986 30 | and bip-0021). 31 | 32 | If the "r" parameter is provided and backwards compatibility 33 | is not required, then the bitcoin address portion of the URI may be 34 | omitted (the URI will be of the form: bitcoin:?r=... ). 35 | 36 | When Bitcoin wallet software that supports this BIP receives a 37 | bitcoin: URI with a request parameter, it should ignore the bitcoin 38 | address/amount/label/message in the URI and instead fetch a 39 | PaymentRequest message and then follow the payment protocol, as 40 | described in BIP 70. 41 | 42 | Bitcoin wallets must support fetching PaymentRequests via http and 43 | https protocols; they may support other protocols. Wallets must 44 | include an "Accept" HTTP header in HTTP(s) requests (as defined 45 | in RFC 2616): 46 | 47 | 
Accept: application/bitcoin-paymentrequest
48 | 49 | If a PaymentRequest cannot be obtained (perhaps the server is 50 | unavailable), then the customer should be informed that the merchant's 51 | payment processing system is unavailable. In the case of an HTTP 52 | request, status codes which are neither success nor error (such as 53 | redirect) should be handled as outlined in RFC 2616. 54 | 55 | ==Compatibility== 56 | 57 | Wallet software that does not support this BIP will simply ignore the 58 | r parameter and will initiate a payment to bitcoin address. 59 | 60 | ==Examples== 61 | A backwards-compatible request: 62 | 
63 | bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
64 |
65 | Non-backwards-compatible equivalent: 66 | 
67 | bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
68 |
69 | 70 | ==References== 71 | 72 | [[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1 73 | -------------------------------------------------------------------------------- /bip-0073.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 73
 3 |   Layer: Applications
 4 |   Title: Use "Accept" header for response type negotiation with Payment Request URLs
 5 |   Author: Stephen Pair 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0073
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2013-08-27
11 |
12 | 13 | ==Abstract== 14 | 15 | This BIP describes an enhancement to the payment protocol ([[bip-0070.mediawiki|BIP 70]]) 16 | that addresses the need for short URLs when scanning from QR codes. It 17 | generalizes the specification for the behavior of a payment request URL in a 18 | way that allows the client and server to negotiate the content of the 19 | response using the HTTP Accept: header field. Specifically, the client 20 | can indicate to the server whether it prefers to receive a bitcoin URI or 21 | a payment request. 22 | 23 | Implementation of this BIP does not require full payment request ([[bip-0070.mediawiki|BIP 70]]) support. 24 | 25 | ==Motivation== 26 | 27 | The payment protocol augments the bitcoin: uri scheme with an additional 28 | "payment" parameter that specifies a URL where a payment request can be 29 | downloaded. This creates long URIs that, when rendered as a QR code, have 30 | a high information density. Dense QR codes can be difficult to scan resulting 31 | in a more frustrating user experience. The goal is to create a standard that 32 | would allow QR scanning wallets to use less dense QR codes. It also makes 33 | general purpose QR code scanners more usable with bitcoin accepting 34 | websites. 35 | 36 | ==Specification== 37 | 38 | QR scanning wallets will consider a non bitcoin URI scanned from a QR code to 39 | be an end point where either a bitcoin URI or a payment request can be obtained. 40 | 41 | A wallet client uses the Accept: HTTP header to specify whether it can accept 42 | a payment request, a URI, or both. A media type of text/uri-list specifies that 43 | the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest 44 | specifies that the client can process a payment request. In the absence of an 45 | Accept: header, the server is expected to respond with text/html suitable for 46 | rendering in a browser. An HTML response will ensure that QR codes scanned 47 | by non Bitcoin wallet QR scanners are useful (they could render an HTML page 48 | with a payment link that when clicked would open a wallet on the device). 49 | 50 | It is not required that the client and server support the full semantics of an 51 | HTTP Accept header. If application/bitcoin-paymentrequest is specified in the 52 | header, the server should send a payment request regardless of anything else 53 | specified in the Accept header. If text/uri-list is specified (but not 54 | application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If 55 | neither is specified, the server can return an HTML page. When a uri-list is returned 56 | only the first item in the list is used (and expected to be a bitcoin URI), any additional 57 | URIs should be ignored. 58 | 59 | ==Compatibility== 60 | 61 | Only QR scanning wallets that implement this BIP will be able to process QR 62 | codes containing payment request URLs. There are two possible workarounds for QR 63 | scanning wallets that do not implement this BIP: 1) the server gives the user an 64 | option to change the QR code to a bitcoin: URI or 2) the user scans the code with 65 | a generic QR code scanner. 66 | 67 | In the second scenario, if the server responds with a webpage containing a link 68 | to a bitcoin URI, the user can complete the payment by clicking that link provided 69 | the user has a wallet installed on their device and it supports bitcoin URIs. If the 70 | wallet/device does not have support for bitcoin URIs, the user can fall back on 71 | address copy/paste. 72 | 73 | This BIP should be fully compatible with BIP 70 assuming it is required that wallets 74 | implementing BIP 70 make use of the Accept: HTTP header when retrieving a 75 | payment request. 76 | 77 | ==Examples== 78 | The first image below is of a bitcoin URI with an amount and payment request 79 | specified (note, this is a fairly minimal URI as it does not contain a 80 | label and the request URL is of moderate size). The second image is a QR 81 | code with only the payment request url specified. 82 | 83 | 84 | -------------------------------------------------------------------------------- /bip-0073/a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0073/a.png -------------------------------------------------------------------------------- /bip-0073/b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0073/b.png -------------------------------------------------------------------------------- /bip-0075/bip70-extension.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0075/bip70-extension.png -------------------------------------------------------------------------------- /bip-0075/encrypted-invoice-request-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0075/encrypted-invoice-request-process.png -------------------------------------------------------------------------------- /bip-0075/invoice-request-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0075/invoice-request-process.png -------------------------------------------------------------------------------- /bip-0075/mobile-sf-encrypted-ir-without-payment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0075/mobile-sf-encrypted-ir-without-payment.png -------------------------------------------------------------------------------- /bip-0075/mobile-sf-ir-with-payment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0075/mobile-sf-ir-with-payment.png -------------------------------------------------------------------------------- /bip-0075/mobile-sf-ir-without-payment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0075/mobile-sf-ir-without-payment.png -------------------------------------------------------------------------------- /bip-0080.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 80
 3 |   Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
 4 |   Author: Justus Ranvier 
 5 |           Jimmy Song 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0080
 8 |   Status: Deferred
 9 |   Type: Informational
10 |   Created: 2014-08-11
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP defines a logical hierarchy for non-colored voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). 17 | 18 | This BIP is a particular application of BIP43 and is based on BIP44. 19 | 20 | ==Motivation== 21 | 22 | The hierarchy proposed in this paper allows the handling of multiple coins and multiple series from a single seed. 23 | 24 | ==Path levels== 25 | 26 | We define the following 4 levels in BIP32 path: 27 | 28 | 
29 | m / purpose' / coin_type' / series' / address_index
30 |
31 | 32 | Apostrophe in the path indicates that BIP32 hardened derivation is used. 33 | 34 | Each level has a special meaning, described in the chapters below. 35 | 36 | ===Purpose=== 37 | 38 | Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "80" with the most significant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification. 39 | 40 | Hardened derivation is used at this level. 41 | 42 | ===Coin type=== 43 | 44 | One master node (seed) can be used for unlimited number of independent cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same space for various cryptocoins has some disadvantages. 45 | 46 | This level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues. 47 | 48 | Coin type is a constant, set for each cryptocoin. The list of registered coin type constants should be obtained from BIP44. 49 | 50 | Hardened derivation is used at this level. 51 | 52 | ===Series=== 53 | 54 | Series are used by voting pools in order to implement FIFO cold storage. By directing deposits into multiple series, the private keys for most of the deposits can be kept offline, and a limited portion can be brought online to process withdrawals. 55 | 56 | Hardened derivation is used at this level. 57 | 58 | ===Index=== 59 | 60 | Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. 61 | 62 | Public keys obtained at this level of the hierarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. 63 | 64 | Public derivation is used at this level. 65 | 66 | ==Compatible wallets== 67 | 68 | * [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools. 69 | 70 | ==Copyright== 71 | 72 | This document is placed in the public domain. 73 | 74 | ==Reference== 75 | 76 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 77 | * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] 78 | * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] 79 | -------------------------------------------------------------------------------- /bip-0081.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 81
 3 |   Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
 4 |   Author: Justus Ranvier 
 5 |           Jimmy Song 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0081
 8 |   Status: Deferred
 9 |   Type: Informational
10 |   Created: 2014-08-11
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). 17 | 18 | This BIP is a particular application of BIP43 and is based on BIP44. 19 | 20 | ==Motivation== 21 | 22 | The hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed. 23 | 24 | ==Path levels== 25 | 26 | We define the following 8 levels in BIP32 path: 27 | 28 | 
29 | m / purpose' / series' / (5 color definition levels) / address_index
30 |
31 | 32 | Apostrophe in the path indicates that BIP32 hardened derivation is used. 33 | 34 | Each level has a special meaning, described in the chapters below. 35 | 36 | ===Purpose=== 37 | 38 | Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "81" with the most significant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification. 39 | 40 | Hardened derivation is used at this level. 41 | 42 | ===Color Definition=== 43 | 44 | Index values which can be applied to a BIP32 node are limited to 4 bytes (32 bits). 45 | 46 | Since this is not sufficient to identify color definitions without a risk of collision, multiple levels are used. 47 | 48 | Color definitions are first shortened to 20 bytes using the Bitcoin hash160 function. 49 | 50 | The resulting 20 bytes are split into five groups in little endian format, and where each group is used as the seed for the five levels of color definition levels 51 | 52 | Public derivation is used at these levels, even when the index exceeds 2^31. 53 | 54 | ===Index=== 55 | 56 | Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. 57 | 58 | Public keys obtained at this level of the hierarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. 59 | 60 | Public derivation is used at this level. 61 | 62 | ==Compatible wallets== 63 | 64 | * [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools. 65 | 66 | ==Copyright== 67 | 68 | This document is placed in the public domain. 69 | 70 | ==Reference== 71 | 72 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 73 | * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] 74 | * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] 75 | * [[bip-0080.mediawiki|BIP80 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]] 76 | -------------------------------------------------------------------------------- /bip-0084.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 84
  3 |   Layer: Applications
  4 |   Title: Derivation scheme for P2WPKH based accounts
  5 |   Author: Pavol Rusnak 
  6 |   Comments-Summary: No comments yet.
  7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0084
  8 |   Status: Final
  9 |   Type: Standards Track
 10 |   Created: 2017-12-28
 11 |   License: CC0-1.0
 12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP defines the derivation scheme for HD wallets using the P2WPKH ([[bip-0173.mediawiki|BIP 173]]) serialization format for segregated witness transactions. 17 | 18 | ==Motivation== 19 | 20 | With the usage of P2WPKH transactions it is necessary to have a common derivation scheme. 21 | It allows the user to use different HD wallets with the same masterseed and/or a single account seamlessly. 22 | 23 | Thus the user needs to create dedicated segregated witness accounts, which ensures that only wallets compatible with this BIP will detect the accounts and handle them appropriately. 24 | 25 | ===Considerations=== 26 | 27 | We use the same rationale as described in Considerations section of [[bip-0049.mediawiki|BIP 49]]. 28 | 29 | ==Specifications== 30 | 31 | This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] root account. 32 | 33 | ===Public key derivation=== 34 | 35 | To derive a public key from the root account, this BIP uses the same account-structure as defined in [[bip-0044.mediawiki|BIP 44]] and [[bip-0049.mediawiki|BIP 49]], but only uses a different purpose value to indicate the different transaction serialization method. 36 | 37 | 
 38 | m / purpose' / coin_type' / account' / change / address_index
 39 |
40 | 41 | For the purpose-path level it uses 84'. The rest of the levels are used as defined in BIP44 or BIP49. 42 | 43 | 44 | ===Address derivation=== 45 | 46 | To derive the P2WPKH address from the above calculated public key, we use the encapsulation defined in [[bip-0141.mediawiki#p2wpkh|BIP 141]]: 47 | 48 | 49 | witness: 50 | scriptSig: (empty) 51 | scriptPubKey: 0 <20-byte-key-hash> 52 | (0x0014{20-byte-key-hash}) 53 | 54 | 55 | ===Extended Key Version=== 56 | 57 | When serializing extended keys, this scheme uses alternate version bytes. Extended public keys use 0x04b24746 to produce a "zpub" prefix, and private keys use 0x04b2430c to produce a "zprv" prefix. Testnet uses 0x045f1cf6 "vpub" and 0x045f18bc "vprv." 58 | 59 | Additional registered version bytes are listed in [[https://github.com/satoshilabs/slips/blob/master/slip-0132.md|SLIP-0132]]. 60 | 61 | 62 | ==Backwards Compatibility== 63 | 64 | This BIP is not backwards compatible by design as described under [[#considerations|considerations]]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong. 65 | 66 | ==Test vectors== 67 | 68 | 
 69 |   mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
 70 |   rootpriv = zprvAWgYBBk7JR8Gjrh4UJQ2uJdG1r3WNRRfURiABBE3RvMXYSrRJL62XuezvGdPvG6GFBZduosCc1YP5wixPox7zhZLfiUm8aunE96BBa4Kei5
 71 |   rootpub  = zpub6jftahH18ngZxLmXaKw3GSZzZsszmt9WqedkyZdezFtWRFBZqsQH5hyUmb4pCEeZGmVfQuP5bedXTB8is6fTv19U1GQRyQUKQGUTzyHACMF
 72 | 
 73 |   // Account 0, root = m/84'/0'/0'
 74 |   xpriv = zprvAdG4iTXWBoARxkkzNpNh8r6Qag3irQB8PzEMkAFeTRXxHpbF9z4QgEvBRmfvqWvGp42t42nvgGpNgYSJA9iefm1yYNZKEm7z6qUWCroSQnE
 75 |   xpub  = zpub6rFR7y4Q2AijBEqTUquhVz398htDFrtymD9xYYfG1m4wAcvPhXNfE3EfH1r1ADqtfSdVCToUG868RvUUkgDKf31mGDtKsAYz2oz2AGutZYs
 76 | 
 77 |   // Account 0, first receiving address = m/84'/0'/0'/0/0
 78 |   privkey = KyZpNDKnfs94vbrwhJneDi77V6jF64PWPF8x5cdJb8ifgg2DUc9d
 79 |   pubkey  = 0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c
 80 |   address = bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu
 81 | 
 82 |   // Account 0, second receiving address = m/84'/0'/0'/0/1
 83 |   privkey = Kxpf5b8p3qX56DKEe5NqWbNUP9MnqoRFzZwHRtsFqhzuvUJsYZCy
 84 |   pubkey  = 03e775fd51f0dfb8cd865d9ff1cca2a158cf651fe997fdc9fee9c1d3b5e995ea77
 85 |   address = bc1qnjg0jd8228aq7egyzacy8cys3knf9xvrerkf9g
 86 | 
 87 |   // Account 0, first change address = m/84'/0'/0'/1/0
 88 |   privkey = KxuoxufJL5csa1Wieb2kp29VNdn92Us8CoaUG3aGtPtcF3AzeXvF
 89 |   pubkey  = 03025324888e429ab8e3dbaf1f7802648b9cd01e9b418485c5fa4c1b9b5700e1a6
 90 |   address = bc1q8c6fshw2dlwun7ekn9qwf37cu2rn755upcp6el
 91 |
92 | 93 | ==Reference== 94 | 95 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 96 | * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] 97 | * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] 98 | * [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]] 99 | * [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]] 100 | * [[bip-0173.mediawiki|BIP173 - Base32 address format for native v0-16 witness outputs]] 101 | -------------------------------------------------------------------------------- /bip-0098/build.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | dot -Tpng -o node-variants.png node-variants.dot 4 | dot -Tpng -o skip-skip.png skip-skip.dot 5 | dot -Tpng -o traversal-example.png traversal-example.dot 6 | dot -Tpng -o unbalanced-hash-tree.png unbalanced-hash-tree.dot 7 | -------------------------------------------------------------------------------- /bip-0098/node-variants.dot: -------------------------------------------------------------------------------- 1 | digraph G { 2 | row1 [shape=none, label=""] 3 | 4 | A [label="000"] 5 | A -> Al [label="L"] 6 | Al [label="VERIFY"] 7 | A -> Ar [label="R"] 8 | Ar [label="SKIP"] 9 | 10 | B [label="001"] 11 | B -> Bl [label="L"] 12 | Bl [label="VERIFY"] 13 | B -> Br [label="R"] 14 | Br [label="VERIFY"] 15 | 16 | { rank = same; row1; A; B; } 17 | 18 | C [label="010"] 19 | C -> Cl [label="L"] 20 | Cl [label="VERIFY"] 21 | C -> Cr [label="R"] 22 | Cr [label="DESCEND"] 23 | Cr -> Crl 24 | Crl [label="..."] 25 | Cr -> Crr 26 | Crr [label="..."] 27 | 28 | D [label="011"] 29 | D -> Dl [label="L"] 30 | Dl [label="DESCEND"] 31 | Dl -> Dll 32 | Dll [label="..."] 33 | Dl -> Dlr 34 | Dlr [label="..."] 35 | D -> Dr [label="R"] 36 | Dr [label="SKIP"] 37 | 38 | E [label="100"] 39 | E -> El [label="L"] 40 | El [label="DESCEND"] 41 | El -> Ell 42 | Ell [label="..."] 43 | El -> Elr 44 | Elr [label="..."] 45 | E -> Er [label="R"] 46 | Er [label="VERIFY"] 47 | 48 | row1 -> invis [style=invis] 49 | invis [shape=none, label=""] 50 | invis -> C [style=invis] 51 | { rank = same; C; D; E; } 52 | 53 | F [label="101"] 54 | F -> Fl [label="L"] 55 | Fl [label="DESCEND"] 56 | Fl -> Fll 57 | Fll [label="..."] 58 | Fl -> Flr 59 | Flr [label="..."] 60 | F -> Fr [label="R"] 61 | Fr [label="DESCEND"] 62 | Fr -> Frl 63 | Frl [label="..."] 64 | Fr -> Frr 65 | Frr [label="..."] 66 | 67 | G [label="110"] 68 | G -> Gl [label="L"] 69 | Gl [label="SKIP"] 70 | G -> Gr [label="R"] 71 | Gr [label="VERIFY"] 72 | 73 | H [label="111"] 74 | H -> Hl [label="L"] 75 | Hl [label="SKIP"] 76 | H -> Hr [label="R"] 77 | Hr [label="DESCEND"] 78 | Hr -> Hrl 79 | Hrl [label="..."] 80 | Hr -> Hrr 81 | Hrr [label="..."] 82 | 83 | Crl -> F [style=invis] 84 | { rank = same; F; G; H; } 85 | } 86 | -------------------------------------------------------------------------------- /bip-0098/node-variants.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0098/node-variants.png -------------------------------------------------------------------------------- /bip-0098/skip-skip.dot: -------------------------------------------------------------------------------- 1 | digraph G { 2 | A [label="???"] 3 | A -> Al [label="L"] 4 | Al [label="SKIP"] 5 | A -> Ar [label="R"] 6 | Ar [label="SKIP"] 7 | } -------------------------------------------------------------------------------- /bip-0098/skip-skip.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0098/skip-skip.png -------------------------------------------------------------------------------- /bip-0098/traversal-example.dot: -------------------------------------------------------------------------------- 1 | digraph G { 2 | a [label="A\n101"] 3 | a -> b 4 | a -> c 5 | 6 | b [label="B\n111"] 7 | b -> s0 8 | s0 [label="SKIP\n0x00..."] 9 | b -> d 10 | 11 | d [label="D\n011"] 12 | d -> f 13 | d -> s1 14 | s1 [label="SKIP\n0x22..."] 15 | 16 | f [label="F\n000"] 17 | f -> v1 18 | v1 [label="VERIFY\n0x55..."] 19 | f -> s2 20 | s2 [label="SKIP\n0x66..."] 21 | 22 | c [label="C\n010"] 23 | c -> v2 24 | v2 [label="VERIFY\n0x11..."] 25 | c -> e 26 | 27 | e [label="E\n001"] 28 | e -> v3 29 | v3 [label="VERIFY\n0x33..."] 30 | e -> v4 31 | v4 [label="VERIFY\n0x44..."] 32 | } 33 | -------------------------------------------------------------------------------- /bip-0098/traversal-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0098/traversal-example.png -------------------------------------------------------------------------------- /bip-0098/unbalanced-hash-tree.dot: -------------------------------------------------------------------------------- 1 | digraph G { 2 | 0 [label="Root\nH(A || H(B || C))"] 3 | 0 -> A 4 | A [label="A\nskip"] 5 | 0 -> 1 6 | 1 [label="Node\nH(B || C)"] 7 | 1 -> B 8 | B [label="B\nskip"] 9 | 1 -> C 10 | C [label="C\nverify"] 11 | } 12 | -------------------------------------------------------------------------------- /bip-0098/unbalanced-hash-tree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0098/unbalanced-hash-tree.png -------------------------------------------------------------------------------- /bip-0102.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 102
 3 |   Layer: Consensus (hard fork)
 4 |   Title: Block size increase to 2MB
 5 |   Author: Jeff Garzik 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0102
 8 |   Status: Rejected
 9 |   Type: Standards Track
10 |   Created: 2015-06-23
11 |
12 | 13 | ==Abstract== 14 | 15 | Simple, one-time increase in total amount of transaction data permitted in a block from 1MB to 2MB. 16 | 17 | ==Motivation== 18 | 19 | # Continue current economic policy. 20 | # Exercise hard fork network upgrade. 21 | 22 | ==Specification== 23 | 24 | # MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point. 25 | # Increase maximum block sigops by similar factor, preserving SIZE/50 formula. 26 | # Trigger: (1) Block time 00:00:00 on flag day, AND (2) 95% of the last 1,000 blocks have signaled support. 27 | 28 | ==Backward compatibility== 29 | 30 | Fully validating older clients are not compatible with this change. 31 | The first block exceeding 1,000,000 bytes will partition older clients 32 | off the new network. 33 | 34 | ==Discussion== 35 | 36 | In the short term, an increase is needed to continue to current 37 | economic policies with regards to fees and block space, matching 38 | market expectations and preventing market disruption. 39 | 40 | In the long term, this limit should focus on reflecting the maximum 41 | network engineering limit. 42 | 43 | ==Implementation== 44 | 45 | https://github.com/jgarzik/bitcoin/tree/2015_2mb_blocksize 46 | 47 | -------------------------------------------------------------------------------- /bip-0104.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 104
 3 |   Layer: Consensus (hard fork)
 4 |   Title: 'Block75' - Max block size like difficulty
 5 |   Author: t.khan 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0104
 8 |   Status: Rejected
 9 |   Type: Standards Track
10 |   Created: 2017-01-13
11 |   License: BSD-2-Clause
12 |            GNU-All-Permissive
13 |
14 | 15 | ==Abstract== 16 | 17 | Automatic adjustment of max block size with the target of keeping blocks 75% full, based on the average block size of the previous 2016 blocks. This would be done on the same schedule as difficulty. 18 | 19 | ==Motivation== 20 | 21 | Blocks are already too full and cannot support further transaction growth. While SegWit and Lightning (and other off-chain solutions) will help, they will not solve this problem. 22 | 23 | Bitcoin needs a reasonably effective and predictable way of managing the maximum block size which allows moderate growth, keeps max block size as small as possible, and prevents wild swings in transaction fees. 24 | 25 | The every two-week and automatic adjustment of difficulty has proven to be a reasonably effective and predictable way of managing how quickly blocks are mined. It works well because humans aren’t involved (except for setting the original target of a 10 minute per block average), and therefore it isn’t political or contentious. It’s simply a response to changing network resources. 26 | 27 | It’s clear at this point that human beings should not be involved in the determination of max block size, just as they’re not involved in deciding the difficulty. Therefore, it is logical and consistent with Bitcoin’s design to implement a permanent solution which, as with the difficulty adjustment, is simply an automatic response to changing transaction volumes. With the target of keeping blocks 75% full on average, this is the goal of Block75. 28 | 29 | 30 | ==Specification== 31 | 32 | The max block size will be recalculated every 2016 blocks, along with difficulty, using Block75’s simple algorithm: 33 | 34 | 35 | new max block size = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY)) 36 | 37 | 38 | * TARGET_CAPACITY = 0.75    //Block75's target of keeping blocks 75% full 39 | * AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a decimal 40 | * x = current max block size 41 | 42 | 43 | All code which generates/validates blocks or uses/references the current hardcoded limits will need to be changed to support Block75. 44 | 45 | ==Rationale== 46 | 47 | The 75% full block target was selected because: 48 | * it is the middle ground between blocks being too small (average 100% full) and blocks being unnecessarily large (average 50% full) 49 | * it can handle short-term spikes in transaction volume of up to 33% 50 | * it limits the growth of max block size to less than 25% over the previous period 51 | * it will maintain average transaction fees at a stable level similar to that of May/June 2016 52 | 53 | The 2016 block (~2 weeks) period was selected because: 54 | * it has been shown to be reasonably adaptive to changing network resources (re: difficulty) 55 | * the frequent and gradual adjustments that result will be relatively easy for miners and node operators to predict and adapt to, as any unforeseen consequences will be visible well in advance 56 | * it minimizes any effect a malicious party could have in an attempt to manipulate max block size 57 | 58 | The Block75 algorithm will adjust the max block size up and down in response to transaction volume, including changes brought on by SegWit and Lightning. This is important as it will keep average transaction fees stable, thereby allowing miners and businesses using Bitcoin more certainty regarding future income/expenses. 59 | 60 | ==Other solutions considered== 61 | A hardcoded increase to max block size (2MB, 8MB, etc.), rejected because: 62 | * only a temporary solution, whatever limit was chosen would inevitably become a problem again 63 | * would cause transaction fees to vary wildly over time 64 | 65 | Allow miners to vote for max block size, rejected because: 66 | * overly complex and political 67 | * human involvement makes this slow to respond to changing transaction volumes 68 | * focuses power over max block size to a relatively small group of people 69 | * unpredictable transaction fees caused by this would create uncertainty in the ecosystem 70 | 71 | ==Backward Compatibility== 72 | This BIP is not backward compatible (hard fork). Any code which fully validates blocks must be upgraded prior to activation, as failure to do so will result in rejection of blocks over the current 1MB limit. 73 | 74 | ==Activation== 75 | To help negate some of the risks associated with a hard fork and to prevent a single relatively small mining pool from preventing Block75's adoption, activation would occur at the next difficulty adjustment once 900 of the last 1,000 blocks mined signal support and a grace period of 4,032 blocks (~1 month) has elapsed. 76 | 77 | ==Copyright== 78 | This BIP is dual-licensed under the BSD 2-clause license and the GNU All-Permissive License. 79 | -------------------------------------------------------------------------------- /bip-0105.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 105
  3 |   Layer: Consensus (hard fork)
  4 |   Title: Consensus based block size retargeting algorithm
  5 |   Author: BtcDrak 
  6 |   Comments-Summary: No comments yet.
  7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0105
  8 |   Status: Rejected
  9 |   Type: Standards Track
 10 |   Created: 2015-08-21
 11 |   License: PD
 12 |
13 | 14 | ==Abstract== 15 | 16 | A method of altering the maximum allowed block size of the Bitcoin protocol 17 | using a consensus based approach. 18 | 19 | ==Motivation== 20 | 21 | There is a belief that Bitcoin cannot easily respond to raising the 22 | blocksize limit if popularity was to suddenly increase due to a mass adoption 23 | curve, because co-ordinating a hard fork takes considerable time, and being 24 | unable to respond in a timely manner would irreparably harm the credibility of 25 | bitcoin. 26 | 27 | Additionally, predetermined block size increases are problematic because they 28 | attempt to predict the future, and if too large could have unintended 29 | consequences like damaging the possibility for a fee market to develop 30 | as block subsidy decreases substantially over the next 9 years; introducing 31 | or exacerbating mining attack vectors; or somehow affect the network in unknown 32 | or unpredicted ways. Since fixed changes are hard to deploy, the damage could be 33 | extensive. 34 | 35 | Dynamic block size adjustments also suffer from the potential to be gamed by the 36 | larger hash power. 37 | 38 | Free voting as suggested by BIP100 allows miners to sell their votes out of band 39 | at no risk, and enable the sponsor the ability to manipulate the blocksize. 40 | It also provides a cost free method or the larger pools to vote in ways to 41 | manipulate the blocksize such to disadvantage or attack smaller pools. 42 | 43 | 44 | ==Rationale== 45 | 46 | By introducing a cost to increase the block size ensures the mining community 47 | will collude to increase it only when there is a clear necessity, and reduce it 48 | when it is unnecessary. Larger miners cannot force their wishes so easily 49 | because not only will they have to pay extra a difficulty target, then can be 50 | downvoted at no cost by the objecting hash power. 51 | 52 | Using difficulty as a penalty is better than a fixed cost in bitcoins because it 53 | is less predictable. 54 | 55 | In order to prevent miners having complete control over blocksize, an upper 56 | limit is required at protocol level. This feature ensures full nodes retain 57 | control over consensus, remembering full nodes are the mechanism to keep miners 58 | honest. 59 | 60 | 61 | ==Specification== 62 | 63 | The initial block size limit shall be 1MB. 64 | 65 | Each time a miner creates a block, they may vote to increase or decrease the 66 | blocksize by a maximum of 10% of the current block size limit. These votes will 67 | be used to recalculate the new block size limit every 2016 blocks. 68 | 69 | Votes are cast using the block's coinbase transaction scriptSig. 70 | 71 | As per BIP34, the coinbase transaction scriptSig starts with a push of the block 72 | height. The next push is a little-endian number representing the preferred block 73 | size in bytes. For example, 0x4c(OP_PUSHDATA1) 0x03(size of constant) 0x80 0x84 0x1e(2MB) 74 | or 0x4c(OP_PUSHDATA1) 0x04(size of constant) 0x80 0x96 0x98 0x00(10MB). 75 | 76 | If a miner votes for an increase, the block hash must meet a difficulty target 77 | which is proportionally larger than the standard difficulty target based on the 78 | percentage increase they voted for. 79 | 80 | Votes proposing decreasing the block size limit do not need to meet a higher 81 | difficulty target. 82 | 83 | Miners can vote for no change by voting for the current block size. 84 | 85 | For blocks to be valid the blockhash must meet the required difficulty target 86 | for the vote otherwise the block is invalid and will be rejected. 87 | 88 | Every 2016 blocks, the block size limit will be recalculated by the median of 89 | all votes in the last 2016 blocks. This will redefine the block size limit for 90 | the next 2016 blocks. 91 | 92 | Blocks that are larger than the calculated base block size limit are invalid and 93 | will be rejected. 94 | 95 | The base block size limit may not reduce below 1MB or increase above 8MB (the exact 96 | number for the upper limit requires further discussion). 97 | 98 | 99 | ==Acknowledgements== 100 | 101 | This proposal is based on ideas and concepts derived from the writings of 102 | Meni Rosenfeld and Gregory Maxwell. 103 | 104 | 105 | ==References== 106 | 107 | [[bip-0034.mediawiki|BIP34]] 108 | 109 | ==Copyright== 110 | 111 | This work is placed in the public domain. 112 | -------------------------------------------------------------------------------- /bip-0109.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 109
 3 |   Layer: Consensus (hard fork)
 4 |   Title: Two million byte size limit with sigop and sighash limits
 5 |   Author: Gavin Andresen 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0109
 8 |   Status: Rejected
 9 |   Type: Standards Track
10 |   Created: 2016-01-28
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | One-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing. 17 | 18 | ==Motivation== 19 | 20 | # Continue current economic policy. 21 | # Exercise hard fork network upgrade. 22 | # Mitigate potential CPU exhaustion attacks 23 | 24 | ==Specification== 25 | 26 | === MAX_BLOCK_SIZE increased to 2,000,000 bytes === 27 | 28 | The maximum number of bytes in a canonically serialized block shall be increased from 29 | 1,000,000 bytes to 2,000,000 bytes. 30 | 31 | === Switch to accurately-counted sigop limit of 20,000 per block === 32 | 33 | The existing MAX_SIGOPS limit of 20,000 signature operations per block shall be retained, 34 | but only ECDSA verifications actually performed to validate the block shall be counted. 35 | 36 | In particular: 37 | 38 | * The coinbase scriptSig is not counted 39 | * Signature operations in un-executed branches of a Script are not counted 40 | * OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisfied by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations. 41 | * Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit 42 | 43 | === Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block === 44 | 45 | The amount of data hashed to compute signature hashes is limited to 1,300,000,000 bytes per block. The same rules for counting are used as for counting signature operations. 46 | 47 | === Activation: 75% hashpower support trigger, followed by 28-day 'grace period' === 48 | 49 | Solo miners or mining pool operators express their support for this BIP by setting the fourth-highest-bit in the block's 32-bit version number (0x10000000 in hex). The first block with that bit set, a timestamp less than or equal to the expiration time, and with at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) with that bit set, shall define the beginning of a grace period. Blocks with timestamps greater than or equal to the triggering block's timestamp plus 28 days (60*60*24*28 seconds) shall be subject to the new limits. 50 | 51 | As always, miners are expected to use their best judgement for what is best for the entire Bitcoin ecosystem when making decisions about what consensus-level changes to support. 52 | 53 | === Expiration: 1-Jan-2018 === 54 | 55 | If this BIP is not triggered before 1-Jan-2018 00:00:00 GMT it should be considered withdrawn. 56 | 57 | Miners that support this BIP should set bit 0x10000000 in the block version until 1-Jan-2018. After that date, that bit can be safely re-used for future consensus rule upgrades. 58 | 59 | ==Backward compatibility== 60 | 61 | Fully validating older clients are not compatible with this change. 62 | The first block exceeding the old limits on block size or inaccurately counted signature operations will partition older clients off the new network. 63 | 64 | SPV (simple payment validation) wallets are compatible with this change. 65 | 66 | ==Rationale== 67 | 68 | In the short term, an increase is needed to handle increasing transaction volume. 69 | 70 | The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software. 71 | 72 | The choices of constants for the deployment scheme were motivated by prior experience with upgrades to the Bitcoin consensus rules: 73 | 74 | * 0x10000000 was chosen to be compatible with the BIP 9 proposal for parallel deployment of soft forks 75 | * 75% was chosen instead of 95% to minimize the opportunity for a single large mining pool or miner to be able to veto an increase, either because of ideological opposition or threat of violence or extortion. 76 | * A four-week grace period after the voting period was chosen as a balance between giving people sufficient time to upgrade and keeping people's attention on the urgent need to upgrade. 77 | 78 | ==Implementation== 79 | 80 | https://github.com/gavinandresen/bitcoin-git/tree/two_mb_bump 81 | 82 | See also http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork 83 | 84 | ==Copyright== 85 | 86 | This work is placed in the public domain. 87 | -------------------------------------------------------------------------------- /bip-0111.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 111
 3 |   Layer: Peer Services
 4 |   Title: NODE_BLOOM service bit
 5 |   Author: Matt Corallo 
 6 |           Peter Todd 
 7 |   Comments-Summary: No comments yet.
 8 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0111
 9 |   Status: Proposed
10 |   Type: Standards Track
11 |   Created: 2015-08-20
12 |   License: PD
13 |
14 | 15 | == Abstract == 16 | 17 | This BIP extends BIP 37, Connection Bloom filtering, by defining a 18 | service bit to allow peers to advertise that they support bloom filters 19 | explicitly. It also bumps the protocol version to allow peers to 20 | identify old nodes which allow bloom filtering of the connection despite 21 | lacking the new service bit. 22 | 23 | 24 | == Motivation == 25 | 26 | BIP 37 did not specify a service bit for the bloom filter service, thus 27 | implicitly assuming that all nodes that serve peers data support it. 28 | However, the connection filtering algorithm proposed in BIP 37, and 29 | implemented in several clients today, has been shown to provide little 30 | to no privacyhttp://eprint.iacr.org/2014/763, as well as being a large DoS risk on some nodes[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html] is one example where the issues were found, though others independently discovered issues as well. Sample DoS exploit code available at https://github.com/petertodd/bloom-io-attack.. 31 | Thus, allowing node operators to disable connection bloom filtering is a 32 | much-needed feature. 33 | 34 | 35 | == Specification == 36 | 37 | The following protocol bit is added: 38 | 39 | 
40 |     NODE_BLOOM = (1 << 2)
41 |
42 | 43 | Nodes which support bloom filters should set that protocol bit. 44 | Otherwise it should remain unset. In addition the protocol version is 45 | increased from 70002 to 70011 in the reference implementation. It is 46 | often the case that nodes which have a protocol version smaller than 47 | 70011, but larger than 70000 support bloom filtered connections without 48 | the NODE_BLOOM bit set, however clients which require bloom filtered 49 | connections should avoid making this assumption. 50 | 51 | NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise 52 | NODE_BLOOM but not NODE_NETWORK (though there is little reason to do 53 | so now, some proposals may make this more useful in the future) 54 | 55 | If a node does not support bloom filters but receives a "filterload", 56 | "filteradd", or "filterclear" message from a peer the node should 57 | disconnect that peer immediately. For backwards compatibility, in 58 | initial implementations, nodes may choose to only disconnect nodes which 59 | have the new protocol version set and attempt to send a filter command. 60 | 61 | While outside the scope of this BIP it is suggested that DNS seeds and 62 | other peer discovery mechanisms support the ability to specify the 63 | services required; current implementations simply check only that 64 | NODE_NETWORK is set. 65 | 66 | 67 | == Design rational == 68 | 69 | A service bit was chosen as applying a bloom filter is a service. 70 | 71 | The increase in protocol version is for backwards compatibility. In 72 | initial implementations, old nodes which are not yet aware of NODE_BLOOM 73 | and use a protocol version < 70011 may still send filter messages to a 74 | node without NODE_BLOOM. This feature may be removed after there are 75 | sufficient NODE_BLOOM nodes available and SPV clients have upgraded, 76 | allowing node operators to fully close the bloom-related DoS vectors. 77 | 78 | 79 | == Reference Implementation == 80 | 81 | https://github.com/bitcoin/bitcoin/pull/6579 82 | 83 | 84 | == Copyright == 85 | 86 | This document is placed in the public domain. 87 | 88 | 89 | == References == 90 | 91 | -------------------------------------------------------------------------------- /bip-0114/mastexample.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0114/mastexample.png -------------------------------------------------------------------------------- /bip-0119/fifty.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0119/fifty.png -------------------------------------------------------------------------------- /bip-0119/five.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0119/five.png -------------------------------------------------------------------------------- /bip-0119/pooledcoshv.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0119/pooledcoshv.png -------------------------------------------------------------------------------- /bip-0119/vaultanim.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0119/vaultanim.gif -------------------------------------------------------------------------------- /bip-0122/chainid.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0122/chainid.png -------------------------------------------------------------------------------- /bip-0130.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 130
 3 |   Layer: Peer Services
 4 |   Title: sendheaders message
 5 |   Author: Suhas Daftuar 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0130
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2015-05-08
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | Add a new message, "sendheaders", which indicates that a node prefers to receive new block announcements via a "headers" message rather than an "inv". 17 | 18 | ==Motivation== 19 | 20 | Since the introduction of "headers-first" downloading of blocks in 0.10, blocks will not be processed unless 21 | they are able to connect to a (valid) headers chain. Consequently, block relay generally works 22 | as follows: 23 | # A node (N) announces the new tip with an "inv" message, containing the block hash 24 | # A peer (P) responds to the "inv" with a "getheaders" message (to request headers up to the new tip) and a "getdata" message for the new tip itself 25 | # N responds with a "headers" message (with the header for the new block along with any preceding headers unknown to P) and a "block" message containing the new block 26 | 27 | However, in the case where a new block is being announced that builds on the tip, it would be generally more efficient if the node N just announced the block header for the new block, rather than just the block hash, and saved the peer from generating and transmitting the getheaders message (and the required block locator). 28 | 29 | In the case of a reorg, where 1 or more blocks are disconnected, nodes currently just send an "inv" for the new tip. Peers currently are able to request the new tip immediately, but wait until the headers for the intermediate blocks are delivered before requesting those blocks. By announcing headers from the last fork point leading up to the new tip in the block announcement, peers are able to request all the intermediate blocks immediately. 30 | 31 | ==Specification== 32 | 33 | # The sendheaders message is defined as an empty message where pchCommand == "sendheaders" 34 | # Upon receipt of a "sendheaders" message, the node will be permitted, but not required, to announce new blocks by sending the header of the new block (along with any other blocks that a node believes a peer might need in order for the block to connect). 35 | # Feature discovery is enabled by checking protocol version >= 70012 36 | 37 | ==Additional constraints== 38 | 39 | As support for sendheaders is optional, software that implements this may also optionally impose additional constraints, such as only honoring sendheaders messages shortly after a connection is established. 40 | 41 | ==Backward compatibility== 42 | 43 | Older clients remain fully compatible and interoperable after this change. 44 | 45 | ==Implementation== 46 | 47 | https://github.com/bitcoin/bitcoin/pull/6494 48 | 49 | ==Copyright== 50 | 51 | This document is placed in the public domain. 52 | -------------------------------------------------------------------------------- /bip-0133.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 133
 3 |   Layer: Peer Services
 4 |   Title: feefilter message
 5 |   Author: Alex Morcos 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0133
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2016-02-13
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | Add a new message, "feefilter", which serves to instruct peers not to send "inv"'s to the node for transactions with fees below the specified fee rate. 17 | 18 | ==Motivation== 19 | 20 | The concept of a limited mempool was introduced in Bitcoin Core 0.12 to provide protection against attacks or spam transactions of low fees that are not being mined. A reject filter was also introduced to help prevent repeated requests for the same transaction that might have been recently rejected for insufficient fee. These methods help keep resource utilization on a node from getting out of control. 21 | 22 | However, there are limitations to the effectiveness of these approaches. The reject filter is reset after every block which means transactions that are inv'ed over a longer time period will be rerequested and there is no method to prevent requesting the transaction the first time. Furthermore, inv data is sent at least once either to or from each peer for every transaction accepted to the mempool and there is no mechanism by which to know that an inv sent to a given peer would not result in a getdata request because it represents a transaction with too little fee. 23 | 24 | After receiving a feefilter message, a node can know before sending an inv that a given transaction's fee rate is below the minimum currently required by a given peer, and therefore the node can skip relaying an inv for that transaction to that peer. 25 | 26 | ==Specification== 27 | 28 | # The feefilter message is defined as a message containing an int64_t where pchCommand == "feefilter" 29 | # Upon receipt of a "feefilter" message, the node will be permitted, but not required, to filter transaction invs for transactions that fall below the feerate provided in the feefilter message interpreted as satoshis per kilobyte. 30 | # The fee filter is additive with a bloom filter for transactions so if an SPV client were to load a bloom filter and send a feefilter message, transactions would only be relayed if they passed both filters. 31 | # Inv's generated from a mempool message are also subject to a fee filter if it exists. 32 | # Feature discovery is enabled by checking protocol version >= 70013 33 | 34 | ==Considerations== 35 | The propagation efficiency of transactions across the network should not be adversely affected by this change. In general, transactions which are not accepted to a node's mempool are not relayed by this node and the functionality implemented with this message is meant only to filter those transactions. There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited. 36 | 37 | Feefilter messages are not sent to whitelisted peers if the "-whitelistforcerelay" option is set. In that case, transactions are intended to be relayed even if they are not accepted to the mempool. 38 | 39 | There are privacy concerns with deanonymizing a node by the fact that it is broadcasting identifying information about its mempool min fee. To help ameliorate this concern, the implementation quantizes the filter value broadcast with a small amount of randomness, in addition, the messages are broadcast to different peers at individually randomly distributed times. 40 | 41 | If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider disabling the fee filter to make sure it is exposed to all possible txid's. 42 | 43 | ==Backward compatibility== 44 | 45 | Older clients remain fully compatible and interoperable after this change. Also, clients implementing this BIP can choose to not send any feefilter messages. 46 | 47 | ==Implementation== 48 | 49 | https://github.com/bitcoin/bitcoin/pull/7542 50 | 51 | ==Copyright== 52 | This document is placed in the public domain. 53 | -------------------------------------------------------------------------------- /bip-0135/bip-0135-states-small.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0135/bip-0135-states-small.png -------------------------------------------------------------------------------- /bip-0135/bip-0135-states.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0135/bip-0135-states.png -------------------------------------------------------------------------------- /bip-0144/witnesstx.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0144/witnesstx.png -------------------------------------------------------------------------------- /bip-0147.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 147
 3 |   Layer: Consensus (soft fork)
 4 |   Title: Dealing with dummy stack element malleability
 5 |   Author: Johnson Lau 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0147
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2016-09-02
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. 17 | 18 | 19 | ==Motivation== 20 | 21 | Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay ([https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP152]). 22 | 23 | A design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY causes them to consume an extra stack element ("dummy element") after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script. This document specifies a new rule to fix this signature malleability. 24 | 25 | 26 | ==Specification== 27 | 28 | To fix the dummy element malleability, a new consensus rule ("NULLDUMMY") is deployed to require that the dummy element MUST be the empty byte array. Anything else makes the script evaluate to false immediately. The NULLDUMMY rule applies to OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY in pre-segregated scripts, and also pay-to-witness-script-hash scripts described in BIP141. 29 | 30 | 31 | ==Deployment== 32 | 33 | This BIP will be deployed by "version bits" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] using the same parameters for BIP141 and BIP143, with the name "segwit" and using bit 1. 34 | 35 | For Bitcoin mainnet, the BIP9 starttime is midnight 15 November 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout is midnight 15 November 2017 UTC (Epoch timestamp 1510704000). 36 | 37 | For Bitcoin testnet, the BIP9 starttime is midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout is midnight 1 May 2017 UTC (Epoch timestamp 1493596800). 38 | 39 | 40 | ==Compatibility== 41 | 42 | The reference client has produced compatible signatures from the beginning, and the NULLDUMMY rule has been enforced as relay policy by the reference client since v0.10.0. There has been no transactions violating the requirement being added to the chain since at least August 2015. 43 | 44 | For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by this requirement. Users MUST pay extra attention to this new rule when designing exotic scripts. 45 | 46 | 47 | ==Implementation== 48 | 49 | An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8636 50 | 51 | 52 | ==Acknowledgements== 53 | 54 | Peter Todd is the original author of NULLDUMMY. This document is extracted from the previous [https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62] proposal, which was composed by Pieter Wuille and had input from various people. 55 | 56 | 57 | ==Copyright== 58 | 59 | This document is placed in the public domain. 60 | -------------------------------------------------------------------------------- /bip-0148.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 148
 3 |   Layer: Consensus (soft fork)
 4 |   Title: Mandatory activation of segwit deployment
 5 |   Author: Shaolin Fry 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0148
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2017-03-12
11 |   License: BSD-3-Clause
12 |            CC0-1.0
13 |
14 | 15 | ==Abstract== 16 | 17 | This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit". 18 | 19 | ==Definitions== 20 | 21 | "existing segwit deployment" refer to the BIP9 "segwit" deployment using bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141, BIP143 and BIP147. 22 | 23 | ==Motivation== 24 | 25 | Segwit increases the blocksize, fixes transaction malleability, and makes scripting easier to upgrade as well as bringing many other [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits]. 26 | 27 | It is hoped that miners will respond to this BIP by activating segwit early, before this BIP takes effect. Otherwise this BIP will cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017. 28 | 29 | ==Specification== 30 | 31 | All times are specified according to median past time. 32 | 33 | This BIP will be active between midnight August 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not locked-in or activated before epoch time 1501545600. This BIP will cease to be active when segwit is locked-in. 34 | 35 | While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected. 36 | 37 | === Reference implementation === 38 | 39 | 
40 | // Check if Segregated Witness is Locked In
41 | bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const Consensus::Params& params)
42 | {
43 |     LOCK(cs_main);
44 |     return (VersionBitsState(pindexPrev, params, Consensus::DEPLOYMENT_SEGWIT, versionbitscache) == THRESHOLD_LOCKED_IN);
45 | }
46 | 
47 | // BIP148 mandatory segwit signalling.
48 | int64_t nMedianTimePast = pindex->GetMedianTimePast();
49 | if ( (nMedianTimePast >= 1501545600) &&  // Tue 01 Aug 2017 00:00:00 UTC
50 |      (nMedianTimePast <= 1510704000) &&  // Wed 15 Nov 2017 00:00:00 UTC
51 |      (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&  // Segwit is not locked in
52 |       !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )   // and is not active.
53 | {
54 |     bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS;
55 |     bool fSegbit = (pindex->nVersion & VersionBitsMask(chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT)) != 0;
56 |     if (!(fVersionBits && fSegbit)) {
57 |         return state.DoS(0, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
58 |     }
59 | }
60 |
61 | 62 | https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-segwit-flagday 63 | 64 | ==Backwards Compatibility== 65 | 66 | This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. 67 | 68 | ==Rationale== 69 | 70 | Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues 71 | 72 | By orphaning non-signalling blocks during the last month of the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment. 73 | 74 | ==References== 75 | 76 | *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html Mailing list discussion] 77 | *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation] 78 | *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]] 79 | *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] 80 | *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]] 81 | *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]] 82 | *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]] 83 | *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits] 84 | 85 | ==Copyright== 86 | 87 | This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. 88 | 89 | -------------------------------------------------------------------------------- /bip-0149.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 149
 3 |   Layer: Consensus (soft fork)
 4 |   Title: Segregated Witness (second deployment)
 5 |   Author: Shaolin Fry 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0149
 8 |   Status: Withdrawn
 9 |   Type: Standards Track
10 |   Created: 2017-04-14
11 |   License: BSD-3-Clause
12 |            CC0-1.0
13 |
14 | 15 | ==Abstract== 16 | 17 | This document specifies a user activated soft fork for [[bip-0141.mediawiki|BIP141]], [[bip-0143.mediawiki|BIP143]] and [[bip-0147.mediawiki|BIP147]] using versionbits with guaranteed lock-in. 18 | 19 | ==Motivation== 20 | 21 | Miners have been reluctant to signal the BIP9 segwit deployment despite a large portion of the Bitcoin ecosystem who want the soft fork activated. This BIP specifies a user activated soft fork (UASF) that deploys segwit again using versionbits with guaranteed lock-in on timeout if the BIP is not already locked-in or activated by the timeout. This ensures users have sufficient time to prepare and no longer require a miner supermajority, while still allowing for an earlier miner activated soft fork (MASF). 22 | 23 | ==Reference implementation== 24 | 25 | The reference implementation will refuse to run on Bitcoin mainnet before 7 November 2017, and can only be run on testnet and regtest until then. 26 | 27 | https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday 28 | 29 | ==Specification== 30 | 31 | This deployment will set service bit (1<<5) as NODE_UAWITNESS. 32 | 33 | ==Deployment== 34 | 35 | This BIP should only be deployed if BIP9-segwit fails to lock-in or activate before timeout on 15 November 2017. This BIP cannot be deployed before 15 November 2017. 36 | 37 | This BIP will be deployed by BIP8 with the name "segwit" and using bit 1. 38 | 39 | For Bitcoin mainnet, the BIP8 starttime will be midnight 16 November 2017 UTC (Epoch timestamp 1510790400) and BIP8 timeout will be 4 July 2018 UTC (Epoch timestamp 1530662400). 40 | 41 | For Bitcoin testnet, segwit is already activated so no deployment is specified. 42 | 43 | ==Backwards Compatibility== 44 | 45 | This deployment reuses the GBT deployment name "segwit" to maintain compatibility with existing mining software. 46 | 47 | This deployment is incompatible with the BIP9-segwit deployment and should not be run concurrently with it. 48 | 49 | ==Rationale== 50 | 51 | The '''starttime''' of this BIP is after the BIP9-segwit timeout to remove compatibility issues with old nodes. 52 | 53 | ==References== 54 | 55 | [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014234.html Mailing list discussion] 56 | 57 | [[bip-0008.mediawiki|BIP8]] 58 | 59 | [[bip-0009.mediawiki|BIP9]] 60 | 61 | [[bip-0141.mediawiki|BIP141]] 62 | 63 | [[bip-0143.mediawiki|BIP143]] 64 | 65 | [[bip-0147.mediawiki|BIP147]] 66 | 67 | ==Copyright== 68 | 69 | This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. 70 | -------------------------------------------------------------------------------- /bip-0152/protocol-flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0152/protocol-flow.png -------------------------------------------------------------------------------- /bip-0156/1-dandelion.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0156/1-dandelion.png -------------------------------------------------------------------------------- /bip-0156/2-attack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0156/2-attack.png -------------------------------------------------------------------------------- /bip-0156/3-attack-plot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0156/3-attack-plot.png -------------------------------------------------------------------------------- /bip-0156/4-dandelion-plot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0156/4-dandelion-plot.png -------------------------------------------------------------------------------- /bip-0156/bitcoin.conf: -------------------------------------------------------------------------------- 1 | regtest=1 # Run this node on its own independent test network 2 | debug=net # Enable network debug logs 3 | debug=mempool # Enable mempool debug logs 4 | debug=mempoolrej # Enable mempool rejection debug logs 5 | debug=dandelion # Enable dandelion debug logs 6 | logips=1 # Log IP addresses in debug output 7 | logtimemicros=1 # Log timestamps with microsecond precision 8 | printtoconsole=1 # Print debug logs to console instead of debug.log 9 | server=1 # Accept command line JSON-RPC commands 10 | rpcuser=xxx # Username for JSON-RPC connections 11 | rpcpassword=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 12 | rpcauth=xxx:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 13 | dns=0 # Do not allow DNS lookups for -addnode, -seednode, and -connect 14 | dnsseed=0 # Do not query for peer addresses via DNS lookup 15 | persistmempool=0 # Do not save mempool on shutdown to load on restart 16 | dandelion=1 # Enable Dandelion transactions 17 | -------------------------------------------------------------------------------- /bip-0156/dandelion-debug-logs-example.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0156/dandelion-debug-logs-example.pdf -------------------------------------------------------------------------------- /bip-0156/dandelion-reference-documentation.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0156/dandelion-reference-documentation.pdf -------------------------------------------------------------------------------- /bip-0158/go.mod: -------------------------------------------------------------------------------- 1 | module github.com/bitcoin/bips/bip-0158 2 | 3 | require ( 4 | github.com/btcsuite/btcd v0.0.0-20190115013929-ed77733ec07d 5 | github.com/btcsuite/btcutil v0.0.0-20190207003914-4c204d697803 6 | github.com/davecgh/go-spew v1.1.1 7 | ) 8 | -------------------------------------------------------------------------------- /bip-0159.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 159
 3 |   Layer: Peer Services
 4 |   Title: NODE_NETWORK_LIMITED service bit
 5 |   Author: Jonas Schnelli 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0159
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2017-05-11
11 |   License: BSD-2-Clause
12 |
13 | 14 | == Abstract == 15 | 16 | Define a service bit that allows pruned peers to signal their limited services. 17 | 18 | ==Motivation== 19 | 20 | Pruned peers can offer the same services as traditional peers, except that of serving all historical blocks. 21 | Bitcoin right now only offers the NODE_NETWORK service bit to indicate that a peer can serve 22 | all historical blocks. 23 | # Pruned peers can relay blocks, headers, transactions, and addresses, but they only guarantee serving a minimum number of historical blocks; thus, they should have a way to announce their service(s) 24 | # Peers no longer in initial block download should consider connecting some of their outbound connections to pruned peers, to allow other peers to bootstrap from non-pruned peers 25 | 26 | == Specification == 27 | 28 | === New service bit === 29 | 30 | This BIP proposes a new service bit 31 | 32 | {|class="wikitable" 33 | |- 34 | | NODE_NETWORK_LIMITED || bit 10 (0x400) || If signaled, the peer MUST be capable of serving at least the last 288 blocks (~2 days). 35 | |} 36 | 37 | Pruned/limited peers MUST NOT set a service bit that signals serving the complete block chain (e.g., NODE_NETWORK). Rationale: nodes that signal serving the complete block chain may also signal NODE_NETWORK_LIMITED. 38 | 39 | A safety buffer of 144 blocks to handle chain reorganizations SHOULD be taken into account when connecting to a peer signaling the NODE_NETWORK_LIMITED service bit. 40 | 41 | === Address relay === 42 | 43 | Full nodes following this BIP SHOULD relay address/services (addr message) from peers they would connect to (including peers signaling NODE_NETWORK_LIMITED). 44 | 45 | === Counter-measures for peer fingerprinting === 46 | 47 | Peers may have different prune depths (depending on their configuration, disk space, etc.), which can result in a fingerprinting weakness (finding the prune depth through getdata requests). 48 | 49 | Pruned nodes should therefore avoid leaking the prune depth and SHOULD NOT serve blocks deeper than the signaled NODE_NETWORK_LIMITED threshold of 288 blocks. 50 | 51 | === Risks === 52 | 53 | Pruned peers following this BIP may consume more outbound bandwidth. 54 | 55 | Light clients (and such) who are not checking the nServiceFlags (service bits) from a relayed addr-message may unwittingly connect to a pruned peer and ask for (filtered) blocks at a depth below the peer’s pruned depth. Light clients should therefore check the service bits and either (1) connect to peers signaling NODE_NETWORK_LIMITED that preferably do not also signal serving the full block chain, if they only require (filtered) blocks around the tip, or (2) connect to peers signaling serving the full block chain if they need data older than the latest 288 blocks. Light clients obtaining peer IPs through DNS seeds should use the DNS filtering option. 56 | 57 | == Compatibility == 58 | 59 | This proposal is backward compatible. 60 | 61 | == Reference implementation == 62 | 63 | * https://github.com/bitcoin/bitcoin/pull/11740 (signaling) 64 | * https://github.com/bitcoin/bitcoin/pull/10387 (connection and relay) 65 | 66 | == Copyright == 67 | 68 | This BIP is licensed under the 2-clause BSD license. 69 | -------------------------------------------------------------------------------- /bip-0174/build.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | pdflatex -output-format=pdf coinjoin-workflow.tex && \ 4 | inkscape --with-gui --export-text-to-path \ 5 | --export-plain-svg=coinjoin-workflow.svg coinjoin-workflow.pdf && \ 6 | pdflatex -output-format=pdf multisig-workflow.tex && \ 7 | inkscape --with-gui --export-text-to-path \ 8 | --export-plain-svg=multisig-workflow.svg multisig-workflow.pdf && \ 9 | echo '"success"' 10 | -------------------------------------------------------------------------------- /bip-0174/coinjoin-workflow.tex: -------------------------------------------------------------------------------- 1 | % using the PGF/TikZ package with pdflatex 2 | \documentclass{standalone} 3 | \usepackage[utf8]{inputenc} 4 | \usepackage[T1]{fontenc} 5 | %~ \usepackage[english]{babel} 6 | \usepackage[none]{hyphenat}% prevent hyphenation 7 | \usepackage{lmodern} 8 | \renewcommand*\familydefault{\sfdefault} 9 | \usepackage{tikz} 10 | \usetikzlibrary{shapes,arrows.meta} 11 | \tikzset{>=latex} 12 | \begin{document} 13 | % \sffamily{} 14 | \tikzstyle{block_center} = 15 | [rectangle, draw=black, thick, fill=white, 16 | text width=12em, text centered, 17 | minimum height=5em] 18 | \tikzstyle{block_rounded} = [rectangle, 19 | draw=black, thick, fill=white, 20 | text width=8em, text centered, 21 | minimum height=5em, 22 | rounded corners] 23 | \begin{tikzpicture}[auto] 24 | % outlining the flowchart on a grid 25 | \matrix[column sep=3ex,row sep=3ex]{ 26 | \node [block_center] (0alice1) 27 | {Alice creates a PSBT with only her inputs 28 | with UTXOs filled in.\\Sends it to Bob.}; 29 | & 30 | \node [block_center] (1bob1) 31 | {Bob adds his inputs and fills in his 32 | UTXOs.}; 33 | & 34 | \node [block_center] (2carol1) 35 | {Carol adds her inputs, fills in her 36 | UTXOs, adds signatures, and finalizes her inputs.}; 37 | \\ 38 | \node [block_rounded] (5alice2) 39 | {Alice extracts the network serialized 40 | transaction and broadcasts it.}; 41 | & 42 | \node [block_center] (4alice1) 43 | {Alice signs the transaction, adds her 44 | signatures, and finalizes her inputs.}; 45 | & 46 | \node [block_center] (3bob2) 47 | {Bob signs the transaction, adds his 48 | signatures, and finalizes his inputs.}; 49 | \\ 50 | };% end matrix 51 | % connecting nodes with paths 52 | \draw [ultra thick, draw=black, -{Stealth[length=8pt]}] 53 | (0alice1) edge (1bob1) 54 | (1bob1) edge (2carol1) 55 | (2carol1) edge (3bob2) 56 | (3bob2) edge (4alice1) 57 | (4alice1) edge (5alice2); 58 | \draw [thin, white, -{Stealth[color=black, fill=white, length=8pt]}] 59 | (0alice1) edge (1bob1) 60 | (1bob1) edge (2carol1) 61 | (2carol1) edge (3bob2) 62 | (3bob2) edge (4alice1) 63 | (4alice1) edge (5alice2); 64 | \end{tikzpicture} 65 | \end{document} 66 | -------------------------------------------------------------------------------- /bip-0174/multisig-workflow.tex: -------------------------------------------------------------------------------- 1 | % using the PGF/TikZ package with pdflatex 2 | \documentclass{standalone} 3 | \usepackage[utf8]{inputenc} 4 | \usepackage[T1]{fontenc} 5 | %~ \usepackage[english]{babel} 6 | \usepackage[none]{hyphenat}% prevent hyphenation 7 | \usepackage{lmodern} 8 | \renewcommand*\familydefault{\sfdefault} 9 | \usepackage{tikz} 10 | \usetikzlibrary{shapes,arrows.meta} 11 | \tikzset{>=latex} 12 | %\pgfdeclarelayer{bg} % declare background layer 13 | %\pgfsetlayers{bg,main} % set order of layers 14 | \newcommand{\h}{\hspace{1em}} 15 | \begin{document} 16 | % \sffamily{} 17 | \tikzstyle{block_center} = 18 | [rectangle, draw=black, thick, fill=white, 19 | text width=10.5em, text centered, 20 | minimum height=1em] 21 | \tikzstyle{block_rounded} = [rectangle, 22 | draw=black, thick, fill=white, 23 | text width=8em, text centered, 24 | minimum height=5em, 25 | rounded corners] 26 | \begin{tikzpicture}[auto] 27 | % outlining the flowchart on a grid 28 | \matrix[column sep=3ex,row sep=2.5ex]{ 29 | \h & 30 | \node [block_center] (R1) 31 | {Alice, Bob and Carol 32 | wish to spend from a 33 | 2-of-3 Multisig.}; 34 | & \h \\ 35 | \h & 36 | \node [block_center] (R2) 37 | {Alice uses a full node 38 | to create a PSBT with 39 | all input UTXOs filled in.}; 40 | & \h \\ 41 | \h & 42 | \node [block_center] (R3) 43 | {PSBT distributed.}; 44 | & \h \\ 45 | \node [block_center] (R4C1) 46 | {Alice signs the 47 | PSBT with her wallet.}; 48 | & 49 | \node [block_center] (R4C2) 50 | {Bob signs the PSBT 51 | with his SPV wallet.}; 52 | & 53 | \node [block_center] (R4C3) 54 | {Carol signs the PSBT 55 | with a completely 56 | offline signing machine.}; 57 | \\ 58 | %~ \h & \node (blind) & \h \\ 59 | \h & 60 | \node [block_center] (R5) 61 | {PSBTs are returned 62 | to Alice.}; 63 | & \h \\ 64 | \h & 65 | \node [block_center] (R6) 66 | {Alices combines the 67 | PSBTs. All inputs now 68 | have 3 signatures.}; 69 | & \h \\ 70 | \h & 71 | \node [block_center] (R7) 72 | {Alice finalizes the PSBT 73 | by creating each input's 74 | final scriptSig. One signature 75 | for each input is dropped.}; 76 | & \h \\ 77 | \h & 78 | \node [block_rounded] (stop) 79 | {Alice extracts the network 80 | serialized transaction and 81 | broadcasts it to the network.}; 82 | & \h \\ 83 | };% end matrix 84 | % connecting nodes with paths 85 | % \begin{pgfonlayer}{bg} 86 | \draw [ultra thick, draw=black, -{Stealth[length=8pt]}] 87 | (R1) edge (R2) 88 | (R2) edge (R3) 89 | (R3) -| (R4C1) 90 | (R3) edge (R4C2) 91 | (R5) edge (R6) 92 | (R6) edge (R7) 93 | (R7) edge (stop); 94 | \draw [thin, white, -{Stealth[color=black, fill=white, length=8pt]}] 95 | (R1) edge (R2) 96 | (R2) edge (R3) 97 | (R3) -| (R4C1) 98 | (R3) edge (R4C2) 99 | (R5) edge (R6) 100 | (R6) edge (R7) 101 | (R7) edge (stop); 102 | % circumvent missing arrow 103 | \draw [ultra thick, draw=black, -{Stealth[length=8pt]}] 104 | (R4C1) |-+(0,-2.2em)-| (R5) 105 | (R4C2) edge (R5) 106 | (R4C3) |-+(0,-2.2em)-| (R5) 107 | (R3) -| (R4C3); 108 | \draw [thin, white, -{Stealth[color=black, fill=white, length=8pt]}] 109 | (R4C1) |-+(0,-2.2em)-| (R5) 110 | (R4C2) edge (R5) 111 | (R4C3) |-+(0,-2.2em)-| (R5) 112 | (R3) -| (R4C3); 113 | % \end{pgfonlayer} 114 | \end{tikzpicture} 115 | \end{document} 116 | -------------------------------------------------------------------------------- /bip-0176.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 176
 3 |   Title: Bits Denomination
 4 |   Author: Jimmy Song 
 5 |   Comments-Summary: No comments yet.
 6 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0176
 7 |   Status: Draft
 8 |   Type: Informational
 9 |   Created: 2017-12-12
10 |   License: BSD-2-Clause
11 |
12 | 13 | == Abstract == 14 | Bits is presented here as the standard term for 100 (one hundred) satoshis or 1/1,000,000 (one one-millionth) of a bitcoin. 15 | 16 | == Motivation == 17 | The bitcoin price has grown over the years and once the price is past $10,000 USD or so, bitcoin amounts under $10 USD start having enough decimal places that it's difficult to tell whether the user is off by a factor of 10 or not. Switching the denomination to "bits" makes comprehension easier. For example, when BTC is $15,000 USD, $10.05 is a somewhat confusing 0.00067 BTC, versus 670 bits, which is a lot clearer. 18 | 19 | Additionally, reverse comparisons are easier as 59 bits being $1 is easier to comprehend for most people than 0.000059 BTC being $1. Similar comparisons can be made to other currencies: 1 yen being 0.8 bits, 1 won being 0.07 bits and so on. 20 | 21 | Potential benefits of utilizing "bits" include: 22 | 23 | # Reduce user error on small bitcoin amounts. 24 | # Reduce unit bias for users that want a "whole" bitcoin. 25 | # Allow easier comparisons of prices for most users. 26 | # Allow easier bi-directional comparisons to fiat currencies. 27 | # Allows all UTXO amounts to need at most 2 decimal places, which can be easier to handle. 28 | 29 | == Specification == 30 | Definition: 1 bit = 100 satoshis. 31 | Plural of "bit" is "bits." The terms "bit" and "bits" are not proper nouns and thus should not be capitalized unless used at the start of a sentence, etc. 32 | 33 | All bitcoin-denominated items are encouraged to also show the denomination in bits, either as the default or as an option. 34 | 35 | == Rationale == 36 | As bitcoin grows in price versus fiat currencies, it's important to give users the ability to quickly and accurately calculate prices for transactions, savings and other economic activities. "Bits" have been used as a denomination within the Bitcoin ecosystem for some time. The idea of this BIP is to formalize this name. Additionally, "bits" is likely the only other denomination that will be needed for Bitcoin as 0.01 bit = 1 satoshi, meaning that two decimal places will be sufficient to describe any current utxo. 37 | 38 | Existing terms used in bitcoin such as satoshi, milli-bitcoin (mBTC) and bitcoin (BTC) do not conflict as they operate at different orders of magnitude. 39 | 40 | The term micro-bitcoin (µBTC) can continue to exist in tandem with the term "bits." 41 | 42 | == Backwards Compatibility == 43 | Software such as the Bitcoin Core GUI currently use the µBTC denomination and can continue to do so. There is no obligation to switch to "bits." 44 | 45 | The term "bit" has many different definitions, but the ones of particular note are these: 46 | 47 | * 1 bit = 1/8 dollar (e.g., that candy cost me 2 bits {or 1/4 dollar}) 48 | * bit meaning some amount of data (e.g., the first bit of the version field is 0) 49 | * bit meaning strength of a cryptographic algorithm (e.g., 256-bit ECDSA is used in Bitcoin) 50 | 51 | The first is a bit dated and isn't likely to confuse people dealing with Bitcoin. The second and third are computer science terms and context should be sufficient to figure out what the user of the word means. 52 | 53 | == Copyright == 54 | This BIP is licensed under the BSD 2-clause license. 55 | 56 | == Credit == 57 | It's hard to ascertain exactly who invented the term "bits," but the term has been around for a while and the author of this BIP does not take any credit for inventing the term. 58 | -------------------------------------------------------------------------------- /bip-0178.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 178
 3 |   Layer: Applications
 4 |   Title: Version Extended WIF
 5 |   Author: Karl-Johan Alm 
 6 |   Comments-Summary: Discouraged for implementation (one person)
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0178
 8 |   Status: Draft
 9 |   Type: Standards Track
10 |   Created: 2018-04-04
11 |   License: CC0-1.0
12 |
13 | 14 | == Abstract == 15 | 16 | An extension to the Wallet Import Format (WIF) to specify what kind of bitcoin address the private key corresponds to. 17 | 18 | == Motivation == 19 | 20 | There are several types of bitcoin addresses which can all be associated with a given private key: P2PKH (legacy 1... format), P2SH-P2WPKH (SegWit public key inside P2SH), P2WPKH (bech32), etc. 21 | 22 | While private keys have a 1-byte suffix indicating whether the corresponding public key is compressed (0x01) or not (through suffix absence), there is no way of knowing what kind of bitcoin address were associated with the private key. As a result, when importing a private key, the wallet has to assume all kinds, and keep track of each possible alternative. 23 | 24 | By extending the suffix, we can specify what kind of bitcoin address was associated with a given private key. 25 | 26 | == Specification == 27 | 28 | Currently, private keys are stored as a uint256 (private key data) followed by an optional uint8 (compressed flag). The latter is extended to specify the address types: 29 | 30 | {|class="wikitable" style="text-align: center;" 31 | |- 32 | !Value 33 | !Type 34 | !Compr 35 | !Clarification 36 | |- 37 | |No suffix||P2PKH_UNCOMPRESSED||No||Uncompressed legacy public key. Unknown public key format 38 | |- 39 | |0x01||P2PKH_COMPRESSED||Yes||Compressed legacy public key. Unknown public key format 40 | |- 41 | |0x10||P2PKH||Yes||Compressed legacy public key. Legacy public key format (1...) 42 | |- 43 | |0x11||P2WPKH||Yes||Bech32 format (native Segwit) 44 | |- 45 | |0x12||P2WPKH_P2SH||Yes||Segwit nested in BIP16 P2SH (3...) 46 | |} 47 | 48 | When a wallet imports a private key, it will have two outcomes: 49 | 50 | * the key is using one of the legacy types, in which case all types must be accounted for 51 | * the key is using one of the extended types, in which case the wallet need only track the specific corresponding address 52 | 53 | Note: the difference between `0x01` and `0x10` is that the former can correspond to any of the types above, whereas the latter *only* corresponds to a P2PKH (legacy non-segwit). 54 | 55 | == Compatibility == 56 | 57 | This proposal is not backwards compatible, in that software that does not recognize the new types will not understand the compressed flag. It would be trivial to change this, by keeping the 'uncompressed' state as it is (no suffix) and changing 'compressed' to be 'anything not 0', as opposed to 'the value 1'. 58 | 59 | The proposal ''is'' backwards compatible in that new wallet software will always understand the old WIF format, however. It will, as it does today, assume that any kind of bitcoin address is possible, and will have to track all of them, as it has to today. 60 | 61 | == Acknowledgements == 62 | 63 | This BIP is based on the initial proposal by Thomas Voegtlin (thomasv at electrum dot org) on the Bitcoin Dev mailing listhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html and the Electrum 3.0 implementationhttps://github.com/spesmilo/electrum/blob/82e88cb89df35288b80dfdbe071da74247351251/RELEASE-NOTES#L95-L108 64 | 65 | == Reference implementation == 66 | 67 | There is a partial implementation which adds, but does not use, the types described in this BIP here: https://github.com/bitcoin/bitcoin/pull/12869 68 | 69 | == References == 70 | 71 | 72 | 73 | == Copyright == 74 | 75 | This document is licensed under the Creative Commons CC0 1.0 Universal license. 76 | -------------------------------------------------------------------------------- /bip-0179.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 179
 3 |   Title: Name for payment recipient identifiers
 4 |   Author: Emil Engler 
 5 |           Luke Dashjr 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0179
 8 |   Status: Draft
 9 |   Type: Informational
10 |   Created: 2019-10-17
11 |   License: CC0-1.0
12 |
13 | 14 | ==Abstract== 15 | This BIP proposes a new term for 'address' 16 | 17 | ==Specification== 18 | The new term is: 19 | ''Bitcoin'' '''Invoice''' ''Address'' 20 | 21 | The ''Bitcoin'' and ''Address'' parts are optional. 22 | The address suffix should only be used as a transitional step. 23 | 24 | A ''Bitcoin'' Invoice ''Address'' is a string of characters that can be used to indicate the intended recipient and purpose of a transaction. 25 | 26 | ==Motivation== 27 | Bitcoin addresses are intended to be only used '''once''' and you should generate a new one for every new incoming payment. 28 | The term 'address' however indicates consistency because nearly everything on the internet or the offline world with the term 'address' 29 | is something that rarely or even never changes (postal address, email address, IP addresses (depends heavily on the provider), etc.) 30 | The motivation for this BIP is to change the term address to something that indicates that the address is connected to a single transaction. 31 | 32 | ==Rationale== 33 | The reason why we use ''Bitcoin Invoice Address'' or just ''Invoice'' is to emphasize that it is single-use. 34 | The terms ''Bitcoin'' and ''Address'' are optional for the following reasons: 35 | For ''Bitcoin'': 36 | * Useful for multicoin wallets to indicate that it belongs to Bitcoin 37 | * Indicates a difference between a lightning and an on-chain invoice 38 | For ''Address'': 39 | * To not confuse users with a completely new term 40 | * To show that it is where you send something to 41 | * To not break backwards compatibility 42 | 43 | This gives us the four following possibilities: 44 | * Bitcoin Invoice Address 45 | * Bitcoin Invoice 46 | * Invoice Address 47 | * Invoice 48 | 49 | ==Backwards Compatibility== 50 | To avoid issues, the 'Address' suffix is permitted, but not recommended. 51 | The suffix 'Address' remains so users should be immediately able to recognize it until the new term is widely known. 52 | 53 | ==Acknowledgements== 54 | Thanks to Chris Belcher for the suggestion of the term 'Bitcoin Invoice Address' 55 | 56 | ==Copyright== 57 | This BIP is released under CC0-1.0 and therefore Public Domain. 58 | -------------------------------------------------------------------------------- /bip-0199.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 199
 3 |   Layer: Applications
 4 |   Title: Hashed Time-Locked Contract transactions
 5 |   Author: Sean Bowe 
 6 |           Daira Hopwood 
 7 |   Comments-Summary: No comments yet.
 8 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0199
 9 |   Status: Rejected
10 |   Type: Standards Track
11 |   Created: 2017-03-27
12 |   License: BSD-3-Clause
13 |            CC0-1.0
14 |
15 | 16 | ==Abstract== 17 | 18 | This BIP describes a script for generalized off-chain contract negotiation. 19 | 20 | ==Summary== 21 | 22 | A Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the "seller") to spend funds by disclosing the preimage of a hash. It also permits 23 | a second party (the "buyer") to spend the funds after a timeout is reached, in a refund situation. 24 | 25 | The script takes the following form: 26 | 27 | OP_IF 28 | [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 29 | OP_ELSE 30 | [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 31 | OP_ENDIF 32 | OP_EQUALVERIFY 33 | OP_CHECKSIG 34 | 35 | [HASHOP] is either OP_SHA256 or OP_HASH160. 36 | 37 | [TIMEOUTOP] is either OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY. 38 | 39 | ===Interaction=== 40 | 41 | * Victor (the "buyer") and Peggy (the "seller") exchange public keys and mutually agree upon a timeout threshold. Peggy provides a hash digest. Both parties can now construct the script and P2SH address for the HTLC. 42 | * Victor sends funds to the P2SH address. 43 | * Either: 44 | ** Peggy spends the funds, and in doing so, reveals the preimage to Victor in the transaction; OR 45 | ** Victor recovers the funds after the timeout threshold. 46 | 47 | Victor is interested in a lower timeout to reduce the amount of time that his funds are encumbered in the event that Peggy does not reveal the preimage. Peggy is 48 | interested in a higher timeout to reduce the risk that she is unable to spend the funds before the threshold, or worse, that her transaction spending the funds does 49 | not enter the blockchain before Victor's but does reveal the preimage to Victor anyway. 50 | 51 | ==Motivation== 52 | 53 | In many off-chain protocols, secret disclosure is used as part of a settlement mechanism. In some others, the secrets themselves are valuable. HTLC transactions are 54 | a safe and cheap method of exchanging secrets for money over the blockchain, due to the ability to recover funds from an uncooperative counterparty, and the 55 | opportunity that the possessor of a secret has to receive the funds before such a refund can occur. 56 | 57 | ===Lightning network=== 58 | 59 | In the lightning network, HTLC scripts are used to perform atomic swaps between payment channels. 60 | 61 | Alice constructs K and hashes it to produce L. She sends an HTLC payment to Bob for the preimage of L. Bob sends an HTLC payment to Carol for the same preimage and 62 | amount. Only when Alice releases the preimage K does any exchange of value occur, and because the secret is divulged for each hop, all parties are compensated. If 63 | at any point some parties become uncooperative, the process can be aborted via the refund conditions. 64 | 65 | ===Zero-knowledge contingent payments=== 66 | 67 | Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a 68 | zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See 69 | [https://github.com/zcash/pay-to-sudoku pay-to-sudoku] for a concrete example of such a protocol.) 70 | 71 | HTLC transactions can be used to exchange such decryption keys for money without risk, and they do not require large or expensive-to-validate transactions. 72 | 73 | ==Implementation== 74 | 75 | https://github.com/bitcoin/bitcoin/pull/7601 76 | 77 | ==Copyright== 78 | 79 | This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. 80 | 81 | -------------------------------------------------------------------------------- /bip-0300/images.txt: -------------------------------------------------------------------------------- 1 | Images used as reference in the documentation. 2 | -------------------------------------------------------------------------------- /bip-0300/m1-cli.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0300/m1-cli.png -------------------------------------------------------------------------------- /bip-0300/m1-gui.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0300/m1-gui.jpg -------------------------------------------------------------------------------- /bip-0320.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 320
 3 |   Title: nVersion bits for general purpose use
 4 |   Author: BtcDrak 
 5 |   Comments-Summary: No comments yet.
 6 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0320
 7 |   Status: Draft
 8 |   Type: Standards Track
 9 |   Created: 2018-03-01
10 |   License: BSD-3-Clause
11 |            CC0-1.0
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP reserves 16 bits of the block header nVersion field for general purpose use and removes their meaning for the purpose of version bits soft-fork signalling. 17 | 18 | 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. 19 | 20 | ==Motivation== 21 | 22 | There are a variety of things that miners may desire to use some of the nVersion field bits for. However, due to their use to coordinate miner activated soft-forks, full node software will generate false warnings about unknown soft forks if those bits are used for non soft fork signalling purposes. By reserving bits from the nVersion field for general use, node software can be updated to ignore those bits and therefore will not emit false warnings. Reserving 16 bits for general use leaves enough for 13 parallel soft-forks using version bits. 23 | 24 | ===Example Uses=== 25 | 26 | The following are example cases that would benefit from using some of the bits from the nVersion field. This list is not exhaustive. 27 | 28 | Bitcoin mining hardware currently can exhaust the 32 bit nonce field in less than 200ms requiring the controller to distribute new jobs very frequently to each mining chip consuming a lot of bandwidth and CPU time. This can be greatly reduced by rolling more bits. Rolling too many bits from nTime is not ideal because it may distort the timestamps over a longer period. 29 | 30 | Version-rolling AsicBoost requires two bits from the nVersion field to calculate 4-way collisions. Any two bits can be used and mining equipment can negotiate which bits are to be used with mining pools via the Stratum "version-rolling" extension. 31 | 32 | ==Specification== 33 | 34 | Sixteen bits from the block header nVersion field, starting from 13 and ending at 28 inclusive (0x1fffe000), are reserved for general use and removed from BIP8 and BIP9 specifications. A mask of 0xe0001fff should be applied to nVersion bits so bits 13-28 inclusive will be ignored for soft-fork signalling and unknown soft-fork warnings. 35 | 36 | This specification does not reserve specific bits for specific purposes. 37 | 38 | ==Reference Implementation== 39 | 40 | https://github.com/btcdrak/bitcoin/commit/d12516e136d4a8952904a13eedc9f4225f35dc3b 41 | 42 | ==Backwards Compatibility== 43 | 44 | Non-upgraded nodes will interpret the reserved bits of this proposal as signals for soft forks, and may additionally activate the warning system for unknown soft forks. 45 | 46 | This proposal does not require a soft fork to implement. 47 | 48 | At the time of writing no known soft forks are pending using any of 16 bits reserved in this BIP, and given that a non-trivial percentage of the hashrate is already making uses of those bits, future soft forks SHOULD NOT utilise those bits for activation signalling. 49 | 50 | ==Acknowledgements== 51 | 52 | Timo Hanke and Sergio Lerner for originally proposing 15-bit extra nNonce2. 53 | 54 | ==References== 55 | 56 | [[bip-0008.mediawiki|BIP8]] 57 | 58 | [[bip-0009.mediawiki|BIP9]] 59 | 60 | [https://arxiv.org/pdf/1604.00575.pdf AsicBoost white paper] 61 | 62 | [https://github.com/BlockheaderNonce2/bitcoin/wiki Blockheader Extra nNonce2 proposal] 63 | 64 | [https://github.com/slushpool/stratumprotocol/blob/master/stratum-extensions.mediawiki Stratum protocol extension BIP for version-rolling] 65 | 66 | ==Copyright== 67 | 68 | This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. 69 | -------------------------------------------------------------------------------- /bip-0324/garbage_terminator.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0324/garbage_terminator.png -------------------------------------------------------------------------------- /bip-0324/run_test_vectors.py: -------------------------------------------------------------------------------- 1 | """Run the BIP-324 test vectors.""" 2 | 3 | import csv 4 | import os 5 | import sys 6 | 7 | import reference 8 | 9 | FILENAME_PACKET_TEST = os.path.join(sys.path[0], 'packet_encoding_test_vectors.csv') 10 | FILENAME_XSWIFTEC_INV_TEST = os.path.join(sys.path[0], 'xswiftec_inv_test_vectors.csv') 11 | FILENAME_ELLSWIFT_DECODE_TEST = os.path.join(sys.path[0], 'ellswift_decode_test_vectors.csv') 12 | 13 | with open(FILENAME_PACKET_TEST, newline='', encoding='utf-8') as csvfile: 14 | print(f"Running {FILENAME_PACKET_TEST} tests...") 15 | reader = csv.DictReader(csvfile) 16 | for row in reader: 17 | in_initiating = int(row['in_initiating']) 18 | bytes_priv_ours = bytes.fromhex(row['in_priv_ours']) 19 | int_priv_ours = int.from_bytes(bytes_priv_ours, 'big') 20 | assert row['mid_x_ours'] == (int_priv_ours * reference.SECP256K1_G).x.to_bytes().hex() 21 | bytes_ellswift_ours = bytes.fromhex(row['in_ellswift_ours']) 22 | assert row['mid_x_ours'] == reference.ellswift_decode(bytes_ellswift_ours).hex() 23 | bytes_ellswift_theirs = bytes.fromhex(row['in_ellswift_theirs']) 24 | assert row['mid_x_theirs'] == reference.ellswift_decode(bytes_ellswift_theirs).hex() 25 | x_shared = reference.ellswift_ecdh_xonly(bytes_ellswift_theirs, bytes_priv_ours) 26 | assert row['mid_x_shared'] == x_shared.hex() 27 | shared_secret = reference.v2_ecdh(bytes_priv_ours, bytes_ellswift_theirs, 28 | bytes_ellswift_ours, in_initiating) 29 | assert row['mid_shared_secret'] == shared_secret.hex() 30 | 31 | peer = reference.initialize_v2_transport(shared_secret, in_initiating) 32 | assert row['mid_initiator_l'] == peer['initiator_L'].hex() 33 | assert row['mid_initiator_p'] == peer['initiator_P'].hex() 34 | assert row['mid_responder_l'] == peer['responder_L'].hex() 35 | assert row['mid_responder_p'] == peer['responder_P'].hex() 36 | assert row['mid_send_garbage_terminator'] == peer['send_garbage_terminator'].hex() 37 | assert row['mid_recv_garbage_terminator'] == peer['recv_garbage_terminator'].hex() 38 | assert row['out_session_id'] == peer['session_id'].hex() 39 | for _ in range(int(row['in_idx'])): 40 | reference.v2_enc_packet(peer, b"") 41 | ciphertext = reference.v2_enc_packet( 42 | peer, 43 | bytes.fromhex(row['in_contents']) * int(row['in_multiply']), 44 | bytes.fromhex(row['in_aad']), int(row['in_ignore'])) 45 | if len(row['out_ciphertext']): 46 | assert row['out_ciphertext'] == ciphertext.hex() 47 | if len(row['out_ciphertext_endswith']): 48 | assert ciphertext.hex().endswith(row['out_ciphertext_endswith']) 49 | 50 | with open(FILENAME_XSWIFTEC_INV_TEST, newline='', encoding='utf-8') as csvfile: 51 | print(f"Running {FILENAME_XSWIFTEC_INV_TEST} tests...") 52 | reader = csv.DictReader(csvfile) 53 | for row in reader: 54 | u = reference.FE.from_bytes(bytes.fromhex(row['u'])) 55 | x = reference.FE.from_bytes(bytes.fromhex(row['x'])) 56 | for case in range(8): 57 | ret = reference.xswiftec_inv(x, u, case) 58 | if ret is None: 59 | assert row[f"case{case}_t"] == "" 60 | else: 61 | assert row[f"case{case}_t"] == ret.to_bytes().hex() 62 | assert reference.xswiftec(u, ret) == x 63 | 64 | with open(FILENAME_ELLSWIFT_DECODE_TEST, newline='', encoding='utf-8') as csvfile: 65 | print(f"Running {FILENAME_ELLSWIFT_DECODE_TEST} tests...") 66 | reader = csv.DictReader(csvfile) 67 | for row in reader: 68 | ellswift = bytes.fromhex(row['ellswift']) 69 | assert reference.ellswift_decode(ellswift).hex() == row['x'] 70 | -------------------------------------------------------------------------------- /bip-0324/secp256k1_test_vectors.py: -------------------------------------------------------------------------------- 1 | """Convert the BIP-324 test vectors to secp256k1 code.""" 2 | 3 | import csv 4 | import reference 5 | import os 6 | import sys 7 | 8 | FILENAME_XSWIFTEC_INV_TEST = os.path.join(sys.path[0], 'xswiftec_inv_test_vectors.csv') 9 | FILENAME_ELLSWIFT_DECODE_TEST = os.path.join(sys.path[0], 'ellswift_decode_test_vectors.csv') 10 | 11 | def format_int(v): 12 | """Format 0 as "0", but other integers as 0x%08x.""" 13 | if v == 0: 14 | return "0" 15 | return f"0x{v:08x}" 16 | 17 | def format_fe(fe): 18 | """Format a field element constant as SECP256K1_FE_CONST code.""" 19 | vals = [(int(fe) >> (32 * (7 - i))) & 0xffffffff for i in range(8)] 20 | strs = ", ".join(format_int(v) for v in vals) 21 | return f"SECP256K1_FE_CONST({strs})" 22 | 23 | def output_xswiftec_inv_cases(): 24 | """Generate lines corresponding to the xswiftec_inv test cases.""" 25 | with open(FILENAME_XSWIFTEC_INV_TEST, newline='', encoding='utf-8') as csvfile: 26 | reader = csv.DictReader(csvfile) 27 | print("xswiftec_inv cases:") 28 | for row in reader: 29 | u = int.from_bytes(bytes.fromhex(row['u']), 'big') 30 | x = int.from_bytes(bytes.fromhex(row['x']), 'big') 31 | pat = sum(1< /dev/null 9 | -------------------------------------------------------------------------------- /bip-0327/vectors/key_agg_vectors.json: -------------------------------------------------------------------------------- 1 | { 2 | "pubkeys": [ 3 | "02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9", 4 | "03DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659", 5 | "023590A94E768F8E1815C2F24B4D80A8E3149316C3518CE7B7AD338368D038CA66", 6 | "020000000000000000000000000000000000000000000000000000000000000005", 7 | "02FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC30", 8 | "04F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9", 9 | "03935F972DA013F80AE011890FA89B67A27B7BE6CCB24D3274D18B2D4067F261A9" 10 | ], 11 | "tweaks": [ 12 | "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141", 13 | "252E4BD67410A76CDF933D30EAA1608214037F1B105A013ECCD3C5C184A6110B" 14 | ], 15 | "valid_test_cases": [ 16 | { 17 | "key_indices": [0, 1, 2], 18 | "expected": "90539EEDE565F5D054F32CC0C220126889ED1E5D193BAF15AEF344FE59D4610C" 19 | }, 20 | { 21 | "key_indices": [2, 1, 0], 22 | "expected": "6204DE8B083426DC6EAF9502D27024D53FC826BF7D2012148A0575435DF54B2B" 23 | }, 24 | { 25 | "key_indices": [0, 0, 0], 26 | "expected": "B436E3BAD62B8CD409969A224731C193D051162D8C5AE8B109306127DA3AA935" 27 | }, 28 | { 29 | "key_indices": [0, 0, 1, 1], 30 | "expected": "69BC22BFA5D106306E48A20679DE1D7389386124D07571D0D872686028C26A3E" 31 | } 32 | ], 33 | "error_test_cases": [ 34 | { 35 | "key_indices": [0, 3], 36 | "tweak_indices": [], 37 | "is_xonly": [], 38 | "error": { 39 | "type": "invalid_contribution", 40 | "signer": 1, 41 | "contrib": "pubkey" 42 | }, 43 | "comment": "Invalid public key" 44 | }, 45 | { 46 | "key_indices": [0, 4], 47 | "tweak_indices": [], 48 | "is_xonly": [], 49 | "error": { 50 | "type": "invalid_contribution", 51 | "signer": 1, 52 | "contrib": "pubkey" 53 | }, 54 | "comment": "Public key exceeds field size" 55 | }, 56 | { 57 | "key_indices": [5, 0], 58 | "tweak_indices": [], 59 | "is_xonly": [], 60 | "error": { 61 | "type": "invalid_contribution", 62 | "signer": 0, 63 | "contrib": "pubkey" 64 | }, 65 | "comment": "First byte of public key is not 2 or 3" 66 | }, 67 | { 68 | "key_indices": [0, 1], 69 | "tweak_indices": [0], 70 | "is_xonly": [true], 71 | "error": { 72 | "type": "value", 73 | "message": "The tweak must be less than n." 74 | }, 75 | "comment": "Tweak is out of range" 76 | }, 77 | { 78 | "key_indices": [6], 79 | "tweak_indices": [1], 80 | "is_xonly": [false], 81 | "error": { 82 | "type": "value", 83 | "message": "The result of tweaking cannot be infinity." 84 | }, 85 | "comment": "Intermediate tweaking result is point at infinity" 86 | } 87 | ] 88 | } 89 | -------------------------------------------------------------------------------- /bip-0327/vectors/key_sort_vectors.json: -------------------------------------------------------------------------------- 1 | { 2 | "pubkeys": [ 3 | "02DD308AFEC5777E13121FA72B9CC1B7CC0139715309B086C960E18FD969774EB8", 4 | "02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9", 5 | "03DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659", 6 | "023590A94E768F8E1815C2F24B4D80A8E3149316C3518CE7B7AD338368D038CA66", 7 | "02DD308AFEC5777E13121FA72B9CC1B7CC0139715309B086C960E18FD969774EFF", 8 | "02DD308AFEC5777E13121FA72B9CC1B7CC0139715309B086C960E18FD969774EB8" 9 | ], 10 | "sorted_pubkeys": [ 11 | "023590A94E768F8E1815C2F24B4D80A8E3149316C3518CE7B7AD338368D038CA66", 12 | "02DD308AFEC5777E13121FA72B9CC1B7CC0139715309B086C960E18FD969774EB8", 13 | "02DD308AFEC5777E13121FA72B9CC1B7CC0139715309B086C960E18FD969774EB8", 14 | "02DD308AFEC5777E13121FA72B9CC1B7CC0139715309B086C960E18FD969774EFF", 15 | "02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9", 16 | "03DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659" 17 | ] 18 | } 19 | -------------------------------------------------------------------------------- /bip-0327/vectors/nonce_agg_vectors.json: -------------------------------------------------------------------------------- 1 | { 2 | "pnonces": [ 3 | "020151C80F435648DF67A22B749CD798CE54E0321D034B92B709B567D60A42E66603BA47FBC1834437B3212E89A84D8425E7BF12E0245D98262268EBDCB385D50641", 4 | "03FF406FFD8ADB9CD29877E4985014F66A59F6CD01C0E88CAA8E5F3166B1F676A60248C264CDD57D3C24D79990B0F865674EB62A0F9018277A95011B41BFC193B833", 5 | "020151C80F435648DF67A22B749CD798CE54E0321D034B92B709B567D60A42E6660279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798", 6 | "03FF406FFD8ADB9CD29877E4985014F66A59F6CD01C0E88CAA8E5F3166B1F676A60379BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798", 7 | "04FF406FFD8ADB9CD29877E4985014F66A59F6CD01C0E88CAA8E5F3166B1F676A60248C264CDD57D3C24D79990B0F865674EB62A0F9018277A95011B41BFC193B833", 8 | "03FF406FFD8ADB9CD29877E4985014F66A59F6CD01C0E88CAA8E5F3166B1F676A60248C264CDD57D3C24D79990B0F865674EB62A0F9018277A95011B41BFC193B831", 9 | "03FF406FFD8ADB9CD29877E4985014F66A59F6CD01C0E88CAA8E5F3166B1F676A602FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC30" 10 | ], 11 | "valid_test_cases": [ 12 | { 13 | "pnonce_indices": [0, 1], 14 | "expected": "035FE1873B4F2967F52FEA4A06AD5A8ECCBE9D0FD73068012C894E2E87CCB5804B024725377345BDE0E9C33AF3C43C0A29A9249F2F2956FA8CFEB55C8573D0262DC8" 15 | }, 16 | { 17 | "pnonce_indices": [2, 3], 18 | "expected": "035FE1873B4F2967F52FEA4A06AD5A8ECCBE9D0FD73068012C894E2E87CCB5804B000000000000000000000000000000000000000000000000000000000000000000", 19 | "comment": "Sum of second points encoded in the nonces is point at infinity which is serialized as 33 zero bytes" 20 | } 21 | ], 22 | "error_test_cases": [ 23 | { 24 | "pnonce_indices": [0, 4], 25 | "error": { 26 | "type": "invalid_contribution", 27 | "signer": 1, 28 | "contrib": "pubnonce" 29 | }, 30 | "comment": "Public nonce from signer 1 is invalid due wrong tag, 0x04, in the first half" 31 | }, 32 | { 33 | "pnonce_indices": [5, 1], 34 | "error": { 35 | "type": "invalid_contribution", 36 | "signer": 0, 37 | "contrib": "pubnonce" 38 | }, 39 | "comment": "Public nonce from signer 0 is invalid because the second half does not correspond to an X coordinate" 40 | }, 41 | { 42 | "pnonce_indices": [6, 1], 43 | "error": { 44 | "type": "invalid_contribution", 45 | "signer": 0, 46 | "contrib": "pubnonce" 47 | }, 48 | "comment": "Public nonce from signer 0 is invalid because second half exceeds field size" 49 | } 50 | ] 51 | } 52 | -------------------------------------------------------------------------------- /bip-0327/vectors/nonce_gen_vectors.json: -------------------------------------------------------------------------------- 1 | { 2 | "test_cases": [ 3 | { 4 | "rand_": "0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F", 5 | "sk": "0202020202020202020202020202020202020202020202020202020202020202", 6 | "pk": "024D4B6CD1361032CA9BD2AEB9D900AA4D45D9EAD80AC9423374C451A7254D0766", 7 | "aggpk": "0707070707070707070707070707070707070707070707070707070707070707", 8 | "msg": "0101010101010101010101010101010101010101010101010101010101010101", 9 | "extra_in": "0808080808080808080808080808080808080808080808080808080808080808", 10 | "expected_secnonce": "B114E502BEAA4E301DD08A50264172C84E41650E6CB726B410C0694D59EFFB6495B5CAF28D045B973D63E3C99A44B807BDE375FD6CB39E46DC4A511708D0E9D2024D4B6CD1361032CA9BD2AEB9D900AA4D45D9EAD80AC9423374C451A7254D0766", 11 | "expected_pubnonce": "02F7BE7089E8376EB355272368766B17E88E7DB72047D05E56AA881EA52B3B35DF02C29C8046FDD0DED4C7E55869137200FBDBFE2EB654267B6D7013602CAED3115A" 12 | }, 13 | { 14 | "rand_": "0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F", 15 | "sk": "0202020202020202020202020202020202020202020202020202020202020202", 16 | "pk": "024D4B6CD1361032CA9BD2AEB9D900AA4D45D9EAD80AC9423374C451A7254D0766", 17 | "aggpk": "0707070707070707070707070707070707070707070707070707070707070707", 18 | "msg": "", 19 | "extra_in": "0808080808080808080808080808080808080808080808080808080808080808", 20 | "expected_secnonce": "E862B068500320088138468D47E0E6F147E01B6024244AE45EAC40ACE5929B9F0789E051170B9E705D0B9EB49049A323BBBBB206D8E05C19F46C6228742AA7A9024D4B6CD1361032CA9BD2AEB9D900AA4D45D9EAD80AC9423374C451A7254D0766", 21 | "expected_pubnonce": "023034FA5E2679F01EE66E12225882A7A48CC66719B1B9D3B6C4DBD743EFEDA2C503F3FD6F01EB3A8E9CB315D73F1F3D287CAFBB44AB321153C6287F407600205109" 22 | }, 23 | { 24 | "rand_": "0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F", 25 | "sk": "0202020202020202020202020202020202020202020202020202020202020202", 26 | "pk": "024D4B6CD1361032CA9BD2AEB9D900AA4D45D9EAD80AC9423374C451A7254D0766", 27 | "aggpk": "0707070707070707070707070707070707070707070707070707070707070707", 28 | "msg": "2626262626262626262626262626262626262626262626262626262626262626262626262626", 29 | "extra_in": "0808080808080808080808080808080808080808080808080808080808080808", 30 | "expected_secnonce": "3221975ACBDEA6820EABF02A02B7F27D3A8EF68EE42787B88CBEFD9AA06AF3632EE85B1A61D8EF31126D4663A00DD96E9D1D4959E72D70FE5EBB6E7696EBA66F024D4B6CD1361032CA9BD2AEB9D900AA4D45D9EAD80AC9423374C451A7254D0766", 31 | "expected_pubnonce": "02E5BBC21C69270F59BD634FCBFA281BE9D76601295345112C58954625BF23793A021307511C79F95D38ACACFF1B4DA98228B77E65AA216AD075E9673286EFB4EAF3" 32 | }, 33 | { 34 | "rand_": "0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F", 35 | "sk": null, 36 | "pk": "02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9", 37 | "aggpk": null, 38 | "msg": null, 39 | "extra_in": null, 40 | "expected_secnonce": "89BDD787D0284E5E4D5FC572E49E316BAB7E21E3B1830DE37DFE80156FA41A6D0B17AE8D024C53679699A6FD7944D9C4A366B514BAF43088E0708B1023DD289702F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9", 41 | "expected_pubnonce": "02C96E7CB1E8AA5DAC64D872947914198F607D90ECDE5200DE52978AD5DED63C000299EC5117C2D29EDEE8A2092587C3909BE694D5CFF0667D6C02EA4059F7CD9786" 42 | } 43 | ] 44 | } 45 | -------------------------------------------------------------------------------- /bip-0327/vectors/tweak_vectors.json: -------------------------------------------------------------------------------- 1 | { 2 | "sk": "7FB9E0E687ADA1EEBF7ECFE2F21E73EBDB51A7D450948DFE8D76D7F2D1007671", 3 | "pubkeys": [ 4 | "03935F972DA013F80AE011890FA89B67A27B7BE6CCB24D3274D18B2D4067F261A9", 5 | "02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9", 6 | "02DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659" 7 | ], 8 | "secnonce": "508B81A611F100A6B2B6B29656590898AF488BCF2E1F55CF22E5CFB84421FE61FA27FD49B1D50085B481285E1CA205D55C82CC1B31FF5CD54A489829355901F703935F972DA013F80AE011890FA89B67A27B7BE6CCB24D3274D18B2D4067F261A9", 9 | "pnonces": [ 10 | "0337C87821AFD50A8644D820A8F3E02E499C931865C2360FB43D0A0D20DAFE07EA0287BF891D2A6DEAEBADC909352AA9405D1428C15F4B75F04DAE642A95C2548480", 11 | "0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F817980279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798", 12 | "032DE2662628C90B03F5E720284EB52FF7D71F4284F627B68A853D78C78E1FFE9303E4C5524E83FFE1493B9077CF1CA6BEB2090C93D930321071AD40B2F44E599046" 13 | ], 14 | "aggnonce": "028465FCF0BBDBCF443AABCCE533D42B4B5A10966AC09A49655E8C42DAAB8FCD61037496A3CC86926D452CAFCFD55D25972CA1675D549310DE296BFF42F72EEEA8C9", 15 | "tweaks": [ 16 | "E8F791FF9225A2AF0102AFFF4A9A723D9612A682A25EBE79802B263CDFCD83BB", 17 | "AE2EA797CC0FE72AC5B97B97F3C6957D7E4199A167A58EB08BCAFFDA70AC0455", 18 | "F52ECBC565B3D8BEA2DFD5B75A4F457E54369809322E4120831626F290FA87E0", 19 | "1969AD73CC177FA0B4FCED6DF1F7BF9907E665FDE9BA196A74FED0A3CF5AEF9D", 20 | "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141" 21 | ], 22 | "msg": "F95466D086770E689964664219266FE5ED215C92AE20BAB5C9D79ADDDDF3C0CF", 23 | "valid_test_cases": [ 24 | { 25 | "key_indices": [1, 2, 0], 26 | "nonce_indices": [1, 2, 0], 27 | "tweak_indices": [0], 28 | "is_xonly": [true], 29 | "signer_index": 2, 30 | "expected": "E28A5C66E61E178C2BA19DB77B6CF9F7E2F0F56C17918CD13135E60CC848FE91", 31 | "comment": "A single x-only tweak" 32 | }, 33 | { 34 | "key_indices": [1, 2, 0], 35 | "nonce_indices": [1, 2, 0], 36 | "tweak_indices": [0], 37 | "is_xonly": [false], 38 | "signer_index": 2, 39 | "expected": "38B0767798252F21BF5702C48028B095428320F73A4B14DB1E25DE58543D2D2D", 40 | "comment": "A single plain tweak" 41 | }, 42 | { 43 | "key_indices": [1, 2, 0], 44 | "nonce_indices": [1, 2, 0], 45 | "tweak_indices": [0, 1], 46 | "is_xonly": [false, true], 47 | "signer_index": 2, 48 | "expected": "408A0A21C4A0F5DACAF9646AD6EB6FECD7F7A11F03ED1F48DFFF2185BC2C2408", 49 | "comment": "A plain tweak followed by an x-only tweak" 50 | }, 51 | { 52 | "key_indices": [1, 2, 0], 53 | "nonce_indices": [1, 2, 0], 54 | "tweak_indices": [0, 1, 2, 3], 55 | "is_xonly": [false, false, true, true], 56 | "signer_index": 2, 57 | "expected": "45ABD206E61E3DF2EC9E264A6FEC8292141A633C28586388235541F9ADE75435", 58 | "comment": "Four tweaks: plain, plain, x-only, x-only." 59 | }, 60 | { 61 | "key_indices": [1, 2, 0], 62 | "nonce_indices": [1, 2, 0], 63 | "tweak_indices": [0, 1, 2, 3], 64 | "is_xonly": [true, false, true, false], 65 | "signer_index": 2, 66 | "expected": "B255FDCAC27B40C7CE7848E2D3B7BF5EA0ED756DA81565AC804CCCA3E1D5D239", 67 | "comment": "Four tweaks: x-only, plain, x-only, plain. If an implementation prohibits applying plain tweaks after x-only tweaks, it can skip this test vector or return an error." 68 | } 69 | ], 70 | "error_test_cases": [ 71 | { 72 | "key_indices": [1, 2, 0], 73 | "nonce_indices": [1, 2, 0], 74 | "tweak_indices": [4], 75 | "is_xonly": [false], 76 | "signer_index": 2, 77 | "error": { 78 | "type": "value", 79 | "message": "The tweak must be less than n." 80 | }, 81 | "comment": "Tweak is invalid because it exceeds group size" 82 | } 83 | ] 84 | } 85 | -------------------------------------------------------------------------------- /bip-0328/_bip327.py: -------------------------------------------------------------------------------- 1 | ../bip-0327/reference.py -------------------------------------------------------------------------------- /bip-0328/_common.py: -------------------------------------------------------------------------------- 1 | """ 2 | Common Classes and Utilities 3 | **************************** 4 | """ 5 | 6 | import hashlib 7 | 8 | def sha256(s: bytes) -> bytes: 9 | """ 10 | Perform a single SHA256 hash. 11 | 12 | :param s: Bytes to hash 13 | :return: The hash 14 | """ 15 | return hashlib.new('sha256', s).digest() 16 | 17 | 18 | def ripemd160(s: bytes) -> bytes: 19 | """ 20 | Perform a single RIPEMD160 hash. 21 | 22 | :param s: Bytes to hash 23 | :return: The hash 24 | """ 25 | return hashlib.new('ripemd160', s).digest() 26 | 27 | 28 | def hash256(s: bytes) -> bytes: 29 | """ 30 | Perform a double SHA256 hash. 31 | A SHA256 is performed on the input, and then a second 32 | SHA256 is performed on the result of the first SHA256 33 | 34 | :param s: Bytes to hash 35 | :return: The hash 36 | """ 37 | return sha256(sha256(s)) 38 | 39 | 40 | def hash160(s: bytes) -> bytes: 41 | """ 42 | perform a single SHA256 hash followed by a single RIPEMD160 hash on the result of the SHA256 hash. 43 | 44 | :param s: Bytes to hash 45 | :return: The hash 46 | """ 47 | return ripemd160(sha256(s)) 48 | -------------------------------------------------------------------------------- /bip-0328/reference.py: -------------------------------------------------------------------------------- 1 | #! /usr/bin/env python3 2 | 3 | import json 4 | import os 5 | import sys 6 | 7 | from _base58 import xpub_to_pub_hex 8 | from _bip327 import cbytes, key_agg 9 | from _xpub import ExtendedKey 10 | 11 | CHAINCODE = bytes.fromhex("868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965") 12 | 13 | def aggregate_to_xpub(aggregate: bytes) -> ExtendedKey: 14 | return ExtendedKey(ExtendedKey.MAINNET_PUBLIC, 0, b"\x00\x00\x00\x00", 0, CHAINCODE, None, aggregate) 15 | 16 | def test_aggregate_to_xpub(): 17 | with open(os.path.join(sys.path[0], "vectors.json"), "r") as f: 18 | test_data = json.load(f) 19 | 20 | for test_case in test_data: 21 | keys = [bytes.fromhex(k) for k in test_case["keys"]] 22 | 23 | agg_ctx = key_agg(keys) 24 | pub = cbytes(agg_ctx.Q) 25 | assert pub.hex() == test_case["aggregate_pubkey"] 26 | 27 | xpub = aggregate_to_xpub(pub) 28 | assert xpub.to_string() == test_case["xpub"] 29 | 30 | if __name__ == "__main__": 31 | test_aggregate_to_xpub() 32 | -------------------------------------------------------------------------------- /bip-0328/vectors.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "aggregate_pubkey": "0354240c76b8f2999143301a99c7f721ee57eee0bce401df3afeaa9ae218c70f23", 4 | "keys": [ 5 | "03935F972DA013F80AE011890FA89B67A27B7BE6CCB24D3274D18B2D4067F261A9", 6 | "02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9" 7 | ], 8 | "xpub": "xpub661MyMwAqRbcFt6tk3uaczE1y6EvM1TqXvawXcYmFEWijEM4PDBnuCXwwXEKGEouzXE6QLLRxjatMcLLzJ5LV5Nib1BN7vJg6yp45yHHRbm" 9 | }, 10 | { 11 | "aggregate_pubkey": "0290539eede565f5d054f32cc0c220126889ed1e5d193baf15aef344fe59d4610c", 12 | "keys": [ 13 | "02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9", 14 | "03DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659", 15 | "023590A94E768F8E1815C2F24B4D80A8E3149316C3518CE7B7AD338368D038CA66" 16 | ], 17 | "xpub": "xpub661MyMwAqRbcFt6tk3uaczE1y6EvM1TqXvawXcYmFEWijEM4PDBnuCXwwVk5TFJk8Tw5WAdV3DhrGfbFA216sE9BsQQiSFTdudkETnKdg8k" 18 | }, 19 | { 20 | "aggregate_pubkey": "022479f134cdb266141dab1a023cbba30a870f8995b95a91fc8464e56a7d41f8ea", 21 | "keys": [ 22 | "02DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659", 23 | "023590A94E768F8E1815C2F24B4D80A8E3149316C3518CE7B7AD338368D038CA66", 24 | "02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9", 25 | "03935F972DA013F80AE011890FA89B67A27B7BE6CCB24D3274D18B2D4067F261A9" 26 | ], 27 | "xpub": "xpub661MyMwAqRbcFt6tk3uaczE1y6EvM1TqXvawXcYmFEWijEM4PDBnuCXwwUvaZYpysLX4wN59tjwU5pBuDjNrPEJbfxjLwn7ruzbXTcUTHkZ" 28 | } 29 | ] 30 | -------------------------------------------------------------------------------- /bip-0330/recon_scheme_merged.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0330/recon_scheme_merged.png -------------------------------------------------------------------------------- /bip-0331/no_package_info.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0331/no_package_info.png -------------------------------------------------------------------------------- /bip-0331/orphan_handling_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0331/orphan_handling_flow.png -------------------------------------------------------------------------------- /bip-0331/package_cpfp_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0331/package_cpfp_flow.png -------------------------------------------------------------------------------- /bip-0331/package_erlay.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0331/package_erlay.png -------------------------------------------------------------------------------- /bip-0331/package_info_only.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0331/package_info_only.png -------------------------------------------------------------------------------- /bip-0331/sender_init_future_version.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0331/sender_init_future_version.png -------------------------------------------------------------------------------- /bip-0331/version_negotiation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0331/version_negotiation.png -------------------------------------------------------------------------------- /bip-0339.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 339
 3 |   Layer: Peer Services
 4 |   Title: WTXID-based transaction relay
 5 |   Author: Suhas Daftuar 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0339
 8 |   Status: Final
 9 |   Type: Standards Track
10 |   Created: 2020-02-03
11 |   License: BSD-2-Clause
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP describes two changes to the p2p protocol to support transaction relay 17 | based on the BIP 141 wtxid of a transaction, rather than its txid. 18 | 19 | ==Motivation== 20 | 21 | Historically, the inv messages sent on the Bitcoin peer-to-peer network to 22 | announce transactions refer to transactions by their txid, which is a hash of 23 | the transaction that does not include the witness (see BIP 141). This has been 24 | the case even since Segregated Witness (BIP 141/143/144) has been adopted by 25 | the network. 26 | 27 | Not committing to the witness in transaction announcements creates 28 | inefficiencies: because a transaction's witness can be malleated without 29 | altering the txid, a node in receipt of a witness transaction that the node 30 | does not accept will generally still download that same transaction when 31 | announced by other peers. This is because the alternative -- of not downloading 32 | a given txid after rejecting a transaction with that txid -- would allow a 33 | third party to interfere with transaction relay by malleating a transaction's 34 | witness and announcing the resulting invalid transaction to nodes, preventing 35 | relay of the valid version of the transaction as well. 36 | 37 | We can eliminate this concern by using the wtxid in place of the txid when 38 | announcing and fetching transactions. 39 | 40 | ==Specification== 41 | 42 | # A new wtxidrelay message is added, which is defined as an empty message where pchCommand == "wtxidrelay". 43 | # The protocol version of nodes implementing this BIP must be set to 70016 or higher. 44 | # The wtxidrelay message MUST be sent in response to a version message from a peer whose protocol version is >= 70016 and prior to sending a verack. A wtxidrelay message received after a verack message MUST be ignored or treated as invalid. 45 | # A new inv type MSG_WTX (0x00000005) is added, for use in both inv messages and getdata requests, indicating that the hash being referenced is a transaction's wtxid. In the case of getdata requests, MSG_WTX implies that the transaction being requested should be serialized with witness as well, as described in BIP 144. 46 | # After a node has received a wtxidrelay message from a peer, the node MUST use the MSG_WTX inv type when announcing transactions to that peer. 47 | # After a node has received a wtxidrelay message from a peer, the node SHOULD use a MSG_WTX getdata message to request any announced transactions. A node MAY still request transactions from that peer using MSG_TX getdata messages, such as for transactions not recently announced by that peer (like the parents of recently announced transactions). 48 | 49 | ==Backward compatibility== 50 | 51 | As wtxid-based transaction relay is only enabled between peers that both support it, older clients remain fully compatible and interoperable after this change. 52 | 53 | ==Implementation== 54 | 55 | https://github.com/bitcoin/bitcoin/pull/18044 56 | 57 | ==Copyright== 58 | 59 | This BIP is licensed under the 2-clause BSD license. 60 | -------------------------------------------------------------------------------- /bip-0340/LICENSE: -------------------------------------------------------------------------------- 1 | BSD-2-Clause OR MIT OR CC0-1.0 2 | 3 | The contents of this directory are provided under one of the following sets of 4 | terms, at your choice: 5 | 6 | - The BSD-2-Clause License 7 | https://opensource.org/license/BSD-2-Clause 8 | - The MIT License 9 | https://opensource.org/license/MIT 10 | - CC0 1.0 11 | https://creativecommons.org/publicdomain/zero/1.0/ 12 | -------------------------------------------------------------------------------- /bip-0341/tree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0341/tree.png -------------------------------------------------------------------------------- /bip-0343.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 343
 3 |   Layer: Consensus (soft fork)
 4 |   Title: Mandatory activation of taproot deployment
 5 |   Author: Shinobius 
 6 |           Michael Folkson 
 7 |   Comments-Summary: No comments yet.
 8 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0343
 9 |   Status: Final
10 |   Type: Standards Track
11 |   Created: 2021-04-25
12 |   License: BSD-3-Clause
13 |            CC0-1.0
14 |
15 | 16 | ==Abstract== 17 | 18 | This document specifies a BIP8 (LOT=true) deployment to activate taproot. 19 | 20 | ==Motivation== 21 | 22 | The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus. 23 | 24 | ==Specification== 25 | 26 | This BIP will begin an activation signaling period using bit 2 at blockheight 681408 with a minimum activation height of 709632 and an activation threshold of 90%. The signaling period will timeout at blockheight 760032 with a latest activation height of 762048. Lockinontimeout (LOT) is set to true so mandatory signaling will be enforced in the last signaling period before the timeout height. Blocks without the signaling bit 2 set run the risk of being rejected during this period if taproot is not locked in prior. This BIP will cease to be active when taproot is locked in. 27 | 28 | ==Reference implementation== 29 | 30 | *[[https://github.com/BitcoinActivation/bitcoin]] 31 | 32 | ==Backward Compatibility== 33 | 34 | As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts. They are strongly encouraged to upgrade in order to fully validate the new programs. 35 | 36 | ==Compatibility with later alternative activations== 37 | 38 | The activation mechanism “Speedy Trial” as proposed by Russell O’Connor and outlined in this bitcoin-dev mailing list [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html post] by David Harding was released in Bitcoin Core. It is effectively a BIP8 activation mechanism with one exception: start height and timeout height were defined using median time past (MTP) rather than block heights. It uses signaling bit 2, was deployed between midnight April 24th 2021 and midnight August 11th 2021, has a minimum activation height of 709632 and intends to activate BIPs 340, 341, and 342. The BIP8(LOT=true) deployment is compatible with the “Speedy Trial” deployment in Bitcoin Core as there was not a discrepancy between MTP and block height for the defined start heights. 39 | 40 | The BIP8 (LOT=true) deployment has also been deliberately designed to be compatible with a future BIP8(LOT=false) or BIP8(LOT=true) deployment in Bitcoin Core assuming Bitcoin Core releases one of these activation mechanisms in the event of the Speedy Trial deployment failing to activate. 41 | 42 | ==Rationale== 43 | 44 | The deployment of BIP148 demonstrated that multiple implementations with different activation mechanisms can incentivize the necessary actors to act so that the different deployments activate in sync. A BIP8 LOT=true deployment can run in parallel with other BIP8 activation mechanisms that have eventual mandatory signaling or no mandatory signaling. Eventual mandatory signaling ensures that miners cannot prevent the activation of a desired feature with community consensus indefinitely. 45 | 46 | ==Acknowledgements== 47 | 48 | Thanks to Shaolin Fry and Luke Dashjr for their work on BIP148 and BIP8 which were important prerequisites for this proposal. 49 | 50 | ==References== 51 | 52 | *[[bip-0008.mediawiki|BIP8 Version bits with lock-in by height]] 53 | *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]] 54 | *[[bip-0340.mediawiki|BIP340 Schnorr Signatures for secp256k1]] 55 | *[[bip-0341.mediawiki|BIP341 Taproot: SegWit version 1 spending rules]] 56 | *[[bip-0342.mediawiki|BIP342 Validation of Taproot Scripts]] 57 | *[https://taproot.works/taproot-faq/ Taproot benefits] 58 | 59 | ==Copyright== 60 | 61 | This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. 62 | 63 | -------------------------------------------------------------------------------- /bip-0345/opvault.drawio.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0345/opvault.drawio.png -------------------------------------------------------------------------------- /bip-0345/vaults-Basic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0345/vaults-Basic.png -------------------------------------------------------------------------------- /bip-0345/withdrawal-comparison.drawio.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0345/withdrawal-comparison.drawio.png -------------------------------------------------------------------------------- /bip-0349.md: -------------------------------------------------------------------------------- 1 | ``` 2 | BIP: 349 3 | Layer: Consensus (soft fork) 4 | Title: OP_INTERNALKEY 5 | Author: Brandon Black 6 | Jeremy Rubin 7 | Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0349 8 | Status: Draft 9 | Type: Standards Track 10 | Created: 2024-11-14 11 | License: BSD-3-Clause 12 | ``` 13 | 14 | ## Abstract 15 | 16 | This BIP describes a new tapscript opcode (`OP_INTERNALKEY`) which 17 | pushes the _taproot internal key_ to the stack. 18 | 19 | ## Specification 20 | 21 | When verifying taproot script path spends having leaf version `0xc0` (as 22 | defined in [BIP 342]), `OP_INTERNALKEY` replaces `OP_SUCCESS203` (0xcb). 23 | `OP_INTERNALKEY` pushes the 32-byte x-only representation of the _taproot 24 | internal key_ (referred to as _p_), as defined in [BIP 341], to the stack. 25 | 26 | ## Motivation 27 | 28 | ### Key spend with additional conditions 29 | 30 | When building taproot outputs, especially those secured by an aggregate key 31 | representing more than one signer, the parties may wish to collaborate on 32 | signing with the _taproot internal key_, but only with additional script 33 | restrictions. In this case, `OP_INTERNALKEY` saves 8 vBytes. 34 | 35 | ### Mitigated control block overhead for scripts using hash locks 36 | 37 | In cases where key path spending is not desired, the internal key may be set to 38 | a NUMS point whose bytes would otherwise be required in a tapscript. This could 39 | be used with any hash locked transaction, for example, to save 8 vBytes. 40 | 41 | Note: The internal key must be the X coordinate of a point on the SECP256K1 42 | curve, so any such hash must be checked and modified until it is such an X 43 | coordinate. This will typically take approximately 2 attempts. 44 | 45 | ### Re-Keying with Merkle Root Preservation 46 | 47 | Consider a program such `CTV CSFS CLTV`. Such fragments are useful for LN-Symmetry applications. 48 | 49 | Such a program would be embedded within a Taproot script path, such as `TR(X, {CTV CSFS CLTV})`. 50 | 51 | Were the internal key to be updated from `X` to `Y`, the resulting program would be: `TR(Y, {CTV CSFS CLTV})`. 52 | 53 | The key in the leaf and the key-path would be mismatched. Were `OP_INTERNALKEY` to be used, 54 | the leaf would automatically re-key. 55 | E.g., `TR(X, {CTV OP_INTERNALKEY CSFS CLTV})` is equivalent to `TR(X, {CTV CSFS CLTV})` 56 | and `TR(Y, {CTV OP_INTERNALKEY CSFS CLTV})` is equivalent to `TR(Y, {CTV CSFS CLTV})`. 57 | 58 | While this particular example is contrived, the general technique of using `OP_INTERNALKEY` 59 | as updatable across an entire script tree is a helpful covenant primitive when it is desirable to 60 | invalidate signatures from prior states. For example, the theoretical `OP_TAPLEAFUPDATEVERIFY` opcode 61 | modifies the internal key directly to remove or add a participant, and `OP_INTERNALKEY` would ensure 62 | that the tweaked key is used from all script paths where desired. 63 | 64 | ## Reference Implementation 65 | 66 | A reference implementation is provided here: 67 | 68 | https://github.com/bitcoin/bitcoin/pull/29269 69 | 70 | ## Backward Compatibility 71 | 72 | By constraining the behavior of an OP_SUCCESS opcode, deployment of the BIP 73 | can be done in a backwards compatible, soft-fork manner. If anyone were to 74 | rely on the OP_SUCCESS behavior of `OP_SUCCESS203`, `OP_INTERNALKEY` would 75 | invalidate their spend. 76 | 77 | ## Deployment 78 | 79 | TBD 80 | 81 | ## Credits 82 | 83 | The concept for INTERNALKEY first arose in a [discussion](https://gnusha.org/bitcoin-wizards/2022-01-05.log) between Russell O'Connor 84 | and Jeremy Rubin in Bitcoin Wizards IRC, inspired by BIP-0118's key punning technique 85 | for the internal key. It was later 86 | drafted into this BIP by Brandon Black. 87 | 88 | 89 | ## Copyright 90 | 91 | This document is licensed under the 3-clause BSD license. 92 | 93 | [BIP 341]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki 94 | 95 | [BIP 342]: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki 96 | -------------------------------------------------------------------------------- /bip-0352/bitcoin_utils.py: -------------------------------------------------------------------------------- 1 | import hashlib 2 | import struct 3 | from io import BytesIO 4 | from ripemd160 import ripemd160 5 | from secp256k1 import ECKey 6 | from typing import Union 7 | 8 | 9 | def from_hex(hex_string): 10 | """Deserialize from a hex string representation (e.g. from RPC)""" 11 | return BytesIO(bytes.fromhex(hex_string)) 12 | 13 | 14 | def ser_uint32(u: int) -> bytes: 15 | return u.to_bytes(4, "big") 16 | 17 | 18 | def ser_uint256(u): 19 | return u.to_bytes(32, 'little') 20 | 21 | 22 | def deser_uint256(f): 23 | return int.from_bytes(f.read(32), 'little') 24 | 25 | 26 | def deser_txid(txid: str): 27 | # recall that txids are serialized little-endian, but displayed big-endian 28 | # this means when converting from a human readable hex txid, we need to first 29 | # reverse it before deserializing it 30 | dixt = "".join(map(str.__add__, txid[-2::-2], txid[-1::-2])) 31 | return bytes.fromhex(dixt) 32 | 33 | 34 | def deser_compact_size(f: BytesIO): 35 | view = f.getbuffer() 36 | nbytes = view.nbytes; 37 | view.release() 38 | if (nbytes == 0): 39 | return 0 # end of stream 40 | 41 | nit = struct.unpack(" bytes: 131 | return ripemd160(hashlib.sha256(s).digest()) 132 | 133 | 134 | def is_p2tr(spk: bytes) -> bool: 135 | if len(spk) != 34: 136 | return False 137 | # OP_1 OP_PUSHBYTES_32 <32 bytes> 138 | return (spk[0] == 0x51) & (spk[1] == 0x20) 139 | 140 | 141 | def is_p2wpkh(spk: bytes) -> bool: 142 | if len(spk) != 22: 143 | return False 144 | # OP_0 OP_PUSHBYTES_20 <20 bytes> 145 | return (spk[0] == 0x00) & (spk[1] == 0x14) 146 | 147 | 148 | def is_p2sh(spk: bytes) -> bool: 149 | if len(spk) != 23: 150 | return False 151 | # OP_HASH160 OP_PUSHBYTES_20 <20 bytes> OP_EQUAL 152 | return (spk[0] == 0xA9) & (spk[1] == 0x14) & (spk[-1] == 0x87) 153 | 154 | 155 | def is_p2pkh(spk: bytes) -> bool: 156 | if len(spk) != 25: 157 | return False 158 | # OP_DUP OP_HASH160 OP_PUSHBYTES_20 <20 bytes> OP_EQUALVERIFY OP_CHECKSIG 159 | return (spk[0] == 0x76) & (spk[1] == 0xA9) & (spk[2] == 0x14) & (spk[-2] == 0x88) & (spk[-1] == 0xAC) 160 | -------------------------------------------------------------------------------- /bip-0352/scan_data_downloader_per_month.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0352/scan_data_downloader_per_month.png -------------------------------------------------------------------------------- /bip-0374/run_test_vectors.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | """Run the BIP-DLEQ test vectors.""" 3 | import csv 4 | import os 5 | import sys 6 | from reference import ( 7 | dleq_generate_proof, 8 | dleq_verify_proof, 9 | ) 10 | from secp256k1 import GE 11 | 12 | 13 | FILENAME_GENERATE_PROOF_TEST = os.path.join(sys.path[0], 'test_vectors_generate_proof.csv') 14 | FILENAME_VERIFY_PROOF_TEST = os.path.join(sys.path[0], 'test_vectors_verify_proof.csv') 15 | 16 | 17 | all_passed = True 18 | print("-----------------------------------------") 19 | print("----- Proof generation test vectors -----") 20 | print("-----------------------------------------") 21 | with open(FILENAME_GENERATE_PROOF_TEST, newline='') as csvfile: 22 | reader = csv.reader(csvfile) 23 | next(reader) 24 | for row in reader: 25 | (index, point_G_hex, seckey_a_hex, point_B_hex, aux_rand_hex, msg_hex, result_str, comment) = row 26 | print(seckey_a_hex) 27 | G = GE() if point_G_hex == 'INFINITY' else GE.from_bytes(bytes.fromhex(point_G_hex)) 28 | a = int.from_bytes(bytes.fromhex(seckey_a_hex), 'big') 29 | B = GE() if point_B_hex == 'INFINITY' else GE.from_bytes(bytes.fromhex(point_B_hex)) 30 | aux_rand = bytes.fromhex(aux_rand_hex) 31 | msg = bytes.fromhex(msg_hex) 32 | if msg == b"": msg = None 33 | print('Test vector', ('#' + index).rjust(3, ' ') + ':' + f' ({comment})') 34 | expected_result = None if result_str == 'INVALID' else bytes.fromhex(result_str) 35 | actual_result = dleq_generate_proof(a, B, aux_rand, G=G, m=msg) 36 | if expected_result == actual_result: 37 | print(' * Passed proof generation test.') 38 | else: 39 | print(' * Failed proof generation test.') 40 | print(' Expected proof: ', expected_result.hex() if expected_result is not None else 'INVALID') 41 | print(' Actual proof: ', actual_result.hex() if actual_result is not None else 'INVALID') 42 | all_passed = False 43 | print() 44 | 45 | 46 | print("-------------------------------------------") 47 | print("----- Proof verification test vectors -----") 48 | print("-------------------------------------------") 49 | with open(FILENAME_VERIFY_PROOF_TEST, newline='') as csvfile: 50 | reader = csv.reader(csvfile) 51 | next(reader) 52 | for row in reader: 53 | (index, point_G_hex, point_A_hex, point_B_hex, point_C_hex, proof_hex, msg_hex, result_success, comment) = row 54 | G = GE() if point_G_hex == 'INFINITY' else GE.from_bytes(bytes.fromhex(point_G_hex)) 55 | A = GE() if point_A_hex == 'INFINITY' else GE.from_bytes(bytes.fromhex(point_A_hex)) 56 | B = GE() if point_B_hex == 'INFINITY' else GE.from_bytes(bytes.fromhex(point_B_hex)) 57 | C = GE() if point_C_hex == 'INFINITY' else GE.from_bytes(bytes.fromhex(point_C_hex)) 58 | proof = bytes.fromhex(proof_hex) 59 | msg = bytes.fromhex(msg_hex) 60 | if msg == b"": msg = None 61 | print('Test vector', ('#' + index).rjust(3, ' ') + ':' + f' ({comment})') 62 | expected_result = result_success == 'TRUE' 63 | actual_result = dleq_verify_proof(A, B, C, proof, G=G, m=msg) 64 | if expected_result == actual_result: 65 | print(' * Passed proof verification test.') 66 | else: 67 | print(' * Failed proof verification test.') 68 | print(' Expected verification result: ', expected_result) 69 | print(' Actual verification result: ', actual_result) 70 | all_passed = False 71 | 72 | 73 | print() 74 | if all_passed: 75 | print('All test vectors passed.') 76 | sys.exit(0) 77 | else: 78 | print('Some test vectors failed.') 79 | sys.exit(1) 80 | -------------------------------------------------------------------------------- /bip-0374/test_vectors_generate_proof.csv: -------------------------------------------------------------------------------- 1 | index,point_G,scalar_a,point_B,auxrand_r,message,result_proof,comment 2 | 0,02cef38f55e78b321a1f785cb1c6e33dfcef9784c18bdc4e279801c449ccdfb88e,07ff93d43f1012a5d4a44aba55240212ed39c87b3344e46757d99f24177fc576,02dad4b35c2379ba8334c9a5dda8f6e6d5cd575a7cc9d3ca4faaac51839daaa30f,cb979b0fc8ccc7f237751e719d992fcc324b6500af33999cd54a3e5c05fb1ea4,efb07d4b382d3da1079fbf24df623ba6c2e4c764993bbfa6dd7a4fe4aaf33859,7e7e934169e0bf4706e6b29e5a621c7fe199a524744a25af80071e111c0e2e94118e730d8add118dd2ee4f7d1cc183e1b87168362d1a6f85c16d8671a3fc7a8a,Success case 1 3 | 1,02464e351831efedb755223cabbf664f10564b4742c725c023034bc928ed339e0e,f4e9172285393c6ada994c811b3e50fc47e96421ea7e54f4a4e459528d4cf562,03fe589b0fa23f060f6d4d1e76b9b19d5bb3db0e56d39a4303913de0e706463008,75f12482b9209dae12230ea1f8bf69723a1b447d361db8f510dd9ab33556fd4c,76184ce9eea5b339ebf5304b57452c1ada1466610f0a58574d6c496798cee04b,6b4521a8363a7ebc5d95ac6ec6b64db81fcf21795187d7c4600c42b73fb4fb9870ab8d106c0fd2d292c1710e10437b20575ddb3cb32eb77a5618d94ddba600f2,Success case 2 4 | 2,0222db2054fef98344352a13bc0304a71da7b5e9a2f7fd1f3c9f3519a3d9377fb7,589476913e763b60d5c2a5bfb39230ec669caac1b44312e9bcd2d3f4473abfef,03bc7a19970c812118f74ba659b491e00dade6096ff62d1afe032a92b8671498ed,4da1c4c4b0f9db4eb6b2e5cb648d7e8a0aa35aa5c4ec4d07f096e0e03deca366,66503623468a78cfcef47888c85e0010ecd897f441d263448bfc7a89b882ab20,12aa2aa469b3c037871a09d18ab18d3840219b1ed169f6ef9deae6d927949884a459705ae89a57522224ce3482dee00a41ba511188ae60efdeb736223eb66e7b,Success case 3 5 | 3,03dfa65bd3711eba75fa1996a0c1d95a4419bd835304152d9aa6efa590670f2af6,24d0ed3fc189eb1b64e5dc9dd4af0f3c8c143b0c79cb5fcca0dfa08a11cc60a1,03b51081323d38fb0b75f0c1ec6755fdb79c239c327ca11269fe68ba8a878b704e,31a68d6db27f6404bbceff646ff1b26a34704a0105a36c5a845d0257cea19c9b,f2996b3766d123a949e65541baf1d89d446360d05af51bd93f0445d8c472c952,7907653d29c5722ae44510e7f2839f253450aefc833b7e0a3b38384032f847f2cf41136b2fe6a558ad125287d20c0117f2a30c4ac0c4cebbcfa1dd3a69d84200,Success case 4 6 | 4,02b15de5a3aefcfe2473916c76e619b5800ac7250ef93a9e6e0dd1505104fc58e7,73fffa796edb72d111b5e0bbda1608f098ac98120796f971b438691e1bfb7b96,03a4692be176ff89a972de9cc407083096847b950d1cae72b947665a3d5f4c2f01,1cdfb4d7cce5e50783299896a471a44e6aa2c5e2100d6c37987c6b40503c6162,0ceb45f560f2cf6b76a139ffe2c47c5ca6d26d6a3a210e59f197413bbec040b4,02277ca5a7acfe8ae13c2db4a8f74489d0ba100ed8b082381ddb6522c4510718ab88b8dbbd785c388ade79586cf6416f3c47a79670af84abccc788a5d9f2e327,Success case 5 7 | 5,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,c08ca8e0bb59769fc6a4e078456284e00ea34f65add988c246e1bba85824ccdc,034bccb1c570ac1f3bc42d61fe35de605b99626501ccb20297e1acbbf2d7152aa1,c8d7056abd4726eb5a0f198740af14d6c1f0c16e5d7a37eaec621b661e669ac4,,503562d36910cd2d61a4d07c8ff680265c713e63dde0dcb88e6ea3c58597bdc05b86db9af95eccc475ce2177f941c118fefed20227d4ce8ce9557cb008758de6,Success case 6 8 | 6,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,8e641ba6bf7f64eec76005a29585a5035376375f33e331215aedfe03b8e80e7a,0231c64e3efa506fdad6aad0f6084d5f6739de7f448d7e66f9d22f842638f41d60,02a7b2e2f5a5e9b1078dbb160502a32491fe80a091e91dd92cf77b0b7d90970f,35841ca532846e1cdd23a3d107824343584f88eff580929469865eae8355ee3c,5c7b27a33210750e9de8679d9f43497cf9f12ac642cde0a1fc26443aa2fc89bf71aabf7bac89f5d8a96cbe86daba155fa74d6f3e111136179e53b04eb6d7807f,Success case 7 9 | 7,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,cfb9a7ecc49bea4f2e2ee34c38a6f48b5cd5bd06f4e4d4ffb45905b3d26db842,021cb81121a00f89769903305a367ad3cc02d5b402b12c026e06ac94bde28cd608,d38466b77484154a3fcb3151094c1c8a845c73a3c036b3a8ebffd8ef62c9047f,22616bb5fb2d7c68270f305122f2a09e833239c4b1c9a04e285119fb606ac794,78a5544afa75bf152653fe55fb76926f2f65131bf090972a0b0b37d310c28a6bde0e7bfacc10ac12d36f55316ba134b6ba0b844a65ae05cad53c0b296c6639bb,Success case 8 10 | 8,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,0000000000000000000000000000000000000000000000000000000000000000,021cb81121a00f89769903305a367ad3cc02d5b402b12c026e06ac94bde28cd608,d38466b77484154a3fcb3151094c1c8a845c73a3c036b3a8ebffd8ef62c9047f,22616bb5fb2d7c68270f305122f2a09e833239c4b1c9a04e285119fb606ac794,INVALID,Failure case (a=0) 11 | 9,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141,021cb81121a00f89769903305a367ad3cc02d5b402b12c026e06ac94bde28cd608,d38466b77484154a3fcb3151094c1c8a845c73a3c036b3a8ebffd8ef62c9047f,22616bb5fb2d7c68270f305122f2a09e833239c4b1c9a04e285119fb606ac794,INVALID,Failure case (a=N [group order]) 12 | 10,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,cfb9a7ecc49bea4f2e2ee34c38a6f48b5cd5bd06f4e4d4ffb45905b3d26db842,INFINITY,d38466b77484154a3fcb3151094c1c8a845c73a3c036b3a8ebffd8ef62c9047f,22616bb5fb2d7c68270f305122f2a09e833239c4b1c9a04e285119fb606ac794,INVALID,Failure case (B is point at infinity) 13 | -------------------------------------------------------------------------------- /bip-0384.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 384
 3 |   Layer: Applications
 4 |   Title: combo() Output Script Descriptors
 5 |   Author: Pieter Wuille 
 6 |           Ava Chow 
 7 |   Comments-Summary: No comments yet.
 8 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0384
 9 |   Status: Final
10 |   Type: Informational
11 |   Created: 2021-06-27
12 |   License: BSD-2-Clause
13 |
14 | 15 | ==Abstract== 16 | 17 | This document specifies combo() output script descriptors. 18 | These take a key and produce P2PK, P2PKH, P2WPKH, and P2SH-P2WPKH output scripts if applicable to the key. 19 | 20 | ==Copyright== 21 | 22 | This BIP is licensed under the BSD 2-clause license. 23 | 24 | ==Motivation== 25 | 26 | In order to make the transition from traditional key based wallets to descriptor based wallets easier, it is useful to be able to take a key and produce the scripts which have traditionally been produced by wallet software. 27 | 28 | ==Specification== 29 | 30 | A new top level script expression is defined: combo(KEY). 31 | This expression can only be used as a top level expression. 32 | It takes a single key expression as an argument and produces either 2 or 4 output scripts, depending on the key. 33 | A combo() expression always produces a P2PK and P2PKH script, the same as putting the key in both a pk() and a pkh() expression. 34 | If the key is/has a compressed public key, then P2WPKH and P2SH-P2WPKH scripts are also produced, the same as putting the key in both a wpkh() and sh(wpkh()) expression. 35 | 36 | ==Test Vectors== 37 | 38 | Valid descriptors followed by the scripts they produce. Descriptors involving derived child keys will have the 0th, and 1st scripts in additional sub-bullets. 39 | 40 | * combo(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1) 41 | ** 2103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bdac 42 | ** 76a9149a1c78a507689f6f54b847ad1cef1e614ee23f1e88ac 43 | ** 00149a1c78a507689f6f54b847ad1cef1e614ee23f1e 44 | ** a91484ab21b1b2fd065d4504ff693d832434b6108d7b87 45 | * combo(04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235) 46 | ** 4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235ac 47 | ** 76a914b5bd079c4d57cc7fc28ecf8213a6b791625b818388ac 48 | * combo([01234567]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL) 49 | ** 2102d2b36900396c9282fa14628566582f206a5dd0bcc8d5e892611806cafb0301f0ac 50 | ** 76a91431a507b815593dfc51ffc7245ae7e5aee304246e88ac 51 | ** 001431a507b815593dfc51ffc7245ae7e5aee304246e 52 | ** a9142aafb926eb247cb18240a7f4c07983ad1f37922687 53 | * combo(xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334/*) 54 | ** Child 0 55 | *** 2102df12b7035bdac8e3bab862a3a83d06ea6b17b6753d52edecba9be46f5d09e076ac 56 | *** 76a914f90e3178ca25f2c808dc76624032d352fdbdfaf288ac 57 | *** 0014f90e3178ca25f2c808dc76624032d352fdbdfaf2 58 | *** a91408f3ea8c68d4a7585bf9e8bda226723f70e445f087 59 | ** Child 1 60 | *** 21032869a233c9adff9a994e4966e5b821fd5bac066da6c3112488dc52383b4a98ecac 61 | *** 76a914a8409d1b6dfb1ed2a3e8aa5e0ef2ff26b15b75b788ac 62 | *** 0014a8409d1b6dfb1ed2a3e8aa5e0ef2ff26b15b75b7 63 | *** a91473e39884cb71ae4e5ac9739e9225026c99763e6687 64 | 65 | Invalid descriptors 66 | 67 | * combo() in sh : sh(combo(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)) 68 | * combo() in wsh : wsh(combo(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)) 69 | * Script in combo(): combo(pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)) 70 | 71 | ==Backwards Compatibility== 72 | 73 | combo() descriptors use the format and general operation specified in [[bip-0380.mediawiki|380]]. 74 | As this is a wholly new descriptor, it is not compatible with any implementation. 75 | However the scripts produced are standard scripts so existing software are likely to be familiar with them. 76 | 77 | ==Reference Implementation== 78 | 79 | combo() descriptors have been implemented in Bitcoin Core since version 0.17. 80 | -------------------------------------------------------------------------------- /bip-0385.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 385
 3 |   Layer: Applications
 4 |   Title: raw() and addr() Output Script Descriptors
 5 |   Author: Pieter Wuille 
 6 |           Ava Chow 
 7 |   Comments-Summary: No comments yet.
 8 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0385
 9 |   Status: Final
10 |   Type: Informational
11 |   Created: 2021-06-27
12 |   License: BSD-2-Clause
13 |
14 | 15 | ==Abstract== 16 | 17 | This document specifies raw() and addr() output script descriptors. 18 | raw() encapsulates a raw script as a descriptor. 19 | addr() encapsulates an address as a descriptor. 20 | 21 | ==Copyright== 22 | 23 | This BIP is licensed under the BSD 2-clause license. 24 | 25 | ==Motivation== 26 | 27 | In order to make descriptors maximally compatible with scripts in use today, it is useful to be able to wrap any arbitrary output script or an address into a descriptor. 28 | 29 | ==Specification== 30 | 31 | Two new script expressions are defined: raw() and addr(). 32 | 33 | ===raw()=== 34 | 35 | The raw(HEX) expression can only be used as a top level descriptor. 36 | As the argument, it takes a hex string representing a Bitcoin script. 37 | The output script produced by this descriptor is the script represented by HEX. 38 | 39 | ===addr()=== 40 | 41 | The addr(ADDR) expression can only be used as a top level descriptor. 42 | It takes an address as its single argument. 43 | The output script produced by this descriptor is the output script produced by the address ADDR. 44 | 45 | ==Test Vectors== 46 | 47 | Valid descriptors followed by the scripts they produce. 48 | 49 | * raw(deadbeef) 50 | ** deadbeef 51 | * raw(512103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea23552ae) 52 | ** 512103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea23552ae 53 | * raw(a9149a4d9901d6af519b2a23d4a2f51650fcba87ce7b87) 54 | ** a9149a4d9901d6af519b2a23d4a2f51650fcba87ce7b87 55 | * addr(3PUNyaW7M55oKWJ3kDukwk9bsKvryra15j) 56 | ** a914eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee87 57 | 58 | Invalid descriptors 59 | 60 | * Non-hex script: raw(asdf) 61 | * Invalid address: addr(asdf) 62 | * raw nested in sh: sh(raw(deadbeef)) 63 | * raw nested in wsh: wsh(raw(deadbeef)) 64 | * addr nested in sh: sh(addr(3PUNyaW7M55oKWJ3kDukwk9bsKvryra15j)) 65 | * addr nested in wsh: wsh(addr(3PUNyaW7M55oKWJ3kDukwk9bsKvryra15j)) 66 | 67 | ==Backwards Compatibility== 68 | 69 | raw() and addr() descriptors use the format and general operation specified in [[bip-0380.mediawiki|380]]. 70 | As this is a wholly new descriptor, it is not compatible with any implementation. 71 | The reuse of existing Bitcoin addresses allows for this to be more easily implemented. 72 | 73 | ==Reference Implementation== 74 | 75 | raw() and addr() descriptors have been implemented in Bitcoin Core since version 0.17. 76 | -------------------------------------------------------------------------------- /bip-0443/amount_example_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0443/amount_example_1.png -------------------------------------------------------------------------------- /bip-0443/amount_example_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0443/amount_example_2.png -------------------------------------------------------------------------------- /bip-0443/amount_example_3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0443/amount_example_3.png -------------------------------------------------------------------------------- /bip-0443/amount_example_4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitcoin/bips/72af87fc72999e3f0a26a06e6e0a7f3134236337/bip-0443/amount_example_4.png -------------------------------------------------------------------------------- /scripts/diffcheck.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | scripts/buildtable.pl >/tmp/table.mediawiki 2> /dev/null 4 | diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true 5 | if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then 6 | diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true 7 | newdiff=$(diff -s /tmp/before.diff /tmp/after.diff -u | grep '^+') 8 | if [ -n "$newdiff" ]; then 9 | echo "$newdiff" 10 | exit 1 11 | fi 12 | echo "README table matches expected table from BIP files" 13 | else 14 | echo 'Cannot build previous commit table for comparison' 15 | exit 1 16 | fi 17 | -------------------------------------------------------------------------------- /scripts/link-format-chk.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | # 3 | # Copyright (c) 2019 The Bitcoin Core developers 4 | # Distributed under the MIT software license, see the accompanying 5 | # file COPYING or http://www.opensource.org/licenses/mit-license.php. 6 | # 7 | # Check wrong mediawiki link format 8 | 9 | ECODE=0 10 | FILES="" 11 | for fname in *.mediawiki; do 12 | GRES=$(grep -n '](http' $fname) 13 | if [ "$GRES" != "" ]; then 14 | if [ $ECODE -eq 0 ]; then 15 | >&2 echo "Github Mediawiki format writes link as [URL text], not as [text](url):" 16 | fi 17 | ECODE=1 18 | echo "- $fname:$GRES" 19 | fi 20 | done 21 | exit $ECODE 22 | --------------------------------------------------------------------------------