├── .travis.yml ├── README.mediawiki ├── bip-0001.mediawiki ├── bip-0001 └── process.png ├── bip-0002.mediawiki ├── bip-0002 ├── process.png └── process.svg ├── bip-0008.mediawiki ├── bip-0008 ├── assignments.mediawiki └── states.png ├── bip-0009.mediawiki ├── bip-0009 ├── assignments.mediawiki └── 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 ├── english.txt ├── french.txt ├── italian.txt ├── japanese.txt ├── korean.txt └── spanish.txt ├── bip-0042.mediawiki ├── bip-0042 └── inflation.png ├── bip-0043.mediawiki ├── bip-0044.mediawiki ├── bip-0045.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-0049.mediawiki ├── bip-0050.mediawiki ├── 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-0080.mediawiki ├── bip-0081.mediawiki ├── bip-0083.mediawiki ├── bip-0084.mediawiki ├── bip-0090.mediawiki ├── bip-0091.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-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-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-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-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-0157.mediawiki ├── bip-0158.mediawiki ├── bip-0158 ├── gentestvectors.go └── testnet-20.csv ├── bip-0159.mediawiki ├── bip-0171.mediawiki ├── bip-0173.mediawiki ├── bip-0174.mediawiki ├── bip-0174 ├── coinjoin-workflow.png └── multisig-workflow.png ├── bip-0175.mediawiki ├── bip-0176.mediawiki ├── bip-0180.mediawiki ├── bip-0199.mediawiki ├── bip-dandelion.mediawiki ├── bip-dandelion ├── 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 └── scripts └── buildtable.pl /.travis.yml: -------------------------------------------------------------------------------- 1 | os: linux 2 | language: generic 3 | sudo: false 4 | script: 5 | - scripts/buildtable.pl >/tmp/table.mediawiki || exit 1 6 | - diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true 7 | - if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true; newdiff=$(diff -s /tmp/before.diff /tmp/after.diff -u | grep '^+'); if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1; fi; else echo 'Cannot build previous commit table for comparison'; fi 8 | -------------------------------------------------------------------------------- /bip-0001/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0001/process.png -------------------------------------------------------------------------------- /bip-0002/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/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-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.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/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.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/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 accomodate 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/op_eval 58 | 59 | == Post History == 60 | 61 | * [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal] 62 | -------------------------------------------------------------------------------- /bip-0012.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 12
 3 |   Layer: Consensus (soft fork)
 4 |   Title: OP_EVAL
 5 |   Author: Gavin Andresen 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0012
 8 |   Status: Withdrawn
 9 |   Type: Standards Track
10 |   Created: 2011-10-18
11 |
12 | 13 | ==Abstract== 14 | 15 | This BIP describes a new opcode (OP_EVAL) for the [https://en.bitcoin.it/wiki/Script Bitcoin scripting system], and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. 16 | 17 | ==Motivation== 18 | 19 | Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions in a way that is backwards-compatible for old clients and miners. 20 | 21 | ==Specification== 22 | 23 | OP_EVAL will re-define the existing OP_NOP1 opcode, and will function as follows: 24 | 25 | * When executed during transaction verification, pops the item from the top of the stack, deserializes it, and executes the resulting script. 26 | * If there is no item on the top of the stack or the item is not a valid script then transaction validation fails. 27 | * If there are any OP_CODESEPARATORs in the deserialized script then transaction validation fails. 28 | * If there are any OP_EVALs in the deserialized script they are also executed, but recursion is limited to a depth of 2. 29 | * Transaction verification must fail if interpreting OP_EVAL as a no-op would cause the verification to fail. 30 | 31 | A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks is also defined: 32 | 33 | DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL 34 | 35 | Which is redeemed by a standard scriptSig: 36 | ...signatures... {serialized script} 37 | 38 | Transactions that redeem standard OP_EVAL scriptPubKeys are only considered standard if the ''serialized script'' is, itself, one of the standard transaction types. 39 | 40 | ==Rationale== 41 | 42 | OP_EVAL allows the receiver of bitcoins to specify how they can be spent when they are spent, instead of requiring the sender of the bitcoins to know the details of how the bitcoins may be redeemed. The sender only needs to know the hash of the ''serialized script'', and one new type of bitcoin address can be used to fund arbitrarily complex transactions. 43 | 44 | If ''serialized script'' is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver. 45 | 46 | The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilties. 47 | 48 | That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure. 49 | 50 | There is a 1-confirmation attack on old clients that interepret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is: 51 | 52 | # Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients. 53 | # Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim. 54 | # Attacker manages to mine a block that contains both transactions. If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block. 55 | 56 | The attack is expensive because it requires the attacker create a block that they know will be invalidated. It is difficult because bitcoin businesses should not accept 1-confirmation transactions for higher-value transactions. 57 | 58 | ==Backwards Compatibility== 59 | 60 | Surprisingly, because OP_EVAL redefines the OP_NOP1 opcode, standard OP_EVAL transactions will validate with old clients and miners. They will check only that the ''serialized script'' hashes to the correct value; the OP_EVAL will be interpreted as a no-op, and as long as the hash is correct the transaction will be considered valid (no signature checking will be done by old clients and miners). 61 | 62 | Old clients will ignore OP_EVAL transactions and transactions that depend on them until they are put into a block by either an old miner that includes non-standard transactions in its blocks or by a new miner. 63 | 64 | Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases: 65 | 66 | # An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners. 67 | # An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners. 68 | 69 | For case (1), new clients and miners will be coded to interpret OP_EVAL as a no-op until February 1, 2012. Before then, miners will be asked to put the string "OP_EVAL" in blocks that they produce so that hashing power that supports the new opcode can be gauged. If less than 50% of miners accept the change as of January 15, 2012 the rollout will be postponed until more than 50% of hashing power supports OP_EVAL (the rollout will be rejected if it becomes clear that a majority of hashing power will not be achieved). 70 | 71 | For case (2), new clients and miners will be written to make sure that transactions involving OP_EVAL are valid if OP_EVAL is interpreted as a no-op. 72 | Example of a transaction that must fail for both old and new miners/clients: 73 | scriptSig: {serialized OP_11} 74 | scriptPubKey: OP_EVAL OP_11 OP_EQUAL 75 | 76 | ==Reference Implementation== 77 | 78 | https://github.com/gavinandresen/bitcoin-git/tree/op_eval 79 | 80 | ==See Also== 81 | 82 | https://bitcointalk.org/index.php?topic=46538 83 | 84 | "Bitcoin Address 01" BIP 85 | 86 | M-of-N Multisignature Transactions BIP 11 87 | -------------------------------------------------------------------------------- /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.cpp1/base58.h at https://github.com/bitcoin/bitcoin/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: Draft
 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/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/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 "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 desireable 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-0039/bip-0039-wordlists.md: -------------------------------------------------------------------------------- 1 | # Wordlists 2 | 3 | * [English](english.txt) 4 | * [Japanese](japanese.txt) 5 | * [Korean](korean.txt) 6 | * [Spanish](spanish.txt) 7 | * [Chinese (Simplified)](chinese_simplified.txt) 8 | * [Chinese (Traditional)](chinese_traditional.txt) 9 | * [French](french.txt) 10 | * [Italian](italian.txt) 11 | 12 | ## Wordlists (Special Considerations) 13 | 14 | ### Japanese 15 | 16 | 1. **Developers implementing phrase generation or checksum verification must separate words using ideographic spaces / accommodate users inputting ideographic spaces.** 17 | (UTF-8 bytes: **0xE38080**; C/C+/Java: **"\u3000"**; Python: **u"\u3000"**) 18 | However, code that only accepts Japanese phrases but does not generate or verify them should be fine as is. 19 | This is because when generating the seed, normalization as per the spec will 20 | automatically change the ideographic spaces into normal ASCII spaces, so as long as your code never shows the user an ASCII space 21 | separated phrase or tries to split the phrase input by the user, dealing with ASCII or Ideographic space is the same. 22 | 23 | 2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the 24 | ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily 25 | for two smaller words (This would be a problem with any of the 3 character sets in Japanese) 26 | 27 | ### Spanish 28 | 29 | 1. Words can be uniquely determined typing the first 4 characters (sometimes less). 30 | 31 | 2. Special Spanish characters like 'ñ', 'ü', 'á', etc... are considered equal to 'n', 'u', 'a', etc... in terms of identifying a word. Therefore, there is no need to use a Spanish keyboard to introduce the passphrase, an application with the Spanish wordlist will be able to identify the words after the first 4 chars have been typed even if the chars with accents have been replaced with the equivalent without accents. 32 | 33 | 3. There are no words in common between the Spanish wordlist and any other language wordlist, therefore it is possible to detect the language with just one word. 34 | 35 | ### Chinese 36 | 37 | 1. Chinese text typically does not use any spaces as word separators. For the sake of 38 | uniformity, we propose to use normal ASCII spaces (0x20) to separate words as per standard. 39 | 40 | ### French 41 | 42 | Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch 43 | ([The pull request](https://github.com/bitcoin/bips/issues/152)) 44 | 45 | 1. High priority on simple and common French words. 46 | 2. Only words with 5-8 letters. 47 | 3. A word is fully recognizable by typing the first 4 letters (special French characters "é-è" are considered equal to "e", for example "museau" and "musée" can not be together). 48 | 4. Only infinitive verbs, adjectives and nouns. 49 | 5. No pronouns, no adverbs, no prepositions, no conjunctions, no interjections (unless a noun/adjective is also popular than its interjection like "mince;chouette"). 50 | 6. No numeral adjectives. 51 | 7. No words in the plural (except invariable words like "univers", or same spelling than singular like "heureux"). 52 | 8. No female adjectives (except words with same spelling for male and female adjectives like "magique"). 53 | 9. No words with several senses AND different spelling in speaking like "verre-vert", unless a word has a meaning much more popular than another like "perle" and "pairle". 54 | 10. No very similar words with 1 letter of difference. 55 | 11. No essentially reflexive verbs (unless a verb is also a noun like "souvenir"). 56 | 12. No words with "ô;â;ç;ê;œ;æ;î;ï;û;ù;à;ë;ÿ". 57 | 13. No words ending by "é;ée;è;et;ai;ait". 58 | 14. No demonyms. 59 | 15. No words in conflict with the spelling corrections of 1990 (http://goo.gl/Y8DU4z). 60 | 16. No embarrassing words (in a very, very large scope) or belonging to a particular religion. 61 | 17. No identical words with the Spanish wordlist (as Y75QMO wants). 62 | 63 | ### Italian 64 | 65 | Credits: @paoloaga @Polve 66 | 67 | Words chosen using the following rules: 68 | 69 | 1. Simple and common Italian words. 70 | 2. Length between 4 and 8 characters. 71 | 3. First 4 letters must be unique between all words. 72 | 4. No accents or special characters. 73 | 5. No complex verb forms. 74 | 6. No plural words. 75 | 7. No words that remind negative/sad/bad things. 76 | 8. If both female/male words are available, choose male version. 77 | 9. No words with double vocals (like: lineetta). 78 | 10. No words already used in other language mnemonic sets. 79 | 11. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must be at least other 3 different letters. 80 | 12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must not be the same sequence of 3 or more letters. 81 | 82 | Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good. 83 | 84 | All the words have been manually selected and automatically checked against the rules. 85 | -------------------------------------------------------------------------------- /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: Draft
 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 mibillenium (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/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/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: Draft
10 |   Type: Informational
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 implementors 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 | Example: Scheme described in BIP44 should use 44' (or 0x8000002C) as purpose. 46 | 47 | Note that m / 0' / * is already taken by BIP32 (default account), which 48 | preceded this BIP. 49 | 50 | Not all wallets may want to support the full range of features and possibilities 51 | described in these BIPs. Instead of choosing arbitrary subset of defined features 52 | and calling themselves BIPxx compatible, we suggest that software which needs 53 | only a limited structure should describe such structure in another BIP and use 54 | different "purpose" value. 55 | 56 | 57 | ==Node serialization== 58 | 59 | Because this scheme can be used to generate nodes for more cryptocurrencies 60 | at once, or even something totally unrelated to cryptocurrencies, there's no 61 | point in using a special version magic described in section "Serialization 62 | format" of BIP32. We suggest to use always 0x0488B21E for public and 0x0488ADE4 63 | for private nodes (leading to prefixes "xpub" and "xprv" respectively). 64 | 65 | ==Reference== 66 | 67 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 68 | -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0047/reusable_payment_codes-01.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0047/reusable_payment_codes-02.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0047/reusable_payment_codes-03.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0047/reusable_payment_codes-04.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0047/reusable_payment_codes-05.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-06.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0047/reusable_payment_codes-06.png -------------------------------------------------------------------------------- /bip-0049.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 49
  3 |   Layer: Applications
  4 |   Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts
  5 |   Author: Daniel Weigl 
  6 |   Comments-Summary: No comments yet.
  7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0049
  8 |   Status: Draft
  9 |   Type: Informational
 10 |   Created: 2016-05-19
 11 |   License: PD
 12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP defines the derivation scheme for HD wallets using the P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki|BIP 141]]) serialization format for segregated witness transactions. 17 | 18 | ==Motivation== 19 | 20 | With the usage of P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]) 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 24 | will detect the accounts and handle them appropriately. 25 | 26 | ===Considerations=== 27 | Two generally different approaches are possible for current BIP44 capable wallets: 28 | 29 | 1) Allow the user to use the same account(s) that they already uses, but add segregated witness encoded addresses to it. 30 | 31 | 1.1) Use the same public keys as defined in BIP44, but in addition to the normal P2PKH address also derive the P2SH address from it. 32 | 33 | 1.2) Use the same account root, but branch off and derive different external and internal chain roots to derive dedicated public keys for the segregated witness addresses. 34 | 35 | 2) Create dedicated accounts used only for segregated witness addresses. 36 | 37 | The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP49-compatible wallet masterseed into/in a non-BIP49-compatible wallet, the account might show up but also it might miss some UTXOs. 38 | 39 | Therefore this BIP uses solution 2, which fails in a more visible way. Either the account shows up or not at all. The user does not have to check his balance after using the same seed in different wallets. 40 | 41 | 42 | ==Specifications== 43 | 44 | This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] root account. 45 | 46 | ===Public key derivation=== 47 | 48 | To derive a public key from the root account, this BIP uses the same account-structure as defined in 49 | [[bip-0044.mediawiki|BIP 44]], but only uses a different purpose value to indicate the different transaction 50 | serialization method. 51 | 52 | 
 53 | m / purpose' / coin_type' / account' / change / address_index
 54 |
55 | 56 | For the `purpose`-path level it uses `49'`. The rest of the levels are used as defined in BIP44. 57 | 58 | 59 | ===Address derivation=== 60 | 61 | To derive the P2SH address from the above calculated public key, we use the encapsulation defined in [[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]: 62 | 63 | witness: 64 | scriptSig: <0 <20-byte-key-hash>> 65 | (0x160014{20-byte-key-hash}) 66 | scriptPubKey: HASH160 <20-byte-script-hash> EQUAL 67 | (0xA914{20-byte-script-hash}87) 68 | 69 | ==Backwards Compatibility== 70 | 71 | This BIP is not backwards compatible by design as described under [#considerations]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong. 72 | 73 | 74 | ==Test vectors== 75 | 76 | 
 77 |   masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
 78 |   masterseed = tprv8ZgxMBicQKsPe5YMU9gHen4Ez3ApihUfykaqUorj9t6FDqy3nP6eoXiAo2ssvpAjoLroQxHqr3R5nE3a5dU3DHTjTgJDd7zrbniJr6nrCzd (testnet)
 79 | 
 80 |   // Account 0, root = m/49'/1'/0'
 81 |   account0Xpriv = tprv8gRrNu65W2Msef2BdBSUgFdRTGzC8EwVXnV7UGS3faeXtuMVtGfEdidVeGbThs4ELEoayCAzZQ4uUji9DUiAs7erdVskqju7hrBcDvDsdbY (testnet)
 82 | 
 83 |   // Account 0, first receiving private key = m/49'/1'/0'/0/0
 84 |   account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ
 85 |   account0recvPrivateKeyHex = 0xc9bdb49cfbaedca21c4b1f3a7803c34636b1d7dc55a717132443fc3f4c5867e8
 86 |   account0recvPublickKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f
 87 | 
 88 |   // Address derivation
 89 |   keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3
 90 |   scriptSig = <0 > = 0x001438971f73930f6c141d977ac4fd4a727c854935b3
 91 |   addressBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742
 92 | 
 93 |   // addressBytes base58check encoded for testnet
 94 |   address = base58check(prefix | addressBytes) = 2Mww8dCYPUpKHofjgcXcBCEGmniw9CoaiD2 (testnet)
 95 |
96 | 97 | 98 | ==Reference== 99 | 100 | * [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]] 101 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 102 | * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] 103 | * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] 104 | * [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]] 105 | 106 | == Copyright == 107 | 108 | This document is placed in the public domain. 109 | -------------------------------------------------------------------------------- /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: Draft
 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 adherance 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 futher 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-0061.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 61
  3 |   Layer: Peer Services
  4 |   Title: Reject P2P message
  5 |   Author: Gavin Andresen 
  6 |   Comments-Summary: Controversial; some recommendation, and some discouragement
  7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0061
  8 |   Status: Final
  9 |   Type: Standards Track
 10 |   Created: 2014-06-18
 11 |
12 | 13 | ==Abstract== 14 | 15 | This BIP describes a new message type for the Bitcoin peer-to-peer network. 16 | 17 | ==Motivation== 18 | 19 | Giving peers feedback about why their blocks or transactions are rejected, or 20 | why they are being banned for not following the protocol helps 21 | interoperability between different implementations. 22 | 23 | It also gives SPV (simplified payment verification) clients a hint that something 24 | may be wrong when their transactions are rejected due to insufficient priority 25 | or fees. 26 | 27 | ==Specification== 28 | 29 | Data types in this specification are as described at https://en.bitcoin.it/wiki/Protocol_specification 30 | 31 | ===reject=== 32 | 33 | One new message type "reject" is introduced. It is sent directly to a peer in response to a "version", "tx" or "block" message. 34 | 35 | For example, the message flow between two peers for a relayed transaction that is rejected for some reason would be: 36 | 37 | --> inv 38 | <-- getdata 39 | --> tx 40 | <-- reject 41 | 42 | All implementations of the P2P protocol version 70,002 and later should support the reject message. 43 | 44 | ====common payload==== 45 | 46 | 47 | Every reject message begins with the following fields. Some messages append extra, message-specific data. 48 | 49 | {| 50 | | Field Size || Name || Data type || Comments 51 | |- 52 | | variable || response-to-msg || var_str || Message that triggered the reject 53 | |- 54 | | 1 || reject-code || uint8_t || 0x01 through 0x4f (see below) 55 | |- 56 | | variable || reason || var_string || Human-readable message for debugging 57 | |} 58 | 59 | The human-readable string is intended only for debugging purposes; in particular, different implementations may 60 | use different strings. The string should not be shown to users or used for anthing besides diagnosing 61 | interoperability problems. 62 | 63 | The following reject code categories are used; in the descriptions below, "server" is the peer generating 64 | the reject message, "client" is the peer that will receive the message. 65 | 66 | {| 67 | | Range || Category 68 | |- 69 | | 0x01-0x0f || Protocol syntax errors 70 | |- 71 | | 0x10-0x1f || Protocol semantic errors 72 | |- 73 | | 0x40-0x4f || Server policy rule 74 | |} 75 | 76 | ==== rejection codes common to all message types ==== 77 | 78 | {| 79 | | Code || Description 80 | |- 81 | | 0x01 || Message could not be decoded 82 | |} 83 | 84 | ==== reject version codes ==== 85 | 86 | Codes generated during the intial connection process in response to a "version" message: 87 | 88 | {| 89 | | Code || Description 90 | |- 91 | | 0x11 || Client is an obsolete, unsupported version 92 | |- 93 | | 0x12 || Duplicate version message received 94 | |} 95 | 96 | ==== reject tx payload, codes ==== 97 | 98 | Transaction rejection messages extend the basic message with the transaction id hash: 99 | 100 | {| 101 | | Field Size || Name || Data type || Comments 102 | |- 103 | | 32 || hash || char[32] || transaction that is rejected 104 | |} 105 | 106 | The following codes are used: 107 | 108 | {| 109 | | Code || Description 110 | |- 111 | | 0x10 || Transaction is invalid for some reason (invalid signature, output value greater than input, etc.) 112 | |- 113 | | 0x12 || An input is already spent 114 | |- 115 | | 0x40 || Not mined/relayed because it is "non-standard" (type or version unknown by the server) 116 | |- 117 | | 0x41 || One or more output amounts are below the 'dust' threshold 118 | |- 119 | | 0x42 || Transaction does not have enough fee/priority to be relayed or mined 120 | |} 121 | 122 | ==== payload, reject block ==== 123 | 124 | Block rejection messages extend the basic message with the block header hash: 125 | 126 | {| 127 | | Field Size || Name || Data type || Comments 128 | |- 129 | | 32 || hash || char[32] || block (hash of block header) that is rejected 130 | |} 131 | 132 | Rejection codes: 133 | 134 | {| 135 | | code || description 136 | |- 137 | | 0x10 || Block is invalid for some reason (invalid proof-of-work, invalid signature, etc) 138 | |- 139 | | 0x11 || Block's version is no longer supported 140 | |- 141 | | 0x43 || Inconsistent with a compiled-in checkpoint 142 | |} 143 | 144 | Note: blocks that are not part of the server's idea of the current best chain, but are otherwise valid, should not trigger reject messages. 145 | 146 | == Compatibility == 147 | 148 | The reject message is backwards-compatible; older peers that do not recognize the reject message will ignore it. 149 | 150 | == Implementation notes == 151 | 152 | Implementors must consider what happens if an attacker either sends them 153 | reject messages for valid transactions/blocks or sends them random 154 | reject messages, and should beware of possible denial-of-service attacks. 155 | For example, notifying the user of every reject message received 156 | would make it trivial for an attacker to mount an annoy-the-user attack. 157 | Even merely writing every reject message to a debugging log could make 158 | an implementation vulnerable to a fill-up-the-users-disk attack. 159 | -------------------------------------------------------------------------------- /bip-0064.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 64
  3 |   Layer: Peer Services
  4 |   Title: getutxo message
  5 |   Author: Mike Hearn 
  6 |   Comments-Summary: No comments yet.
  7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0064
  8 |   Status: Draft
  9 |   Type: Standards Track
 10 |   Created: 2014-06-10
 11 |
12 | 13 | ==Abstract== 14 | 15 | This document describes a small P2P protocol extension that performs UTXO lookups given a set of outpoints. 16 | 17 | ==Motivation== 18 | 19 | All full Bitcoin nodes maintain a database called the unspent transaction output set. This set is 20 | how double spending is checked for: to be valid a transaction must identify unspent outputs in this 21 | set using an identifier called an "outpoint", which is merely the hash of the output's containing 22 | transaction plus an index. 23 | 24 | The ability to query this can sometimes be useful for a lightweight/SPV client which does not have 25 | the full UTXO set at hand. For example, it can be useful in applications implementing assurance 26 | contracts to do a quick check when a new pledge becomes visible to test whether that pledge was 27 | already revoked via a double spend. Although this message is not strictly necessary because e.g. 28 | such an app could be implemented by fully downloading and storing the block chain, it is useful for 29 | obtaining acceptable performance and resolving various UI cases. 30 | 31 | Another example of when this data can be useful is for performing floating fee calculations in an 32 | SPV wallet. This use case requires some other changes to the Bitcoin protocol however, so we will 33 | not dwell on it here. 34 | 35 | ==Specification== 36 | 37 | Two new messages are defined. The "getutxos" message has the following structure: 38 | 39 | {|class="wikitable" 40 | ! Field Size !! Description !! Data type !! Comments 41 | |- 42 | | 1 || check mempool || bool || Whether to apply mempool transactions during the calculation, thus exposing their UTXOs and removing outputs that they spend. 43 | |- 44 | | ? || outpoints || vector || The list of outpoints to be queried. Each outpoint is serialized in the same way it is in a tx message. 45 | |} 46 | 47 | The response message "utxos" has the following structure: 48 | 49 | {|class="wikitable" 50 | ! Field Size !! Description !! Data type !! Comments 51 | |- 52 | | 4 || chain height || uint32 || The height of the chain at the moment the result was calculated. 53 | |- 54 | | 32 || chain tip hash || uint256 || Block hash of the top of the chain at the moment the result was calculated. 55 | |- 56 | | ? || hit bitmap || byte[] || An array of bytes encoding one bit for each outpoint queried. Each bit indicates whether the queried outpoint was found in the UTXO set or not. 57 | |- 58 | | ? || result utxos || result[] || A list of result objects (defined below), one for each outpoint that is unspent (i.e. has a bit set in the bitmap). 59 | |} 60 | 61 | The result object is defined as: 62 | 63 | {|class="wikitable" 64 | ! Field Size !! Description !! Data type !! Comments 65 | |- 66 | | 4 || tx version || uint32 || The version number of the transaction the UTXO was found in. 67 | |- 68 | | 4 || height || uint32 || The height of the block containing the defining transaction, or 0x7FFFFFFF if the tx is in the mempool. 69 | |- 70 | | ? || output || CTxOut || The output itself, serialized in the same way as in a tx message. 71 | |} 72 | 73 | ==Backward compatibility== 74 | 75 | Nodes indicate support by advertising a protocol version above 70003 and by setting a new 76 | NODE_GETUTXO flag in their nServices field, which has a value of 2 (the second bit of the field). 77 | 78 | ==Authentication== 79 | 80 | The UTXO set is not currently authenticated by anything. There are proposals to resolve this by 81 | introducing a new consensus rule that commits to a root hash of the UTXO set in blocks, however this 82 | feature is not presently available in the Bitcoin protocol. Once it is, the utxos message could be 83 | upgraded to include Merkle branches showing inclusion of the UTXOs in the committed sets. 84 | 85 | If the requesting client is looking up outputs for a signed transaction that they have locally, the 86 | client can partly verify the returned output by running the input scripts with it. Currently this 87 | verifies only that the script is correct. A future version of the Bitcoin protocol is likely to also 88 | allow the value to be checked in this way. It does not show that the output is really unspent or was 89 | ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey 90 | should be checked before execution to ensure the remote peer doesn't just set the script to OP_TRUE. 91 | 92 | If the requesting client has a mapping of chain heights to block hashes in the best chain e.g. 93 | obtained via getheaders, then they can obtain a proof that the output did at one point exist by 94 | requesting the block and searching for the output within it. When combined with Bloom filtering this 95 | can be reasonably efficient. 96 | 97 | Note that even when the outputs are being checked against something this protocol has the same 98 | security model as Bloom filtering: a remote node can lie through omission by claiming the requested 99 | UTXO does not exist / was already spent (they are the same, from the perspective of a full node). 100 | Querying multiple nodes and combining their answers can be a partial solution to this, although as 101 | nothing authenticates the Bitcoin P2P network a man in the middle could still yield incorrect 102 | results. 103 | 104 | ==Implementation== 105 | 106 | https://github.com/bitcoin/bitcoin/pull/4351/files 107 | -------------------------------------------------------------------------------- /bip-0068/encoding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0068/encoding.png -------------------------------------------------------------------------------- /bip-0070/Protocol_Sequence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/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/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0073/a.png -------------------------------------------------------------------------------- /bip-0073/b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0073/b.png -------------------------------------------------------------------------------- /bip-0074.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 74
 3 |   Layer: Applications
 4 |   Title: Allow zero value OP_RETURN in Payment Protocol
 5 |   Author: Toby Padilla 
 6 |   Comments-Summary: Unanimously Discourage for implementation
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0074
 8 |   Status: Draft
 9 |   Type: Standards Track
10 |   Created: 2016-01-29
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. 17 | 18 | ==Motivation== 19 | 20 | The Payment Protocol (defined in BIP70) gives merchants a way to build sophisticated transactions by serializing one or more outputs in the form of a PaymentRequest. The PaymentRequest is then served over http/https to a customer's wallet where the serialized transaction can be executed. 21 | 22 | While the Payment Protocol allows for any valid script in its outputs, it also ignores outputs with zero value. This means BIP70 implementations can encode an OP_RETURN script but must provide a greater than dust value for that output. The end result is a successful PaymentRequest transaction with an OP_RETURN but the value assigned to that output is lost forever. 23 | 24 | This BIP allows for zero value OP_RETURN outputs in serialized PaymentRequests. The change means that OP_RETURN scripts will work as they were originally intended from within PaymentRequests without permanently destroying Bitcoin value. Zero value non-OP_RETURN scripts should continue to be ignored. 25 | 26 | In addition to fixing the issue of destroyed value, this change opens up new use cases that were previously impossible. 27 | 28 | While storing data on the blockchain is controversial, when used responsibly OP_RETURN provides a powerful mechanism for attaching metadata to a transaction. This BIP effectively decouples the creation of transactions containing OP_RETURN data from the execution of those transactions. The result are positive benefits for both merchants and wallets/customers. 29 | 30 | By supporting this BIP, wallets can participate in current and future, unforeseen use cases that benefit from metadata stored in OP_RETURN. Until now OP_RETURN transactions have typically been created and submitted by custom software. If a wallet can process a PaymentRequest with OP_RETURN data as proposed by this BIP, it will support potentially sophisticated Bitcoin applications without the wallet developer having to have prior knowledge of that application. 31 | 32 | An example might be a merchant that adds the hash of a plain text invoice to the checkout transaction. The merchant could construct the PaymentRequest with the invoice hash in an OP_RETURN and pass it to the customer's wallet. The wallet could then submit the transaction, including the invoice hash from the PaymentRequest. The wallet will have encoded a proof of purchase to the blockchain without the wallet developer having to coordinate with the merchant software or add features beyond this BIP. 33 | 34 | Merchants and Bitcoin application developers benefit from this BIP because they can now construct transactions that include OP_RETURN data in a keyless environment. Again, prior to this BIP, transactions that used OP_RETURN (with zero value) needed to be constructed and executed in the same software. By separating the two concerns, this BIP allows merchant software to create transactions with OP_RETURN metadata on a server without storing public or private Bitcoin keys. This greatly enhances security where OP_RETURN applications currently need access to a private key to sign transactions. 35 | 36 | ==Specification== 37 | 38 | The specification for this BIP is straightforward. BIP70 should be fully implemented with the following changes: 39 | 40 | * Outputs where the script is an OP_RETURN and the value is zero should be accepted by the wallet. 41 | 42 | BIP70 has special handling for the case with multiple zero value outputs: 43 | 44 |
45 | If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored). 46 |
47 | 48 | This behavior should be retained with the exception of OP_RETURN handling. In the case of a multiple output transaction where the sum of the output values is zero, the user should be prompted for a value and that value should be distributed over any or all outputs ''except'' the OP_RETURN output. In the case where the sum of outputs.amount is non-zero then any OP_RETURN outputs should not be ignored but no value should be assigned to them. 49 | 50 | Payment requests also must contain at least one payable output (i.e. no payment requests with ''just'' an OP_RETURN). 51 | 52 | ==Rationale== 53 | 54 | As with the discussion around vanilla OP_RETURN, the practice of storing data on the blockchain is controversial. While blockchain and network bloat is an undeniable issue, the benefits that come from attaching metadata to transactions has proven to be too powerful to dismiss entirely. In the absence of OP_RETURN support the Bitcoin ecosystem has seen alternative, less elegant and more wasteful methods employed for Blockchain data storage. 55 | 56 | As it exists today, BIP70 allows for OP_RETURN data storage at the expense of permanently destroyed Bitcoin. Even fully removing support for OP_RETURN values in the Payment Protocol would still leave the door open to suboptimal data encoding via burning a larger than dust value to an output with a false address designed to encode data. 57 | 58 | This BIP offers all of the same benefits that come from the OP_RETURN compromise. Mainly that OP_RETURN scripts are provably unspendable and thus can be pruned from the UTXO pool. Without supporting this BIP, wallets that support BIP70 will allow for wasteful data storage. 59 | 60 | ==Compatibility== 61 | 62 | Since this BIP still supports OP_RETURN statements with a greater than zero value, it should be fully backwards compatible with any existing implementations. 63 | 64 | ==Copyright== 65 | 66 | This document is placed in the public domain. 67 | -------------------------------------------------------------------------------- /bip-0075/bip70-extension.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0075/bip70-extension.png -------------------------------------------------------------------------------- /bip-0075/encrypted-invoice-request-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0075/encrypted-invoice-request-process.png -------------------------------------------------------------------------------- /bip-0075/invoice-request-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0075/invoice-request-process.png -------------------------------------------------------------------------------- /bip-0075/mobile-sf-encrypted-ir-without-payment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0075/mobile-sf-encrypted-ir-without-payment.png -------------------------------------------------------------------------------- /bip-0075/mobile-sf-ir-with-payment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0075/mobile-sf-ir-with-payment.png -------------------------------------------------------------------------------- /bip-0075/mobile-sf-ir-without-payment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0075/mobile-sf-ir-without-payment.png -------------------------------------------------------------------------------- /bip-0075/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/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 | 48 | // BIP-IR Extensions 49 | message InvoiceRequest { 50 | required bytes sender_public_key = 1; // Sender's DER-Encoded EC Public Key 51 | optional uint64 amount = 2 [default = 0]; // amount is integer-number-of-satoshis 52 | optional string pki_type = 3 [default = "none"]; // none / x509+sha256 53 | optional bytes pki_data = 4; // Depends on pki_type 54 | optional string memo = 5; // Human-readable description of invoice request for the receiver 55 | optional string notification_url = 6; // URL to notify on EncryptedPaymentRequest ready 56 | optional bytes signature = 7; // PKI-dependent signature 57 | } 58 | 59 | enum ProtocolMessageType { 60 | UNKNOWN_MESSAGE_TYPE = 0; 61 | INVOICE_REQUEST = 1; 62 | PAYMENT_REQUEST = 2; 63 | PAYMENT = 3; 64 | PAYMENT_ACK = 4; 65 | } 66 | 67 | message ProtocolMessage { 68 | required uint64 version = 1 [default = 1]; // Protocol version number 69 | required uint64 status_code = 2 [default = 1]; // Payment Protocol Status Code (Default: 1 "OK") 70 | required ProtocolMessageType message_type = 3; // Message Type of serialized_message 71 | required bytes serialized_message = 4; // Serialized Payment Protocol Message 72 | optional string status_message = 5; // Human-readable Payment Protocol status message 73 | required bytes identifier = 6; // Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String) 74 | } 75 | 76 | message EncryptedProtocolMessage { 77 | required uint64 version = 1 [default = 1]; // Protocol version number 78 | required uint64 status_code = 2 [default = 1]; // Payment Protocol Status Code (Default: 1 "OK") 79 | required ProtocolMessageType message_type = 3; // Message Type of Decrypted encrypted_message 80 | required bytes encrypted_message = 4; // AES-256-GCM Encrypted (as defined in BIP75) Payment Protocol Message 81 | required bytes receiver_public_key = 5; // Receiver's DER-encoded EC Public Key 82 | required bytes sender_public_key = 6; // Sender's DER-encoded EC Public Key 83 | required uint64 nonce = 7; // Microseconds since epoch 84 | required bytes identifier = 8; // Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String) 85 | optional string status_message = 9; // Human-readable Payment Protocol status message 86 | optional bytes signature = 10; // Signature over the full EncryptedProtocolMessage with EC Key Belonging to Sender / Receiver, respectively 87 | } -------------------------------------------------------------------------------- /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 signifigant 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 signifigant 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-0083.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 83
 3 |   Layer: Applications
 4 |   Title: Dynamic Hierarchical Deterministic Key Trees
 5 |   Author: Eric Lombrozo 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0083
 8 |   Status: Draft
 9 |   Type: Standards Track
10 |   Created: 2015-11-16
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP defines a scheme for key derivation that allows for dynamic creation of key hierarchies based on the algorithm described in BIP32. 17 | 18 | ==Motivation== 19 | 20 | Several proposals have been made to try to standardize a structure for hierarchical deterministic wallets for the sake of interoperability (reference BIP32, BIP44, BIP45). However, all proposals to date have tried to impose a specific structure upfront without providing any flexibility for dynamic creation of new hierarchical levels with different semantics or mapping between different applications that use distinct structures. 21 | 22 | Instead of attempting to impose a specific structure upfront, this BIP proposes that we design the derivation in such a way that we can continue extending hierarchies arbitrarily and indefinitely. 23 | 24 | ==Specification== 25 | 26 | BIP32 provides a hierarchical derivation scheme where every node in the tree can be either used to derive child nodes or used as a signing key for ECDSA. This means that as soon as we choose to use a node as a signing key, we can no longer derive children from that node. To draw an analogy to file systems, each node is either a file or a directory but never both. However, given the need to predictably know the location of new children, it is generally not a good idea to mix both signing keys and parent nodes at the same level in the hierarchy. This means that as soon as we've decided that a particular level in the hierarchy is to be used for signing keys, we've lost the ability to nest deeper levels into the tree. 27 | 28 | At every level of the hierarchy, we reserve the child with index 0 to allow further nesting, and for signing key parent nodes use child indices 1 to MAX_INDEX (231 - 1) for signing keys. We can use either hardened or nonhardened derivation. 29 | 30 | Let p denote a specific signing key parent node and k be an index greater than 0. The children signing keys are then: 31 | 32 | p / k 33 | 34 | with k > 0. 35 | 36 | To create sublevels, we derive the nested nodes: 37 | 38 | p / 0 / n 39 | 40 | with n ≥ 0. 41 | 42 | Each of these nodes can now contain signing key children of their own, and again we reserve index 0 to allow deeper nesting. 43 | 44 | ==Notation== 45 | 46 | We propose the following shorthand for writing nested node derivations: 47 | 48 | p // n instead of p / 0 / n 49 | 50 | p //' n instead of p / 0' / n 51 | 52 | ==Mappings== 53 | 54 | Rather than specifying upfront which path is to be used for a specific purpose (i.e. external invoicing vs. internal change), different applications can specify arbitrary parent nodes and derivation paths. This allows for nesting of sublevels to arbitrary depth with application-specified semantics. Rather than trying to specify use cases upfront, we leave the design completely open-ended. Different applications can exchange these mappings for interoperability. Eventually, if certain mappings become popular, application user interfaces can provide convenient shortcuts or use them as defaults. 55 | 56 | Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (231 - 1) for this purpose. However, we believe doing so introduces more ideosyncracies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits. 57 | 58 | ==Use Cases== 59 | 60 | ===Account Hierarchies=== 61 | 62 | For all that follows, we assume that key indices k > 0 and parent node indices n ≥ 0. 63 | 64 | From a master seed m, we can construct a default account using the following derivations for nonhardened signing keys: 65 | 66 | m / 1 / k (for change/internal outputs) 67 | 68 | m / 2 / k (for invoice/external outputs) 69 | 70 | To create subaccount an, we use: 71 | 72 | an = m // n 73 | 74 | To generate keys for subaccount an, we use: 75 | 76 | an / 1 / k (for change/internal outputs) 77 | 78 | an / 2 / k (for invoice/external outputs) 79 | 80 | We can continue creating subaccounts indefinitely using this scheme. 81 | 82 | ===Bidirectional Payment Channels=== 83 | 84 | In order to create a bidirectional payment channel, it is necessary that previous commitments be revokable. In order to revoke previous commitments, each party reveals a secret to the other that would allow them to steal the funds in the channel if a transaction for a previous commitment is inserted into the blockchain. 85 | 86 | By allowing for arbitrary nesting of sublevels, we can construct decision trees of arbitrary depth and revoke an entire branch by revealing a parent node used to derive all the children. 87 | 88 | ==References== 89 | 90 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 91 | * [[https://lightning.network/lightning-network-paper.pdf|Lightning Network Whitepaper]] 92 | 93 | ==Copyright== 94 | 95 | This document is placed in the public domain. 96 | 97 | -------------------------------------------------------------------------------- /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: Draft
 9 |   Type: Informational
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 | ==Backwards Compatibility== 55 | 56 | This BIP is not backwards compatible by design as described under [#considerations]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong. 57 | 58 | ==Test vectors== 59 | 60 | 
61 |   mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
62 |   rootpriv = zprvAWgYBBk7JR8Gjrh4UJQ2uJdG1r3WNRRfURiABBE3RvMXYSrRJL62XuezvGdPvG6GFBZduosCc1YP5wixPox7zhZLfiUm8aunE96BBa4Kei5
63 |   rootpub  = zpub6jftahH18ngZxLmXaKw3GSZzZsszmt9WqedkyZdezFtWRFBZqsQH5hyUmb4pCEeZGmVfQuP5bedXTB8is6fTv19U1GQRyQUKQGUTzyHACMF
64 | 
65 |   // Account 0, root = m/84'/0'/0'
66 |   xpriv = zprvAdG4iTXWBoARxkkzNpNh8r6Qag3irQB8PzEMkAFeTRXxHpbF9z4QgEvBRmfvqWvGp42t42nvgGpNgYSJA9iefm1yYNZKEm7z6qUWCroSQnE
67 |   xpub  = zpub6rFR7y4Q2AijBEqTUquhVz398htDFrtymD9xYYfG1m4wAcvPhXNfE3EfH1r1ADqtfSdVCToUG868RvUUkgDKf31mGDtKsAYz2oz2AGutZYs
68 | 
69 |   // Account 0, first receiving address = m/84'/0'/0'/0/0
70 |   privkey = KyZpNDKnfs94vbrwhJneDi77V6jF64PWPF8x5cdJb8ifgg2DUc9d
71 |   pubkey  = 0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c
72 |   address = bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu
73 | 
74 |   // Account 0, second receiving address = m/84'/0'/0'/0/1
75 |   privkey = Kxpf5b8p3qX56DKEe5NqWbNUP9MnqoRFzZwHRtsFqhzuvUJsYZCy
76 |   pubkey  = 03e775fd51f0dfb8cd865d9ff1cca2a158cf651fe997fdc9fee9c1d3b5e995ea77
77 |   address = bc1qnjg0jd8228aq7egyzacy8cys3knf9xvrerkf9g
78 | 
79 |   // Account 0, first change address = m/84'/0'/0'/1/0
80 |   privkey = KxuoxufJL5csa1Wieb2kp29VNdn92Us8CoaUG3aGtPtcF3AzeXvF
81 |   pubkey  = 03025324888e429ab8e3dbaf1f7802648b9cd01e9b418485c5fa4c1b9b5700e1a6
82 |   address = bc1q8c6fshw2dlwun7ekn9qwf37cu2rn755upcp6el
83 |
84 | 85 | ==Reference== 86 | 87 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 88 | * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] 89 | * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] 90 | * [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]] 91 | * [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]] 92 | * [[bip-0173.mediawiki|BIP173 - Base32 address format for native v0-16 witness outputs]] 93 | -------------------------------------------------------------------------------- /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/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/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/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/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/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/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/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/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: Draft
 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-0103.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 103
 3 |   Layer: Consensus (hard fork)
 4 |   Title: Block size following technological growth
 5 |   Author: Pieter Wuille 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0103
 8 |   Status: Draft
 9 |   Type: Standards Track
10 |   Created: 2015-07-21
11 |   License: BSD-2-Clause
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future. 17 | 18 | ==Copyright== 19 | 20 | This BIP is licensed under the 2-clause BSD license. 21 | 22 | ==Motivation== 23 | 24 | Many people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depended on have improved as well as their availability on the market, there is no reason why Bitcoin's fundamental transaction rate cannot improve proportionally. 25 | 26 | Currently, there is a consensus rule in place that limits the size of blocks to 1000000 bytes. Changing this requires a hard-forking change: one that will require every full node in the network to implement the new rules. The new chain created by those changed nodes will be rejected by old nodes, so this would effectively be a request to the ecosystem to migrate to a new and incompatible network. Doing this while controversy exists is dangerous to the network and the ecosystem. 27 | 28 | Furthermore, the effective space available is always constrained by a hash rate majority and its ability to process transactions. No hard forking change that relaxes the block size limit can be guaranteed to provide enough space for every possible demand - or even any particular demand - unless strong centralization of the mining ecosystem is expected. Because of that, the development of a fee market and the evolution towards an ecosystem that is able to cope with block space competition should be considered healthy. This does not mean the block size or its limitation needs to be constant forever. However, the purpose of such a change should be evolution with technological growth, and not kicking the can down the road because of a fear of change in economics. 29 | 30 | Bitcoin's advantage over other systems does not lie in scalability. Well-designed centralized systems can trivially compete with Bitcoin's on-chain transactions in terms of cost, speed, reliability, convenience, and scale. Its power lies in transparency, lack of need for trust in network peers, miners, and those who influence or control the system. Wanting to increase the scale of the system is in conflict with all of those. Attempting to buy time with a fast increase is not wanting to face that reality, and treating the system as something whose scale trumps all other concerns. A long term scalability plan should aim on decreasing the need for trust required in off-chain systems, rather than increasing the need for trust in Bitcoin. 31 | 32 | In summary, hard forks are extremely powerful, and we need to use them very responsibly as a community. They have the ability to fundamentally change the technology or economics of the system, and can be used to disadvantage those who expected certain rules to be immutable. They should be restricted to uncontroversial changes, or risk eroding the expectation of low trust needed in the system in the longer term. As the block size debate has been controversial so far - for good or bad reasons - this BIP aims for gradual change and its effects start far enough in the future. 33 | 34 | ==Specification== 35 | 36 | The block size limitation is replaced by the function below, applied to the median of the timestamps of the previous 11 blocks, or in code terms: the block size limit for pindexBlock is GetMaxBlockSize(pindexBlock->pprev->GetMedianTimePast()). 37 | 38 | The sigop limit scales proportionally. 39 | 40 | It implements a series of block size steps, one every ~97 days, between January 2017 and July 2063, each increasing the maximum block size by 4.4%. This allows an overall growth of 17.7% per year. 41 | 42 | 
43 | uint32_t GetMaxBlockSize(int64_t nMedianTimePast) {
44 |     // The first step is on January 1st 2017.
45 |     if (nMedianTimePast < 1483246800) {
46 |         return 1000000;
47 |     }
48 |     // After that, one step happens every 2^23 seconds.
49 |     int64_t step = (nMedianTimePast - 1483246800) >> 23;
50 |     // Don't do more than 11 doublings for now.
51 |     step = std::min(step, 175);
52 |     // Every step is a 2^(1/16) factor.
53 |     static const uint32_t bases[16] = {
54 |         // bases[i] == round(1000000 * pow(2.0, (i + 1) / 16.0))
55 |         1044274, 1090508, 1138789, 1189207,
56 |         1241858, 1296840, 1354256, 1414214,
57 |         1476826, 1542211, 1610490, 1681793,
58 |         1756252, 1834008, 1915207, 2000000
59 |     };
60 |     return bases[step & 15] << (step / 16);
61 | }
62 |
63 | 64 | ==Rationale== 65 | 66 | Waiting 1.5 years before the hard fork takes place should provide ample time to minimize the risk of a hard fork, if found uncontroversial. 67 | 68 | Because every increase (including the first) is only 4.4%, risk from large market or technological changes is minimized. 69 | 70 | The growth rate of 17.7% growth per year is consistent with the average growth rate of bandwidth the last years, which seems to be the bottleneck. If over time, this growth factor is beyond what the actual technology offers, the intention should be to soft fork a tighter limit. 71 | 72 | Using a time-based check is very simple to implement, needs little context, is efficient, and is trivially reviewable. Using the "median time past" guarantees monotonic behaviour, as this median is required to be increasing, according to Bitcoin's existing consensus rules. Using the "median time past" of the block before means we know in advance what the limit of each block will be, without depending on the actual block's timestamp. 73 | 74 | ==Compatibility== 75 | 76 | This is a hard forking change, thus breaks compatibility with old fully-validating node. It should not be deployed without widespread consensus. 77 | 78 | ==Acknowledgements== 79 | 80 | Thanks to Gregory Maxwell and Wladimir J. van der Laan for their suggestions. 81 | -------------------------------------------------------------------------------- /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: Draft
 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: Draft
  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-0106.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 106
 3 |   Layer: Consensus (hard fork)
 4 |   Title: Dynamically Controlled Bitcoin Block Size Max Cap
 5 |   Author: Upal Chakraborty 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0106
 8 |   Status: Draft
 9 |   Type: Standards Track
10 |   Created: 2015-08-24
11 |
12 | 13 | ==Abstract== 14 | 15 | This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... 16 | 17 | i. Depending only on previous block size calculation. 18 | 19 | ii. Depending on previous block size calculation and previous Tx fee collected by miners. 20 | 21 | ==Motivation== 22 | 23 | With increased adoption, transaction volume on bitcoin network is bound to grow. If the one megabyte max cap is not changed to a flexible one which changes itself with changing network demand, then adoption will hamper and bitcoin's growth may choke up. Following graph shows the change in average block size since inception... 24 | 25 | https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address= 26 | 27 | ==Specification== 28 | 29 | ===Proposal 1 : Depending only on previous block size calculation=== 30 | 31 | If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize 32 | Double MaxBlockSize 33 | Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize 34 | Half MaxBlockSize 35 | Else 36 | Keep the same MaxBlockSize 37 | 38 | ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== 39 | 40 | TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period 41 | TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) 42 | 43 | TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period 44 | TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) 45 | 46 | If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) ) 47 | MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty 48 | Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) ) 49 | MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty 50 | Else 51 | Keep the same MaxBlockSize 52 | 53 | ==Rationale== 54 | 55 | These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguments can be found [http://upalc.com/maxblocksize.php here]. 56 | 57 | ===Proposal 1 : Depending only on previous block size calculation=== 58 | 59 | This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty. 60 | 61 | ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== 62 | 63 | This solution takes care of stable mining subsidy. It will not increase maximum block size, if Tx fee collection is not increasing and thereby creating a Tx fee pressure on the market. On the other hand, though the block size max cap is dynamically controlled, it is very difficult to game by any party because the increase or decrease of block size max cap will take place in the same ratio of average block size increase or decrease. 64 | 65 | ==Compatibility== 66 | 67 | This is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk rejecting a chain containing larger-than-one-megabyte blocks. 68 | 69 | ==Other solutions considered== 70 | 71 | [http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Making Decentralized Economic Policy] - by Jeff Garzik 72 | 73 | [https://bitcointalk.org/index.php?topic=1078521.0 Elastic block cap with rollover penalties] - by Meni Rosenfeld 74 | 75 | [https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki Increase maximum block size] - by Gavin Andresen 76 | 77 | [https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size following technological growth] - by Pieter Wuille 78 | 79 | [https://lightning.network/lightning-network-paper.pdf The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus Dryja 80 | 81 | ==Deployment== 82 | 83 | If consensus is achieved, deployment can be made at a future block number at which difficulty will change. 84 | -------------------------------------------------------------------------------- /bip-0107.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 107
 3 |   Layer: Consensus (hard fork)
 4 |   Title: Dynamic limit on the block size
 5 |   Author: Washington Y. Sanchez 
 6 |   Comments-Summary: No comments yet.
 7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0107
 8 |   Status: Draft
 9 |   Type: Standards Track
10 |   Created: 2015-09-11
11 |   License: PD
12 |
13 | 14 | ==Abstract== 15 | 16 | This BIP proposes a dynamic limit to the block size based on transaction volume. 17 | 18 | ==Motivation== 19 | 20 | Over the next few years, large infrastructure investments will be made into: 21 | 22 | # Improving global network connectivity 23 | # Improving block propagation across the Bitcoin network 24 | # Layer 2 services and networks for off-chain transactions 25 | # General efficiency improvements to transactions and the blockchain 26 | 27 | * While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. 28 | * In contrast, failing to respond to elevated on-chain transaction volume may lead to a consumer-failure of Bitcoin, where ordinary users - having enjoyed over 6 years of submitting transactions on-chain at relatively low cost - will be priced out of blockchain with the emergence of a prohibitive 'fee market'. 29 | * These two concerns must be delicately balanced so that all users can benefit from a robust, scalable, and neutral network. 30 | 31 | ==Specification== 32 | 33 | * Increases in the block size will occur in 2 phases 34 | * '''Phase 1''' 35 | ** The block size will be increased similar to [[https://twitter.com/adam3us/status/636410827969421312|Adam Back's proposal]], as a safe runway prior to switching to Phase 2, while network and protocol infrastructure is improved 36 | ** The schedule: 37 | *** ''2016-2017:'' 2 MB 38 | *** ''2018-2019:'' 4 MB 39 | *** ''2020:'' 6 MB 40 | * '''Phase 2''' 41 | ** In 2020, the maximum block size will be increased dynamically according to sustained increases in transaction volume 42 | ** Every 4032 blocks (~4 weeks), a CHECK will be performed to determine if a raise in the maximum block size should occur 43 | *** This calculates to a theoretical maximum of 13 increases per year 44 | ** IF of the last >= 3025 blocks were >=60% full, the maximum block size will be increased by 10% 45 | ** The maximum block size can only ever be increased, not decreased 46 | * The default limitfreerelay will also be raised in proportion to maximum block size increases 47 | ** Transactions without fees can continue to be submitted and relayed on the network as per normal 48 | ** limitfreerelay also helps counter attempts to trigger a block size increase by 'penny-flooding' 49 | 50 | For example: 51 | * When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size will be 6 MB 52 | * IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. 53 | * The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. 54 | 55 | ==Rationale== 56 | 57 | * '''Phase 1''' 58 | ** This runway has a schedule for conservative increases to the block size in order to relieve transaction volume pressure while allowing network and protocol infrastructure improvements to be made, as well as layer 2 services to emerge 59 | * '''Phase 2''' 60 | ** Why 60% full blocks? 61 | *** IF blocks are 60% full, they count as a ''vote'' towards increasing the block size 62 | *** If this parameter is too low, the trigger sensitivity may be too high and vulnerable to spam attacks or miner collusion 63 | *** Setting the parameter too high may set the trigger sensitivity too low, causing transaction delays that are trying to be avoided in the first place 64 | *** Between September 2013-2015, the standard deviation measured from average block size (n=730 data points from blockchain.info) was ~ 0.13 MB or 13% of the maximum block size 65 | **** If blocks needed to be 90% full before an increase were triggered, normal variance in the average block size would mean some blocks would be full before an increase could be triggered 66 | *** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit. 67 | ** Why 3025 blocks? 68 | *** The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1 69 | *** Increases in the maximum block size should only occur after a sustained trend can be observed in order to: 70 | ***# Demonstrate a market-driven secular elevation in the transaction volume 71 | ***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions 72 | *** In other words, increases to the maximum block size must be conservative but meaningful to relieve transaction volume pressure in response to true market demand 73 | ** Why 10% increase in the block size? 74 | *** Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunities to increase the block size per year 75 | *** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community 76 | 77 | ==Deployment== 78 | Similar deployment model to BIP101: 79 |
Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks.
80 | 81 | ==Acknowledgements== 82 | 83 | Thanks to Austin Williams, Brian Hoffman, Angel Leon, Bulukani Mlalazi, Chris Pacia, and Ryan Shea for their comments. 84 | 85 | ==Copyright== 86 | 87 | This work is placed in the public domain. 88 | -------------------------------------------------------------------------------- /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 satisified 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-0113.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 113
  3 |   Layer: Consensus (soft fork)
  4 |   Title: Median time-past as endpoint for lock-time calculations
  5 |   Author: Thomas Kerin 
  6 |           Mark Friedenbach 
  7 |   Comments-Summary: No comments yet.
  8 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0113
  9 |   Status: Final
 10 |   Type: Standards Track
 11 |   Created: 2015-08-10
 12 |   License: PD
 13 |
14 | 15 | 16 | ==Abstract== 17 | 18 | This BIP is a proposal to redefine the semantics used in determining a 19 | time-locked transaction's eligibility for inclusion in a block. The 20 | median of the last 11 blocks is used instead of the block's timestamp, 21 | ensuring that it increases monotonically with each block. 22 | 23 | 24 | ==Motivation== 25 | 26 | At present, transactions are excluded from inclusion in a block if the 27 | present time or block height is less than or equal to that specified 28 | in the locktime. Since the consensus rules do not mandate strict 29 | ordering of block timestamps, this has the unfortunate outcome of 30 | creating a perverse incentive for miners to lie about the time of 31 | their blocks in order to collect more fees by including transactions 32 | that by wall clock determination have not yet matured. 33 | 34 | This BIP proposes comparing the locktime against the median of the 35 | past 11 block's timestamps, rather than the timestamp of the block 36 | including the transaction. Existing consensus rules guarantee this 37 | value to monotonically advance, thereby removing the capability for 38 | miners to claim more transaction fees by lying about the timestamps of 39 | their block. 40 | 41 | This proposal seeks to ensure reliable behaviour in locktime calculations 42 | as required by BIP65 (CHECKLOCKTIMEVERIFY) and matching the behavior of 43 | BIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY). 44 | 45 | 46 | ==Specification== 47 | 48 | The values for transaction locktime remain unchanged. The difference is only in 49 | the calculation determining whether a transaction can be included. Instead of 50 | an unreliable timestamp, the following function is used to determine the current 51 | block time for the purpose of checking lock-time constraints: 52 | 53 | enum { nMedianTimeSpan=11 }; 54 | 55 | int64_t GetMedianTimePast(const CBlockIndex* pindex) 56 | { 57 | int64_t pmedian[nMedianTimeSpan]; 58 | int64_t* pbegin = &pmedian[nMedianTimeSpan]; 59 | int64_t* pend = &pmedian[nMedianTimeSpan]; 60 | for (int i = 0; i < nMedianTimeSpan && pindex; i++, pindex = pindex->pprev) 61 | *(--pbegin) = pindex->GetBlockTime(); 62 | std::sort(pbegin, pend); 63 | return pbegin[(pend - pbegin)/2]; 64 | } 65 | 66 | Lock-time constraints are checked by the consensus method IsFinalTx(). 67 | This method takes the block time as one parameter. This BIP proposes 68 | that after activation calls to IsFinalTx() within consensus code use 69 | the return value of `GetMedianTimePast(pindexPrev)` instead. 70 | 71 | The new rule applies to all transactions, including the coinbase transaction. 72 | 73 | A reference implementation of this proposal is provided by the 74 | following pull request: 75 | 76 | https://github.com/bitcoin/bitcoin/pull/6566 77 | 78 | 79 | ==Deployment== 80 | 81 | This BIP is to be deployed by "versionbits" BIP9 using bit 0. 82 | 83 | For Bitcoin '''mainnet''', the BIP9 '''starttime''' will be midnight 1st May 2016 UTC (Epoch timestamp 1462060800) and BIP9 '''timeout''' will be midnight 1st May 2017 UTC (Epoch timestamp 1493596800). 84 | 85 | For Bitcoin '''testnet''', the BIP9 '''starttime''' will be midnight 1st March 2016 UTC (Epoch timestamp 1456790400) and BIP9 '''timeout''' will be midnight 1st May 2017 UTC (Epoch timestamp 1493596800). 86 | 87 | This BIP must be deployed simultaneously with BIP68 and BIP112 using the same deployment mechanism. 88 | 89 | 90 | ==Acknowledgements== 91 | 92 | Mark Friedenbach for designing and authoring the reference 93 | implementation of this BIP. 94 | 95 | Thanks go to Gregory Maxwell who came up with the original idea, 96 | in #bitcoin-wizards on 2013-07-16. 97 | 98 | Thomas Kerin authored this BIP document. 99 | 100 | 101 | ==Compatibility== 102 | 103 | Transactions generated using time-based lock-time will take 104 | approximately an hour longer to confirm than would be expected under 105 | the old rules. This is not known to introduce any compatibility 106 | concerns with existing protocols. 107 | 108 | 109 | ==References== 110 | 111 | [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9: Versionbits] 112 | 113 | [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY] 114 | 115 | [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement signaled via sequence numbers] 116 | 117 | [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY] 118 | 119 | [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations] 120 | 121 | [https://gist.github.com/sipa/bf69659f43e763540550 Version bits] 122 | 123 | 124 | ==Copyright== 125 | 126 | This document is placed in the public domain. 127 | -------------------------------------------------------------------------------- /bip-0114/mastexample.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0114/mastexample.png -------------------------------------------------------------------------------- /bip-0122.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 122
  3 |   Layer: Applications
  4 |   Title: URI scheme for Blockchain references / exploration
  5 |   Author: Marco Pontello 
  6 |   Comments-Summary: No comments yet.
  7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0122
  8 |   Status: Draft
  9 |   Type: Standards Track
 10 |   Created: 2015-08-29
 11 |   License: PD
 12 |   Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html
 13 |
14 | 15 | ==Abstract== 16 | 17 | This BIP proposes a URI scheme for looking up blocks, transactions and addresses on a Blockchain explorer, or in general to make proper Blockchain references. 18 | 19 | ==Motivation== 20 | 21 | The purpose of this URI scheme is to enable users to handle all the requests for details about blocks, transactions, etc. with their preferred tool (being that a web service or a local application). 22 | Currently a Bitcoin client usually points to an arbitrary blockchain explorer when the user looks for the details of a transaction or allows the user to choose from a set of alternatives. 23 | Resorting to copy + paste into a browser is often required. 24 | The same happens with posts and messages that reference some particular txs or blocks, if they provide links at all. 25 | 26 | ==Specification== 27 | 28 | The URI follow this form: 29 | 30 | blockchain:[//]// 31 | 32 | Where: 33 | 34 | {| class="wikitable" 35 | ! style="text-align: center;" | Element 36 | ! colspan="2" style="text-align: center;" | Description 37 | ! Required? 38 | |- 39 | | chain 40 | | colspan="2" | '''chain ID''' (see below) of the desired chain, leading 0s included. If omitted (which would be the usual case), Bitcoin main net is assumed. 41 | | optional 42 | |- 43 | | rowspan="3" | type 44 | | tx 45 | | for transactions. 46 | | rowspan="3" | required 47 | |- 48 | | block 49 | | for blocks (supports both hash or height). 50 | |- 51 | | address 52 | | for addresses. 53 | |- 54 | | hash 55 | | colspan="2" | the relevant hash to refer to (leading zeros included), or block height. 56 | | required 57 | |} 58 | 59 | ====ABNF grammar==== 60 | 61 | 
 62 | blockchainuri = "blockchain:" ["//" chain] "/" object
 63 | object = ("tx" "/" hash) / ("block" "/" (hash / blockheight)) /
 64 |          ("address" "/" address)
 65 | chain = hash
 66 | hash = 64HEXDIG
 67 | blockheight = 1*15DIGIT ; 15 is somehow arbitrary, i.e. a "small" int.
 68 | address = base58 ; https://en.wikipedia.org/wiki/Base58
 69 |
70 | 71 | ---- 72 | ===Definition of chain ID=== 73 | 74 | The '''chain ID''' of a chain is the block hash of the corresponding genesis block. For forked chains, it's the block hash of the first block after fork. 75 | 76 | So, for example: 77 | 
 78 | Bitcoin main   : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 
 79 | Bitcoin test   : 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
 80 | Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206 
 81 |
82 | 83 | An example of forked chain (Feathercoin, that forked Litecoin): 84 | 85 | 86 | 87 | 
 88 | Litecoin   : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2
 89 | Feathercoin: fdbe99b90c90bae7505796461471d89ae8388ab953997aa06a355bbda8d915cb
 90 |
91 | 92 | 93 | ==Examples== 94 | 95 | A transaction on Bitcoin main net: 96 | blockchain:/tx/b462ae6eb8bdae2e060239a2a3ea5d9c3e0f9ef34d9717beb2dcf0ed42cee7da 97 | 98 | A block on Bitcoin main net: 99 | blockchain:/block/00000000000000000119af5bcae2926df54ae262e9071a94a99c913cc217cc72 100 | or 101 | blockchain:/block/372338 102 | 103 | An address on Bitcoin main net: 104 | blockchain:/address/16EW6Rv9P9AxFDBrZV816dD4sj1EAYUX3f 105 | 106 | A transaction on Bitcoin test net: 107 | blockchain://000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a 108 | 109 | ==Rationale== 110 | 111 | From the point of view of a wallet (or other Blockchain related tool) developers which need to reference Blockchain data, using this scheme mean that he can simply make it a `blockchain:` link without having to worry about any specific Blockchain explorer or provide a means for the user to select one. 112 | 113 | Blockchain explorers in turn will simply offer to handle the `blockchain:` URI schema, the first time the user visit their website, or launch/install the application, or even set themselves if there isn't already one. 114 | 115 | Users can link directly to their preferred block explorer (avoiding copy + paste which can be awkward on mobile devices). 116 | 117 | == Sample implementation == 118 | 119 | [https://github.com/MarcoPon/blockchain-exploration Demo Blockchain: URI handler on GitHub] 120 | 121 | ==Acknowledgements== 122 | 123 | Thanks to Btc Drak for suggesting support for different networks and Jorge Timon for the suggestion that we could identify each network by its genesis block hash. 124 | Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for help with the structure and hierarchy of the URI scheme. 125 | 126 | ==Copyright== 127 | 128 | This document is placed in the public domain. 129 | -------------------------------------------------------------------------------- /bip-0122/chainid.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0122/chainid.png -------------------------------------------------------------------------------- /bip-0124.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 124
  3 |   Layer: Applications
  4 |   Title: Hierarchical Deterministic Script Templates
  5 |   Author: Eric Lombrozo 
  6 |           William Swanson 
  7 |   Comments-Summary: No comments yet.
  8 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0124
  9 |   Status: Draft
 10 |   Type: Informational
 11 |   Created: 2015-11-20
 12 |   License: PD
 13 |   Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html
 14 |
15 | 16 | ==Abstract== 17 | 18 | This BIP defines a script template format that can be used by wallets to deterministically generate scripts with specific authorization policies using the key derivation mechanism defined in BIP32. 19 | 20 | ==Motivation== 21 | 22 | Currently existing wallets typically issue scripts in only a tiny handful of widely used formats. The most popular formats are pay-to-pubkey-hash and m-of-n pay-to-script-hash (BIP16). However, different wallets tend to use mutually incompatible derivation schemes to generate signing keys and construct scripts from them. Moreover, with the advent of hashlocked and timelocked contracts (BIP65, BIP112), it is necessary for different wallets to be able to cooperatively generate even more sophisticated scripts. 23 | 24 | In addition, there's a lot of ongoing work in the development of multilayered protocols that use the blockchain as a settlement layer (i.e. the Lightning Network). These efforts require sufficiently generalized templates to allow for rapidly evolving script designs. 25 | 26 | This BIP provides a generalized format for constructing a script template that guarantees that different wallets will all produce the same scripts for a given set of derivation paths according to BIP32. 27 | 28 | ==Specification== 29 | 30 | ===Keys=== 31 | 32 | An individual key is determined by a BIP32 derivation path and an index. For convenience, we introduce the following notation: 33 | 34 | '''A'''k = (derivation path for A)/k 35 | 36 | ===Key Groups=== 37 | 38 | Let '''m'''i denote distinct BIP32 derivation paths. We define a key group of n keys as a set of key derivation paths with a free index k: 39 | 40 | {'''K'''k} = { '''m'''1/k, '''m'''2/k, '''m'''3/k, ..., '''m'''n/k } 41 | 42 | Key groups are useful for constructing scripts that are symmetric in a set of keys. Scripts are symmetric in a set of keys if the semantics of the script is unaffected by permutations of the keys. Key groups enforce a canonical form and can improve privacy. 43 | 44 | ===Sorting=== 45 | 46 | We define a lexicographic sorting of the keys. (TODO: specification of sorting conventions - compressed pubkeys, encoding, etc...) 47 | 48 | Define {'''K'''k}j to be the jth element of the sorted keys for derivation index k. 49 | 50 | ===Script Templates=== 51 | 52 | We construct script templates by inserting placeholders for data into a script. To denote a placeholder, we use the following notation: 53 | 54 | ''Script''('''A''') = opcodes ['''A'''] opcodes 55 | 56 | We extend this notation to an arbitrary number of placeholders: 57 | 58 | ''Script''('''X1''', '''X2''', ..., '''Xn''') = opcodes ['''X1'''] opcodes ['''X2'''] opcodes ... opcodes ['''Xn'''] opcodes 59 | 60 | We introduce the following convenient notation for sorted key groups: 61 | 62 | [{'''K'''k}] = [{'''K'''k}1] [{'''K'''k}2] ... [{'''K'''k}n] 63 | 64 | ===Operations on Keys=== 65 | 66 | In some applications, we might want to insert the result of some operation performed on a key rather than the key itself into the script. For example, we might want to insert a Hash160 of key '''A'''k. We can use the following notation: 67 | 68 | [''Hash160''('''A'''k)] 69 | 70 | ===Encoding=== 71 | 72 | TODO 73 | 74 | ==Examples== 75 | 76 | ===2-of-3 Multisig=== 77 | 78 | The script template is defined by: 79 | 80 | ''Script''('''X''') = 2 ['''X'''] 3 OP_CHECKMULTISIG 81 | 82 | Letting '''K'''k = { '''m'''1/k, '''m'''2/k, '''m'''3/k }, the ''k''th script for this key group is denoted by ''Script''({'''K'''k}). 83 | 84 | ===1-of-1 or 2-of-3=== 85 | 86 | The script template is defined by: 87 | 88 | ''Script''('''A''', '''B''') =
89 |         OP_DUP ['''A'''] OP_CHECKSIG
90 |         OP_NOTIF
91 |                 2 ['''B'''] 3 OP_CHECKMULTISIGVERIFY
92 |         OP_NOTIF
93 |         OP_ENDIF
94 |         OP_TRUE
95 | 96 | Let '''M'''k = '''m'''/k be a key of a superuser that can authorize all transactions and {'''K'''k} be a key group of three users that can only authorize transactions if at least two of them agree. 97 | 98 | The ''k''th script is given by ''Script''('''M'''k, {'''K'''k}). 99 | 100 | ===Timelocked Contract=== 101 | 102 | The output is payable to Alice immediately if she knows the private key for '''A'''k. Bob must know the private key for '''B'''k and also wait for a timeout '''t''' before being able to spend the output. 103 | 104 | The script template is defined by: 105 | 106 | ''Script''('''A''', '''B''', '''T''') =
107 |         OP_IF
108 |                 OP_DUP OP_HASH160 [''Hash160''('''A''')] OP_EQUALVERIFY OP_CHECKSIG
109 |         OP_ELSE
110 |                 ['''T'''] OP_CHECKLOCKTIMEVERIFY OP_DROP
111 |                 OP_DUP OP_HASH160 [''Hash160''('''B''')] OP_EQUALVERIFY OP_CHECKSIG
112 |         OP_ENDIF 113 | 114 | The ''k''th script with timeout '''t''' is given by ''Script''('''A'''k, '''B'''k, '''t'''). 115 | 116 | ==References== 117 | 118 | * [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]] 119 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 120 | * [[bip-0065.mediawiki|BIP65 - OP_CHECKLOCKTIMEVERIFY]] 121 | * [[bip-0112.mediawiki|BIP112 - CHECKSEQUENCEVERIFY]] 122 | * [[https://lightning.network/lightning-network-paper.pdf|Lightning Network Whitepaper]] 123 | 124 | ==Copyright== 125 | 126 | This document is placed in the public domain. 127 | 128 | -------------------------------------------------------------------------------- /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: Proposed
 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-0131.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 131
  3 |   Layer: Consensus (hard fork)
  4 |   Title: "Coalescing Transaction" Specification (wildcard inputs)
  5 |   Author: Chris Priest 
  6 |   Comments-Summary: No comments yet.
  7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0131
  8 |   Status: Draft
  9 |   Type: Standards Track
 10 |   Created: 2015-11-30
 11 |   License: PD
 12 |
13 | 14 | ==Abstract== 15 | 16 | This specification defines a new type of transaction that supplements (not replaces) 17 | normal "non coalescing" bitcoin transactions. 18 | 19 | ==Motivation== 20 | 21 | Normal "non-coalescing" Bitcoin Transactions have one large inefficiency: When you want to spend 22 | from multiple inputs with the exact same scriptPubKey, you have to list each 23 | input separately, along with the same signature multiple times, even though the signature expresses the same information. 24 | This bloats the transaction size and makes it expensive to spend from small value inputs. 25 | 26 | Because small value inputs are expensive to send, they remain in the UTXO pool 27 | which full nodes have to keep around. It is believed that long term increase of the UTXO 28 | set can have negative scaling consequences on the network. 29 | 30 | If maximum blocksize is made to increase *slower* than the actual number of transactions bitcoin users are sending 31 | to the network, this problem is projected to get worse. In other words, as transaction 32 | fees increase, the minimum economical value of a spending a UTXO will increase. 33 | 34 | ==Specification== 35 | 36 | === Redefinition of Transaction version === 37 | 38 | First, this BIP redefines the version field on transactions. The first four bytes 39 | are defined as the version number, while the last four bytes are defined as the 40 | transaction type. Type "0000" denotes normal transactions, and "0001" defines 41 | coalescing transaction. 42 | 43 | Examples: 44 | 45 | version 1 transaction with normal inputs: 46 | version: 10000000 47 | 48 | version 2 transaction with normal inputs: 49 | version: 20000000 50 | 51 | version 2 transaction with coalescing inputs: 52 | version: 20000001 53 | 54 | Essentially the last bit in the version field is set to 1 to enable wildcard inputs for all 55 | inputs present in the transaction. 56 | 57 | === Wildcard inputs === 58 | 59 | A coalescing transaction is formulated the exact same way as a version 1 transaction 60 | with one exception: each input is treated as a "wildcard input". 61 | 62 | A wildcard input beings the value of all inputs with the exact same scriptPubKey 63 | in a block lower or equal to the block the wildcard input is confirmed into. 64 | 65 | == Changes needed to implement == 66 | 67 | The bitcoin code needs to be modified in three places in order to handle Coalescing Transactions. 68 | 69 | 1. Full Node Coalescing validation - When a full node receives a coalescing transaction, it has to 70 | aggregate the value of all the UTXOs in the blockchain older than the input 71 | with the same scriptPubKey. If this value is greater than or equal to the 72 | amount of all outputs, then that coalescing transaction is valid and can be propagated. 73 | 74 | 2. Full Node Non-Coalescing validation - When a non-coalescing transaction comes in, the code needs to be modified 75 | to check if each input has not been spent by a coalescing transaction. If there exist any 76 | coalescing transaction in the blockchain with the same scriptPubKey found in a block *after* that input, 77 | then the UTXO has been spent and the transaction is invalid. 78 | 79 | 3. Wallet - The user facing wallet portion of the reference client should notify 80 | the user when their wallet contains many UTXOs that qualify it to benefit from 81 | a coalescing transaction. Wallets should not simply replace non-coalescing transactions 82 | with coalescing transactions in all instances. 83 | 84 | == Isn't this BIP bad because it encourage address re-use? == 85 | 86 | Address re-use comes in two forms: re-use by the ''sender'', and re-use by the ''receiver''. 87 | 88 | Re-use by the sender is basically using the same address for the change output. This is generally considered bad 89 | since people looking through your transaction history can determine who you do business with. When 90 | you generate a new address for every change, your privacy is conserved as it is impossible to know which 91 | output is a recipient, and which output is the change output. This BIP has '''no effect''' on re-use 92 | by the sender. 93 | 94 | On the other hand, address re-use by the ''receiver'' occurs under completely different circumstances. 95 | When you publish an address and have multiple people send to that address, you are engaging in address re-use 96 | from the receiver. This activity has historically been considered bad because it leads to re-using a private key. 97 | When you re-use a private key too many times, you run the risk of an attacker performing statistical analysis 98 | on the multiple signatures, which can lead to an attacker finding out your private key. 99 | 100 | This BIP introduces a way to spend multiple inputs ''without'' re-using the private key. In a sense, this BIP 101 | fixes the problem that makes address re-use bad for the receiver. After this BIP becomes implemented 102 | and deployed, address re-use by the receiver will no longer be considered bad form. 103 | 104 | ==Copyright== 105 | 106 | This document is placed in the public domain. 107 | -------------------------------------------------------------------------------- /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: Draft
 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/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0135/bip-0135-states-small.png -------------------------------------------------------------------------------- /bip-0135/bip-0135-states.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0135/bip-0135-states.png -------------------------------------------------------------------------------- /bip-0144.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 144
  3 |   Layer: Peer Services
  4 |   Title: Segregated Witness (Peer Services)
  5 |   Author: Eric Lombrozo 
  6 |           Pieter Wuille 
  7 |   Comments-Summary: No comments yet.
  8 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0144
  9 |   Status: Final
 10 |   Type: Standards Track
 11 |   Created: 2016-01-08
 12 |   License: PD
 13 |
14 | 15 | ==Abstract== 16 | This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures. 17 | 18 | ==Motivation== 19 | In addition to defining witness structures and requiring commitments in future blocks ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141] - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes. 20 | 21 | ==Specification== 22 | 23 | === Serialization === 24 | A new serialization format for tx messages is added to the peer-to-peer protocol. 25 | 26 | The serialization has the following structure: 27 | 28 | {| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" 29 | !Field Size 30 | !Name 31 | !Type 32 | !Description 33 | |- 34 | | 4 35 | | version 36 | | int32_t 37 | | Transaction data format version 38 | |- 39 | | 1 40 | | marker 41 | | char 42 | | Must be zero 43 | |- 44 | | 1 45 | | flag 46 | | char 47 | | Must be nonzero 48 | |- 49 | | 1+ 50 | | txin_count 51 | | var_int 52 | | Number of transaction inputs 53 | |- 54 | | 41+ 55 | | txins 56 | | txin[] 57 | | A list of one or more transaction inputs 58 | |- 59 | | 1+ 60 | | txout_count 61 | | var_int 62 | | Number of transaction outputs 63 | |- 64 | | 9+ 65 | | txouts 66 | | txouts[] 67 | | A list of one or more transaction outputs 68 | |- 69 | | 1+ 70 | | script_witnesses 71 | | script_witnesses[] 72 | | The witness structure as a serialized byte array 73 | |- 74 | | 4 75 | | lock_time 76 | | uint32_t 77 | | The block number or timestamp until which the transaction is locked 78 | |} 79 | 80 | Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output. 81 | 82 | If the witness is empty, the old serialization format should be used. 83 | 84 | Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins. 85 | 86 | * '''Rationale for not having an independent message type with its own serialization''': this would require separate "tx" and "block" messages, and all RPC calls operating on raw transactions would need to be duplicated, or need inefficient or nondeterministic guesswork to know which type is to be used. 87 | 88 | * '''Rationale for not using just a single 0x00 byte as marker''': that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data. 89 | 90 | * '''Rationale for the 0x01 flag byte in between''': this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector. 91 | 92 | === Handshake === 93 | A node will signal that it can provide witnesses using the following service bit 94 | 95 | NODE_WITNESS = (1 << 3) 96 | 97 | 98 | === Hashes === 99 | Transaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness 100 | serialization. 101 | 102 | Support for a new hash including the witness data is added that is 103 | computed from the new witness serialization. (Note that transactions 104 | with an empty witness always use the old serialization, 105 | and therefore, they have witness hash equal to normal hash.) 106 | 107 | 108 | 109 | === Relay === 110 | New inv types MSG_WITNESS_TX (0x40000001, or (1<<30)+MSG_TX) and MSG_WITNESS_BLOCK (0x40000002, or (1<<30)+MSG_BLOCK) are added, only 111 | for use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK, 112 | similar to MSG_FILTERED_BLOCK. A further inv type MSG_FILTERED_WITNESS_BLOCK (0x40000003, or (1<<30)+MSG_FILTERED_BLOCK) is reserved for future use. 113 | 114 | * '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones. 115 | 116 | MSG_WITNESS_TX getdata requests should use the non-witness serialized hash. The peer shall respond with a tx message, and if the witness structure is nonempty, the witness serialization shall be used. 117 | 118 | MSG_WITNESS_BLOCK requests will return a block message with transactions that have a witness using witness serialization. 119 | 120 | == Credits == 121 | Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork. 122 | 123 | == Reference Implementation == 124 | https://github.com/bitcoin/bitcoin/pull/8149 125 | 126 | == Copyright == 127 | This document is placed in the public domain. 128 | -------------------------------------------------------------------------------- /bip-0144/witnesstx.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0144/witnesstx.png -------------------------------------------------------------------------------- /bip-0145.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 145
  3 |   Layer: API/RPC
  4 |   Title: getblocktemplate Updates for Segregated Witness
  5 |   Author: Luke Dashjr 
  6 |   Comments-Summary: No comments yet.
  7 |   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0145
  8 |   Status: Final
  9 |   Type: Standards Track
 10 |   Created: 2016-01-30
 11 |   License: BSD-2-Clause
 12 |            OPL
 13 |
14 | 15 | ==Abstract== 16 | 17 | This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]]. 18 | 19 | ==Specification== 20 | 21 | ===Block Template=== 22 | 23 | The template Object is revised to include a new key: 24 | 25 | {| class="wikitable" 26 | !colspan=4| template 27 | |- 28 | ! Key !! Required !! Type !! Description 29 | |- 30 | | weightlimit || No || Number || total weight allowed in blocks 31 | |} 32 | 33 | The '!' rule prefix MUST be enabled on the "segwit" rule for templates including transactions with witness data. 34 | In particular, note that even if the client's "rules" list lacks "segwit", server MAY support old miners by producing a witness-free template and omitting the '!' rule prefix for "segwit" in the template's "rules" list. 35 | If the GBT server does not support producing witness-free templates after its activation, it must also use the '!' rule prefix in the "vbavailable" list prior to activation. 36 | 37 | ====Transactions Object Format==== 38 | 39 | The Objects listed in the response's "transactions" key is revised to include these keys: 40 | 41 | {| class="wikitable" 42 | !colspan=3|template "transactions" element 43 | |- 44 | ! Key !! Type !! Description 45 | |- 46 | | txid || String || transaction id encoded in hexadecimal; required for transactions with witness data 47 | |- 48 | | weight || Number || numeric weight of the transaction, as counted for purposes of the block's weightlimit; if key is not present, weight is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves 49 | |- 50 | | hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal 51 | |} 52 | 53 | Transactions with witness data may only be included if the template's "rules" list (see [[bip-0009.mediawiki#getblocktemplate_changes|BIP 9]]) includes "segwit". 54 | 55 | ===Sigops=== 56 | 57 | For templates with "segwit" enabled as a rule, the "sigoplimit" and "sigops" keys must use the new values as calculated in [[bip-0141.mediawiki#Sigops|BIP 141]]. 58 | 59 | ===Block Assembly with Witness Transactions=== 60 | 61 | When block assembly is done without witness transactions, no changes are made by this BIP, and it should be assembled as previously. 62 | 63 | When witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' "txid" field instead of "hash". A secondary merkle root MUST be calculated as per [[bip-0141.mediawiki#Commitment_structure|BIP 141's commitment structure specification]] to be inserted into the generation (coinbase) transaction. 64 | 65 | Servers MUST NOT include a commitment in the "coinbasetxn" key on the template. Clients MUST insert the commitment as an additional output at the end of the final generation (coinbase) transaction. Only if the template includes a "mutable" key (see [[bip-0023.mediawiki#Mutations|BIP 23 Mutations]]) including "generation", the client MAY in that case place the commitment output in any position it chooses, provided that no later output matches the commitment pattern. 66 | 67 | ==Motivation== 68 | 69 | Segregated witness substantially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient. 70 | It additionally also adds a new way of counting resource limits, and so GBT must be extended to convey this information correctly as well. 71 | 72 | ==Rationale== 73 | 74 | Why doesn't "weightlimit" simply redefine the existing "sizelimit"? 75 | * "sizelimit" is already enforced by clients by counting the sum of bytes in transactions' "data" keys. 76 | * Servers may wish to limit the overall size of a block, independently from the "weight" of the block. 77 | 78 | Why is "sigoplimit" redefined instead of a new "sigopweightlimit" being added? 79 | * The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop weight" is merely a change in the arbitrary formula used. 80 | 81 | Why is "sigoplimit" divided by 4? 82 | * To resemble the previous values. (FIXME: is this a good reason? maybe we shouldn't divide it?) 83 | 84 | Why is the witness commitment required to be added to the end of the generation transaction rather than anywhere else? 85 | * Servers which do not allow modification of the generation outputs ought to be checking this as part of the validity of submissions. By requiring a specific placement, they can simply strip the commitment and do a byte-for-byte comparison of the outputs. Placing it at the end avoids the possibility of a later output matching the pattern and overriding it. 86 | 87 | Why shouldn't the server simply add the commitment upfront in the "coinbasetxn", and simply send the client stripped transaction data? 88 | * It would become impossible for servers to specify only "coinbasevalue", since clients would no longer have the information required to construct the commitment. 89 | * getblocktemplate is intended to be a *decentralised* mining protocol, and allowing clients to be blinded to the content of the block works contrary to that purpose. 90 | * BIP 23's "transactions" mutations allow the client to modify the transaction-set on their own, which is impossible without the complete transaction data. 91 | 92 | ==Reference Implementation== 93 | 94 | * [https://github.com/bitcoin/libblkmaker/tree/segwit libblkmaker] 95 | * [https://github.com/luke-jr/eloipool/tree/segwit Eloipool] 96 | * [https://github.com/bitcoin/bitcoin/pull/7404/files Bitcoin Core] 97 | 98 | ==See Also== 99 | * [[bip-0009.mediawiki|BIP 9: Version bits with timeout and delay]] 100 | * [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]] 101 | * [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]] 102 | * [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]] 103 | 104 | ==Copyright== 105 | 106 | This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. 107 | -------------------------------------------------------------------------------- /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/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0152/protocol-flow.png -------------------------------------------------------------------------------- /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: Draft
 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 allow pruned peers to signal their limited services 17 | 18 | ==Motivation== 19 | 20 | Pruned peers can offer the same services as traditional peer except of serving all historical blocks. 21 | Bitcoin right now only offers the NODE_NETWORK service bit which indicates that a peer can serve 22 | all historical blocks. 23 | # Pruned peers can relay blocks, headers, transactions, addresses and can serve a limited number of historical blocks, thus they should have a way how to announce their service(s) 24 | # Peers no longer in initial block download should consider connecting some of its 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 | 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. 38 | 39 | === Address relay === 40 | 41 | Full nodes following this BIP SHOULD relay address/services (addr message) from peers they would connect to (including peers signaling NODE_NETWORK_LIMITED). 42 | 43 | === Counter-measures for peer fingerprinting === 44 | 45 | Peers may have different prune depths (depending on the peers configuration, disk space, etc.) which can result in a fingerprinting weakness (finding the prune depth through getdata requests). NODE_NETWORK_LIMITED supporting peers SHOULD avoid leaking the prune depth and therefore not serve blocks deeper than the signaled NODE_NETWORK_LIMITED threshold (244 blocks). 46 | 47 | === Risks === 48 | 49 | Pruned peers following this BIP may consume more outbound bandwidth. 50 | 51 | Light clients (and such) who are not checking the nServiceFlags (service bits) from a relayed addr-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling NODE_NETWORK_LIMITED if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option. 52 | 53 | == Compatibility == 54 | 55 | This proposal is backward compatible. 56 | 57 | == Reference implementation == 58 | 59 | * https://github.com/bitcoin/bitcoin/pull/11740 (signaling) 60 | * https://github.com/bitcoin/bitcoin/pull/10387 (connection and relay) 61 | 62 | == Copyright == 63 | 64 | This BIP is licensed under the 2-clause BSD license. 65 | -------------------------------------------------------------------------------- /bip-0174/coinjoin-workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0174/coinjoin-workflow.png -------------------------------------------------------------------------------- /bip-0174/multisig-workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-0174/multisig-workflow.png -------------------------------------------------------------------------------- /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 | Additonally, 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) 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. -------------------------------------------------------------------------------- /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: Draft
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 42 | construct the script and P2SH address for the HTLC. 43 | * Victor sends funds to the P2SH address. 44 | * Either: 45 | ** Peggy spends the funds, and in doing so, reveals the preimage to Victor in the transaction; OR 46 | ** Victor recovers the funds after the timeout threshold. 47 | 48 | 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 49 | 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 50 | not enter the blockchain before Victor's but does reveal the preimage to Victor anyway. 51 | 52 | ==Motivation== 53 | 54 | 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 55 | 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 56 | opportunity that the possessor of a secret has to receive the funds before such a refund can occur. 57 | 58 | ===Lightning network=== 59 | 60 | In the lightning network, HTLC scripts are used to perform atomic swaps between payment channels. 61 | 62 | 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 63 | 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 64 | at any point some parties become uncooperative, the process can be aborted via the refund conditions. 65 | 66 | ===Zero-knowledge contingent payments=== 67 | 68 | Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a 69 | zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See 70 | [https://github.com/zcash/pay-to-sudoku pay-to-sudoku] for a concrete example of such a protocol.) 71 | 72 | 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. 73 | 74 | ==Implementation== 75 | 76 | https://github.com/bitcoin/bitcoin/pull/7601 77 | 78 | ==Copyright== 79 | 80 | This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. 81 | 82 | -------------------------------------------------------------------------------- /bip-dandelion/1-dandelion.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-dandelion/1-dandelion.png -------------------------------------------------------------------------------- /bip-dandelion/2-attack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-dandelion/2-attack.png -------------------------------------------------------------------------------- /bip-dandelion/3-attack-plot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-dandelion/3-attack-plot.png -------------------------------------------------------------------------------- /bip-dandelion/4-dandelion-plot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-dandelion/4-dandelion-plot.png -------------------------------------------------------------------------------- /bip-dandelion/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-dandelion/dandelion-debug-logs-example.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-dandelion/dandelion-debug-logs-example.pdf -------------------------------------------------------------------------------- /bip-dandelion/dandelion-reference-documentation.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dandelion-org/bips/e07ece38aa299964d6f1c7a9e18d0aba6f733441/bip-dandelion/dandelion-reference-documentation.pdf --------------------------------------------------------------------------------