diff options
65 files changed, 6373 insertions, 96 deletions
diff --git a/README.mediawiki b/README.mediawiki index 3ffa466..c8431d2 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -2,7 +2,7 @@ People wishing to submit BIPs, first should propose their idea or document to th We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. -Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community. +Having a BIP here does not make it a formally accepted standard until its status becomes Final or Active. Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority]). @@ -27,6 +27,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Luke Dashjr | Process | Active +|- +| [[bip-0008.mediawiki|8]] +| +| Version bits with lock-in by height +| Shaolin Fry +| Informational +| Draft |- style="background-color: #cfffcf" | [[bip-0009.mediawiki|9]] | @@ -406,6 +413,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Suhas Daftuar | Informational | Draft +|- style="background-color: #cfffcf" +| [[bip-0091.mediawiki|91]] +| Consensus (soft fork) +| Reduced threshold Segwit MASF +| James Hilliard +| Standard +| Final |- | [[bip-0099.mediawiki|99]] | @@ -435,6 +449,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0104.mediawiki|104]] +| Consensus (hard fork) +| 'Block75' - Max block size like difficulty +| t.khan +| Standard +| Draft +|- | [[bip-0105.mediawiki|105]] | Consensus (hard fork) | Consensus based block size retargeting algorithm @@ -491,6 +512,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0115.mediawiki|115]] +| Consensus (soft fork) +| Generic anti-replay protection using Script +| Luke Dashjr +| Standard +| Draft +|- | [[bip-0120.mediawiki|120]] | Applications | Proof of Payment @@ -575,47 +603,54 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0135.mediawiki|135]] +| +| Generalized version bits voting +| Sancho Panza +| Informational +| Draft +|- | [[bip-0140.mediawiki|140]] | Consensus (soft fork) | Normalized TXID | Christian Decker | Standard | Draft -|- +|- style="background-color: #ffffcf" | [[bip-0141.mediawiki|141]] | Consensus (soft fork) | Segregated Witness (Consensus layer) | Eric Lombrozo, Johnson Lau, Pieter Wuille | Standard -| Draft -|- +| Proposed +|- style="background-color: #ffcfcf" | [[bip-0142.mediawiki|142]] | Applications | Address Format for Segregated Witness | Johnson Lau | Standard -| Deferred -|- +| Withdrawn +|- style="background-color: #ffffcf" | [[bip-0143.mediawiki|143]] | Consensus (soft fork) | Transaction Signature Verification for Version 0 Witness Program | Johnson Lau, Pieter Wuille | Standard -| Draft -|- +| Proposed +|- style="background-color: #ffffcf" | [[bip-0144.mediawiki|144]] | Peer Services | Segregated Witness (Peer Services) | Eric Lombrozo, Pieter Wuille | Standard -| Draft -|- +| Proposed +|- style="background-color: #cfffcf" | [[bip-0145.mediawiki|145]] | API/RPC | getblocktemplate Updates for Segregated Witness | Luke Dashjr | Standard -| Draft +| Final |- | [[bip-0146.mediawiki|146]] | Consensus (soft fork) @@ -623,13 +658,27 @@ Those proposing changes should consider that ultimately consent may rest with th | Johnson Lau, Pieter Wuille | Standard | Draft -|- +|- style="background-color: #ffffcf" | [[bip-0147.mediawiki|147]] | Consensus (soft fork) | Dealing with dummy stack element malleability | Johnson Lau | Standard -| Draft +| Proposed +|- style="background-color: #cfffcf" +| [[bip-0148.mediawiki|148]] +| Consensus (soft fork) +| Mandatory activation of segwit deployment +| Shaolin Fry +| Standard +| Final +|- style="background-color: #ffcfcf" +| [[bip-0149.mediawiki|149]] +| Consensus (soft fork) +| Segregated Witness (second deployment) +| Shaolin Fry +| Standard +| Withdrawn |- | [[bip-0150.mediawiki|150]] | Peer Services @@ -651,6 +700,62 @@ Those proposing changes should consider that ultimately consent may rest with th | Matt Corallo | Standard | Draft +|- +| [[bip-0154.mediawiki|154]] +| Peer Services +| Rate Limiting via peer specified challenges +| Karl-Johan Alm +| Standard +| Draft +|- +| [[bip-0159.mediawiki|159]] +| Peer Services +| NODE_NETWORK_LIMITED service bit +| Jonas Schnelli +| Standard +| Draft +|- +| [[bip-0171.mediawiki|171]] +| Applications +| Currency/exchange rate information API +| Luke Dashjr +| Standard +| Draft +|- +| [[bip-0173.mediawiki|173]] +| Applications +| Base32 address format for native v0-16 witness outputs +| Pieter Wuille, Greg Maxwell +| Informational +| Draft +|- +| [[bip-0174.mediawiki|174]] +| Applications +| Partially Signed Bitcoin Transaction Format +| Andrew Chow +| Standard +| Draft +|- +| [[bip-0175.mediawiki|175]] +| Applications +| Pay to Contract Protocol +| Omar Shibli, Nicholas Gregory +| Informational +| Draft +|- +| [[bip-0180.mediawiki|180]] +| Peer Services +| Block size/weight fraud proof +| Luke Dashjr +| Standard +| Draft +|- +| [[bip-0199.mediawiki|199]] +| Applications +| Hashed Time-Locked Contract transactions +| Sean Bowe, Daira Hopwood +| Standard +| Draft |} <!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --> diff --git a/bip-0002/process.png b/bip-0002/process.png Binary files differindex a834947..b532799 100644 --- a/bip-0002/process.png +++ b/bip-0002/process.png diff --git a/bip-0002/process.svg b/bip-0002/process.svg index efaa02b..7bfbe7a 100644 --- a/bip-0002/process.svg +++ b/bip-0002/process.svg @@ -1,4 +1,4 @@ -<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 526 206" width="526" height="206"> +<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 720 206" width="720" height="206"> <defs> <style type="text/css"><![CDATA[ rect { @@ -20,7 +20,7 @@ <path d="M0,2 L0,11 L8,6 L0,2" style="fill: black;" /> </marker> </defs> - + <rect x="8" y="8" width="128" height="32"/> <text x="72" y="32" font-size="20" text-anchor="middle">Draft</text> <path d="M136,24 L200,24"/> @@ -32,18 +32,22 @@ <path d="M456,40 L456,80"/> <rect x="392" y="80" width="128" height="32"/> <text x="456" y="104" font-size="20" text-anchor="middle">Replaced</text> - + <path d="M120,40 L120,72 L200,72"/> <rect x="200" y="56" width="128" height="32"/> <text x="264" y="80" font-size="20" text-anchor="middle">Rejected</text> <path d="M328,32 L360,32 L360,72 L328,72" stroke-dasharray="4, 2"/> - + <path d="M88,40 L88,120 L200,120"/> <rect x="200" y="104" width="128" height="32"/> <text x="264" y="128" font-size="20" text-anchor="middle">Withdrawn</text> - + <path d="M24,40 L24,166"/> <rect x="8" y="166" width="128" height="32"/> <text x="72" y="190" font-size="20" text-anchor="middle">Deferred</text> <path d="M56,166 L56,40"/> + + <path d="M520,24 L584,24"/> + <rect x="584" y="8" width="128" height="32"/> + <text x="648" y="32" font-size="20" text-anchor="middle">Obsolete</text> </svg> diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki new file mode 100644 index 0000000..9840bed --- /dev/null +++ b/bip-0008.mediawiki @@ -0,0 +1,213 @@ +<pre> + BIP: 8 + Title: Version bits with lock-in by height + Author: Shaolin Fry <shaolinfry@protonmail.ch> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0008 + Status: Draft + Type: Informational + Created: 2017-02-01 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This document specifies an alteration to [[bip-0009.mediawiki|BIP9]] that replaces time based activation with block height, as well as guaranteed activation of backward-compatible changes (further called "soft forks"). + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + +==Motivation== + +BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide eventual flag day activation after a reasonable time (recommended a year), as well as for accelerated activation by majority of hash rate before the flag date. + +Block time is somewhat unreliable and may be intentionally or unintentionally inaccurate, so thresholds based on block time are not ideal. Secondly, BIP9 specified triggers based on the first retarget after a given time, which is non-intuitive. Since each new block must increase the height by one, thresholds based on block height are much more reliable and intuitive and can be calculated exactly for difficulty retarget. + +==Specification== + +===Summary=== + +This specification is the same as [[bip-0009.mediawiki|BIP9]] except that MTP time based threshold are replaced with block height, and the state machine has no FAILED condition. The state transition from '''STARTED''' to '''LOCKED_IN''' will occur under two condition: + +The first is when the threshold of blocks signalling is reached as per BIP9, before '''LOCKED_IN''' state has been reached. The second condition is when the block height reaches the timeout block height while still being in the '''STARTED''' state. + +===Parameters=== + +Each soft fork deployment is specified by the following per-chain parameters (further elaborated below): + +# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number. +# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}. +# The '''startheight''' specifies a minimum block height at which a block at which the bit gains its meaning. +# The '''timeoutheight''' specifies a block height at which the deployment should lock-in if not already locked in or activated. + +===Selection guidelines=== + +The following guidelines are suggested for selecting these parameters for a soft fork: + +# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. +# '''bit''' should be selected such that no two concurrent softforks use the same bit. +# '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) after a software release date including the soft fork. This allows for some release delays, while preventing triggers as a result of parties running pre-release software. The startheight should be a retarget block height for simplicity. +# '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''. + +A later deployment using the same bit is possible as long as the startheight is after the previous one's timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software. + +===States=== + +With each block and soft fork, we associate a deployment state. The possible states are: + +# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment. +# '''STARTED''' for blocks past the startheight. +# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion. +# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period. +# '''FAILED''' if block height is greater than or equal to timeoutheight during the DEFINED state. + +===Bit flags=== + +The nVersion block header field is to be interpreted as a 32-bit little-endian integer (as present), and bits are selected within this integer as values (1 << N) where N is the bit number. + +Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. + +Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available. This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011). When a block nVersion does not have top bits 001, it is treated as if all bits are 0 for the purposes of deployments. + +Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on consensus rules. + +===New consensus rules=== + +The new consensus rules for each soft fork are enforced for each block that has ACTIVE state. + +===State transitions=== + +<img src="bip-0008/states.png" align="middle"></img> + +The genesis block has state DEFINED for each deployment, by definition. + + State GetStateForBlock(block) { + if (block.height == 0) { + return DEFINED; + } + +All blocks within a retarget period have the same state. This means that if floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for every deployment. + + if ((block.height % 2016) != 0) { + return GetStateForBlock(block.parent); + } + +Otherwise, the next state depends on the previous state: + + switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) { + +We remain in the initial state until either we pass the start block height or the timeout height. + + case DEFINED: + if (block.height >= timeoutheight) { + return FAILED; + } + if (block.height >= startheight) { + return STARTED; + } + return DEFINED; + +After a period in the STARTED state, if we're past the timeout, we switch to LOCKED_IN. If not, we tally the bits set, +and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their +version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016). + +There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the +other one simultaneously transitions to STARTED, which would mean both would demand setting the bit. + +Note that a block's state never depends on its own nVersion; only on that of its ancestors. + + case STARTED: + if (block.height >= timeoutheight) + return LOCKED_IN; + + int count = 0; + walk = block; + for (i = 0; i < 2016; i++) { + walk = walk.parent; + if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) { + count++; + } + } + if (count >= threshold) { + return LOCKED_IN; + } + return STARTED; + +After a retarget period of LOCKED_IN, we automatically transition to ACTIVE. + + case LOCKED_IN: + return ACTIVE; + +And ACTIVE is terminal a state, which a deployment stays in once reached. + + case ACTIVE: + return ACTIVE; + } + +'''Implementation''' +It should be noted that the states are maintained along block chain branches, but may need recomputation when a reorganization happens. + +Given that the state for a specific block/deployment combination is completely determined by its ancestry before the current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)), it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016 block, indexed by its parent. + +===Warning mechanism=== + +To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state). + +===getblocktemplate changes=== + +The template request Object is extended to include a new item: + +{| class="wikitable" +!colspan=4| template request +|- +! Key !! Required !! Type !! Description +|- +| rules || No || Array of Strings || list of supported softfork deployments, by name +|} + +The template Object is also extended: + +{| class="wikitable" +!colspan=4| template +|- +! Key !! Required !! Type !! Description +|- +| rules || Yes || Array of Strings || list of softfork deployments, by name, that are active state +|- +| vbavailable || Yes || Object || set of pending, supported softfork deployments; each uses the softfork name as the key, and the softfork bit as its value +|- +| vbrequired || No || Number || bit mask of softfork deployment version bits the server requires enabled in submissions +|} + +The "version" key of the template is retained, and used to indicate the server's preference of deployments. +If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF]. +Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". + +Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character. +Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113. +If a client does not understand a rule without the prefix, it may use it unmodified for mining. +On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction). +A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified. + +=== Reference implementation === + +https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip8-height + +==Backwards compatibility== + +BIP8 and BIP9 deployments should not share concurrent active deployment bits. Nodes that only implement BIP9 will not activate a BIP8 soft fork if hashpower threshold is not reached by '''timeout''', however, those nodes will still accept the blocks generated by activated nodes. + +==Deployments== + +A living list of deployment proposals can be found [[bip-0008/assignments.mediawiki|here]]. + +==References== + +[[bip-0009.mediawiki|BIP9]] + +[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html Mailing list discussion] + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. + diff --git a/bip-0008/assignments.mediawiki b/bip-0008/assignments.mediawiki new file mode 100644 index 0000000..c18751b --- /dev/null +++ b/bip-0008/assignments.mediawiki @@ -0,0 +1,6 @@ +==Deployments== + +List of deployments. + +State can be defined, active, failed. Dates are in UTC. + diff --git a/bip-0008/states.png b/bip-0008/states.png Binary files differnew file mode 100644 index 0000000..13fae23 --- /dev/null +++ b/bip-0008/states.png diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 11e3505..a68bb80 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -113,7 +113,7 @@ referred to as MTP in the diagram above, and is treated as a monotonic clock def After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set, and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016). -The transition to FAILED takes precendence, as otherwise an ambiguity can arise. +The transition to FAILED takes precedence, as otherwise an ambiguity can arise. There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the other one simultaneously transitions to STARTED, which would mean both would demand setting the bit. diff --git a/bip-0013.mediawiki b/bip-0013.mediawiki index 9805ed0..081ea2a 100644 --- a/bip-0013.mediawiki +++ b/bip-0013.mediawiki @@ -14,7 +14,7 @@ This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin. -In essence, an address encoded under this proposal represents the encoded hash of a [[script]], rather than the encoded hash of an ECDSA public key. +In essence, an address encoded under this proposal represents the encoded hash of a [https://en.bitcoin.it/wiki/Script script], rather than the encoded hash of an ECDSA public key. ==Motivation== @@ -22,7 +22,7 @@ Enable "end-to-end" secure wallets and payments to fund escrow transactions or o ==Specification== -The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [[Base58Check encoding]]): +The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [https://en.bitcoin.it/Base58Check_encoding Base58Check encoding]): base58-encode: [one-byte version][20-byte hash][4-byte checksum] diff --git a/bip-0019.mediawiki b/bip-0019.mediawiki index 99462b7..744b97a 100644 --- a/bip-0019.mediawiki +++ b/bip-0019.mediawiki @@ -46,7 +46,7 @@ But only for n less than or equal to 3. These transactions are redeemed using a standard scriptSig: ...signatures... -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. +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. ===Templates=== scriptPubKey: diff --git a/bip-0030.mediawiki b/bip-0030.mediawiki index 56ef3de..b653ba6 100644 --- a/bip-0030.mediawiki +++ b/bip-0030.mediawiki @@ -8,10 +8,15 @@ Status: Final Type: Standards Track Created: 2012-02-22 + License: BSD-2-Clause </pre> ==Abstract== -This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementations has with them. +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. + +==Copyright== + +This BIP is licensed under the 2-clause BSD license. ==Motivation== 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. diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 50964a2..ab6ff9e 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -1,4 +1,5 @@ RECENT CHANGES: +* (24 Feb 2017) Added test vectors for hardened derivation with leading zeros * (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage) * (30 Apr 2013) Switched from multiplication by I<sub>L</sub> to addition of I<sub>L</sub> (faster, easier implementation) * (25 May 2013) Added test vectors @@ -14,6 +15,7 @@ RECENT CHANGES: Status: Final Type: Informational Created: 2012-02-11 + License: BSD-2-Clause </pre> ==Abstract== @@ -24,6 +26,10 @@ The specification is intended to set a standard for deterministic wallets that c The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree. +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + ==Motivation== The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such "neutered" wallets lose the power to generate public keys as well. @@ -116,7 +122,7 @@ Each leaf node in the tree corresponds to an actual key, while the internal node ===Key identifiers=== -Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized ECSDA public key K, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself). +Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized ECDSA public key K, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself). The first 32 bits of the identifier are called the key fingerprint. @@ -150,7 +156,7 @@ In case I<sub>L</sub> is 0 or ≥n, the master key is invalid. ==Specification: Wallet structure== -The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimick it for compatibility, even if not all features are supported. +The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimic it for compatibility, even if not all features are supported. ===The default wallet layout=== @@ -254,6 +260,18 @@ Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c ** ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt ** ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j +===Test vector 3=== + +These vectors test for the retention of leading zeros. See [https://github.com/bitpay/bitcore-lib/issues/47 bitpay/bitcore-lib#47] and [https://github.com/iancoleman/bip39/issues/58 iancoleman/bip39#58] for more information. + +Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45d239319ac14f863b8d5ab5a0d0c64d2e8a1e7d1457df2e5a3c51c73235be +* Chain m +** ext pub: xpub661MyMwAqRbcEZVB4dScxMAdx6d4nFc9nvyvH3v4gJL378CSRZiYmhRoP7mBy6gSPSCYk6SzXPTf3ND1cZAceL7SfJ1Z3GC8vBgp2epUt13 +** ext prv: xprv9s21ZrQH143K25QhxbucbDDuQ4naNntJRi4KUfWT7xo4EKsHt2QJDu7KXp1A3u7Bi1j8ph3EGsZ9Xvz9dGuVrtHHs7pXeTzjuxBrCmmhgC6 +* Chain m/0<sub>H</sub> +** ext pub: xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y +** ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L + ==Implementations== Two Python implementations exist: @@ -274,7 +292,7 @@ hdkeychain (https://github.com/conformal/btcutil/tree/master/hdkeychain) provide Two JavaScript implementations exist: available at https://github.com/sarchar/brainwallet.github.com/tree/bip32 and https://github.com/bitpay/bitcore -A PHP implemetation is available at https://github.com/Bit-Wasp/bitcoin-lib-php +A PHP implementation is available at https://github.com/Bit-Wasp/bitcoin-lib-php A C# implementation is available at https://github.com/NicolasDorier/NBitcoin (ExtKey, ExtPubKey) diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index e1e3558..bfe1f4a 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -4,7 +4,7 @@ Title: Passphrase-protected private key Author: Mike Caldwell <mcaldwell@swipeclock.com> Aaron Voisine <voisine@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0038 Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion) Type: Standards Track diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 4a6b41e..2fad971 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -6,7 +6,7 @@ Pavol Rusnak <stick@satoshilabs.com> Aaron Voisine <voisine@gmail.com> Sean Bowe <ewillbefull@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039 Status: Proposed Type: Standards Track @@ -25,7 +25,7 @@ BIP-0032 or similar methods. ==Motivation== A mnemonic code or sentence is superior for human interaction compared to the -handling of raw binary or hexidecimal representations of a wallet seed. The +handling of raw binary or hexadecimal representations of a wallet seed. The sentence could be written on paper or spoken over the telephone. This guide is meant to be a way to transport computer-generated randomness with @@ -134,6 +134,9 @@ http://github.com/trezor/python-mnemonic ==Other Implementations== +Elixir: +* https://github.com/izelnakri/mnemonic + Objective-C: * https://github.com/nybex/NYMnemonic @@ -152,3 +155,15 @@ JavaScript: Ruby: * https://github.com/sreekanthgs/bip_mnemonic + +Rust: +* https://github.com/infincia/bip39-rs + +Swift: +* https://github.com/CikeQiu/CKMnemonic + +C++: +* https://github.com/libbitcoin/libbitcoin/blob/master/include/bitcoin/bitcoin/wallet/mnemonic.hpp + +C (with Python/Java/Javascript bindings): +* https://github.com/ElementsProject/libwally-core diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index aef1a23..635b901 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/bip-0039/bip-0039-wordlists.md @@ -1,29 +1,30 @@ -#Wordlists +# Wordlists * [English](english.txt) * [Japanese](japanese.txt) +* [Korean](korean.txt) * [Spanish](spanish.txt) * [Chinese (Simplified)](chinese_simplified.txt) * [Chinese (Traditional)](chinese_traditional.txt) * [French](french.txt) * [Italian](italian.txt) -##Wordlists (Special Considerations) +## Wordlists (Special Considerations) -###Japanese +### Japanese -1. **Developers implementing phrase generation or checksum verification must separate words using ideographic spaces / accommodate users inputting ideographic spaces.** -(UTF-8 bytes: **0xE38080**; C/C+/Java: **"\u3000"**; Python: **u"\u3000"**) +1. **Developers implementing phrase generation or checksum verification must separate words using ideographic spaces / accommodate users inputting ideographic spaces.** +(UTF-8 bytes: **0xE38080**; C/C+/Java: **"\u3000"**; Python: **u"\u3000"**) However, code that only accepts Japanese phrases but does not generate or verify them should be fine as is. This is because when generating the seed, normalization as per the spec will automatically change the ideographic spaces into normal ASCII spaces, so as long as your code never shows the user an ASCII space separated phrase or tries to split the phrase input by the user, dealing with ASCII or Ideographic space is the same. -2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the -ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily +2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the +ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily for two smaller words (This would be a problem with any of the 3 character sets in Japanese) -###Spanish +### Spanish 1. Words can be uniquely determined typing the first 4 characters (sometimes less). @@ -31,19 +32,19 @@ for two smaller words (This would be a problem with any of the 3 character sets 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. -###Chinese +### Chinese 1. Chinese text typically does not use any spaces as word separators. For the sake of uniformity, we propose to use normal ASCII spaces (0x20) to separate words as per standard. -###French +### French Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch ([The pull request](https://github.com/bitcoin/bips/issues/152)) -1. High priority on simple and common french words. +1. High priority on simple and common French words. 2. Only words with 5-8 letters. -3. A word is fully recognizable by typing the first 4 letters (special french characters "é-è" are considered equal to "e", for exemple "museau" and "musée" can not be together). +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). 4. Only infinitive verbs, adjectives and nouns. 5. No pronouns, no adverbs, no prepositions, no conjunctions, no interjections (unless a noun/adjective is also popular than its interjection like "mince;chouette"). 6. No numeral adjectives. @@ -65,7 +66,7 @@ Credits: @paoloaga @Polve Words chosen using the following rules: -1. Simple and common italian words. +1. Simple and common Italian words. 2. Length between 4 and 8 characters. 3. First 4 letters must be unique between all words. 4. No accents or special characters. @@ -76,8 +77,8 @@ Words chosen using the following rules: 9. No words with double vocals (like: lineetta). 10. No words already used in other language mnemonic sets. 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. -12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there not must be the same sequence of 3 or more letters. +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. -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. +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. All the words have been manually selected and automatically checked against the rules. diff --git a/bip-0039/korean.txt b/bip-0039/korean.txt new file mode 100644 index 0000000..1acebf7 --- /dev/null +++ b/bip-0039/korean.txt @@ -0,0 +1,2048 @@ +가격 +가끔 +가난 +가능 +가득 +가르침 +가뭄 +가방 +가상 +가슴 +가운데 +가을 +가이드 +가입 +가장 +가정 +가족 +가죽 +각오 +각자 +간격 +간부 +간섭 +간장 +간접 +간판 +갈등 +갈비 +갈색 +갈증 +감각 +감기 +감소 +감수성 +감자 +감정 +갑자기 +강남 +강당 +강도 +강력히 +강변 +강북 +강사 +강수량 +강아지 +강원도 +강의 +강제 +강조 +같이 +개구리 +개나리 +개방 +개별 +개선 +개성 +개인 +객관적 +거실 +거액 +거울 +거짓 +거품 +걱정 +건강 +건물 +건설 +건조 +건축 +걸음 +검사 +검토 +게시판 +게임 +겨울 +견해 +결과 +결국 +결론 +결석 +결승 +결심 +결정 +결혼 +경계 +경고 +경기 +경력 +경복궁 +경비 +경상도 +경영 +경우 +경쟁 +경제 +경주 +경찰 +경치 +경향 +경험 +계곡 +계단 +계란 +계산 +계속 +계약 +계절 +계층 +계획 +고객 +고구려 +고궁 +고급 +고등학생 +고무신 +고민 +고양이 +고장 +고전 +고집 +고춧가루 +고통 +고향 +곡식 +골목 +골짜기 +골프 +공간 +공개 +공격 +공군 +공급 +공기 +공동 +공무원 +공부 +공사 +공식 +공업 +공연 +공원 +공장 +공짜 +공책 +공통 +공포 +공항 +공휴일 +과목 +과일 +과장 +과정 +과학 +관객 +관계 +관광 +관념 +관람 +관련 +관리 +관습 +관심 +관점 +관찰 +광경 +광고 +광장 +광주 +괴로움 +굉장히 +교과서 +교문 +교복 +교실 +교양 +교육 +교장 +교직 +교통 +교환 +교훈 +구경 +구름 +구멍 +구별 +구분 +구석 +구성 +구속 +구역 +구입 +구청 +구체적 +국가 +국기 +국내 +국립 +국물 +국민 +국수 +국어 +국왕 +국적 +국제 +국회 +군대 +군사 +군인 +궁극적 +권리 +권위 +권투 +귀국 +귀신 +규정 +규칙 +균형 +그날 +그냥 +그늘 +그러나 +그룹 +그릇 +그림 +그제서야 +그토록 +극복 +극히 +근거 +근교 +근래 +근로 +근무 +근본 +근원 +근육 +근처 +글씨 +글자 +금강산 +금고 +금년 +금메달 +금액 +금연 +금요일 +금지 +긍정적 +기간 +기관 +기념 +기능 +기독교 +기둥 +기록 +기름 +기법 +기본 +기분 +기쁨 +기숙사 +기술 +기억 +기업 +기온 +기운 +기원 +기적 +기준 +기침 +기혼 +기획 +긴급 +긴장 +길이 +김밥 +김치 +김포공항 +깍두기 +깜빡 +깨달음 +깨소금 +껍질 +꼭대기 +꽃잎 +나들이 +나란히 +나머지 +나물 +나침반 +나흘 +낙엽 +난방 +날개 +날씨 +날짜 +남녀 +남대문 +남매 +남산 +남자 +남편 +남학생 +낭비 +낱말 +내년 +내용 +내일 +냄비 +냄새 +냇물 +냉동 +냉면 +냉방 +냉장고 +넥타이 +넷째 +노동 +노란색 +노력 +노인 +녹음 +녹차 +녹화 +논리 +논문 +논쟁 +놀이 +농구 +농담 +농민 +농부 +농업 +농장 +농촌 +높이 +눈동자 +눈물 +눈썹 +뉴욕 +느낌 +늑대 +능동적 +능력 +다방 +다양성 +다음 +다이어트 +다행 +단계 +단골 +단독 +단맛 +단순 +단어 +단위 +단점 +단체 +단추 +단편 +단풍 +달걀 +달러 +달력 +달리 +닭고기 +담당 +담배 +담요 +담임 +답변 +답장 +당근 +당분간 +당연히 +당장 +대규모 +대낮 +대단히 +대답 +대도시 +대략 +대량 +대륙 +대문 +대부분 +대신 +대응 +대장 +대전 +대접 +대중 +대책 +대출 +대충 +대통령 +대학 +대한민국 +대합실 +대형 +덩어리 +데이트 +도대체 +도덕 +도둑 +도망 +도서관 +도심 +도움 +도입 +도자기 +도저히 +도전 +도중 +도착 +독감 +독립 +독서 +독일 +독창적 +동화책 +뒷모습 +뒷산 +딸아이 +마누라 +마늘 +마당 +마라톤 +마련 +마무리 +마사지 +마약 +마요네즈 +마을 +마음 +마이크 +마중 +마지막 +마찬가지 +마찰 +마흔 +막걸리 +막내 +막상 +만남 +만두 +만세 +만약 +만일 +만점 +만족 +만화 +많이 +말기 +말씀 +말투 +맘대로 +망원경 +매년 +매달 +매력 +매번 +매스컴 +매일 +매장 +맥주 +먹이 +먼저 +먼지 +멀리 +메일 +며느리 +며칠 +면담 +멸치 +명단 +명령 +명예 +명의 +명절 +명칭 +명함 +모금 +모니터 +모델 +모든 +모범 +모습 +모양 +모임 +모조리 +모집 +모퉁이 +목걸이 +목록 +목사 +목소리 +목숨 +목적 +목표 +몰래 +몸매 +몸무게 +몸살 +몸속 +몸짓 +몸통 +몹시 +무관심 +무궁화 +무더위 +무덤 +무릎 +무슨 +무엇 +무역 +무용 +무조건 +무지개 +무척 +문구 +문득 +문법 +문서 +문제 +문학 +문화 +물가 +물건 +물결 +물고기 +물론 +물리학 +물음 +물질 +물체 +미국 +미디어 +미사일 +미술 +미역 +미용실 +미움 +미인 +미팅 +미혼 +민간 +민족 +민주 +믿음 +밀가루 +밀리미터 +밑바닥 +바가지 +바구니 +바나나 +바늘 +바닥 +바닷가 +바람 +바이러스 +바탕 +박물관 +박사 +박수 +반대 +반드시 +반말 +반발 +반성 +반응 +반장 +반죽 +반지 +반찬 +받침 +발가락 +발걸음 +발견 +발달 +발레 +발목 +발바닥 +발생 +발음 +발자국 +발전 +발톱 +발표 +밤하늘 +밥그릇 +밥맛 +밥상 +밥솥 +방금 +방면 +방문 +방바닥 +방법 +방송 +방식 +방안 +방울 +방지 +방학 +방해 +방향 +배경 +배꼽 +배달 +배드민턴 +백두산 +백색 +백성 +백인 +백제 +백화점 +버릇 +버섯 +버튼 +번개 +번역 +번지 +번호 +벌금 +벌레 +벌써 +범위 +범인 +범죄 +법률 +법원 +법적 +법칙 +베이징 +벨트 +변경 +변동 +변명 +변신 +변호사 +변화 +별도 +별명 +별일 +병실 +병아리 +병원 +보관 +보너스 +보라색 +보람 +보름 +보상 +보안 +보자기 +보장 +보전 +보존 +보통 +보편적 +보험 +복도 +복사 +복숭아 +복습 +볶음 +본격적 +본래 +본부 +본사 +본성 +본인 +본질 +볼펜 +봉사 +봉지 +봉투 +부근 +부끄러움 +부담 +부동산 +부문 +부분 +부산 +부상 +부엌 +부인 +부작용 +부장 +부정 +부족 +부지런히 +부친 +부탁 +부품 +부회장 +북부 +북한 +분노 +분량 +분리 +분명 +분석 +분야 +분위기 +분필 +분홍색 +불고기 +불과 +불교 +불꽃 +불만 +불법 +불빛 +불안 +불이익 +불행 +브랜드 +비극 +비난 +비닐 +비둘기 +비디오 +비로소 +비만 +비명 +비밀 +비바람 +비빔밥 +비상 +비용 +비율 +비중 +비타민 +비판 +빌딩 +빗물 +빗방울 +빗줄기 +빛깔 +빨간색 +빨래 +빨리 +사건 +사계절 +사나이 +사냥 +사람 +사랑 +사립 +사모님 +사물 +사방 +사상 +사생활 +사설 +사슴 +사실 +사업 +사용 +사월 +사장 +사전 +사진 +사촌 +사춘기 +사탕 +사투리 +사흘 +산길 +산부인과 +산업 +산책 +살림 +살인 +살짝 +삼계탕 +삼국 +삼십 +삼월 +삼촌 +상관 +상금 +상대 +상류 +상반기 +상상 +상식 +상업 +상인 +상자 +상점 +상처 +상추 +상태 +상표 +상품 +상황 +새벽 +색깔 +색연필 +생각 +생명 +생물 +생방송 +생산 +생선 +생신 +생일 +생활 +서랍 +서른 +서명 +서민 +서비스 +서양 +서울 +서적 +서점 +서쪽 +서클 +석사 +석유 +선거 +선물 +선배 +선생 +선수 +선원 +선장 +선전 +선택 +선풍기 +설거지 +설날 +설렁탕 +설명 +설문 +설사 +설악산 +설치 +설탕 +섭씨 +성공 +성당 +성명 +성별 +성인 +성장 +성적 +성질 +성함 +세금 +세미나 +세상 +세월 +세종대왕 +세탁 +센터 +센티미터 +셋째 +소규모 +소극적 +소금 +소나기 +소년 +소득 +소망 +소문 +소설 +소속 +소아과 +소용 +소원 +소음 +소중히 +소지품 +소질 +소풍 +소형 +속담 +속도 +속옷 +손가락 +손길 +손녀 +손님 +손등 +손목 +손뼉 +손실 +손질 +손톱 +손해 +솔직히 +솜씨 +송아지 +송이 +송편 +쇠고기 +쇼핑 +수건 +수년 +수단 +수돗물 +수동적 +수면 +수명 +수박 +수상 +수석 +수술 +수시로 +수업 +수염 +수영 +수입 +수준 +수집 +수출 +수컷 +수필 +수학 +수험생 +수화기 +숙녀 +숙소 +숙제 +순간 +순서 +순수 +순식간 +순위 +숟가락 +술병 +술집 +숫자 +스님 +스물 +스스로 +스승 +스웨터 +스위치 +스케이트 +스튜디오 +스트레스 +스포츠 +슬쩍 +슬픔 +습관 +습기 +승객 +승리 +승부 +승용차 +승진 +시각 +시간 +시골 +시금치 +시나리오 +시댁 +시리즈 +시멘트 +시민 +시부모 +시선 +시설 +시스템 +시아버지 +시어머니 +시월 +시인 +시일 +시작 +시장 +시절 +시점 +시중 +시즌 +시집 +시청 +시합 +시험 +식구 +식기 +식당 +식량 +식료품 +식물 +식빵 +식사 +식생활 +식초 +식탁 +식품 +신고 +신규 +신념 +신문 +신발 +신비 +신사 +신세 +신용 +신제품 +신청 +신체 +신화 +실감 +실내 +실력 +실례 +실망 +실수 +실습 +실시 +실장 +실정 +실질적 +실천 +실체 +실컷 +실태 +실패 +실험 +실현 +심리 +심부름 +심사 +심장 +심정 +심판 +쌍둥이 +씨름 +씨앗 +아가씨 +아나운서 +아드님 +아들 +아쉬움 +아스팔트 +아시아 +아울러 +아저씨 +아줌마 +아직 +아침 +아파트 +아프리카 +아픔 +아홉 +아흔 +악기 +악몽 +악수 +안개 +안경 +안과 +안내 +안녕 +안동 +안방 +안부 +안주 +알루미늄 +알코올 +암시 +암컷 +압력 +앞날 +앞문 +애인 +애정 +액수 +앨범 +야간 +야단 +야옹 +약간 +약국 +약속 +약수 +약점 +약품 +약혼녀 +양념 +양력 +양말 +양배추 +양주 +양파 +어둠 +어려움 +어른 +어젯밤 +어쨌든 +어쩌다가 +어쩐지 +언니 +언덕 +언론 +언어 +얼굴 +얼른 +얼음 +얼핏 +엄마 +업무 +업종 +업체 +엉덩이 +엉망 +엉터리 +엊그제 +에너지 +에어컨 +엔진 +여건 +여고생 +여관 +여군 +여권 +여대생 +여덟 +여동생 +여든 +여론 +여름 +여섯 +여성 +여왕 +여인 +여전히 +여직원 +여학생 +여행 +역사 +역시 +역할 +연결 +연구 +연극 +연기 +연락 +연설 +연세 +연속 +연습 +연애 +연예인 +연인 +연장 +연주 +연출 +연필 +연합 +연휴 +열기 +열매 +열쇠 +열심히 +열정 +열차 +열흘 +염려 +엽서 +영국 +영남 +영상 +영양 +영역 +영웅 +영원히 +영하 +영향 +영혼 +영화 +옆구리 +옆방 +옆집 +예감 +예금 +예방 +예산 +예상 +예선 +예술 +예습 +예식장 +예약 +예전 +예절 +예정 +예컨대 +옛날 +오늘 +오락 +오랫동안 +오렌지 +오로지 +오른발 +오븐 +오십 +오염 +오월 +오전 +오직 +오징어 +오페라 +오피스텔 +오히려 +옥상 +옥수수 +온갖 +온라인 +온몸 +온종일 +온통 +올가을 +올림픽 +올해 +옷차림 +와이셔츠 +와인 +완성 +완전 +왕비 +왕자 +왜냐하면 +왠지 +외갓집 +외국 +외로움 +외삼촌 +외출 +외침 +외할머니 +왼발 +왼손 +왼쪽 +요금 +요일 +요즘 +요청 +용기 +용서 +용어 +우산 +우선 +우승 +우연히 +우정 +우체국 +우편 +운동 +운명 +운반 +운전 +운행 +울산 +울음 +움직임 +웃어른 +웃음 +워낙 +원고 +원래 +원서 +원숭이 +원인 +원장 +원피스 +월급 +월드컵 +월세 +월요일 +웨이터 +위반 +위법 +위성 +위원 +위험 +위협 +윗사람 +유난히 +유럽 +유명 +유물 +유산 +유적 +유치원 +유학 +유행 +유형 +육군 +육상 +육십 +육체 +은행 +음력 +음료 +음반 +음성 +음식 +음악 +음주 +의견 +의논 +의문 +의복 +의식 +의심 +의외로 +의욕 +의원 +의학 +이것 +이곳 +이념 +이놈 +이달 +이대로 +이동 +이렇게 +이력서 +이론적 +이름 +이민 +이발소 +이별 +이불 +이빨 +이상 +이성 +이슬 +이야기 +이용 +이웃 +이월 +이윽고 +이익 +이전 +이중 +이튿날 +이틀 +이혼 +인간 +인격 +인공 +인구 +인근 +인기 +인도 +인류 +인물 +인생 +인쇄 +인연 +인원 +인재 +인종 +인천 +인체 +인터넷 +인하 +인형 +일곱 +일기 +일단 +일대 +일등 +일반 +일본 +일부 +일상 +일생 +일손 +일요일 +일월 +일정 +일종 +일주일 +일찍 +일체 +일치 +일행 +일회용 +임금 +임무 +입대 +입력 +입맛 +입사 +입술 +입시 +입원 +입장 +입학 +자가용 +자격 +자극 +자동 +자랑 +자부심 +자식 +자신 +자연 +자원 +자율 +자전거 +자정 +자존심 +자판 +작가 +작년 +작성 +작업 +작용 +작은딸 +작품 +잔디 +잔뜩 +잔치 +잘못 +잠깐 +잠수함 +잠시 +잠옷 +잠자리 +잡지 +장관 +장군 +장기간 +장래 +장례 +장르 +장마 +장면 +장모 +장미 +장비 +장사 +장소 +장식 +장애인 +장인 +장점 +장차 +장학금 +재능 +재빨리 +재산 +재생 +재작년 +재정 +재채기 +재판 +재학 +재활용 +저것 +저고리 +저곳 +저녁 +저런 +저렇게 +저번 +저울 +저절로 +저축 +적극 +적당히 +적성 +적용 +적응 +전개 +전공 +전기 +전달 +전라도 +전망 +전문 +전반 +전부 +전세 +전시 +전용 +전자 +전쟁 +전주 +전철 +전체 +전통 +전혀 +전후 +절대 +절망 +절반 +절약 +절차 +점검 +점수 +점심 +점원 +점점 +점차 +접근 +접시 +접촉 +젓가락 +정거장 +정도 +정류장 +정리 +정말 +정면 +정문 +정반대 +정보 +정부 +정비 +정상 +정성 +정오 +정원 +정장 +정지 +정치 +정확히 +제공 +제과점 +제대로 +제목 +제발 +제법 +제삿날 +제안 +제일 +제작 +제주도 +제출 +제품 +제한 +조각 +조건 +조금 +조깅 +조명 +조미료 +조상 +조선 +조용히 +조절 +조정 +조직 +존댓말 +존재 +졸업 +졸음 +종교 +종로 +종류 +종소리 +종업원 +종종 +종합 +좌석 +죄인 +주관적 +주름 +주말 +주머니 +주먹 +주문 +주민 +주방 +주변 +주식 +주인 +주일 +주장 +주전자 +주택 +준비 +줄거리 +줄기 +줄무늬 +중간 +중계방송 +중국 +중년 +중단 +중독 +중반 +중부 +중세 +중소기업 +중순 +중앙 +중요 +중학교 +즉석 +즉시 +즐거움 +증가 +증거 +증권 +증상 +증세 +지각 +지갑 +지경 +지극히 +지금 +지급 +지능 +지름길 +지리산 +지방 +지붕 +지식 +지역 +지우개 +지원 +지적 +지점 +지진 +지출 +직선 +직업 +직원 +직장 +진급 +진동 +진로 +진료 +진리 +진짜 +진찰 +진출 +진통 +진행 +질문 +질병 +질서 +짐작 +집단 +집안 +집중 +짜증 +찌꺼기 +차남 +차라리 +차량 +차림 +차별 +차선 +차츰 +착각 +찬물 +찬성 +참가 +참기름 +참새 +참석 +참여 +참외 +참조 +찻잔 +창가 +창고 +창구 +창문 +창밖 +창작 +창조 +채널 +채점 +책가방 +책방 +책상 +책임 +챔피언 +처벌 +처음 +천국 +천둥 +천장 +천재 +천천히 +철도 +철저히 +철학 +첫날 +첫째 +청년 +청바지 +청소 +청춘 +체계 +체력 +체온 +체육 +체중 +체험 +초등학생 +초반 +초밥 +초상화 +초순 +초여름 +초원 +초저녁 +초점 +초청 +초콜릿 +촛불 +총각 +총리 +총장 +촬영 +최근 +최상 +최선 +최신 +최악 +최종 +추석 +추억 +추진 +추천 +추측 +축구 +축소 +축제 +축하 +출근 +출발 +출산 +출신 +출연 +출입 +출장 +출판 +충격 +충고 +충돌 +충분히 +충청도 +취업 +취직 +취향 +치약 +친구 +친척 +칠십 +칠월 +칠판 +침대 +침묵 +침실 +칫솔 +칭찬 +카메라 +카운터 +칼국수 +캐릭터 +캠퍼스 +캠페인 +커튼 +컨디션 +컬러 +컴퓨터 +코끼리 +코미디 +콘서트 +콜라 +콤플렉스 +콩나물 +쾌감 +쿠데타 +크림 +큰길 +큰딸 +큰소리 +큰아들 +큰어머니 +큰일 +큰절 +클래식 +클럽 +킬로 +타입 +타자기 +탁구 +탁자 +탄생 +태권도 +태양 +태풍 +택시 +탤런트 +터널 +터미널 +테니스 +테스트 +테이블 +텔레비전 +토론 +토마토 +토요일 +통계 +통과 +통로 +통신 +통역 +통일 +통장 +통제 +통증 +통합 +통화 +퇴근 +퇴원 +퇴직금 +튀김 +트럭 +특급 +특별 +특성 +특수 +특징 +특히 +튼튼히 +티셔츠 +파란색 +파일 +파출소 +판결 +판단 +판매 +판사 +팔십 +팔월 +팝송 +패션 +팩스 +팩시밀리 +팬티 +퍼센트 +페인트 +편견 +편의 +편지 +편히 +평가 +평균 +평생 +평소 +평양 +평일 +평화 +포스터 +포인트 +포장 +포함 +표면 +표정 +표준 +표현 +품목 +품질 +풍경 +풍속 +풍습 +프랑스 +프린터 +플라스틱 +피곤 +피망 +피아노 +필름 +필수 +필요 +필자 +필통 +핑계 +하느님 +하늘 +하드웨어 +하룻밤 +하반기 +하숙집 +하순 +하여튼 +하지만 +하천 +하품 +하필 +학과 +학교 +학급 +학기 +학년 +학력 +학번 +학부모 +학비 +학생 +학술 +학습 +학용품 +학원 +학위 +학자 +학점 +한계 +한글 +한꺼번에 +한낮 +한눈 +한동안 +한때 +한라산 +한마디 +한문 +한번 +한복 +한식 +한여름 +한쪽 +할머니 +할아버지 +할인 +함께 +함부로 +합격 +합리적 +항공 +항구 +항상 +항의 +해결 +해군 +해답 +해당 +해물 +해석 +해설 +해수욕장 +해안 +핵심 +핸드백 +햄버거 +햇볕 +햇살 +행동 +행복 +행사 +행운 +행위 +향기 +향상 +향수 +허락 +허용 +헬기 +현관 +현금 +현대 +현상 +현실 +현장 +현재 +현지 +혈액 +협력 +형부 +형사 +형수 +형식 +형제 +형태 +형편 +혜택 +호기심 +호남 +호랑이 +호박 +호텔 +호흡 +혹시 +홀로 +홈페이지 +홍보 +홍수 +홍차 +화면 +화분 +화살 +화요일 +화장 +화학 +확보 +확인 +확장 +확정 +환갑 +환경 +환영 +환율 +환자 +활기 +활동 +활발히 +활용 +활짝 +회견 +회관 +회복 +회색 +회원 +회장 +회전 +횟수 +횡단보도 +효율적 +후반 +후춧가루 +훈련 +훨씬 +휴식 +휴일 +흉내 +흐름 +흑백 +흑인 +흔적 +흔히 +흥미 +흥분 +희곡 +희망 +희생 +흰색 +힘껏 diff --git a/bip-0042.mediawiki b/bip-0042.mediawiki index 1b80605..00ac10c 100644 --- a/bip-0042.mediawiki +++ b/bip-0042.mediawiki @@ -3,7 +3,7 @@ Layer: Consensus (soft fork) Title: A finite monetary supply for Bitcoin Author: Pieter Wuille <pieter.wuille@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Recommended for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042 Status: Draft Type: Standards Track diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index b13ba54..5ee2209 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -4,7 +4,7 @@ Title: Multi-Account Hierarchy for Deterministic Wallets Author: Marek Palatinus <slush@satoshilabs.com> Pavol Rusnak <stick@satoshilabs.com> - Comments-Summary: No comments yet. + Comments-Summary: Mixed review (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0044 Status: Proposed Type: Standards Track @@ -265,12 +265,16 @@ is required and a pull request to the above file should be created. ==Compatible wallets== -* [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]]) -* [[https://play.google.com/store/apps/details?id=com.bonsai.wallet32|Wallet32 @ Android]] ([[https://github.com/ksedgwic/Wallet32|source]]) * [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]]) * [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]]) -* [[https://maza.club/encompass|Encompass]] ([[https://github.com/mazaclub/encompass|source]]) * [[https://www.coinvault.io/|CoinVault]] ([[https://github.com/CoinVault/dotblock|source]]) +* [[https://samouraiwallet.com/|Samourai Wallet]] ([[https://github.com/Samourai-Wallet/samourai-wallet-android|source]]) + +* [[https://trezor.io/|TREZOR]] ([[https://github.com/trezor/|source]]) +* [[https://www.keepkey.com/|KeepKey]] ([[https://github.com/keepkey/|source]]) +* [[https://www.ledgerwallet.com/|Ledger Wallet]] ([[https://github.com/LedgerHQ|source]]) +* [[https://21.co/learn/21-lib-wallet/|21 Machine Wallet]] ([[https://github.com/21dotco|source]]) + ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] diff --git a/bip-0045.mediawiki b/bip-0045.mediawiki index d364784..51a9903 100644 --- a/bip-0045.mediawiki +++ b/bip-0045.mediawiki @@ -192,7 +192,7 @@ an external chain by generating a new address. ===Rationale=== -This stucture provides a general way of doing HDPM wallets between m-of-n +This structure provides a general way of doing HDPM wallets between m-of-n parties. Here are some explanations about the design decisions made. The reason for using separate branches for each cosigner is we don't want diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index e16dd7f..af801f9 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -8,7 +8,7 @@ RECENT CHANGES: Layer: Applications Title: Reusable Payment Codes for Hierarchical Deterministic Wallets Author: Justus Ranvier <justus@openbitcoinprivacyproject.org> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0047 Status: Draft Type: Informational @@ -174,7 +174,7 @@ Note: this procedure is used if Bob uses a version 1 payment code (regardless of ## Bob selects the designated pubkey: <pre>A, where A = aG</pre> ## Bob selects the private key associated with his notification address: <pre>b</pre> ## Bob calculates a secret point: <pre>S = bA</pre> -## Bob calculates the binding factor: <pre>s = HMAC-SHA512(x, o)</pre> +## Bob calculates the blinding factor: <pre>s = HMAC-SHA512(x, o)</pre> ### "x" is the x value of the secret point ### "o" is the outpoint being spent by the designated input. ## Bob interprets the 80 byte payload as a payment code, except: @@ -218,7 +218,7 @@ The following actions are recommended to reduce this risk: ====Sending==== -# Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH follows: +# Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH as follows: ## Alice selects the 0th private key derived from her payment code: <pre>a</pre> ## Alice selects the next unused public key derived from Bob's payment code, starting from zero: <pre>B, where B = bG</pre> ### The "next unused" public key is based on an index specific to the Alice-Bob context, not global to either Alice or Bob @@ -312,7 +312,7 @@ A recipient specifies their preference for alternate notification by setting the ===Bitmessage Notification=== -A recipient prefers to receive notifications via Bitmessage indiates this preference by: +A recipient which prefers to receive notifications via Bitmessage indicates this preference by: * Setting bit 0 of the features byte to 1 * Setting byte 67 of the serialized payment code to the desired Bitmessage address version diff --git a/bip-0060.mediawiki b/bip-0060.mediawiki index 4627dfb..8e9f289 100644 --- a/bip-0060.mediawiki +++ b/bip-0060.mediawiki @@ -3,7 +3,7 @@ Layer: Peer Services Title: Fixed Length "version" Message (Relay-Transactions Field) Author: Amir Taaki <genjix@riseup.net> - Comments-Summary: No comments yet. + Comments-Summary: Discouraged for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0060 Status: Draft Type: Standards Track diff --git a/bip-0061.mediawiki b/bip-0061.mediawiki index 2060658..1e3d41f 100644 --- a/bip-0061.mediawiki +++ b/bip-0061.mediawiki @@ -3,7 +3,7 @@ Layer: Peer Services Title: Reject P2P message Author: Gavin Andresen <gavinandresen@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0061 Status: Final Type: Standards Track diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index deff62b..7dd2b5b 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -10,12 +10,17 @@ Status: Withdrawn Type: Standards Track Created: 2014-03-12 + License: BSD-2-Clause </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it). +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + ==Motivation== As of february 2014, Bitcoin transactions are malleable in multiple ways. This means a (valid) transaction can be modified in-flight, without invalidating it, but without access to the relevant private keys. diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index 904dc16..065eb15 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -94,7 +94,7 @@ There exist a number of protocols where a transaction output is created that requires the co-operation of both parties to spend the output. To ensure the failure of one party does not result in the funds becoming lost, refund transactions are setup in advance using nLockTime. These refund transactions -need to be created interactively, and additionaly, are currently vulnerable to +need to be created interactively, and additionally, are currently vulnerable to transaction malleability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the interactive setup with a non-interactive setup, and additionally, making transaction malleability a non-issue. diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki index d2ab189..7cc3cf2 100644 --- a/bip-0066.mediawiki +++ b/bip-0066.mediawiki @@ -8,12 +8,17 @@ Status: Final Type: Standards Track Created: 2015-01-10 + License: BSD-2-Clause </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding. +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + ==Motivation== Bitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software. @@ -32,7 +37,7 @@ These operators all perform ECDSA verifications on pubkey/signature pairs, itera The following code specifies the behaviour of strict DER checking. Note that this function tests a signature byte vector which includes the 1-byte sighash flag that Bitcoin adds, even though that flag falls outside of the DER specification, and is unaffected by this proposal. The function is also not called for cases where the length of sig is 0, in order to provide a simple, short and efficiently-verifiable encoding for deliberately invalid signatures. -DER is specified in http://www.itu.int/rec/T-REC-X.690-200811-I/en . +DER is specified in https://www.itu.int/rec/T-REC-X.690/en . <pre> bool static IsValidSignatureEncoding(const std::vector<unsigned char> &sig) { diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki index f262126..e9f9245 100644 --- a/bip-0069.mediawiki +++ b/bip-0069.mediawiki @@ -30,11 +30,6 @@ Since wallet clients are left to their own devices to determine this ordering, t For example, a wallet client might naively order inputs based on when addresses were added to a wallet by the user through importing or random generation. Many wallets will place spending outputs first and change outputs second, leaking information about both the sender and receiver’s finances to passive blockchain observers. Such information should remain private not only for the benefit of consumers, but in higher order financial systems must be kept secret to prevent fraud. -Currently, there is no clear standard for how wallet clients ought to order transaction inputs and outputs. -Since wallet clients are left to their own devices to determine this ordering, they often leak information about their users’ finances. -For example, a wallet client might naively order inputs based on when addresses were added to a wallet by the user through importing or random generation. -Many wallets will place spending outputs first and change outputs second, leaking information about both the sender and receiver’s finances to passive blockchain observers. -Such information should remain private not only for the benefit of consumers, but in higher order financial systems must be kept secret to prevent fraud. A researcher recently demonstrated this principle when he detected that Bitstamp leaked information when creating exchange transactions, enabling potential espionage among traders. [1] One way to address these privacy weaknesses is by randomizing the order of inputs and outputs. [2] diff --git a/bip-0074.mediawiki b/bip-0074.mediawiki index d1f1a23..01fcf2c 100644 --- a/bip-0074.mediawiki +++ b/bip-0074.mediawiki @@ -3,7 +3,7 @@ Layer: Applications Title: Allow zero value OP_RETURN in Payment Protocol Author: Toby Padilla <tobypadilla@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0074 Status: Draft Type: Standards Track diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki index 2a6fdd5..a516916 100644 --- a/bip-0075.mediawiki +++ b/bip-0075.mediawiki @@ -6,7 +6,7 @@ Matt David <mgd@mgddev.com> Aaron Voisine <voisine@gmail.com> James MacWhyte <macwhyte@gmail.com> - Comments-Summary: No comments yet. + Comments-Summary: Recommended for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0075 Status: Draft Type: Standards Track @@ -174,7 +174,7 @@ message ProtocolMessage { ===Versioning=== This BIP introduces version 1 of this protocol. All messages sent using these base requirements MUST use a value of 1 for the version number. Any future BIPs that modify this protocol (encryption schemes, etc) MUST each increment the version number by 1. -When initiating communication, the version field of the first message SHOULD be set to the highest verison number the sender understands. All clients MUST be able to understand all version numbers less than the highest number they support. If a client receives a message with a version number higher than they understand, they MUST send the message back to the sender with a status code of 101 ("version too high") and the version field set to the highest version number the recipient understands. The sender must then resend the original message using the same version number returned by the recipient or abort. +When initiating communication, the version field of the first message SHOULD be set to the highest version number the sender understands. All clients MUST be able to understand all version numbers less than the highest number they support. If a client receives a message with a version number higher than they understand, they MUST send the message back to the sender with a status code of 101 ("version too high") and the version field set to the highest version number the recipient understands. The sender must then resend the original message using the same version number returned by the recipient or abort. ===EncryptedProtocolMessage=== The '''EncryptedProtocolMessage''' message is an encapsualting wrapper for any Payment Protocol message. It allows two-way, authenticated and encrypted communication of Payment Protocol messages in order to keep their contents secret. The message also includes a status code and status message that is used for error communication such that the protocol does not rely on transport-layer error handling. diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki index 2c4d8a7..0cade19 100644 --- a/bip-0080.mediawiki +++ b/bip-0080.mediawiki @@ -59,7 +59,7 @@ Hardened derivation is used at this level. Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. -Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. +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. Public derivation is used at this level. diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki index e88ee14..96ac8d1 100644 --- a/bip-0081.mediawiki +++ b/bip-0081.mediawiki @@ -55,7 +55,7 @@ Public derivation is used at these levels, even when the index exceeds 2^31. Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. -Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. +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. Public derivation is used at this level. diff --git a/bip-0090.mediawiki b/bip-0090.mediawiki index 653e40d..a2d3456 100644 --- a/bip-0090.mediawiki +++ b/bip-0090.mediawiki @@ -3,7 +3,7 @@ Layer: Consensus (hard fork) Title: Buried Deployments Author: Suhas Daftuar <sdaftuar@chaincode.com> - Comments-Summary: No comments yet. + Comments-Summary: Mostly Recommended for implementation, with some Discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 Status: Draft Type: Informational diff --git a/bip-0091.mediawiki b/bip-0091.mediawiki new file mode 100644 index 0000000..fa3d199 --- /dev/null +++ b/bip-0091.mediawiki @@ -0,0 +1,117 @@ +<pre> + BIP: 91 + Layer: Consensus (soft fork) + Title: Reduced threshold Segwit MASF + Author: James Hilliard <james.hilliard1@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0091 + Status: Final + Type: Standards Track + Created: 2017-05-22 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This document specifies a method to activate the existing BIP9 segwit deployment with a majority hashpower less than 95%. + +==Definitions== + +"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. + +==Motivation== + +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]. + +This BIP provides a way for a simple majority of miners to coordinate activation of the existing segwit deployment with less than 95% hashpower. For a number of reasons a complete redeployment of segwit is difficult to do until the existing deployment expires. This is due to 0.13.1+ having many segwit related features active already, including all the P2P components, the new network service flag, the witness-tx and block messages, compact blocks v2 and preferential peering. A redeployment of segwit will need to redefine all these things and doing so before expiry would greatly complicate testing. + +==Specification== + +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. + +==Deployment== + +This BIP will be deployed by a "version bits" with an 80%(this can be adjusted if desired) 269 block activation threshold and 336 block confirmation window BIP9 with the name "segsignal" and using bit 4. + +This BIP will have a start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout on midnight November 15th 2017 (epoch time 1510704000). This BIP will cease to be active when segwit (BIP141) is locked-in, active, or failed + +=== Reference implementation === + +<pre> +// Deployment of SEGSIGNAL +consensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].bit = 4; +consensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].nStartTime = 1496275200; // June 1st, 2017. +consensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].nTimeout = 1510704000; // November 15th, 2017. +consensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].nOverrideMinerConfirmationWindow = 336; // ~2.33 days +consensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].nOverrideRuleChangeActivationThreshold = 269; // 80% + +class VersionBitsConditionChecker : public AbstractThresholdConditionChecker { +private: + const Consensus::DeploymentPos id; + +protected: + int64_t BeginTime(const Consensus::Params& params) const { return params.vDeployments[id].nStartTime; } + int64_t EndTime(const Consensus::Params& params) const { return params.vDeployments[id].nTimeout; } + int Period(const Consensus::Params& params) const { + if (params.vDeployments[id].nOverrideMinerConfirmationWindow > 0) + return params.vDeployments[id].nOverrideMinerConfirmationWindow; + return params.nMinerConfirmationWindow; + } + int Threshold(const Consensus::Params& params) const { + if (params.vDeployments[id].nOverrideRuleChangeActivationThreshold > 0) + return params.vDeployments[id].nOverrideRuleChangeActivationThreshold; + return params.nRuleChangeActivationThreshold; + } + + bool Condition(const CBlockIndex* pindex, const Consensus::Params& params) const + { + return (((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & Mask(params)) != 0); + } + +public: + VersionBitsConditionChecker(Consensus::DeploymentPos id_) : id(id_) {} + uint32_t Mask(const Consensus::Params& params) const { return ((uint32_t)1) << params.vDeployments[id].bit; } +}; + +// SEGSIGNAL mandatory segwit signalling. +if (VersionBitsState(pindex->pprev, chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE && + VersionBitsState(pindex->pprev, chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT, versionbitscache) == THRESHOLD_STARTED) +{ + bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS; + bool fSegbit = (pindex->nVersion & VersionBitsMask(chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT)) != 0; + if (!(fVersionBits && fSegbit)) { + return state.DoS(0, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit"); + } +} +</pre> + +https://github.com/segsignal/bitcoin + +==Backwards Compatibility== + +This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. Miners will need to upgrade their nodes to support segsignal otherwise they may build on top of an invalid block. While this bip is active users should either upgrade to segsignal or wait for additional confirmations when accepting payments. + +==Rationale== + +Historically we have used IsSuperMajority() to activate soft forks such as BIP66 which has a mandatory signalling requirement for miners once activated, this ensures that miners are aware of new rules being enforced. This technique can be leveraged to lower the signalling threshold of a soft fork while it is in the process of being deployed in a backwards compatible way. + +By orphaning non-signalling blocks during the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment. + +==References== + +*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html Mailing list discussion] +*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation] +*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]] +*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] +*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]] +*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]] +*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]] +*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]] +*[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]] +*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits] + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. + diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index cbde553..1496557 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -144,7 +144,7 @@ unnecessary. Fundamental disagreements and controversies are part of social systems, like the one defined as the human participants in the Bitcoin network. Without judging the motivation of the rule discrepancies or -what rules were in place first, we're definining schism[1] hardforks as +what rules were in place first, we're defining schism[1] hardforks as those in which - for whatever reason - users are consiously going to validate 2 different sets of consensus rules. Since they will validate different rulesets, they will end up following 2 different chains for at least diff --git a/bip-0103.mediawiki b/bip-0103.mediawiki index 7cef84a..bc06000 100644 --- a/bip-0103.mediawiki +++ b/bip-0103.mediawiki @@ -8,12 +8,17 @@ Status: Draft Type: Standards Track Created: 2015-07-21 + License: BSD-2-Clause </pre> ==Abstract== This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future. +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + ==Motivation== 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. @@ -68,7 +73,7 @@ Using a time-based check is very simple to implement, needs little context, is e ==Compatibility== -This is a hard forking change, thus breaks compatbility with old fully-validating node. It should not be deployed without widespread consensus. +This is a hard forking change, thus breaks compatibility with old fully-validating node. It should not be deployed without widespread consensus. ==Acknowledgements== diff --git a/bip-0104.mediawiki b/bip-0104.mediawiki new file mode 100644 index 0000000..00db9a3 --- /dev/null +++ b/bip-0104.mediawiki @@ -0,0 +1,78 @@ +<pre> + BIP: 104 + Layer: Consensus (hard fork) + Title: 'Block75' - Max block size like difficulty + Author: t.khan <teekhan42@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0104 + Status: Draft + Type: Standards Track + Created: 2017-01-13 + License: BSD-2-Clause + GNU-All-Permissive +</pre> + +==Abstract== + +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. + +==Motivation== + +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. + +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. + +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. + +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. + + +==Specification== + +The max block size will be recalculated every 2016 blocks, along with difficulty, using Block75’s simple algorithm: + +<code> +new max block size = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY)) +</code> + +* TARGET_CAPACITY = 0.75 //Block75's target of keeping blocks 75% full +* AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a decimal +* x = current max block size + + +All code which generates/validates blocks or uses/references the current hardcoded limits will need to be changed to support Block75. + +==Rationale== + +The 75% full block target was selected because: +* it is the middle ground between blocks being too small (average 100% full) and blocks being unnecessarily large (average 50% full) +* it can handle short-term spikes in transaction volume of up to 33% +* it limits the growth of max block size to less than 25% over the previous period +* it will maintain average transaction fees at a stable level similar to that of May/June 2016 + +The 2016 block (~2 weeks) period was selected because: +* it has been shown to be reasonably adaptive to changing network resources (re: difficulty) +* 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 +* it minimizes any effect a malicious party could have in an attempt to manipulate max block size + +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. + +==Other solutions considered== +A hardcoded increase to max block size (2MB, 8MB, etc.), rejected because: +* only a temporary solution, whatever limit was chosen would inevitably become a problem again +* would cause transaction fees to vary wildly over time + +Allow miners to vote for max block size, rejected because: +* overly complex and political +* human involvement makes this slow to respond to changing transaction volumes +* focuses power over max block size to a relatively small group of people +* unpredictable transaction fees caused by this would create uncertainty in the ecosystem + +==Backward Compatibility== +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. + +==Activation== +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. + +==Copyright== +This BIP is dual-licensed under the BSD 2-clause license and the GNU All-Permissive License. diff --git a/bip-0106.mediawiki b/bip-0106.mediawiki index 399c725..f622907 100644 --- a/bip-0106.mediawiki +++ b/bip-0106.mediawiki @@ -52,7 +52,7 @@ https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false& ==Rationale== -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 arguements can be found [http://upalc.com/maxblocksize.php here]. +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]. ===Proposal 1 : Depending only on previous block size calculation=== diff --git a/bip-0115.mediawiki b/bip-0115.mediawiki new file mode 100644 index 0000000..9432f5c --- /dev/null +++ b/bip-0115.mediawiki @@ -0,0 +1,117 @@ +<pre> + BIP: 115 + Layer: Consensus (soft fork) + Title: Generic anti-replay protection using Script + Author: Luke Dashjr <luke+bip@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0115 + Status: Draft + Type: Standards Track + Created: 2016-09-23 + License: BSD-2-Clause +</pre> + +==Abstract== + +This BIP describes a new opcode (<code>OP_CHECKBLOCKATHEIGHT</code>) for the Bitcoin scripting system that allows construction of transactions which are valid only on specific blockchains. + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + +==Specification== + +<code>OP_CHECKBLOCKATHEIGHT</code> redefines the existing <code>OP_NOP5</code> opcode. + +When this opcode is executed: + +* If the stack has fewer than 2 elements, the script fails. +* If the top item on the stack cannot be interpreted as a minimal-length 32-bit CScriptNum, the script fails. +* The top item on the stack is interpreted as a block height (ParamHeight). +* If the blockchain (in the context of the execution) does not have ParamHeight blocks prior to the one including this transaction, the script fails (this failure must not be cached across blocks; it is equivalent to non-final status). +* If ParamHeight specifies a block deeper than 52596 blocks in the chain (including negative values), the opcode completes successfully and script continues as normal. +* The second-to-top item on the stack is interpreted as a block hash (ParamBlockHash). +* If ParamBlockHash is longer than 28 bytes, the script fails. +* If ParamBlockHash does not match the equivalent ending bytes of the block hash specified by ParamHeight, the script fails. + +Otherwise, script execution will continue as if a NOP had been executed. + +===Deployment=== + +This BIP will be deployed by "version bits" [[bip-0009.mediawiki|BIP9]] with the '''name''' "cbah" and using '''bit''' TBD. + +For Bitcoin '''mainnet''', the BIP9 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP9 '''timeout''' will be TBD (Epoch timestamp TBD). + +For Bitcoin '''mainnet''', the BIP9 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP9 '''timeout''' will be TBD (Epoch timestamp TBD). + +==Motivation== + +===Securely recovering from double spends=== + +In some circumstances, users may wish to spend received bitcoins before they have confirmed on the blockchain (Tx B1). +However, if the transaction sending them those bitcoins (Tx A1) is double-spent, the wallet must re-issue their own transaction spending them (Tx B2). +So long as the double-spend of the incoming transaction (Tx A2) also pays the wallet, this can be managed by simply updating the outgoing transaction with the new outpoint and resigning. +However, if the double-spend does not pay the wallet, the situation is presently irrecoverable: +it must spend different, non-conflicting TXOs in Tx B2, which allows an attacker to then reorganise the chain (reversing the incoming transaction's double-spend) and confirm both of his transactions Tx B1 and Tx B2. + +By adding <code>OP_CHECKBLOCKATHEIGHT</code>, the wallet can issue Tx B2 with a condition that the block confirming Tx A2 is in the history, thus eliminating this risk. + +===Replay protection in the event of a persistent blockchain split=== + +In the event of a persistent blockchain split, some mechanism is desired by which the UTXOs valid in either chain may be spent without the transaction being validly replayable on the other chain. + +This can be guaranteed by choosing a block which exists only on either side of the split, and pinning (using <code>OP_CHECKBLOCKATHEIGHT</code>) common UTXOs to be spent only on chains based on that block. + +==Best practices for wallets== + +To avoid unnecessary conflicts when a chain is reorganized, wallets should always avoid specifying the last 100 blocks when practical. +Wallets that use recent blocks when unavoidable SHOULD actively monitor the network and re-create transactions that are reorganised out with updated block hashes. +Unless it conflicts with local/user security policies, wallets SHOULD retain the private key in memory to re-sign such transactions until the pinned block is at least 100 blocks deep into the chain. + +For ordinary usage, wallets SHOULD specify the ParamBlockHash as 16 bytes. + +==Rationale== + +How is this different from the transaction's lock-time? + +* The lock-time specifies a time or block height before a transaction becomes valid. <code>OP_CHECKBLOCKATHEIGHT</code>, on the other hand, specifies a specific block's hash. + +Why are block heights required to be absolute, rather than relative? + +* A relative block height would allow for creation of transactions which are valid at block N, but not N+1. This is carefully avoided by Bitcoin to ensure that if any given block is reorganised out, non-malicious transactions can be simply re-confirmed in a later block. + +Why are blocks older than 52596 deep in the chain not verified? + +* This is to avoid creating an infinite storage requirement from all full nodes which would be necessary to maintain all the block headers indefinitely. 52596 block headers requires a fixed size of approximately 4 MB. +* In any case where you might want to specify a deeper block, you can also just as well specify a more recent one that descends from it. +* It is assumed that 1 year is sufficient time to double-spend any common UTXOs on all blockchains of interest. +* If a deeper check is needed, it can be softforked in. Making the check more shallow, on the other hand, is a hardfork. + +Why is ParamBlockHash allowed to match less than the full block hash? + +* In a chain split, it is sufficient to check only a few bytes to avoid replay. +* In all scenarios, it is likely sufficient to check only a minority of the full hash to avoid any realistic chance of replay. +* Allowing less than the full hash to be specified saves space in transaction data. +* Using a single byte can be combined with other opcodes (such as <code>OP_LESSTHAN</code>) to enable on-chain gambling logic. + +What if ParamBlockHash has leading zeros? Should this be prevented? + +* If leading zeros are included, they should be compared to the actual block hash. (If they were truncated, fewer bytes would be compared.) +* It is unlikely that the leading zeros will ever be necessary for sufficient precision, so the additional space is not a concern. +* Since all block hashes are in principle shorter than than 29 bytes, ParamBlockHash may not be larger than 28 bytes. + +Why is it safe to allow checking blocks as recently as the immediate previous block? + +* This should only be used when necessary (ie, the deeper block is not sufficient), and when the wallet can actively issue updates should the blockchain reorganise. +* While this allows intentionally creating a transaction which may be invalid in a reorganization, the same can already be accomplished by creating double spends. + +==Backwards Compatibility== + +<code>OP_NOP5</code> ought to be forbidden by policy by all miners for future extensions such as this, so old miners will under no circumstances produce blocks which would now be considered invalid under the new rules. +However, miners must still upgrade to avoid accepting and building on top of such a possible invalid block as part of an attack. + +Old nodes will likely also not relay transactions using this opcode for the same extensibility reasons, but this is not important since the rule cannot be verified deterministically outside the context of a block. + +==Reference Implementation== + +https://github.com/bitcoin/bitcoin/compare/master...luke-jr:cbah diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki index d438322..2404937 100644 --- a/bip-0123.mediawiki +++ b/bip-0123.mediawiki @@ -7,6 +7,8 @@ Status: Active Type: Process Created: 2015-08-26 + License: CC0-1.0 + GNU-All-Permissive </pre> ==Abstract== @@ -17,6 +19,10 @@ BIPs are classified by system layers with lower numbered layers involving more i The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. +==Copyright== + +This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses. + ==Motivation== Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them. diff --git a/bip-0134.mediawiki b/bip-0134.mediawiki index 9adc8b5..74f6302 100644 --- a/bip-0134.mediawiki +++ b/bip-0134.mediawiki @@ -195,7 +195,7 @@ calculation of the merkle tree. This means that changes in signatures would not be detectable and open an attack vector. For this reason the merkle tree is extended to include (append) the hash of -the v4 transactions. The markle tree will continue to have all the +the v4 transactions. The merkle tree will continue to have all the transactions' tx-ids but appended to that are the v4 hashes that include the signatures as well. Specifically the hash is taken over a data-blob that is built up from: diff --git a/bip-0135.mediawiki b/bip-0135.mediawiki new file mode 100644 index 0000000..89d3077 --- /dev/null +++ b/bip-0135.mediawiki @@ -0,0 +1,411 @@ +<pre> + BIP: 135 + Title: Generalized version bits voting + Author: Sancho Panza <sanch0panza@protonmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0135 + https://bitco.in/forum/threads/bip9-generalized-version-bits-voting-bip-genvbvoting.1968/ + Status: Draft + Type: Informational + Created: 2017-03-29 + License: CC0-1.0 + GNU-All-Permissive + Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013969.html + Replaces: 9 +</pre> + + +==Abstract== + +BIP9 introduced a mechanism for using the version bits to signal support for +backwards-compatible changes (soft-forks) using a tally over the previous 2016 +blocks computed at re-targeting intervals. It provided for a fixed threshold and +non-configurable lock-in interval applicable to all deployments on a chain. + +This document describes a generalized signaling scheme which allows each +signaling bit to have its own configurable threshold, window size (number of +blocks over which it is tallied) and a configurable lock-in period. + +It extends the semantics of the signaling bits to cover arbitrary consensus +changes, referred to under the general term 'forks'. The same range +of version bits is used for signaling. + +The states of the BIP9 state machine and its original parameters (name, bit, +starttime, timeout) are retained. Some state transition conditions are +extended by additional parameters ('threshold', 'windowsize', 'minlockedblocks', +'minlockedtime') to provide for fine-tuning of threshold and grace period. + + +==Motivation== + +The Bitcoin protocol requires a flexible scheme for finding consensus on +protocol changes, to ensure that it can adapt to the needs of the market and +remain competitive as an electronic payment system. + +While BIP9 has served the community well for previous deployments, there are +some shortcomings in its approach: + +* it specifically applies only to backward-compatible changes + +* its fixed 95% threshold is not flexible enough to allow for a 'spectrum of contentiousness' to be represented + +* small minorities can veto proposed changes, which can lead to undesirable stagnation + +A generalized revision of the BIP9 specification can address these issues +and satisfy the needs of the market for both soft and hard fork changes +as well as more flexible activation thresholds and upgrade (grace) periods. + +The proposal should allow more freedom of choice in activation strategies +while remaining backward compatible with respect to existing BIP9-based +deployments. + + +==Terms and conventions== + +The version bits used by this proposal for signaling deployment of forks are +referred to as 'signaling bits' or shortened to 'bits' where unambiguous. + +All times in this specification are in seconds since the epoch [1]. +Durations / time offsets are in seconds. + +The term 'MTP' refers to the 'median time past' which is calculated as the +median nTime of a block and its 10 predecessors. It is treated as a monotonic +clock defined by a chain, and evaluated on the ancestor of a block, i.e. + +MTP := '''GetMedianTimePast(block.parent)''' + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this +document are to be interpreted as described in RFC 2119. + + +==Specification== + + +===Backward compatibility=== + +This specification SHALL enable strict backward compatibility with existing +BIP9-based deployments through suitable parameter configuration. Any part of +the specification preventing full backward compatibility SHALL be considered +as erroneous and amended. + +As before, a set of configuration parameters SHALL exist for the version bits +for each chain supported by an implementation. This permits each bit to be +configured independently for each chain (mainnet, testnet, etc.) + + +===Signaling bits=== + + +The signaling bits SHALL comprise the 29 least significant bits of the +nVersion block header field. nVersion is a 32-bit field which is treated as +a little-endian integer. + +Signaling bits SHALL be assigned numbers from 0..28 ranging from the least +significant (bit 0) to the most significant (bit 28) in the range. + +The top 3 bits of nVersion MUST be set to 001 , yielding a range of possible +nVersion values between [0x20000000...0x3FFFFFFF], inclusive. + +If a block's nVersion does not have its top 3 bits set to 001, all its signaling +bits MUST be treated as if they are 0 (see also: 'Tallying' section below). + + +===Deployment states=== + +With each block and fork, we associate a deployment state. +The possible states are: + +# '''DEFINED''' is the first state that each fork starts out as. The genesis block for any chain SHALL by definition be in this state for each deployment. +# '''STARTED''' for blocks past the starttime. +# '''LOCKED_IN''' after STARTED, if at least threshold out of windowsize blocks have the associated bit set in nVersion, measured at next height that is evenly divisible by the windowsize. +# '''ACTIVE''' for all blocks after the grace period conditions have been met. +# '''FAILED''' if past the timeout time and LOCKED_IN was not reached. + +In accordance with BIP9, a block's state SHALL never depend on its own nVersion; +only on that of its ancestors. + + +===Fork deployment parameters=== + +Each fork deployment is specified by the following per-chain parameters: + +# The '''name''' specifies a very brief description of the fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number. +# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the fork deployment. It is chosen from the set {0,1,2,...,28}. +# The '''starttime''' specifies a minimum median time past (MTP) of a block at which the bit gains its meaning. +# The '''timeout''' specifies a time at which the deployment is considered failed. If the MTP of a block >= timeout and the fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block. +# The '''windowsize''' specifies the number of past blocks (including the block under consideration) to be taken into account for locking in a fork. +# The '''threshold''' specifies a number of blocks, in the range of 1..windowsize, which must signal for a fork in order to lock it in. The support is measured when the chain height is evenly divisible by the windowsize. If the windowsize is set to 2016 (as in BIP9) this coincides with the 2016-block re-targeting intervals. +# The '''minlockedblocks''' specifies a minimum number of blocks which a fork must remain in locked-in state before it can become active. Both minlockedblocks and minlockedtime (see below) must be satisfied before a fork can become active. +# The '''minlockedtime''' specifies a minimum grace time, an earliest time after lock-in at which the fork can become active. If the MTP of a block >= (minlockedtime + median time of the block that locked in the fork), then the fork becomes activated. Both minlockedtime and minlockedblocks (see above) must be satisfied before a fork can become active. + + +===Tallying=== + +If a block's nVersion does not have its top 3 bits set to 001, all its signaling +bits MUST be treated as if they are '0'. + +A signaling bit value of '1' SHALL indicate support of a fork and SHALL count +towards its tally on a chain. + +A signaling bit value of '0' SHALL indicate absence of support of a fork and +SHALL NOT count towards its tally on a chain. + +The signaling bits SHALL be tallied whenever the head of the active chain +changes (including after reorganizations). + + +===State transitions=== + +The following diagram illustrates the generalized state machine: + +<img src="bip-0135/bip-0135-states-small.png" align="middle"></img> +<br> + +'''NOTES:''' + +The genesis block of any chain SHALL have the state DEFINED for each deployment. + +A given deployment SHALL remain in the DEFINED state until it either passes the +starttime (and becomes STARTED) or the timeout time (and becomes FAILED). + +Once a deployment has STARTED, the signal for that deployment SHALL be tallied +over the the past windowsize blocks whenever a new block is received on that +chain. + +A transition from the STARTED state to the LOCKED_IN state SHALL only occur +when all of these are true: + +* the height of the received block is an integer multiple of the window size +* the MTP is below the timeout time +* at least threshold out of windowsize blocks have signaled support + +A similar height synchronization precondition SHALL exist for the transition from +LOCKED_IN to ACTIVE. +These synchronization conditions are expressed by the "mod(height, windowsize) = 0" +clauses in the diagram, and have been been added so that backward compatibility +with BIP9's use of the 2016-block re-targeting periods can be configured for +existing deployments (see above 'Optional full backward compatibility' section). + +A transition from LOCKED_IN to ACTIVE state SHALL only occur if the height +synchronization criterion is met and two configurable 'grace period' conditions +are fulfilled: + +# current height MUST be at least minlockedblocks above LOCKED_IN height +# MTP must exceed LOCKED_IN time by at least minlockedtime seconds + +NOTE: If minlockedtime and minlockedblocks are both set to 0, then the fork will +proceed directly to ACTIVE state once the chain height reaches a multiple of the +windowsize. + +The ACTIVE and FAILED states are terminal; a deployment stays in these states +once they are reached. + +Deployment states are maintained along block chain branches. +They need re-computation when a reorganization happens. + + +===New consensus rules=== + +New consensus rules deployed by a fork SHALL be enforced for each block that has +ACTIVE state. + + +===Optional operator notifications=== + +An implementation SHOULD notify the operator when a deployment transitions +to STARTED, LOCKED_IN, ACTIVE or FAILED states. + +It is RECOMMENDED that an implementation provide finer-grained notifications +to the operator which allow him/her to track the measured support level for +defined deployments. + +An implementation SHOULD warn the operator if the configured (emitted) nVersion +has been overridden to contain bits set to '1' in contravention of the above +non-signaling recommendations for DEFINED forks. + +It is RECOMMENDED that an implementation warn the operator if no signal has +been received for a given deployment during a full windowsize period after the +deployment has STARTED. This could indicate that something may be wrong with +the operator's configuration that is causing them not to receive the signal +correctly. + +For undefined signals, it is RECOMMENDED that implementation track these and +alert their operators with supportive upgrade notifications, e.g. + +* "warning: signaling started on unknown feature on version bit X" +* "warning: signaling on unknown feature reached X% (over last N blocks)" +* "info: signaling ceased on unknown feature (over last M blocks)" + +Since parameters of these deployments are unknown, it is RECOMMENDED that +implementations allow the user to configure the emission of such notifications +(e.g. suitable N and M parameters in the messages above, e.g. a best-guess +window of 100 blocks). + + +===getblocktemplate changes=== + +The getblocktemplate features introduced in BIP9 remain in effect unmodified. + + +==Rationale== + +The timeout into FAILED state allows eventual reuse of bits if a fork was not +successfully activated. + +A fallow period at the conclusion of a fork attempt allows some detection of +buggy clients, and allows time for warnings and software upgrades for +successful forks. The duration of a fallow period is not specified by this +proposal, although a conventional fallow period of 3 months is RECOMMENDED. + +Due to the constraints set by BIP 34, BIP 66 and BIP 65, there are only +0x7FFFFFFB possible nVersion values available. This limits to at most 30 +independent deployments. +By restricting the top 3 bits to 001 we we are left with 29 out of those for +the purposes of this proposal, and support two future upgrades for different +mechanisms (top bits 010 and 011). + + +==Guidelines== + + +===Parameter selection guidelines=== + +The following guidelines are suggested for selecting the parameters for a fork: + +# '''name''' SHOULD be selected such that no two forks, concurrent or otherwise, ever use the same name. +# '''bit''' SHOULD be selected such that no two concurrent forks use the same bit. Implementors should make an effort to consult resources such as [2] to establish whether the bit they wish to use can reasonably be assumed to be unclaimed by a concurrent fork, and to announce their use ('claim') of a bit for a fork purpose on various project mailing lists, to reduce chance of collisions. +# '''starttime''' SHOULD be set to some date in the future, approximately one month after a software release date which includes the fork signaling. This allows for some release delays, while preventing triggers as a result of parties running pre-release software. +# '''timeout''' is RECOMMENDED to be 1 year (31536000 seconds) after starttime. +# '''windowsize''' SHOULD be set large enough to allow reception of an adequately precise signal. A good high-resolution value would be 2016 blocks as used in BIP9. It is NOT RECOMMENDED to use a windowsize less than 100 blocks. +# '''threshold''' SHOULD be set as high as possible to ensure a smooth activation based on the estimated support and the nature of the proposed changes. It is strongly RECOMMENDED that threshold >= windowsize / 2 (rounded up) to ensure that a proposal is only activated by majority support. +# '''minlockedblocks''' is RECOMMENDED to be set >= windowsize, to ensure that a full window passes in LOCKED_IN state. Lower values will be ineffective as the transition from LOCKED_IN to ACTIVE is guarded by a synchronization based on the window size. +# '''minlockedtime''' SHOULD only be set > 0 if a minimum LOCKED_IN time period needs be strictly enforced. It is permissible to set minlockedblocks to 0 and only specify minlockedtime, however the synchronization condition means the grace period can only expire once the time has passed AND the chain height is a multiple of the windowsize. + +NOTE: If minlockedtime and minlockedblocks are both set to 0, then the fork will +proceed to ACTIVE state when the chain height reaches a multiple of the windowsize. + +A later deployment using the same bit is possible as long as the starttime is +after the previous fork's timeout or activation, but it is discouraged until +necessary, and even then recommended to have a pause in between to detect +buggy software. + + +===Signaling guidelines=== + +An implementation SHOULD signal '0' on a bit if one of the following holds true: + +* the deployment parameters are not DEFINED (not configured or explicitly undefined) +* the deployment is DEFINED and has not yet reached the STARTED state +* the deployment has succeeded (it has become ACTIVE) +* the deployment has FAILED + +An implementation SHOULD enable the operator to choose (override) whether to +signal '0' or '1' on a bit, once its deployment has at least reached the STARTED +state. + +An implementation SHOULD warn the operator if the configured (emitted) nVersion +has been overridden to contain bits set to '1' in contravention of the above +non-signaling recommendations. + +A supporting miner SHOULD signal '1' on a bit for which the deployment +is LOCKED_IN state so that uptake is visible. However, this has no effect on +consensus rules. +Once LOCKED_IN, a deployment proceeds to ACTIVE solely based on the configured +grace period parameters (see 'Fork deployment parameters' above). + +A miner SHOULD signal '0' on a bit if they wish to suspend signaling of support +for a fork that is DEFINED in their software. + +It is NOT RECOMMENDED to signal '1' for bits where the meaning is undefined +(i.e. bits which are unclaimed by proposals). + + +===Settings for BIP9 compatibility=== + +This section lists parameter values which can be used to effect compatibility +with the existing BIP9 versionbits state machine. + +The following table describes mainnet compatibility options (95%, 2016 blocks): + +{| class="wikitable" +!colspan=3 | +|- +! Parameter !! BIP9 value !! BIP135 value +|- +| name || some_name || some_name +|- +| bit || b || b +|- +| starttime || T_start || T_start +|- +| timeout || T_timeout || T_timeout +|- +| windowsize || n/a || 2016 +|- +| threshold || n/a || 1916 +|- +| minlockedblocks || n/a || 2016 +|- +| minlockedtime || n/a || 0 +|} + +The following table describes testnet compatibility options (75%, 2016 blocks): + +{| class="wikitable" +!colspan=3 | +|- +! Parameter !! BIP9 value !! BIP135 value +|- +| name || some_name || some_name +|- +| bit || b || b +|- +| starttime || T_start || T_start +|- +| timeout || T_timeout || T_timeout +|- +| windowsize || n/a || 2016 +|- +| threshold || n/a || 1512 +|- +| minlockedblocks || n/a || 2016 +|- +| minlockedtime || n/a || 0 +|} + + +==Deployment== + +As this BIP is not itself consensus-relevant (Information like BIP9), it can +be rolled out without the use of a BIP9 fork bit. + +Backward compatibility through judicious fork configuration parameters should +ensure that it does not interfere with existing known deployments. + +By way of design it does not interfere with unknown (undefined) deployments. + + +==Reference implementation== + +A working reference implementation, including tests, can be found in these Pull Requests: + +* https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/458 + +* https://github.com/bitcoin/bitcoin/pull/10437 + +Existing unit tests and regression tests have been left active to demonstrate +backward compatibility of the default settings with BIP9. + + +==References== + +[1] http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16 + +[2] [[https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki|List of existing BIP9 deployment proposals]] + + +==Copyright== + +This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and +GNU All-Permissive licenses. diff --git a/bip-0135/bip-0135-states-small.png b/bip-0135/bip-0135-states-small.png Binary files differnew file mode 100644 index 0000000..9191ae3 --- /dev/null +++ b/bip-0135/bip-0135-states-small.png diff --git a/bip-0135/bip-0135-states.png b/bip-0135/bip-0135-states.png Binary files differnew file mode 100644 index 0000000..ace0617 --- /dev/null +++ b/bip-0135/bip-0135-states.png diff --git a/bip-0135/bip-0135-states.svg b/bip-0135/bip-0135-states.svg new file mode 100644 index 0000000..4b06ef9 --- /dev/null +++ b/bip-0135/bip-0135-states.svg @@ -0,0 +1,598 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> + +<svg + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="744.09448819" + height="1052.3622047" + id="svg2" + version="1.1" + inkscape:version="0.48.3.1 r9886" + sodipodi:docname="bip-0135-states.svg"> + <defs + id="defs4"> + <marker + inkscape:stockid="Arrow2Send" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Send" + style="overflow:visible;"> + <path + id="path3908" + style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(0.3) rotate(180) translate(-2.3,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Mend" + style="overflow:visible;"> + <path + id="path3902" + style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(0.6) rotate(180) translate(0,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Mend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Mend" + style="overflow:visible;"> + <path + id="path3884" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;" + transform="scale(0.4) rotate(180) translate(10,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Send" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Send" + style="overflow:visible;"> + <path + id="path3890" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;" + transform="scale(0.2) rotate(180) translate(6,0)" /> + </marker> + <marker + inkscape:stockid="EmptyTriangleOutL" + orient="auto" + refY="0.0" + refX="0.0" + id="EmptyTriangleOutL" + style="overflow:visible"> + <path + id="path4035" + d="M 5.77,0.0 L -2.88,5.0 L -2.88,-5.0 L 5.77,0.0 z " + style="fill-rule:evenodd;fill:#FFFFFF;stroke:#000000;stroke-width:1.0pt" + transform="scale(0.8) translate(-6,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Lend" + style="overflow:visible;"> + <path + id="path3878" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;" + transform="scale(0.8) rotate(180) translate(12.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Lend" + style="overflow:visible;"> + <path + id="path3896" + style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(1.1) rotate(180) translate(1,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lstart" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Lstart" + style="overflow:visible"> + <path + id="path3893" + style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(1.1) translate(1,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-7" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-3" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-1" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-2" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-15" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-0" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-0" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-4" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-11" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-30" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-6" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-5" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-2" + style="overflow:visible"> + <path + inkscape:connector-curvature="0" + id="path3902-21" + style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6,-0.6)" /> + </marker> + </defs> + <sodipodi:namedview + id="base" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="0.98994949" + inkscape:cx="349.38128" + inkscape:cy="598.85682" + inkscape:document-units="px" + inkscape:current-layer="layer1" + showgrid="true" + showguides="true" + inkscape:guide-bbox="true" + inkscape:window-width="1280" + inkscape:window-height="1004" + inkscape:window-x="1917" + inkscape:window-y="-3" + inkscape:window-maximized="1"> + <sodipodi:guide + orientation="1,0" + position="400,637.14286" + id="guide2985" /> + <inkscape:grid + type="xygrid" + id="grid2987" /> + </sodipodi:namedview> + <metadata + id="metadata7"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:title></dc:title> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1"> + <rect + style="fill:none;stroke:#000000;stroke-width:1.27499998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="rect3759" + width="180" + height="60" + x="60" + y="212.36218" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="100" + y="252.36218" + id="text3761" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan3763" + x="100" + y="252.36218" + style="font-size:24px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:Monospace;-inkscape-font-specification:Monospace Bold">DEFINED</tspan></text> + <rect + style="fill:none;stroke:#000000;stroke-width:1.27499998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="rect3759-4" + width="180" + height="60" + x="60" + y="372.36218" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="100" + y="412.36218" + id="text3761-9" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan3763-9" + x="100" + y="412.36218" + style="font-size:24px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:Monospace;-inkscape-font-specification:Monospace Bold">STARTED</tspan></text> + <rect + style="fill:none;stroke:#000000;stroke-width:1.27499998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="rect3759-0" + width="220" + height="60" + x="40" + y="532.36218" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:46.18802261px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="69.282005" + y="660.90692" + id="text3761-8" + sodipodi:linespacing="125%" + transform="scale(1.1547005,0.86602543)" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan3763-93" + x="69.282005" + y="660.90692" + style="font-size:24px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:Monospace;-inkscape-font-specification:Monospace Bold">LOCKED_IN</tspan></text> + <rect + style="fill:none;stroke:#000000;stroke-width:1.20957112;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="rect3759-4-1" + width="180" + height="60" + x="60" + y="692.36218" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="100" + y="732.36218" + id="text3761-9-4" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan3763-9-8" + x="100" + y="732.36218" + style="font-size:24px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:Monospace;-inkscape-font-specification:Monospace Bold">ACTIVE</tspan></text> + <rect + style="fill:none;stroke:#000000;stroke-width:1.27499998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="rect3759-4-9" + width="180" + height="60" + x="390" + y="292.36218" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="430" + y="332.36218" + id="text3761-9-6" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan3763-9-7" + x="430" + y="332.36218" + style="font-size:24px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-family:Monospace;-inkscape-font-specification:Monospace Bold">FAILED</tspan></text> + <path + sodipodi:type="arc" + style="fill:none;stroke:#000000;stroke-width:9.2748518;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:none;marker-end:url(#Arrow2Mend)" + id="path3869" + sodipodi:cx="140" + sodipodi:cy="142.36218" + sodipodi:rx="80" + sodipodi:ry="70" + d="m 194.86409,193.30741 a 80,70 0 1 1 24.86632,-56.68713" + sodipodi:start="0.8150924" + sodipodi:end="6.2010659" + sodipodi:open="true" + transform="matrix(0.3037615,0,0,0.35042181,-2.52661,162.0049)" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + style="fill:none;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 240,242.36218 150,50" + id="path6409" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + style="fill:none;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 150,272.36218 0,100" + id="path6409-7" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + style="fill:none;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 150,432.36218 0,100" + id="path6409-7-2" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + style="fill:none;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 150,592.36218 0,100" + id="path6409-7-9" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + style="fill:none;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 240,402.36218 150,-50" + id="path6409-0" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="160" + y="322.36218" + id="text6692" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694" + x="160" + y="322.36218" + style="font-size:14px">starttime <= MTP < timeout</tspan></text> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="330" + y="262.36218" + id="text6692-1" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694-3" + x="330" + y="262.36218" + style="font-size:14px">MTP >= timeout</tspan></text> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="330" + y="392.36218" + id="text6692-1-7" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694-3-4" + x="330" + y="392.36218" + style="font-size:14px">MTP >= timeout</tspan></text> + <path + sodipodi:type="arc" + style="fill:none;stroke:#000000;stroke-width:9.2748518;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:none;marker-end:url(#Arrow2Mend)" + id="path3869-3" + sodipodi:cx="140" + sodipodi:cy="142.36218" + sodipodi:rx="80" + sodipodi:ry="70" + d="m 194.86409,193.30741 a 80,70 0 1 1 24.86632,-56.68713" + sodipodi:start="0.8150924" + sodipodi:end="6.2010659" + sodipodi:open="true" + transform="matrix(0.3037615,0,0,0.35042181,-2.52661,317.94584)" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="160" + y="468.36218" + id="text6692-2" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694-1" + x="160" + y="468.36218" + style="font-size:14px"> (mod(height, windowsize) = 0)</tspan><tspan + sodipodi:role="line" + x="160" + y="485.86218" + style="font-size:14px" + id="tspan6856"> AND</tspan><tspan + sodipodi:role="line" + x="160" + y="503.36218" + style="font-size:14px" + id="tspan6858">(MTP < timeout) AND (threshold reached)</tspan></text> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="110" + y="612.36218" + id="text6692-2-7" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694-1-5" + x="110" + y="612.36218" + style="font-size:14px"> (mod(height, windowsize) = 0)</tspan><tspan + sodipodi:role="line" + x="110" + y="629.86218" + style="font-size:14px" + id="tspan6804"> AND</tspan><tspan + sodipodi:role="line" + x="110" + y="647.36218" + style="font-size:14px" + id="tspan6806"> (height >= locked_in_height + minlockedblocks) </tspan><tspan + sodipodi:role="line" + x="110" + y="664.86218" + style="font-size:14px" + id="tspan3052"> AND</tspan><tspan + sodipodi:role="line" + x="110" + y="682.36218" + style="font-size:14px" + id="tspan3054"> (MTP >= locked_in_time + minlockedtime)</tspan></text> + <path + sodipodi:type="arc" + style="fill:none;stroke:#000000;stroke-width:9.2748518;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:none;marker-end:url(#Arrow2Mend)" + id="path3869-3-4" + sodipodi:cx="140" + sodipodi:cy="142.36218" + sodipodi:rx="80" + sodipodi:ry="70" + d="m 194.86409,193.30741 a 80,70 0 1 1 24.86632,-56.68713" + sodipodi:start="0.8150924" + sodipodi:end="6.2010659" + sodipodi:open="true" + transform="matrix(0.3037615,0,0,0.35042181,-2.52661,637.94584)" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <path + sodipodi:type="arc" + style="fill:none;stroke:#000000;stroke-width:9.2748518;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:none;marker-end:url(#Arrow2Mend)" + id="path3869-3-4-7" + sodipodi:cx="140" + sodipodi:cy="142.36218" + sodipodi:rx="80" + sodipodi:ry="70" + d="m 194.86409,193.30741 a 80,70 0 1 1 24.86632,-56.68713" + sodipodi:start="0.8150924" + sodipodi:end="6.2010659" + sodipodi:open="true" + transform="matrix(-0.3037615,0,0,0.35042181,632.52661,237.0049)" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325" /> + <text + xml:space="preserve" + style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans" + x="80" + y="642.36218" + id="text6692-1-3" + sodipodi:linespacing="125%" + inkscape:export-xdpi="300.02325" + inkscape:export-ydpi="300.02325"><tspan + sodipodi:role="line" + id="tspan6694-3-6" + x="80" + y="642.36218" + style="font-size:14px;font-style:italic;-inkscape-font-specification:Sans Italic">(Always)</tspan></text> + </g> +</svg> diff --git a/bip-0140.mediawiki b/bip-0140.mediawiki index ea5061f..9fb52b4 100644 --- a/bip-0140.mediawiki +++ b/bip-0140.mediawiki @@ -83,7 +83,7 @@ There are a number of advantages to using normalized transaction IDs: Scalable Off-Chain Instant Payments]]</ref> in which several parties sign a transaction. Without normalized transaction IDs it is trivial for one party to re-sign a transaction, hence changing the transaction hash and invalidating any transaction built on top of its outputs. Normalized transaction IDs force the ID not to change, even if a party replaces its signature. * Many higher level protocols build structures of transactions on top of multisig outputs that are not completely signed. This is currently not possible without one party holding a fully signed transaction and then calculating the ID. It is desirable to be able to build successive transactions without one party collecting all signatures, and thus possibly lock in funds unilaterally. Normalized transaction IDs allow the use of transaction templates, i.e., completely unsigned transactions upon which further transactions can be built, and only once every party is assured the structure matches its expectations it signs the template, thus validating the template. -The only occurence in which transactions can still be modified unilaterally is in the case <code>SIGHASH_NONE</code>, <code>SIGHASH_SINGLE</code> or <code>SIGHASH_ANYONECANPAY</code> is used. This however is not problematic since in these cases the creator of the transaction explicitly allows modification. +The only occurrence in which transactions can still be modified unilaterally is in the case <code>SIGHASH_NONE</code>, <code>SIGHASH_SINGLE</code> or <code>SIGHASH_ANYONECANPAY</code> is used. This however is not problematic since in these cases the creator of the transaction explicitly allows modification. In case of a transaction becoming invalid due to one of the inputs being malleated it is necessary to modify the spending transaction to reference the modified transaction ID. However, the signatures, which only use the normalized IDs, remain valid as long as the semantics of the funding transaction remain unchanged. An observer in the network may fix the transaction and reinject a corrected version. diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 7cc587a..70eb1e1 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -7,7 +7,7 @@ Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0141 - Status: Draft + Status: Proposed Type: Standards Track Created: 2015-12-21 License: PD @@ -249,7 +249,7 @@ Segregated witness fixes the problem of transaction malleability fundamentally, Two parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the "funding transaction"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the "spending transaction"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties. -Such setups is not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction. +Such setups are not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction. Unconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system. diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki index 80a413f..b11095b 100644 --- a/bip-0142.mediawiki +++ b/bip-0142.mediawiki @@ -5,7 +5,7 @@ Author: Johnson Lau <jl2012@xbt.hk> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0142 - Status: Deferred + Status: Withdrawn Type: Standards Track Created: 2015-12-24 License: PD diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 476b84d..b3d6c09 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -6,7 +6,7 @@ Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0143 - Status: Draft + Status: Proposed Type: Standards Track Created: 2016-01-03 License: PD @@ -67,7 +67,7 @@ The item 6 is a 8-byte value of the amount of bitcoin spent in this input. <code>hashOutputs</code>: *If the sighash type is neither <code>SINGLE</code> nor <code>NONE</code>, <code>hashOutputs</code> is the double SHA256 of the serialization of all output amount (8-byte little endian) with <code>scriptPubKey</code> (serialized as scripts inside CTxOuts); *If sighash type is <code>SINGLE</code> and the input index is smaller than the number of outputs, <code>hashOutputs</code> is the double SHA256 of the output amount with <code>scriptPubKey</code> of the same index as the input; -*Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>.<ref>In the original algorithm, a <code>uint256</code> of <code>0x0000......0001</code> is commited if the input index for a <code>SINGLE</code> signature is greater than or equal to the number of outputs. In this BIP a <code>0x0000......0000</code> is commited, without changing the semantics.</ref> +*Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>.<ref>In the original algorithm, a <code>uint256</code> of <code>0x0000......0001</code> is committed if the input index for a <code>SINGLE</code> signature is greater than or equal to the number of outputs. In this BIP a <code>0x0000......0000</code> is commited, without changing the semantics.</ref> The <code>hashPrevouts</code>, <code>hashSequence</code>, and <code>hashOutputs</code> calculated in an earlier verification may be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n). @@ -282,7 +282,7 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH The second input comes from a native P2WSH witness program: scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49 witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac - <026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPERATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG + <026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG To sign it with a nHashType of 3 (SIGHASH_SINGLE): @@ -338,12 +338,12 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an The first input comes from a native P2WSH witness program: scriptPubKey: 0020ba468eea561b26301e4cf69fa34bde4ad60c81e70f059f045ca9a79931004a4d value: 0.16777215 witnessScript:0063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac - 0 IF CODESEPERATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG + 0 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG The second input comes from a native P2WSH witness program: scriptPubKey: 0020d9bbfbe56af7c4b7f960a70d7ea107156913d9e5a26b0a71429df5e097ca6537 value: 0.16777215 witnessScript:5163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac - 1 IF CODESEPERATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG + 1 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG To sign it with a nHashType of 0x83 (SINGLE|ANYONECANPAY): diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index 8e65554..a0e88c1 100644 --- a/bip-0144.mediawiki +++ b/bip-0144.mediawiki @@ -6,7 +6,7 @@ Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0144 - Status: Draft + Status: Proposed Type: Standards Track Created: 2016-01-08 License: PD @@ -83,7 +83,7 @@ If the witness is empty, the old serialization format should be used. 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. -* '''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 inefficinent or nondeterministic guesswork to know which type is to be used. +* '''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. * '''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. diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index a7ace98..f139c6a 100644 --- a/bip-0145.mediawiki +++ b/bip-0145.mediawiki @@ -5,7 +5,7 @@ Author: Luke Dashjr <luke+bip22@dashjr.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0145 - Status: Draft + Status: Final Type: Standards Track Created: 2016-01-30 License: BSD-2-Clause diff --git a/bip-0147.mediawiki b/bip-0147.mediawiki index 8a5c67a..5a85a69 100644 --- a/bip-0147.mediawiki +++ b/bip-0147.mediawiki @@ -5,7 +5,7 @@ Author: Johnson Lau <jl2012@xbt.hk> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0147 - Status: Draft + Status: Proposed Type: Standards Track Created: 2016-09-02 License: PD diff --git a/bip-0148.mediawiki b/bip-0148.mediawiki new file mode 100644 index 0000000..6a7a062 --- /dev/null +++ b/bip-0148.mediawiki @@ -0,0 +1,88 @@ +<pre> + BIP: 148 + Layer: Consensus (soft fork) + Title: Mandatory activation of segwit deployment + Author: Shaolin Fry <shaolinfry@protonmail.ch> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0148 + Status: Final + Type: Standards Track + Created: 2017-03-12 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit". + +==Definitions== + +"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. + +==Motivation== + +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]. + +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. + +==Specification== + +All times are specified according to median past time. + +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. + +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. + +=== Reference implementation === + +<pre> +// Check if Segregated Witness is Locked In +bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const Consensus::Params& params) +{ + LOCK(cs_main); + return (VersionBitsState(pindexPrev, params, Consensus::DEPLOYMENT_SEGWIT, versionbitscache) == THRESHOLD_LOCKED_IN); +} + +// BIP148 mandatory segwit signalling. +int64_t nMedianTimePast = pindex->GetMedianTimePast(); +if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC + (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC + (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) && // Segwit is not locked in + !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) ) // and is not active. +{ + bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS; + bool fSegbit = (pindex->nVersion & VersionBitsMask(chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT)) != 0; + if (!(fVersionBits && fSegbit)) { + return state.DoS(0, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit"); + } +} +</pre> + +https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-segwit-flagday + +==Backwards Compatibility== + +This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. + +==Rationale== + +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 + +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. + +==References== + +*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html Mailing list discussion] +*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation] +*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]] +*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] +*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]] +*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]] +*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]] +*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits] + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. + diff --git a/bip-0149.mediawiki b/bip-0149.mediawiki new file mode 100644 index 0000000..d4dc732 --- /dev/null +++ b/bip-0149.mediawiki @@ -0,0 +1,69 @@ +<pre> + BIP: 149 + Layer: Consensus (soft fork) + Title: Segregated Witness (second deployment) + Author: Shaolin Fry <shaolinfry@protonmail.ch> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0149 + Status: Withdrawn + Type: Standards Track + Created: 2017-04-14 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +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. + +==Motivation== + +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). + +==Reference implementation== + +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. + +https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday + +==Specification== + +This deployment will set service bit (1<<5) as NODE_UAWITNESS. + +==Deployment== + +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. + +This BIP will be deployed by BIP8 with the name "segwit" and using bit 1. + +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). + +For Bitcoin testnet, segwit is already activated so no deployment is specified. + +==Backwards Compatibility== + +This deployment reuses the GBT deployment name "segwit" to maintain compatibility with existing mining software. + +This deployment is incompatible with the BIP9-segwit deployment and should not be run concurrently with it. + +==Rationale== + +The '''starttime''' of this BIP is after the BIP9-segwit timeout to remove compatibility issues with old nodes. + +==References== + +[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014234.html Mailing list discussion] + +[[bip-0008.mediawiki|BIP8]] + +[[bip-0009.mediawiki|BIP9]] + +[[bip-0141.mediawiki|BIP141]] + +[[bip-0143.mediawiki|BIP143]] + +[[bip-0147.mediawiki|BIP147]] + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. diff --git a/bip-0150.mediawiki b/bip-0150.mediawiki index e3f74f5..277341d 100644 --- a/bip-0150.mediawiki +++ b/bip-0150.mediawiki @@ -3,7 +3,7 @@ Layer: Peer Services Title: Peer Authentication Author: Jonas Schnelli <dev@jonasschnelli.ch> - Comments-Summary: No comments yet. + Comments-Summary: Discouraged for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0150 Status: Draft Type: Standards Track @@ -17,7 +17,7 @@ This BIP describes a way for peers to authenticate to other peers to guarantee n == Motivation == -We assume peer operators want to limit the access of different node services or increase datastream priorities to a selective subset of peers. Also we assume that peers want to connect to specific peers to broadcast or filter transactions (or similar actions that reveal sensitive informations) and therefore operators want to authenticate the remote peer and ensure that they have not connected to a MITM (man-in-the-middle) attacker. +We assume peer operators want to limit the access of different node services or increase datastream priorities to a selective subset of peers. Also we assume that peers want to connect to specific peers to broadcast or filter transactions (or similar actions that reveal sensitive information) and therefore operators want to authenticate the remote peer and ensure that they have not connected to a MITM (man-in-the-middle) attacker. Benefits of peer authentication: * Peers can detect MITM attacks when connecting to known peers diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index 228f66d..a01a8bb 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -3,7 +3,7 @@ Layer: Peer Services Title: Peer-to-Peer Communication Encryption Author: Jonas Schnelli <dev@jonasschnelli.ch> - Comments-Summary: No comments yet. + Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0151 Status: Draft Type: Standards Track diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 0d2b65c..e6a3969 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -3,7 +3,7 @@ Layer: Peer Services Title: Compact Block Relay Author: Matt Corallo <bip152@bluematt.me> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Recommended for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0152 Status: Draft Type: Standards Track @@ -128,7 +128,7 @@ A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are adde # Upon receipt of a cmpctblock message after sending a sendcmpct message, nodes SHOULD calculate the short transaction ID for each unconfirmed transaction they have available (ie in their mempool) and compare each to each short transaction ID in the cmpctblock message. # After finding already-available transactions, nodes which do not have all transactions available to reconstruct the full block SHOULD request the missing transactions using a getblocktxn message. # A node MUST NOT send a cmpctblock message unless they are able to respond to a getblocktxn message which requests every transaction in the block. -# A node MUST NOT send a cmpctblock message without having validated that the header properly commits to each transaction in the block, and properly builds on top of the existing chain with a valid proof-of-work. A node MAY send a cmpctblock before validating that each transaction in the block validly spends existing UTXO set entries. +# A node MUST NOT send a cmpctblock message without having validated that the header properly commits to each transaction in the block, and properly builds on top of the existing, fully-validated chain with a valid proof-of-work either as a part of the current most-work valid chain, or building directly on top of it. A node MAY send a cmpctblock before validating that each transaction in the block validly spends existing UTXO set entries. ====getblocktxn==== # The getblocktxn message is defined as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn". diff --git a/bip-0154.mediawiki b/bip-0154.mediawiki new file mode 100644 index 0000000..a0bf387 --- /dev/null +++ b/bip-0154.mediawiki @@ -0,0 +1,752 @@ +<pre> + BIP: 154 + Layer: Peer Services + Title: Rate Limiting via peer specified challenges + Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0154 + Status: Draft + Type: Standards Track + Created: 2017-04-12 + License: BSD-2-Clause +</pre> + +==Abstract== + +An anti-DoS system which provides additional service for peers which perform proof of work. + +==Definitions== + +* '''POW''' : a proof of work using some arbitrary algorithm, such as SHA256 +* '''challenge''' : a problem in the form of a POW specification and other data +* '''solution''' : a set of inputs which solve a given challenge +* '''free connection slot''' : an inbound connection slot that does not require POW +* '''POW connection slot''' : an inbound connection slot that requires POW +* '''SPH''' : Special Purpose Hardware, such as an ASIC chip +* '''GPH''' : General Purpose Hardware, such as a desktop computer +* '''Work''' : A measurement of optimized average resources (clock cycles, memory, ...) required to perform a single attempt at solving a given POW algorithm on GPH + +==Motivation== + +The Bitcoin network has a maximum number of inbound and outbound connections (125). +It is trivial and relatively cheap to flood the network with connections via dummy +nodes. Such an attack would result in (1) nodes evicting some other nodes in order to +facilitate the new connection, and (2) nodes' ability to connect to each other being +severely hampered. In this state, the network is vulnerable to e.g. a Sybil attack. + +While the network is under pressure as in the above case, nodes could allow incoming +connections anyway by requiring that the incoming peer performs some form of proof +of work, to prove that they are not simply spamming the network. This would severely +ramp up the costs of a Sybil attack, as the attacker would now have to perform proof +of work for each node, beyond the free slots. + +However, using the "standard" double-SHA256 POW algorithm in use by Bitcoin nodes to +generate blocks means attackers can use special-purpose hardware to greatly accelerate +the POW solving process. To counter this, the proof weight would have to be raised, +but this would mean standard nodes would need to solve unacceptably costly challenges +for simple operation. Therefore, a different proof of work which is arguably less +sensitive to special-purpose hardware implementations is introduced. As this is not +consensus sensitive, additional POW algorithms may be added in the future. + +==Specification== + +A peer that supports Proof of Work Rate Limiting defines two maximums: + +* max connections, from which the maximum inbound connections is calculated as <code>nMaxConnections - (nMaxOutbound + nMaxFeeler)</code> +* POW connection slots, which define how many of the above inbound connections require a POW challenge + +The peer must interpret two new network peer message types, <code>challenge</code> and <code>solution</code>. + +In addition, the network handshake sequence must be altered slightly to facilitate the exchange of challenges and/or solutions: +* when a node connects, it may send a <code>solution</code> message prior to the <code>version</code> +* if it does, and +** the solution satisfies the local node, it is given a connection, but if +** the solution does not satisfy the local node (unknown, wrong, ...), a new <code>challenge</code> is sent and the connection is closed +* if it does not, and it is marked as needing to do POW, a <code>challenge</code> is sent and the connection is closed + +This means nodes will be disconnected after receiving the challenge. It is then up to the individual nodes whether they +solve the challenge and reconnect, or discard it and find a different peer (or wait for the peer to have an open free slot). + +===POW Identifiers=== + +There are two POW identifiers currently. When a new identifier is introduced, it should be added with an increment of 1 +to the last identifier in the list. When an identifier is deprecated, its status should be changed to <code>Deprecated</code> but it should +retain its place in the list indefinitely. + +{|class="wikitable" +! ID !! Algorithm Name !! Work !! Param size !! Solution size !! Provably Secure !! SPH Resistance !! Status +|- +| 1 || sha256 || 11k cycles || 11+ bytes || 0, 4 or 8 bytes || Yes || Low || Active +|- +| 2 || cuckoo-cycle || ss 28: 150G cycles / ~48M RAM || 6+ bytes || 168 bytes || No || High || Active +|} + +====sha256==== + +Properties: + +{|class="wikitable" +! Property !! Value +|- +| Solution probability || <code>sum((1/2)^i*(1-targetBE[i]))</code> +|} + +Challenge format: + +{|class="wikitable" +! Range !! Field Name !! Data Type !! Description +|- +| 0 || config_length || varint || Length of configuration part; always 9 +|- +| 1..4 || target || uint32 || Difficulty target, in the form of a compact size (like nBits in blocks). +|- +| 5 || nonce_size || uint8 || Size of nonce in bytes; must be 0 (no nonce), 4 (uint32) or 8 (uint64) +|- +| 6..9 || nonce_offset || uint32 || Location of nonce value in target +|- +| 10.. || payload_length || varint || Length of the input data +|- +| .. || payload || byte array || Input data +|} + +Solution format: + +{|class="wikitable" +! Range !! Field Name !! Data Type !! Description +|- +| 0.. || nonce || uint32/64, or data || Nonce value that satisfies challenge; for zero-byte nonces, this is variable data that is appended to the challenge payload before hashing +|} + +Note: SHA256 works in two "modes". +# One is where the task is to insert a nonce into an existing data block so that the hash of the data block matches a given target; this is the conventional block proof of work behavior. +# The other is where the whole or parts of the data chunk are given as input (a "big nonce"). In this case, the internal nonce size is zero bytes, and the task is simply to check whether the hash of the data matches the target. If it does not, there is no way to find a solution except by getting different input from the generator (a successor algorithm). This mode is used when SHA256 is a predecessor to another algorithm. + +Additional notes: + +* The initial nonce value (when present) for finding a suitable digest should be randomized, or a challenger may deliberately pick a challenge with "poor" outcomes to fool a node into spending more than predicted time solving. + +====cuckoo-cycle==== + +Properties: + +{|class="wikitable" +! Property !! Value +|- +| Solution probability || <code>~1.0</code> for sizeshift=28, proofsize-min:-max=12:228 +|} + +Challenge format: + +{|class="wikitable" +! Range !! Field Name !! Data Type !! Description +|- +| 0 || config_length || varint || Length of configuration part; always 5 +|- +| 1 || sizeshift || uint8 || Size shift; must be equal to 28, but may be variable in the future +|- +| 2..3 || proofsize-min || uint16 || Minimum number of edges in cycle; must be even and greater than or equal to 12 (recommended: 12) +|- +| 4..5 || proofsize-max || uint16 || Maximum number of edges in cycle; must be even, greater than or equal to proofsize-min, and smaller than or equal to 254 (recommended: 228) +|- +| 6 || payload_length || varint || Length of the input data; must be 76, but may be variable in the future +|- +| 7.. || payload || byte array || Input data +|} + +Solution format: + +{|class="wikitable" +! Range !! Field Name !! Data Type !! Description +|- +| 0..3 || nonce || uint32 || Nonce which is appended to challenge payload to form solution graph +|- +| 4..171 || edges || uint32 array || 42 values which identify each of the 42 edges in the cycle +|} + +Additional notes: + +* The initial nonce value used for finding a graph with a suitable solution should be randomized, or a challenger may deliberately pick a challenge with "poor" outcomes to fool a node into spending more than predicted time solving. +* Further information on the recommended challenge parameters can be found here: http://bc-2.jp/cuckoo-profile.pdf + +===Purpose Identifiers=== + +There is only one Purpose Identifier currently. In the future, more Purpose Identifiers could be added for at-DoS-risk operations, +such as bloom filters. When a new identifier is introduced, it should be added with an increment of 1 to the last identifier in the +list. When an identifier is deprecated, its status should be changed to <code>Deprecated</code> but it should retain its place in +the list indefinitely. + +{|class="wikitable" +! ID !! Purpose Name !! Description !! Status +|- +| 1 || connect || Establish peer to peer connection || Active +|} + +===Challenges=== + +Challenges consist of one or several chained POW identifiers with accompanying parameters, as well as indicators for the purpose of the challenge, +and a signature that lets the node verify the challenge authenticity. + +After creating a challenge, the node signs it, delivers it to the peer, then discards it. +When a node provides a solution to a challenge, the node verifies the signature and adds the challenge hash to a list of solved +challenges along with its expiration time. This list is pruned on each insertion, removing any expired challenges. + +If nodes needed to keep track of unsolved challenges, an attacker could hypothetically swarm a node, causing a DoS by having it generate so many +challenges that it runs out of memory and crashes. +By signing and discarding challenges, a node only has to retain challenges that were solved, and which have not yet expired, effectively DoS- +protecting the node via the challenges themselves. + +===The <code>challenge</code> message type=== + +A challenge consists of four parts: the POW specification, a purpose identifier, an expiration date, and a signature. +The POW specification contains a list of tuples containing a POW identifier and corresponding POW parameters. + +* Each POW identifier specifies a POW algorithm (see POW Identifiers) +* The POW parameters define the inputs and requirements of the POW algorithm +* The purpose identifier specifies the purpose of the challenge (see Purpose Identifiers) +* The expiration date is a UNIX timestamp indicating when the challenge expires +* The signed content should contain a signature of the hash <code>SHA256(SHA256(pow-count || pow-id || pow-params || ... || purpose-id || expiration))</code>, i.e. the hash of the entire challenge except for the signature length and data. + +{|class="wikitable" +! Field Size !! Description !! Data type !! Description +|- +| 1 byte || pow-count || uint8 || Number of POW algorithms in the range [1..255] +|- +| 4 bytes || pow-id || uint32 || The POW algorithm to solve the problem with +|- +| ? || pow-params || ? || The POW parameters and payload +|- +| ... || ... || ... || pow-id and pow-params for algorithms 2 and beyond +|- +| 4 bytes || purpose-id || uint32 || The purpose of the challenge +|- +| 8 bytes || expiration || int64 || Expiration UNIX timestamp +|- +| ? || sign-len || varint || The length of the signature +|- +| ? || sign || byte array || The signature data +|} + +For POW specifications with a pow-count > 1, the output of the succeeding POW algorithm will be appended to the input of the predecessor for all POW algorithms except the last one. +Normally mid-layer (all but the last) POW algorithms have a zero-length input. Example implementing sha256(cuckoo-cycle): + +{|class="wikitable" +! Range !! Field Name !! Value !! Comment +|- +| 0 || pow-count || 2 || Two POW algorithms +|- +| 1..4 || pow-id || 1 || sha256 +|- +| 5 || pow-params (config_length) || 9 || +|- +| 6..9 || pow-params (target) || 0x207fffff || Resulting hash must be <= the compact hash 0x207fffff* +|- +| 10 || pow-params (nonce_size) || 0 || No nonce +|- +| 11..14 || pow-params (nonce_offset) || 0 || -- +|- +| 15..18 || pow-params (payload_length) || 0 || 0 byte input (turns into 32 byte input from successor) +|- +| 19..22 || pow-id || 2 || cuckoo-cycle +|- +| 23 || pow-params (config_length) || 8 || +|- +| 24 || pow-params (sizeshift) || 28 +|- +| 25..26 || pow-params (proofsize-min) || 12 || +|- +| 27..28 || pow-params (proofsize-max) || 228 || +|- +| 29 || pow-params (payload_length) || 76 || 76 byte input +|- +| 30..105 || pow-params || (random data) || A randomized challenge of 76 bytes +|- +| 106..109 || purpose-id || 1 || Purpose is a peer-to-peer connection +|- +| 110..117 || expiration || 1491285696 || Expiration is April 4 2017, 15:01:36 (JST) +|- +| 118 || sign-len || 71 || 71 byte signature +|- +| 119..189 || sign || (signature) || Signature of above challenge +|} + +(* Compact 0x207fffff = 0x7fffff0000000000000000000000000000000000000000000000000000000000.) + +The above should be interpreted as SHA256(cuckoo-cycle(random data || nonce)) < 0x7fffff0000000000000000000000000000000000000000000000000000000000. +* Run cuckoo-cycle on random data || nonce; increment nonce until solution is found, then +** Run SHA256 on 32 byte digest from above; if less than 0x7fffff0000000000000000000000000000000000000000000000000000000000, +*** Mark solved. +* Otherwise loop back and increase nonce and continue finding solutions + +===The <code>solution</code> message type=== + +A solution consists of two parts: the entire challenge, and solution parameters: +* The challenge must match the given challenge up to and including the signature bytes +* The solution parameters must form a valid solution to each POW step in the challenge + +{|class="wikitable" +! Field Size !! Description !! Data type !! Description +|- +| 1 byte || pow-count || uint8 || Number of POW algorithms in the range [1..255] +|- +| 4 bytes || pow-id || uint32 || The POW algorithm used to solve the problem +|- +| ? || pow-params || ? || The input to the POW solver for the above algorithm +|- +| ... || ... || ... || pow-id and pow-params for algorithms 2 and beyond +|- +| 4 bytes || purpose-id || uint32 || The purpose of the challenge +|- +| 8 bytes || expiration || int64 || Expiration UNIX timestamp +|- +| ? || sign-len || varint || The length of the signature +|- +| ? || sign || byte array || The signature data +|- +| ? || solution || ? || The solution to the challenge +|} + +Note that the solution contains the parameters for the last algorithm only. +For each algorithm except the last one, the input is derived from the output of the successor. +Example solution: + +{|class="wikitable" +! Range !! Name !! Value !! Description +|- +| 0 || length || 4 || The input to the innermost POW is 4 bytes in length +|- +| 1..4 || nonce32 || 0x12345 || The nonce used as input is 0x12345 +|} + +The above example will provide a single nonce for the inner POW. For the SHA256(SHA256(challenge data || nonce32)) case, the solution would +claim that SHA256(SHA256(challenge data || 0x00012345)) solves the challenge. + +==Signing and Verifying Challenges== + +Below is a suggestion for how to sign a challenge. The implementation generates a new, random key-pair at launch and uses that +to sign all challenges until the node is shutdown. + +===Signing a Challenge=== + +# (first time) Create a new random key-pair <code>key</code> and <code>pubkey</code> and keep these around until shutdown +# (second+ time) Fetch <code>key</code> created above +# Create a double-SHA256 <code>sighash</code> of the challenge in serialized form up until and including the expiration bytes +# Create a signature <code>sign</code> of <code>sighash</code> using <code>key</code> +# Append <code>varint(len(sign))</code> and <code>sign</code> to challenge + +===Verifying a Challenge=== + +# Fetch <code>pubkey</code> and declare failure if not defined (that means we never issued a challenge) +# Create a double-SHA256 <code>sighash</code> of the challenge provided with the solution up until and including the expiration bytes +# Verify <code>sighash</code> is not known, and add it to known hashes along with its expiration date for pruning purposes +# Set <code>sign</code> to the signature included in the challenge +# Verify the signature <code>sign</code> using <code>pubkey</code> and <code>sighash</code> +# Check that the solution solves the challenge + +Note that a list of known hashes should be kept and pruned of expired challenges on verification. Otherwise nodes may reuse the same +solution repeatedly up until its expiration. + +==Difficulty and Cost== + +===Estimating Challenge Cost=== + +Nodes need to be able to make a judgement call on whether solving a given challenge is worth their efforts. If a challenge is expected to take +so much time that it would expire before being solved (on average), it should be immediately discarded. Beyond this, a threshold should be +established for nodes based on their "value" to the node, which is inversely proportional to the current number of connections as a function +of uptime, with arbitrary modifiers (a whitelisted node or a node added via -addnode has a much higher threshold). + +It is hard to obtain an accurate value for <code>cycles_per_second</code>, and as such a fixed value of 1700000000=1.7e9 may be used. + +Given a threshold <code>t</code>, calculate the estimated work required to solve the challenge as follows: +# Define <code>p(alg)</code> as the probability that an attempt at finding a solution given the algorithm <code>alg</code> succeeds +# Define <code>w(alg)</code> as the work parameter of the algorithm <code>alg</code>. +# Let <code>Wc ← 0, Wm ← 1, Wi ← 1</code> +# For each proof of work <code>pow</code> in the POW specification: +## Let <code>p ← p(pow)</code>, <code>w ← w(pow)</code> +## Update <code>Wc ← Wc + w_cycles</code>, <code>Wi ← Wi * 1/p</code>, <code>Wm ← Wm + w_ram</code> +# Let <code>eta ← (Wc * Wi) / cycles_per_second</code> +# If <code>date() + eta >= expiration</code>, discard challenge +# If <code>eta > t</code>, discard challenge + +Example: <code>SHA256(cuckoo-cycle(...)) < 0x7fffff0000000000000000000000000000000000000000000000000000000000</code> +# <code>p(cuckoo-cycle) = 1</code>, <code>p(sha256, 0x7fffff000...) ~= (1/2)^1 = 1/2</code> +# <code>w(cuckoo-cycle) = (1.5e11 cycles, 5e7 ram)</code>, <code>w(sha256, 0x7fffff000...) = (11e3 cycles)</code> +# <code>Wc = 0, Wm = 1, Wi = 1</code> +## <code>p = p(cuckoo-cycle) = 1, w = w(cuckoo-cycle) = (1.5e11 cycles, 5e7 ram)</code> +## <code>Wc = 0 + 1.5e11 = 1.5e11</code>, <code>Wi = 1 * 1 = 1</code>, <code>Wm = 1 + 5e7 = 5e7</code> +## <code>p = p(sha256) = 1/2, w = w(sha256) = (11e3 cycles)</code> +## <code>Wc = 1.5e11 + 11e3 ~= 1.5e11, Wi = 1 * 2 = 2, Wm = 5e7 + 0 = 5e7</code> +# <code>eta = (1.5e11 * 2) / cycles_per_second</code> = <code>7.5e10 / 1.7e9</code> = 44.1 seconds</code> + +TODO: Determine how memory impacts threshold. + +To avoid other nodes dropping our challenges due to early expiration, we use a fairly generous expiration based on the pressure value +<pre> +expiration = date() + 600 * (1 + pressure) +</pre> +which means the expiration is 10 minutes for the weakest challenge, and gradually rises to 20 minutes for the hardest one. + +===Establishing Difficulty Parameters=== + +The difficulty setting for the network should change based on connection slot availability. The amount of pressure +on the network in the sense of connection slot availability is proportional to the number of established connections +over the number of total available connections. This can be locally approximated by a node to the number of +local connections compared to the local connection maximum. + +In other words, the network pressure can be approximated by any node as <code>connections / max</code> and the difficulty +can be based on e.g. <code>(connections - free) / pow_slots</code>. + +The challenge difficulty parameters can be set based on this, where 0.0 means "low pressure" and 1.0 means +"maximum pressure". The <code>GetPressure</code> method below gives 0.0 at 67 connections (for a 50 POW slot set up), and hits the 1.0 mark at <code>(nMaxConnections - nMaxOutbound - nMaxFeeler)</code>, incrementing by 0.02 for each new connection: +<pre> +int nMaxInbound = nMaxConnections - (nMaxOutbound + nMaxFeeler + nPOWConnectionSlots); +return ((double)GetNodeCount(CONNECTIONS_ALL) - nMaxInbound) / nPOWConnectionSlots; +</pre> + +An example of difficulty for a SHA256(Cuckoo-Cycle) specification would be based on a desired probability of a random SHA256 digest matching a given target: +<pre> +prob_target = 1 / (1 + pressure^2 * 15) +</pre> +This would result in probability targets according to the table below, for varying pressures (where the pressure is in the range [0..1]): + +{|class="wikitable" +! pressure !! prob_target !! solution time sha256(cc) +|- +| 0.0 || 1.00 || 00:45 +|- +| 0.1 || 0.87 || 00:51 +|- +| 0.2 || 0.63 || 01:11 +|- +| 0.3 || 0.43 || 01:45 +|- +| 0.4 || 0.29 || 02:32 +|- +| 0.5 || 0.21 || 03:32 +|- +| 0.6 || 0.16 || 04:46 +|- +| 0.7 || 0.12 || 06:13 +|- +| 0.8 || 0.09 || 07:54 +|- +| 0.9 || 0.08 || 09:48 +|- +| 1.0 || 0.06 || 11:55 +|- +|} + +==Cuckoo Cycle== + +Cuckoo Cycle[1] is a "graph-theoretic proof-of-work system, based on finding small cycles or other structures in large random graphs." + +It is memory hard, which greatly increases the complexity and cost of producing dedicated (special purpose) hardware, an ideal property for an anti-DoS system. + +The implementation specifics of the algorithm are beyond the scope of this BIP, but the github repository[2] has several reference implementations in various languages. + +==Compatibility== + +This proposal is backward compatible. Non-supporting peers will ignore the <code>challenge</code> message +and be disconnected, as if they hit the peer connection limit as normal. + +==Reference implementation== + +https://github.com/kallewoof/bitcoin/pull/2 (https://github.com/kallewoof/bitcoin/tree/pow-connection-slots) + +==References== + +* [1] Cuckoo Cycle https://github.com/tromp/cuckoo/blob/master/doc/cuckoo.pdf?raw=true +* [2] Cuckoo Cycle github https://github.com/tromp/cuckoo + +==Test vectors== + +===Cuckoo-Cycle=== + +Cuckoo Cycle header (76 bytes): +<pre> +00..1f 68a639cb 3deab5b6 23054d60 e7856037 8afa0f31 4f08dec1 6cc4ec4f d9bef1ff +20..3f 468af883 c6c9c3d5 4260087a 046d12a0 7cc3988f 9ff2957a 384de8ed db75b037 +40..4b 798d1073 214b7ea6 954f1b3a +</pre> + +Example solution nonce: 0 (<code>00000000</code>) + +Solution edges (16 number of 32-bit unsigned integers, read horizontally from top left): + +<pre> +550b1100 0fc89a00 45034401 ddfce701 08da0e02 6ccc5703 06fe8404 1d3f8504 +559e3e05 d41a9905 17075206 97cfa006 59e50d07 7bd71f07 13fe2607 14493007 +</pre> + +===SHA256(Cuckoo-Cycle)=== + +SHA256 target: <code>0x205fffff</code> + +Cuckoo Cycle header (76 bytes, same as above): +<pre> +00..1f 68a639cb 3deab5b6 23054d60 e7856037 8afa0f31 4f08dec1 6cc4ec4f d9bef1ff +20..3f 468af883 c6c9c3d5 4260087a 046d12a0 7cc3988f 9ff2957a 384de8ed db75b037 +40..4b 798d1073 214b7ea6 954f1b3a +</pre> + +Example solution nonce: 0 (<code>00000000</code>) + +SHA256 input (cuckoo-cycle nonce + solution): + +<pre> +00000000 +550b1100 0fc89a00 45034401 ddfce701 08da0e02 6ccc5703 06fe8404 1d3f8504 +559e3e05 d41a9905 17075206 97cfa006 59e50d07 7bd71f07 13fe2607 14493007 +</pre> + +SHA256 hash: <code>262c8558c7c589b19b3d513abf5fcb15162745473e603f0146889ceff750bcc3</code> + +Must be less than: <code>5fffff0000000000000000000000000000000000000000000000000000000000</code> + +===Serialized challenge example=== + +<pre> +020100000009ffff5f2000000000000002000000051c0c00e4004c68a639cb3deab5b623054d60e7 +8560378afa0f314f08dec16cc4ec4fd9bef1ff468af883c6c9c3d54260087a046d12a07cc3988f9f +f2957a384de8eddb75b037798d1073214b7ea6954f1b3a01000000a49d0659000000004730450221 +0095fc5fafe2032097c4d12a8901401cda297aad614e16f23ec42d4b78955856c002206ab7ada4ac +8f6fa9d5bd7cd06f9ba89587a28e14cea14e7f8f8d5ab851541791 +</pre> + +{|class="wikitable" +! Hex !! Description +|- +| <code>0x02</code> || Two proofs of work +|- +| <code>0x01000000</code> || Proof of work ID = 1 (SHA256) +|- +| <code>0x09</code> || Config is 9 bytes +|- +| <code>0xffff5f20</code> || SHA256: Compact target = 0x205fffff +|- +| <code>0x00</code> || SHA256: Nonce size is 0 bytes +|- +| <code>0x00000000</code> || SHA256: Nonce offset is 0 +|- +| <code>0x00</code> || Payload is 0 bytes +|- +| <code>0x02000000</code> || Proof of work ID = 2 (cuckoo-cycle) +|- +| <code>0x05</code> || Config is 5 bytes +|- +| <code>0x1c</code> || Size shift is 28 +|- +| <code>0x0c00</code> || Proof size min is 12 +|- +| <code>0xe400</code> || Proof size max is 228 +|- +| <code>0x4c</code> || Payload is 76 bytes +|- +| <code>0x68a639cb3deab5b623054d60e7856037</code> || Payload +|- +| <code>0x8afa0f314f08dec16cc4ec4fd9bef1ff</code> +|- +| <code>0x468af883c6c9c3d54260087a046d12a0</code> +|- +| <code>0x7cc3988f9ff2957a384de8eddb75b037</code> +|- +| <code>0x798d1073214b7ea6954f1b3a</code> +|- +| <code>0x01000000</code> || Purpose ID = 1 (PURPOSE_CONNECT) +|- +| <code>0xa49d065900000000</code> || UNIX timestamp 1493605796 +|- +| <code>0x47</code> || 71 byte signature +|- +| <code>0x304502210095fc5fafe2032097c4d12a</code> || Signature data +|- +| <code>0x8901401cda297aad614e16f23ec42d4b</code> +|- +| <code>0x78955856c002206ab7ada4ac8f6fa9d5</code> +|- +| <code>0xbd7cd06f9ba89587a28e14cea14e7f8f</code> +|- +| <code>0x8d5ab851541791</code> +|} + +===Serialized solution example=== + +<pre> +020100000009ffff5f2000000000000002000000051c0c00e4004c68a639cb3deab5b623054d60e7 +8560378afa0f314f08dec16cc4ec4fd9bef1ff468af883c6c9c3d54260087a046d12a07cc3988f9f +f2957a384de8eddb75b037798d1073214b7ea6954f1b3a01000000a49d0659000000004730450221 +0095fc5fafe2032097c4d12a8901401cda297aad614e16f23ec42d4b78955856c002206ab7ada4ac +8f6fa9d5bd7cd06f9ba89587a28e14cea14e7f8f8d5ab8515417914400000000550b11000fc89a00 +45034401ddfce70108da0e026ccc570306fe84041d3f8504559e3e05d41a99051707520697cfa006 +59e50d077bd71f0713fe260714493007 +</pre> + +Note that the first 187 bytes are identical to the challenge above. + +{|class="wikitable" +! Hex !! Description +|- +| <code>0x0201..1791</code> || Challenge +|- +| <code>0x44</code> || Solution is 68 bytes long +|- +| <code>0x00000000</code> || The cuckoo cycle nonce is 0 +|- +| <code>0x550b11000fc89a0045034401ddfce701</code> || Cycle edges 0..3 +|- +| <code>0x08da0e026ccc570306fe84041d3f8504</code> || Cycle edges 4..7 +|- +| <code>0x559e3e05d41a99051707520697cfa006</code> || Cycle edges 8..11 +|- +| <code>0x59e50d077bd71f0713fe260714493007</code> || Cycle edges 12..15 +|} + +===Cuckoo-Cycle Example 2=== + +Cuckoo Cycle header (76 bytes): +<pre> +00..1f 3c1e3ee5 c799b7e9 92bcccbb 8985979d cb8dd229 b8d0db06 e677d00b b3a43c88 +20..3f ef8596a7 7cbd1dda 23b0a0b8 4bdf6084 d7aa28dd bd5e91b5 11b3578c baf92707 +40..4b c940b051 a0759b3f 80c5fb65 +</pre> + +Example solution nonce: 4 (<code>04000000</code>) + +Solution edges (22 number of 32-bit unsigned integers, read horizontally from top left): + +<pre> +5a013700 7074ce00 e3dbeb00 e88f7901 06d71d02 984d3d02 091b5002 378a8e02 +90a6d202 b3c67003 757cb703 44d9cf03 297f2004 8e76a604 67e44a05 7b077405 +634f8405 23e88c05 0d887606 109d3e07 c4bdcd07 3db2d407 +</pre> + +===SHA256(Cuckoo-Cycle)=== + +SHA256 target: <code>0x2021642c</code> + +Cuckoo Cycle header (76 bytes, same as above): +<pre> +00..1f 3c1e3ee5 c799b7e9 92bcccbb 8985979d cb8dd229 b8d0db06 e677d00b b3a43c88 +20..3f ef8596a7 7cbd1dda 23b0a0b8 4bdf6084 d7aa28dd bd5e91b5 11b3578c baf92707 +40..4b c940b051 a0759b3f 80c5fb65 +</pre> + +Example solution nonce: 4 (<code>04000000</code>) + +SHA256 input (cuckoo-cycle nonce + solution): + +<pre> +04000000 +5a013700 7074ce00 e3dbeb00 e88f7901 06d71d02 984d3d02 091b5002 378a8e02 +90a6d202 b3c67003 757cb703 44d9cf03 297f2004 8e76a604 67e44a05 7b077405 +634f8405 23e88c05 0d887606 109d3e07 c4bdcd07 3db2d407 +</pre> + +SHA256 hash: <code>08210561257e26776135ec1cb92cfe17f46803613c0bdc02043e5545b18556ce</code> + +Must be less than: <code>21642c0000000000000000000000000000000000000000000000000000000000</code> + +===Serialized challenge example=== + +<pre> +0201000000092c64212000000000000002000000051c0c00e4004c3c1e3ee5c799b7e992bcccbb89 +85979dcb8dd229b8d0db06e677d00bb3a43c88ef8596a77cbd1dda23b0a0b84bdf6084d7aa28ddbd +5e91b511b3578cbaf92707c940b051a0759b3f80c5fb650100000024aa0659000000004630440220 +0edfb5c4812a31d84cbbd4b24e631795435a0d16b57d37ef773735b8a87caa8a0220631d0b78b7f1 +d29c9e54a76f3457ff1a2ee19490ff027c528a896f4bf6aff577 +</pre> + +{|class="wikitable" +! Hex !! Description +|- +| <code>0x02</code> || Two proofs of work +|- +| <code>0x01000000</code> || Proof of work ID = 1 (SHA256) +|- +| <code>0x09</code> || Config is 9 bytes +|- +| <code>0x2c642120</code> || SHA256: Compact target = 0x2021642c +|- +| <code>0x00</code> || SHA256: Nonce size is 0 bytes +|- +| <code>0x00000000</code> || SHA256: Nonce offset is 0 +|- +| <code>0x00</code> || Payload is 0 bytes +|- +| <code>0x02000000</code> || Proof of work ID = 2 (cuckoo-cycle) +|- +| <code>0x05</code> || Config is 5 bytes +|- +| <code>0x1c</code> || Size shift is 28 +|- +| <code>0x0c00</code> || Proof size min is 12 +|- +| <code>0xe400</code> || Proof size max is 228 +|- +| <code>0x4c</code> || Payload is 76 bytes +|- +| <code>0x3c1e3ee5c799b7e992bcccbb8985979d</code> || Payload +|- +| <code>0xcb8dd229b8d0db06e677d00bb3a43c88</code> +|- +| <code>0xef8596a77cbd1dda23b0a0b84bdf6084</code> +|- +| <code>0xd7aa28ddbd5e91b511b3578cbaf92707</code> +|- +| <code>0xc940b051a0759b3f80c5fb65</code> +|- +| <code>0x01000000</code> || Purpose ID = 1 (PURPOSE_CONNECT) +|- +| <code>0x24aa065900000000</code> || UNIX timestamp 1493608996 +|- +| <code>0x46</code> || 70 byte signature +|- +| <code>0x304402200edfb5c4812a31d84cbbd4b2</code> || Signature data +|- +| <code>0x4e631795435a0d16b57d37ef773735b8</code> +|- +| <code>0xa87caa8a0220631d0b78b7f1d29c9e54</code> +|- +| <code>0xa76f3457ff1a2ee19490ff027c528a89</code> +|- +| <code>0x6f4bf6aff577</code> +|} + +===Serialized solution example=== + +<pre> +0201000000092c64212000000000000002000000051c0c00e4004c3c1e3ee5c799b7e992bcccbb89 +85979dcb8dd229b8d0db06e677d00bb3a43c88ef8596a77cbd1dda23b0a0b84bdf6084d7aa28ddbd +5e91b511b3578cbaf92707c940b051a0759b3f80c5fb650100000024aa0659000000004630440220 +0edfb5c4812a31d84cbbd4b24e631795435a0d16b57d37ef773735b8a87caa8a0220631d0b78b7f1 +d29c9e54a76f3457ff1a2ee19490ff027c528a896f4bf6aff5775c040000005a0137007074ce00e3 +dbeb00e88f790106d71d02984d3d02091b5002378a8e0290a6d202b3c67003757cb70344d9cf0329 +7f20048e76a60467e44a057b077405634f840523e88c050d887606109d3e07c4bdcd073db2d407 +</pre> + +Note that the first 186 bytes are identical to the challenge above. + +{|class="wikitable" +! Hex !! Description +|- +| <code>0x0201..f577</code> || Challenge +|- +| <code>0x5c</code> || Solution is 92 bytes long +|- +| <code>0x04000000</code> || The cuckoo cycle nonce is 4 +|- +| <code>0x5a0137007074ce00e3dbeb00e88f7901</code> || Cycle edges 0..3 +|- +| <code>0x06d71d02984d3d02091b5002378a8e02</code> || Cycle edges 4..7 +|- +| <code>0x90a6d202b3c67003757cb70344d9cf03</code> || Cycle edges 8..11 +|- +| <code>0x297f20048e76a60467e44a057b077405</code> || Cycle edges 12..15 +|- +| <code>0x634f840523e88c050d887606109d3e07</code> || Cycle edges 16..19 +|- +| <code>0xc4bdcd073db2d407</code> || Cycle edges 20..21 +|} + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki new file mode 100644 index 0000000..79fd0fc --- /dev/null +++ b/bip-0159.mediawiki @@ -0,0 +1,66 @@ +<pre> + BIP: 159 + Layer: Peer Services + Title: NODE_NETWORK_LIMITED service bit + Author: Jonas Schnelli <dev@jonasschnelli.ch> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0159 + Status: Draft + Type: Standards Track + Created: 2017-05-11 + License: BSD-2-Clause +</pre> + +== Abstract == + +Define a service bit that allow pruned peers to signal their limited services + +==Motivation== + +Pruned peers can offer the same services as traditional peer except of serving all historical blocks. +Bitcoin right now only offers the NODE_NETWORK service bit which indicates that a peer can serve +all historical blocks. +# 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) +# 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 + +== Specification == + +=== New service bit === + +This BIP proposes a new service bit + +{|class="wikitable" +|- +| NODE_NETWORK_LIMITED || bit 10 (0x400) || If signaled, the peer <I>MUST</I> be capable of serving at least the last 288 blocks (~2 day / the current minimum limit for Bitcoin Core). +|} + +A safety buffer of additional 144 blocks to handle chain reorganizations <I>SHOULD</I> be taken into account when connecting to a peer signaling the <code>NODE_NETWORK_LIMITED</code> service bit. + +=== Address relay === + +Full nodes following this BIP <I>SHOULD</I> relay address/services (<code>addr</code> message) from peers they would connect to (including peers signaling <code>NODE_NETWORK_LIMITED</code>). + +=== Counter-measures for peer fingerprinting === + +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 <I>SHOULD</I> avoid leaking the prune depth and therefore not serve blocks deeper then the signaled <code>NODE_NETWORK_LIMITED</code> thresholds. + +=== Risks === + +Pruned peers following this BIP may consume more outbound bandwidth. + +Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-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 <code>NODE_NETWORK_LIMITED</code> if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option. + +== Compatibility == + +This proposal is backward compatible. + +== Reference implementation == + +* https://github.com/bitcoin/bitcoin/pull/10387 + + +== References == + +== Copyright == + +This BIP is licensed under the 2-clause BSD license. diff --git a/bip-0171.mediawiki b/bip-0171.mediawiki new file mode 100644 index 0000000..11eb109 --- /dev/null +++ b/bip-0171.mediawiki @@ -0,0 +1,200 @@ +<pre> + BIP: 171 + Layer: Applications + Title: Currency/exchange rate information API + Author: Luke Dashjr <luke+bip@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0171 + Status: Draft + Type: Standards Track + Created: 2017-03-04 + License: BSD-2-Clause +</pre> + +==Abstract== + +A common interface for requesting currency exchange rate information from a server. + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + +==Specification== + +Four requests are defined, which are all made by a GET request to a common URI with parameters encoded in application/x-www-form-urlencoded format. +All matching parameters may be specified with multiple comma-separated values, which are to be interpreted as "any of these". +Each result is always in JSON format, with a line-feed (never a carriage-return) separating multiple results. + +Authentication for subscription-based services MAY be supported using standard HTTP authentication. +It is recommended to use TLS (HTTPS) and/or Linked Data Signatures, so that MITM attackers cannot deceive the client. + +To be BIP 171 compatible, servers MUST support at least one currency-pair compared to XBT. +All inquiries for bitcoin amounts MUST be specified in XBT, even if the presentation to the end user is in another unit. +(FIXME: or should this be satoshis?) + +Currency-pair tokens are arbitrary Strings no longer than 255 characters, which may include any ASCII [https://tools.ietf.org/html/rfc3986#section-2.3 RFC 3986 unreserved characters] (ie, alphanumerics and the hyphen, underscore, period, and tilde symbols). + +Currency code(s) used herein are defined as such: + +* All ISO 4217 codes are valid currency codes. +* XBT is defined as 100000000 satoshis (commonly known as 1 BTC). +* Strings longer than 3 characters may be used for currencies without an applicable code. (If a shorter code is desired despite this, it may be padded with space(s) to the left until it is 4 characters. Software MAY strip these spaces.) + +Rate is defined as the amount of quote-currency to be exchanged for one unit of the base-currency. +In other words, <code>1 baseCurrency = rate quoteCurrency</code>. + +===Enumerating supported currency-pair tokens=== + +Parameters: + +* ''mode'' - Always "list" for this request. +* ''quote'' - If provided, the server MAY limit the results to only currency-pairs describing a currency with the given currency code(s). +* ''base'' - If provided, the server MAY limit the results to only currency-pairs describing currency rates compared to the given currency code(s). +* ''locale'' - If provided, the server MAY limit the results to only currency-pairs supporting the given Unicode CLDR locale(s). + +Each currency-pair will receive a separate result, a JSON Object, with the following information: + +* ''cp'' - The currency-pair token. +* ''quote'' - The currency code for the quote currency. +* ''base'' - The currency code for the base currency. +* ''locale'' - If provided, a String with the applicable Unicode CLDR locale. +* ''desc'' - Optional description. For example, it could be "Based on Florida BTM prices." or any other short String that provides information useful to the user. SHOULD be shorter than 45 characters. +* ''signature'' - Optional. May be used for Linked Data Signatures. + +Example: + + Request: http://api.example.tld/?mode=list"e=USD&base=XBT&locale=en_US,en_GB + Result: + {"cp":"XBTUSD-ver4", "quote":"USD", "base": "XBT", "locale": "en_US", "desc": "Smoothed averages"} + {"cp":"2", "quote":"USD", "base": "XBT", "locale": "en_US", "desc": "Updated per-trade"} + {"cp":"XBTUSD-european", "quote":"USD", "base": "XBT", "locale": "en_GB"} + +===Currency-pair information=== + +Parameters: + +* ''mode'' - Always "info" for this request. +* ''cp'' - Currency pair(s) for which information is requested. + +Each currency-pair will receive a separate result, a JSON Object, with the following information: + +* ''cp'' - The currency-pair token. +* ''quote'' - The currency code for the quote currency. +* ''base'' - The currency code for the base currency. +* ''locale'' - If provided, a String with the applicable Unicode CLDR locale. +* ''desc'' - Optional description. For example, it could be "Based on Florida BTM prices." or any other short String that provides information useful to the user. SHOULD be shorter than 45 characters. +* ''longdesc'' - Optional description, but may be longer and include newlines. +* ''symbol'' - An Array of prefix and suffix for the quote currency. Each may be either a fixed String, an Array of two Strings (negative and positive), or null. Any positive or negative symbols must be included in this prefix/suffix; it MUST NOT be implied otherwise. +* ''digits'' - The type of digits to use for the quote currency's numbers. "arabic" should be used for common 0-9 digits. +* ''grouping'' - An Array alternating between Numbers representing a series of digits, and Strings used as delimiters. If terminated by a zero, the final grouping is to be repeated continually. For example, the common US locale thousands grouping would be <code>[3, ",", 0]</code> +* ''fraction_sep'' - A String to be placed between whole numbers and a fractional amount. +* ''fraction_digits'' - Array of absolute minimum (even for whole numbers) number of fractional digits, minimum fractional digits when a fraction exists, and maximum number of fractional digits when absolute precision is not demanded (below which is to be rounded in an implementation-dependent manner). +* ''minpoll'' - A Number of seconds indicating a minimum time between polls to the server. Clients should be prudent about not polling too often, even if this number is low. +* ''longpoll'' - If provided and true, indicates longpolling is supported by the server. +* ''history'' - If provided, indicates the server has historical records going back no earlier than the POSIX timestamp provided as a value. +* ''archive'' - If provided, indicates the server no longer has current rates, and has no historical rates more recent than the POSIX timestamp provided as a value. +* ''signature'' - Optional. May be used for Linked Data Signatures. + +Example: + + Request: http://api.example.tld/?mode=info&cp=XBTUSD-ver4,2 + Result: + {"cp":"XBTUSD-ver4", "quote":"USD", "base": "XBT", "locale": "en_US", "desc": "Smoothed averages", "longdesc": "USD price quotes as compared to Bitcoin value\n\nRecommended for casual usage", "symbol": [["-$", "$"], null], "digits": "arabic", "grouping": [3, ",", 0], "fraction_sep": ".", "fraction_digits": [0, 2, 2], "minpoll": 300, "longpoll": true, "history": 1457231416} + {"cp":"2", "quote":"USD", "base": "XBT", "locale": "en_US", "desc": "Updated per-trade", "longdesc": "Maximum precision USD price quotes as compared to Bitcoin value", "symbol": [["-$", "$"], null], "digits": "arabic", "grouping": [3, ",", 0], "fraction_sep": ".", "fraction_digits": [0, 2, 2], "minpoll": 3600, "longpoll": false, "history": 1467458333.1225} + +===Current exchange rate=== + +Parameters: + +* ''mode'' - Always "rate" for this request. +* ''cp'' - Currency pair(s) for which rate is requested. +* ''type'' - Type of exchange rate data being requested. May be "high", "low", "average", "typical", or any other arbitrary name. If omitted, the server may provide any rates it deems appropriate. +* ''minrate'', ''maxrate'' - If specified, indicates this request is a longpoll. The server should not send a response until the rate(s) fall below or above (respectively) the provided value. +* ''nonce'' - If specified, the server SHOULD return it in each result. + +Each currency-pair receives a separate result (a JSON Object) with all requested rate types: + +* ''cp'' - The currency-pair token. +* ''time'' - The time (as a POSIX timestamp) the rate information is applicable to (should be approximately the request time). +* ''rates'' - A JSON Object with each rate type provided as a key, and a Number as the value specifying the rate. +* ''nonce'' - Only if the request specified a nonce, the server SHOULD include it here as a JSON String. +* ''signature'' - Optional. May be used for Linked Data Signatures. + +Example: + + Request: http://api.example.tld/?mode=rate&cp=XBTUSD-ver4,2&type=typical,high + Result: + {"cp":"XBTUSD-ver4", "time": 1488767410.5463133, "rates": {"typical": 1349.332215, "high": 1351.2}} + {"cp":"2", "time": 1488767410, "rates": {"typical": 1350.111332}} + +===Historical exchange rates=== + +Parameters: + +* ''mode'' - Always "history" for this request. +* ''cp'' - Currency pair(s) for which rate is requested. +* ''type'' - Type of exchange rate data being requested. May be "high", "low", "average", "typical", or any other arbitrary name. If omitted, the server may provide any rates it deems appropriate. +* ''from'' - POSIX timestamp the results should begin with. +* ''to'' - POSIX timestamp the results should end with. If omitted, the present time shall be used. +* ''nearest'' - If provided and true, indicates that only the nearest timestamp to "from" must be returned, and a range is not desired. ("to" should be omitted in this case.) +* ''ratedelta'', ''timedelta'' - If specified, the server may omit data where the rate or time has not changed since the last provided rate and time. If both are provided, either a significant rate change OR time change should trigger a new record in the results. + +A result is provided for each currency-pair and timestamp record, in the same format as the current exchange rate request. +Records MUST be provided in chronological order, but only within the scope of the applicable currency-pair (ie, it is okay to send the full history for one currency-pair, and then the full history for the next; or to intermix them out of any given order). + +If there is no exact record for the times specified by "from" and/or "to", a single record before "from" and/or after "to" should also be included. +This is not necessary when only the nearest record is requested, or when "to" is omitted (ie, ending at the most recent record). + +Example: + + Request: http://api.example.tld/?mode=history&cp=XBTUSD-ver4,2&type=typical&ratedelta=0.1&timedelta=10&from=1488759998&to=1488760090 + Result: + {"cp":"XBTUSD-ver4", "time": 1488760000, "rates": {"typical": 1300}} + {"cp":"XBTUSD-ver4", "time": 1488760010, "rates": {"typical": 1301.1}} + {"cp":"XBTUSD-ver4", "time": 1488760020, "rates": {"typical": 1320}} + {"cp":"XBTUSD-ver4", "time": 1488760030, "rates": {"typical": 1305}} + {"cp":"2", "time": 1488760000.1, "rates": {"typical": 1300}} + {"cp":"2", "time": 1488760010.2, "rates": {"typical": 1301.1}} + {"cp":"2", "time": 1488760020.2, "rates": {"typical": 1320.111332}} + {"cp":"2", "time": 1488760031, "rates": {"typical": 1305.222311}} + {"cp":"XBTUSD-ver4", "time": 1488760040, "rates": {"typical": 1303.33}} + {"cp":"2", "time": 1488760042, "rates": {"typical": 1303.33}} + {"cp":"XBTUSD-ver4", "time": 1488760050, "rates": {"typical": 1305}} + {"cp":"2", "time": 1488760052, "rates": {"typical": 1307}} + {"cp":"XBTUSD-ver4", "time": 1488760060, "rates": {"typical": 1309}} + {"cp":"XBTUSD-ver4", "time": 1488760072, "rates": {"typical": 1308}} + {"cp":"2", "time": 1488760062, "rates": {"typical": 1309.55555555}} + {"cp":"2", "time": 1488760072, "rates": {"typical": 1308}} + {"cp":"XBTUSD-ver4", "time": 1488760082, "rates": {"typical": 1309}} + {"cp":"2", "time": 1488760082, "rates": {"typical": 1309.1}} + +==Motivation== + +End users often desire to see fiat currency information in their Bitcoin wallet software. +Due to the nature of Bitcoin, there is inherently no authoritative source for exchange rates. +There are many independent providers of such information, but they all use different formats for providing it, so wallet software is currently forced to implement dedicated code for each provider. + +By providing a standard interface for retrieving this information, wallets (and other software) and service providers can implement it once, and become immediately interoperable with all other compatible implementations. + +==Rationale== + +Why are multiple results separated by a line-feed rather than using a JSON Array? + +* Clients ought to cache historical data, and using a line-feed format allows them to simply append to a cache file. +* Parsing JSON typically requires the entire data parsed together as a single memory object. Using simple lines to separate results, however, allows parsing a single result at a time. + +What if long descriptions require line and paragraph breaks? + +* Clients should word-wrap long lines, and JSON escapes newlines as "\n" which can be used doubly ("\n\n") for paragraph breaks. + +==Backwards compatibility== + +While this new standard is adopted, software and providers can continue to use and provide their current formats until they are no longer needed. + +==Reference implementation== + +TODO + +==See also== + +* [https://w3c-dvcg.github.io/ld-signatures/ Draft W3c Linked Data Signatures specification] diff --git a/bip-0173.mediawiki b/bip-0173.mediawiki new file mode 100644 index 0000000..90ed629 --- /dev/null +++ b/bip-0173.mediawiki @@ -0,0 +1,399 @@ +<pre> + BIP: 173 + Layer: Applications + Title: Base32 address format for native v0-16 witness outputs + Author: Pieter Wuille <pieter.wuille@gmail.com> + Greg Maxwell <greg@xiph.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0173 + Status: Draft + Type: Informational + Created: 2016-03-20 + License: BSD-2-Clause + Replaces: 142 +</pre> + +==Introduction== + +===Abstract=== + +This document proposes a checksummed base32 format, "Bech32", and a standard for native segregated witness output addresses using it. + +===Copyright=== + +This BIP is licensed under the 2-clause BSD license. + +===Motivation=== + +For most of its history, Bitcoin has relied on base58 addresses with a +truncated double-SHA256 checksum. They were part of the original +software and their scope was extended in +[https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki BIP13] +for Pay-to-script-hash +([https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki P2SH]). +However, both the character set and the checksum algorithm have limitations: +* Base58 needs a lot of space in QR codes, as it cannot use the ''alphanumeric mode''. +* The mixed case in base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud. +* The double SHA256 checksum is slow and has no error-detection guarantees. +* Most of the research on error-detecting codes only applies to character-set sizes that are a [https://en.wikipedia.org/wiki/Prime_power prime power], which 58 is not. +* Base58 decoding is complicated and relatively slow. + +Included in the Segregated Witness proposal are a new class of outputs +(witness programs, see +[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]), +and two instances of it ("P2WPKH" and "P2WSH", see +[https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143]). +Their functionality is available indirectly to older clients by embedding in P2SH +outputs, but for optimal efficiency and security it is best to use it +directly. In this document we propose a new address format for native +witness outputs (current and future versions). + +This replaces +[https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki BIP142], +and was previously discussed +[https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html#base32 here] (summarized +[https://bitcoincore.org/en/meetings/2016/05/20/#error-correcting-codes-for-future-address-types here]). + +===Examples=== + +All examples use public key +<tt>0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798</tt>. +The P2WSH examples use <tt>key OP_CHECKSIG</tt> as script. + +* Mainnet P2WPKH: <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4</tt> +* Testnet P2WPKH: <tt>tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx</tt> +* Mainnet P2WSH: <tt>bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3</tt> +* Testnet P2WSH: <tt>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7</tt> + +==Specification== + +We first describe the general checksummed base32<ref>'''Why use base32 at all?''' The lack of mixed case makes it more +efficient to read out loud or to put into QR codes. It does come with a 15% length +increase, but that does not matter when copy-pasting addresses.</ref> format called +''Bech32'' and then define Segregated Witness addresses using it. + +===Bech32=== + +A Bech32<ref>'''Why call it Bech32?''' "Bech" contains the characters BCH (the error +detection algorithm used) and sounds a bit like "base".</ref> string is at most 90 characters long and consists of: +* The '''human-readable part''', which is intended to convey the type of data, or anything else that is relevant to the reader. This part MUST contain 1 to 83 US-ASCII characters, with each character having a value in the range [33-126]. HRP validity may be further restricted by specific applications. +* The '''separator''', which is always "1". In case "1" is allowed inside the human-readable part, the last one in the string is the separator<ref>'''Why include a separator in addresses?''' That way the human-readable +part is unambiguously separated from the data part, avoiding potential +collisions with other human-readable parts that share a prefix. It also +allows us to avoid having character-set restrictions on the human-readable part. The +separator is ''1'' because using a non-alphanumeric character would +complicate copy-pasting of addresses (with no double-click selection in +several applications). Therefore an alphanumeric character outside the normal character set +was chosen.</ref>. +* The '''data part''', which is at least 6 characters long and only consists of alphanumeric characters excluding "1", "b", "i", and "o"<ref>'''Why not use an existing character set like [http://www.faqs.org/rfcs/rfc3548.html RFC3548] or [https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt z-base-32]'''? +The character set is chosen to minimize ambiguity according to +[https://hissa.nist.gov/~black/GTLD/ this] visual similarity data, and +the ordering is chosen to minimize the number of pairs of similar +characters (according to the same data) that differ in more than 1 bit. +As the checksum is chosen to maximize detection capabilities for low +numbers of bit errors, this choice improves its performance under some +error models.</ref>. + + +{| class="wikitable" +|- +! +!0 +!1 +!2 +!3 +!4 +!5 +!6 +!7 +|- +!+0 +|q||p||z||r||y||9||x||8 +|- +!+8 +|g||f||2||t||v||d||w||0 +|- +!+16 +|s||3||j||n||5||4||k||h +|- +!+24 +|c||e||6||m||u||a||7||l +|} + + +'''Checksum''' + +The last six characters of the data part form a checksum and contain no +information. Valid strings MUST pass the criteria for validity specified +by the Python3 code snippet below. The function +<tt>bech32_verify_checksum</tt> must return true when its arguments are: +* <tt>hrp</tt>: the human-readable part as a string +* <tt>data</tt>: the data part as a list of integers representing the characters after conversion using the table above + +<pre> +def bech32_polymod(values): + GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3] + chk = 1 + for v in values: + b = (chk >> 25) + chk = (chk & 0x1ffffff) << 5 ^ v + for i in range(5): + chk ^= GEN[i] if ((b >> i) & 1) else 0 + return chk + +def bech32_hrp_expand(s): + return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s] + +def bech32_verify_checksum(hrp, data): + return bech32_polymod(bech32_hrp_expand(hrp) + data) == 1 +</pre> + +This implements a [https://en.wikipedia.org/wiki/BCH_code BCH code] that +guarantees detection of '''any error affecting at most 4 characters''' +and has less than a 1 in 10<sup>9</sup> chance of failing to detect more +errors. More details about the properties can be found in the +Checksum Design appendix. The human-readable part is processed by first +feeding the higher bits of each character's US-ASCII value into the +checksum calculation followed by a zero and then the lower bits of each<ref>'''Why are the high bits of the human-readable part processed first?''' +This results in the actually checksummed data being ''[high hrp] 0 [low hrp] [data]''. This means that under the assumption that errors to the +human readable part only change the low 5 bits (like changing an alphabetical character into another), errors are restricted to the ''[low hrp] [data]'' +part, which is at most 89 characters, and thus all error detection properties (see appendix) remain applicable.</ref>. + +To construct a valid checksum given the human-readable part and (non-checksum) values of the data-part characters, the code below can be used: + +<pre> +def bech32_create_checksum(hrp, data): + values = bech32_hrp_expand(hrp) + data + polymod = bech32_polymod(values + [0,0,0,0,0,0]) ^ 1 + return [(polymod >> 5 * (5 - i)) & 31 for i in range(6)] +</pre> + +'''Error correction''' + +One of the properties of these BCH codes is that they can be used for +error correction. An unfortunate side effect of error correction is that +it erodes error detection: correction changes invalid inputs into valid +inputs, but if more than a few errors were made then the valid input may +not be the correct input. Use of an incorrect but valid input can cause +funds to be lost irrecoverably. Because of this, implementations SHOULD +NOT implement correction beyond potentially suggesting to the user where +in the string an error might be found, without suggesting the correction +to make. + +'''Uppercase/lowercase''' + +The lowercase form is used when determining a character's value for checksum purposes. + +Encoders MUST always output an all lowercase Bech32 string. +If an uppercase version of the encoding result is desired, (e.g.- for presentation purposes, or QR code use), +then an uppercasing procedure can be performed external to the encoding process. + +Decoders MUST NOT accept strings where some characters are uppercase and some are lowercase (such strings are referred to as mixed case strings). + +For presentation, lowercase is usually preferable, but inside QR codes uppercase SHOULD be used, as those permit the use of +''[http://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding alphanumeric mode]'', which is 45% more compact than the normal +''[http://www.thonky.com/qr-code-tutorial/byte-mode-encoding byte mode]''. + +===Segwit address format=== + +A segwit address<ref>'''Why not make an address format that is generic for all scriptPubKeys?''' +That would lead to confusion about addresses for +existing scriptPubKey types. Furthermore, if addresses that do not have a one-to-one mapping with scriptPubKeys (such as ECDH-based +addresses) are ever introduced, having a fully generic old address type available would +permit reinterpreting the resulting scriptPubKeys using the old address +format, with lost funds as a result if bitcoins are sent to them.</ref> is a Bech32 encoding of: + +* The human-readable part "bc"<ref>'''Why use 'bc' as human-readable part and not 'btc'?''' 'bc' is shorter.</ref> for mainnet, and "tb"<ref>'''Why use 'tb' as human-readable part for testnet?''' It was chosen to +be of the same length as the mainnet counterpart (to simplify +implementations' assumptions about lengths), but still be visually +distinct.</ref> for testnet. +* The data-part values: +** 1 value: the witness version +** A conversion of the the 2-to-40-byte witness program (as defined by [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) to base32: +*** Start with the bits of the witness program, most significant bit per byte first. +*** Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed. +*** Translate those bits to characters using the table above. + +'''Decoding''' + +Software interpreting a segwit address: +* MUST verify that the human-readable part is "bc" for mainnet and "tb" for testnet. +* MUST verify that the first decoded data value (the witness version) is between 0 and 16, inclusive. +* Convert the rest of the data to bytes: +** Translate the values to 5 bits, most significant bit first. +** Re-arrange those bits into groups of 8 bits. Any incomplete group at the end MUST be 4 bits or less, MUST be all zeroes, and is discarded. +** There MUST be between 2 and 40 groups, which are interpreted as the bytes of the witness program. + +Decoders SHOULD enforce known-length restrictions on witness programs. +For example, BIP141 specifies ''If the version byte is 0, but the witness +program is neither 20 nor 32 bytes, the script must fail.'' + +As a result of the previous rules, addresses are always between 14 and 74 characters long, and their length modulo 8 cannot be 0, 3, or 5. +Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version. + +Implementations should take special care when converting the address to a +scriptPubkey, where witness version ''n'' is stored as ''OP_n''. OP_0 is +encoded as 0x00, but OP_1 through OP_16 are encoded as 0x51 though 0x60 +(81 to 96 in decimal). If a bech32 address is converted to an incorrect +scriptPubKey the result will likely be either unspendable or insecure. + +===Compatibility=== + +Only new software will be able to use these addresses, and only for +receivers with segwit-enabled new software. In all other cases, P2SH or +P2PKH addresses can be used. + +==Rationale== + +<references /> + +==Reference implementations== + +* Reference encoder and decoder: +** [https://github.com/sipa/bech32/tree/master/ref/c For C] +** [https://github.com/sipa/bech32/tree/master/ref/c++ For C++] +** [https://github.com/sipa/bech32/tree/master/ref/javascript For JavaScript] +** [https://github.com/sipa/bech32/tree/master/ref/go For Go] +** [https://github.com/sipa/bech32/tree/master/ref/python For Python] +** [https://github.com/sipa/bech32/tree/master/ref/haskell For Haskell] +** [https://github.com/sipa/bech32/tree/master/ref/ruby For Ruby] +** [https://github.com/sipa/bech32/tree/master/ref/rust For Rust] + +* Fancy decoder that localizes errors: +** [https://github.com/sipa/bech32/tree/master/ecc/javascript For JavaScript] ([http://bitcoin.sipa.be/bech32/demo/demo.html demo website]) + +==Appendices== + +===Test vectors=== + +The following strings are valid Bech32: +* <tt>A12UEL5L</tt> +* <tt>a12uel5l</tt> +* <tt>an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs</tt> +* <tt>abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw</tt> +* <tt>11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j</tt> +* <tt>split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w</tt> +* <tt>?1ezyfcl</tt> WARNING: During conversion to US-ASCII some encoders may set unmappable characters to a valid US-ASCII character, such as '?'. For example: + +<pre> +>>> bech32_encode('\x80'.encode('ascii', 'replace').decode('ascii'), []) +'?1ezyfcl' +</pre> + +The following string are not valid Bech32 (with reason for invalidity): +* 0x20 + <tt>1nwldj5</tt>: HRP character out of range +* 0x7F + <tt>1axkwrx</tt>: HRP character out of range +* 0x80 + <tt>1eym55h</tt>: HRP character out of range +* <tt>an84characterslonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1569pvx</tt>: overall max length exceeded +* <tt>pzry9x0s0muk</tt>: No separator character +* <tt>1pzry9x0s0muk</tt>: Empty HRP +* <tt>x1b4n0q5v</tt>: Invalid data character +* <tt>li1dgmt3</tt>: Too short checksum +* <tt>de1lg7wt</tt> + 0xFF: Invalid character in checksum +* <tt>A1G7SGD8</tt>: checksum calculated with uppercase form of HRP +* <tt>10a06t8</tt>: empty HRP +* <tt>1qzzfhee</tt>: empty HRP + +The following list gives valid segwit addresses and the scriptPubKey that they +translate to in hex. +* <tt>BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4</tt>: <tt>0014751e76e8199196d454941c45d1b3a323f1433bd6</tt> +* <tt>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7</tt>: <tt>00201863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262</tt> +* <tt>bc1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7k7grplx</tt>: <tt>5128751e76e8199196d454941c45d1b3a323f1433bd6751e76e8199196d454941c45d1b3a323f1433bd6</tt> +* <tt>BC1SW50QA3JX3S</tt>: <tt>6002751e</tt> +* <tt>bc1zw508d6qejxtdg4y5r3zarvaryvg6kdaj</tt>: <tt>5210751e76e8199196d454941c45d1b3a323</tt> +* <tt>tb1qqqqqp399et2xygdj5xreqhjjvcmzhxw4aywxecjdzew6hylgvsesrxh6hy</tt>: <tt>0020000000c4a5cad46221b2a187905e5266362b99d5e91c6ce24d165dab93e86433</tt> + +The following list gives invalid segwit addresses and the reason for +their invalidity. +* <tt>tc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty</tt>: Invalid human-readable part +* <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5</tt>: Invalid checksum +* <tt>BC13W508D6QEJXTDG4Y5R3ZARVARY0C5XW7KN40WF2</tt>: Invalid witness version +* <tt>bc1rw5uspcuh</tt>: Invalid program length +* <tt>bc10w508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7kw5rljs90</tt>: Invalid program length +* <tt>BC1QR508D6QEJXTDG4Y5R3ZARVARYV98GJ9P</tt>: Invalid program length for witness version 0 (per BIP141) +* <tt>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sL5k7</tt>: Mixed case +* <tt>bc1zw508d6qejxtdg4y5r3zarvaryvqyzf3du</tt>: zero padding of more than 4 bits +* <tt>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3pjxtptv</tt>: Non-zero padding in 8-to-5 conversion +* <tt>bc1gmk9yu</tt>: Empty data section + +===Checksum design=== + +'''Design choices''' + +BCH codes can be constructed over any prime-power alphabet and can be chosen to have a good trade-off between +size and error-detection capabilities. While most work around BCH codes uses a binary alphabet, that is not a requirement. +This makes them more appropriate for our use case than [https://en.wikipedia.org/wiki/Cyclic_redundancy_check CRC codes]. Unlike +[https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction Reed-Solomon codes], +they are not restricted in length to one less than the alphabet size. While they also support efficient error correction, +the implementation of just error detection is very simple. + +We pick 6 checksum characters as a trade-off between length of the addresses and the error-detection capabilities, as 6 +characters is the lowest number sufficient for a random failure chance below 1 per billion. For the length of data +we're interested in protecting (up to 71 bytes for a potential future 40-byte witness +program), BCH codes can be constructed that guarantee detecting up to 4 errors. + +'''Selected properties''' + +Many of these codes perform badly when dealing with more errors than they are designed to detect, but not all. +For that reason, we consider codes that are designed to detect only 3 errors as well as 4 errors, +and analyse how well they perform in practice. + +The specific code chosen here is the result +of: +* Starting with an exhaustive list of 159605 BCH codes designed to detect 3 or 4 errors up to length 93, 151, 165, 341, 1023, and 1057. +* From those, requiring the detection of 4 errors up to length 71, resulting in 28825 remaining codes. +* From those, choosing the codes with the best worst-case window for 5-character errors, resulting in 310 remaining codes. +* From those, picking the code with the lowest chance for not detecting small numbers of ''bit'' errors. + +As a naive search would require over 6.5 * 10<sup>19</sup> checksum evaluations, a collision-search approach was used for +analysis. The code can be found [https://github.com/sipa/ezbase32/ here]. + +'''Properties''' + +The following table summarizes the chances for detection failure (as +multiples of 1 in 10<sup>9</sup>). + +{| class="wikitable" +|- +!colspan="2" | Window length +!colspan="6" | Number of wrong characters +|- +!Length +!Description +!≤4 +!5 +!6 +!7 +!8 +!≥9 +|- +| 8 || Longest detecting 6 errors || colspan="3" | 0 || 1.127 || 0.909 || n/a +|- +| 18 || Longest detecting 5 errors || colspan="2" | 0 || 0.965 || 0.929 || 0.932 || 0.931 +|- +| 19 || Worst case for 6 errors || 0 || 0.093 || 0.972 || 0.928 || colspan="2" | 0.931 +|- +| 39 || Length for a P2WPKH address || 0 || 0.756 || 0.935 || 0.932 || colspan="2" | 0.931 +|- +| 59 || Length for a P2WSH address || 0 || 0.805 || 0.933 || colspan="3" | 0.931 +|- +| 71 || Length for a 40-byte program address || 0 || 0.830 || 0.934 || colspan="3" | 0.931 +|- +| 89 || Longest detecting 4 errors || 0 || 0.867 || 0.933 || colspan="3" | 0.931 +|} +This means that when 5 changed characters occur randomly distributed in +the 39 characters of a P2WPKH address, there is a chance of +''0.756 per billion'' that it will go undetected. When those 5 changes +occur randomly within a 19-character window, that chance goes down to +''0.093 per billion''. As the number of errors goes up, the chance +converges towards ''1 in 2<sup>30</sup>'' = ''0.931 per billion''. + +Even though the chosen code performs reasonably well up to 1023 characters, +other designs are preferable for lengths above 89 characters (excluding the +separator). + +==Acknowledgements== + +This document is inspired by the [https://rusty.ozlabs.org/?p=578 address proposal] by Rusty Russell, the +[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html base32] proposal by Mark Friedenbach, and had input from Luke Dashjr, +Johnson Lau, Eric Lombrozo, Peter Todd, and various other reviewers. diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki new file mode 100644 index 0000000..b1f0aaf --- /dev/null +++ b/bip-0174.mediawiki @@ -0,0 +1,453 @@ +<pre> + BIP: 174 + Layer: Applications + Title: Partially Signed Bitcoin Transaction Format + Author: Andrew Chow <achow101@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174 + Status: Draft + Type: Standards Track + Created: 2017-07-12 + License: BSD-2-Clause +</pre> + +==Introduction== + +===Abstract=== + +This document proposes a binary transaction format which contains the information +necessary for a signer to produce signatures for the transaction and holds the +signatures for an input while the input does not have a complete set of signatures. +The signer can be offline as all necessary information will be provided in the +transaction. + +===Copyright=== + +This BIP is licensed under the 2-clause BSD license. + +===Motivation=== + +Creating unsigned or partially signed transactions to be passed around to multiple +signers is currently implementation dependent, making it hard for people who use +different wallet software from being able to easily do so. One of the goals of this +document is to create a standard and extensible format that can be used between clients to allow +people to pass around the same transaction to sign and combine their signatures. The +format is also designed to be easily extended for future use which is harder to do +with existing transaction formats. + +Signing transactions also requires users to have access to the UTXOs being spent. This transaction +format will allow offline signers such as air-gapped wallets and hardware wallets +to be able to sign transactions without needing direct access to the UTXO set and without +risk of being defrauded. + +==Specification== + +The Partially Signed Bitcoin Transaction (PSBT) format consists of key-value maps. +Each key-value pair must be unique within its scope; duplicates are not allowed. +Each map consists of a sequence of records, terminated by a <tt>0x00</tt> byte <ref>'''Why +is the separator here <tt>0x00</tt> instead of <tt>0xff</tt>?''' +The separator here is used to distinguish between each chunk of data. A separator of 0x00 would mean that +the unserializer can read it as a key length of 0, which would never occur with actual keys. It can thus +be used as a separator and allow for easier unserializer implementation.</ref>. The format +of a record is as follows: + +Note: <tt><..></tt> indicates that the data is prefixed by a compact size unsigned integer representing +the length of that data. <tt>{..}</tt> indicates the raw data itself. + +<pre> +<key>|<value> +</pre> + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Name +!Type +!Description +|- +| Key Length +| Compact Size Unsigned Integer +| Specify how long the key is +|- +| Key +| byte[] +| The key itself with the first byte being the type of the key-value pair +|- +| Value Length +| Compact Size Unsigned Integer +| Specify how long the value is +|- +| Value +| byte[] +| The Value itself +|} + +The format of each key-value map is as follows: + +<pre> +{key-value pair}|{key-value pair}|...|{0x00} +</pre> + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Field Size +!Name +!Type +!Value +!Description +|- +| 1+ +| Key-value pairs +| Array of key-value pairs +| varies +| The key-value pairs. +|- +| 1 +| separator +| char +| <tt>0x00</tt> +| Must be <tt>0x00</tt>. +|} + +The first byte of each key specifies the type of the key-value pair. Some types are +for global fields and other fields are for each input. The only required type in a +PSBT is the transaction type, as defined below. The currently defined global types are as follows: + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; +table-layout: fixed;" +!Number +!Name +!Key Data +!Value Data +!Format Example +|- +| <tt>0x00</tt> +| Transaction +| None. The key must only contain the 1 byte type. +| The transaction in network serialization. The scriptSigs and +witnesses for each input must be empty unless the input is complete. The transaction +must be in the witness serialization format as defined in BIP 144. A PSBT must have +a transaction, otherwise it is invalid. +| Key: +<pre> +{0x00} +</pre> +Value: +<pre> +{transaction} +</pre> +|- +| <tt>0x01</tt> +| Redeem Script<ref>'''Why are redeem scripts and witness scripts global''' Redeem + scripts and witness scripts are global data to avoid duplication. Instead of specifying + a redeems script and witness script multiple times in inputs that need those scripts, + they are specified once in the global data.</ref> +| The hash160 of the redeem script +| A redeem script that will be needed to sign a Pay-To-Script-Hash input or is spent +to by an output.<ref>'''Why are outputs' redeem scripts and witness scripts included?''' +Redeem scripts and witness scripts spent to by an output in this transaction are included +so that the user can verify that the transaction they are signing is creating the correct +outputs that have the correct redeem and witness scripts. This is best used when the +PSBT creator is not trusted by the signers.</ref> +| Key: +<pre> +{0x01}|{hash160} +</pre> +Value: +<pre> +{redeem script} +</pre> +|- +| <tt>0x02</tt> +| Witness Script +| The sha256 hash of the witness script +| A witness script that will be needed to sign a Pay-To-Witness-Script-Hash input or is spent +to by an output. +| Key: +<pre> +{0x02}|{sha256} +</pre> +Value: +<pre> +{witness script} +</pre> +|- +| <tt>0x03</tt> +| BIP 32 Derivation path, public key, and Master Key fingerprint +| The public key +| The master key fingerprint concatenated with the derivation path of the public key. The +derivation path is represented as 32 bit unsigned integer indexes concatenated +with each other. This must omit the index of the master key. +| Key: +<pre> +{0x03}|{public key} +</pre> +Value: +<pre> +{master key fingerprint}|{32-bit int}|...|{32-bit int} +</pre> +|- +| <tt>0x04</tt> +| Number of inputs +| None. The key must only contain the 1 byte type. +| A compact size unsigned integer representing the number of inputs that this transaction has +| Key: +<pre> +{0x04} +</pre> +Value: +<pre> +{number of inputs} +</pre> +|} + +The currently defined per-input types are defined as follows: + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; +table-layout: fixed;" +!Number +!Name +!Key Data +!Value Data +!Format Example +|- +| <tt>0x00</tt> +| Non-Witness UTXO +| None. The key must only contain the 1 byte type. +| The transaction in network serialization format the current input spends from. +| Key: +<pre> +{0x00} +</pre> +Value: +<pre> +{transaction} +</pre> +|- +| <tt>0x01</tt> +| Witness UTXO +| None. The key must only contain the 1 byte type. +| The entire transaction output in network serialization which the current input spends from. +| Key: +<pre> +{0x01} +</pre> +Value: +<pre> +{serialized transaction output({output value}|<scriptPubKey>)} +</pre> +|- +| <tt>0x02</tt> +| Partial Signature +| The public key which corresponds to this signature. +| The signature as would be pushed to the stack from a scriptSig or witness. +| Key: +<pre> +{0x02}|{public key} +</pre> +Value: +<pre> +{signature} +</pre> +|- +| <tt>0x03</tt> +| Sighash Type +| None. The key must only contain the 1 byte type. +| The 32-bit unsigned integer recommending a sighash type to be used for this input. +The sighash type is only a recommendation and the signer does not need to use +the sighash type specified. +| Key: +<pre> +{0x03} +</pre> +Value: +<pre> +{sighash type} +</pre> +|- +| <tt>0x04</tt> +| Input index +| None. The key must only contain the 1 byte type. +| A compact size unsigned integer representing the index of this input. This field +is optional to allow for completed inputs to be skipped without needing a separator byte. +If one input has this type, then all inputs must have it. +| Key: +<pre> +{0x04} +</pre> +Value: +<pre> +{input index} +</pre> +|} + +The transaction format is specified as follows: + + +<pre> + {0x70736274}|{0xff}|{global key-value map}|{input key-value map}|...|{input key-value map} +</pre> + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Field Size +!Name +!Type +!Value +!Description +|- +| 4 +| Magic Bytes +| int32_t +| <tt>0x70736274</tt> +| Magic bytes which are ASCII for psbt. <ref>'''Why use 4 bytes for psbt?''' The +transaction format needed to start with a 5 byte header which uniquely identifies +it. The first bytes were chosen to be the ASCII for psbt because that stands for +Partially Signed Bitcoin Transaction. </ref> This integer should be serialized +in most significant byte order. +|- +| 1 +| separator +| char +| <tt>0xff</tt> +| Must be <tt>0xff</tt> <ref>'''Why Use a separator after the magic bytes?''' The separator +is part of the 5 byte header for PSBT. This byte is a separator of <tt>0xff</tt> because +this will cause any non-PSBT unserializer to fail to properly unserialize the PSBT +as a normal transaction. Likewise, since the 5 byte header is fixed, no transaction +in the non-PSBT format will be able to be unserialized by a PSBT unserializer.</ref> +|- +| 1+ +| Global data +| Key-value Map +| varies +| The key-value pairs for all global data. +|- +| 1+ +| Inputs +| Array of key-value maps +| varies +| The key-value pairs for each input as described below +|} + +Each block of data between separators can be viewed as a scope, and all separators +are required<ref>'''Why are all separators required?''' The separators are required +so that the unserializer knows which input it is unserializing data for.</ref>. +Types can be skipped when they are unnecessary. For example, if an input is a witness +input, then it should not have a Non-Witness UTXO key-value pair. + +If the signer encounters key-value pairs that it does not understand, it must +pass those key-value pairs through when re-serializing the transaction. + +===Handling Duplicated Keys=== + +Keys within each scope should never be duplicated; all keys in the format are unique. However implementors +will still need to handle events where keys are duplicated, either duplicated in the transaction +itself or when combining transactions with duplicated fields. If duplicated keys are +encountered, the software may choose to use any of the values corresponding to that key. + +==Usage== + +Using the transaction format involves many different roles. The roles may be combined +into one entity, but each role has a specific set of things that it must be able to do. + +===Transaction Creator=== + +The transaction creator must be able to accept either a network serialized transaction or a PSBT +and either produce a PSBT or update the provided PSBT. For all scriptSigs which are not finalized, it must make the +scriptSig empty and fill in the input fields with information from the scriptSig, if any. +If it is able to, it should also look for any required redeemScripts and witnesScripts +and add those to the global data section of the PSBT. The transaction creator +should also fill in UTXOs that it knows about. + +===Transaction Signer=== + +The transaction signer must accept a PSBT. It should use the UTXOs provided in the PSBT +to produce signatures for the inputs that it can sign for. The signer should not need +access to the UTXO set as all necessary information is provided in the PSBT itself. +Any and all signatures created should be added as a Partial Signature key-value pair +to the input for which it corresponds to. + +The signer should also be able to compute the amount being spent, the amount being +transacted, the inputs being spent, the transaction fee, and the addresses being +paid. It can be interactive and ask the user for confirmation of all of the above things. + +===Transaction Combiner=== + +The transaction combiner must be able to accept multiple PSBTs. It should parse each +PSBT and merge them into one transaction if possible. If the PSBTs correspond to the +same transaction, then the combiner should create one PSBT which contains all of the +key-value pairs from the PSBTs. It should also handle duplicated keys and remove the +duplication according to the specification. + +===Transaction Finalizer=== + +The transaction finalizer must take a PSBT and build the finalized scriptSigs for each +input. If an input contains enough signatures for that input to have a complete set of +signatures, the finalizer should take those signatures, any necessary redeemScripts +and witnessScripts, and build the complete scriptSig. The scriptSig should then be +included in the transaction and the input should have all key-value pairs removed. +The finalizer may remove any global data which is not needed for any other inputs. + +===Transaction Broadcaster=== +The transaction broadcaster takes a finalized PSBT. It takes the transaction out of the +PSBT, ensures that the transaction is valid, and broadcasts it to the Bitcoin network. + +==Extensibility== + +The Partially Signed Transaction format can be extended in the future by adding +new types for key-value pairs. Backwards compatibilty will still be maintained as those new +types will be ignored and passed-through by signers which do not know about them. + +Additional key-value maps with different types for the key-value pairs can be added on to +the end of the format. The number of each map that follows must be specified in the globals +section so that parsers will know when to use different definitions of the data types. + +==Compatibility== + +This transaction format is designed so that it is unable to be properly unserialized +by normal transaction unserializers. Likewise, a normal transaction will not be +able to be unserialized by an unserializer for the PSBT format. + +==Examples== + +===Manual CoinJoin Workflow=== + +<img src="bip-0174/coinjoin-workflow.png" align="middle"></img> + +===2-of-3 Multisig Workflow=== + +<img src="bip-0174/multisig-workflow.png" align="middle"></img> + +==Test Vector== + +TBD + +==Rationale== + +<references/> + +==Reference implementation== + +The reference implementation of the PSBT format is available at https://github.com/achow101/bitcoin/tree/psbt. + +==Acknowledgements== + +Special thanks to Pieter Wuille for suggesting that such a transaction format should be made +and for coming up with the name and abbreviation of PSBT. + +Thanks to Pieter Wuille, Gregory Maxwell, Jonathan Underwood, and Daniel Cousens for additional comments +and suggestions for improving this proposal. + +==Appendix A: Data types and their specifications== + +Any data types, their associated scope and BIP number must be defined here + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Scope +!Type values +!BIP Number +|- +| Global +| 0,1,2,3,4 +| BIP 174 +|- +| Input +| 0,1,2,3,4 +| BIP 174 +|} diff --git a/bip-0174/coinjoin-workflow.png b/bip-0174/coinjoin-workflow.png Binary files differnew file mode 100644 index 0000000..0909c1d --- /dev/null +++ b/bip-0174/coinjoin-workflow.png diff --git a/bip-0174/multisig-workflow.png b/bip-0174/multisig-workflow.png Binary files differnew file mode 100644 index 0000000..0e752c5 --- /dev/null +++ b/bip-0174/multisig-workflow.png diff --git a/bip-0175.mediawiki b/bip-0175.mediawiki new file mode 100644 index 0000000..a3ffd1c --- /dev/null +++ b/bip-0175.mediawiki @@ -0,0 +1,259 @@ +<pre> + BIP: 175 + Layer: Applications + Title: Pay to Contract Protocol + Author: Omar Shibli <omar@commerceblock.com> + Nicholas Gregory <nicholas@commerceblock.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0175 + Status: Draft + Type: Informational + Created: 2017-07-17 + License: BSD-2-Clause +</pre> + +==Abstract== + +Utilizing hierarchical deterministic wallets as described in BIP-0032 and the "Purpose Field" in BIP-0043, this document specifies the multiparty pay-to-contract key derivation scheme outlined by Ilja Gerhardt and Timo Hanke.[0] + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + +==Motivation== + +A Bitcoin transaction represents a "real world" contract between two parties transferring value. Counterparties in a business interaction traditionally keep track of a payment with bills (invoices) and receipts. Delivery of a good is made by the payee once the payer has signed the receipt, agreeing to pay for the items on the invoice. Gerhardt and Hanke [0] formulate this interaction within the confines of the Bitcoin protocol using homomorphic payment addresses and the multiparty pay-to-contract protocol. + +The protocol is constructed in such a way that all parties have cryptographic proof of both who is being paid and for what. Using the technique described in this BIP, an address can be provably derived from the terms of a contract and the payee's public key. This derivation scheme does not bloat the UTXO and is completely hidden to network participants; the derived address looks like any other P2(W)PKH or P2(W)SH address. Redemption of the funds requires knowledge of the contract and the payee's private key. + +This scheme utilizes the foundations of BIP-0032, providing a consistent way for preexisting wallet developers to implement the specification. + +==Specification== + +This key derivation scheme requires two parties: a payer (customer) and a payee (merchant). +The customer submits to the merchant a purchase request, specifying what goods/services they would like to buy. From the purchase request the merchant constructs an invoice (contract), specifying the billable items and total amount to be paid. +The merchant must give this contract alongside a “payment base” extended public key to the customer. Given this information, the customer will be able to fulfill the contract by generating the public key of the payment address associated with the contract and the payment base, then sending the funds there. + +We define the following levels in BIP32 path: + +<code> +m / purpose' / coin_type' / contract_hash +</code> + +<code>contract_hash</code> consists of multiple levels. + +Apostrophe in the path indicates that BIP32 hardened derivation is used. + +We define the following extended public keys: + +Payment base denoted as <code>payment_base</code>: + + m / purpose' / coin_type' + +Payment address denoted as <code>payment_address</code>: + + m / purpose' / coin_type' / contract_hash + or + m / payment_base / contract_hash + +Each level has special meaning described in the chapters below. + +===Purpose=== + +Purpose is a constant set to <code>175'</code> (or <code>0x800000AF</code>) following the BIP-0043 recommendation. It indicates that the subtree of this node is used according to this specification. + +<code> +m / 175' / * +</code> + +Hardened derivation is used at this level. + +===Coin type=== + +The coin type field is identical to the same field in BIP-0044. + +Hardened derivation is used at this level. + +===Payment address generation=== + +For a given contract documents denoted by c<sub>1</sub>,...,c<sub>n</sub>, payment base extended public key denoted by <code>payment_base</code>, and cryptographic hash function denoted by <code>h</code>. + +1. Compute cryptographic hashes for all contract documents, by applying the hash function. + + h(c1),...,h(cn) + +2. Sort all hashes lexicographically. + + hash_1,...,hash_n + +3. Prepend payment_base and concatenate the sorted hashes and apply the hash function. + + h(payment_base+hash_1+...+hash_n) + +4. Compute a partial BIP32 derivation path from the combined hash as defined in Hash to Partial Derivation Path Mapping procedure below. + + contract_hash + +5. Prepend <code>payment_base</code> to contract_hash derivation path. + + payment_base / contract_hash + +6. Compute public extended key from the derivation path in step 5. + +7. Compute address of the public extended key (P2PKH) from step 6. + +===Payment address verification=== + +For a given Bitcoin address, <code>payment_base</code> extended public key, contract documents denoted by c<sub>1</sub>,...,c<sub>n</sub>, and cryptographic hash function denoted by <code>h</code>, we can verify the integrity of the address by the following steps: + +1. Compute contract address from the given inputs as described in Contract Address Generation section. + +2. Compare the computed address from step 1 with the given Bitcoin address as an input. + +===Redemption=== + +The merchant is able to construct the private key offline using the method described in the Payment Address Generation section. +The merchant should actively monitor the blockchain for the payment to the payment address. +Because the address is generated from the payment base and the contract, the merchant must implicitly agree to those terms in order to spend the funds. +The act of making the payment to that address thus serves as a receipt for the customer. + +===Hash to partial derivation path mapping=== + +At this section, we define hash to partial BIP32 derivation path mapping procedure that maps between an arbitrary hex number to a partial BIP32 derivation path. + +For a given hex number, do the following: + +1. Partition hex number into parts, each part length is 4 chars. + +2. Convert each part to integer in decimal format. + +3. Concatenate all numbers with slash <code>/</code>. + +==Examples== + +For the following given inputs: + + master private extended key: + xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73 + coin type: + 0 + +we can compute payment base as follows: + + payment base derivation path: + m/175'/0' + contract base public extended key: + xpub6B3JSEWjqm5GgfzcjPwBixxLPzi15pFM3jq4E4yCzXXUFS5MFdXiSdw7b5dbdPGHuc7c1V4zXbbFRtc9G1njMUt9ZvMdGVGYQSQsurD6HAW + +In the below examples, we are going to use SHA256 as a cryptographic hash function, and the above contract base public key. + +====Payment address generation==== + +As an input, we have a contract that consists of two documents, below are contents: + +document 1: + + bar + +document 2: + + foo + +1. Apply the hash function: + + document 1: + fcde2b2edba56bf408601fb721fe9b5c338d10ee429ea04fae5511b68fbf8fb9 + document 2: + 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae + +2. Sort all hashes lexicographically: + + 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae + fcde2b2edba56bf408601fb721fe9b5c338d10ee429ea04fae5511b68fbf8fb9 + +3. Concatenate hashes and apply the hash function. + + concatenated hash: payment_base + xpub6B3JSEWjqm5GgfzcjPwBixxLPzi15pFM3jq4E4yCzXXUFS5MFdXiSdw7b5dbdPGHuc7c1V4zXbbFRtc9G1njMUt9ZvMdGVGYQSQsurD6HAW2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7aefcde2b2edba56bf408601fb721fe9b5c338d10ee429ea04fae5511b68fbf8fb9 + combined hash: + 310057788c6073640dc222466d003411cd5c1cc0bf2803fc6ebbfae03ceb4451 + +4. Compute the partial BIP32 derivation path of the combined hash. + + 12544/22392/35936/29540/3522/8774/27904/13329/52572/7360/48936/1020/28347/64224/15595/17489 + +5. Prepend <code>payment_base</code> to <code>contract_hash</code> derivation path. + + contract_base_pub/12544/22392/35936/29540/3522/8774/27904/13329/52572/7360/48936/1020/28347/64224/15595/17489 + or + m/175'/0'/12544/22392/35936/29540/3522/8774/27904/13329/52572/7360/48936/1020/28347/64224/15595/17489 + +6. Compute public extended key. + + xpub6hefaATTG5LbcwyPDvmNfnkyzefoM2TJDoo5astH7Gvs1g8vZURviBWvAvBnWc2CNb8ybJ6mDpnQYVsvNSZ3oUmbssX3rUVG97TFYa6AXVk + +7. Compute address of the public extended key (P2PKH). + + 1C7f322izqMqLzZzfzkPAjxBzprxDi47Yf + + +====Verification example (negative test)==== + +Similar to the input above, except this time we have a contract that consists of one document, below is the content: + +document 1: + + baz + +1. Apply the hash function. + + baa5a0964d3320fbc0c6a922140453c8513ea24ab8fd0577034804a967248096 + +2. Prepend payment_base + + xpub6B3JSEWjqm5GgfzcjPwBixxLPzi15pFM3jq4E4yCzXXUFS5MFdXiSdw7b5dbdPGHuc7c1V4zXbbFRtc9G1njMUt9ZvMdGVGYQSQsurD6HAWbaa5a0964d3320fbc0c6a922140453c8513ea24ab8fd0577034804a967248096 + +2. Apply hash function + + 3a08605829413ce0bf551b08d21e4a28dbda6e407f90eff1c448e839050c73a1 + +3. Compute the partial derivation path. + + 5338/54412/19213/962/30664/62597/11873/59874/56779/24089/54550/19585/28087/36422/18666/17562 + +4. Prepend contract_base<sub>pub</sub> to contract_hash derivation path. + + contract_base_pub/5338/54412/19213/962/30664/62597/11873/59874/56779/24089/54550/19585/28087/36422/18666/17562 + or + m/175'/0'/5338/54412/19213/962/30664/62597/11873/59874/56779/24089/54550/19585/28087/36422/18666/17562 + +5. Compute public extended key. + + xpub6h9k2KqsMpwghxt7naj1puhGV1ZDC88sxvpYN1HibCf8yQZdPsuhYmmvdK32Kf2Lb3rS1sV8UcZ1f84DJEiXuVfLCAj4bC85aEUCxh38m8i + +7. Compute address of the public extended key (P2PKH). + + 1QGe5LaDMAmHeibJbZBmZqhQDZSp7QCqSs + +8. As expected the address doesn't match the Bitcoin address from the last example <code>1C7f322izqMqLzZzfzkPAjxBzprxDi47Yf</code>. + +Verification operation will succeed only if we use identical documents to ones that have been used in the contract address generation. + +==Compatibility== + +This specification is not backward compatible with BIP32 specification, the proposed derivation scheme in this BIP is a BIP32 compliant. +Communication between payer and payee as well as hashing the contract and generating the path requires significant modification to the wallet. + +==Reference implementations== + +* Reference wallet implementation, based on Copay project : https://github.com/commerceblock/copay ([[https://github.com/commerceblock/copay/pull/1|pull_request]]) +* Reference implementation to Hash to Partial Derivation Path Mapping in javascript ([[https://github.com/commerceblock/pay-to-contract-lib/blob/master/lib/contract.js|https://github.com/commerceblock/pay-to-contract-lib]]) + +==Reference== + +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] +* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] +* [[https://arxiv.org/abs/1212.3257|Homomorphic Payment Addresses and the Pay-to-Contract Protocol]] + +==Copyright== + +This BIP is licensed under the 2-clause BSD license. diff --git a/bip-0180.mediawiki b/bip-0180.mediawiki new file mode 100644 index 0000000..9f6bd18 --- /dev/null +++ b/bip-0180.mediawiki @@ -0,0 +1,149 @@ +<pre> + BIP: 180 + Layer: Peer Services + Title: Block size/weight fraud proof + Author: Luke Dashjr <luke+bip@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0180 + Status: Draft + Type: Standards Track + Created: 2017-03-17 + License: BSD-2-Clause +</pre> + +==Abstract== + +A fraud proof that enables light clients to detect oversized (or overweight) blocks. + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + +==Definitions== + +; full tx size proof : SHA2 midstate and tail data proving the size of the full transaction data being hashed. +; size component : Either a merkle link and height in the merkle tree thereof, or a full tx size proof. +; full-size proof : The set of size components proving the lower-bound size of the block. +; stripped-size proof : The set of size components proving the lower-bound size of the block when stripped of segwit witness data. + +==Specification== + +===Proof format=== + +* varint: ceil(log2(number of transactions in block)) +* varint: number of size components in stripped-size proof +* foreach: +** varint: ceil(log2(number of transactions represented by this size-component)) + 1 +** if zero: +*** (this indicates a full tx size proof) +*** 256-bit: SHA2 midstate up until just before the final SHA2 chunk +*** varint: total size of tx +*** uint8: size of final SHA2 chunk (0-55) +*** 0-55 bytes: final SHA2 chunk +** if one or more: +*** (this indicates default tx size counting) +*** 256-bit: SHA2 hash of merkle link +* varint: number of size components in full-size proof (zero in case of a size-exceeded proof; non-zero for a weight-exceeded proof) +* foreach: (same as with stripped-size proof) + +===Proof verification=== + +To verify an individual size proof: + +#Check that at least one size component is a full tx size proof. (At least one size component MUST be a full tx size proof.) +#Determine the lower-bound number of transactions in the block (lowTxCount). It is either <code>pow(ceil(log2(txcount)) - 1, 2)</code>, or the position of the last full tx proof (plus one, if using 0-based positions). Note that the last full tx proof from *either* of the size proofs (stripped-size and full-size) should be used here. +#Calculate the lower-bound transaction-data size as the default size * lowTxCount. +#For each full tx size proof: +##Subtract the default size it was presumed to consume, and add the claimed total size of tx. +##Take the SHA2 midstate, and update it with the final SHA2 chunk (which needs to be padded, including with the total tx size). The final SHA2 hash is the transaction id (stripped-size proof) or hash (full-size proof). +#For the full-size proof, replace the 60 byte default with any larger sizes proven from the stripped-size proof. +#Build the merkle root, and compare it to the block header (stripped-size proof) or witness commitment (full-size proof). Ensure when building the merkle root, that there are no duplicate merkle links, and each merkle link claims to represent the correct number of represented transactions. +#Add 80 bytes, plus the size of the tx-count varint, to the calculated lower-bound size. +#The calculated size is returned as the lower-bound possible size of the block. + +For the stripped-size proof, the default size of transactions is 60 bytes. +For the full-size proof, it is the size established by the stripped-size proof. + +To verify the complete weight proof: + +# Verify the stripped-size proof. Save the resulting lower-bound size (call it lowStrippedSize). +# Verify the full-size proof. Save the resulting lower-bound size (call it lowFullSize). +# Calculate minFullSize + (minStrippedSize * 3). This is the lower-bound block weight. +# Compare the lower-bound block weight to the applicable block weight limit. + +===Network protocol=== + +If a light client detects that one or more of its peers do not consider the block it knows to have the most work as their best block, it should inquire with all those peers for a fraud proof by sending a new message <code>getfraud</code>, with a block locator (between the last common block, and the presumed best tip) as the sole parameter (extra parameters should be ignored). + +Compatible nodes will respond with a (new) <code>fraud</code> message, which has 2-3 parameters: + +* uint256: The hash of the most recent block in the locator (or a parent thereof) that it has checked. In the event of an invalid block, this should be the exact invalid block's hash (post-invalid blocks should be treated as unchecked, even if the node has independently checked them for some reason). +* varint: Fraud proof type code +** 0 = Block is valid +** 1 = No fraud proof available +** 2 = Size/weight exceeded +* (For type 2) the fraud proof + +If none of the blocks in the locator are recognised, compatible nodes should send a <code>fraud</code> message with no parameters. +(To avoid this outcome, clients may include a known-common block in the locator.) + +In the event that the peer claims a block earlier than the client's tip is valid, the light client should prepare a new locator between that block and its tip, and rerequest <code>getfraud</code> until it has determined which block the peer rejects and why. + +Once a block is proven to be invalid, the light client should never consider any blockchain including it as a candidate for the best chain. +It should not recheck blocks known to be invalid, nor continue proving it from other nodes. +(To avoid doubt: the user MAY be given the opportunity to override any rejections, but should be warned of the implications of doing so.) + +If an invalid fraud proof is provided, the client SHOULD CONSIDER disconnecting and possibly banning the node providing it. +However, if any change has been made to the size/weight limits, that should be taken into consideration (eg, if the limit increases, an innocent node may prove a size smaller than the limit). + +==Information== + +===Creation of proofs=== + +Proofs should ideally use the smallest amount of data required to prove excess of the limit. +The most obvious mechanism in doing so, would be to include full tx size proofs for the largest transactions until the limit is exceeded. +However, in some cases, a smaller size may be accomplished by collapsing more merkle links. + +Because optimisation of proof size may be complicated, nodes are not required to implement it in any particular manner, so long as the proofs meet the requirements given above in [[#proof-verification|Proof verification]]. + +==Motivation== + +Recently, there have been proposals for hardforks to increase the block size limit. +While no consensus has been reached, proponents of these ideas often threaten and attempt to have miners force them through anyway. +As things presently are, light clients cannot detect invalid blocks at all, and could be fooled into accepting an invalid chain created in such a manner. +By supporting block size fraud proofs, light clients can protect their users from this form of unconsensual "hardfork" attempt. + +==Rationale== + +Why must a full tx size proof be included? + +* This is necessary to establish that the claimed block transaction count is not inflated. Otherwise, a prover could claim any number of represented transactions for merkle links, and rely on the default size alone to exceed the limit. + +How does the full tx size proof actually prove the size? + +* The first step of SHA2 hashing is to transform the input data into chunks (per [https://tools.ietf.org/html/rfc4634#section-4.1 RFC 4634]). The final chunk is required to include the absolute length of the input data at the end of the final chunk. Therefore, by committing to the midstate prior to the final chunk, and replaying only the final chunk, we can confirm that the claimed size matches the full transaction data being hashed. + +How does this prove the block weight? + +* The block weight defined by [[bip-0141.mediawiki|BIP 141]] is the size of the block stripped of its segwit signatures times 3, plus the full size of the block. By proving lower-bound sizes of both the stripped block and the full block, a lower-bound weight can also be calculated. + +Why is the number of transactions in the block represented as a log2? + +* To avoid attacks that rely on fooling clients by claiming an amount they cannot verify. + +Why does it matter if a full tx size proof is on the right side of a duplicate merkle link? + +* We assume full tx size proofs show the number of transactions in the block. This assumption doesn't hold if the proof is provided on the right-hand side of duplicate links. + +Why a fraud proof only for oversized/overweight blocks? + +* While it is currently believed to be impossible to prove all invalid (or rather, won't-be-part-of-the-main-chain) blocks, there are regularly active proposals of miners attacking with simply oversized blocks in an attempt to force a hardfork. This specific attack can be proven, and reliably so, since the proof cannot be broken without also breaking the attempted hardfork at the same time. + +==Backwards compatibility== + +These fraud proofs protect only clients which use them. +In non-attack scenarios, they are unnecessary and clients supporting them will otherwise behave as any other. + +==Reference implementation== + +TODO diff --git a/bip-0199.mediawiki b/bip-0199.mediawiki new file mode 100644 index 0000000..887804a --- /dev/null +++ b/bip-0199.mediawiki @@ -0,0 +1,81 @@ +<pre> + BIP: 199 + Layer: Applications + Title: Hashed Time-Locked Contract transactions + Author: Sean Bowe <sean@z.cash> + Daira Hopwood <daira@z.cash> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0199 + Status: Draft + Type: Standards Track + Created: 2017-03-27 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This BIP describes a script for generalized off-chain contract negotiation. + +==Summary== + +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 +a second party (the "buyer") to spend the funds after a timeout is reached, in a refund situation. + +The script takes the following form: + + OP_IF + [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash> + OP_ELSE + <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash> + OP_ENDIF + OP_EQUALVERIFY + OP_CHECKSIG + +[HASHOP] is either OP_SHA256 or OP_HASH160. + +[TIMEOUTOP] is either OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY. + +===Interaction=== + +* Victor (the "buyer") and Peggy (the "seller") exchange public keys and mutually agree upon a timeout threshold. Peggy provides a hash digest. Both parties can now +construct the script and P2SH address for the HTLC. +* Victor sends funds to the P2SH address. +* Either: +** Peggy spends the funds, and in doing so, reveals the preimage to Victor in the transaction; OR +** Victor recovers the funds after the timeout threshold. + +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 +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 +not enter the blockchain before Victor's but does reveal the preimage to Victor anyway. + +==Motivation== + +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 +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 +opportunity that the possessor of a secret has to receive the funds before such a refund can occur. + +===Lightning network=== + +In the lightning network, HTLC scripts are used to perform atomic swaps between payment channels. + +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 +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 +at any point some parties become uncooperative, the process can be aborted via the refund conditions. + +===Zero-knowledge contingent payments=== + +Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a +zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See +[https://github.com/zcash/pay-to-sudoku pay-to-sudoku] for a concrete example of such a protocol.) + +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. + +==Implementation== + +https://github.com/bitcoin/bitcoin/pull/7601 + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. + diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl index 981346b..144ede6 100755 --- a/scripts/buildtable.pl +++ b/scripts/buildtable.pl @@ -9,7 +9,6 @@ my %RequiredFields = ( BIP => undef, Title => undef, Author => undef, - 'Comments-Summary' => undef, 'Comments-URI' => undef, Status => undef, Type => undef, @@ -20,6 +19,7 @@ my %MayHaveMulti = ( Author => undef, 'Comments-URI' => undef, License => undef, + 'License-Code' => undef, 'Post-History' => undef, ); my %DateField = ( @@ -86,7 +86,8 @@ my %DefinedLicenses = ( 'PD' => undef, ); my %GrandfatheredPD = map { $_ => undef } qw(9 36 37 38 42 49 50 60 65 67 69 74 80 81 83 90 99 105 107 109 111 112 113 114 122 124 125 126 130 131 132 133 140 141 142 143 144 146 147 150 151 152); -my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 30 31 32 33 34 35 39 43 44 45 47 61 62 64 66 68 70 71 72 73 101 102 103 106 120 121 123); +my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 31 33 34 35 39 43 44 45 47 61 64 68 70 71 72 73 101 102 106 120 121); +my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173); my %emails; @@ -107,6 +108,7 @@ while (++$bipnum <= $topbip) { $field = $1; $val = $2; die "Duplicate $field field in $fn" if exists $found{$field}; + die "Too many spaces in $fn" if $val =~ /^\s/; } elsif (m[^ ( +)(.*\S)$]) { die "Continuation of non-field in $fn" unless defined $field; die "Too many spaces in $fn" if length $1 != 2 + length $field; @@ -120,6 +122,8 @@ while (++$bipnum <= $topbip) { die "$fn claims to be BIP $val" if $val ne $bipnum; } elsif ($field eq 'Title') { $title = $val; + my $title_len = length($title); + die "$fn has too-long TItle ($title_len > 44 char max)" if $title_len > 44 and not exists $TolerateTitleTooLong{$bipnum}; } elsif ($field eq 'Author') { $val =~ m/^(\S[^<@>]*\S) \<([^@>]*\@[\w.]+\.\w+)\>$/ or die "Malformed Author line in $fn"; my ($authorname, $authoremail) = ($1, $2); @@ -146,14 +150,15 @@ while (++$bipnum <= $topbip) { } elsif ($field eq 'Layer') { # BIP 123 die "Invalid layer $val in $fn" unless exists $ValidLayer{$val}; $layer = $val; - } elsif ($field eq 'License') { + } elsif ($field =~ /^License(?:\-Code)?$/) { die "Undefined license $val in $fn" unless exists $DefinedLicenses{$val}; - if (not $found{License}) { + if (not $found{$field}) { die "Unacceptable license $val in $fn" unless exists $AcceptableLicenses{$val} or ($val eq 'PD' and exists $GrandfatheredPD{$bipnum}); } } elsif ($field eq 'Comments-URI') { if (not $found{'Comments-URI'}) { - die unless $val eq sprintf('https://github.com/bitcoin/bips/wiki/Comments:BIP-%04d', $bipnum); + my $first_comments_uri = sprintf('https://github.com/bitcoin/bips/wiki/Comments:BIP-%04d', $bipnum); + die "First Comments-URI must be exactly \"$first_comments_uri\" in $fn" unless $val eq $first_comments_uri; } } elsif (exists $DateField{$field}) { die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0\d|1[012])\-(?:[012]\d|30|31)$/; |
