diff options
118 files changed, 13312 insertions, 173 deletions
diff --git a/README.mediawiki b/README.mediawiki index 1398ca3..c8a1596 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1,8 +1,8 @@ -People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Luke Dashjr <luke_bipeditor@dashjr.org>. After copy-editing and acceptance, it will be published here. +People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list. After discussion, please open a PR. After copy-editing and acceptance, it will be published here. 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]] | @@ -216,13 +223,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Marek Palatinus | Standard | BIP number allocated -|- +|- style="background-color: #cfffcf" | [[bip-0042.mediawiki|42]] | Consensus (soft fork) | A finite monetary supply for Bitcoin | Pieter Wuille | Standard -| Draft +| Final |- | [[bip-0043.mediawiki|43]] | Applications @@ -251,13 +258,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Justus Ranvier | Informational | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0049.mediawiki|49]] | Applications | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | Daniel Weigl | Informational -| Draft +| Final |- style="background-color: #cfffcf" | [[bip-0050.mediawiki|50]] | @@ -364,20 +371,27 @@ Those proposing changes should consider that ultimately consent may rest with th | Stephen Pair | Standard | Final -|- +|- style="background-color: #ffcfcf" | [[bip-0074.mediawiki|74]] | Applications | Allow zero value OP_RETURN in Payment Protocol | Toby Padilla | Standard -| Draft -|- +| Rejected +|- style="background-color: #cfffcf" | [[bip-0075.mediawiki|75]] | Applications | Out of Band Address Exchange using Payment Protocol Encryption | Justin Newton, Matt David, Aaron Voisine, James MacWhyte | Standard -| Draft +| Final +|- style="background-color: #ffffcf" +| [[bip-0079.mediawiki|79]] +| Applications +| Bustapay :: a practical coinjoin protocol +| Ryan Havar +| Informational +| Proposed |- | [[bip-0080.mediawiki|80]] | @@ -400,12 +414,33 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0084.mediawiki|84]] +| Applications +| Derivation scheme for P2WPKH based accounts +| Pavol Rusnak +| Informational +| Draft +|- | [[bip-0090.mediawiki|90]] -| Consensus (hard fork) +| | Buried Deployments | Suhas Daftuar | Informational | Draft +|- style="background-color: #cfffcf" +| [[bip-0091.mediawiki|91]] +| Consensus (soft fork) +| Reduced threshold Segwit MASF +| James Hilliard +| Standard +| Final +|- +| [[bip-0098.mediawiki|98]] +| Consensus (soft fork) +| Fast Merkle Trees +| Mark Friedenbach, Kalle Alm, BtcDrak +| Standard +| Draft |- | [[bip-0099.mediawiki|99]] | @@ -498,19 +533,47 @@ 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-0116.mediawiki|116]] +| Consensus (soft fork) +| MERKLEBRANCHVERIFY +| Mark Friedenbach, Kalle Alm, BtcDrak +| Standard +| Draft +|- +| [[bip-0117.mediawiki|117]] +| Consensus (soft fork) +| Tail Call Execution Semantics +| Mark Friedenbach, Kalle Alm, BtcDrak +| Standard +| Draft +|- +| [[bip-0118.mediawiki|118]] +| Consensus (soft fork) +| SIGHASH_NOINPUT +| Christian Decker +| Standard +| Draft +|- style="background-color: #ffcfcf" | [[bip-0120.mediawiki|120]] | Applications | Proof of Payment | Kalle Rosenbaum | Standard -| Draft -|- +| Withdrawn +|- style="background-color: #ffcfcf" | [[bip-0121.mediawiki|121]] | Applications | Proof of Payment URI scheme | Kalle Rosenbaum | Standard -| Draft +| Withdrawn |- | [[bip-0122.mediawiki|122]] | Applications @@ -546,6 +609,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Kristov Atlas | Informational | Draft +|- +| [[bip-0127.mediawiki|127]] +| Applications +| Simple Proof-of-Reserves Transactions +| Steven Roose +| Standard +| Draft |- style="background-color: #ffffcf" | [[bip-0130.mediawiki|130]] | Peer Services @@ -582,47 +652,68 @@ 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-0136.mediawiki|136]] +| Applications +| Bech32 Encoded Tx Position References +| Велеслав, Jonas Schnelli, Daniel Pape +| Informational +| Draft +|- style="background-color: #cfffcf" +| [[bip-0137.mediawiki|137]] +| Applications +| Signatures of Messages using Private Keys +| Christopher Gilliard +| Standard +| Final +|- | [[bip-0140.mediawiki|140]] | Consensus (soft fork) | Normalized TXID | Christian Decker | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0141.mediawiki|141]] | Consensus (soft fork) | Segregated Witness (Consensus layer) | Eric Lombrozo, Johnson Lau, Pieter Wuille | Standard -| Draft -|- +| Final +|- style="background-color: #ffcfcf" | [[bip-0142.mediawiki|142]] | Applications | Address Format for Segregated Witness | Johnson Lau | Standard -| Deferred -|- +| Withdrawn +|- style="background-color: #cfffcf" | [[bip-0143.mediawiki|143]] | Consensus (soft fork) | Transaction Signature Verification for Version 0 Witness Program | Johnson Lau, Pieter Wuille | Standard -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0144.mediawiki|144]] | Peer Services | Segregated Witness (Peer Services) | Eric Lombrozo, Pieter Wuille | Standard -| Draft -|- +| Final +|- 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) @@ -630,13 +721,27 @@ Those proposing changes should consider that ultimately consent may rest with th | Johnson Lau, Pieter Wuille | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0147.mediawiki|147]] | Consensus (soft fork) | Dealing with dummy stack element malleability | Johnson Lau | Standard -| Draft +| Final +|- 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 @@ -644,13 +749,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Jonas Schnelli | Standard | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0151.mediawiki|151]] | Peer Services | Peer-to-Peer Communication Encryption | Jonas Schnelli | Standard -| Draft +| Withdrawn |- | [[bip-0152.mediawiki|152]] | Peer Services @@ -658,6 +763,139 @@ 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-0155.mediawiki|155]] +| Peer Services +| addrv2 message +| Wladimir J. van der Laan +| Standard +| Draft +|- +| [[bip-0156.mediawiki|156]] +| Peer Services +| Dandelion - Privacy Enhancing Routing +| Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod Viswanath +| Standard +| Draft +|- +| [[bip-0157.mediawiki|157]] +| Peer Services +| Client Side Block Filtering +| Olaoluwa Osuntokun, Alex Akselrod, Jim Posen +| Standard +| Draft +|- +| [[bip-0158.mediawiki|158]] +| Peer Services +| Compact Block Filters for Light Clients +| Olaoluwa Osuntokun, Alex Akselrod +| 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 +|- style="background-color: #cfffcf" +| [[bip-0173.mediawiki|173]] +| Applications +| Base32 address format for native v0-16 witness outputs +| Pieter Wuille, Greg Maxwell +| Informational +| Final +|- style="background-color: #ffffcf" +| [[bip-0174.mediawiki|174]] +| Applications +| Partially Signed Bitcoin Transaction Format +| Andrew Chow +| Standard +| Proposed +|- +| [[bip-0175.mediawiki|175]] +| Applications +| Pay to Contract Protocol +| Omar Shibli, Nicholas Gregory +| Informational +| Draft +|- +| [[bip-0176.mediawiki|176]] +| +| Bits Denomination +| Jimmy Song +| Informational +| Draft +|- +| [[bip-0178.mediawiki|178]] +| Applications +| Version Extended WIF +| Karl-Johan Alm +| Standard +| Draft +|- +| [[bip-0180.mediawiki|180]] +| Peer Services +| Block size/weight fraud proof +| Luke Dashjr +| Standard +| Draft +|- +| [[bip-0197.mediawiki|197]] +| Applications +| Hashed Time-Locked Collateral Contract +| Matthew Black, Tony Cai +| Standard +| Draft +|- +| [[bip-0199.mediawiki|199]] +| Applications +| Hashed Time-Locked Contract transactions +| Sean Bowe, Daira Hopwood +| Standard +| Draft +|- +| [[bip-0301.mediawiki|301]] +| Consensus (soft fork) +| Blind Merged Mining (Consensus layer) +| Paul Sztorc, CryptAxe +| Standard +| Draft +|- +| [[bip-0310.mediawiki|310]] +| Applications +| Stratum protocol extensions +| Pavel Moravec, Jan Čapek +| Informational +| Draft +|- +| [[bip-0320.mediawiki|320]] +| +| nVersion bits for general purpose use +| BtcDrak +| Standard +| Draft +|- +| [[bip-0322.mediawiki|322]] +| Applications +| Generic Signed Message Format +| Karl-Johan Alm +| Standard +| Draft |} <!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --> diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki index ea60d1d..3bf5aec 100644 --- a/bip-0002.mediawiki +++ b/bip-0002.mediawiki @@ -208,7 +208,7 @@ Peer services BIPs should be observed to be adopted by at least 1% of public lis API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications. -Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs Bitcoin Wallet for Android's wallet/README.specs file]. +Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/bitcoin-wallet/bitcoin-wallet/blob/master/wallet/README.specs.md Bitcoin Wallet for Android's wallet/README.specs.md file]. These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status. @@ -240,7 +240,7 @@ What if a single merchant wishes to block a hard-fork? How about a small number of merchants (maybe only two) who sell products to each other? -* In this scenario, it would seem the previous Bitcoin is alive any working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP. +* In this scenario, it would seem the previous Bitcoin is alive and working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP. How can economic agreement veto a soft-fork? 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-0009/assignments.mediawiki b/bip-0009/assignments.mediawiki index 6a12e79..c6a8f00 100644 --- a/bip-0009/assignments.mediawiki +++ b/bip-0009/assignments.mediawiki @@ -29,7 +29,7 @@ State can be defined, active, failed. Dates are in UTC. | 1 | 2016-11-15 00:00:00 | 2017-11-15 00:00:00 -| - +| active since #481824 | 2016-05-01 00:00:00 | 2017-05-01 00:00:00 | active since #834624 diff --git a/bip-0011.mediawiki b/bip-0011.mediawiki index bb0a308..e5052eb 100644 --- a/bip-0011.mediawiki +++ b/bip-0011.mediawiki @@ -38,7 +38,7 @@ OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig: (OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack). -The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to 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. ==Rationale== diff --git a/bip-0013.mediawiki b/bip-0013.mediawiki index 9805ed0..70be90d 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] @@ -50,7 +50,7 @@ This proposal is not backwards compatible, but it fails gracefully-- if an older ==Reference Implementation== -See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src +See base58.cpp/base58.h at https://github.com/bitcoin/bitcoin/tree/master/src ==See Also== diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki index d5d39ef..0f4fb81 100644 --- a/bip-0016.mediawiki +++ b/bip-0016.mediawiki @@ -40,7 +40,7 @@ The rules for validating these outpoints when relaying transactions or consideri # Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint. # {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey. -These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transaction earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details). +These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transactions earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details). For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: @@ -101,7 +101,7 @@ If a majority of hashing power does not support the new validation rules, then r ===520-byte limitation on serialized script size=== -As a consequence of the requirement for backwards compatiblity the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes. +As a consequence of the requirement for backwards compatibility the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes. ==Reference Implementation== diff --git a/bip-0016/qa.mediawiki b/bip-0016/qa.mediawiki index 6a8a08d..1edf28e 100644 --- a/bip-0016/qa.mediawiki +++ b/bip-0016/qa.mediawiki @@ -1,4 +1,4 @@ -This page is a Quality Assurance test plan for [[BIP 16]]. If you see a test missing, please add it. +This page is a Quality Assurance test plan for [[../bip-0016.mediawiki|BIP 16]]. If you see a test missing, please add it. If you can help test, please edit this page to sign-off on it. {| class="wikitable" 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 a63b737..b653ba6 100644 --- a/bip-0030.mediawiki +++ b/bip-0030.mediawiki @@ -12,7 +12,7 @@ </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== diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index a4c1b96..18b3b0c 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -3,6 +3,7 @@ RECENT CHANGES: * (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 * (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions. +* (24 Feb 2017) Added test vectors for hardened derivation with leading zeros <pre> BIP: 32 @@ -121,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. @@ -155,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=== @@ -259,11 +260,23 @@ 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: -PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for dealing with Bitcoin that includes BIP0032 wallet features. BIP32Utils (https://github.com/jmcorgan/bip32utils) is a library and command line interface specifically focused on BIP0032 wallets and scripting. +PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for dealing with Bitcoin that includes BIP0032 wallet features. BIP32Utils (https://pypi.org/project/bip32utils/) is a library and command line interface specifically focused on BIP0032 wallets and scripting. 2 Java implementations exist: https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java and https://github.com/bushidowallet/bushido-java-core/tree/master/src/main/java/com/bushidowallet/core/bitcoin/bip32 @@ -279,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..af76d59 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,12 @@ http://github.com/trezor/python-mnemonic ==Other Implementations== +Go: +* https://github.com/tyler-smith/go-bip39 + +Elixir: +* https://github.com/izelnakri/mnemonic + Objective-C: * https://github.com/nybex/NYMnemonic @@ -152,3 +158,16 @@ JavaScript: Ruby: * https://github.com/sreekanthgs/bip_mnemonic + +Rust: +* https://github.com/infincia/bip39-rs + +Swift: +* https://github.com/CikeQiu/CKMnemonic +* https://github.com/yuzushioh/WalletKit + +C++: +* https://github.com/libbitcoin/libbitcoin-system/blob/master/include/bitcoin/system/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 5b4a1de..0940f35 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/bip-0039/bip-0039-wordlists.md @@ -1,7 +1,8 @@ -#Wordlists +# Wordlists * [English](english.txt) * [Japanese](japanese.txt) +* [Korean](korean.txt) * [Spanish](spanish.txt) * [Chinese (Simplified)](chinese_simplified.txt) * [Chinese (Traditional)](chinese_traditional.txt) @@ -9,22 +10,22 @@ * [Italian](italian.txt) * [Czech](czech.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). @@ -32,19 +33,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. @@ -66,7 +67,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. @@ -77,9 +78,9 @@ 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/french.txt b/bip-0039/french.txt index 8600949..1d74990 100644 --- a/bip-0039/french.txt +++ b/bip-0039/french.txt @@ -1,4 +1,4 @@ -abaisser +abaisser abandon abdiquer abeille @@ -2045,4 +2045,4 @@ yacht zèbre zénith zeste -zoologie
\ No newline at end of file +zoologie 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..223076f 100644 --- a/bip-0042.mediawiki +++ b/bip-0042.mediawiki @@ -3,9 +3,9 @@ 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 + Status: Final Type: Standards Track Created: 2014-04-01 License: PD diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index b13ba54..4ddd56b 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 @@ -263,14 +263,6 @@ is required and a pull request to the above file should be created. |m / 44' / 1' / 1' / 1 / 1 |} -==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]]) ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] diff --git a/bip-0045.mediawiki b/bip-0045.mediawiki index d364784..f4d200c 100644 --- a/bip-0045.mediawiki +++ b/bip-0045.mediawiki @@ -62,7 +62,7 @@ Hardened derivation is used at this level. The index of the party creating a P2SH multisig address. The indices can be determined independently by lexicographically sorting the purpose public -keys of each cosigner. Each cosigner creates addresses on it's own branch, +keys of each cosigner. Each cosigner creates addresses on its own branch, even though they have independent extended master public key, as explained in the "Address generation" section. @@ -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 @@ -244,7 +244,7 @@ requested by the corresponding cosigner. | m / 45' / 2 / 1 / 9 |} -==Compatible walets== +==Compatible wallets== * [[https://copay.io|Copay wallet]] ([[https://github.com/bitpay/copay|source]]) 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-0049.mediawiki b/bip-0049.mediawiki index 109fde8..0029003 100644 --- a/bip-0049.mediawiki +++ b/bip-0049.mediawiki @@ -2,10 +2,10 @@ BIP: 49 Layer: Applications Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts - Author: Daniel Weigl <Daniel.Weigl@mycelium.com> + Author: Daniel Weigl <DanielWeigl@gmx.at> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0049 - Status: Draft + Status: Final Type: Informational Created: 2016-05-19 License: PD @@ -20,19 +20,19 @@ This BIP defines the derivation scheme for HD wallets using the P2WPKH-nested-in With the usage of P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]) transactions it is necessary to have a common derivation scheme. It allows the user to use different HD wallets with the same masterseed and/or a single account seamlessly. -Thus the user needs to create a dedicated segregate witness accounts, which ensures that only wallets compatible with this BIP -will detect the account and handle them appropriately. +Thus the user needs to create dedicated segregated witness accounts, which ensures that only wallets compatible with this BIP +will detect the accounts and handle them appropriately. ===Considerations=== Two generally different approaches are possible for current BIP44 capable wallets: -1) Allow the user to use the same account(s) that they already uses, but add segregated witness encoded addresses to it +1) Allow the user to use the same account(s) that they already uses, but add segregated witness encoded addresses to it. 1.1) Use the same public keys as defined in BIP44, but in addition to the normal P2PKH address also derive the P2SH address from it. 1.2) Use the same account root, but branch off and derive different external and internal chain roots to derive dedicated public keys for the segregated witness addresses. -2) Create dedicated accounts only used for segregated witness addresses. +2) Create dedicated accounts used only for segregated witness addresses. The solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP49-compatible wallet masterseed into/in a non-BIP49-compatible wallet, the account might show up but also it might miss some UTXOs. @@ -53,7 +53,7 @@ serialization method. m / purpose' / coin_type' / account' / change / address_index </pre> -For the `purpose`-path level it uses `49'`. The rest of the levels are used as defined in BIP44 +For the `purpose`-path level it uses `49'`. The rest of the levels are used as defined in BIP44. ===Address derivation=== @@ -66,19 +66,28 @@ To derive the P2SH address from the above calculated public key, we use the enca scriptPubKey: HASH160 <20-byte-script-hash> EQUAL (0xA914{20-byte-script-hash}87) + +===Extended Key Version=== + +When serializing extended keys, this scheme uses alternate version bytes. Extended public keys use <code>0x049d7cb2</code> to produce a "ypub" prefix, and private keys use <code>0x049d7878</code> to produce a "yprv" prefix. Testnet uses <code>0x044a5262</code> "upub" and <code>0x044a4e28</code> "uprv." + +Additional registered version bytes are listed in [[https://github.com/satoshilabs/slips/blob/master/slip-0132.md|SLIP-0132]]. + + ==Backwards Compatibility== -This BIP is not backwards compatible by design as described under [#considerations]. A not compatible wallet will not discover accounts at all and the user will notice that something is wrong. +This BIP is not backwards compatible by design as described under [[#considerations|considerations]]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong. ==Test vectors== <pre> masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about - masterseed = tprv8ZgxMBicQKsPe5YMU9gHen4Ez3ApihUfykaqUorj9t6FDqy3nP6eoXiAo2ssvpAjoLroQxHqr3R5nE3a5dU3DHTjTgJDd7zrbniJr6nrCzd (testnet) + masterseed = uprv8tXDerPXZ1QsVNjUJWTurs9kA1KGfKUAts74GCkcXtU8GwnH33GDRbNJpEqTvipfCyycARtQJhmdfWf8oKt41X9LL1zeD2pLsWmxEk3VAwd (testnet) // Account 0, root = m/49'/1'/0' - account0Xpriv = tprv8gRrNu65W2Msef2BdBSUgFdRTGzC8EwVXnV7UGS3faeXtuMVtGfEdidVeGbThs4ELEoayCAzZQ4uUji9DUiAs7erdVskqju7hrBcDvDsdbY (testnet) + account0Xpriv = uprv91G7gZkzehuMVxDJTYE6tLivdF8e4rvzSu1LFfKw3b2Qx1Aj8vpoFnHdfUZ3hmi9jsvPifmZ24RTN2KhwB8BfMLTVqaBReibyaFFcTP1s9n (testnet) + account0Xpub = upub5EFU65HtV5TeiSHmZZm7FUffBGy8UKeqp7vw43jYbvZPpoVsgU93oac7Wk3u6moKegAEWtGNF8DehrnHtv21XXEMYRUocHqguyjknFHYfgY (testnet) // Account 0, first receiving private key = m/49'/1'/0'/0/0 account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ 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..b08739d 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 @@ -83,7 +83,7 @@ the reject message, "client" is the peer that will receive the message. ==== reject version codes ==== -Codes generated during the intial connection process in response to a "version" message: +Codes generated during the initial connection process in response to a "version" message: {| | Code || Description diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index 904dc16..1365884 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. @@ -136,7 +136,7 @@ transaction is created, tx3, to ensure that should the payee vanish the payor can get their deposit back. The process by which the refund transaction is created is currently vulnerable to transaction malleability attacks, and additionally, requires the payor to store the refund. Using the same -scriptPubKey from as in the Two-factor wallets example solves both these issues. +scriptPubKey form as in the Two-factor wallets example solves both these issues. ===Trustless Payments for Publishing Data=== @@ -312,20 +312,24 @@ time. ==References== -PayPub - https://github.com/unsystem/paypub +PayPub -Jeremy Spilman Payment Channels - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html +* https://github.com/unsystem/paypub + +Jeremy Spilman Payment Channels + +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html ==Implementations== Python / python-bitcoinlib -- https://github.com/petertodd/checklocktimeverify-demos +* https://github.com/petertodd/checklocktimeverify-demos JavaScript / Node.js / bitcore -- https://github.com/mruddy/bip65-demos +* https://github.com/mruddy/bip65-demos ==Copyright== diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki index a47c82d..936d507 100644 --- a/bip-0066.mediawiki +++ b/bip-0066.mediawiki @@ -37,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) { @@ -142,3 +142,6 @@ An implementation for the reference client is available at https://github.com/bi This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well. +==Disclosures== + +* Subsequent to the network-wide adoption and enforcement of this BIP, the author [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html disclosed] that strict DER signatures provided an indirect solution to a consensus bug he had previously discovered. diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki index f262126..3aa9463 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] @@ -83,7 +78,7 @@ N.B. All comparisons do not need to operate in constant time since they are not ===Transaction Inputs=== -Transaction inputs are defined by the hash of a previous transaction, the output index of of a UTXO from that previous transaction, the size of an unlocking script, the unlocking script, and a sequence number. [3] +Transaction inputs are defined by the hash of a previous transaction, the output index of a UTXO from that previous transaction, the size of an unlocking script, the unlocking script, and a sequence number. [3] For sorting inputs, the hash of the previous transaction and the output index within that transaction are sufficient for sorting purposes; each transaction hash has an extremely high probability of being unique in the blockchain — this is enforced for coinbase transactions by BIP30 — and output indices within a transaction are unique. For the sake of efficiency, transaction hashes should be compared first before output indices, since output indices from different transactions are often equivalent, while all bytes of the transaction hash are effectively random variables. @@ -92,7 +87,7 @@ In the event of two matching transaction hashes, the respective previous output If the previous output indices match, the inputs are considered equal. Transaction malleability will not negatively impact the correctness of this process. -Even if a wallet client follows this process using unconfirmed UTXOs as inputs and an attacker changes modifies the blockchain’s record of the hash of the previous transaction, the wallet client will include the invalidated previous transaction hash in its input data, and will still correctly sort with respect to that invalidated hash. +Even if a wallet client follows this process using unconfirmed UTXOs as inputs and an attacker modifies the blockchain’s record of the hash of the previous transaction, the wallet client will include the invalidated previous transaction hash in its input data, and will still correctly sort with respect to that invalidated hash. ===Transaction Outputs=== diff --git a/bip-0074.mediawiki b/bip-0074.mediawiki index d1f1a23..b6e9b39 100644 --- a/bip-0074.mediawiki +++ b/bip-0074.mediawiki @@ -3,9 +3,9 @@ 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 + Status: Rejected Type: Standards Track Created: 2016-01-29 License: PD diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki index 2a6fdd5..8c49645 100644 --- a/bip-0075.mediawiki +++ b/bip-0075.mediawiki @@ -6,9 +6,9 @@ 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 + Status: Final Type: Standards Track Created: 2015-11-20 License: CC-BY-4.0 @@ -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-0079.mediawiki b/bip-0079.mediawiki new file mode 100644 index 0000000..99430d9 --- /dev/null +++ b/bip-0079.mediawiki @@ -0,0 +1,124 @@ +<pre> + BIP: 79 + Layer: Applications + Title: Bustapay :: a practical coinjoin protocol + Author: Ryan Havar <rhavar@protonmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0079 + Status: Proposed + Type: Informational + Created: 2018-10-05 + License: CC0-1.0 +</pre> + + +==Abstract== + +The way bitcoin transactions are normally created leaks more information than desirable, and as a result has been exploited by unreasonably effective blockchain analysis techniques to jeopardize important properties that are expected of a useful currency. + +Bustapay is a simple and practical protocol for the sender and receiver of a payment to collaboratively sign a bitcoin transaction in such a way that busts some analysis assumptions to the immediate benefit of the sender and receiver. Furthermore it does so in such a way that gives a significant amount of control to the receiver to help manage their utxo set size, a constant problem for bitcoin merchants. + +==Copyright== + +This document is licensed under the Creative Commons CC0 1.0 Universal license. + +==Motivation== + +One of the most powerful blockchain analysis heuristics has been to assume all inputs of a transaction are controlled by a single party unless otherwise known (such as by the distinctive structure of a traditional coinjoin, or multisig spends that are validated onchain). Combined with other techniques (notably change-output guessing) this has lead to unexpectedly accurate tracking that has exposed bitcoin participants to unacceptable personal, business and financial risks -- undermining bitcoin's utility and fungibility -- and ultimately jeopardizing its ability to function as useful money. + +We however can bust these assumptions with a sender-receiver coinjoin. To prevent costless spy/DoS attacks, we require the sending party to provide a fully-valid ready-to-propagate transaction to initiate the process, that the receiver can broadcast if the sender never completes the coinjoin thus tying the cost to that of spending a utxo. Most promisingly, bustapay transactions do not have an identifiable structure so any network analysis will be not able to tell if a given transaction is a bustapay transaction or not which erodes the confidence of their entire models, providing positive externalities for the entire bitcoin ecosystem. + +Bustapay transactions also do not grow the receiver's count of unspent transaction outputs, and in fact gives the receiver an opportunity to better manage their utxo set, something normally only done when sending payments. Large utxo sets are often problematic and expensive, and frequently requiring privacy-destroying consolidation. Besides busting clustering assumptions, bustapay also provides a layer of obfuscation of send amounts. + +It is worth noting that this specification has eschewed complexity and potentially useful extensions on the assumption that simplicity is of the most important to encourage adoption. + + +==Overview== + +A bustapay payment is made from a sender to a receiver. + +====Step 1. Sender creates a bitcoin transaction paying the receiver==== + +This transaction must use segwit for all inputs, and be fully valid and signed. The transaction must be eligible for propagation on the network (but not done so at this stage) + +====Step 2. Sender gives the "template transaction" to the receiver==== + +This is done via an HTTP POST request, sent to a "bustapay url" + +====Step 3. Receiver processes the transaction and returns a partially signed coinjoin==== + +The receiver validates the transaction, and pays himself. The receiver then adds one or more of his own inputs (known as the ''contributed inputs'') and (optionally) increases the output that pays himself (generally by the sum of the ''contributed inputs''). Doing so creates a ''partial transaction'', which the receiver returns to the sender. It is called such as it requires the sender to re-sign his own inputs. + +====Step 4. Sender validates, re-signs, and propagates on the bitcoin network==== + +The sender MUST validate the ''partial transaction'' was changed correctly and non-maliciously (to allow using potentially untrusted communication channels), re-sign its original inputs and propagate the final transaction over the bitcoin network. + +====Step 5. Receiver observes the finalized transaction on the bitcoin network==== + +Once the receiver has seen the finalized transactions on the network (and has enough confirmations) it can process it like a normal payment for the sent amount (as opposed to the amount that it looks like on the network). If the receiver does not see the finalized transaction after a timeout, they will propagate the original "template transaction", which ensures the payment happens and functions a strong anti-DoS mechanism. + +== Specification == + +The standard way of letting a sender know where to send a bustapay transaction is done via a bip21 encoded address. The key value "bpu" (short for "BustaPayUrl") should be used. An example of such address would be bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bpu=https://bp.bustabit.com/submit It is highly encouraged that urls are kept short. + +When the sender is creating a "template transaction" it is done almost identically to creating a normal send, with the exception that *only* segwit inputs may be used. The sender is also encouraged to use a slightly more aggressive feerate than usual as well as BIP125 (Opt-in Full Replace-by-Fee Signaling), but neither is strictly required. + +The template transaction should be sent to the receiver via an HTTP POST to the bustapay url, with a binary encoded body. + +The receiver is then responsible for validating the template transaction. If there is a problem with the transaction, or the receiver is generally unhappy with the transaction (e.g. fees are too small) the HTTP response code of 422 should be used and a human-readable string containing information on why which can be directly given to the user. + +Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefor assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid. + +=== Contributed Input Choice === + +The receiver must add at least one input to the transaction (the "contributed inputs"). If the receiver has no inputs, it should use a 500 internal server error, so the client can send the transaction as per normal (or try again later). Its generally advised to only add a single contributed input, however they are circumstances where adding more than a single input can be useful. + +To prevent an attack where a receiver is continually sent variations of the same transaction to enumerate the receivers utxo set, it is essential that the receiver always returns the same contributed inputs when it's seen the same inputs. + +It is strongly preferable that the receiver makes an effort to pick a contributed input of the same type as the other transaction inputs if possible. + +=== Output Adjustment === + +After adding inputs to the transaction, the receiver generally will want to adjust the output that pays himself by increasing it by the sum of the contributed input amounts (minus any fees he wants to contribute). However the only strict requirement is that the receiver *must never* remove inputs, and *must not* ever decrease any output amount. + +=== Returning the partial transaction === + +The receiver must sign all contributed inputs in the partial transaction. The partial transaction should also remove all witnesses from the the original template transaction as they are no longer valid, and need to be recalculated by the sender. The receiver returns the partial transaction as a binary-encoded HTTP response with a status code of 200. To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header "Access-Control-Allow-Origin: *" + + +=== Sender Validation === + +The sender *must* do important validation on the partial transaction. They *must* verify: + +* All template transaction inputs are in the partial transaction (but perhaps different order) and have the same sequence numbers. +* The partial transaction contains at least one new (and signed) segwit input (owned by the receiver) +* All outputs from the template transaction exist in the partial transaction, except they are allowed to be reordered and have their amounts increased (but *never* decreased) + +=== Creating Final Transaction === + +After validating the partial transaction, the sender signs all its inputs to create what is now the final transaction. It is important that the sender is careful to not be tricked by the receiver into signing other inputs it owns. The sender must only sign inputs that existed in the template transaction. If the sender is not careful the receiver may "contribute" inputs that are actually owned with by the sender, with the hope the sender blindly signs everything. + + +=== Transaction Publishing === + +Once the final transaction is created, the sender should publish it directly onto the bitcoin network. If the sender does not do this after a reasonable time (e.g. 1 minute), the receiver should publish the template transaction as an important anti-spy/anti-DoS tactic . The sender may also choose to publish the template transaction instead of the final transaction if they believe the receiver to have unreasonably lowered the feerate of the transaction (i.e. increased the size of the transaction, but not the feerate enough). And both parties can consider publishing the template transaction even after the finalized transaction is on the network (taking advantage of replace-by-fee) if the final transaction is not confirming and the template transaction has more fees. + + +=== Implementation Notes === +For anyone wanting to implement bustapay payments, here are some notes for receivers: + +* A transaction can easily be checked if it's suitable for the mempool with testmempoolaccept in bitcoin core 0.17+ +* Tracking transactions by txid is precarious. To keep your sanity make sure all inputs are segwit. But remember segwit does not prevent txid malleability unless you validate the transaction. So really make sure you're using testmempoolaccept at the very least +* Bustapay could be abused by a malicious party to query if you own a deposit address or not. So never accept a bustapay transaction that pays an already used deposit address +* You will need to keep a mapping of which utxos people have showed you and which you revealed. So if you see them again, you can reveal the same one of your own +* Check if the transaction was already sorted according to BIP69, if so ensure the result stays that way. Otherwise probably just shuffle the inputs/outputs +* A reference implementation is maintained at https://github.com/rhavar/bustapay which functions as a wrapper around some RPC calls to bitcoin core's wallet. +* The sender must be careful of an attack where the receiver tries to add additional inputs that are controlled by the sender, with the hope that the sender blindly signs it. + +== Backwards Compatibility == + +Bustapay is an optional payment protocol and therefor has no backwards compatibility concerns. It in fact can only be supported in addition to normal transaction processing, as falling back to a normal bitcoin transaction is a required behavior. + + +== Credits == +The idea is obviously based upon Dr. Maxwell's seminal CoinJoin proposal, and reduced scope inspired by a simplification of the "pay 2 endpoint" blog post by blockstream. 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-0084.mediawiki b/bip-0084.mediawiki new file mode 100644 index 0000000..dc5a05d --- /dev/null +++ b/bip-0084.mediawiki @@ -0,0 +1,100 @@ +<pre> + BIP: 84 + Layer: Applications + Title: Derivation scheme for P2WPKH based accounts + Author: Pavol Rusnak <stick@satoshilabs.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0084 + Status: Draft + Type: Informational + Created: 2017-12-28 + License: CC0-1.0 +</pre> + +==Abstract== + +This BIP defines the derivation scheme for HD wallets using the P2WPKH ([[bip-0173.mediawiki|BIP 173]]) serialization format for segregated witness transactions. + +==Motivation== + +With the usage of P2WPKH transactions it is necessary to have a common derivation scheme. +It allows the user to use different HD wallets with the same masterseed and/or a single account seamlessly. + +Thus the user needs to create dedicated segregated witness accounts, which ensures that only wallets compatible with this BIP will detect the accounts and handle them appropriately. + +===Considerations=== + +We use the same rationale as described in Considerations section of [[bip-0049.mediawiki|BIP 49]]. + +==Specifications== + +This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] root account. + +===Public key derivation=== + +To derive a public key from the root account, this BIP uses the same account-structure as defined in [[bip-0044.mediawiki|BIP 44]] and [[bip-0049.mediawiki|BIP 49]], but only uses a different purpose value to indicate the different transaction serialization method. + +<pre> +m / purpose' / coin_type' / account' / change / address_index +</pre> + +For the <code>purpose</code>-path level it uses <code>84'</code>. The rest of the levels are used as defined in BIP44 or BIP49. + + +===Address derivation=== + +To derive the P2WPKH address from the above calculated public key, we use the encapsulation defined in [[bip-0141.mediawiki#p2wpkh|BIP 141]]: + + + witness: <signature> <pubkey> + scriptSig: (empty) + scriptPubKey: 0 <20-byte-key-hash> + (0x0014{20-byte-key-hash}) + + +===Extended Key Version=== + +When serializing extended keys, this scheme uses alternate version bytes. Extended public keys use <code>0x04b24746</code> to produce a "zpub" prefix, and private keys use <code>0x04b2430c</code> to produce a "zprv" prefix. Testnet uses <code>0x045f1cf6</code> "vpub" and <code>0x045f18bc</code> "vprv." + +Additional registered version bytes are listed in [[https://github.com/satoshilabs/slips/blob/master/slip-0132.md|SLIP-0132]]. + + +==Backwards Compatibility== + +This BIP is not backwards compatible by design as described under [#considerations]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong. + +==Test vectors== + +<pre> + mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about + rootpriv = zprvAWgYBBk7JR8Gjrh4UJQ2uJdG1r3WNRRfURiABBE3RvMXYSrRJL62XuezvGdPvG6GFBZduosCc1YP5wixPox7zhZLfiUm8aunE96BBa4Kei5 + rootpub = zpub6jftahH18ngZxLmXaKw3GSZzZsszmt9WqedkyZdezFtWRFBZqsQH5hyUmb4pCEeZGmVfQuP5bedXTB8is6fTv19U1GQRyQUKQGUTzyHACMF + + // Account 0, root = m/84'/0'/0' + xpriv = zprvAdG4iTXWBoARxkkzNpNh8r6Qag3irQB8PzEMkAFeTRXxHpbF9z4QgEvBRmfvqWvGp42t42nvgGpNgYSJA9iefm1yYNZKEm7z6qUWCroSQnE + xpub = zpub6rFR7y4Q2AijBEqTUquhVz398htDFrtymD9xYYfG1m4wAcvPhXNfE3EfH1r1ADqtfSdVCToUG868RvUUkgDKf31mGDtKsAYz2oz2AGutZYs + + // Account 0, first receiving address = m/84'/0'/0'/0/0 + privkey = KyZpNDKnfs94vbrwhJneDi77V6jF64PWPF8x5cdJb8ifgg2DUc9d + pubkey = 0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c + address = bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu + + // Account 0, second receiving address = m/84'/0'/0'/0/1 + privkey = Kxpf5b8p3qX56DKEe5NqWbNUP9MnqoRFzZwHRtsFqhzuvUJsYZCy + pubkey = 03e775fd51f0dfb8cd865d9ff1cca2a158cf651fe997fdc9fee9c1d3b5e995ea77 + address = bc1qnjg0jd8228aq7egyzacy8cys3knf9xvrerkf9g + + // Account 0, first change address = m/84'/0'/0'/1/0 + privkey = KxuoxufJL5csa1Wieb2kp29VNdn92Us8CoaUG3aGtPtcF3AzeXvF + pubkey = 03025324888e429ab8e3dbaf1f7802648b9cd01e9b418485c5fa4c1b9b5700e1a6 + address = bc1q8c6fshw2dlwun7ekn9qwf37cu2rn755upcp6el +</pre> + +==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]] +* [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]] +* [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]] +* [[bip-0173.mediawiki|BIP173 - Base32 address format for native v0-16 witness outputs]] diff --git a/bip-0090.mediawiki b/bip-0090.mediawiki index 653e40d..8cf3d6d 100644 --- a/bip-0090.mediawiki +++ b/bip-0090.mediawiki @@ -1,9 +1,8 @@ <pre> BIP: 90 - 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-0098.mediawiki b/bip-0098.mediawiki new file mode 100644 index 0000000..8540d1a --- /dev/null +++ b/bip-0098.mediawiki @@ -0,0 +1,308 @@ +<pre> + BIP: 98 + Layer: Consensus (soft fork) + Title: Fast Merkle Trees + Author: Mark Friedenbach <mark@friedenbach.org> + Kalle Alm <kalle.alm@gmail.com> + BtcDrak <btcdrak@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0098 + Status: Draft + Type: Standards Track + Created: 2017-08-24 + License: CC-BY-SA-4.0 + License-Code: MIT +</pre> + +==Abstract== + +In many applications it is useful to prove membership of a data element in a set without having to reveal the entire contents of that set. +The Merkle hash-tree, where inner/non-leaf nodes are labeled with the hash of the labels or values of its children, is a cryptographic tool that achieves this goal. +Bitcoin uses a Merkle hash-tree construct for committing the transactions of a block into the block header. +This particular design, created by Satoshi, suffers from a serious flaw related to duplicate entries documented in the National Vulnerability Database as CVE-2012-2459[1], and also suffers from less than optimal performance due to unnecessary double-hashing. + +This Bitcoin Improvement Proposal describes a more efficient Merkle hash-tree construct that is not vulnerable to CVE-2012-2459 +and achieves an approximate 55% decrease in hash-tree construction and validation times as compared with fully optimized implementations of the Satoshi Merkle hash-tree construct. + +==Copyright== + +This BIP is licensed under a Creative Commons Attribution-ShareAlike license. All provided source code is licensed under the MIT license. + +==Motivation== + +A Merkle hash-tree is a directed acyclic graph data structure where all non-terminal nodes are labeled with the hash of combined labels or values of the node(s) it is connected to. +Bitcoin uses a unique Merkle hash-tree construct invented by Satoshi for calculating the block header commitment to the list of transactions in a block. +While it would be convenient for new applications to make use of this same data structure so as to share implementation and maintenance costs, there are three principle drawbacks to reuse. + +First, Satoshi's Merkle hash-tree has a serious vulnerability[1] related to duplicate tree entries that can cause bugs in protocols that use it. +While it is possible to secure protocols and implementations against exploit of this flaw, it requires foresight and it is a bit more tricky to design secure protocols that work around this vulnerability. +Designers of new protocols ought avoid using the Satoshi Merkle hash-tree construct where at all possible in order to responsibly decrease the likelihood of downstream bugs in naïve implementations. + +Second, Satoshi's Merkle hash-tree performs an unnecessary number of cryptographic hash function compression rounds, resulting in construction and validation times that are approximately three (3) times more computation than is strictly necessary in a naïve implementation, or 2.32x more computation in an implementation specialized for this purpose only[2]. +New implementations that do not require backwards compatibility ought to consider hash-tree implementations that do not carry this unnecessary performance hit. + +Third, Satoshi's algorithm presumes construction of a tree index from an ordered list, and therefore is designed to support balanced trees with a uniform path length from root to leaf for all elements in the tree. +Many applications, on the other hand, benefit from having unbalanced trees, particularly if the shorter path is more likely to be used. +While it is possible to make a few elements of a Satoshi hash-tree have shorter paths than the others, the tricks for doing so are dependent on the size of the tree and not very flexible. + +Together these three reasons provide justification for specifying a standard Merkle hash-tree structure for use in new protocols that fixes these issues. +This BIP describes such a structure, and provides an example implementation. + +==Specification== + +A Merkle hash-tree as defined by this BIP is an arbitrarily-balanced binary tree whose terminal/leaf nodes are labelled with the double-SHA256 hashes of data, whose format is outside the scope of this BIP, and inner nodes with labels constructed from the fast-SHA256 hash of its children's labels. +The following image depicts an example unbalanced hash-tree: + +:: [[File:bip-0098/unbalanced-hash-tree.png]] + +'''A''', '''B''', and '''C''' are leaf labels, 32-byte double-SHA256 hashes of the data associated with the leaf. +'''Node''' and '''Root''' are inner nodes, whose labels are fast-SHA256 (defined below) hashes of their respective children's labels. +'''Node''' is labelled with the fast-SHA256 hash of the concatenation of '''B''' and '''C'''. +'''Root''' is labelled with the fast-SHA256 hash of the concatenation of '''A''' and '''Node''', and is the ''Merkle root'' of the tree. +Nodes with single children are not allowed. + +The ''double-SHA256'' cryptographic hash function takes an arbitrary-length data as input and produces a 32-byte hash by running the data through the SHA-256 hash function as specified in FIPS 180-4[3], and then running the same hash function again on the 32-byte result, as a protection against length-extension attacks. + +The ''fast-SHA256'' cryptographic hash function takes two 32-byte hash values, concatenates these to produce a 64-byte buffer, and applies a single run of the SHA-256 hash function with a custom 'initialization vector' (IV) and without message paddding. +The result is a 32-byte 'midstate' which is the combined hash value and the label of the inner node. +The changed IV protects against path-length extension attacks (grinding to interpret a hash as both an inner node and a leaf). +fast-SHA256 is only defined for two 32-byte inputs. +The custom IV is the intermediate hash value generated after performing a standard SHA-256 of the following hex-encoded bytes and extracting the midstate: + + cbbb9d5dc1059ed8 e7730eaff25e24a3 f367f2fc266a0373 fe7a4d34486d08ae + d41670a136851f32 663914b66b4b3c23 1b9e3d7740a60887 63c11d86d446cb1c + +This data is the first 512 fractional bits of the square root of 23, the 9th prime number. +The resulting midstate is used as IV for the fast-SHA256 cryptographic hash function: + + static unsigned char _MidstateIV[32] = + { 0x89, 0xcc, 0x59, 0xc6, 0xf7, 0xce, 0x43, 0xfc, + 0xf6, 0x12, 0x67, 0x0e, 0x78, 0xe9, 0x36, 0x2e, + 0x76, 0x8f, 0xd2, 0xc9, 0x18, 0xbd, 0x42, 0xed, + 0x0e, 0x0b, 0x9f, 0x79, 0xee, 0xf6, 0x8a, 0x24 }; + +As fast-SHA256 is only defined for two (2) 32-byte hash inputs, there are necessarily two special cases: +an empty Merkle tree is not allowed, nor is any root hash defined for such a "tree"; +and a Merkle tree with a single value has a root hash label equal to that self-same value of the leaf branch, the only node in the tree (a passthrough operation with no hashing). + +===Rationale=== + +The fast-SHA256 hash function can be calculated 2.32x faster than a specialized double-SHA256 implementation[2], or three (3) times faster than an implementation applying a generic SHA-256 primitive twice, +as hashing 64 bytes of data with SHA-256 as specified by FIPS 180-4[3] takes two compression runs (because of message padding) and then a third compression run for the double-SHA256 construction. +Validating a fast-SHA256 Merkle root is therefore more than twice as fast as the double-SHA256 construction used by Satoshi in bitcoin. +Furthermore the fastest fast-SHA256 implementation ''is'' the generic SHA-256 implementation, enabling generic circuitry and code reuse without a cost to performance. + +The application of fast-SHA256 to inner node label updates is safe in this limited domain because the inputs are hash values and fixed in number and in length, +so the sorts of attacks prevented by message padding and double-hashing do not apply. + +The 'initialization vector' for fast-SHA256 is changed in order to prevent a category of attacks on higher level protocols where a partial collision can serve as both a leaf hash and as an inner node commitment to another leaf hash. +The IV is computed using standard SHA-256 plus midstate extraction so as to preserve compatibility with cryptographic library interfaces that do not support custom IVs, at the cost of a 2x performance hit if neither custom IVs nor resuming from midstate are supported. +The data hashed is a nothing-up-my-sleeve number that is unlikely to have a known hash preimage. +The prime 23 was chosen as the leading fractional bits of the first eight (8) primes, two (2) through nineteen (19), are constants used in the setup of SHA-256 itself. +Using the next prime in sequence reduces the likelihood of introducing weakness due to reuse of a constant factor. + +The Merkle root hash of a single element tree is a simple pass-through of the leaf hash without modification so as to allow for chained validation of split proofs. +This is particularly useful when the validation environment constrains proof sizes, such as push limits in Bitcoin script. +Chained validation allows a verifier to split one proof into two or more, where the leaf is shown to be under an inner node, and that inner node is shown to be under the root. +Without pass-through hashing in a single-element tree, use of chained validation would unnecessarily introduce a minimum path length requirement equal to the number of chain links. +Pass-through hashing of single elements allows instead for one or more of the chained validations to use a "NOP" proof consisting of a zero-length path, +thereby allowing, for example, a fixed series of four (4) chained validations to verify a length three (3) or shorter path. + +==Inclusion Proofs== + +An important use of Merkle hash-trees is the ability to compactly prove membership with log-sized proofs. +This section specifies a standard encoding for a multi-element inclusion proof. + +To prove that a set of hashes is contained within a Merkle tree with a given root requires four pieces of information: + +# The root hash of the Merkle tree; +# The hash values to be verified, a set usually consisting of the double-SHA256 hash of data elements, but potentially the labels of inner nodes instead, or both; +# The paths from the root to the nodes containing the values under consideration, expressed as a serialized binary tree structure; and +# The hash values of branches not taken along those paths. + +Typically the last two elements, the paths and the elided branch hashes, are lumped together and referred to as the ''proof''. + +Serialization begins with a variable-length integer (VarInt) used to encode N, the number of internal nodes in the proof. +Next the structure of the tree is traversed using depth-first, left-to-right, pre-order algorithm to visit each internal nodes, which are serialized using a packed 3-bit representation for the configuration of each node, consuming <code>(3*N + 7) / 8</code> bytes. +Then the number skipped hashes (those included in the proof, not verified by the proof) is serialized as a variable-length integer (VarInt), +followed by the hashes themselves in the order previously traversed. + +There are eight possible configurations of internal nodes, as given in the following diagram: + +:: [[File:bip-0098/node-variants.png]] + +In this diagram, DESCEND means the branch links to another internal node, as indicated by its child graph elements labeled "..."; +SKIP means the branch contains a hash of an elided subtree or element, and the fast-SHA256 root hash of this subtree or double-SHA256 hash of the element is included in the proof structure; and +VERIFY means the branch contains an externally provided hash that is needed as witness for the verification of the proof. +In tabular form, these code values are: + +{| class="wikitable" +|- +| scope="col"| Code +| scope="col"| Left +| scope="col"| Right +|- +| scope="row"| 000 +| VERIFY +| SKIP +|- +| scope="row"| 001 +| VERIFY +| VERIFY +|- +| scope="row"| 010 +| VERIFY +| DESCEND +|- +| scope="row"| 011 +| DESCEND +| SKIP +|- +| scope="row"| 100 +| DESCEND +| VERIFY +|- +| scope="row"| 101 +| DESCEND +| DESCEND +|- +| scope="row"| 110 +| SKIP +| VERIFY +|- +| scope="row"| 111 +| SKIP +| DESCEND +|} + +These 3-bit codes are packed into a byte array such that eight (8) codes would fit in every three (3) bytes. +The order of filling a byte begins with the most significant bit <code>0x80</code> and ends with the least significant bit <code>0x01</code>. +Unless the number of inner nodes is a multiple of eight (8), there will be excess low-order bits in the final byte of serialization. +These excess bits must be zero. + +Note that the tree serialization is self-segmenting. +By tracking tree structure a proof reader will know when the parser has reached the last internal node. +The number of inner nodes serialized in the proof MUST equal the number of nodes inferred from the tree structure itself. +Similarly, the number of SKIP hashes can also be inferred from the tree structure as serialized, and MUST equal the number of hashes provided within the proof. + +The single-hash proof has N=0 (the number of inner nodes), +the tree structure is not serialized (as there are no inner nodes), +and the number of SKIP hashes can be either 0 or 1. + +===Example=== + +Consider the following Merkle tree structure: + +:: [[File:bip-0098/traversal-example.png]] + +There are six (6) internal nodes. +The depth-first, left-to-right, pre-order traversal of the tree visits these nodes in the following order: A, B, D, F, C, then E. +There are three (3) skipped hashes, visited in the following order: 0x00..., 0x66..., and 0x22... +The remaining four (4) hashes are provided at runtime to be verified by the proof. + +{| +| scope="col"| +| scope="col"| Byte 1 +| scope="col"| Byte 2 +| scope="col"| Byte 3 +|- +| scope="row"| Bits +| 76543210 +| 76543210 +| 76543210 +|- +| scope="row"| Nodes +| AAABBBDD +| DFFFCCCE +| EE------ +|- +| scope="row"| Code +| 10111101 +| 10000100 +| 01000000 +|} + +The serialization begins with the VarInt encoded number of inner nodes, <code>0x06</code>, followed by the tree serialization itself, <code>0xbd8440</code>. +Next the number of SKIP hashes is VarInt encoded, <code>0x03</code>, followed by the three (3) hashes in sequence. +The resulting 101 byte proof, encoded in base64:. + + Br2EQAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGZmZmZmZmZmZmZmZmZmZmZmZmZm + ZmZmZmZmZmZmZmZmREREREREREREREREREREREREREREREREREREREREREQ= + +===Rationale=== + +The 3-bit encoding for inner nodes allows encoding all relevant configurations of the nodes where the left and right branches can each be one of {DESCEND, SKIP, VERIFY}. +The excluded 9th possibility would have both branches as SKIP: + +:: [[File:bip-0098/skip-skip.png]] + +This possibility is not allowed as for verification purposes it is entirely equivalent to the shorter proof where the branch to that node was SKIP'ed. +Disallowing a node with two SKIP branches eliminates what would otherwise be a source of proof malleability. + +The number of hashing operations required to verify a proof is one less than the number of hashes (SKIP and VERIFY combined), +and is exactly equal to the number of inner nodes serialized as the beginning of the proof as N. +The variable-length integer encoding has the property that serialized integers, sorted lexigraphically, will also be sorted numerically. +Since the first serialized item is the number of inner nodes, sorting proofs lexigraphically has the effect of sorting the proofs by the amount of work required to verify. + +The number of hashes required as input for verification of a proof is N+1 minus the number of SKIP hashes, +and can be quickly calculated without parsing the tree structure. + +The coding and packing rules for the serialized tree structure were also chosen to make lexigraphical comparison useful (or at least not meaningless). +If we consider a fully-expanded tree (no SKIP hashes, all VERIFY) to be encoding a list of elements in the order traversed depth-first from left-to-right, +then we can extract proofs for subsets of the list by SKIP'ing the hashes of missing values and recursively pruning any resulting SKIP,SKIP nodes. +Lexigraphically comparing the resulting serialized tree structures is the same as lexigraphically comparing lists of indices from the original list verified by the derived proof. + +Because the number of inner nodes and the number of SKIP hashes is extractible from the tree structure, +both variable-length integers in the proof are redundant and could have been omitted. +However that would require either construction and storage of the explicit tree in memory at deserialization time, +or duplication of the relatively complicated tree parsing code in both the serialization and verification methods. +For that reason (as well as to handle the single-hash edge case) the redundant inner node and SKIP hash counts are made explicit in the serialization, +and the two values must match what is inferred from the tree structure for a proof to be valid. +This makes deserialization trivial and defers tree construction until verification time, +which has the additional benefit of enabling log-space verification algorithms. + +==Fast Merkle Lists== + +Many applications use a Merkle tree to provide indexing of, or compact membership proofs about the elements in a list. +This addendum specifies an algorithm that constructs a canonical balanced tree structure for lists of various lengths. +It differs in a subtle but important way from the algorithm used by Satoshi so as to structurally prevent the vulnerability described in [1]. + +# Begin with a list of arbitrary data strings. +# Pre-process the list by replacing each element with its double-SHA256 hash. +# If the list is empty, return the zero hash. +# While the list has 2 or more elements, +#* Pass through the list combining adjacent entries with the fast-SHA256 hash. If the list has an odd number of elements, leave the last element as-is (this fixes [1]). This step reduces a list of N elements to ceil(N/2) entries. +# The last remaining item in the list is the Merkle root. + +This algorithm differs from Merkle lists used in bitcoin in two ways. +First, fast-SHA256 is used instead of double-SHA256 for inner node labels. +Second, final entries on an odd-length list are not duplicated and hashed, which is the mistake that led to CVE-2012-2459[1]. + +==Implementation== + +An implementation of this BIP for extraction of Merkle branches and fast, log-space Merkle branch validation is available at the following Github repository: + +[https://github.com/maaku/bitcoin/tree/fast-merkle-tree] + +Also included in this repo is a 'merklebranch' RPC for calculating root values and extracting inclusion proofs for both arbitrary trees and trees constructed from lists of values using the algorithm in this BIP, +and a 'mergemerklebranch' RPC for unifying two or more fast Merkle tree inclusion proofs--replacing SKIP hashes in one proof with a subtree extracted from another. + +==Deployment== + +This BIP is used by BIP116 (MERKLEBRANCHVERIFY)[4] to add Merkle inclusion proof verification to script by means of a soft-fork NOP expansion opcode. +Deployment of MERKLEBRANCHVERIFY would make the contents of this BIP consensus critical. +The deployment plan for BIP116 is covered in the text of that BIP. + +==Compatibility== + +This BIP on its own does not cause any backwards incompatibility. + +==References== + +[1] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2459 National Vulnerability Database: CVE-2012-2459] + +[2] [https://github.com/sipa/bitcoin/tree/201709_dsha256_64 github.com:sipa/bitcoin 201709_dsha256_64] Pieter Wuille, September 2017, personal communication. By making use of knowledge that the inputs at each stage are fixed length, Mr. Wuille was able to achieve a 22.7% reduction in the time it takes to compute the double-SHA256 hash of 64 bytes of data, the hash aggregation function of the Satoshi Merkle tree construction. + +[3] [http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf Secure Hash Standard] + +[4] [https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki BIP 116 MERKLEBRANCHVERIFY] diff --git a/bip-0098/build.sh b/bip-0098/build.sh new file mode 100755 index 0000000..a8a3155 --- /dev/null +++ b/bip-0098/build.sh @@ -0,0 +1,6 @@ +#!/bin/sh + +dot -Tpng -o node-variants.png node-variants.dot +dot -Tpng -o skip-skip.png skip-skip.dot +dot -Tpng -o traversal-example.png traversal-example.dot +dot -Tpng -o unbalanced-hash-tree.png unbalanced-hash-tree.dot diff --git a/bip-0098/node-variants.dot b/bip-0098/node-variants.dot new file mode 100644 index 0000000..7171346 --- /dev/null +++ b/bip-0098/node-variants.dot @@ -0,0 +1,85 @@ +digraph G { + row1 [shape=none, label=""] + + A [label="000"] + A -> Al [label="L"] + Al [label="VERIFY"] + A -> Ar [label="R"] + Ar [label="SKIP"] + + B [label="001"] + B -> Bl [label="L"] + Bl [label="VERIFY"] + B -> Br [label="R"] + Br [label="VERIFY"] + + { rank = same; row1; A; B; } + + C [label="010"] + C -> Cl [label="L"] + Cl [label="VERIFY"] + C -> Cr [label="R"] + Cr [label="DESCEND"] + Cr -> Crl + Crl [label="..."] + Cr -> Crr + Crr [label="..."] + + D [label="011"] + D -> Dl [label="L"] + Dl [label="DESCEND"] + Dl -> Dll + Dll [label="..."] + Dl -> Dlr + Dlr [label="..."] + D -> Dr [label="R"] + Dr [label="SKIP"] + + E [label="100"] + E -> El [label="L"] + El [label="DESCEND"] + El -> Ell + Ell [label="..."] + El -> Elr + Elr [label="..."] + E -> Er [label="R"] + Er [label="VERIFY"] + + row1 -> invis [style=invis] + invis [shape=none, label=""] + invis -> C [style=invis] + { rank = same; C; D; E; } + + F [label="101"] + F -> Fl [label="L"] + Fl [label="DESCEND"] + Fl -> Fll + Fll [label="..."] + Fl -> Flr + Flr [label="..."] + F -> Fr [label="R"] + Fr [label="DESCEND"] + Fr -> Frl + Frl [label="..."] + Fr -> Frr + Frr [label="..."] + + G [label="110"] + G -> Gl [label="L"] + Gl [label="SKIP"] + G -> Gr [label="R"] + Gr [label="VERIFY"] + + H [label="111"] + H -> Hl [label="L"] + Hl [label="SKIP"] + H -> Hr [label="R"] + Hr [label="DESCEND"] + Hr -> Hrl + Hrl [label="..."] + Hr -> Hrr + Hrr [label="..."] + + Crl -> F [style=invis] + { rank = same; F; G; H; } +} diff --git a/bip-0098/node-variants.png b/bip-0098/node-variants.png Binary files differnew file mode 100644 index 0000000..991d7bc --- /dev/null +++ b/bip-0098/node-variants.png diff --git a/bip-0098/skip-skip.dot b/bip-0098/skip-skip.dot new file mode 100644 index 0000000..5e633d6 --- /dev/null +++ b/bip-0098/skip-skip.dot @@ -0,0 +1,7 @@ +digraph G { + A [label="???"] + A -> Al [label="L"] + Al [label="SKIP"] + A -> Ar [label="R"] + Ar [label="SKIP"] +}
\ No newline at end of file diff --git a/bip-0098/skip-skip.png b/bip-0098/skip-skip.png Binary files differnew file mode 100644 index 0000000..d3e7c45 --- /dev/null +++ b/bip-0098/skip-skip.png diff --git a/bip-0098/traversal-example.dot b/bip-0098/traversal-example.dot new file mode 100644 index 0000000..2993642 --- /dev/null +++ b/bip-0098/traversal-example.dot @@ -0,0 +1,32 @@ +digraph G { + a [label="A\n101"] + a -> b + a -> c + + b [label="B\n111"] + b -> s0 + s0 [label="SKIP\n0x00..."] + b -> d + + d [label="D\n011"] + d -> f + d -> s1 + s1 [label="SKIP\n0x22..."] + + f [label="F\n000"] + f -> v1 + v1 [label="VERIFY\n0x55..."] + f -> s2 + s2 [label="SKIP\n0x66..."] + + c [label="C\n010"] + c -> v2 + v2 [label="VERIFY\n0x11..."] + c -> e + + e [label="E\n001"] + e -> v3 + v3 [label="VERIFY\n0x33..."] + e -> v4 + v4 [label="VERIFY\n0x44..."] +} diff --git a/bip-0098/traversal-example.png b/bip-0098/traversal-example.png Binary files differnew file mode 100644 index 0000000..a6a7954 --- /dev/null +++ b/bip-0098/traversal-example.png diff --git a/bip-0098/unbalanced-hash-tree.dot b/bip-0098/unbalanced-hash-tree.dot new file mode 100644 index 0000000..c637652 --- /dev/null +++ b/bip-0098/unbalanced-hash-tree.dot @@ -0,0 +1,11 @@ +digraph G { + 0 [label="Root\nH(A || H(B || C))"] + 0 -> A + A [label="A\nskip"] + 0 -> 1 + 1 [label="Node\nH(B || C)"] + 1 -> B + B [label="B\nskip"] + 1 -> C + C [label="C\nverify"] +} diff --git a/bip-0098/unbalanced-hash-tree.png b/bip-0098/unbalanced-hash-tree.png Binary files differnew file mode 100644 index 0000000..339bb22 --- /dev/null +++ b/bip-0098/unbalanced-hash-tree.png 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 36bb87f..bc06000 100644 --- a/bip-0103.mediawiki +++ b/bip-0103.mediawiki @@ -73,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-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-0112.mediawiki b/bip-0112.mediawiki index 65171a4..f3d370a 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -32,7 +32,7 @@ When executed, if any of the following conditions are true, the script interpret ** the transaction version is less than 2; or ** the transaction input sequence number disable flag (1 << 31) is set; or ** the relative lock-time type is not the same; or -** the top stack item is greater than the transaction sequence (when masked according to the BIP68); +** the top stack item is greater than the transaction input sequence (when masked according to the BIP68); Otherwise, script execution will continue as if a NOP had been executed. 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-0116.mediawiki b/bip-0116.mediawiki new file mode 100644 index 0000000..86b0f9a --- /dev/null +++ b/bip-0116.mediawiki @@ -0,0 +1,145 @@ +<pre> + BIP: 116 + Layer: Consensus (soft fork) + Title: MERKLEBRANCHVERIFY + Author: Mark Friedenbach <mark@friedenbach.org> + Kalle Alm <kalle.alm@gmail.com> + BtcDrak <btcdrak@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0116 + Status: Draft + Type: Standards Track + Created: 2017-08-25 + License: CC-BY-SA-4.0 + License-Code: MIT +</pre> + +==Abstract== + +A general approach to bitcoin contracts is to fully enumerate the possible spending conditions and then program verification of these conditions into a single script. +At redemption, the spending condition used is explicitly selected, e.g. by pushing a value on the witness stack which cascades through a series if if/else constructs. + +This approach has significant downsides, such as requiring all program pathways to be visible in the scriptPubKey or redeem script, even those which are not used at validation. +This wastes space on the block chain, restricts the size of possible scripts due to push limits, and impacts both privacy and fungibility as details of the contract can often be specific to the user. + +This BIP proposes a new soft-fork upgradeable opcode, MERKLEBRANCHVERIFY, which allows script writers to commit to a set of data elements and have one or more of these elements be provided at redemption without having to reveal the entire set. +As these data elements can be used to encode policy, such as public keys or validation subscripts, the MERKLEBRANCHVERIFY opcode can be used to overcome these limitations of existing bitcoin script. + +==Copyright== + +This BIP is licensed under a Creative Commons Attribution-ShareAlike license. All provided source code is licensed under the MIT license. + +==Specification== + +MERKLEBRANCHVERIFY redefines the existing NOP4 opcode. +When executed, if any of the following conditions are true, the script interpreter will terminate with an error: + +# the stack contains less than three (3) items; +# the first item on the stack is more than 2 bytes; +# the first item on the stack, interpreted as an integer, N, is negative or not minimally encoded; +# the second item on the stack is not exactly 32 bytes; +# the third item on the stack is not a serialized Merkle tree inclusion proof as specified by BIP98[1] and requiring exactly <code>floor(N/2)</code> VERIFY hashes; or +# the remainder of the stack contains less than <code>floor(N/2)</code> additional items, together referred to as the input stack elements. + +If the low-order bit of N is clear, <code>N&1 == 0</code>, each input stack element is hashed using double-SHA256. +Otherwise, each element must be exactly 32 bytes in length and are interpreted as serialized hashes. +These are the VERIFY hashes. + +If the fast Merkle root computed from the Merkle tree inclusion proof, the third item on the stack, +with the VERIFY hashes in the order as presented on the stack, from top to bottom, +does not exactly match the second item on the stack, +the script interpreter will terminate with an error. + +Otherwise, script execution will continue as if a NOP had been executed. + +==Motivation== + +Although BIP16 (Pay to Script Hash)[2] and BIP141 (Segregated Witness)[3] both allow the redeem script to be kept out of the scriptPubKey and therefore out of the UTXO set, the entire spending conditions for a coin must nevertheless be revealed when that coin is spent. +This includes execution pathways or policy conditions which end up not being needed by the redemption. +Not only is it inefficient to require this unnecessary information to be present on the blockchain, albeit in the witness, it also impacts privacy and fungibility as some unused script policies may be identifying. +Using a Merkle hash tree to commit to the policy options, and then only forcing revelation of the policy used at redemption minimizes this information leakage. + +Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would would otherwise be possible, due to various built-in script size and runtime limitations. +With Merkle commitments to policy these size and runtime limitations constrain the complexity of any one policy that can be used rather than the sum of all possible policies. + +==Rationale== + +The MERKLEBRANCHVERIFY opcode uses fast Merkle hash trees as specified by BIP98[1] rather than the construct used by Satoshi for committing transactions to the block header as the later has a known vulnerability relating to duplicate entries that introduces a source of malleability to downstream protocols[4]. +A source of malleability in Merkle proofs could potentially lead to spend vulnerabilities in protocols that use MERKLEBRANCHVERIFY. +For example, a compact 2-of-N policy could be written by using MERKLEBRANCHVERIFY to prove that two keys are extracted from the same tree, one at a time, then checking the proofs for bitwise equality to make sure the same entry wasn't used twice. +With the vulnerable Merkle tree implementation there are privledged positions in unbalanced Merkle trees that allow multiple proofs to be constructed for the same, single entry. + +BIP141 (Segregated Witness)[3] provides support for a powerful form of script upgrades called script versioning, which is able to achieve the sort of upgrades which would previously have been hard-forks. +If script versioning were used for deployment then MERKLEBRANCHVERIFY could be written to consume its inputs, which would provide a small 2-byte savings for many anticipated use cases. +However the more familiar NOP-expansion soft-fork mechanism used by BIP65 (CHECKLOCKTIMEVERIFY)[5] and BIP112 (CHECKSEQUENCEVERIFY)[6] was chosen over script versioning for the following two reasons: + +# '''Infrastructure compatibility.''' Using soft-fork NOP extensions allows MERKLEBRANCHVERIFY to be used by any existing software able to consume custom scripts, and results in standard P2SH or P2WSH-nested-in-P2SH addresses without the need for BIP143[7] signing code. This allows MERKLEBRANCHVERIFY to be used immediately by services that need it rather than wait on support for script versioning and/or BIP-143[7] signatures in tools and libraries. +# '''Delayed decision on script upgrade protocol.''' There are unresolved issues with respect to how script versioning should be used for future script upgrades. There are only 16 available script versions reserved for future use, and so they should be treated as a scarce resource. Additionally, script feature versioning should arguably be specified in the witness and the BIP141 script versioning only be used to specify the structure of the witness, however no such protocol exists as of yet. Using the NOP-expansion space prevents MERKLEBRANCHVERIFY from being stalled due to waiting on script upgrade procedure to be worked out, while making use of expansion space that is already available. + +The MERKLEBRANCHVERIFY opcode allows for VERIFY hashes to be presented directly, or calculated from the leaf values using double-SHA256. +In most cases the latter approach is expected to be used so that the leaf value(s) can be used for both branch validation and other purposes without any explicit preprocessing. +However allowing already-calculated hash values as inputs enables using chained MERKLEBRANCHVERIFY opcodes to verify branches of trees with proofs large enough that they would not fit in the 520 byte script push limitation. +As specified, a 30-branch path can be verified by proving the path from the leaf to the 15th interior node as the 'root', then proving that node's hash to be a child of the actual Merkle tree root hash. +Validation of a 256-branch path (e.g. a binary prefix tree with a hash value as key) would require 18 chained validations, which would fit within current script limitations. + +==Applications== + +===1-of-N for large N=== + +Here is a redeem script that allows a coin to be spent by any key from a large set, without linear scaling in script size: + + redeemScript: <root> 2 MERKLEBRANCHVERIFY 2DROP DROP CHECKSIG + witness: <sig> <pubkey> <proof> + +The redeem script looks very similar to the standard pay-to-pubkey-hash, except instead of showing that the pubkey's hash is the same as the commitment given, we demonstrate that the pubkey is one of potentially many pubkeys included in the Merkle tree committed to in the redeem script. +The low-order bit of the first parameter, 2, is clear, meaning that there is one input (<code>(2>>1) == 1</code>), the serialized pubkey, and its VERIFY hash needs to be calculated by MERKLEBRANCHVERIFY using double-SHA256. + +===Honeypots=== + +As described by Pieter Wuille[8] the 1-of-N scheme is particularly useful for constructing honeypots. +The desire is to put a large bounty on a server, larger than the value of the server itself so that if the server is compromised it is highly likely that the hacker will claim the bitcoin, thereby revealing the intrusion. +However if there are many servers, e.g. 1,000, it becomes excessively expensive to lock up separate bounties for each server. +It would be desirable if the same bounty was shared across multiple servers in such a way that the spend would reveal which server was compromised. + +This is accomplished by generating 1,000 different keys, building a hash tree of these public keys, and placing each key and associated Merkle path on separate servers. +When the honeypot is claimed, the (previous) owner of the coins can tell which server was compromised from the key and path used to claim the funds. + +==Implementation== + +An implementation of this BIP, including both consensus code updates and tests is available at the following Github repository: + +[https://github.com/maaku/bitcoin/tree/merkle-branch-verify] + +==Deployment== + +This BIP will be deployed by BIP8 (Version bits with lock-in by height)[9] with the name "merklebranchverify" and using bit 2. + +For Bitcoin mainnet, the BIP8 startheight will be at height M to be determined and BIP8 timeout activation will occur on height M + 50,400 blocks. + +For Bitcoin testnet, the BIP8 startheight will be at height T to be determined and BIP8 timeout activation will occur on height T + 50,400 blocks. + +We note that DISCOURAGE_UPGRADABLE_NOPS means that transactions which use this feature are already considered non-standard by the rules of the network, making deployment easier than was the case with, for example, with BIP68 (Relative lock-time using consensus-enforced sequence numbers)[9]. + +==Compatibility== + +Old clients will consider the OP_MERKLEBRANCHVERIFY as a NOP and ignore it. Proof will not be verified, but the transaction will be accepted. + +==References== + +[1] [https://github.com/bitcoin/bips/blob/master/bip-0098.mediawiki BIP98: Fast Merkle Trees (Consensus layer)] + +[2] [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP16: Pay to Script Hash] + +[3] [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141: Segregated Witness (Consensus layer)] + +[4] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2459 National Vulnerability Database: CVE-2012-2459] + +[5] [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY] + +[6] [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY] + +[7] [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143: Transaction Signature Verification for Version 0 Witness Program] + +[8] [https://blockstream.com/2015/08/24/treesignatures.html Multisig on steroids using tree signatures] + +[9] [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers] diff --git a/bip-0117.mediawiki b/bip-0117.mediawiki new file mode 100644 index 0000000..4b5706e --- /dev/null +++ b/bip-0117.mediawiki @@ -0,0 +1,196 @@ +<pre> + BIP: 117 + Layer: Consensus (soft fork) + Title: Tail Call Execution Semantics + Author: Mark Friedenbach <mark@friedenbach.org> + Kalle Alm <kalle.alm@gmail.com> + BtcDrak <btcdrak@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0117 + Status: Draft + Type: Standards Track + Created: 2017-08-25 + License: CC-BY-SA-4.0 + License-Code: MIT +</pre> + +==Abstract== + +BIP16 (Pay to Script Hash)[1] and BIP141 (Segregated Witness)[2] provide mechanisms by which script policy can be revealed at spend time as part of the execution witness. +In both cases only a single script can be committed to by the construct. +While useful for achieving the goals of these proposals, they still require that all policies be specified within the confine of a single script, regardless of whether the policies are needed at the time of spend. + +This BIP, in conjunction with BIP116 (MERKLEBRANCHVERIFY)[3] allows for a script to commit to a practically unbounded number of code pathways, and then reveal the actual code pathway used at spend time. +This achieves a form of generalized MAST[4] enabling decomposition of complex branching scripts into a set of non-branching flat execution pathways, committing to the entire set of possible pathways, and then revealing only the path used at spend time. + +==Copyright== + +This BIP is licensed under a Creative Commons Attribution-ShareAlike license. All provided source code is licensed under the MIT license. + +==Specification== + +If, at the end of script execution: + +* the execution state is non-clean, meaning +*# the main stack has more than one item on it, or +*# the main stack has exactly one item and the alt-stack is not empty; +* the top-most element of the main stack evaluates as true when interpreted as a bool; and +* the top-most element is not a single byte or is outside the inclusive range of <code>0x51</code> to <code>0x60</code>, + +then that top-most element of the main stack is popped and interpreted as a serialized script and executed, +while the remaining elements of both stacks remain in place as inputs. + +If the above conditions hold except for the last one, such that: + +* the top-most element ''is'' a single byte within the inclusive range of <code>0x51</code> (<code>OP_1</code>, meaning N=2) to <code>0x60</code> (<code>OP_16</code>, meaning N=17); and +* other than this top-most element there are at least N additional elements on the main stack and alt stack combined, + +then the top-most element of the main stack is dropped, +and the N=2 (<code>0x51</code>) to 17 (<code>0x60</code>) further elements are popped from the main stack, +continuing from the alt stack if the main stack is exhausted, +and concatenated together in reverse order to form a serialized script, +which is then executed with the remaining elements of both stacks remaining in place as inputs. + +The presence of CHECKSIG or CHECKMULTISIG within the subscript do not count towards the global MAX_BLOCK_SIGOPS_COST limit, +and the number of non-push opcodes executed in the subscript is not limited by MAX_OPS_PER_SCRIPT. +Execution state, other than the above exceptions, carries over into the subscript, +and termination of the subscript terminates execution of the script as a whole. +This is known as execution with tail-call semantics. + +Only one such tail-call of a subscript is allowed per script execution context, and only from within a segwit redeem script. +Alternatively stated, neither evaluation of witness stack nor execution of the scriptPubKey or scriptSig or P2SH redeem script results in tail-call semantics. + +==Motivation== + +BIP16 (Pay to Script Hash)[1] and BIP141 (Segregated Witness)[2] allow delayed revelation of a script's policy until the time of spend. +However these approaches are limited in that only a single policy can be committed to in a given transaction output. +It is not possible to commit to multiple policies and then choose, at spend time, which to reveal. + +BIP116 (MERKLEBRANCHVERIFY)[3] allows multiple data elements to be committed to while only revealing those necessary at the time of spend. +The MERKLEBRANCHVERIFY opcode is only able to provide commitments to a preselected set of data values, and does not by itself allow for executing code. + +This BIP generalizes the approach of these prior methods by allowing the redeem script to perform any type of computation necessary to place the policy script on the stack. +The policy script is then executed from the top of the data stack in a way similar to how BIP16 and BIP141 enable redeem scripts to be executed from the top of the witness stack. +In particular, using MERKLEBRANCHVERIFY[3] in the scriptPubKey or redeem script allows selection of the policy script that contains only the necessary conditions for validation of the spend. +This is a form of generalized MAST[4] where a stage of precomputation splits a syntax tree into possible execution pathways, which are then enumerated and hashed into a Merkle tree of policy scripts. +At spend time membership in this tree of the provided policy script is proven before execution recurses into the policy script. + +==Rationale== + +This proposal is a soft-fork change to bitcoin's consensus rules because leaving a script that data-wise evaluates as true from its serialized form on the stack as execution terminates would result in the script validation returning true anyway. +Giving the subscript a chance to terminate execution is only further constraining the validation rules. +The only scripts which would evaluate as false are the empty script, or a script that does nothing more than push empty/zero values to the stack. +None of these scripts have any real-world utility, so excluding them to achieve soft-fork compatibility doesn't come with any downsides. + +By restricting ourselves to tail-call evaluation instead of a more general EVAL opcode we greatly simplify the implementation. +Tail-call semantics means that execution never returns to the calling script's context, and therefore no state needs to be saved or later restored. +The implementation is truly as simple as pulling the subscript off the stack, resetting a few state variables, and performing a jump back to the beginning of the script interpreter. + +The restriction to allow only one layer of tail-call recursion is admittedly limiting, however the technical challenges to supporting multi-layer tail-call recursion are significant. +A new metric would have to be developed to track script resource usage, for which transaction data witness size are only two factors. +This new weight would have to be relayed with transactions, used as the basis for fee calculation, validated in-line with transaction execution, and policy decided upon for DoS-banning peers that propagate violating transactions. + +However should these problems be overcome, dropping the single recursion constraint is itself a soft-fork for the same reason, applied inductively. +Allowing only one layer of tail-call recursion allows us to receive the primary benefit of multi-policy commitments / generalized MAST, +while leaving the door open to future generalized tail-call recursion if and when the necessary changes are made to resource accounting and p2p transaction distribution. + +The global SIGOP limit and per-script opcode limits do not apply to the policy script +because dynamic selection of the policy script makes it not possible for static analysis tools to verify these limits in general, +and because performance improvements to libsecp256k1 and Bitcoin Core have made these limits no longer necessary as they once were. +The validation costs are still limited by the number of signature operations it is possible to encode within block size limits, +and the maximum script size per input is limited to 10,000 + 17*520 = 18,840 bytes. + +To allow for this drop of global and per-script limits, +tail-call evaluation cannot be allowed for direct execution of the scriptPubKey, +as such scripts are fetched from the UTXO and do not count towards block size limits of the block being validated. +Likewise tail-call from P2SH redeem scripts is not supported due to quadratic blow-up vulnerabilities that are fixed in segwit. + +==Generalized MAST== + +When combined with BIP116 (MERKLEBRANCHVERIFY)[3], tail-call semantics allows for generalized MAST capabilities[4]. +The script author starts with a full description of the entire contract they want to validate at the time of spend. +The possible execution pathways through the script are then enumerated, with conditional branches replaced by a validation of the condition and the branch taken. +The list of possible execution pathways is then put into a Merkle tree, with the flattened policy scripts as the leaves of this tree. +The final redeem script which funds are sent to is as follows: + + redeemScript: <nowiki><root> 2 MERKLEBRANCHVERIFY 2DROP DROP</nowiki> + witness: <nowiki><argN> ... <arg1> <policyScript> <proof></nowiki> + +Where <code>policyScript</code> is the flattened execution pathway, <code>proof</code> is the serialized Merkle branch and path that proves the policyScript is drawn from the set used to construct the Merkle tree <code>root</code>, and <code>arg1</code> through <code>argN</code> are the arguments required by <code>policyScript</code>. +The <code>2</code> indicates that a single leaf (<code>1 << 1</code>) follows, and the leaf value is not pre-hashed. +The <code>2DROP DROP</code> is necessary to remove the arguments to MERKLEBRANCHVERIFY from the stack. + +The above example was designed for clarity, but actually violates the CLEANSTACK rule of segwit v0 script execution. +Unless the CLEANSTACK rule is dropped or modified in a new segwit output version, this would script would have to be modified to use the alt-stack, as follows: + + redeemScript: <nowiki>[TOALTSTACK]*N <root> 2 MERKLEBRANCHVERIFY 2DROP DROP</nowiki> + witness: <nowiki><policyScript> <proof> <arg1> ... <argN></nowiki> + +Where <code>[TOALTSTACK]*N</code> is the TOALTSTACK opcode repeated N times. +This moves <code>arg1</code> through <code>argN</code> to the alt-stack in reverse order, such that <code>arg1</code> is on the top of the alt-stack when execution of <code>policyScript</code> begins. +The <code>policyScript</code> would also have to be modified to fetch its arguments from the alt-stack, of course. + +If the total set of policy scripts includes scripts that take a varying number of parameters, that too can be supported, within reasonable limits. +The following redeem script allows between 1 and 3 witness arguments in addition to the policy script and Merkle proof: + + witness: <nowiki><policyScript> <proof> <arg1> ... <argN></nowiki> // N is between 1 and 3 + redeemScript: DEPTH TOALTSTACK // Save number of witness elements to alt-stack + TOALTSTACK // Save 1st element (required) to alt-stack + DEPTH 2 SUB // Calculate number of optional elements, ignoring policyScript and proof + DUP IF SWAP TOALTSTACK 1SUB ENDIF // Save 2nd element (optional) to alt-stack, if it is present + IF TOALTSTACK ENDIF // Save 3rd element (optional) to alt-stack, if it is present; consume counter + <nowiki><root></nowiki> 2 MERKLEBRANCHVERIFY 2DROP DROP + alt-stack: <nowiki><N+2> <argN> ... <arg1></nowiki> + +Because the number of witness elements is pushed onto the alt-stack, this enables policy scripts to verify the number of arguments passed, even though the size of the alt-stack is not usually accessible to script. +The following policy script for use with the above redeem script will only accept 2 witness elements on the alt-stack, preventing witness malleability: + + policyScript: <nowiki>FROMALTSTACK ...check arg1... FROMALTSTACK ...check&consume arg2/arg1&2... FROMALTSTACK 4 EQUAL + +The number 4 is expected as that includes the <code>policyScript</code> and <code>proof</code>. + +The verbosity of this example can be prevented by using a uniform number of witness elements as parameters for all policy subscripts, eliminating the conditionals and stack size counts. +Future script version upgrades should also consider relaxing CLEANSTACK rules to allow direct pass-through of arguments from the witness/redeem script to the policy script on the main stack. + +===Comparison with BIP114=== + +BIP114 (Merkelized Abstract Syntax Tree)[5] specifies an explicit MAST scheme activated by BIP141 script versioning[2]. +Unlike BIP114, the scheme proposed by this BIP in conjunction with BIP116 (MERKLEBRANCHVERIFY)[3] implicitly enables MAST constructs using script itself to validate membership of the policy script in the MAST. +This has the advantage of requiring vastly fewer consensus code changes, as well as potentially enabling future script-based innovation without requiring any further consensus code changes at all, as the MAST scheme itself is programmable. + +Furthermore, by adding MERKLEBRANCHVERIFY and tail-call semantics to all script using the NOP-expansion space, BIP141 style script versioning is not required. +This removes a potentially significant hurdle to deployment by making this feature not dependent on resolving outstanding issues over address formats, how script version upgrades should be deployed, and consensus over what other features might go into a v1 upgrade. + +==Implementation== + +An implementation of this BIP, including both consensus code changes and tests are available at the following Github repository: + +[https://github.com/maaku/bitcoin/tree/tail-call-semantics] + +==Deployment== + +This BIP will be deployed by BIP8 (Version bits with lock-in by height)[9] with the name "tailcall" and using bit 3. + +For Bitcoin mainnet, the BIP8 startheight will be at height M to be determined and BIP8 timeout activation will occur on height M + 50,400 blocks. + +For Bitcoin testnet, the BIP8 startheight will be at height T to be determined and BIP8 timeout activation will occur on height T + 50,400 blocks. + +We note that CLEANSTACK means that transactions which use this feature are already considered non-standard by the rules of the network, making deployment easier than was the case with, for example, with BIP68 (Relative lock-time using consensus-enforced sequence numbers)[6]. + +==Compatibility== + +The v0 segwit rules prohibit leaving anything on the stack, so for v0 parameters have to be passed on the alt stack for compatibility reasons. + +==References== + +[1] [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP16: Pay to Script Hash] + +[2] [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141: Segregated Witness (Consensus Layer)] + +[3] [https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki BIP116: MERKLEBRANCHVERIFY] + +[4] "[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015028.html An explanation and justification of the tail-call and MBV approach to MAST]", Mark Friedenbach, Bitcoin Development Mailing List, 20 September 2017. + +[5] [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP114: Merkelized Abstract Syntax Tree] + +[6] [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers] diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki new file mode 100644 index 0000000..1b2f27c --- /dev/null +++ b/bip-0118.mediawiki @@ -0,0 +1,144 @@ +<pre> + BIP: 118 + Layer: Consensus (soft fork) + Title: SIGHASH_NOINPUT + Author: Christian Decker <decker.christian@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0118 + Status: Draft + Type: Standards Track + Created: 2017-02-28 + License: BSD-3-Clause +</pre> + +== Abstract == +This BIP describes a new signature hash flag (<tt>sighash</tt>-flag) for +segwit transactions. It removes any commitment to the output being +spent from the signature verification mechanism. This enables dynamic +binding of transactions to outputs, predicated solely on the +compatibility of output scripts to input scripts. + +== Motivation == +Off-chain protocols make use of transactions that are not yet +broadcast to the Bitcoin network in order to renegotiate the final +state that should be settled on-chain. +In a number of cases it is desirable to react to a given transaction +being seen on-chain with a predetermined reaction in the form of +another transaction. +Often the reaction is identical, no matter which transaction is seen +on-chain, but the application still needs to create many identical +transactions. +This is because signatures in the input of a transaction uniquely +commit to the hash of the transaction that created the output being +spent. + +This proposal introduces a new sighash flag that modifies the behavior +of the transaction digest algorithm used in the signature creation and +verification, to exclude the previous output commitment. +By removing the commitment we enable dynamic rebinding of a signed +transaction to outputs whose <tt>witnessProgram</tt> and value match the ones +in the <tt>witness</tt> of the spending transaction. + +The dynamic binding is opt-in and can further be restricted by using +unique <tt>witnessProgram</tt> scripts that are specific to the application +instance, e.g., using public keys that are specific to the off-chain +protocol instance. + +== Specification == +<tt>SIGHASH_NOINPUT</tt> is a flag with value <tt>0x40</tt> appended to a signature +so that the signature does not commit to any of the inputs, and +therefore to the outputs being spent. The flag applies solely to the +verification of that single signature. + +The <tt>SIGHASH_NOINPUT</tt> flag is only active for segwit scripts with +version 1 or higher. Should the flag be used in a non-segwit script or +a segwit script of version 0, the current behavior is maintained and +the script execution MUST abort with a failure. + +The transaction digest algorithm from BIP 143 is used when verifying a +<tt>SIGHASH_NOINPUT</tt> signature, with the following modifications: + + 2. hashPrevouts (32-byte hash) is 32 0x00 bytes + 3. hashSequence (32-byte hash) is 32 0x00 bytes + 4. outpoint (32-byte hash + 4-byte little endian) is + set to 36 0x00 bytes + 5. scriptCode of the input is set to an empty script + 0x00 + +The <tt>value</tt> of the previous output remains part of the transaction +digest and is therefore also committed to in the signature. + +The <tt>NOINPUT</tt> flag MAY be combined with the <tt>SINGLE</tt> flag in which +case the <tt>hashOutputs</tt> is modified as per BIP +143<ref>https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki</ref>: it +only commits to the output with the matching index, if such output exists, and +is a <tt>uint256</tt> <tt>0x0000......0000</tt> otherwise. + +Being a change in the digest algorithm, the <tt>NOINPUT</tt> flag applies to +all segwit signature verification opcodes, specifically it applies to: + +* <tt>OP_CHECKSIG</tt> + +* <tt>OP_CHECKSIGVERIFY</tt> + +* <tt>OP_CHECKMULTISIG</tt> + +* <tt>OP_CHECKMULTISIGVERIFY</tt> + +== Binding through scripts == +Using <tt>NOINPUT</tt> the input containing the signature no longer +references a specific output. +Any participant can take a transaction and rewrite it by changing the +hash reference to the previous output, without invalidating the +signatures. +This allows transactions to be bound to any output that matches the +value committed to in the <tt>witness</tt> and whose <tt>witnessProgram</tt>, +combined with the spending transaction's <tt>witness</tt> returns <tt>true</tt>. + +Previously, all information in the transaction was committed in the +signature itself, while now the relationship between the spending +transaction and the output being spent is solely based on the +compatibility of the <tt>witnessProgram</tt> and the <tt>witness</tt>. + +This also means that particular care has to be taken in order to avoid +unintentionally enabling this rebinding mechanism. <tt>NOINPUT</tt> MUST NOT +be used, unless it is explicitly needed for the application, e.g., it +MUST NOT be a default signing flag in a wallet +implementation. Rebinding is only possible when the outputs the +transaction may bind to all use the same public keys. Any public key +that is used in a <tt>NOINPUT</tt> signature MUST only be used for outputs +that the input may bind to, and they MUST NOT be used for transactions +that the input may not bind to. For example an application SHOULD +generate a new key-pair for the application instance using <tt>NOINPUT</tt> +signatures and MUST NOT reuse them afterwards. + +== Deployment == +The <tt>NOINPUT</tt> sighash flag is to be deployed during a regular segwit +script update. + +== Backward compatibility == +As a soft fork, older software will continue to operate without +modification. Non-upgraded nodes, however, will not verify the +validity of the new sighash flag and will consider the transaction +valid by default. Being only applicable to segwit transactions, +non-segwit nodes will see an anyone-can-spend script and will consider +it valid. + +== Acknowledgments == + +The <tt>NOINPUT</tt> sighash flag was first proposed by Joseph Poon in +February 2016<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html</ref>, after being mentioned in the original +Lightning paper<ref>http://lightning.network/lightning-network.pdf</ref>. A formal proposal was however +deferred until after the activation of segwit. This proposal is a +continuation of this discussion and attempts to formalize it in such a +way that it can be included in the Bitcoin protocol. As such we'd like +acknowledge Joseph Poon and Thaddeus Dryja as the original inventors +of the <tt>NOINPUT</tt> sighash flag, and its uses in off-chain protocols. + +== References == + +<references/> + +== Copyright == + +This document is licensed under the BSD 3 Clause license. diff --git a/bip-0120.mediawiki b/bip-0120.mediawiki index d48cdfa..b951e93 100644 --- a/bip-0120.mediawiki +++ b/bip-0120.mediawiki @@ -5,7 +5,7 @@ Author: Kalle Rosenbaum <kalle@rosenbaum.se> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0120 - Status: Draft + Status: Withdrawn Type: Standards Track Created: 2015-07-28 </pre> diff --git a/bip-0121.mediawiki b/bip-0121.mediawiki index 34820f5..1b01a0b 100644 --- a/bip-0121.mediawiki +++ b/bip-0121.mediawiki @@ -5,7 +5,7 @@ Author: Kalle Rosenbaum <kalle@rosenbaum.se> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0121 - Status: Draft + Status: Withdrawn Type: Standards Track Created: 2015-07-27 </pre> diff --git a/bip-0125.mediawiki b/bip-0125.mediawiki index a4b0279..7dfdcbe 100644 --- a/bip-0125.mediawiki +++ b/bip-0125.mediawiki @@ -51,11 +51,11 @@ transaction) that spends one or more of the same inputs if, # The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section. -# The replacement transaction pays an absolute higher fee than the sum paid by the original transactions. +# The replacement transaction may only include an unconfirmed input if that input was included in one of the original transactions. (An unconfirmed input spends an output from a currently-unconfirmed transaction.) -# The replacement transaction does not contain any new unconfirmed inputs that did not previously appear in the mempool. (Unconfirmed inputs are inputs spending outputs from currently unconfirmed transactions.) +# The replacement transaction pays an absolute fee of at least the sum paid by the original transactions. -# The replacement transaction must pay for its own bandwidth in addition to the amount paid by the original transactions at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals. +# The replacement transaction must also pay for its own bandwidth at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals. # The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions. @@ -85,7 +85,7 @@ unconfirmed. Wallets that don't want to signal replaceability should use either a max sequence number (0xffffffff) or a sequence number of (0xffffffff-1) when -then also want to use locktime; all known wallets currently do this. +they also want to use locktime; all known wallets currently do this. They should also take care not to spend any unconfirmed transaction that signals replaceability explicitly or through inherited signaling; most wallets also currently do this by not spending any unconfirmed transactions except diff --git a/bip-0127.mediawiki b/bip-0127.mediawiki new file mode 100644 index 0000000..15c7755 --- /dev/null +++ b/bip-0127.mediawiki @@ -0,0 +1,226 @@ + +<pre> + BIP: 127 + Layer: Applications + Title: Simple Proof-of-Reserves Transactions + Author: Steven Roose <steven@stevenroose.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0127 + Status: Draft + Type: Standards Track + Created: 2019-01-28 + License: CC0-1.0 +</pre> + + +==Abstract== + +This BIP describes a simple way to construct proof-of-reserves transactions. +This proposal formalizes a standard format for constructing such proofs, easing +their construction with existing wallet infrastructure and enabling general +proof-verification software. It relies on existing standards such as regular +Bitcoin transaction serialization/validation and the BIP 174 PSBT format. +The proposal also includes the description of a PSBT extension for a better +user experience. + +==Copyright== + +This BIP is licensed under the Creative Commons CC0 1.0 Universal license. + +==Motivation== + +From the very early days in the history of Bitcoin, there have been companies +managing bitcoins for their users. These users give up control over their coins +in return for a certain service. Inevitably, there have been many cases of +companies losing their users' bitcoins without timely disclosing such events to +the public. Proofs of Reserves are a way for companies managing large amounts +of bitcoins to prove ownership over a given amount of funds. The regular proof +of control helps to ensure that no significant loss has occurred. + +While the term proof-of-reserves is not new by any means, the procedure is not +very common among high-value custodian companies. One of the reasons for this +is that every company that wants to perform a proof-of-reserves has to construct +its own way to do so. Accordingly, their users have to understand the +construction of the proof in order to be able to verify it. This raises the bar +of entry both for custodians and for users. + + +===What this BIP is not doing=== + +The proof-of-reserve construction described in this document has some known +shortcomings, mostly with regards to its privacy properties. While there exists +research about improved proof-of-reserves mechanisms that have much better +privacy properties<ref>Dagher, Gaby G., Benedikt Bünz, Joseph Bonneau, Jeremy +Clark, and Dan Boneh. "Provisions: Privacy-preserving proofs of solvency for +Bitcoin exchanges." (2015).</ref>, this BIP intentionally only formalizes +the de-facto existing method. + + +==Specification== + +Our specification consists of two parts: +# the format for the actual proofs +# a file format used to package a set of proofs and relevant metadata + +The final construction should have the following properties: +* flexible proof construction to support complex wallet infrastructures +* easy integration with existing wallet solutions (both hardware and software wallets) +* support for verification via a standard procedure, regardless of publisher of the proof +* proof prevents reuse of proofs by other parties by committing to a message +* allow validating that the issuer had the funds under his control at a certain block, regardless of what happened after that block + +===Proof Format=== + +To allow for maximal compatibility with existing systems, proofs are formatted as regular Bitcoin +transactions. However, one small adaptation to the transaction is made that has two functions: +# make the transaction unspendable to avoid putting funds at risk +# link the proof to the issuer of the proof to prevent copying proofs from other custodians + +The resulting construction is a Bitcoin transaction with the following +characteristics: + +* The first input (the "commitment input") +** MUST have the txid part of the previous outpoint set to the SHA-256 hash of the commitment message prefixed with "Proof-of-Reserves: "<ref>If the message is "Some Message", the txid part should be <tt>SHA-256("Proof-of-Reserves: Some Message")</tt> with the string encoded as UTF-8.</ref> and index 0. +* The remaining inputs +** MUST have signatures that commit to the commitment input (e.g. using <tt>SIGHASH_ALL</tt>). +* The transaction MUST have a single output that is the exact sum of all the inputs, assuming the commitment input to have 0 value; this means the transaction has no miner fee. + +The existence of the first input (which is just a commitment hash) ensures +that this transaction is invalid and can never be confirmed. + + +===Proof File Format=== + +In theory, the first part of the specification would be sufficient as a minimum +viable standard. However, there are a number of motivations to extend the +standard with an extra layer of metadata: + +# constructing and combining multiple proofs +#:Having thousands of UTXOs spread across different offline and online wallets could make it difficult to construct a single proof transaction with all UTXOs. Allowing multiple proof transactions with the same commitment message and block number gives extra flexibility to custodians with complex wallet infrastructure without making the combined proof less secure. +# metadata for verification +#:Not all systems that will be used for verification have access to a full index of all transactions. However, proofs should be easily verifiable even after some of the UTXOs used in the proof are no longer unspent. Metadata present in the proof allows for relatively efficient verification of proofs even if no transaction index is available. +# potential future improvements +#:The extensible metadata format allows for amending the standard in the future. One potential improvement would be having UTXO set commitments. These would allow the proofs-of-reserves to come with accompanying proofs-of-inclusion of all used UTXOs in the UTXO set at the block of proof construction (making validation even more efficient). + +The proposed proof-file format provides a standard way of combining multiple +proofs and associated metadata. The specification of the format is in the +Protocol Buffers<ref>https://github.com/protocolbuffers/protobuf/</ref> format. + +<pre> +syntax = "proto3"; +import "google/protobuf/any.proto"; + +message OutputMeta { + // Identify the outpoint. + bytes txid = 1; + uint32 vout = 2; + + // The block hash of the block where this output was created. + bytes block_hash = 3; +} + +message FinalProof { + // The proof transaction. Should be able to be parsed like a regular + // Bitcoin transaction. + bytes proof_tx = 1; + + // The metadata of the ouputs used in the proof transaction. + repeated OutputMeta output_metadata = 2; +} + +message ProofOfReserves { + // A version number for this format to enable extending it with + // additional fields. + uint32 version = 1; + + // The network magic for the network in which the proofs are valid. + // 0xD9B4BEF9 for mainnet, 0x0709110B for testnet + //TODO consider BIP44 coin type ids instead: + // https://github.com/satoshilabs/slips/blob/master/slip-0044.md + uint32 network_magic = 2; + + // The commitment message for this proof-of-reserves. + // This message is global for all the proofs. + string message = 3; + + // The block at which this proof is supposed to be validated. + // Verification should take into account unspentness of outputs at this + // block height. + bytes block_hash = 4; + + // The set of final proof transactions with their output metadata. + repeated FinalProof final_proofs = 5; + + // Reserved field that can potentially be used by proof-construction tools. + // It can be ignored for verification. + repeated google.protobuf.Any pending_proofs = 6; +} +</pre> + +The last field, <tt>pending_proofs</tt>, leaves open some space in the same +file that can be used by proof-construction tools. This allows them to +construct different proofs incrementally without having to switch between file +formats. + + +===PSBT (BIP 174) extension=== + +The "commitment input" detailed in the proof format section does not spend an +existing UTXO and thus shouldn't be signed (empty <tt>scriptSig</tt> and +witness). This can cause some problems when signing this type of transactions. +For example, hardware wallets often require the signer to provide information +about all inputs of transactions they are signing, such as the previous output +or previous transaction; this data obviously doesn't exist for the commitment +inputs. + +For most existing devices, it's possible to circumvent these requirements by +providing dummy data or by instructing the device to ignore this specific +input. However, there is still a UX problem. Because the hardware wallet +device doesn't recognize the transaction as a proof-of-reserves transaction it +will think it is signing a regular transaction that is spending all the money +in the UTXOs. Most devices will ask for confirmation with a message along the +lines of "Are you sure you want to send XXX BTC to address [...]?". This is +not the best user experience. + +An addition to the BIP 174 PSBT format could help signing devices to recognize proof-of-reserve transactions. +The following field is added to the BIP 174 <tt>INPUT</tt> map: + +* Type: Proof-of-reserves commitment <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x09}</tt> +** Value: The UTF-8 encoded commitment message string for the proof-of-reserves. +*** <tt>{porCommitment}</tt> + +Wallets processing an input that has this field set +* MUST make sure the txid of the previous outpoint is set to the SHA-256 hash of the prefixed commitment message string, as detailed above; +* MUST assume the input value to be 0 (without requiring the previous output or transaction to be provided); +* SHOULD display the commitment message to ask the user for confirmation before signing any inputs; +* SHOULD only provide signatures with a signature hash that commits to this input; +* SHOULD accept an empty <tt>scriptSig</tt> for this input (as if the <tt>scriptPubKey</tt> was <tt>OP_TRUE</tt>). + + +==Compatibility== + +The proof transaction specification is based on the Bitcoin transaction +serialization protocol and will thus always be compatible with serializers +that can interpret Bitcoin transactions. The protobuf file format is custom +to this BIP and has a version byte to enable updates while attempting to remain +backwards compatible. + + +==Implementations== + +A proof-of-concept implementation of the PSBT extension in the +[https://github.com/rust-bitcoin/rust-bitcoin rust-bitcoin] project can be +found in the <tt>psbt-por</tt> branch here: +https://github.com/stevenroose/rust-bitcoin/tree/psbt-por + +A work-in-progress implementation of a tool that produces and verifies proofs +in the described format can be found here: +https://github.com/stevenroose/reserves + + +== Footnotes == + +<references /> + 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-0136.mediawiki b/bip-0136.mediawiki new file mode 100644 index 0000000..f94171d --- /dev/null +++ b/bip-0136.mediawiki @@ -0,0 +1,328 @@ +<pre> + BIP: 136 + Layer: Applications + Title: Bech32 Encoded Tx Position References + Author: Велеслав <veleslav.bips@protonmail.com> + Jonas Schnelli <dev@jonasschnelli.ch> + Daniel Pape <dpape@dpape.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0136 + Status: Draft + Type: Informational + Created: 2017-07-09 + License: BSD-2-Clause +</pre> + +== Introduction == + +=== Abstract === +This document proposes a convenient human useable format, '''"TxRef"''', as a standard way to refer to a transaction position within the Bitcoin Blockchain, and optionally a particular outpoint index within the referred transaction. The primary purpose of this format is to allow users to refer to a confirmed transaction (and optionally an outpoint index within) in a standard, reliable, and concise way. + +''Please note: Unlike TxID where there is strong cryptographic link between the ID and the actual transaction, TxRef only provides a weak link to a particular transaction. TxRef locates an offset within a blockchain for a transaction, that may - or may not - point to an actual transaction, which in fact may change with reorganisations. We recommend that TxRef's should be not used for positions within the blockchain having a maturity less than 100 blocks.'' + +=== Copyright === + +This BIP is licensed under the 2-clause BSD license. + +=== Motivation === +Since the first version of Bitcoin, TxID's (Transaction Identifiers) have been a core part of the consensus protocol and have been routinely used to identify individual transactions between users. + +However, for many use-cases they have practical limitations: +* TxIDs are expensive for full nodes to lookup (requiring either a linear scan of the blockchain, or an expensive TxID index). +* TxIDs require third-party services for SPV wallets to lookup. +* TxIDs are very long HEX encoded values (64 characters long). + +For transactions that have been embedded in the blockchain, it is possible to reference them not by their TxID, but by their location within the blockchain itself. The encoding can be made friendly for occasional human transcription. In this document, we propose a standard for doing this. + +=== Examples === +These examples are for Bitcoin Transactions. +* Genesis Coinbase Transaction (Transaction #0 of Block #0): <tt>tx1:rqqq-qqqq-qmhu-qhp</tt> +* Transaction #2205 of Block #466793: <tt>tx1:rjk0-uqay-zsrw-hqe</tt> + +== Specification == + +A '''confirmed transaction position reference''', or '''TxRef''', is a reference to a particular location within the blockchain, specified by the block height and a transaction index within the block, and optionally a outpoint index within the transaction. + +''Please Note: All values in this specification are encoded in little-endian format.'' + +=== Transaction Position Reference Considerations === +A TxRef may reference a location that doesn't exist because: + +* The specified block hasn't yet been mined. Or, +* The transaction index is greater than the total number of transactions included within the specified block. +* The optional outpoint index is greater than the total outpoints contained within the transaction. + +Therefore, implementers must be careful not to display TxRef's to users prematurely: + +* Applications MUST NOT display TxRef's for transactions with less than 6 confirmations. +* Application MUST show a warning for TxRef's for transactions with less than 100 confirmations. +** This warning SHOULD state that in the case of a large reorganisation, the TxRefs Displayed may point to a different transaction, or to no transaction at all. + +=== Encoding === + +TxRef uses standard Bech32<ref name=":0">'''Why use Bech32 Encoding for Confirmed Transaction References?''' The error detection and correction properties of this encoding format make it very attractive. We expect that it will be reasonable for software to correct a maximum of two characters; however, we haven’t specified this yet.</ref> encoding as defined in [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-173] and therefore consists of: + +* Human-readable Part, or "HRP", that provides namespacing. We have chosen to distinguish between Main and Test Networks: +** For Any Mainnet Network: '''"tx"'''. +** For Any Testnet Network: '''"txtest"'''. +** Please see [https://github.com/satoshilabs/slips/blob/master/slip-0173.md SLIP-0173 : Registered human-readable parts for BIP-0173] for a full list of HRP's including these two and others relating to other projects. +* Separator: '''"1"'''. +* Data Part. + +Please note: other specifications, such as [https://w3c-ccg.github.io/did-spec/ the Decentralized Identifiers spec], have implicitly encoded the information contained within the HRP elsewhere. In this case they may choose to not include the HRP as specified here. + +To increase portability and readability additional separators SHOULD be added: + +* A Colon<ref>'''Why add a colon here?''' This allows it to conform better with W3C URN/URL standards.</ref> '''":"''' added after '1'. +* Hyphens<ref>'''Why hyphens within the TxRef?''' As TxRef's are short, we expect that they will be quoted via voice or written by hand. The inclusion of hyphens every 4 characters breaks up the string and means people don't lose their place so easily.</ref> '''"-"''' added after every 4 characters beyond the colon. + +All non-bech32-alphabet characters after the bech32 code separator MUST be ignored/removed when parsing (except for terminating characters).<ref>'''Why strip all non-bech32-alphabet characters?''' We do not wish to expect the users to keep their TxRef's in good unicode form (hyphens, colons, invisible spaces, random unicode characters, etc). We expect them to copy, paste, write by-hand, write in a mix of character sets, etc. Parsers should automatically correct for all sorts of these common errors. +</ref> +{| class="wikitable" +|+Text Encoding of the TxRef +! +!Bit +!Character +!Characters +!Value +|- +|Human Readable Part +| +|1 – 2 +|2 +|Bitcoin Mainnet: "'''tx'''", Bitcoin Testnet: "'''txtest'''" +|- +|Separator +| +|3 +|1 +|"'''1'''" +|- +|Colon +| +|4 +|1 +|"''':'''" +|- +|Data +|0 – 19 +|5 – 8 +|4 +| +|- +|Hyphen +| +|9 +|1 +|"'''-'''" +|} +The Data - Hyphen pattern is repeated for the entire length of data, ( a hyphen is inserted after every encoded 20 bits or 4 data characters). +=== Data === + +Depending on if an optional transaction outpoint is included, there can be 75 or 90 bits of data encoded in the string above. These bits are defined in this manner: + +{| class="wikitable" +|+TxRef Binary Format for Bitcoin Mainnet and Bitcoin Testnet: +! +!'''Bit''' +!'''Bit(s)''' +!'''Type''' +!'''Values''' +!'''Notes''' +|- +|Magic Code +|0 – 4 +|5 +|Chain Namespacing Code +|'''0x3''' for Bitcoin Mainnet. +'''0x4''' for Bitcoin Mainnet with Outpoint. +'''0x6''' for Bitcoin Testnet. +'''0x7''' for Bitcoin Testnet with Outpoint. +| +|- +|Version +|5 +|1 +|For Future Use +|Must be '''0x0''' +| +|- +|Block Height +|6 – 29 +|24 +|The Block Height of the Tx +|Block 0 (genesis) to block 16777215 +|Until Year ~2328 +|- +|Transaction Index +|30 – 44 +|15 +|The index of the Tx inside the block +|Tx 0 (coinbase) to Tx position 32767 +|Max Tx's in block is 16665 +|} +If the magic code is '''0x4''' or '''0x7''', an optional outpoint is included in the encoding: + +{| class="wikitable" +|+Optional Outpoint Index Encoding: +! +!'''Bit''' +!'''Bit(s)''' +!'''Type''' +!'''Values''' +!'''Notes''' +|- +|Outpoint Index +|45 – 59 +|15 +|The index of the Outpoint inside the Tx +|Outpoint 0 to Outpoint Position 32767 +| +|} + +We include the 30-bit checksum last: +{| class="wikitable" +|+Bech32 Checksum Encoding: +! +!'''Bit''' +!'''Bit(s)''' +!'''Type''' +!'''Values''' +!'''Notes''' +|- +|Checksum +|45 – 74 or 60 – 89 +|30 +|Bech32 Checksum +| +| +|} + +==== Magic Notes: ==== +The magic code provides namespacing between chains. 5-bit magic codes are used for the Bitcoin Mainnet and the Bitcoin Testnet. (it may be significantly longer for other projects/chains): + +* For Bitcoin Mainnet the magic code is: '''0x3''', leading to an '''"r"''' character when encoded. +* For Bitcoin Mainnet with Outpoint Encoded the magic code is: '''0x4''', leading to an '''"y"''' character when encoded. +* For Bitcoin Testnet the magic code is: '''0x6''', leading to an '''"x"''' character when encoded. +* For Bitcoin Testnet with Outpoint Encoded the magic code is: '''0x7''', leading to an '''"8"''' character when encoded. + +Codes '''0x0''', '''0x1''', '''0x2''', '''0x5''', are also reserved for future use within the Bitcoin project. + +''Any other chain MUST NOT start their magic code with any value between 0x0 and 0x7 inclusive.'' + +Other magic codes will be specified in SLIP-XXXX "TxRef for Non-Bitcoin Chains and Networks". + +=== Compatibility === +There are no known compatibility issues. + +== Rationale == + +<references /> + +== Reference implementations == +C Reference Implementation (supports magic codes 0x3 and 0x6): https://github.com/jonasschnelli/bitcoin_txref_code + +Go Reference Implementation (supports magic codes 0x3 and 0x6): https://github.com/kulpreet/txref + +C++ Reference Implementation (support magic codes 0x3, 0x4, 0x6, 0x7): https://github.com/dcdpr/btcr-DID-method/ + +== Appendices == + +=== Test Vectors === +There are two sets of Test Vectors included here: + +* Bech32 Encoding Test Vectors. These are to test if a implementation accepts the encoding, with the correct human readable part, and separator. +* Bitcoin TxRef Test Vectors. These test the full specification, in particular, correct values for block height and the transaction index. + +==== Bech32 Encoding (for TxRef). ==== +''Please Note: All test vectors are shown to help test if a string is compliant or not. All real-life applications (such as for Bitcoin) should comply with the Bitcoin Test Vectors listed Below.'' + +The following strings have a valid Human Readable Part and Bech32 Checksum. +* <tt>TX1A12UEL5L</tt> +* <tt>tx1an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs</tt> +* <tt>tx1abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw</tt> +* <tt>tx11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j</tt> + +The following list gives invalid TxRef's and the reason for their invalidity. +* <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty</tt>: Invalid human-readable part +* <tt>tx1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5</tt>: Invalid checksum + +==== Bitcoin TxRef (mainnet and testnet) ==== +The following list gives properly encoded Bitcoin mainnet TxRef's and the values in hex. (block height, transaction index) + +* <tt>tx1:rqqq-qqqq-qmhu-qhp</tt>: <tt>(0x0, 0x0)</tt> +* <tt>tx1:rqqq-qqll-l8xh-jkg</tt>: <tt>(0x0, 0x7FFF)</tt> +* <tt>tx1:r7ll-llqq-qghq-qr8</tt>: <tt>(0xFFFFFF, 0x0)</tt> +* <tt>tx1:r7ll-llll-l5xt-jzw</tt>: <tt>(0xFFFFFF, 0x7FFF)</tt> + +The following list gives properly encoded Bitcoin testnet TxRef's and the values in hex. (block height, transaction index) + +* <tt>txtest1:xqqq-qqqq-qkla-64l</tt>: <tt>(0x0, 0x0)</tt> +* <tt>txtest1:xqqq-qqll-l2wk-g5k</tt>: <tt>(0x0, 0x7FFF)</tt> +* <tt>txtest1:x7ll-llqq-q9lp-6pe</tt>: <tt>(0xFFFFFF, 0x0)</tt> +* <tt>txtest1:x7ll-llll-lew2-gqs</tt>: <tt>(0xFFFFFF, 0x7FFF)</tt> + +The following list gives valid (though strangely formatted) Bitcoin TxRef's and the values in hex. (block height, transaction index) +* <tt>tx1:rjk0-uqay-zsrw-hqe</tt>: <tt>(0x71F69, 0x89D)</tt> +* <tt>TX1RJK0UQAYZSRWHQE</tt>: <tt>(0x71F69, 0x89D)</tt> +* <tt>TX1RJK0--UQaYZSRw----HQE</tt>: <tt>(0x71F69, 0x89D)</tt> +* <tt>tx1 rjk0 uqay zsrw hqe</tt>: <tt>(0x71F69, 0x89D)</tt> +* <tt>tx1!rjk0\uqay*zsrw^^hqe</tt>: <tt>(0x71F69, 0x89D)</tt> + +The following list gives invalid Bitcoin TxRef's and the reason for their invalidity. +* <tt>tx1:t7ll-llll-ldup-3hh</tt>: Magic 0xB instead of 0x3. <tt>(0xFFFFFF, 0x7FFF)</tt> +* <tt>tx1:rlll-llll-lfet-r2y</tt>: Version 1 instead of 0. <tt>(0xFFFFFF, 0x7FFF)</tt> +* <tt>tx1:rjk0-u5ng-gghq-fkg7</tt>: Valid Bech32, but 10x5bit packages instead of 8. +* <tt>tx1:rjk0-u5qd-s43z</tt>: Valid Bech32, but 6x5bit packages instead of 8. + +==== Bitcoin TxRef with Outpoints (mainnet and testnet) ==== +The following list gives properly encoded Bitcoin mainnet TxRef's with Outpoints and the values in hex. (block height, transaction index, TXO index) + +* <tt>tx1:yqqq-qqqq-qqqq-ksvh-26</tt>: <tt>(0x0, 0x0, 0x0)</tt> +* <tt>tx1:yqqq-qqll-lqqq-v0h2-2k</tt>: <tt>(0x0, 0x7FFF, 0x0)</tt> +* <tt>tx1:y7ll-llqq-qqqq-a5zy-tc</tt>: <tt>(0xFFFFFF, 0x0, 0x0)</tt> +* <tt>tx1:y7ll-llll-lqqq-8tee-t5</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x0)</tt> + +* <tt>tx1:yqqq-qqqq-qpqq-5j9q-nz</tt>: <tt>(0x0, 0x0, 0x1)</tt> +* <tt>tx1:yqqq-qqll-lpqq-wd7a-nw</tt>: <tt>(0x0, 0x7FFF, 0x1)</tt> +* <tt>tx1:y7ll-llqq-qpqq-lktn-jq</tt>: <tt>(0xFFFFFF, 0x0, 0x1)</tt> +* <tt>tx1:y7ll-llll-lpqq-9fsw-jv</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x1)</tt> + +* <tt>tx1:yjk0-uqay-zrfq-g2cg-t8</tt>: <tt>(0x71F69, 0x89D, 0x123)</tt> +* <tt>tx1:yjk0-uqay-zu4x-nk6u-pc</tt>: <tt>(0x71F69, 0x89D, 0x1ABC)</tt> + +The following list gives properly encoded Bitcoin testnet TxRef's with Outpoints and the values in hex. (block height, transaction index, TXO index) + +* <tt>txtest1:8qqq-qqqq-qqqq-cgru-fa</tt>: <tt>(0x0, 0x0, 0x0)</tt> +* <tt>txtest1:8qqq-qqll-lqqq-zhcp-f3</tt>: <tt>(0x0, 0x7FFF, 0x0)</tt> +* <tt>txtest1:87ll-llqq-qqqq-nvd0-gl</tt>: <tt>(0xFFFFFF, 0x0, 0x0)</tt> +* <tt>txtest1:87ll-llll-lqqq-fnkj-gn</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x0)</tt> + +* <tt>txtest1:8qqq-qqqq-qpqq-622t-s9</tt>: <tt>(0x0, 0x0, 0x1)</tt> +* <tt>txtest1:8qqq-qqll-lpqq-q43k-sf</tt>: <tt>(0x0, 0x7FFF, 0x1)</tt> +* <tt>txtest1:87ll-llqq-qpqq-3wyc-38</tt>: <tt>(0xFFFFFF, 0x0, 0x1)</tt> +* <tt>txtest1:87ll-llll-lpqq-t3l9-3t</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x1)</tt> + +* <tt>txtest1:8jk0-uqay-zrfq-xjhr-gq</tt>: <tt>(0x71F69, 0x89D, 0x123)</tt> +* <tt>txtest1:8jk0-uqay-zu4x-aw4h-zl</tt>: <tt>(0x71F69, 0x89D, 0x1ABC)</tt> + + +=== Bitcoin TxRef Payload Value Choice: === +Some calculations showing why we chose these particular bit-length of the block height and transaction index. + +==== Block Height Value: ==== +24-bit: between 0, and 0xFFFFFF (16,777,216 blocks). + +*There are ~52,500 blocks every year, leading to ~319 years of blocks addressable. +*Therefore before year 2328 this specification should be extended. (We think that we have plenty of time). + +==== Tx Position Value: ==== +15-bit: between 0x0, and 0x7FFF. (32,768 transactions). + +*The ''realistic'' smallest Tx is 83 Bytes: Max 12047 tx in a block. +**4B version + 1B tx_in count + 36B previous_output + 1B script length + 0B signature script + 4B sequence + 1B tx_out count + 8B amount + 1B script length + 23B pubkey script + 4B lock_time = 83B +*The ''extreme'' smallest Tx is 60 Byte's: Max 16665 tx in a block. +**4B version + 1B tx_in count + 36B previous_output + 1B script length + 0B signature script + 4B sequence + 1B tx_out count + 8B amount + 1B script length + 0B pubkey script + 4B lock_time = 60B + +== Acknowledgements == +Special Thanks to Pieter Wuille and Greg Maxwell for Bech32, a wonderful user-facing data encoding. diff --git a/bip-0137.mediawiki b/bip-0137.mediawiki new file mode 100644 index 0000000..7ef89f4 --- /dev/null +++ b/bip-0137.mediawiki @@ -0,0 +1,135 @@ +<pre> + BIP: 137 + Layer: Applications + Title: Signatures of Messages using Private Keys + Author: Christopher Gilliard <christopher.gilliard@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0137 + Status: Final + Type: Standards Track + Created: 2019-02-16 + License: BSD-2-Clause +</pre> + +==Abstract== + +This document describes a signature format for signing messages with Bitcoin private keys. + +The specification is intended to describe the standard for signatures of messages that can be signed and verfied between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme. + +One of the key problems in this area is that there are several different types of Bitcoin addresses and without introducing specific standards it is unclear which type of address format is being used. See [2]. This BIP will attempt to address these issues and define a clear and concise format for Bitcoin signatures. + +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + +==Motivation== + +Since Bitcoin private keys can not only be used to sign Bitcoin transactions, but also any other message, it has become customary to use them to sign various messages for differing purposes. Some applications of signing messages with a Bitcoin private key are as follows: proof of funds for collateral, credit worthiness, enterence to events, airdrops, audits as well as other applications. While there was no BIP written for how to digitally sign messages with Bitcoin private keys with P2PKH addresses it is a fairly well understood process, however with the introduction of Segwit (both in the form of P2SH and bech32) addresses, it is unclear how to distinguish a P2PKH, P2SH, or bech32 address from one another. This BIP proposes a standard signature format that will allow clients to distinguish between the different address formats. + +==Specification== + +===Background on ECDSA Signatures=== + +(For readers who already understand how ECDSA signatures work, you can skip this section as this is only intended as background information.) +Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners. + +A few concepts related to ECDSA: + +<b>private key</b>: A secret number, known only to the person that generated it. A private key is essentially a randomly generated number. In Bitcoin, someone with the private key that corresponds to funds on the block chain can spend the funds. In Bitcoin, a private key is a single unsigned 256 bit integer (32 bytes). + +<b>public key</b>: A number that corresponds to a private key, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine (in other words, produced with the proper key) without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called x. The older uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called x and y (2 * 32 bytes). The prefix of a compressed key allows for the y value to be derived from the x value. + +<b>signature</b>: A number that proves that a signing operation took place. A signature is mathematically generated from a hash of something to be signed, plus a private key. The signature itself is two numbers known as r and s. With the public key, a mathematical algorithm can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are either 73, 72, or 71 bytes long, with probabilities approximately 25%, 50% and 25% respectively, although sizes even smaller than that are possible with exponentially decreasing probability. Source [3]. + +===Conventions with signatures used in Bitcoin=== + +Bitcoin signatures have the r and s values mentioned above, and a header. The header is a single byte and the r and s are each 32 bytes so a signature's size is 65 bytes. The header is used to specify information about the signature. It can be thought of as a bitmask with each bit in this byte having a meaning. The serialization format of a Bitcoin signature is as follows: + +[1 byte of header data][32 bytes for r value][32 bytes for s value] + +The header byte has a few components to it. First, it stores something known as the recId. This value is stored in the least significant 2 bits of the header. If the header is between a value of 31 and 34, this indicates that it is a compressed address. If the header value is between 35 and 38 inclusive, it is a p2sh segwit address. If the header value is between 39 and 42, it is a bech32 address. + +===Procedure for signing/verifying a signature=== + +As noted above the signature is composed of three components, the header, r and s values. r/s can be computed with standard ECDSA library functions. Part of the header includes something called a recId. This is part of every ECDSA signature and should be generated by the ECDSA library. The recId is a number between 0 and 3 inclusive. The header is the recId plus a constant which indicates what time of Bitcoin private key this is. For P2PKH uncompressed keys, this value is 27. For P2PKH compressed keys, this value is 31. For P2SH Segwit keys, this value is 35 and for bech32 keys, this value is 35. So, you have the following ranges: +27-30: P2PKH uncompressed +31-34: P2PKH compressed +35-38: Segwit P2SH +39-42: Segwit Bech32 + +To verify a signature, the recId is obtained by subtracting this constant from the header value. + +===Sample Code for processing a signature=== + +Note: this code is a modification of the BitcoinJ code which is written in java. + + public static ECKey signedMessageToKey(String message, String signatureBase64) throws SignatureException { + byte[] signatureEncoded; + try { + signatureEncoded = Base64.decode(signatureBase64); + } catch (RuntimeException e) { + // This is what you get back from Bouncy Castle if base64 doesn't decode :( + throw new SignatureException("Could not decode base64", e); + } + // Parse the signature bytes into r/s and the selector value. + if (signatureEncoded.length < 65) + throw new SignatureException("Signature truncated, expected 65 bytes and got " + signatureEncoded.length); + int header = signatureEncoded[0] & 0xFF; + // The header byte: 0x1B = first key with even y, 0x1C = first key with odd y, + // 0x1D = second key with even y, 0x1E = second key with odd y + if (header < 27 || header > 42) + throw new SignatureException("Header byte out of range: " + header); + BigInteger r = new BigInteger(1, Arrays.copyOfRange(signatureEncoded, 1, 33)); + BigInteger s = new BigInteger(1, Arrays.copyOfRange(signatureEncoded, 33, 65)); + ECDSASignature sig = new ECDSASignature(r, s); + byte[] messageBytes = formatMessageForSigning(message); + // Note that the C++ code doesn't actually seem to specify any character encoding. Presumably it's whatever + // JSON-SPIRIT hands back. Assume UTF-8 for now. + Sha256Hash messageHash = Sha256Hash.twiceOf(messageBytes); + boolean compressed = false; + // this section is added to support new signature types + if(header>= 39) // this is a bech32 signature + { + header -= 12; + compressed = true; + } // this is a segwit p2sh signature + else if(header >= 35) + { + header -= 8; + compressed = true; + } // this is a compressed key signature + else if (header >= 31) { + compressed = true; + header -= 4; + } + int recId = header - 27; + ECKey key = ECKey.recoverFromSignature(recId, sig, messageHash, compressed); + if (key == null) + throw new SignatureException("Could not recover public key from signature"); + return key; + } + +==Backwards Compatibility== + +Since this format includes P2PKH keys, it is backwards compatible, but keep in mind some software has checks for ranges of headers and will report the newer segwit header types as errors. + +==Implications== + +Message signing is an important use case and potentially underused due to the fact that, up until now, there has not been a formal specification for how wallets can sign messages using Bitcoin private keys. Bitcoin wallets should be interoperable and use the same conventions for determing a signature's validity. This BIP can also be updated as new signature formats emerge. + +==Acknowledgements== + +* Konstantin Bay - review +* Holly Casaletto - review +* James Bryrer - review + +Note that the background on ECDSA signatures was taken from en.bitcoin.it and code sample modified from BitcoinJ. + +==References== + +[1] - https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki + +[2] - https://github.com/bitcoin/bitcoin/issues/10542 + +[3] - https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm 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..82f6abd 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: Final 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. @@ -324,6 +324,7 @@ https://github.com/bitcoin/bitcoin/pull/8149 *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]] *[[bip-0144.mediawiki|BIP144 Segregated Witness (Peer Services)]] +*[[bip-0173.mediawiki|BIP173 Base32 address format for native v0-16 witness outputs]] == Copyright == 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..81763a0 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: Final 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 committed, 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): @@ -303,7 +303,7 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH scriptCode: 4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac ^^ - (please note that the not-yet-exectued OP_CODESEPARATOR is not removed from the scriptCode) + (please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode) preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8000000004721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000 sigHash: 82dde6e4f1e94d02c2b7ad03d2115d691f48d064e9d52f58194a6637e4194391 public key: 026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae @@ -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): @@ -391,7 +391,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an 02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac nLockTime: 00000000 - Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the the input-output pairs are swapped: + Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the input-output pairs are swapped: 0100000000010280e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffffe9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff0280969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac80969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000 nVersion: 01000000 marker: 00 diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index 8e65554..8ec2191 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: Final Type: Standards Track Created: 2016-01-08 License: PD @@ -79,11 +79,11 @@ The serialization has the following structure: Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output. -If the witness is empty, the old serialization format should be used. +If the witness is empty, the old serialization format must 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..2d007c6 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: Final 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..005c552 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -3,9 +3,9 @@ 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 + Status: Withdrawn Type: Standards Track Created: 2016-03-23 License: PD @@ -18,7 +18,7 @@ This BIP describes an alternative way that a peer can encrypt their communicatio == Motivation == -The Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users. Mostly this is negligible because of the nature of Bitcoins trust model, however for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer. +The Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users. Mostly this is negligible because of the nature of Bitcoin's trust model, however, for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer. Encrypting peer traffic will make analysis and specific user targeting much more difficult than it currently is. Today it's trivial for a network provider or any other men-in-the-middle to identify a Bitcoin user and its controlled addresses/keys (and link with his Google profile, etc.). Just created and broadcasted transactions will reveal the amount and the payee to the network provider. @@ -26,13 +26,13 @@ This BIP also describes a way that data manipulation (blocking commands by a int Analyzing the type of p2p communication would still be possible because of the characteristics (size, sending-interval, etc.) of the encrypted messages. -Encrypting traffic between peers is already possible with VPN, tor, stunnel, curveCP or any other encryption mechanism on a deeper OSI level, however, most mechanism are not practical for SPV or other DHCP/NAT environment and will require significant knowhow in how to setup such a secure channel. +Encrypting traffic between peers is already possible with VPN, tor, stunnel, curveCP or any other encryption mechanism on a deeper OSI level, however, most mechanisms are not practical for SPV or other DHCP/NAT environment and will require significant knowhow in how to setup such a secure channel. == Specification == A peer that supports encryption must accept encryption requests from all peers. -A independent ECDH negotiation for both communication directions is required and therefore a bidirectional communication will use two symmetric cipher keys (one per direction). +An independent ECDH negotiation for both communication directions is required and therefore a bidirectional communication will use two symmetric cipher keys (one per direction). Both peers must only send encrypted messages after a successful ECDH negotiation in ''both directions''. @@ -40,7 +40,7 @@ Encryption initialization must happen before sending any other messages to the r === Symmetric Encryption Cipher Keys === -The symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be derived with HKDF [2] after the following specification: +The symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of an ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be derived with HKDF [2] after the following specification: 1. HKDF extraction <code>PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinecdh", ikm=ecdh_secret|cipher-type)</code>. @@ -59,7 +59,7 @@ Both sides must also calculate the 256bit session-id using <code>SID = HKDF_EXPA === The <code>encinit</code> message type === -To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an <code>encinit</code> message to the responding peer and waits for a <code>encack</code> message. The responding node must do the same <code>encinit</code>/<code>encack</code> interaction for the opposite communication direction. +To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an <code>encinit</code> message to the responding peer and waits for an <code>encack</code> message. The responding node must do the same <code>encinit</code>/<code>encack</code> interaction for the opposite communication direction. {|class="wikitable" ! Field Size !! Description !! Data type !! Comments @@ -90,11 +90,11 @@ The chacha20-poly1305@openssh.com specified and defined by openssh [5] combines <code>K_2</code> must be used in conjunction with poly1305 to build an AEAD. -Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304. +Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per byte then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304. === The <code>encack</code> message type === -The responding peer accepts the encryption request by sending a <code>encack</code> message. +The responding peer accepts the encryption request by sending an <code>encack</code> message. {|class="wikitable" ! Field Size !! Description !! Data type !! Comments @@ -150,7 +150,7 @@ If more data is present, another message must be deserialized. There is no expli === Re-Keying === -A responding peer can inform the requesting peer over a re-keying with a <code>encack</code> message containing 33byte of zeros to indicate that all encrypted message following after this <code>encack</code> message will be encrypted with ''the next symmetric cipher key''. +A responding peer can inform the requesting peer over a re-keying with an <code>encack</code> message containing 33byte of zeros to indicate that all encrypted message following after this <code>encack</code> message will be encrypted with ''the next symmetric cipher key''. The new symmetric cipher key will be calculated by <code>SHA256(SHA256(session_id || old_symmetric_cipher_key))</code>. @@ -172,12 +172,12 @@ This proposal is backward compatible. Non-supporting peers will ignore the <code == References == -* [1] http://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf +* [1] https://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf * [2] HKDF (RFC 5869) https://tools.ietf.org/html/rfc5869 -* [3] ChaCha20 http://cr.yp.to/chacha/chacha-20080128.pdf -* [4] Poly1305 http://cr.yp.to/mac/poly1305-20050329.pdf +* [3] ChaCha20 https://cr.yp.to/chacha/chacha-20080128.pdf +* [4] Poly1305 https://cr.yp.to/mac/poly1305-20050329.pdf * [5] https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305 -* [6] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03 +* [6] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03 == Acknowledgements == * Pieter Wuille and Gregory Maxwell for most of the ideas in this BIP. 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-0155.mediawiki b/bip-0155.mediawiki new file mode 100644 index 0000000..5914241 --- /dev/null +++ b/bip-0155.mediawiki @@ -0,0 +1,189 @@ +<pre> + BIP: 155 + Layer: Peer Services + Title: addrv2 message + Author: Wladimir J. van der Laan <laanwj@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0155 + Status: Draft + Type: Standards Track + Created: 2019-02-27 + License: BSD-2-Clause +</pre> + +==Introduction== + +===Abstract=== + +This document proposes a new P2P message to gossip longer node addresses over the P2P network. +This is required to support new-generation Onion addresses, I2P, and potentially other networks +that have longer endpoint addresses than fit in the 128 bits of the current <code>addr</code> message. + +===Copyright=== + +This BIP is licensed under the 2-clause BSD license. + +===Motivation=== + +Tor v3 hidden services are part of the stable release of Tor since version 0.3.2.9. They have +various advantages compared to the old hidden services, among which better encryption and privacy +<ref>[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt Tor Rendezvous Specification - Version 3]</ref>. +These services have 256 bit addresses and thus do not fit in the existing <code>addr</code> message, which encapsulates onion addresses in OnionCat IPv6 addresses. + +Other transport-layer protocols such as I2P have always used longer +addresses. This change would make it possible to gossip such addresses over the +P2P network, so that other peers can connect to them. + +==Specification== + +<blockquote> +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<ref>[https://tools.ietf.org/html/rfc2119 RFC 2119]</ref>. +</blockquote> + +The <code>addrv2</code> message is defined as a message where <code>pchCommand == "addrv2"</code>. +It is serialized in the standard encoding for P2P messages. +Its format is similar to the current <code>addr</code> message format +<ref>[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]</ref>, with the difference that the +fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the time and services format has been changed to VARINT. + +This means that the message contains a serialized <code>std::vector</code> of the following structure: + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Type +!Name +!Description +|- +| <code>VARINT</code> (unsigned) +| <code>time</code> +| Time that this node was last seen as connected to the network. A time in Unix epoch time format, up to 64 bits wide. +|- +| <code>VARINT</code> (unsigned) +| <code>services</code> +| Service bits. A 64-wide bit field. +|- +| <code>uint8_t</code> +| <code>networkID</code> +| Network identifier. An 8-bit value that specifies which network is addressed. +|- +| <code>std::vector<uint8_t></code> +| <code>addr</code> +| Network address. The interpretation depends on networkID. +|- +| <code>uint16_t</code> +| <code>port</code> +| Network port. If not relevant for the network this MUST be 0. +|} + +One message can contain up to 1,000 addresses. Clients SHOULD reject messages with more addresses. + +Field <code>addr</code> has a variable length, with a maximum of 32 bytes (256 bits). Clients SHOULD reject +longer addresses. + +The list of reserved network IDs is as follows: + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Network ID +!Enumeration +!Address length (bytes) +!Description +|- +| <code>0x01</code> +| <code>IPV4</code> +| 4 +| IPv4 address (globally routed internet) +|- +| <code>0x02</code> +| <code>IPV6</code> +| 16 +| IPv6 address (globally routed internet) +|- +| <code>0x03</code> +| <code>TORV2</code> +| 10 +| Tor v2 hidden service address +|- +| <code>0x04</code> +| <code>TORV3</code> +| 32 +| Tor v3 hidden service address +|- +| <code>0x05</code> +| <code>I2P</code> +| 32 +| I2P overlay network address +|- +| <code>0x06</code> +| <code>CJDNS</code> +| 16 +| Cjdns overlay network address +|} + +To allow for future extensibility, clients MUST ignore address types that they do not know about. +Client MAY store and gossip address formats that they do not know about. Further network ID numbers MUST be reserved in a new BIP document. + +Clients SHOULD reject addresses that have a different length than specified in this table for a specific address ID, as these are meaningless. + +See the appendices for the address encodings to be used for the various networks. + +==Compatibility== + +Send <code>addrv2</code> messages only, and exclusively, when the peer has a certain protocol version (or higher): +<source lang="c++"> +//! gossiping using `addrv2` messages starts with this version +static const int GOSSIP_ADDRV2_VERSION = 70016; +</source> +For older peers keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types. + +==Reference implementation== + +The reference implementation is available at (to be done) + +==Acknowledgements== + +- Jonas Schnelli: change <code>services</code> field to VARINT, to make the message more compact in the likely case instead of always using 8 bytes. + +- Luke-Jr: change <code>time</code> field to VARINT, for post-2038 compatibility. + +- Gregory Maxwell: various suggestions regarding extensibility + +==Appendix A: Tor v2 address encoding== + +The new message introduces a separate network ID for <code>TORV2</code>. + +Clients MUST send Tor hidden service addresses with this network ID, with the 80-bit hidden service ID in the address field. This is the same as the representation in the legacy <code>addr</code> message, minus the 6 byte prefix of the OnionCat wrapping. + +Clients SHOULD ignore OnionCat (<code>fd87:d87e:eb43::/48</code>) addresses on receive if they come with the <code>IPV6</code> network ID. + +==Appendix B: Tor v3 address encoding== + +According to the spec <ref>[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt Tor Rendezvous Specification - Version 3: Encoding onion addresses]</ref>, next-gen <code>.onion</code> addresses are encoded as follows: +<pre> +onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion" + CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2] + + where: + - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service. + - VERSION is an one byte version field (default value '\x03') + - ".onion checksum" is a constant string + - CHECKSUM is truncated to two bytes before inserting it in onion_address +</pre> + +Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte PUBKEY part in the address field. As VERSION will always be '\x03' in the case of v3 addresses, this is enough to reconstruct the onion address. + +==Appendix C: I2P address encoding== + +Like Tor, I2P naming uses a base32-encoded address format<ref>[https://geti2p.net/en/docs/naming#base32 I2P: Naming and address book]</ref>. + +I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by <code>.b32.i2p</code>. + +I2P addresses MUST be sent with the <code>I2P</code> network ID, with the decoded SHA-256 hash as address field. + +==Appendix D: Cjdns address encoding== + +Cjdns addresses are simply IPv6 addresses in the <code>fc00::/8</code> range<ref>[https://github.com/cjdelisle/cjdns/blob/6e46fa41f5647d6b414612d9d63626b0b952746b/doc/Whitepaper.md#pulling-it-all-together Cjdns whitepaper: Pulling It All Together]</ref>. They MUST be sent with the <code>CJDNS</code> network ID. + +==References== + +<references/> diff --git a/bip-0156.mediawiki b/bip-0156.mediawiki new file mode 100644 index 0000000..dde928a --- /dev/null +++ b/bip-0156.mediawiki @@ -0,0 +1,321 @@ +<pre> + BIP: 156 + Layer: Peer Services + Title: Dandelion - Privacy Enhancing Routing + Author: Brad Denby <bdenby@cmu.edu> + Andrew Miller <soc1024@illinois.edu> + Giulia Fanti <gfanti@andrew.cmu.edu> + Surya Bakshi <sbakshi3@illinois.edu> + Shaileshh Bojja Venkatakrishnan <shaileshh.bv@gmail.com> + Pramod Viswanath <pramodv@illinois.edu> + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0156 + Status: Draft + Type: Standards Track + Created: 2017-06-09 + License: CC0-1.0 +</pre> + +==Abstract== + +Bitcoin's transaction spreading protocol is vulnerable to deanonymization +attacks. Dandelion is a transaction routing mechanism that provides formal +anonymity guarantees against these attacks. When a node generates a transaction +without Dandelion, it transmits that transaction to its peers with independent, +exponential delays. This approach, known as diffusion in academia, allows +network adversaries to link transactions to IP addresses. + +Dandelion mitigates this class of attacks by sending transactions over a +randomly selected path before diffusion. Transactions travel along this path +during the "stem phase" and are then diffused during the "fluff phase" (hence +Dandelion). We have shown that this routing protocol provides near-optimal +anonymity guarantees among schemes that do not introduce additional encryption +mechanisms. + +==Motivation== + +Transaction diffusion in Bitcoin is vulnerable to deanonymization attacks. +Because transactions are sent to peers with independent, exponential delays, +messages spread through the network in a statistically symmetric manner. This +pattern allows colluding spy nodes to infer the transaction source. Breaking +this symmetry prevents the attack. However, we have shown that an adversary with +knowledge of the network topology can launch a much more effective "fingerprint" +attack if the symmetry breaking is not done properly. + +Consider a botnet-style adversary with access to the P2P graph. Botnets of size +comparable to the Bitcoin P2P network are common and cheap, and these +adversaries can learn the network structure with probe messages. We have shown +that such an adversary can achieve total deanonymization of the entire network +after observing less than ten transactions per node. + +Dandelion is a practical, lightweight privacy solution that provides the Bitcoin +network formal anonymity guarantees. While other privacy solutions aim to +protect individual users, Dandelion protects anonymity by limiting the +capability of adversaries to deanonymize the entire network. + +==How Dandelion Works== + +Dandelion enhances user privacy by sending transactions through an anonymity +phase before diffusing them throughout the network. At a high level, Dandelion +enhances privacy by (i) breaking the symmetry of diffusion and (ii) mixing +transactions by forwarding messages from different sources along the same path. + +Dandelion routing can be conceptualized in three phases. First, a privacy graph +is constructed. In practice, this privacy graph is constructed in a fully +decentralized manner and is a subgraph of the existing Bitcoin P2P network. +Next, transactions are forwarded along this privacy graph during the "stem +phase." Finally, messages are broadcast to the network during the "fluff phase" +using the typical method of diffusion. + +[[File:bip-0156/1-dandelion.png|framed|center|alt=An illustration of Dandelion routing|Figure 1]] +Figure 1 + +In order to select the privacy graph in a decentralized manner, each node +selects a subset of its outbound peers to be Dandelion destinations. Dandelion +transactions (transactions in their stem phase) that arrive at this node via +inbound connections are forwarded to these Dandelion destinations. + +In an ideal setting, we have found that a Hamiltonian circuit provides +near-optimal privacy guarantees. However, constructing a Hamiltonian circuit +through the Bitcoin P2P network in a decentralized, trustless manner is not +feasible. Thus, we recommend that each node select two Dandelion destinations +uniformly at random without replacement from its list of outbound peers. Our +tests have shown that this method provides comparable privacy with increased +robustness. + +During stem phase routing, there is a question of how to route messages in order +to protect privacy. For example, if two Dandelion transactions arrive at a node +from different inbound peers, to which Dandelion destination(s) should these +transactions be sent? We have found that some choices are much better than +others. + +Consider the case in which each Dandelion transaction is forwarded to a +Dandelion destination selected uniformly at random. This approach results in a +fingerprint attack allowing network-level botnet adversaries to achieve total +deanonymization of the P2P network after observing less than ten transactions +per node. + +[[File:bip-0156/2-attack.png|framed|center|alt=An illustration of a fingerprint attack|Figure 2]] +Figure 2 + +During a fingerprint attack, a botnet-style adversary with knowledge of the +graph structure first simulates transaction propagation. This offline step lets +the adversary generate fingerprints for each network node. During the online +attack, the adversary collects transactions at its spy nodes and matches these +observations to the simulated fingerprints. Our simulations have shown that this +attack results in devastating, network-wide deanonymization. + +[[File:bip-0156/3-attack-plot.png|framed|center|alt=A plot illustrating total deanonymization|Figure 3]] +Figure 3 + +To avoid this issue, we suggest "per-inbound-edge" routing. Each inbound peer is +assigned a particular Dandelion destination. Each Dandelion transaction that +arrives via this peer is forwarded to the same Dandelion destination. +Per-inbound-edge routing breaks the described attack by blocking an adversary's +ability to construct useful fingerprints. Fingerprints arise when routing +decisions are made independently per transaction at each node. In this case, two +transactions from the same node generally take different paths through the +network. Crucially, this results in multiple, unique data points that are +aggregated to match with a fingerprint. + +Dandelion ensures that two transactions from the same node take the same network +path, limiting adversaries to the far-left of the graph in Figure 3. In other +words, adversary knowledge is limited to the case of one observed message rather +than a rich profile of multiple transaction paths. Dandelion also breaks the +symmetry of diffusion, making the source of the transaction difficult to infer. + +[[File:bip-0156/4-dandelion-plot.png|framed|center|alt=A plot illustrating limited deanonymization|Figure 4]] +Figure 4 + +After a transaction has traveled along a Dandelion stem for a random number of +hops, it transitions into the fluff phase of routing. The transaction is shared +with the network through the existing process of diffusion. In practice, this +fluff mechanism is enforced by a weighted coin flip at each node. If the random +value is below some threshold, the Dandelion transaction is transformed into a +typical transaction. In our testing, we have chosen a probability of ten percent +that a given Dandelion transaction enters fluff phase when leaving a given node. +This value strikes a good balance between stem path length and transaction +spreading latency. + +Note that Dandelion's expected precision guarantees are a population-level +metric, whereas the expected recall guarantees can be interpreted as an +individual-level metric. Expected recall is equivalent to the probability that +an adversary associates a single transaction with a given source. These +guarantees are probabilistic. They do not address scenarios in which a node has +been eclipsed by other nodes, or when a node is specifically targeted by an +ISP-like adversary. Individuals who are concerned about targeted deanonymization +should still use Tor. + +At a high level, Dandelion is like an "anonymity inoculation" for the public at +large - including users who are not aware of Bitcoin's privacy issues. Higher +adoption leads to greater benefits, even for users who do not use Tor. Early +adopters of Dandelion still receive privacy benefits. In the worst case when no +neighbors support Dandelion, transactions make at least one hop before +diffusing. Note that any solution based only on routing cannot be perfectly +anonymous due to the fundamental lower bounds on precision and recall shown in +the original Dandelion paper. Dandelion provides near-optimal anonymity +guarantees among such solutions. + +==Specification== + +Dandelion can be specified with a handful of features: Dandelion transaction +support, Dandelion routing data and logic, periodic Dandelion route shuffling, +memory pool logic, the fluff mechanism, transaction embargoes, and Dandelion +transaction logic. Specification details are summarized below. + +===Dandelion transaction support=== + +During the stem phase, transactions are "Dandelion transactions." When a +Dandelion transaction enters fluff phase, it becomes a typical Bitcoin +transaction. Dandelion transactions and typical transactions differ only in +their <code>NetMsgType</code>. + +Dandelion (stem phase) transactions MUST be differentiable from typical Bitcoin +transactions. + +===Dandelion routing data and logic=== + +Dandelion routing during the stem phase requires notions of inbound peers, +outbound peers, Dandelion destinations, and Dandelion routes. Inbound peers +consist of all currently connected peers that initiated the peer connection. +Outbound peers consist of all currently connected peers that were connected to +by this node. Dandelion destinations are a subset of outbound peers. The number +of Dandelion destinations is limited by the +<code>DANDELION_MAX_DESTINATIONS</code> parameter. In the reference +implementation, this parameter is set to two. Our tests have shown that this +value provides both privacy and robustness (see the reference paper for more +details on the parameter tradeoffs). Dandelion routes are a map of inbound peers +to Dandelion destinations. Every inbound peer is mapped to a Dandelion +destination. + +Note that a Dandelion node may choose a different +<code>DANDELION_MAX_DESTINATIONS</code> parameter without splitting from the +privacy graph. When mapping inbound connections to outbound connections for +Dandelion routes, we implement the following routing logic. First, select a set +of Dandelion destinations from the set of outbound peers. This set of Dandelion +destinations is of size less than or equal to +<code>DANDELION_MAX_DESTINATIONS</code>. For each inbound connection, first +identify the subset of Dandelion destinations with the least number of routes. +For example, some subset of Dandelion destinations may be affiliated with zero +routes while all other Dandelion destinations are affiliated with one or more +routes. From this subset, select one Dandelion destination uniformly at random. +Establish a Dandelion route from the inbound connection to this Dandelion +destination. + +For a given Dandelion routing epoch, two distinct Dandelion destinations SHOULD +be selected uniformly at random from the set of outbound connections. All +Dandelion transactions that arrive via a given inbound connection MUST be +transmitted to the same Dandelion destination. When choosing a Dandelion +destination for a given inbound connection, the destination MUST be selected +uniformly at random from the set of Dandelion destinations with the least number +of inbound connections mapped to them. + +===Periodic Dandelion route shuffling=== + +The map of Dandelion routes is cleared and reconstructed every ten minutes on +average. We have chosen the value of ten minutes heuristically in order to make +privacy graph learning difficult for adversaries. Note that a Dandelion node may +choose a different average shuffle time without splitting from the privacy +graph. + +Dandelion routes MUST be cleared and reconstructed at random intervals. +Dandelion routes SHOULD be cleared and reconstructed every ten minutes on +average. + +===Memory pool logic=== + +Dandelion transactions are segregated from typical transactions. The +<code>mempool</code> remains unchanged. Another instance of the +<code>CTxMemPool</code> class, called the <code>stempool</code>, is used for +Dandelion transactions. Information flows from <code>mempool</code> to +<code>stempool</code> in order to ensure proper transaction propagation. +Information does not flow from <code>stempool</code> to <code>mempool</code>, +except when a Dandelion transaction fluffs into a typical transaction. + +When a Dandelion transaction arrives, the transaction MUST be added to the +stempool and MUST NOT be added to the mempool. When a typical Bitcoin +transaction arrives, the transaction MUST be added to the mempool and MUST be +added to the stempool. When a Dandelion transaction fluffs, the transaction MUST +be added to the mempool. + +===The fluff mechanism=== + +When relaying a Dandelion transaction along a Dandelion route, there is a 10% +chance that the Dandelion transaction becomes a typical Bitcoin transaction and +is therefore relayed via diffusion. In our testing, this value strikes a good +balance between stem path length and transaction spreading latency. Note that a +Dandelion node may choose a different chance of fluffing without splitting from +the privacy graph. + +When a node prepares to transmit a Dandelion transaction, the node MUST flip a +biased coin. If the outcome is "Dandelion transaction," then the node MUST +transmit the transaction to the appropriate Dandelion destination. Otherwise, +the node MUST convert the Dandelion transaction into a typical Bitcoin +transaction. A Dandelion transaction SHOULD fluff into a typical Bitcoin +transaction with a 10% probability. + +===Transaction embargoes=== + +During the stem phase, transactions are relayed along a single path. If any node +in this path were to receive the Dandelion transaction and go offline, then the +transaction would cease to propagate. To increase robustness, every node that +forwards a Dandelion transaction initializes a timer at the time of reception. +If the Dandelion transaction does not appear in the memory pool by the time the +timer expires, then the transaction enters fluff phase and is forwarded via +diffusion. + +When a Dandelion transaction arrives, the node MUST set an embargo timer for a +random time in the future. If the Dandelion transaction arrives as a typical +Bitcoin transaction, the node MUST cancel the timer. If the timer expires before +the Dandelion transaction is observed as a typical Bitcoin transaction, then the +node MUST fluff the Dandelion transaction. + +===Dandelion transaction logic=== + +The following cases define a node's behavior when receiving network packets +referencing Dandelion transactions. +* Receive INV for Dandelion TX: If the peer is inbound and the Dandelion transaction has not been received from this peer, then reply with GETDATA. +* Receive GETDATA for Dandelion TX: If the peer is not inbound and the Dandelion transaction has been advertised to this peer, then reply with the Dandelion transaction. +* Receive Dandelion TX: If the peer is inbound, then relay the Dandelion TX to the appropriate Dandelion destination. + +==Implementation== + +A reference implementation is available at the following URL: +https://github.com/dandelion-org/bitcoin/tree/dandelion-feature-commits + +All features have been compressed into a single commit at the following URL: +https://github.com/dandelion-org/bitcoin/tree/dandelion + +==Compatibility== + +Dandelion does not conflict with existing versions of Bitcoin. A Bitcoin node +that supports Dandelion appears no differently to Bitcoin nodes running older +software versions. Bitcoin nodes that support Dandelion can identify feature +support through a probe message. Obviously, older nodes are not capable of +Dandelion routing. If a Bitcoin node supporting Dandelion has no peers that also +support Dandelion, then its behavior naturally decays to that of a Bitcoin node +without Dandelion support due to the Dandelion transaction embargoes. + +==Acknowledgements== + +We would like to thank the Bitcoin Core developers and Gregory Maxwell in +particular for their insightful comments, which helped to inform this +implementation and some of the follow-up work we conducted. We would also like +to thank the Mimblewimble development community for coining the term "stempool," +which we happily adopted for this implementation. + +==References== + +# An Analysis of Anonymity in Bitcoin Using P2P Network Traffic http://fc14.ifca.ai/papers/fc14_submission_71.pdf +# Deanonymisation of clients in Bitcoin P2P network https://arxiv.org/abs/1405.7418 +# Discovering Bitcoin’s Public Topology and Influential Nodes https://cs.umd.edu/projects/coinscope/coinscope.pdf +# (Sigmetrics 2017) Dandelion: Redesigning the Bitcoin Network for Anonymity https://arxiv.org/abs/1701.04439 +# (Sigmetrics 2018) Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees https://arxiv.org/pdf/1805.11060.pdf + +==Copyright== + +To the extent possible under law, the author(s) have dedicated all copyright and +related and neighboring rights to this work to the public domain worldwide. This +work is distributed without any warranty. + +You should have received a copy of the CC0 Public Domain Dedication with this +work. If not, see https://creativecommons.org/publicdomain/zero/1.0/ . diff --git a/bip-0156/1-dandelion.png b/bip-0156/1-dandelion.png Binary files differnew file mode 100644 index 0000000..d17e5ce --- /dev/null +++ b/bip-0156/1-dandelion.png diff --git a/bip-0156/2-attack.png b/bip-0156/2-attack.png Binary files differnew file mode 100644 index 0000000..c6165d1 --- /dev/null +++ b/bip-0156/2-attack.png diff --git a/bip-0156/3-attack-plot.png b/bip-0156/3-attack-plot.png Binary files differnew file mode 100644 index 0000000..8a35a86 --- /dev/null +++ b/bip-0156/3-attack-plot.png diff --git a/bip-0156/4-dandelion-plot.png b/bip-0156/4-dandelion-plot.png Binary files differnew file mode 100644 index 0000000..5fe2150 --- /dev/null +++ b/bip-0156/4-dandelion-plot.png diff --git a/bip-0156/bitcoin.conf b/bip-0156/bitcoin.conf new file mode 100644 index 0000000..e9e6581 --- /dev/null +++ b/bip-0156/bitcoin.conf @@ -0,0 +1,16 @@ +regtest=1 # Run this node on its own independent test network +debug=net # Enable network debug logs +debug=mempool # Enable mempool debug logs +debug=mempoolrej # Enable mempool rejection debug logs +debug=dandelion # Enable dandelion debug logs +logips=1 # Log IP addresses in debug output +logtimemicros=1 # Log timestamps with microsecond precision +printtoconsole=1 # Print debug logs to console instead of debug.log +server=1 # Accept command line JSON-RPC commands +rpcuser=xxx # Username for JSON-RPC connections +rpcpassword=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx +rpcauth=xxx:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx +dns=0 # Do not allow DNS lookups for -addnode, -seednode, and -connect +dnsseed=0 # Do not query for peer addresses via DNS lookup +persistmempool=0 # Do not save mempool on shutdown to load on restart +dandelion=1 # Enable Dandelion transactions diff --git a/bip-0156/dandelion-debug-logs-example.pdf b/bip-0156/dandelion-debug-logs-example.pdf Binary files differnew file mode 100644 index 0000000..4f4180e --- /dev/null +++ b/bip-0156/dandelion-debug-logs-example.pdf diff --git a/bip-0156/dandelion-reference-documentation.pdf b/bip-0156/dandelion-reference-documentation.pdf Binary files differnew file mode 100644 index 0000000..aee33f1 --- /dev/null +++ b/bip-0156/dandelion-reference-documentation.pdf diff --git a/bip-0157.mediawiki b/bip-0157.mediawiki new file mode 100644 index 0000000..4a47706 --- /dev/null +++ b/bip-0157.mediawiki @@ -0,0 +1,471 @@ +<pre> + BIP: 157 + Layer: Peer Services + Title: Client Side Block Filtering + Author: Olaoluwa Osuntokun <laolu32@gmail.com> + Alex Akselrod <alex@akselrod.org> + Jim Posen <jimpo@coinbase.com> + Comments-Summary: None yet + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0157 + Status: Draft + Type: Standards Track + Created: 2017-05-24 + License: CC0-1.0 +</pre> + + +== Abstract == + +This BIP describes a new light client protocol in Bitcoin that improves upon +currently available options. The standard light client protocol in use today, +defined in BIP +37<ref>https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki</ref>, has +known flaws that weaken the security and privacy of clients and allow +denial-of-service attack vectors on full +nodes<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html</ref>. +The new protocol overcomes these issues by allowing light clients to obtain +compact probabilistic filters of block content from full nodes and download full +blocks if the filter matches relevant data. + +New P2P messages empower light clients to securely sync the blockchain without +relying on a trusted source. This BIP also defines a filter header, which serves +as a commitment to all filters for previous blocks and provides the ability to +efficiently detect malicious or faulty peers serving invalid filters. The +resulting protocol guarantees that light clients with at least one honest peer +are able to identify the correct block filters. + +== Motivation == + +Bitcoin light clients allow applications to read relevant transactions from the +blockchain without incurring the full cost of downloading and validating all +data. Such applications seek to simultaneously minimize the trust in peers and +the amount of bandwidth, storage space, and computation required. They achieve +this by downloading all block headers, verifying the proofs of work, and +following the longest proof-of-work chain. Since block headers are a fixed +80-bytes and are generated every 10 minutes on average, the bandwidth required +to sync the block headers is minimal. Light clients then download only the +blockchain data relevant to them directly from peers and validate inclusion in +the header chain. Though clients do not check the validity of all blocks in the +longest proof-of-work chain, they rely on miner incentives for security. + +BIP 37 is currently the most widely used light client execution mode for +Bitcoin. With BIP 37, a client sends a Bloom filter it wants to watch to a full +node peer, then receives notifications for each new transaction or block that +matches the filter. The client then requests relevant transactions from the peer +along with Merkle proofs of inclusion in the blocks containing them, which are +verified against the block headers. The Bloom filters match data such as client +addresses and unspent outputs, and the filter size must be carefully tuned to +balance the false positive rate with the amount of information leaked to peer. It +has been shown, however, that most implementations available offer virtually +''zero privacy'' to wallets and other +applications<ref>https://eprint.iacr.org/2014/763.pdf</ref><ref>https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/</ref>. +Additionally, malicious full nodes serving light clients can omit critical data +with little risk of detection, which is unacceptable for some applications +(such as Lightning Network clients) that must respond to certain on-chain +events. Finally, honest nodes servicing BIP 37 light clients may incur +significant I/O and CPU resource usage due to maliciously crafted Bloom filters, +creating a denial-of-service (DoS) vector and disincentizing node operators from +supporting the +protocol<ref>https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki</ref>. + +The alternative detailed in this document can be seen as the opposite of BIP 37: +instead of the client sending a filter to a full node peer, full nodes generate +deterministic filters on block data that are served to the client. A light +client can then download an entire block if the filter matches the data it is +watching for. Since filters are deterministic, they only need to be constructed +once and stored on disk, whenever a new block is connected to the chain. This +keeps the computation required to serve filters minimal, and eliminates the I/O +asymmetry that makes BIP 37 enabled nodes vulnerable. Clients also get better +assurance of seeing all relevant transactions because they can check the +validity of filters received from peers more easily than they can check +completeness of filtered blocks. Finally, client privacy is improved because +blocks can be downloaded from ''any source'', so that no one peer gets complete +information on the data required by a client. Extremely privacy conscious light +clients may opt to anonymously fetch blocks using advanced techniques such a +Private Information +Retrieval<ref>https://en.wikipedia.org/wiki/Private_information_retrieval</ref>. + +== Definitions == + +<code>[]byte</code> represents a vector of bytes. + +<code>[N]byte</code> represents a fixed-size byte array with length N. + +''CompactSize'' is a compact encoding of unsigned integers used in the Bitcoin +P2P protocol. + +''double-SHA256'' is a hash algorithm defined by two invocations of SHA-256: +<code>double-SHA256(x) = SHA256(SHA256(x))</code>. + +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 == + +=== Filter Types === + +For the sake of future extensibility and reducing filter sizes, there are +multiple ''filter types'' that determine which data is included in a block +filter as well as the method of filter construction/querying. In this model, +full nodes generate one filter per block per filter type supported. + +Each type is identified by a one byte code, and specifies the contents and +serialization format of the filter. A full node MAY signal support for +particular filter types using service bits. The initial filter types are defined +separately in [[bip-0158.mediawiki|BIP 158]], and one service bit is allocated +to signal support for them. + +=== Filter Headers === + +This proposal draws inspiration from the headers-first mechanism that Bitcoin +nodes use to sync the block +chain<ref>https://bitcoin.org/en/developer-guide#headers-first</ref>. Similar to +how block headers have a Merkle commitment to all transaction data in the block, +we define filter headers that have commitments to the block filters. Also like +block headers, filter headers each have a commitment to the preceding one. +Before downloading the block filters themselves, a light client can download all +filter headers for the current block chain and use them to verify the +authenticity of the filters. If the filter header chains differ between multiple +peers, the client can identify the point where they diverge, then download the +full block and compute the correct filter, thus identifying which peer is +faulty. + +The canonical hash of a block filter is the double-SHA256 of the serialized +filter. Filter headers are 32-byte hashes derived for each block filter. They +are computed as the double-SHA256 of the concatenation of the filter hash with +the previous filter header. The previous filter header used to calculate that of +the genesis block is defined to be the 32-byte array of 0's. + +=== New Messages === + +==== getcfilters ==== +<code>getcfilters</code> is used to request the compact filters of a particular +type for a particular range of blocks. The message contains the following +fields: + +{| class="wikitable" +! Field Name +! Data Type +! Byte Size +! Description +|- +| FilterType +| byte +| 1 +| Filter type for which headers are requested +|- +| StartHeight +| uint32 +| 4 +| The height of the first block in the requested range +|- +| StopHash +| [32]byte +| 32 +| The hash of the last block in the requested range +|} + +# Nodes SHOULD NOT send <code>getcfilters</code> unless the peer has signaled support for this filter type. Nodes receiving <code>getcfilters</code> with an unsupported filter type SHOULD NOT respond. +# StopHash MUST be known to belong to a block accepted by the receiving peer. This is the case if the peer had previously sent a <code>headers</code> or <code>inv</code> message with that block or any descendents. A node that receives <code>getcfilters</code> with an unknown StopHash SHOULD NOT respond. +# The height of the block with hash StopHash MUST be greater than or equal to StartHeight, and the difference MUST be strictly less than 100. +# The receiving node MUST respond to valid requests by sending one <code>cfilter</code> message for each block in the requested range, sequentially in order by block height. + +==== cfilter ==== +<code>cfilter</code> is sent in response to <code>getcfilters</code>, one for +each block in the requested range. The message contains the following fields: + +{| class="wikitable" +! Field Name +! Data Type +! Byte Size +! Description +|- +| FilterType +| byte +| 1 +| Byte identifying the type of filter being returned +|- +| BlockHash +| [32]byte +| 32 +| Block hash of the Bitcoin block for which the filter is being returned +|- +| NumFilterBytes +| CompactSize +| 1-5 +| A variable length integer representing the size of the filter in the following field +|- +| FilterBytes +| []byte +| NumFilterBytes +| The serialized compact filter for this block +|} + +# The FilterType SHOULD match the field in the <code>getcfilters</code> request, and BlockHash must correspond to a block that is an ancestor of StopHash with height greater than or equal to StartHeight. + +==== getcfheaders ==== +<code>getcfheaders</code> is used to request verifiable filter headers for a +range of blocks. The message contains the following fields: + +{| class="wikitable" +! Field Name +! Data Type +! Byte Size +! Description +|- +| FilterType +| byte +| 1 +| Filter type for which headers are requested +|- +| StartHeight +| uint32 +| 4 +| The height of the first block in the requested range +|- +| StopHash +| [32]byte +| 32 +| The hash of the last block in the requested range +|} + +# Nodes SHOULD NOT send <code>getcfheaders</code> unless the peer has signaled support for this filter type. Nodes receiving <code>getcfheaders</code> with an unsupported filter type SHOULD NOT respond. +# StopHash MUST be known to belong to a block accepted by the receiving peer. This is the case if the peer had previously sent a <code>headers</code> or <code>inv</code> message with that block or any descendents. A node that receives <code>getcfheaders</code> with an unknown StopHash SHOULD NOT respond. +# The height of the block with hash StopHash MUST be greater than or equal to StartHeight, and the difference MUST be strictly less than 2,000. + +==== cfheaders ==== +<code>cfheaders</code> is sent in response to <code>getcfheaders</code>. Instead +of including the filter headers themselves, the response includes one filter +header and a sequence of filter hashes, from which the headers can be derived. +This has the benefit that the client can verify the binding links between the +headers. The message contains the following fields: + +{| class="wikitable" +! Field Name +! Data Type +! Byte Size +! Description +|- +| FilterType +| byte +| 1 +| Filter type for which hashes are requested +|- +| StopHash +| [32]byte +| 32 +| The hash of the last block in the requested range +|- +| PreviousFilterHeader +| [32]byte +| 32 +| The filter header preceding the first block in the requested range +|- +| FilterHashesLength +| CompactSize +| 1-3 +| The length of the following vector of filter hashes +|- +| FilterHashes +| [][32]byte +| FilterHashesLength * 32 +| The filter hashes for each block in the requested range +|} + +# The FilterType and StopHash SHOULD match the fields in the <code>getcfheaders</code> request. +# FilterHashesLength MUST NOT be greater than 2,000. +# FilterHashes MUST have one entry for each block on the chain terminating with tip StopHash, starting with the block at height StartHeight. The entries MUST be the filter hashes of the given type for each block in that range, in ascending order by height. +# PreviousFilterHeader MUST be set to the previous filter header of first block in the requested range. + +==== getcfcheckpt ==== +<code>getcfcheckpt</code> is used to request filter headers at evenly spaced +intervals over a range of blocks. Clients may use filter hashes from +<code>getcfheaders</code> to connect these checkpoints, as is described in the +[[#client-operation|Client Operation]] section below. The +<code>getcfcheckpt</code> message contains the following fields: + +{| class="wikitable" +! Field Name +! Data Type +! Byte Size +! Description +|- +| FilterType +| byte +| 1 +| Filter type for which headers are requested +|- +| StopHash +| [32]byte +| 32 +| The hash of the last block in the chain that headers are requested for +|} + +# Nodes SHOULD NOT send <code>getcfcheckpt</code> unless the peer has signaled support for this filter type. Nodes receiving <code>getcfcheckpt</code> with an unsupported filter type SHOULD NOT respond. +# StopHash MUST be known to belong to a block accepted by the receiving peer. This is the case if the peer had previously sent a <code>headers</code> or <code>inv</code> message with any descendent blocks. A node that receives <code>getcfcheckpt</code> with an unknown StopHash SHOULD NOT respond. + +==== cfcheckpt ==== +<code>cfcheckpt</code> is sent in response to <code>getcfcheckpt</code>. The +filter headers included are the set of all filter headers on the requested chain +where the height is a positive multiple of 1,000. The message contains the +following fields: + +{| class="wikitable" +! Field Name +! Data Type +! Byte Size +! Description +|- +| FilterType +| byte +| 1 +| Filter type for which headers are requested +|- +| StopHash +| [32]byte +| 32 +| The hash of the last block in the chain that headers are requested for +|- +| FilterHeadersLength +| CompactSize +| 1-3 +| The length of the following vector of filter headers +|- +| FilterHeaders +| [][32]byte +| FilterHeadersLength * 32 +| The filter headers at intervals of 1,000 +|} + +# The FilterType and StopHash SHOULD match the fields in the <code>getcfcheckpt</code> request. +# FilterHeaders MUST have exactly one entry for each block on the chain terminating in StopHash, where the block height is a multiple of 1,000 greater than 0. The entries MUST be the filter headers of the given type for each such block, in ascending order by height. + +=== Node Operation === + +Full nodes MAY opt to support this BIP and generate filters for any of the +specified filter types. Such nodes SHOULD treat the filters as an additional +index of the blockchain. For each new block that is connected to the main chain, +nodes SHOULD generate filters for all supported types and persist them. Nodes +that are missing filters and are already synced with the blockchain SHOULD +reindex the chain upon start-up, constructing filters for each block from +genesis to the current tip. They also SHOULD keep every checkpoint header in +memory, so that <code>getcfcheckpt</code> requests do not result in many +random-access disk reads. + +Nodes SHOULD NOT generate filters dynamically on request, as malicious peers may +be able to perform DoS attacks by requesting small filters derived from large +blocks. This would require an asymmetical amount of I/O on the node to compute +and serve, similar to attacks against BIP 37 enabled nodes noted in BIP 111. + +Nodes MAY prune block data after generating and storing all filters for a block. + +=== Client Operation === + +This section provides recommendations for light clients to download filters with +maximal security. + +Clients SHOULD first sync the entire block header chain from peers using the +standard headers-first syncing mechanism before downloading any block filters or +filter headers. Clients configured with trusted checkpoints MAY only sync +headers started from the last checkpoint. Clients SHOULD disconnect any outbound +peers whose best chain has significantly less work than the known longest +proof-of-work chain. + +Once a client's block headers are in sync, it SHOULD download and verify filter +headers for all blocks and filter types that it might later download. The client +SHOULD send <code>getcfheaders</code> messages to peers and derive and store the +filter headers for each block. The client MAY first fetch headers at evenly +spaced intervals of 1,000 by sending <code>getcfcheckpt</code>. The header +checkpoints allow the client to download filter headers for different intervals +from multiple peers in parallel, verifying each range of 1,000 headers against +the checkpoints. + +Unless securely connected to a trusted peer that is serving filter headers, the +client SHOULD connect to multiple outbound peers that support each filter type +to mitigate the risk of downloading incorrect headers. If the client receives +conflicting filter headers from different peers for any block and filter type, +it SHOULD interrogate them to determine which is faulty. The client SHOULD use +<code>getcfheaders</code> and/or <code>getcfcheckpt</code> to first identify +the first filter headers that the peers disagree on. The client then SHOULD +download the full block from any peer and derive the correct filter and filter +header. The client SHOULD ban any peers that sent a filter header that does not +match the computed one. + +Once the client has downloaded and verified all filter headers needed, ''and'' +no outbound peers have sent conflicting headers, the client can download the +actual block filters it needs. The client MAY backfill filter headers before the +first verified one at this point if it only downloaded them starting at a later +point. Clients SHOULD persist the verified filter headers for last 100 blocks in +the chain (or whatever finality depth is desired), to compare against headers +received from new peers after restart. They MAY store more filter headers to +avoid redownloading them if a rescan is later necessary. + +Starting from the first block in the desired range, the client now MAY download +the filters. The client SHOULD test that each filter links to its corresponding +filter header and ban peers that send incorrect filters. The client MAY download +multiple filters at once to increase throughput, though it SHOULD test the +filters sequentially. The client MAY check if a filter is empty before +requesting it by checking if the filter header commits to the hash of the empty +filter, saving a round trip if that is the case. + +Each time a new valid block header is received, the client SHOULD request the +corresponding filter headers from all eligible peers. If two peers send +conflicting filter headers, the client should interrogate them as described +above and ban any peers that send an invalid header. + +If a client is fetching full blocks from the P2P network, they SHOULD be downloaded +from outbound peers at random to mitigate privacy loss due to transaction +intersection analysis. Note that blocks may be downloaded from peers that do not +support this BIP. + +== Rationale == + +The filter headers and checkpoints messages are defined to help clients identify +the correct filter for a block when connected to peers sending conflicting +information. An alternative solution is to require Bitcoin blocks to include +commitments to derived block filters, so light clients can verify authenticity +given block headers and some additional witness data. This would require a +network-wide change to the Bitcoin consensus rules, however, whereas this +document proposes a solution purely at the P2P layer. + +The constant interval of 1,000 blocks between checkpoints was chosen so that, +given the current chain height and rate of growth, the size of a +<code>cfcheckpt</code> message is not drastically from a +<code>cfheaders</code> between two checkpoints. Also, 1,000 is a nice round +number, at least to those of us who think in decimal. + +== Compatibility == + +This light client mode is not compatible with current node deployments and +requires support for the new P2P messages. The node implementation of this +proposal is not incompatible with the current P2P network rules (ie. doesn't +affect network topology of full nodes). Light clients may adopt protocols based +on this as an alternative to the existing BIP 37. Adoption of this BIP may +result in reduced network support for BIP 37. + +== Acknowledgments == + +We would like to thank bfd (from the bitcoin-dev mailing list) for bringing the +basis of this BIP to our attention, Joseph Poon for suggesting the filter header +chain scheme, and Pedro Martelletto for writing the initial indexing code for +<code>btcd</code>. + +We would also like to thank Dave Collins, JJ Jeffrey, Eric Lombrozo, and Matt +Corallo for useful discussions. + +== Reference Implementation == + +Light client: [https://github.com/lightninglabs/neutrino] + +Full-node indexing: https://github.com/Roasbeef/btcd/tree/segwit-cbf + +Golomb-Rice Coded sets: https://github.com/Roasbeef/btcutil/tree/gcs/gcs + +== References == + +<references/> + +== Copyright == + +This document is licensed under the Creative Commons CC0 1.0 Universal license. diff --git a/bip-0158.mediawiki b/bip-0158.mediawiki new file mode 100644 index 0000000..ad46da6 --- /dev/null +++ b/bip-0158.mediawiki @@ -0,0 +1,443 @@ +<pre> + BIP: 158 + Layer: Peer Services + Title: Compact Block Filters for Light Clients + Author: Olaoluwa Osuntokun <laolu32@gmail.com> + Alex Akselrod <alex@akselrod.org> + Comments-Summary: None yet + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0158 + Status: Draft + Type: Standards Track + Created: 2017-05-24 + License: CC0-1.0 +</pre> + + +== Abstract == + +This BIP describes a structure for compact filters on block data, for use in the +BIP 157 light client protocol<ref>bip-0157.mediawiki</ref>. The filter +construction proposed is an alternative to Bloom filters, as used in BIP 37, +that minimizes filter size by using Golomb-Rice coding for compression. This +document specifies two initial types of filters based on this construction that +enables basic wallets and applications with more advanced smart contracts. + +== Motivation == + +[[bip-0157.mediawiki|BIP 157]] defines a light client protocol based on +deterministic filters of block content. The filters are designed to +minimize the expected bandwidth consumed by light clients, downloading filters +and full blocks. This document defines the initial filter type ''basic'' +that is designed to reduce the filter size for regular wallets. + +== Definitions == + +<code>[]byte</code> represents a vector of bytes. + +<code>[N]byte</code> represents a fixed-size byte array with length N. + +''CompactSize'' is a compact encoding of unsigned integers used in the Bitcoin +P2P protocol. + +''Data pushes'' are byte vectors pushed to the stack according to the rules of +Bitcoin script. + +''Bit streams'' are readable and writable streams of individual bits. The +following functions are used in the pseudocode in this document: +* <code>new_bit_stream</code> instantiates a new writable bit stream +* <code>new_bit_stream(vector)</code> instantiates a new bit stream reading data from <code>vector</code> +* <code>write_bit(stream, b)</code> appends the bit <code>b</code> to the end of the stream +* <code>read_bit(stream)</code> reads the next available bit from the stream +* <code>write_bits_big_endian(stream, n, k)</code> appends the <code>k</code> least significant bits of integer <code>n</code> to the end of the stream in big-endian bit order +* <code>read_bits_big_endian(stream, k)</code> reads the next available <code>k</code> bits from the stream and interprets them as the least significant bits of a big-endian integer + +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 == + +=== Golomb-Coded Sets === + +For each block, compact filters are derived containing sets of items associated +with the block (eg. addresses sent to, outpoints spent, etc.). A set of such +data objects is compressed into a probabilistic structure called a +''Golomb-coded set'' (GCS), which matches all items in the set with probability +1, and matches other items with probability <code>1/M</code> for some +integer parameter <code>M</code>. The encoding is also parameterized by +<code>P</code>, the bit length of the remainder code. Each filter defined +specifies values for <code>P</code> and <code>M</code>. + +At a high level, a GCS is constructed from a set of <code>N</code> items by: +# hashing all items to 64-bit integers in the range <code>[0, N * M)</code> +# sorting the hashed values in ascending order +# computing the differences between each value and the previous one +# writing the differences sequentially, compressed with Golomb-Rice coding + +The following sections describe each step in greater detail. + +==== Hashing Data Objects ==== + +The first step in the filter construction is hashing the variable-sized raw +items in the set to the range <code>[0, F)</code>, where <code>F = N * +M</code>. Customarily, <code>M</code> is set to <code>2^P</code>. However, if +one is able to select both Parameters independently, then more optimal values +can be +selected<ref>https://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845</ref>. +Set membership queries against the hash outputs will have a false positive rate +of <code>M</code>. To avoid integer overflow, the number of items <code>N</code> +MUST be <2^32 and <code>M</code> MUST be <2^32. + +The items are first passed through the pseudorandom function ''SipHash'', which +takes a 128-bit key <code>k</code> and a variable-sized byte vector and produces +a uniformly random 64-bit output. Implementations of this BIP MUST use the +SipHash parameters <code>c = 2</code> and <code>d = 4</code>. + +The 64-bit SipHash outputs are then mapped uniformly over the desired range by +multiplying with F and taking the top 64 bits of the 128-bit result. This +algorithm is a faster alternative to modulo reduction, as it avoids the +expensive division +operation<ref>https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-reduction/</ref>. +Note that care must be taken when implementing this reduction to ensure the +upper 64 bits of the integer multiplication are not truncated; certain +architectures and high level languages may require code that decomposes the +64-bit multiplication into four 32-bit multiplications and recombines into the +result. + +<pre> +hash_to_range(item: []byte, F: uint64, k: [16]byte) -> uint64: + return (siphash(k, item) * F) >> 64 + +hashed_set_construct(raw_items: [][]byte, k: [16]byte, M: uint) -> []uint64: + let N = len(raw_items) + let F = N * M + + let set_items = [] + + for item in raw_items: + let set_value = hash_to_range(item, F, k) + set_items.append(set_value) + + return set_items +</pre> + +==== Golomb-Rice Coding ==== + +Instead of writing the items in the hashed set directly to the filter, greater +compression is achieved by only writing the differences between successive +items in sorted order. Since the items are distributed uniformly, it can be +shown that the differences resemble a geometric +distribution<ref>https://en.wikipedia.org/wiki/Geometric_distribution</ref>. +''Golomb-Rice'' +''coding''<ref>https://en.wikipedia.org/wiki/Golomb_coding#Rice_coding</ref> +is a technique that optimally compresses geometrically distributed values. + +With Golomb-Rice, a value is split into a quotient and remainder modulo +<code>2^P</code>, which are encoded separately. The quotient <code>q</code> is +encoded as ''unary'', with a string of <code>q</code> 1's followed by one 0. The +remainder <code>r</code> is represented in big-endian by P bits. For example, +this is a table of Golomb-Rice coded values using <code>P=2</code>: + +{| class="wikitable" +! n !! (q, r) !! c +|- +| 0 || (0, 0) || <code>0 00</code> +|- +| 1 || (0, 1) || <code>0 01</code> +|- +| 2 || (0, 2) || <code>0 10</code> +|- +| 3 || (0, 3) || <code>0 11</code> +|- +| 4 || (1, 0) || <code>10 00</code> +|- +| 5 || (1, 1) || <code>10 01</code> +|- +| 6 || (1, 2) || <code>10 10</code> +|- +| 7 || (1, 3) || <code>10 11</code> +|- +| 8 || (2, 0) || <code>110 00</code> +|- +| 9 || (2, 1) || <code>110 01</code> +|} + +<pre> +golomb_encode(stream, x: uint64, P: uint): + let q = x >> P + + while q > 0: + write_bit(stream, 1) + q-- + write_bit(stream, 0) + + write_bits_big_endian(stream, x, P) + +golomb_decode(stream, P: uint) -> uint64: + let q = 0 + while read_bit(stream) == 1: + q++ + + let r = read_bits_big_endian(stream, P) + + let x = (q << P) + r + return x +</pre> + +==== Set Construction ==== + +A GCS is constructed from four parameters: +* <code>L</code>, a vector of <code>N</code> raw items +* <code>P</code>, the bit parameter of the Golomb-Rice coding +* <code>M</code>, the target false positive rate +* <code>k</code>, the 128-bit key used to randomize the SipHash outputs + +The result is a byte vector with a minimum size of <code>N * (P + 1)</code> +bits. + +The raw items in <code>L</code> are first hashed to 64-bit unsigned integers as +specified above and sorted. The differences between consecutive values, +hereafter referred to as ''deltas'', are encoded sequentially to a bit stream +with Golomb-Rice coding. Finally, the bit stream is padded with 0's to the +nearest byte boundary and serialized to the output byte vector. + +<pre> +construct_gcs(L: [][]byte, P: uint, k: [16]byte, M: uint) -> []byte: + let set_items = hashed_set_construct(L, k, M) + + set_items.sort() + + let output_stream = new_bit_stream() + + let last_value = 0 + for item in set_items: + let delta = item - last_value + golomb_encode(output_stream, delta, P) + last_value = item + + return output_stream.bytes() +</pre> + +==== Set Querying/Decompression ==== + +To check membership of an item in a compressed GCS, one must reconstruct the +hashed set members from the encoded deltas. The procedure to do so is the +reverse of the compression: deltas are decoded one by one and added to a +cumulative sum. Each intermediate sum represents a hashed value in the original +set. The queried item is hashed in the same way as the set members and compared +against the reconstructed values. Note that querying does not require the entire +decompressed set be held in memory at once. + +<pre> +gcs_match(key: [16]byte, compressed_set: []byte, target: []byte, P: uint, N: uint, M: uint) -> bool: + let F = N * M + let target_hash = hash_to_range(target, F, k) + + stream = new_bit_stream(compressed_set) + + let last_value = 0 + + loop N times: + let delta = golomb_decode(stream, P) + let set_item = last_value + delta + + if set_item == target_hash: + return true + + // Since the values in the set are sorted, terminate the search once + // the decoded value exceeds the target. + if set_item > target_hash: + break + + last_value = set_item + + return false +</pre> + +Some applications may need to check for set intersection instead of membership +of a single item. This can be performed far more efficiently than checking each +item individually by leveraging the sorted structure of the compressed GCS. +First the query elements are all hashed and sorted, then compared in order +against the decompressed GCS contents. See +[[#golomb-coded-set-multi-match|Appendix B]] for pseudocode. + +=== Block Filters === + +This BIP defines one initial filter type: +* Basic (<code>0x00</code>) +** <code>M = 784931</code> +** <code>P = 19</code> + +==== Contents ==== + +The basic filter is designed to contain everything that a light client needs to +sync a regular Bitcoin wallet. A basic filter MUST contain exactly the +following items for each transaction in a block: +* The previous output script (the script being spent) for each input, except + for the coinbase transaction. +* The scriptPubKey of each output, aside from all <code>OP_RETURN</code> output + scripts. + +Any "nil" items MUST NOT be included into the final set of filter elements. + +We exclude all outputs that start with <code>OP_RETURN</code> in order to allow +filters to easily be committed to in the future via a soft-fork. A likely area +for future commitments is an additional <code>OP_RETURN</code> output in the +coinbase transaction similar to the current witness commitment +<ref>https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki</rev>. By +excluding all <code>OP_RETURN</code> outputs we avoid a circular dependency +between the commitment, and the item being committed to. + +==== Construction ==== + +The basic type is constructed as Golomb-coded sets with the following +parameters. + +The parameter <code>P</code> MUST be set to <code>19</code>, and the parameter +<code>M</code> MUST be set to <code>784931</code>. Analysis has shown that if +one is able to select <code>P</code> and <code>M</code> independently, then +setting <code>M=1.497137 * 2^P</code> is close to optimal +<ref>https://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845</ref>. + +Empirical analysis also shows that was chosen as these parameters minimize the +bandwidth utilized, considering both the expected number of blocks downloaded +due to false positives and the size of the filters themselves. + +The parameter <code>k</code> MUST be set to the first 16 bytes of the hash +(in standard little-endian representation) of the block for which the filter is +constructed. This ensures the key is deterministic while still varying from +block to block. + +Since the value <code>N</code> is required to decode a GCS, a serialized GCS +includes it as a prefix, written as a <code>CompactSize</code>. Thus, the +complete serialization of a filter is: +* <code>N</code>, encoded as a <code>CompactSize</code> +* The bytes of the compressed filter itself + +==== Signaling ==== + +This BIP allocates a new service bit: + +{| class="wikitable" +|- +| NODE_COMPACT_FILTERS +| style="white-space: nowrap;" | <code>1 << 6</code> +| If enabled, the node MUST respond to all BIP 157 messages for filter types <code>0x00</code> and <code>0x01</code> +|} + +== Compatibility == + +This block filter construction is not incompatible with existing software, +though it requires implementation of the new filters. + +== Acknowledgments == + +We would like to thank bfd (from the bitcoin-dev mailing list) for bringing the +basis of this BIP to our attention, Greg Maxwell for pointing us in the +direction of Golomb-Rice coding and fast range optimization, Pieter Wullie for +his analysis of optimal GCS parameters, and Pedro +Martelletto for writing the initial indexing code for <code>btcd</code>. + +We would also like to thank Dave Collins, JJ Jeffrey, and Eric Lombrozo for +useful discussions. + +== Reference Implementation == + +Light client: [https://github.com/lightninglabs/neutrino] + +Full-node indexing: https://github.com/Roasbeef/btcd/tree/segwit-cbf + +Golomb-Rice Coded sets: https://github.com/btcsuite/btcutil/blob/master/gcs + +== Appendix A: Alternatives == + +A number of alternative set encodings were considered before Golomb-coded +sets were settled upon. In this appendix section, we'll list a few of the +alternatives along with our rationale for not pursuing them. + +==== Bloom Filters ==== + +Bloom Filters are perhaps the best known probabilistic data structure for +testing set membership, and were introduced into the Bitcoin protocol with BIP +37. The size of a Bloom filter is larger than the expected size of a GCS with +the same false positive rate, which is the main reason the option was rejected. + +==== Cryptographic Accumulators ==== + +Cryptographic +accumulators<ref>https://en.wikipedia.org/wiki/Accumulator_(cryptography)</ref> +are a cryptographic data structures that enable (amongst other operations) a one +way membership test. One advantage of accumulators are that they are constant +size, independent of the number of elements inserted into the accumulator. +However, current constructions of cryptographic accumulators require an initial +trusted set up. Additionally, accumulators based on the Strong-RSA Assumption +require mapping set items to prime representatives in the associated group which +can be preemptively expensive. + +==== Matrix Based Probabilistic Set Data Structures ==== + +There exist data structures based on matrix solving which are even more space +efficient compared to Bloom +filters<ref>https://arxiv.org/pdf/0804.1845.pdf</ref>. We instead opted for our +GCS-based filters as they have a much lower implementation complexity and are +easier to understand. + +== Appendix B: Pseudocode == + +=== Golomb-Coded Set Multi-Match === + +<pre> +gcs_match_any(key: [16]byte, compressed_set: []byte, targets: [][]byte, P: uint, N: uint, M: uint) -> bool: + let F = N * M + + // Map targets to the same range as the set hashes. + let target_hashes = [] + for target in targets: + let target_hash = hash_to_range(target, F, k) + target_hashes.append(target_hash) + + // Sort targets so matching can be checked in linear time. + target_hashes.sort() + + stream = new_bit_stream(compressed_set) + + let value = 0 + let target_idx = 0 + let target_val = target_hashes[target_idx] + + loop N times: + let delta = golomb_decode(stream, P) + value += delta + + inner loop: + if target_val == value: + return true + + // Move on to the next set value. + else if target_val > value: + break inner loop + + // Move on to the next target value. + else if target_val < value: + target_idx++ + + // If there are no targets left, then there are no matches. + if target_idx == len(targets): + break outer loop + + target_val = target_hashes[target_idx] + + return false +</pre> + +== Appendix C: Test Vectors == + +Test vectors for basic block filters on five testnet blocks, including the filters and filter headers, can be found [[bip-0158/testnet-19.json|here]]. The code to generate them can be found [[bip-0158/gentestvectors.go|here]]. + +== References == + +<references/> + +== Copyright == + +This document is licensed under the Creative Commons CC0 1.0 Universal license. diff --git a/bip-0158/gentestvectors.go b/bip-0158/gentestvectors.go new file mode 100644 index 0000000..3435eb3 --- /dev/null +++ b/bip-0158/gentestvectors.go @@ -0,0 +1,301 @@ +// This program connects to your local btcd and generates test vectors for +// 5 blocks and collision space sizes of 1-32 bits. Change the RPC cert path +// and credentials to run on your system. The program assumes you're running +// a btcd with cfilter support, which mainline btcd doesn't have; in order to +// circumvent this assumption, comment out the if block that checks for +// filter size of DefaultP. + +package main + +import ( + "bytes" + "encoding/hex" + "encoding/json" + "fmt" + "io" + "io/ioutil" + "os" + "path/filepath" + + "github.com/btcsuite/btcd/blockchain" + "github.com/btcsuite/btcd/chaincfg/chainhash" + "github.com/btcsuite/btcd/rpcclient" + "github.com/btcsuite/btcd/wire" + "github.com/btcsuite/btcutil" + "github.com/btcsuite/btcutil/gcs/builder" + "github.com/davecgh/go-spew/spew" +) + +var ( + // testBlockHeights are the heights of the blocks to include in the test + // vectors. Any new entries must be added in sorted order. + testBlockHeights = []testBlockCase{ + {0, "Genesis block"}, + {2, ""}, + {3, ""}, + {15007, "Tx has non-standard OP_RETURN output followed by opcodes"}, + {49291, "Tx pays to empty output script"}, + {180480, "Tx spends from empty output script"}, + {926485, "Duplicate pushdata 913bcc2be49cb534c20474c4dee1e9c4c317e7eb"}, + {987876, "Coinbase tx has unparseable output script"}, + {1263442, "Includes witness data"}, + {1414221, "Empty data"}, + } + + defaultBtcdDir = btcutil.AppDataDir("btcd", false) + defaultBtcdRPCCertFile = filepath.Join(defaultBtcdDir, "rpc.cert") +) + +const ( + fp = 19 +) + +type testBlockCase struct { + height uint32 + comment string +} + +type JSONTestWriter struct { + writer io.Writer + firstRowWritten bool +} + +func NewJSONTestWriter(writer io.Writer) *JSONTestWriter { + return &JSONTestWriter{writer: writer} +} + +func (w *JSONTestWriter) WriteComment(comment string) error { + return w.WriteTestCase([]interface{}{comment}) +} + +func (w *JSONTestWriter) WriteTestCase(row []interface{}) error { + var err error + if w.firstRowWritten { + _, err = io.WriteString(w.writer, ",\n") + } else { + _, err = io.WriteString(w.writer, "[\n") + w.firstRowWritten = true + } + if err != nil { + return err + } + + rowBytes, err := json.Marshal(row) + if err != nil { + return err + } + + _, err = w.writer.Write(rowBytes) + return err +} + +func (w *JSONTestWriter) Close() error { + if !w.firstRowWritten { + return nil + } + + _, err := io.WriteString(w.writer, "\n]\n") + return err +} + +func fetchPrevOutputScripts(client *rpcclient.Client, block *wire.MsgBlock) ([][]byte, error) { + var prevScripts [][]byte + + txCache := make(map[chainhash.Hash]*wire.MsgTx) + for _, tx := range block.Transactions { + if blockchain.IsCoinBaseTx(tx) { + continue + } + + for _, txIn := range tx.TxIn { + prevOp := txIn.PreviousOutPoint + + tx, ok := txCache[prevOp.Hash] + if !ok { + originTx, err := client.GetRawTransaction( + &prevOp.Hash, + ) + if err != nil { + return nil, fmt.Errorf("unable to get "+ + "txid=%v: %v", prevOp.Hash, err) + } + + txCache[prevOp.Hash] = originTx.MsgTx() + + tx = originTx.MsgTx() + } + + index := prevOp.Index + + prevScripts = append( + prevScripts, tx.TxOut[index].PkScript, + ) + } + } + + return prevScripts, nil +} + +func main() { + var ( + writerFile *JSONTestWriter + prevBasicHeader chainhash.Hash + ) + fName := fmt.Sprintf("testnet-%02d.json", fp) + file, err := os.Create(fName) + if err != nil { + fmt.Println("Error creating output file: ", err.Error()) + return + } + defer file.Close() + + writer := &JSONTestWriter{ + writer: file, + } + defer writer.Close() + + err = writer.WriteComment("Block Height,Block Hash,Block," + + "[Prev Output Scripts for Block],Previous Basic Header," + + "Basic Filter,Basic Header,Notes") + if err != nil { + fmt.Println("Error writing to output file: ", err.Error()) + return + } + + writerFile = writer + + cert, err := ioutil.ReadFile(defaultBtcdRPCCertFile) + if err != nil { + fmt.Println("Couldn't read RPC cert: ", err.Error()) + return + } + + conf := rpcclient.ConnConfig{ + Host: "127.0.0.1:18334", + Endpoint: "ws", + User: "kek", + Pass: "kek", + Certificates: cert, + } + client, err := rpcclient.New(&conf, nil) + if err != nil { + fmt.Println("Couldn't create a new client: ", err.Error()) + return + } + + var testBlockIndex int + for height := 0; testBlockIndex < len(testBlockHeights); height++ { + blockHash, err := client.GetBlockHash(int64(height)) + if err != nil { + fmt.Println("Couldn't get block hash: ", err.Error()) + return + } + + block, err := client.GetBlock(blockHash) + if err != nil { + fmt.Println("Couldn't get block hash: ", err.Error()) + return + } + + var blockBuf bytes.Buffer + err = block.Serialize(&blockBuf) + if err != nil { + fmt.Println("Error serializing block to buffer: ", err.Error()) + return + } + blockBytes := blockBuf.Bytes() + + prevOutputScripts, err := fetchPrevOutputScripts(client, block) + if err != nil { + fmt.Println("Couldn't fetch prev output scipts: ", err) + return + } + + basicFilter, err := builder.BuildBasicFilter(block, prevOutputScripts) + if err != nil { + fmt.Println("Error generating basic filter: ", err.Error()) + return + } + basicHeader, err := builder.MakeHeaderForFilter(basicFilter, prevBasicHeader) + if err != nil { + fmt.Println("Error generating header for filter: ", err.Error()) + return + } + + // We'll now ensure that we've constructed the same filter as + // the chain server we're fetching blocks form. + filter, err := client.GetCFilter( + blockHash, wire.GCSFilterRegular, + ) + if err != nil { + fmt.Println("Error getting basic filter: ", + err.Error()) + return + } + + nBytes, err := basicFilter.NBytes() + if err != nil { + fmt.Println("Couldn't get NBytes(): ", err) + return + } + if !bytes.Equal(filter.Data, nBytes) { + // Don't error on empty filters + fmt.Printf("basic filter doesn't match: generated "+ + "%x, rpc returns %x, block %v", nBytes, + filter.Data, spew.Sdump(block)) + return + } + + header, err := client.GetCFilterHeader( + blockHash, wire.GCSFilterRegular, + ) + if err != nil { + fmt.Println("Error getting basic header: ", err.Error()) + return + } + if !bytes.Equal(header.PrevFilterHeader[:], basicHeader[:]) { + fmt.Println("Basic header doesn't match!") + return + } + + if height%1000 == 0 { + fmt.Printf("Verified height %v against server\n", height) + } + + if uint32(height) == testBlockHeights[testBlockIndex].height { + var bfBytes []byte + bfBytes, err = basicFilter.NBytes() + if err != nil { + fmt.Println("Couldn't get NBytes(): ", err) + return + } + + prevScriptStrings := make([]string, len(prevOutputScripts)) + for i, prevScript := range prevOutputScripts { + prevScriptStrings[i] = hex.EncodeToString(prevScript) + } + + row := []interface{}{ + height, + blockHash.String(), + hex.EncodeToString(blockBytes), + prevScriptStrings, + prevBasicHeader.String(), + hex.EncodeToString(bfBytes), + basicHeader.String(), + testBlockHeights[testBlockIndex].comment, + } + err = writerFile.WriteTestCase(row) + if err != nil { + fmt.Println("Error writing test case to output: ", err.Error()) + return + } + } + + prevBasicHeader = basicHeader + + if uint32(height) == testBlockHeights[testBlockIndex].height { + testBlockIndex++ + } + } +} diff --git a/bip-0158/go.mod b/bip-0158/go.mod new file mode 100644 index 0000000..0e9bd6e --- /dev/null +++ b/bip-0158/go.mod @@ -0,0 +1,7 @@ +module github.com/bitcoin/bips/bip-0158 + +require ( + github.com/btcsuite/btcd v0.0.0-20190115013929-ed77733ec07d + github.com/btcsuite/btcutil v0.0.0-20190207003914-4c204d697803 + github.com/davecgh/go-spew v1.1.1 +) diff --git a/bip-0158/go.sum b/bip-0158/go.sum new file mode 100644 index 0000000..013eb4b --- /dev/null +++ b/bip-0158/go.sum @@ -0,0 +1,54 @@ +github.com/aead/siphash v1.0.1 h1:FwHfE/T45KPKYuuSAKyyvE+oPWcaQ+CUmFW0bPlM+kg= +github.com/aead/siphash v1.0.1/go.mod h1:Nywa3cDsYNNK3gaciGTWPwHt0wlpNV15vwmswBAUSII= +github.com/btcsuite/btcd v0.0.0-20190115013929-ed77733ec07d h1:xG8Pj6Y6J760xwETNmMzmlt38QSwz0BLp1cZ09g27uw= +github.com/btcsuite/btcd v0.0.0-20190115013929-ed77733ec07d/go.mod h1:d3C0AkH6BRcvO8T0UEPu53cnw4IbV63x1bEjildYhO0= +github.com/btcsuite/btclog v0.0.0-20170628155309-84c8d2346e9f h1:bAs4lUbRJpnnkd9VhRV3jjAVU7DJVjMaK+IsvSeZvFo= +github.com/btcsuite/btclog v0.0.0-20170628155309-84c8d2346e9f/go.mod h1:TdznJufoqS23FtqVCzL0ZqgP5MqXbb4fg/WgDys70nA= +github.com/btcsuite/btcutil v0.0.0-20180706230648-ab6388e0c60a/go.mod h1:+5NJ2+qvTyV9exUAL/rxXi3DcLg2Ts+ymUAY5y4NvMg= +github.com/btcsuite/btcutil v0.0.0-20190207003914-4c204d697803 h1:j3AgPKKZtZStM2nyhrDSLSYgT7YHrZKdSkq1OYeLjvM= +github.com/btcsuite/btcutil v0.0.0-20190207003914-4c204d697803/go.mod h1:+5NJ2+qvTyV9exUAL/rxXi3DcLg2Ts+ymUAY5y4NvMg= +github.com/btcsuite/go-socks v0.0.0-20170105172521-4720035b7bfd h1:R/opQEbFEy9JGkIguV40SvRY1uliPX8ifOvi6ICsFCw= +github.com/btcsuite/go-socks v0.0.0-20170105172521-4720035b7bfd/go.mod h1:HHNXQzUsZCxOoE+CPiyCTO6x34Zs86zZUiwtpXoGdtg= +github.com/btcsuite/goleveldb v0.0.0-20160330041536-7834afc9e8cd h1:qdGvebPBDuYDPGi1WCPjy1tGyMpmDK8IEapSsszn7HE= +github.com/btcsuite/goleveldb v0.0.0-20160330041536-7834afc9e8cd/go.mod h1:F+uVaaLLH7j4eDXPRvw78tMflu7Ie2bzYOH4Y8rRKBY= +github.com/btcsuite/snappy-go v0.0.0-20151229074030-0bdef8d06723 h1:ZA/jbKoGcVAnER6pCHPEkGdZOV7U1oLUedErBHCUMs0= +github.com/btcsuite/snappy-go v0.0.0-20151229074030-0bdef8d06723/go.mod h1:8woku9dyThutzjeg+3xrA5iCpBRH8XEEg3lh6TiUghc= +github.com/btcsuite/websocket v0.0.0-20150119174127-31079b680792 h1:R8vQdOQdZ9Y3SkEwmHoWBmX1DNXhXZqlTpq6s4tyJGc= +github.com/btcsuite/websocket v0.0.0-20150119174127-31079b680792/go.mod h1:ghJtEyQwv5/p4Mg4C0fgbePVuGr935/5ddU9Z3TmDRY= +github.com/btcsuite/winsvc v1.0.0/go.mod h1:jsenWakMcC0zFBFurPLEAyrnc/teJEM1O46fmI40EZs= +github.com/davecgh/go-spew v0.0.0-20171005155431-ecdeabc65495/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= +github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c= +github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= +github.com/fsnotify/fsnotify v1.4.7 h1:IXs+QLmnXW2CcXuY+8Mzv/fWEsPGWxqefPtCP5CnV9I= +github.com/fsnotify/fsnotify v1.4.7/go.mod h1:jwhsz4b93w/PPRr/qN1Yymfu8t87LnFCMoQvtojpjFo= +github.com/golang/protobuf v1.2.0 h1:P3YflyNX/ehuJFLhxviNdFxQPkGK5cDcApsge1SqnvM= +github.com/golang/protobuf v1.2.0/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U= +github.com/hpcloud/tail v1.0.0 h1:nfCOvKYfkgYP8hkirhJocXT2+zOD8yUNjXaWfTlyFKI= +github.com/hpcloud/tail v1.0.0/go.mod h1:ab1qPbhIpdTxEkNHXyeSf5vhxWSCs/tWer42PpOxQnU= +github.com/jessevdk/go-flags v0.0.0-20141203071132-1679536dcc89/go.mod h1:4FA24M0QyGHXBuZZK/XkWh8h0e1EYbRYJSGM75WSRxI= +github.com/jrick/logrotate v1.0.0/go.mod h1:LNinyqDIJnpAur+b8yyulnQw/wDuN1+BYKlTRt3OuAQ= +github.com/kkdai/bstream v0.0.0-20161212061736-f391b8402d23 h1:FOOIBWrEkLgmlgGfMuZT83xIwfPDxEI2OHu6xUmJMFE= +github.com/kkdai/bstream v0.0.0-20161212061736-f391b8402d23/go.mod h1:J+Gs4SYgM6CZQHDETBtE9HaSEkGmuNXF86RwHhHUvq4= +github.com/onsi/ginkgo v1.6.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE= +github.com/onsi/ginkgo v1.7.0 h1:WSHQ+IS43OoUrWtD1/bbclrwK8TTH5hzp+umCiuxHgs= +github.com/onsi/ginkgo v1.7.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE= +github.com/onsi/gomega v1.4.3 h1:RE1xgDvH7imwFD45h+u2SgIfERHlS2yNG4DObb5BSKU= +github.com/onsi/gomega v1.4.3/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY= +golang.org/x/crypto v0.0.0-20170930174604-9419663f5a44 h1:9lP3x0pW80sDI6t1UMSLA4to18W7R7imwAI/sWS9S8Q= +golang.org/x/crypto v0.0.0-20170930174604-9419663f5a44/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= +golang.org/x/net v0.0.0-20180906233101-161cd47e91fd h1:nTDtHvHSdCn1m6ITfMRqtOd/9+7a3s8RBNOZ3eYZzJA= +golang.org/x/net v0.0.0-20180906233101-161cd47e91fd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f h1:wMNYb4v58l5UBM7MYRLPG6ZhfOqbKu7X5eyFl8ZhKvA= +golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +golang.org/x/sys v0.0.0-20180909124046-d0be0721c37e h1:o3PsSEY8E4eXWkXrIP9YJALUkVZqzHJT5DOasTyn8Vs= +golang.org/x/sys v0.0.0-20180909124046-d0be0721c37e/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +golang.org/x/text v0.3.0 h1:g61tztE5qeGQ89tm6NTjjM9VPIm088od1l6aSorWRWg= +golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= +gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405 h1:yhCVgyC4o1eVCa2tZl7eS0r+SDo693bJlVdllGtEeKM= +gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= +gopkg.in/fsnotify.v1 v1.4.7 h1:xOHLXZwVvI9hhs+cLKq5+I5onOuwQLhQwiu63xxlHs4= +gopkg.in/fsnotify.v1 v1.4.7/go.mod h1:Tz8NjZHkW78fSQdbUxIjBTcgA1z1m8ZHf0WmKUhAMys= +gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7 h1:uRGJdciOHaEIrze2W8Q3AKkepLTh2hOroT7a+7czfdQ= +gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7/go.mod h1:dt/ZhP58zS4L8KSrWDmTeBkI65Dw0HsyUHuEVlX15mw= +gopkg.in/yaml.v2 v2.2.1 h1:mUhvW9EsL+naU5Q3cakzfE91YhliOondGd6ZrsDBHQE= +gopkg.in/yaml.v2 v2.2.1/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= diff --git a/bip-0158/testnet-19.json b/bip-0158/testnet-19.json new file mode 100644 index 0000000..8945296 --- /dev/null +++ b/bip-0158/testnet-19.json @@ -0,0 +1,13 @@ +[ +["Block Height,Block Hash,Block,[Prev Output Scripts for Block],Previous Basic Header,Basic Filter,Basic Header,Notes"], +[0,"000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943","0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4adae5494dffff001d1aa4ae180101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000",[],"0000000000000000000000000000000000000000000000000000000000000000","019dfca8","21584579b7eb08997773e5aeff3a7f932700042d0ed2a6129012b7d7ae81b750","Genesis block"], +[2,"000000006c02c8ea6e4ff69651f7fcde348fb9d557a06e6957b65552002a7820","0100000006128e87be8b1b4dea47a7247d5528d2702c96826c7a648497e773b800000000e241352e3bec0a95a6217e10c3abb54adfa05abb12c126695595580fb92e222032e7494dffff001d00d235340101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0e0432e7494d010e062f503253482fffffffff0100f2052a010000002321038a7f6ef1c8ca0c588aa53fa860128077c9e6c11e6830f4d7ee4e763a56b7718fac00000000",[],"d7bdac13a59d745b1add0d2ce852f1a0442e8945fc1bf3848d3cbffd88c24fe1","0174a170","186afd11ef2b5e7e3504f2e8cbf8df28a1fd251fe53d60dff8b1467d1b386cf0",""], +[3,"000000008b896e272758da5297bcd98fdc6d97c9b765ecec401e286dc1fdbe10","0100000020782a005255b657696ea057d5b98f34defcf75196f64f6eeac8026c0000000041ba5afc532aae03151b8aa87b65e1594f97504a768e010c98c0add79216247186e7494dffff001d058dc2b60101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0e0486e7494d0151062f503253482fffffffff0100f2052a01000000232103f6d9ff4c12959445ca5549c811683bf9c88e637b222dd2e0311154c4c85cf423ac00000000",[],"186afd11ef2b5e7e3504f2e8cbf8df28a1fd251fe53d60dff8b1467d1b386cf0","016cf7a0","8d63aadf5ab7257cb6d2316a57b16f517bff1c6388f124ec4c04af1212729d2a",""], +[15007,"0000000038c44c703bae0f98cdd6bf30922326340a5996cc692aaae8bacf47ad","0100000002394092aa378fe35d7e9ac79c869b975c4de4374cd75eb5484b0e1e00000000eb9b8670abd44ad6c55cee18e3020fb0c6519e7004b01a16e9164867531b67afc33bc94fffff001d123f10050101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0e04c33bc94f0115062f503253482fffffffff0100f2052a01000000232103f268e9ae07e0f8cb2f6e901d87c510d650b97230c0365b021df8f467363cafb1ac00000000",[],"18b5c2b0146d2d09d24fb00ff5b52bd0742f36c9e65527abdb9de30c027a4748","013c3710","07384b01311867949e0c046607c66b7a766d338474bb67f66c8ae9dbd454b20e","Tx has non-standard OP_RETURN output followed by opcodes"], +[49291,"0000000018b07dca1b28b4b5a119f6d6e71698ce1ed96f143f54179ce177a19c","02000000abfaf47274223ca2fea22797e44498240e482cb4c2f2baea088962f800000000604b5b52c32305b15d7542071d8b04e750a547500005d4010727694b6e72a776e55d0d51ffff001d211806480201000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0d038bc0000102062f503253482fffffffff01a078072a01000000232102971dd6034ed0cf52450b608d196c07d6345184fcb14deb277a6b82d526a6163dac0000000001000000081cefd96060ecb1c4fbe675ad8a4f8bdc61d634c52b3a1c4116dee23749fe80ff000000009300493046022100866859c21f306538152e83f115bcfbf59ab4bb34887a88c03483a5dff9895f96022100a6dfd83caa609bf0516debc2bf65c3df91813a4842650a1858b3f61cfa8af249014730440220296d4b818bb037d0f83f9f7111665f49532dfdcbec1e6b784526e9ac4046eaa602204acf3a5cb2695e8404d80bf49ab04828bcbe6fc31d25a2844ced7a8d24afbdff01ffffffff1cefd96060ecb1c4fbe675ad8a4f8bdc61d634c52b3a1c4116dee23749fe80ff020000009400483045022100e87899175991aa008176cb553c6f2badbb5b741f328c9845fcab89f8b18cae2302200acce689896dc82933015e7230e5230d5cff8a1ffe82d334d60162ac2c5b0c9601493046022100994ad29d1e7b03e41731a4316e5f4992f0d9b6e2efc40a1ccd2c949b461175c502210099b69fdc2db00fbba214f16e286f6a49e2d8a0d5ffc6409d87796add475478d601ffffffff1e4a6d2d280ea06680d6cf8788ac90344a9c67cca9b06005bbd6d3f6945c8272010000009500493046022100a27400ba52fd842ce07398a1de102f710a10c5599545e6c95798934352c2e4df022100f6383b0b14c9f64b6718139f55b6b9494374755b86bae7d63f5d3e583b57255a01493046022100fdf543292f34e1eeb1703b264965339ec4a450ec47585009c606b3edbc5b617b022100a5fbb1c8de8aaaa582988cdb23622838e38de90bebcaab3928d949aa502a65d401ffffffff1e4a6d2d280ea06680d6cf8788ac90344a9c67cca9b06005bbd6d3f6945c8272020000009400493046022100ac626ac3051f875145b4fe4cfe089ea895aac73f65ab837b1ac30f5d875874fa022100bc03e79fa4b7eb707fb735b95ff6613ca33adeaf3a0607cdcead4cfd3b51729801483045022100b720b04a5c5e2f61b7df0fcf334ab6fea167b7aaede5695d3f7c6973496adbf1022043328c4cc1cdc3e5db7bb895ccc37133e960b2fd3ece98350f774596badb387201ffffffff23a8733e349c97d6cd90f520fdd084ba15ce0a395aad03cd51370602bb9e5db3010000004a00483045022100e8556b72c5e9c0da7371913a45861a61c5df434dfd962de7b23848e1a28c86ca02205d41ceda00136267281be0974be132ac4cda1459fe2090ce455619d8b91045e901ffffffff6856d609b881e875a5ee141c235e2a82f6b039f2b9babe82333677a5570285a6000000006a473044022040a1c631554b8b210fbdf2a73f191b2851afb51d5171fb53502a3a040a38d2c0022040d11cf6e7b41fe1b66c3d08f6ada1aee07a047cb77f242b8ecc63812c832c9a012102bcfad931b502761e452962a5976c79158a0f6d307ad31b739611dac6a297c256ffffffff6856d609b881e875a5ee141c235e2a82f6b039f2b9babe82333677a5570285a601000000930048304502205b109df098f7e932fbf71a45869c3f80323974a826ee2770789eae178a21bfc8022100c0e75615e53ee4b6e32b9bb5faa36ac539e9c05fa2ae6b6de5d09c08455c8b9601483045022009fb7d27375c47bea23b24818634df6a54ecf72d52e0c1268fb2a2c84f1885de022100e0ed4f15d62e7f537da0d0f1863498f9c7c0c0a4e00e4679588c8d1a9eb20bb801ffffffffa563c3722b7b39481836d5edfc1461f97335d5d1e9a23ade13680d0e2c1c371f030000006c493046022100ecc38ae2b1565643dc3c0dad5e961a5f0ea09cab28d024f92fa05c922924157e022100ebc166edf6fbe4004c72bfe8cf40130263f98ddff728c8e67b113dbd621906a601210211a4ed241174708c07206601b44a4c1c29e5ad8b1f731c50ca7e1d4b2a06dc1fffffffff02d0223a00000000001976a91445db0b779c0b9fa207f12a8218c94fc77aff504588ac80f0fa02000000000000000000",["5221033423007d8f263819a2e42becaaf5b06f34cb09919e06304349d950668209eaed21021d69e2b68c3960903b702af7829fadcd80bd89b158150c85c4a75b2c8cb9c39452ae","52210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179821021d69e2b68c3960903b702af7829fadcd80bd89b158150c85c4a75b2c8cb9c39452ae","522102a7ae1e0971fc1689bd66d2a7296da3a1662fd21a53c9e38979e0f090a375c12d21022adb62335f41eb4e27056ac37d462cda5ad783fa8e0e526ed79c752475db285d52ae","52210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179821022adb62335f41eb4e27056ac37d462cda5ad783fa8e0e526ed79c752475db285d52ae","512103b9d1d0e2b4355ec3cdef7c11a5c0beff9e8b8d8372ab4b4e0aaf30e80173001951ae","76a9149144761ebaccd5b4bbdc2a35453585b5637b2f8588ac","522103f1848b40621c5d48471d9784c8174ca060555891ace6d2b03c58eece946b1a9121020ee5d32b54d429c152fdc7b1db84f2074b0564d35400d89d11870f9273ec140c52ae","76a914f4fa1cc7de742d135ea82c17adf0bb9cf5f4fb8388ac"],"ed47705334f4643892ca46396eb3f4196a5e30880589e4009ef38eae895d4a13","0afbc2920af1b027f31f87b592276eb4c32094bb4d3697021b4c6380","b6d98692cec5145f67585f3434ec3c2b3030182e1cb3ec58b855c5c164dfaaa3","Tx pays to empty output script"], +[180480,"00000000fd3ceb2404ff07a785c7fdcc76619edc8ed61bd25134eaa22084366a","020000006058aa080a655aa991a444bd7d1f2defd9a3bbe68aabb69030cf3b4e00000000d2e826bfd7ef0beaa891a7eedbc92cd6a544a6cb61c7bdaa436762eb2123ef9790f5f552ffff001d0002c90f0501000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0e0300c102024608062f503253482fffffffff01c0c6072a01000000232102e769e60137a4df6b0df8ebd387cca44c4c57ae74cc0114a8e8317c8f3bfd85e9ac00000000010000000381a0802911a01ffb025c4dea0bc77963e8c1bb46313b71164c53f72f37fe5248010000000151ffffffffc904b267833d215e2128bd9575242232ac2bc311550c7fc1f0ef6f264b40d14c010000000151ffffffffdf0915666649dba81886519c531649b7b02180b4af67d6885e871299e9d5f775000000000151ffffffff0180817dcb00000000232103bb52138972c48a132fc1f637858c5189607dd0f7fe40c4f20f6ad65f2d389ba4ac0000000001000000018da38b434fba82d66052af74fc5e4e94301b114d9bc03f819dc876398404c8b4010000006c493046022100fe738b7580dc5fb5168e51fc61b5aed211125eb71068031009a22d9bbad752c5022100be5086baa384d40bcab0fa586e4f728397388d86e18b66cc417dc4f7fa4f9878012103f233299455134caa2687bdf15cb0becdfb03bd0ff2ff38e65ec6b7834295c34fffffffff022ebc1400000000001976a9147779b7fba1c1e06b717069b80ca170e8b04458a488ac9879c40f000000001976a9142a0307cd925dbb66b534c4db33003dd18c57015788ac0000000001000000026139a62e3422a602de36c873a225c1d3ca5aeee598539ceecb9f0dc8d1ad0f83010000006b483045022100ad9f32b4a0a2ddc19b5a74eba78123e57616f1b3cfd72ce68c03ea35a3dda1f002200dbd22aa6da17213df5e70dfc3b2611d40f70c98ed9626aa5e2cde9d97461f0a012103ddb295d2f1e8319187738fb4b230fdd9aa29d0e01647f69f6d770b9ab24eea90ffffffff983c82c87cf020040d671956525014d5c2b28c6d948c85e1a522362c0059eeae010000006b4830450221009ca544274c786d30a5d5d25e17759201ea16d3aedddf0b9e9721246f7ef6b32e02202cfa5564b6e87dfd9fd98957820e4d4e6238baeb0f65fe305d91506bb13f5f4f012103c99113deac0d5d044e3ac0346abc02501542af8c8d3759f1382c72ff84e704f7ffffffff02c0c62d00000000001976a914ae19d27efe12f5a886dc79af37ad6805db6f922d88ac70ce2000000000001976a9143b8d051d37a07ea1042067e93efe63dbf73920b988ac000000000100000002be566e8cd9933f0c75c4a82c027f7d0c544d5c101d0607ef6ae5d07b98e7f1dc000000006b483045022036a8cdfd5ea7ebc06c2bfb6e4f942bbf9a1caeded41680d11a3a9f5d8284abad022100cacb92a5be3f39e8bc14db1710910ef7b395fa1e18f45d41c28d914fcdde33be012102bf59abf110b5131fae0a3ce1ec379329b4c896a6ae5d443edb68529cc2bc7816ffffffff96cf67645b76ceb23fe922874847456a15feee1655082ff32d25a6bf2c0dfc90000000006a47304402203471ca2001784a5ac0abab583581f2613523da47ec5f53df833c117b5abd81500220618a2847723d57324f2984678db556dbca1a72230fc7e39df04c2239942ba942012102925c9794fd7bb9f8b29e207d5fc491b1150135a21f505041858889fa4edf436fffffffff026c840f00000000001976a914797fb8777d7991d8284d88bfd421ce520f0f843188ac00ca9a3b000000001976a9146d10f3f592699265d10b106eda37c3ce793f7a8588ac00000000",["","","","76a9142903b138c24be9e070b3e73ec495d77a204615e788ac","76a91433a1941fd9a37b9821d376f5a51bd4b52fa50e2888ac","76a914e4374e8155d0865742ca12b8d4d14d41b57d682f88ac","76a914001fa7459a6cfc64bdc178ba7e7a21603bb2568f88ac","76a914f6039952bc2b307aeec5371bfb96b66078ec17f688ac"],"d34ef98386f413769502808d4bac5f20f8dfd5bffc9eedafaa71de0eb1f01489","0db414c859a07e8205876354a210a75042d0463404913d61a8e068e58a3ae2aa080026","c582d51c0ca365e3fcf36c51cb646d7f83a67e867cb4743fd2128e3e022b700c","Tx spends from empty output script"], +[926485,"000000000000015d6077a411a8f5cc95caf775ccf11c54e27df75ce58d187313","0000002060bbab0edbf3ef8a49608ee326f8fd75c473b7e3982095e2d100000000000000c30134f8c9b6d2470488d7a67a888f6fa12f8692e0c3411fbfb92f0f68f67eedae03ca57ef13021acc22dc4105010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff2f0315230e0004ae03ca57043e3d1e1d0c8796bf579aef0c0000000000122f4e696e6a61506f6f6c2f5345475749542fffffffff038427a112000000001976a914876fbb82ec05caa6af7a3b5e5a983aae6c6cc6d688ac0000000000000000266a24aa21a9ed5c748e121c0fe146d973a4ac26fa4a68b0549d46ee22d25f50a5e46fe1b377ee00000000000000002952534b424c4f434b3acd16772ad61a3c5f00287480b720f6035d5e54c9efc71be94bb5e3727f10909001200000000000000000000000000000000000000000000000000000000000000000000000000100000000010145310e878941a1b2bc2d33797ee4d89d95eaaf2e13488063a2aa9a74490f510a0100000023220020b6744de4f6ec63cc92f7c220cdefeeb1b1bed2b66c8e5706d80ec247d37e65a1ffffffff01002d3101000000001976a9143ebc40e411ed3c76f86711507ab952300890397288ac0400473044022001dd489a5d4e2fbd8a3ade27177f6b49296ba7695c40dbbe650ea83f106415fd02200b23a0602d8ff1bdf79dee118205fc7e9b40672bf31563e5741feb53fb86388501483045022100f88f040e90cc5dc6c6189d04718376ac19ed996bf9e4a3c29c3718d90ffd27180220761711f16c9e3a44f71aab55cbc0634907a1fa8bb635d971a9a01d368727bea10169522103b3623117e988b76aaabe3d63f56a4fc88b228a71e64c4cc551d1204822fe85cb2103dd823066e096f72ed617a41d3ca56717db335b1ea47a1b4c5c9dbdd0963acba621033d7c89bd9da29fa8d44db7906a9778b53121f72191184a9fee785c39180e4be153ae00000000010000000120925534261de4dcebb1ed5ab1b62bfe7a3ef968fb111dc2c910adfebc6e3bdf010000006b483045022100f50198f5ae66211a4f485190abe4dc7accdabe3bc214ebc9ea7069b97097d46e0220316a70a03014887086e335fc1b48358d46cd6bdc9af3b57c109c94af76fc915101210316cff587a01a2736d5e12e53551b18d73780b83c3bfb4fcf209c869b11b6415effffffff0220a10700000000001976a91450333046115eaa0ac9e0216565f945070e44573988ac2e7cd01a000000001976a914c01a7ca16b47be50cbdbc60724f701d52d75156688ac00000000010000000203a25f58630d7a1ea52550365fd2156683f56daf6ca73a4b4bbd097e66516322010000006a47304402204efc3d70e4ca3049c2a425025edf22d5ca355f9ec899dbfbbeeb2268533a0f2b02204780d3739653035af4814ea52e1396d021953f948c29754edd0ee537364603dc012103f7a897e4dbecab2264b21917f90664ea8256189ea725d28740cf7ba5d85b5763ffffffff03a25f58630d7a1ea52550365fd2156683f56daf6ca73a4b4bbd097e66516322000000006a47304402202d96defdc5b4af71d6ba28c9a6042c2d5ee7bc6de565d4db84ef517445626e03022022da80320e9e489c8f41b74833dfb6a54a4eb5087cdb46eb663eef0b25caa526012103f7a897e4dbecab2264b21917f90664ea8256189ea725d28740cf7ba5d85b5763ffffffff0200e1f5050000000017a914b7e6f7ff8658b2d1fb107e3d7be7af4742e6b1b3876f88fc00000000001976a914913bcc2be49cb534c20474c4dee1e9c4c317e7eb88ac0000000001000000043ffd60d3818431c495b89be84afac205d5d1ed663009291c560758bbd0a66df5010000006b483045022100f344607de9df42049688dcae8ff1db34c0c7cd25ec05516e30d2bc8f12ac9b2f022060b648f6a21745ea6d9782e17bcc4277b5808326488a1f40d41e125879723d3a012103f7a897e4dbecab2264b21917f90664ea8256189ea725d28740cf7ba5d85b5763ffffffffa5379401cce30f84731ef1ba65ce27edf2cc7ce57704507ebe8714aa16a96b92010000006a473044022020c37a63bf4d7f564c2192528709b6a38ab8271bd96898c6c2e335e5208661580220435c6f1ad4d9305d2c0a818b2feb5e45d443f2f162c0f61953a14d097fd07064012103f7a897e4dbecab2264b21917f90664ea8256189ea725d28740cf7ba5d85b5763ffffffff70e731e193235ff12c3184510895731a099112ffca4b00246c60003c40f843ce000000006a473044022053760f74c29a879e30a17b5f03a5bb057a5751a39f86fa6ecdedc36a1b7db04c022041d41c9b95f00d2d10a0373322a9025dba66c942196bc9d8adeb0e12d3024728012103f7a897e4dbecab2264b21917f90664ea8256189ea725d28740cf7ba5d85b5763ffffffff66b7a71b3e50379c8e85fc18fe3f1a408fc985f257036c34702ba205cef09f6f000000006a4730440220499bf9e2db3db6e930228d0661395f65431acae466634d098612fd80b08459ee022040e069fc9e3c60009f521cef54c38aadbd1251aee37940e6018aadb10f194d6a012103f7a897e4dbecab2264b21917f90664ea8256189ea725d28740cf7ba5d85b5763ffffffff0200e1f5050000000017a9148fc37ad460fdfbd2b44fe446f6e3071a4f64faa6878f447f0b000000001976a914913bcc2be49cb534c20474c4dee1e9c4c317e7eb88ac00000000",["a914feb8a29635c56d9cd913122f90678756bf23887687","76a914c01a7ca16b47be50cbdbc60724f701d52d75156688ac","76a914913bcc2be49cb534c20474c4dee1e9c4c317e7eb88ac","76a914913bcc2be49cb534c20474c4dee1e9c4c317e7eb88ac","76a914913bcc2be49cb534c20474c4dee1e9c4c317e7eb88ac","76a914913bcc2be49cb534c20474c4dee1e9c4c317e7eb88ac","76a914913bcc2be49cb534c20474c4dee1e9c4c317e7eb88ac","76a914913bcc2be49cb534c20474c4dee1e9c4c317e7eb88ac"],"8f13b9a9c85611635b47906c3053ac53cfcec7211455d4cb0d63dc9acc13d472","09027acea61b6cc3fb33f5d52f7d088a6b2f75d234e89ca800","546c574a0472144bcaf9b6aeabf26372ad87c7af7d1ee0dbfae5e099abeae49c","Duplicate pushdata 913bcc2be49cb534c20474c4dee1e9c4c317e7eb"], +[987876,"0000000000000c00901f2049055e2a437c819d79a3d54fd63e6af796cd7b8a79","000000202694f74969fdb542090e95a56bc8aa2d646e27033850e32f1c5f000000000000f7e53676b3f12d5beb524ed617f2d25f5a93b5f4f52c1ba2678260d72712f8dd0a6dfe5740257e1a4b1768960101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff1603e4120ff9c30a1c216900002f424d4920546573742fffffff0001205fa012000000001e76a914c486de584a735ec2f22da7cd9681614681f92173d83d0aa68688ac00000000",[],"fe4d230dbb0f4fec9bed23a5283e08baf996e3f32b93f52c7de1f641ddfd04ad","010c0b40","0965a544743bbfa36f254446e75630c09404b3d164a261892372977538928ed5","Coinbase tx has unparseable output script"], +[1263442,"000000006f27ddfe1dd680044a34548f41bed47eba9e6f0b310da21423bc5f33","000000201c8d1a529c39a396db2db234d5ec152fa651a2872966daccbde028b400000000083f14492679151dbfaa1a825ef4c18518e780c1f91044180280a7d33f4a98ff5f45765aaddc001d38333b9a02010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff230352471300fe5f45765afe94690a000963676d696e6572343208000000000000000000ffffffff024423a804000000001976a914f2c25ac3d59f3d674b1d1d0a25c27339aaac0ba688ac0000000000000000266a24aa21a9edcb26cb3052426b9ebb4d19c819ef87c19677bbf3a7c46ef0855bd1b2abe83491012000000000000000000000000000000000000000000000000000000000000000000000000002000000000101d20978463906ba4ff5e7192494b88dd5eb0de85d900ab253af909106faa22cc5010000000004000000014777ff000000000016001446c29eabe8208a33aa1023c741fa79aa92e881ff0347304402207d7ca96134f2bcfdd6b536536fdd39ad17793632016936f777ebb32c22943fda02206014d2fb8a6aa58279797f861042ba604ebd2f8f61e5bddbd9d3be5a245047b201004b632103eeaeba7ce5dc2470221e9517fb498e8d6bd4e73b85b8be655196972eb9ccd5566754b2752103a40b74d43df244799d041f32ce1ad515a6cd99501701540e38750d883ae21d3a68ac00000000",["002027a5000c7917f785d8fc6e5a55adfca8717ecb973ebb7743849ff956d896a7ed"],"31d66d516a9eda7de865df29f6ef6cb8e4bf9309e5dac899968a9a62a5df61e3","0385acb4f0fe889ef0","4e6d564c2a2452065c205dd7eb2791124e0c4e0dbb064c410c24968572589dec","Includes witness data"], +[1414221,"0000000000000027b2b3b3381f114f674f481544ff2be37ae3788d7e078383b1","000000204ea88307a7959d8207968f152bedca5a93aefab253f1fb2cfb032a400000000070cebb14ec6dbc27a9dfd066d9849a4d3bac5f674665f73a5fe1de01a022a0c851fda85bf05f4c19a779d1450102000000010000000000000000000000000000000000000000000000000000000000000000ffffffff18034d94154d696e6572476174653030310d000000f238f401ffffffff01c817a804000000000000000000",[],"5e5e12d90693c8e936f01847859404c67482439681928353ca1296982042864e","00","021e8882ef5a0ed932edeebbecfeda1d7ce528ec7b3daa27641acf1189d7b5dc","Empty data"] +] diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki new file mode 100644 index 0000000..0226692 --- /dev/null +++ b/bip-0159.mediawiki @@ -0,0 +1,64 @@ +<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 days). +|} + +A safety buffer of 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 than the signaled <code>NODE_NETWORK_LIMITED</code> threshold (288 blocks). + +=== 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/11740 (signaling) +* https://github.com/bitcoin/bitcoin/pull/10387 (connection and relay) + +== 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..c3ee060 --- /dev/null +++ b/bip-0173.mediawiki @@ -0,0 +1,405 @@ +<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: Final + Type: Informational + Created: 2017-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 byte: the witness version +** A conversion of 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]) + +==Registered Human-readable Prefixes== + +SatoshiLabs maintains a full list of registered human-readable parts for other cryptocurrencies: + +[https://github.com/satoshilabs/slips/blob/master/slip-0173.md SLIP-0173 : Registered human-readable parts for BIP-0173] + +==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..b4a6407 --- /dev/null +++ b/bip-0174.mediawiki @@ -0,0 +1,755 @@ +<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: Proposed + 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 map consists of a sequence of key-value 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>. +Each key-value pair must have a unique key within its scope; duplicates are not allowed. 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. There are global types, +per-input types, and per-output types. + +The currently defined global types are as follows: + +* Type: Unsigned Transaction <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x00}</tt> +** Value: The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses). A PSBT must have a transaction, otherwise it is invalid. +*** <tt>{transaction}</tt> +** Note: Every PSBT must have a field with this type. + +* Type: Extended Public Key <tt>PSBT_GLOBAL_XPUB = 0x01</tt> +** Key: The type followed by the 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived. +*** <tt>{0x01}|{xpub}</tt> +** Value: The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key. +*** <tt>{master key fingerprint}|{32-bit int}|...|{32-bit int}</tt> + +The currently defined per-input types are defined as follows: + +* Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> +** Key: None. The key must only contain the 1 byte type. +***<tt>{0x00}</tt> +** Value: The transaction in network serialization format the current input spends from. This should only be present for inputs which spend non-segwit outputs. However, if it is unknown whether an input spends a segwit output, this type should be used. +*** <tt>{transaction}</tt> + +* Type: Witness UTXO <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x01}</tt> +** Value: The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. +*** <tt>{serialized transaction output({output value}|<scriptPubKey>)}</tt> + +* Type: Partial Signature <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt> +** Key: The public key which corresponds to this signature. +*** <tt>{0x02}|{public key}</tt> +** Value: The signature as would be pushed to the stack from a scriptSig or witness. +*** <tt>{signature}</tt> + +* Type: Sighash Type <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x03}</tt> +** Value: The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature. +*** <tt>{sighash type}</tt> + +* Type: Redeem Script <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x04}</tt> +** Value: The redeemScript for this input if it has one. +*** <tt>{redeemScript}</tt> + +* Type: Witness Script <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x05}</tt> +** Value: The witnessScript for this input if it has one. +*** <tt>{witnessScript}</tt> + +* Type: BIP 32 Derivation Path <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt> +** Key: The public key +*** <tt>{0x06}|{public key}</tt> +** Value: The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input. +*** <tt>{master key fingerprint}|{32-bit int}|...|{32-bit int}</tt> + +* Type: Finalized scriptSig <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x07}</tt> +** Value: The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. +*** <tt>{scriptSig}</tt> + +* Type: Finalized scriptWitness <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x08}</tt> +** Value: The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. +*** <tt>{scriptWitness}</tt> + +* Type: Proof-of-reserves commitment <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x09}</tt> +** Value: The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. +*** <tt>{porCommitment}</tt> + +The currently defined per-output <ref>'''Why do we need per-output data?''' Per-output data allows signers +to verify that the outputs are going to the intended recipient. The output data can also be use by signers to +determine which outputs are change outputs and verify that the change is returning to the correct place.</ref> types are defined as follows: + +* Type: Redeem Script <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x00}</tt> +** Value: The redeemScript for this output if it has one. +*** <tt>{redeemScript}</tt> + +* Type: Witness Script <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0x01}</tt> +** Value: The witnessScript for this output if it has one. +*** <tt>{witnessScript}</tt> + +* Type: BIP 32 Derivation Path <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt> +** Key: The public key +*** <tt>{0x02}|{public key}</tt> +** Value: 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. Public keys are those needed to spend this output. +*** <tt>{master key fingerprint}|{32-bit int}|...|{32-bit int}</tt> + +The transaction format is specified as follows: + + +<pre> + {0x70736274}|{0xff}|{global key-value map}|{input key-value map}|...|{input key-value map}|{output key-value map}|...|{output 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 above. Every input in the unsigned transaction must have a corresponding input map. +|- +| 1+ +| Outputs +| Array of key-value maps +| varies +| The key-value pairs for each output as described above. Every output in the unsigned transaction must have a corresponding output map. +|} + +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. + +All keys must have the data that they specify. If any key or value does not match the +specified format for that type, the PSBT must be considered invalid. For example, any +key that has no data except for the type specifier must only have the type specifier in +the key. + +===Handling Duplicated Keys=== + +Keys within each scope should never be duplicated; all keys in the format are unique. PSBTs containing duplicate keys are invalid. However implementors +will still need to handle events where keys are duplicated when combining transactions with duplicated fields. In this event, the software may choose +whichever value it wishes.<ref>'''Why can the values be arbitrarily chosen?''' When there are duplicated keys, the values that can be chosen will either be +valid or invalid. If the values are invalid, a signer would simply produce an invalid signature and the final transaction itself would be invalid. If the +values are valid, then it does not matter which is chosen as either way the transaction is still valid.</ref> + +==Responsibilities== + +Using the transaction format involves many different responsibilities. Multiple responsibilities can be handled by a single entity, but each responsibility is specialized in what it should be capable of doing. + +===Creator=== + +The Creator creates a new PSBT. It must create an unsigned transaction and place it in the PSBT. +The Creator must create empty input fields. + +===Updater=== + +The Updater must only accept a PSBT. +The Updater adds information to the PSBT that it has access to. If it has the UTXO for an input, it should add it to the PSBT. +The Updater should also add redeemScripts, witnessScripts, and BIP 32 derivation paths to the input and output data if it knows them. + +A single entity is likely to be both a Creator and Updater. + +===Signer=== + +The Signer must only accept a PSBT. +The Signer must only use the UTXOs provided in the PSBT to produce signatures for inputs. +Before signing a non-witness input, the Signer must verify that the TXID of the non-witness UTXO matches the TXID specified in the unsigned transaction. +Before signing a witness input, the Signer must verify that the witnessScript (if provided) matches the hash specified in the UTXO or the redeemScript, and the redeemScript (if provided) matches the hash in the UTXO. +The Signer should not need any additional data sources, as all necessary information is provided in the PSBT format. +The Signer must only add data to a PSBT. +Any signatures created by the Signer must be added as a "Partial Signature" key-value pair for the respective input it relates to. +If a Signer cannot sign a transaction, it must not add a Partial Signature. + +The Signer can additionally compute the addresses and values being sent, and the transaction fee, optionally showing this data to the user as a confirmation of intent and the consequences of signing the PSBT. + +Signers do not need to sign for all possible input types. For example, a signer may choose to only sign only Segwit inputs. + +A single entity is likely to be both a Signer and an Updater as it can update a PSBT with necessary information prior to signing it. + +====Data Signers Check For==== + +For a Signer to only produce valid signatures for what it expects to sign, it must check that the following conditions are true: + +* If a non-witness UTXO is provided, its hash must match the hash specified in the prevout +* If a witness UTXO is provided, no non-witness signature may be created +* If a redeemScript is provided, the scriptPubKey must be for that redeemScript +* If a witnessScript is provided, the scriptPubKey or the redeemScript must be for that witnessScript +* If a sighash type is provided, the signer must check that the sighash is acceptable. If unacceptable, they must fail. +* If a sighash type is not provided, the signer should sign using SIGHASH_ALL, but may use any sighash type they wish. + +=====Simple Signer Algorithm===== + +A simple signer can use the following algorithm to determine what and how to sign + +<pre> +sign_witness(script_code, i): + for key, sighash_type in psbt.inputs[i].items: + if sighash_type == None: + sighash_type = SIGHASH_ALL + if IsMine(key) and IsAcceptable(sighash_type): + sign(witness_sighash(script_code, i, input)) + +sign_non_witness(script_code, i): + for key, sighash_type in psbt.inputs[i].items: + if sighash_type == None: + sighash_type = SIGHASH_ALL + if IsMine(key) and IsAcceptable(sighash_type): + sign(non_witness_sighash(script_code, i, input)) + +for input,i in enumerate(psbt.inputs): + if non_witness_utxo.exists: + assert(sha256d(non_witness_utxo) == psbt.tx.innput[i].prevout.hash) + if redeemScript.exists: + assert(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey == P2SH(redeemScript)) + sign_non_witness(redeemScript) + else: + sign_non_witness(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey) + else if witness_utxo.exists: + if redeemScript.exists: + assert(witness_utxo.scriptPubKey == P2SH(redeemScript)) + script = redeemScript + else: + script = witness_utxo.scriptPubKey + if IsP2WPKH(script): + sign_witness(P2PKH(script[2:22])) + else if IsP2WSH(script): + assert(script == P2WSH(witnessScript)) + sign_witness(witnessScript) + else: + assert False +</pre> + +====Change Detection==== + +Signers may wish to display the inputs and outputs to users for extra verification. +In such displays, signers may wish to identify which outputs are change outputs in order to omit them to avoid additional user confusion. +In order to detect change, a signer can use the BIP 32 derivation paths provided in inputs and outputs as well as the extended public keys provided globally. + +For a single key output, a signer can observe whether the master fingerprint for the public key for that output belongs to itself. +If it does, it can then derive the public key at the specified derivation path and check whether that key is the one present in that output. + +For outputs involving multiple keys, a signer can first examine the inputs that it is signing. +It should determine the general pattern of the script and internally produce a representation of the policy that the script represents. +Such a policy can include things like how many keys are present, what order they are in, how many signers are necessary, which signers are required, etc. +The signer can then use the BIP 32 derivation paths for each of the pubkeys to find which global extended public key is the one that can derive that particular public key. +To do so, the signer would extract the derivation path to the highest hardened index and use that to lookup the public key with that index and master fingerprint. +The signer would construct this script policy with extended public keys for all of the inputs and outputs. +Change outputs would then be identified as being the outputs which have the same script policy as the inputs that are being signed. + +===Combiner=== + +The Combiner can accept 1 or many PSBTs. +The Combiner must merge them into one PSBT (if possible), or fail. +The resulting PSBT must contain all of the key-value pairs from each of the PSBTs. +The Combiner must remove any duplicate key-value pairs, in accordance with the specification. It can pick arbitrarily when conflicts occur. +A Combiner must not combine two different PSBTs. PSBTs can be uniquely identified by <tt>0x00</tt> global transaction typed key-value pair. +For every type that a Combiner understands, it may refuse to combine PSBTs if it detects that there will be inconsistencies or conflicts for that type in the combined PSBT. + +The Combiner does not need to know how to interpret scripts in order to combine PSBTs. It can do so without understanding scripts or the network serialization format. + +In general, the result of a Combiner combining two PSBTs from independent participants A and B should be functionally equivalent to a result obtained from processing the original PSBT by A and then B in a sequence. +Or, for participants performing fA(psbt) and fB(psbt): Combine(fA(psbt), fB(psbt)) == fA(fB(psbt)) == fB(fA(psbt)) + +===Input Finalizer=== + +The Input Finalizer must only accept a PSBT. +For each input, the Input Finalizer determines if the input has enough data to pass validation. If it does, it must construct the scriptSig and scriptWitness and place them into the input key-value map. +All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT. The UTXO should be kept to allow Transaction Extractors to verify the final network serialized transaction. + +===Transaction Extractor=== + +The Transaction Extractor must only accept a PSBT. +It checks whether all inputs have complete scriptSigs and scriptWitnesses by checking for the presence of <tt>0x07</tt> Finalized scriptSig and <tt>0x08</tt> Finalized scriptWitness typed records. If they do, the Transaction Extractor should construct complete scriptSigs and scriptWitnesses and encode them into network serialized transactions. Otherwise the Extractor must not modify the PSBT. +The Extractor should produce a fully valid, network serialized transaction if all inputs are complete. + +The Transaction Extractor does not need to know how to interpret scripts in order to extract the network serialized transaction. However it may be able to in order to validate the network serialized transaction at the same time. + +A single entity is likely to be both a Transaction Extractor and an Input Finalizer. + +==Encoding== + +A PSBT can be represented in two ways: in binary (as a file) or as a Base64 string using the encoding described in [https://tools.ietf.org/html/rfc4648#section-4 RFC4648]. + +Binary PSBT files should use the <tt>.psbt</tt> file extension. +A MIME type name will be added to this document once one has been registered. + +==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. + +If one byte type fields were to ever run out, new extensions can still be added by defining multi-byte types where the first byte signals that the next byte indicates the type and so on. + +==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.svg" align="middle"></img> + +===2-of-3 Multisig Workflow=== + +<img src="bip-0174/multisig-workflow.svg" align="middle"></img> + +==Test Vectors== + +The following are invalid PSBTs: + +* Case: Network transaction, not PSBT format +** Bytes in Hex: <pre>0200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf6000000006a473044022070b2245123e6bf474d60c5b50c043d4c691a5d2435f09a34a7662a9dc251790a022001329ca9dacf280bdf30740ec0390422422c81cb45839457aeb76fc12edd95b3012102657d118d3357b8e0f4c2cd46db7b39f6d9c38d9a70abcb9b2de5dc8dbfe4ce31feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300</pre> +** Base64 String: <pre>AgAAAAEmgXE3Ht/yhek3re6ks3t4AAwFZsuzrWRkFxPKQhcb9gAAAABqRzBEAiBwsiRRI+a/R01gxbUMBD1MaRpdJDXwmjSnZiqdwlF5CgIgATKcqdrPKAvfMHQOwDkEIkIsgctFg5RXrrdvwS7dlbMBIQJlfRGNM1e44PTCzUbbezn22cONmnCry5st5dyNv+TOMf7///8C09/1BQAAAAAZdqkU0MWZA8W6woaHYOkP1SGkZlqnZSCIrADh9QUAAAAAF6kUNUXm4zuDLEcFDyTT7rk8nAOUi8eHsy4TAA==</pre> + +* Case: PSBT missing outputs +** Bytes in Hex: <pre>70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000000</pre> +** Base64 String: <pre>cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAA==</pre> + +* Case: PSBT where one input has a filled scriptSig in the unsigned tx +** Bytes in Hex: <pre>70736274ff0100fd0a010200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be4000000006a47304402204759661797c01b036b25928948686218347d89864b719e1f7fcf57d1e511658702205309eabf56aa4d8891ffd111fdf1336f3a29da866d7f8486d75546ceedaf93190121035cdc61fc7ba971c0b501a646a2a83b102cb43881217ca682dc86e2d73fa88292feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac00000000000001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb82308000000</pre> +** Base64 String: <pre>cHNidP8BAP0KAQIAAAACqwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QAAAAAakcwRAIgR1lmF5fAGwNrJZKJSGhiGDR9iYZLcZ4ff89X0eURZYcCIFMJ6r9Wqk2Ikf/REf3xM286KdqGbX+EhtdVRs7tr5MZASEDXNxh/HupccC1AaZGoqg7ECy0OIEhfKaC3Ibi1z+ogpL+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAABASAA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHhwEEFgAUhdE1N/LiZUBaNNuvqePdoB+4IwgAAAA=</pre> + +* Case: PSBT where inputs and outputs are provided but without an unsigned tx +** Bytes in Hex: <pre>70736274ff000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000000</pre> +** Base64 String: <pre>cHNidP8AAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAA==</pre> + +* Case: PSBT with duplicate keys in an input +** Bytes in Hex: <pre>70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000001003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000000</pre> +** Base64 String: <pre>cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAQA/AgAAAAH//////////////////////////////////////////wAAAAAA/////wEAAAAAAAAAAANqAQAAAAAAAAAA</pre> + +* Case: PSBT With invalid global transaction typed key +** Bytes in Hex: <pre>70736274ff020001550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> +** Base64 String: <pre>cHNidP8CAAFVAgAAAAEnmiMjpd+1H8RfIg+liw/BPh4zQnkqhdfjbNYzO1y8OQAAAAAA/////wGgWuoLAAAAABl2qRT/6cAGEJfMO2NvLLBGD6T8Qn0rRYisAAAAAAABASCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre> + +* Case: PSBT With invalid input witness utxo typed key +** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac000000000002010020955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> +** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAIBACCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre> + +* Case: PSBT With invalid pubkey length for input partial signature typed key +** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87210203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd46304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> +** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIQIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYwQwIgBCS1jv+qppThVZ6lyTu/1KiQZCJAVc3wcLZ3FGlELQcCH1yOsP6mUW1guKyzOtZO3mDoeFv7OqlLmb34YVHbmpoBAQQiACB3H9GK1FlmbdSfPVZOPbxC9MhHdONgraFoFqjtSI1WgQEFR1IhA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GIQPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvVKuIgYDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYQtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==</pre> + +* Case: PSBT With invalid redeemscript typed key +** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a01020400220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> +** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQIEACIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre> + +* Case: PSBT With invalid witnessscript typed key +** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d568102050047522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> +** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoECBQBHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre> + +* Case: PSBT With invalid bip32 typed key +** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae210603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd10b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> +** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriEGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb0QtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==</pre> + +* Case: PSBT With invalid non-witness utxo typed key +** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f0000000000020000bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAIAALsCAAAAAarXOTEBi9JfhK5AC2iEi+CdtwbqwqwYKYur7nGrZW+LAAAAAEhHMEQCIFj2/HxqM+GzFUjUgcgmwBW9MBNarULNZ3kNq2bSrSQ7AiBKHO0mBMZzW2OT5bQWkd14sA8MWUL7n3UYVvqpOBV9ugH+////AoDw+gIAAAAAF6kUD7lGNCFpa4LIM68kHHjBfdveSTSH0PIKJwEAAAAXqRQpynT4oI+BmZQoGFyXtdhS5AY/YYdlAAAAAQfaAEcwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAUgwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gFHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4AAQEgAMLrCwAAAAAXqRS39fr0Dj1ApaRZsds1NfK3L6kh6IcBByMiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEI2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre> + +* Case: PSBT With invalid final scriptsig typed key +** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000020700da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAACBwDaAEcwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAUgwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gFHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4AAQEgAMLrCwAAAAAXqRS39fr0Dj1ApaRZsds1NfK3L6kh6IcBByMiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEI2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre> + +* Case: PSBT With invalid final script witness typed key +** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903020800da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAggA2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre> + +* Case: PSBT With invalid pubkey in output BIP 32 derivation paths typed key +** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00210203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca58710d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQjaBABHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwFHMEQCIGX0W6WZi1mif/4ae+0BavHx+Q1Us6qPdFCqX1aiUQO9AiB/ckcDrR7blmgLKEtW1P/LiPf7dZ6rvgiqMPKbhROD0gFHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4AIQIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1PtnuylhxDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA</pre> + +* Case: PSBT With invalid input sighash type typed key +** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0203000100000000010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00</pre> +** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wCAwABAAAAAAEAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre> + +* Case: PSBT With invalid output redeemScript typed key +** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0002000016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00</pre> +** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAgAAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre> + +* Case: PSBT With invalid output witnessScript typed key +** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00</pre> +** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre> + +The following are valid PSBTs: + +* Case: PSBT with one P2PKH input. Outputs are empty +** Bytes in Hex: <pre>70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000000000</pre> +** Base64 String: <pre>cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAAAA</pre> + +* Case: PSBT with one P2PKH input and one P2SH-P2WPKH input. First input is signed and finalized. Outputs are empty +** Bytes in Hex: <pre>70736274ff0100a00200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40000000000feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac000000000001076a47304402204759661797c01b036b25928948686218347d89864b719e1f7fcf57d1e511658702205309eabf56aa4d8891ffd111fdf1336f3a29da866d7f8486d75546ceedaf93190121035cdc61fc7ba971c0b501a646a2a83b102cb43881217ca682dc86e2d73fa882920001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb82308000000</pre> +** Base64 String: <pre>cHNidP8BAKACAAAAAqsJSaCMWvfEm4IS9Bfi8Vqz9cM9zxU4IagTn4d6W3vkAAAAAAD+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAEHakcwRAIgR1lmF5fAGwNrJZKJSGhiGDR9iYZLcZ4ff89X0eURZYcCIFMJ6r9Wqk2Ikf/REf3xM286KdqGbX+EhtdVRs7tr5MZASEDXNxh/HupccC1AaZGoqg7ECy0OIEhfKaC3Ibi1z+ogpIAAQEgAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4cBBBYAFIXRNTfy4mVAWjTbr6nj3aAfuCMIAAAA</pre> + +* Case: PSBT with one P2PKH input which has a non-final scriptSig and has a sighash type specified. Outputs are empty +** Bytes in Hex: <pre>70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000001030401000000000000</pre> +** Base64 String: <pre>cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAQMEAQAAAAAAAA==</pre> + +* Case: PSBT with one P2PKH input and one P2SH-P2WPKH input both with non-final scriptSigs. P2SH-P2WPKH input's redeemScript is available. Outputs filled. +** Bytes in Hex: <pre>70736274ff0100a00200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40000000000feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac00000000000100df0200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf6000000006a473044022070b2245123e6bf474d60c5b50c043d4c691a5d2435f09a34a7662a9dc251790a022001329ca9dacf280bdf30740ec0390422422c81cb45839457aeb76fc12edd95b3012102657d118d3357b8e0f4c2cd46db7b39f6d9c38d9a70abcb9b2de5dc8dbfe4ce31feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e13000001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb8230800220202ead596687ca806043edc3de116cdf29d5e9257c196cd055cf698c8d02bf24e9910b4a6ba670000008000000080020000800022020394f62be9df19952c5587768aeb7698061ad2c4a25c894f47d8c162b4d7213d0510b4a6ba6700000080010000800200008000</pre> +** Base64 String: <pre>cHNidP8BAKACAAAAAqsJSaCMWvfEm4IS9Bfi8Vqz9cM9zxU4IagTn4d6W3vkAAAAAAD+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAEA3wIAAAABJoFxNx7f8oXpN63upLN7eAAMBWbLs61kZBcTykIXG/YAAAAAakcwRAIgcLIkUSPmv0dNYMW1DAQ9TGkaXSQ18Jo0p2YqncJReQoCIAEynKnazygL3zB0DsA5BCJCLIHLRYOUV663b8Eu3ZWzASECZX0RjTNXuOD0ws1G23s59tnDjZpwq8ubLeXcjb/kzjH+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQEgAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4cBBBYAFIXRNTfy4mVAWjTbr6nj3aAfuCMIACICAurVlmh8qAYEPtw94RbN8p1eklfBls0FXPaYyNAr8k6ZELSmumcAAACAAAAAgAIAAIAAIgIDlPYr6d8ZlSxVh3aK63aYBhrSxKJciU9H2MFitNchPQUQtKa6ZwAAAIABAACAAgAAgAA=</pre> + +* Case: PSBT with one P2SH-P2WSH input of a 2-of-2 multisig, redeemScript, witnessScript, and keypaths are available. Contains one signature. +** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> +** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriIGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GELSmumcAAACAAAAAgAQAAIAiBgPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvRC0prpnAAAAgAAAAIAFAACAAAA=</pre> + +* Case: PSBT with unknown types in the inputs. +** Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0000</pre> +** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAA=</pre> + +Fails Signer checks + +* Case: A Witness UTXO is provided for a non-witness input +** Bytes in Hex: <pre>70736274ff0100a00200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40000000000feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac0000000000010122d3dff505000000001976a914d48ed3110b94014cb114bd32d6f4d066dc74256b88ac0001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb8230800220202ead596687ca806043edc3de116cdf29d5e9257c196cd055cf698c8d02bf24e9910b4a6ba670000008000000080020000800022020394f62be9df19952c5587768aeb7698061ad2c4a25c894f47d8c162b4d7213d0510b4a6ba6700000080010000800200008000</pre> +** Base64 String: <pre>cHNidP8BAKACAAAAAqsJSaCMWvfEm4IS9Bfi8Vqz9cM9zxU4IagTn4d6W3vkAAAAAAD+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAEBItPf9QUAAAAAGXapFNSO0xELlAFMsRS9Mtb00GbcdCVriKwAAQEgAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4cBBBYAFIXRNTfy4mVAWjTbr6nj3aAfuCMIACICAurVlmh8qAYEPtw94RbN8p1eklfBls0FXPaYyNAr8k6ZELSmumcAAACAAAAAgAIAAIAAIgIDlPYr6d8ZlSxVh3aK63aYBhrSxKJciU9H2MFitNchPQUQtKa6ZwAAAIABAACAAgAAgAA=</pre> + +* Case: redeemScript with non-witness UTXO does not match the scriptPubKey +** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752af2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq8iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQMBBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSriIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre> + +* Case: redeemScript with witness UTXO does not match the scriptPubKey +** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028900010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQABBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSriIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre> + +* Case: witnessScript with witness UTXO does not match the redeemScript +** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ad2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQMBBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSrSIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre> + +The private keys in the tests below are derived from the following master private key: + +* Extended Private Key: <pre>tprv8ZgxMBicQKsPd9TeAdPADNnSyH9SSUUbTVeFszDE23Ki6TBB5nCefAdHkK8Fm3qMQR6sHwA56zqRmKmxnHk37JkiFzvncDqoKmPWubu7hDF</pre> +** Seed: <pre>cUkG8i1RFfWGWy5ziR11zJ5V4U4W3viSFCfyJmZnvQaUsd1xuF3T</pre> + +A creator creating a PSBT for a transaction which creates the following outputs: + +* scriptPubKey: <tt>0014d85c2b71d0060b09c9886aeb815e50991dda124d</tt>, Amount: <tt>1.49990000</tt> +* scriptPubKey: <tt>001400aea9a2e5f0f876a588df5546e8742d1d87008f</tt>, Amount: <tt>1.00000000</tt> + +and spends the following inputs: + +* TXID: <tt>75ddabb27b8845f5247975c8a5ba7c6f336c4570708ebe230caf6db5217ae858</tt>, Index: <tt>0</tt> +* TXID: <tt>1dea7cd05979072a3578cab271c02244ea8a090bbb46aa680a65ecd027048d83</tt>, Index: <tt>1</tt> + +must create this PSBT: +* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f000000000000000000</pre> +* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAAAAAA=</pre> + +Given the above PSBT, an updater with only the following: + +* Redeem Scripts: +** <tt>5221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae</tt> +** <tt>00208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903</tt> +* Witness Scripts: +** <tt>522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae</tt> +* Previous Transactions: +** <pre>0200000000010158e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd7501000000171600145f275f436b09a8cc9a2eb2a2f528485c68a56323feffffff02d8231f1b0100000017a914aed962d6654f9a2b36608eb9d64d2b260db4f1118700c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e88702483045022100a22edcc6e5bc511af4cc4ae0de0fcd75c7e04d8c1c3a8aa9d820ed4b967384ec02200642963597b9b1bc22c75e9f3e117284a962188bf5e8a74c895089046a20ad770121035509a48eb623e10aace8bfd0212fdb8a8e5af3c94b0b133b95e114cab89e4f7965000000</pre> +** <pre>0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000</pre> +* Public Keys +** Key: <tt>029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f</tt>, Derivation Path: <tt>m/0'/0'/0'</tt> +** Key: <tt>02dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7</tt>, Derivation Path: <tt>m/0'/0'/1'</tt> +** Key: <tt>03089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc</tt>, Derivation Path: <tt>m/0'/0'/2'</tt> +** Key: <tt>023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73</tt>, Derivation Path: <tt>m/0'/0'/3'</tt> +** Key: <tt>03a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca58771</tt>, Derivation Path: <tt>m/0'/0'/4'</tt> +** Key: <tt>027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b50051096</tt>, Derivation Path: <tt>m/0'/0'/5'</tt> + +Must create this PSBT: + +* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e88701042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABBEdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSriIGApWDvzmuCmCXR60Zmt3WNPphCFWdbFzTm0whg/GrluB/ENkMak8AAACAAAAAgAAAAIAiBgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU21xDZDGpPAAAAgAAAAIABAACAAAEBIADC6wsAAAAAF6kUt/X69A49QKWkWbHbNTXyty+pIeiHAQQiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEFR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuIgYCOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnMQ2QxqTwAAAIAAAACAAwAAgCIGAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcENkMak8AAACAAAAAgAIAAIAAIgIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1Ptnuylh3EQ2QxqTwAAAIAAAACABAAAgAAiAgJ/Y5l1fS7/VaE2rQLGhLGDi2VW5fG2s0KCqUtrUAUQlhDZDGpPAAAAgAAAAIAFAACAAA==</pre> + +An updater which adds SIGHASH_ALL to the above PSBT must create this PSBT: + +* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEDBAEAAAABBCIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQVHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4iBgI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8OcxDZDGpPAAAAgAAAAIADAACAIgYDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwQ2QxqTwAAAIAAAACAAgAAgAAiAgOppMN/WZbTqiXbrGtXCvBlA5RJKUJGCzVHU+2e7KWHcRDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA</pre> + +Given the above updated PSBT, a signer that supports SIGHASH_ALL for P2PKH and P2WPKH spends and uses RFC6979 for nonce generation and has the following keys: +* <tt>cP53pDbR5WtAD8dYAW9hhTjuvvTVaEiQBdrz9XPrgLBeRFiyCbQr</tt> (<tt>m/0'/0'/0'</tt>) +* <tt>cR6SXDoyfQrcp4piaiHE97Rsgta9mNhGTen9XeonVgwsh4iSgw6d</tt> (<tt>m/0'/0'/2'</tt>) +must create this PSBT: + +* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000002202029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e887220203089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgf0cwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAQEDBAEAAAABBEdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSriIGApWDvzmuCmCXR60Zmt3WNPphCFWdbFzTm0whg/GrluB/ENkMak8AAACAAAAAgAAAAIAiBgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU21xDZDGpPAAAAgAAAAIABAACAAAEBIADC6wsAAAAAF6kUt/X69A49QKWkWbHbNTXyty+pIeiHIgIDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtxHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwEBAwQBAAAAAQQiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEFR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuIgYCOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnMQ2QxqTwAAAIAAAACAAwAAgCIGAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcENkMak8AAACAAAAAgAIAAIAAIgIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1Ptnuylh3EQ2QxqTwAAAIAAAACABAAAgAAiAgJ/Y5l1fS7/VaE2rQLGhLGDi2VW5fG2s0KCqUtrUAUQlhDZDGpPAAAAgAAAAIAFAACAAA==</pre> + +Given the above updated PSBT, a signer with the following keys: +* <tt>cT7J9YpCwY3AVRFSjN6ukeEeWY6mhpbJPxRaDaP5QTdygQRxP9Au</tt> (<tt>m/0'/0'/1'</tt>) +* <tt>cNBc3SWUip9PPm1GjRoLEJT6T41iNzCYtD7qro84FMnM5zEqeJsE</tt> (<tt>m/0'/0'/3'</tt>) +must create this PSBT: + +* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQMBBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSriIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre> + +Given both of the above PSBTs, a combiner must create this PSBT: + +* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000002202029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e887220203089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f012202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgf0cwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMASICAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAQEDBAEAAAABBEdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSriIGApWDvzmuCmCXR60Zmt3WNPphCFWdbFzTm0whg/GrluB/ENkMak8AAACAAAAAgAAAAIAiBgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU21xDZDGpPAAAAgAAAAIABAACAAAEBIADC6wsAAAAAF6kUt/X69A49QKWkWbHbNTXyty+pIeiHIgIDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtxHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwEiAgI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc0cwRAIgZfRbpZmLWaJ//hp77QFq8fH5DVSzqo90UKpfVqJRA70CIH9yRwOtHtuWaAsoS1bU/8uI9/t1nqu+CKow8puFE4PSAQEDBAEAAAABBCIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQVHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4iBgI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8OcxDZDGpPAAAAgAAAAIADAACAIgYDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwQ2QxqTwAAAIAAAACAAgAAgAAiAgOppMN/WZbTqiXbrGtXCvBlA5RJKUJGCzVHU+2e7KWHcRDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA</pre> + +Given the above PSBT, an input finalizer must create this PSBT: + +* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> +* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQjaBABHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwFHMEQCIGX0W6WZi1mif/4ae+0BavHx+Q1Us6qPdFCqX1aiUQO9AiB/ckcDrR7blmgLKEtW1P/LiPf7dZ6rvgiqMPKbhROD0gFHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4AIgIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1Ptnuylh3EQ2QxqTwAAAIAAAACABAAAgAAiAgJ/Y5l1fS7/VaE2rQLGhLGDi2VW5fG2s0KCqUtrUAUQlhDZDGpPAAAAgAAAAIAFAACAAA==</pre> + +Given the above PSBT, a transaction extractor must create this Bitcoin transaction: + +* Bytes in Hex: <pre>0200000000010258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd7500000000da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752aeffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d01000000232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f000400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00000000</pre> + +Given these two PSBTs with unknown key-value pairs: +* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f00</pre> +** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwA=</pre> + +* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f00</pre> +** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre> + +A combiner which orders keys lexicographically must produce the following PSBT: + +* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f00</pre> +* Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8KDwECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PCg8BAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwoPAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre> + +==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, Daniel Cousens and those who commented on the bitcoin-dev mailing list 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 +!Name +!BIP Number +|- +| Global +| 0 +| PSBT_GLOBAL_UNSIGNED_TX +| BIP 174 +|- +| Input +| 0 +| PSBT_IN_NON_WITNESS_UTXO +| BIP 174 +|- +| Input +| 1 +| PSBT_IN_WITNESS_UTXO +| BIP 174 +|- +| Input +| 2 +| PSBT_IN_PARTIAL_SIG +| BIP 174 +|- +| Input +| 3 +| PSBT_IN_SIGHASH_TYPE +| BIP 174 +|- +| Input +| 4 +| PSBT_IN_REDEEM_SCRIPT +| BIP 174 +|- +| Input +| 5 +| PSBT_IN_WITNESS_SCRIPT +| BIP 174 +|- +| Input +| 6 +| PSBT_IN_BIP32_DERIVATION +| BIP 174 +|- +| Input +| 7 +| PSBT_IN_FINAL_SCRIPTSIG +| BIP 174 +|- +| Input +| 8 +| PSBT_IN_FINAL_SCRIPTWITNESS +| BIP 174 +|- +| Input +| 9 +| PSBT_IN_POR_COMMITMENT +| [[bip-0127.mediawiki|BIP 127]] +|- +| Output +| 0 +| PSBT_OUT_REDEEM_SCRIPT +| BIP 174 +|- +| Output +| 1 +| PSBT_OUT_WITNESS_SCRIPT +| BIP 174 +|- +| Output +| 2 +| PSBT_OUT_BIP32_DERIVATION +| BIP 174 +|} diff --git a/bip-0174/coinjoin-workflow.svg b/bip-0174/coinjoin-workflow.svg new file mode 100644 index 0000000..67a0aad --- /dev/null +++ b/bip-0174/coinjoin-workflow.svg @@ -0,0 +1,655 @@ +<?xml version="1.0" encoding="UTF-8"?> +<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="420.819pt" height="118.266pt" viewBox="0 0 420.819 118.266" version="1.1"> +<defs> +<g> +<symbol overflow="visible" id="glyph0-0"> +<path style="stroke:none;" d=""/> +</symbol> +<symbol overflow="visible" id="glyph0-1"> +<path style="stroke:none;" d="M 6.359375 0 L 3.765625 -6.921875 L 2.875 -6.921875 L 0.28125 0 L 1.015625 0 L 1.78125 -2.03125 L 4.6875 -2.03125 L 5.4375 0 Z M 4.46875 -2.59375 L 2 -2.59375 C 2.5 -4.015625 2.140625 -2.96875 2.640625 -4.390625 C 2.84375 -4.984375 3.15625 -5.828125 3.234375 -6.203125 C 3.265625 -6.0625 3.328125 -5.8125 3.5625 -5.15625 Z M 4.46875 -2.59375 "/> +</symbol> +<symbol overflow="visible" id="glyph0-2"> +<path style="stroke:none;" d="M 1.5625 0 L 1.5625 -6.921875 L 0.8125 -6.921875 L 0.8125 0 Z M 1.5625 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-3"> +<path style="stroke:none;" d="M 1.5625 0 L 1.5625 -4.421875 L 0.8125 -4.421875 L 0.8125 0 Z M 1.640625 -5.640625 L 1.640625 -6.53125 L 0.75 -6.53125 L 0.75 -5.640625 Z M 1.640625 -5.640625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-4"> +<path style="stroke:none;" d="M 4.140625 -0.40625 L 4.078125 -1.0625 C 3.5625 -0.671875 3.03125 -0.53125 2.515625 -0.53125 C 1.6875 -0.53125 1.140625 -1.25 1.140625 -2.21875 C 1.140625 -3 1.5 -3.953125 2.5625 -3.953125 C 3.078125 -3.953125 3.421875 -3.875 3.96875 -3.515625 L 4.09375 -4.171875 C 3.5 -4.5 3.15625 -4.59375 2.546875 -4.59375 C 1.171875 -4.59375 0.359375 -3.390625 0.359375 -2.21875 C 0.359375 -0.984375 1.265625 0.109375 2.515625 0.109375 C 3.046875 0.109375 3.59375 -0.03125 4.140625 -0.40625 Z M 4.140625 -0.40625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-5"> +<path style="stroke:none;" d="M 4.125 -2.1875 C 4.125 -2.515625 4.109375 -3.265625 3.734375 -3.875 C 3.3125 -4.484375 2.71875 -4.59375 2.359375 -4.59375 C 1.25 -4.59375 0.34375 -3.53125 0.34375 -2.25 C 0.34375 -0.9375 1.3125 0.109375 2.5 0.109375 C 3.125 0.109375 3.703125 -0.125 4.09375 -0.40625 L 4.03125 -1.0625 C 3.40625 -0.53125 2.734375 -0.5 2.515625 -0.5 C 1.71875 -0.5 1.078125 -1.203125 1.046875 -2.1875 Z M 3.5625 -2.734375 L 1.09375 -2.734375 C 1.25 -3.484375 1.78125 -3.984375 2.359375 -3.984375 C 2.875 -3.984375 3.421875 -3.65625 3.5625 -2.734375 Z M 3.5625 -2.734375 "/> +</symbol> +<symbol overflow="visible" id="glyph0-6"> +<path style="stroke:none;" d="M 3.265625 -3.875 L 3.265625 -4.53125 C 2.375 -4.53125 1.828125 -4.03125 1.515625 -3.578125 L 1.515625 -4.484375 L 0.8125 -4.484375 L 0.8125 0 L 1.5625 0 L 1.5625 -2.140625 C 1.5625 -3.125 2.28125 -3.84375 3.265625 -3.875 Z M 3.265625 -3.875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-7"> +<path style="stroke:none;" d="M 4.078125 0 L 4.078125 -2.875 C 4.078125 -3.890625 3.34375 -4.59375 2.4375 -4.59375 C 1.78125 -4.59375 1.328125 -4.4375 0.875 -4.171875 L 0.921875 -3.515625 C 1.453125 -3.875 1.9375 -4 2.4375 -4 C 2.90625 -4 3.296875 -3.609375 3.296875 -2.875 L 3.296875 -2.4375 C 1.796875 -2.421875 0.53125 -2 0.53125 -1.125 C 0.53125 -0.703125 0.8125 0.109375 1.671875 0.109375 C 1.8125 0.109375 2.75 0.09375 3.328125 -0.359375 L 3.328125 0 Z M 3.296875 -1.3125 C 3.296875 -1.125 3.296875 -0.875 2.953125 -0.6875 C 2.671875 -0.515625 2.296875 -0.5 2.1875 -0.5 C 1.703125 -0.5 1.25 -0.734375 1.25 -1.140625 C 1.25 -1.84375 2.875 -1.90625 3.296875 -1.9375 Z M 3.296875 -1.3125 "/> +</symbol> +<symbol overflow="visible" id="glyph0-8"> +<path style="stroke:none;" d="M 3.3125 -0.265625 L 3.15625 -0.859375 C 2.890625 -0.640625 2.578125 -0.53125 2.25 -0.53125 C 1.890625 -0.53125 1.75 -0.828125 1.75 -1.359375 L 1.75 -3.84375 L 3.15625 -3.84375 L 3.15625 -4.421875 L 1.75 -4.421875 L 1.75 -5.6875 L 1.0625 -5.6875 L 1.0625 -4.421875 L 0.1875 -4.421875 L 0.1875 -3.84375 L 1.03125 -3.84375 L 1.03125 -1.1875 C 1.03125 -0.59375 1.171875 0.109375 1.859375 0.109375 C 2.546875 0.109375 3.0625 -0.140625 3.3125 -0.265625 Z M 3.3125 -0.265625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-9"> +<path style="stroke:none;" d="M 3.59375 -1.28125 C 3.59375 -1.828125 3.21875 -2.15625 3.203125 -2.1875 C 2.8125 -2.546875 2.546875 -2.609375 2.046875 -2.6875 C 1.5 -2.796875 1.03125 -2.90625 1.03125 -3.390625 C 1.03125 -4 1.75 -4 1.890625 -4 C 2.203125 -4 2.734375 -3.96875 3.296875 -3.625 L 3.421875 -4.28125 C 2.90625 -4.515625 2.5 -4.59375 1.984375 -4.59375 C 1.734375 -4.59375 0.328125 -4.59375 0.328125 -3.296875 C 0.328125 -2.796875 0.625 -2.484375 0.875 -2.296875 C 1.171875 -2.078125 1.390625 -2.03125 1.9375 -1.921875 C 2.296875 -1.859375 2.875 -1.734375 2.875 -1.203125 C 2.875 -0.515625 2.09375 -0.515625 1.9375 -0.515625 C 1.140625 -0.515625 0.578125 -0.890625 0.40625 -1 L 0.28125 -0.328125 C 0.59375 -0.171875 1.140625 0.109375 1.953125 0.109375 C 2.140625 0.109375 2.6875 0.109375 3.109375 -0.203125 C 3.421875 -0.453125 3.59375 -0.84375 3.59375 -1.28125 Z M 3.59375 -1.28125 "/> +</symbol> +<symbol overflow="visible" id="glyph0-10"> +<path style="stroke:none;" d="M 5.796875 -4.90625 C 5.796875 -5.96875 4.8125 -6.921875 3.4375 -6.921875 L 0.953125 -6.921875 L 0.953125 0 L 1.84375 0 L 1.84375 -2.875 L 3.515625 -2.875 C 4.75 -2.875 5.796875 -3.78125 5.796875 -4.90625 Z M 5 -4.90625 C 5 -4.109375 4.359375 -3.453125 3.21875 -3.453125 L 1.8125 -3.453125 L 1.8125 -6.359375 L 3.21875 -6.359375 C 4.3125 -6.359375 5 -5.75 5 -4.90625 Z M 5 -4.90625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-11"> +<path style="stroke:none;" d="M 4.96875 -1.890625 C 4.96875 -2.53125 4.671875 -3.015625 4.453125 -3.25 C 3.984375 -3.75 3.65625 -3.84375 2.734375 -4.0625 C 2.15625 -4.203125 2 -4.25 1.6875 -4.5 C 1.625 -4.5625 1.34375 -4.859375 1.34375 -5.296875 C 1.34375 -5.875 1.890625 -6.484375 2.796875 -6.484375 C 3.640625 -6.484375 4.109375 -6.15625 4.484375 -5.84375 L 4.640625 -6.640625 C 4.09375 -6.96875 3.53125 -7.140625 2.8125 -7.140625 C 1.421875 -7.140625 0.5625 -6.15625 0.5625 -5.171875 C 0.5625 -4.75 0.703125 -4.328125 1.09375 -3.90625 C 1.515625 -3.453125 1.953125 -3.34375 2.546875 -3.203125 C 3.390625 -2.984375 3.484375 -2.953125 3.765625 -2.71875 C 3.96875 -2.546875 4.1875 -2.21875 4.1875 -1.78125 C 4.1875 -1.125 3.640625 -0.46875 2.734375 -0.46875 C 2.328125 -0.46875 1.421875 -0.5625 0.59375 -1.28125 L 0.4375 -0.46875 C 1.3125 0.078125 2.109375 0.21875 2.734375 0.21875 C 4.0625 0.21875 4.96875 -0.78125 4.96875 -1.890625 Z M 4.96875 -1.890625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-12"> +<path style="stroke:none;" d="M 6.078125 -1.875 C 6.078125 -2.734375 5.21875 -3.453125 4.15625 -3.625 C 5.0625 -3.84375 5.8125 -4.421875 5.8125 -5.1875 C 5.8125 -6.09375 4.75 -6.921875 3.328125 -6.921875 L 0.96875 -6.921875 L 0.96875 0 L 3.59375 0 C 5.03125 0 6.078125 -0.890625 6.078125 -1.875 Z M 5.03125 -5.171875 C 5.03125 -4.578125 4.328125 -3.890625 2.953125 -3.890625 L 1.796875 -3.890625 L 1.796875 -6.359375 L 3.046875 -6.359375 C 4.15625 -6.359375 5.03125 -5.828125 5.03125 -5.171875 Z M 5.28125 -1.890625 C 5.28125 -1.140625 4.390625 -0.5625 3.3125 -0.5625 L 1.796875 -0.5625 L 1.796875 -3.296875 L 3.234375 -3.296875 C 4.296875 -3.296875 5.28125 -2.6875 5.28125 -1.890625 Z M 5.28125 -1.890625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-13"> +<path style="stroke:none;" d="M 6.421875 -6.203125 L 6.421875 -6.859375 L 0.359375 -6.859375 L 0.359375 -6.203125 L 1.6875 -6.203125 C 1.8125 -6.203125 1.9375 -6.21875 2.046875 -6.21875 L 2.953125 -6.21875 L 2.953125 0 L 3.84375 0 L 3.84375 -6.21875 L 4.71875 -6.21875 C 4.84375 -6.21875 4.96875 -6.203125 5.078125 -6.203125 Z M 6.421875 -6.203125 "/> +</symbol> +<symbol overflow="visible" id="glyph0-14"> +<path style="stroke:none;" d="M 6.65625 -4.421875 L 5.9375 -4.421875 L 5.296875 -2.3125 C 5.1875 -1.953125 4.890625 -0.96875 4.828125 -0.53125 C 4.78125 -0.84375 4.53125 -1.734375 4.359375 -2.296875 L 3.71875 -4.421875 L 3.015625 -4.421875 L 2.453125 -2.546875 C 2.34375 -2.203125 2 -1.0625 1.96875 -0.546875 L 1.953125 -0.546875 C 1.90625 -1.03125 1.578125 -2.15625 1.421875 -2.703125 L 0.890625 -4.421875 L 0.140625 -4.421875 L 1.5 0 L 2.296875 0 L 2.90625 -2.046875 C 3.046875 -2.515625 3.328125 -3.5 3.359375 -3.875 L 3.375 -3.875 C 3.390625 -3.59375 3.5625 -2.90625 3.6875 -2.46875 L 4.421875 0 L 5.296875 0 Z M 6.65625 -4.421875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-15"> +<path style="stroke:none;" d="M 4.34375 0 L 4.34375 -2.96875 C 4.34375 -3.625 4.1875 -4.53125 2.96875 -4.53125 C 2.359375 -4.53125 1.875 -4.234375 1.5625 -3.8125 L 1.5625 -6.921875 L 0.8125 -6.921875 L 0.8125 0 L 1.578125 0 L 1.578125 -2.4375 C 1.578125 -3.09375 1.828125 -3.921875 2.59375 -3.921875 C 3.546875 -3.921875 3.5625 -3.21875 3.5625 -2.90625 L 3.5625 0 Z M 4.34375 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-16"> +<path style="stroke:none;" d="M 4.671875 -2.1875 C 4.671875 -3.53125 3.671875 -4.59375 2.5 -4.59375 C 1.265625 -4.59375 0.296875 -3.5 0.296875 -2.1875 C 0.296875 -0.875 1.3125 0.109375 2.484375 0.109375 C 3.671875 0.109375 4.671875 -0.890625 4.671875 -2.1875 Z M 3.890625 -2.296875 C 3.890625 -1.109375 3.21875 -0.53125 2.484375 -0.53125 C 1.796875 -0.53125 1.078125 -1.09375 1.078125 -2.296875 C 1.078125 -3.5 1.828125 -3.984375 2.484375 -3.984375 C 3.1875 -3.984375 3.890625 -3.46875 3.890625 -2.296875 Z M 3.890625 -2.296875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-17"> +<path style="stroke:none;" d="M 4.34375 0 L 4.34375 -2.96875 C 4.34375 -3.625 4.1875 -4.53125 2.96875 -4.53125 C 2.078125 -4.53125 1.578125 -3.859375 1.53125 -3.78125 L 1.53125 -4.484375 L 0.8125 -4.484375 L 0.8125 0 L 1.578125 0 L 1.578125 -2.4375 C 1.578125 -3.09375 1.828125 -3.921875 2.59375 -3.921875 C 3.546875 -3.921875 3.5625 -3.21875 3.5625 -2.90625 L 3.5625 0 Z M 4.34375 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-18"> +<path style="stroke:none;" d="M 4.453125 -4.421875 L 3.703125 -4.421875 C 2.40625 -1.25 2.375 -0.796875 2.375 -0.5625 L 2.359375 -0.5625 C 2.296875 -1.234375 1.5 -3.09375 1.46875 -3.1875 L 0.921875 -4.421875 L 0.140625 -4.421875 L 2.078125 0 L 1.71875 0.890625 C 1.453125 1.46875 1.28125 1.46875 1.140625 1.46875 C 0.984375 1.46875 0.671875 1.4375 0.375 1.3125 L 0.421875 1.96875 C 0.640625 2.015625 0.921875 2.046875 1.140625 2.046875 C 1.5 2.046875 1.859375 1.921875 2.265625 0.90625 Z M 4.453125 -4.421875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-19"> +<path style="stroke:none;" d="M 4.78125 -2.21875 C 4.78125 -3.421875 4.15625 -4.53125 3.203125 -4.53125 C 2.609375 -4.53125 2.03125 -4.328125 1.5625 -3.9375 L 1.5625 -4.421875 L 0.8125 -4.421875 L 0.8125 1.9375 L 1.59375 1.9375 L 1.59375 -0.453125 C 1.90625 -0.171875 2.34375 0.109375 2.9375 0.109375 C 3.90625 0.109375 4.78125 -0.875 4.78125 -2.21875 Z M 4 -2.21875 C 4 -1.203125 3.296875 -0.5 2.546875 -0.5 C 2.15625 -0.5 1.890625 -0.703125 1.6875 -0.96875 C 1.59375 -1.109375 1.59375 -1.140625 1.59375 -1.3125 L 1.59375 -3.3125 C 1.828125 -3.671875 2.21875 -3.890625 2.65625 -3.890625 C 3.40625 -3.890625 4 -3.140625 4 -2.21875 Z M 4 -2.21875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-20"> +<path style="stroke:none;" d="M 4.34375 0 L 4.34375 -4.421875 L 3.5625 -4.421875 L 3.5625 -1.53125 C 3.5625 -0.78125 3 -0.4375 2.359375 -0.4375 C 1.65625 -0.4375 1.578125 -0.703125 1.578125 -1.125 L 1.578125 -4.421875 L 0.8125 -4.421875 L 0.8125 -1.09375 C 0.8125 -0.375 1.03125 0.109375 1.859375 0.109375 C 2.390625 0.109375 3.09375 -0.046875 3.59375 -0.484375 L 3.59375 0 Z M 4.34375 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-21"> +<path style="stroke:none;" d="M 5.90625 -2.328125 L 5.90625 -6.921875 L 5.140625 -6.921875 L 5.140625 -2.3125 C 5.140625 -1 4.296875 -0.34375 3.453125 -0.34375 C 2.640625 -0.34375 1.828125 -0.96875 1.828125 -2.3125 L 1.828125 -6.921875 L 0.9375 -6.921875 L 0.9375 -2.328125 C 0.9375 -0.875 2.109375 0.21875 3.453125 0.21875 C 4.78125 0.21875 5.90625 -0.875 5.90625 -2.328125 Z M 5.90625 -2.328125 "/> +</symbol> +<symbol overflow="visible" id="glyph0-22"> +<path style="stroke:none;" d="M 6.5 0 L 3.671875 -3.65625 L 6.078125 -6.921875 L 5.125 -6.921875 L 3.25 -4.3125 L 1.3125 -6.921875 L 0.28125 -6.921875 L 2.828125 -3.65625 L 0.140625 0 L 1.09375 0 L 3.25 -3.046875 L 5.46875 0 Z M 6.5 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-23"> +<path style="stroke:none;" d="M 6.765625 -3.4375 C 6.765625 -5.53125 5.328125 -7.140625 3.671875 -7.140625 C 1.96875 -7.140625 0.5625 -5.515625 0.5625 -3.4375 C 0.5625 -1.328125 2.03125 0.21875 3.65625 0.21875 C 5.328125 0.21875 6.765625 -1.34375 6.765625 -3.4375 Z M 5.875 -3.59375 C 5.875 -1.640625 4.8125 -0.421875 3.671875 -0.421875 C 2.5 -0.421875 1.453125 -1.671875 1.453125 -3.59375 C 1.453125 -5.40625 2.546875 -6.5 3.65625 -6.5 C 4.8125 -6.5 5.875 -5.375 5.875 -3.59375 Z M 5.875 -3.59375 "/> +</symbol> +<symbol overflow="visible" id="glyph0-24"> +<path style="stroke:none;" d="M 4.5625 -6.09375 L 4.5625 -6.921875 L 3.734375 -6.921875 L 3.734375 -6.09375 Z M 4.515625 0 L 4.515625 -4.421875 L 3.765625 -4.421875 L 3.765625 0 Z M 2.9375 -3.84375 L 2.9375 -4.421875 L 1.71875 -4.421875 L 1.71875 -5.625 C 1.71875 -6.265625 2.078125 -6.421875 2.328125 -6.421875 C 2.546875 -6.421875 2.765625 -6.34375 2.9375 -6.234375 L 2.9375 -6.921875 C 2.875 -6.9375 2.625 -7.03125 2.328125 -7.03125 C 1.59375 -7.03125 1 -6.328125 1 -5.328125 L 1 -4.421875 L 0.265625 -4.421875 L 0.265625 -3.84375 L 1 -3.84375 L 1 0 L 1.75 0 L 1.75 -3.84375 Z M 2.9375 -3.84375 "/> +</symbol> +<symbol overflow="visible" id="glyph0-25"> +<path style="stroke:none;" d="M 4.328125 0 L 4.328125 -6.921875 L 3.578125 -6.921875 L 3.578125 -3.984375 C 3.046875 -4.421875 2.5 -4.53125 2.125 -4.53125 C 1.140625 -4.53125 0.359375 -3.5 0.359375 -2.21875 C 0.359375 -0.90625 1.125 0.109375 2.078125 0.109375 C 2.40625 0.109375 2.984375 0.015625 3.546875 -0.515625 L 3.546875 0 Z M 3.546875 -1.390625 C 3.546875 -1.25 3.53125 -1.0625 3.21875 -0.78125 C 2.984375 -0.578125 2.734375 -0.5 2.484375 -0.5 C 1.859375 -0.5 1.140625 -0.96875 1.140625 -2.203125 C 1.140625 -3.515625 2 -3.921875 2.578125 -3.921875 C 3.03125 -3.921875 3.328125 -3.703125 3.546875 -3.375 Z M 3.546875 -1.390625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-26"> +<path style="stroke:none;" d="M 1.796875 0 L 1.796875 -0.828125 L 0.96875 -0.828125 L 0.96875 0 Z M 1.796875 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-27"> +<path style="stroke:none;" d="M 4.78125 -2.21875 C 4.78125 -3.453125 4.109375 -4.53125 3.171875 -4.53125 C 2.78125 -4.53125 2.15625 -4.4375 1.5625 -3.953125 L 1.5625 -6.921875 L 0.8125 -6.921875 L 0.8125 0 L 1.59375 0 L 1.59375 -0.453125 C 1.828125 -0.234375 2.265625 0.109375 2.9375 0.109375 C 3.921875 0.109375 4.78125 -0.890625 4.78125 -2.21875 Z M 4 -2.21875 C 4 -0.921875 3.171875 -0.5 2.5625 -0.5 C 2.171875 -0.5 1.84375 -0.671875 1.59375 -1.140625 L 1.59375 -3.34375 C 1.75 -3.578125 2.109375 -3.921875 2.65625 -3.921875 C 3.25 -3.921875 4 -3.5 4 -2.21875 Z M 4 -2.21875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-28"> +<path style="stroke:none;" d="M 5.859375 -0.453125 L 5.796875 -1.140625 C 5.5 -0.9375 5.21875 -0.75 4.875 -0.640625 C 4.5625 -0.53125 4.203125 -0.53125 3.875 -0.53125 C 3.21875 -0.53125 2.625 -0.875 2.21875 -1.390625 C 1.765625 -1.96875 1.546875 -2.71875 1.546875 -3.453125 C 1.546875 -4.203125 1.765625 -4.953125 2.21875 -5.546875 C 2.625 -6.046875 3.21875 -6.40625 3.875 -6.40625 C 4.171875 -6.40625 4.46875 -6.375 4.765625 -6.28125 C 5.0625 -6.1875 5.34375 -6.046875 5.609375 -5.859375 L 5.734375 -6.671875 C 5.4375 -6.796875 5.140625 -6.890625 4.8125 -6.953125 C 4.5 -7.015625 4.1875 -7.03125 3.875 -7.03125 C 2.984375 -7.03125 2.1875 -6.640625 1.59375 -5.984375 C 0.984375 -5.296875 0.65625 -4.390625 0.65625 -3.453125 C 0.65625 -2.53125 0.984375 -1.625 1.59375 -0.9375 C 2.1875 -0.296875 2.984375 0.109375 3.875 0.109375 C 4.21875 0.109375 4.5625 0.09375 4.90625 0 C 5.25 -0.09375 5.546875 -0.265625 5.859375 -0.453125 Z M 5.859375 -0.453125 "/> +</symbol> +<symbol overflow="visible" id="glyph0-29"> +<path style="stroke:none;" d="M 1.796875 -0.015625 L 1.796875 -0.828125 L 0.96875 -0.828125 L 0.96875 0 L 1.21875 0 L 0.96875 1.25 L 1.375 1.25 Z M 1.796875 -0.015625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-30"> +<path style="stroke:none;" d="M 4.828125 -3.90625 L 4.71875 -4.53125 C 4.03125 -4.53125 3.453125 -4.34375 3.15625 -4.21875 C 2.9375 -4.390625 2.609375 -4.53125 2.203125 -4.53125 C 1.34375 -4.53125 0.625 -3.8125 0.625 -2.90625 C 0.625 -2.546875 0.75 -2.1875 0.953125 -1.921875 C 0.65625 -1.515625 0.65625 -1.125 0.65625 -1.078125 C 0.65625 -0.8125 0.75 -0.53125 0.921875 -0.3125 C 0.40625 -0.015625 0.28125 0.453125 0.28125 0.703125 C 0.28125 1.453125 1.265625 2.046875 2.484375 2.046875 C 3.703125 2.046875 4.6875 1.46875 4.6875 0.703125 C 4.6875 -0.6875 3.03125 -0.6875 2.640625 -0.6875 L 1.765625 -0.6875 C 1.640625 -0.6875 1.1875 -0.6875 1.1875 -1.21875 C 1.1875 -1.328125 1.21875 -1.484375 1.296875 -1.578125 C 1.5 -1.421875 1.828125 -1.28125 2.203125 -1.28125 C 3.09375 -1.28125 3.796875 -2.03125 3.796875 -2.90625 C 3.796875 -3.390625 3.578125 -3.765625 3.46875 -3.90625 L 3.515625 -3.890625 C 3.734375 -3.890625 4 -3.9375 4.25 -3.9375 C 4.421875 -3.9375 4.828125 -3.90625 4.828125 -3.90625 Z M 3.09375 -2.90625 C 3.09375 -2.140625 2.625 -1.859375 2.203125 -1.859375 C 1.828125 -1.859375 1.3125 -2.078125 1.3125 -2.90625 C 1.3125 -3.734375 1.828125 -3.96875 2.203125 -3.96875 C 2.625 -3.96875 3.09375 -3.6875 3.09375 -2.90625 Z M 4 0.71875 C 4 1.15625 3.3125 1.484375 2.5 1.484375 C 1.6875 1.484375 0.984375 1.171875 0.984375 0.703125 C 0.984375 0.671875 0.984375 0.03125 1.75 0.03125 L 2.65625 0.03125 C 2.875 0.03125 4 0.03125 4 0.71875 Z M 4 0.71875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-31"> +<path style="stroke:none;" d="M 4 0 L 4 -0.625 L 2.546875 -0.625 C 2.421875 -0.625 2.296875 -0.609375 2.1875 -0.609375 L 1.328125 -0.609375 L 3.984375 -4.03125 L 3.984375 -4.421875 L 0.421875 -4.421875 L 0.421875 -3.84375 L 1.796875 -3.84375 C 1.921875 -3.84375 2.046875 -3.84375 2.15625 -3.84375 L 2.9375 -3.84375 L 0.28125 -0.40625 L 0.28125 0 Z M 4 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-32"> +<path style="stroke:none;" d="M 4.578125 0 L 2.59375 -2.28125 L 4.421875 -4.421875 L 3.59375 -4.421875 L 2.265625 -2.78125 L 0.890625 -4.421875 L 0.0625 -4.421875 L 1.9375 -2.28125 L 0 0 L 0.8125 0 L 2.265625 -1.875 L 3.765625 0 Z M 4.578125 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-33"> +<path style="stroke:none;" d="M 4.6875 0 L 2.796875 -2.71875 L 4.46875 -4.421875 L 3.578125 -4.421875 L 1.5625 -2.359375 L 1.5625 -6.921875 L 0.84375 -6.921875 L 0.84375 0 L 1.53125 0 L 1.53125 -1.40625 L 2.328125 -2.234375 L 3.875 0 Z M 4.6875 0 "/> +</symbol> +</g> +<clipPath id="clip1"> + <path d="M 19 53 L 128 53 L 128 118.265625 L 19 118.265625 Z M 19 53 "/> +</clipPath> +</defs> +<g id="surface1"> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -63.097625 -24.908594 L 63.097687 -24.908594 L 63.097687 24.907812 L -63.097625 24.907812 Z M -63.097625 -24.908594 " transform="matrix(1,0,0,-1,73.457,29.4)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="28.847" y="14.926"/> + <use xlink:href="#glyph0-2" x="35.489065" y="14.926"/> + <use xlink:href="#glyph0-3" x="37.869131" y="14.926"/> + <use xlink:href="#glyph0-4" x="40.249196" y="14.926"/> + <use xlink:href="#glyph0-5" x="44.677571" y="14.926"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-4" x="52.423493" y="14.926"/> + <use xlink:href="#glyph0-6" x="56.851869" y="14.926"/> + <use xlink:href="#glyph0-5" x="60.256089" y="14.926"/> + <use xlink:href="#glyph0-7" x="64.684465" y="14.926"/> + <use xlink:href="#glyph0-8" x="69.47249" y="14.926"/> + <use xlink:href="#glyph0-5" x="73.069985" y="14.926"/> + <use xlink:href="#glyph0-9" x="77.498361" y="14.926"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="84.634571" y="14.926"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="92.750105" y="14.926"/> + <use xlink:href="#glyph0-11" x="99.11521" y="14.926"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-12" x="104.640468" y="14.926"/> + <use xlink:href="#glyph0-13" x="111.282534" y="14.926"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="31.85" y="26.882"/> + <use xlink:href="#glyph0-3" x="38.657445" y="26.882"/> + <use xlink:href="#glyph0-8" x="41.03751" y="26.882"/> + <use xlink:href="#glyph0-15" x="44.635005" y="26.882"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="53.100226" y="26.882"/> + <use xlink:href="#glyph0-17" x="58.081526" y="26.882"/> + <use xlink:href="#glyph0-2" x="63.229201" y="26.882"/> + <use xlink:href="#glyph0-18" x="65.609266" y="26.882"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="73.53053" y="26.882"/> + <use xlink:href="#glyph0-5" x="78.678205" y="26.882"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-6" x="83.096618" y="26.882"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="89.828347" y="26.882"/> + <use xlink:href="#glyph0-17" x="92.208412" y="26.882"/> + <use xlink:href="#glyph0-19" x="97.356088" y="26.882"/> + <use xlink:href="#glyph0-20" x="102.503763" y="26.882"/> + <use xlink:href="#glyph0-8" x="107.651438" y="26.882"/> + <use xlink:href="#glyph0-9" x="111.248933" y="26.882"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="28.951" y="38.837"/> + <use xlink:href="#glyph0-3" x="35.758445" y="38.837"/> + <use xlink:href="#glyph0-8" x="38.13851" y="38.837"/> + <use xlink:href="#glyph0-15" x="41.736005" y="38.837"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-21" x="50.201226" y="38.837"/> + <use xlink:href="#glyph0-13" x="57.050513" y="38.837"/> + <use xlink:href="#glyph0-22" x="63.831059" y="38.837"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-23" x="70.194171" y="38.837"/> + <use xlink:href="#glyph0-9" x="77.527641" y="38.837"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-24" x="84.673814" y="38.837"/> + <use xlink:href="#glyph0-2" x="90.014764" y="38.837"/> + <use xlink:href="#glyph0-2" x="92.394829" y="38.837"/> + <use xlink:href="#glyph0-5" x="94.774894" y="38.837"/> + <use xlink:href="#glyph0-25" x="99.20327" y="38.837"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="107.668491" y="38.837"/> + <use xlink:href="#glyph0-17" x="110.048557" y="38.837"/> + <use xlink:href="#glyph0-26" x="115.196232" y="38.837"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-11" x="39.391" y="50.792"/> + <use xlink:href="#glyph0-5" x="44.926221" y="50.792"/> + <use xlink:href="#glyph0-17" x="49.354596" y="50.792"/> + <use xlink:href="#glyph0-25" x="54.502272" y="50.792"/> + <use xlink:href="#glyph0-9" x="59.649947" y="50.792"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="66.786157" y="50.792"/> + <use xlink:href="#glyph0-8" x="69.166223" y="50.792"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="76.081263" y="50.792"/> + <use xlink:href="#glyph0-16" x="79.678758" y="50.792"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-12" x="87.987567" y="50.792"/> + <use xlink:href="#glyph0-16" x="94.629632" y="50.792"/> + <use xlink:href="#glyph0-27" x="99.610932" y="50.792"/> + <use xlink:href="#glyph0-26" x="104.758607" y="50.792"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -63.098187 -24.908594 L 63.097125 -24.908594 L 63.097125 24.907812 L -63.098187 24.907812 Z M -63.098187 -24.908594 " transform="matrix(1,0,0,-1,213.731,29.4)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-12" x="172.621" y="26.882"/> + <use xlink:href="#glyph0-16" x="179.263065" y="26.882"/> + <use xlink:href="#glyph0-27" x="184.244365" y="26.882"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="192.709587" y="26.882"/> + <use xlink:href="#glyph0-25" x="197.497612" y="26.882"/> + <use xlink:href="#glyph0-25" x="202.645288" y="26.882"/> + <use xlink:href="#glyph0-9" x="207.792963" y="26.882"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="214.939136" y="26.882"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="220.076849" y="26.882"/> + <use xlink:href="#glyph0-9" x="222.456914" y="26.882"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="229.603087" y="26.882"/> + <use xlink:href="#glyph0-17" x="231.983152" y="26.882"/> + <use xlink:href="#glyph0-19" x="237.130828" y="26.882"/> + <use xlink:href="#glyph0-20" x="242.278503" y="26.882"/> + <use xlink:href="#glyph0-8" x="247.426178" y="26.882"/> + <use xlink:href="#glyph0-9" x="251.023673" y="26.882"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="166.194" y="38.837"/> + <use xlink:href="#glyph0-17" x="170.982026" y="38.837"/> + <use xlink:href="#glyph0-25" x="176.129701" y="38.837"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-24" x="184.594922" y="38.837"/> + <use xlink:href="#glyph0-2" x="189.935872" y="38.837"/> + <use xlink:href="#glyph0-2" x="192.315937" y="38.837"/> + <use xlink:href="#glyph0-9" x="194.696002" y="38.837"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="201.842175" y="38.837"/> + <use xlink:href="#glyph0-17" x="204.22224" y="38.837"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="212.687462" y="38.837"/> + <use xlink:href="#glyph0-3" x="217.835137" y="38.837"/> + <use xlink:href="#glyph0-9" x="220.215202" y="38.837"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-21" x="227.351413" y="38.837"/> + <use xlink:href="#glyph0-13" x="234.2007" y="38.837"/> + <use xlink:href="#glyph0-22" x="240.981246" y="38.837"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-23" x="247.344358" y="38.837"/> + <use xlink:href="#glyph0-9" x="254.677828" y="38.837"/> + <use xlink:href="#glyph0-26" x="258.496493" y="38.837"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -63.09775 -25.682031 L 63.097563 -25.682031 L 63.097563 25.68125 L -63.09775 25.68125 Z M -63.09775 -25.682031 " transform="matrix(1,0,0,-1,354.004,29.4)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-28" x="308.259" y="13.958"/> + <use xlink:href="#glyph0-7" x="314.624105" y="13.958"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-6" x="319.133178" y="13.958"/> + <use xlink:href="#glyph0-16" x="322.537398" y="13.958"/> + <use xlink:href="#glyph0-2" x="327.518698" y="13.958"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="333.216309" y="13.958"/> + <use xlink:href="#glyph0-25" x="338.004335" y="13.958"/> + <use xlink:href="#glyph0-25" x="343.15201" y="13.958"/> + <use xlink:href="#glyph0-9" x="348.299686" y="13.958"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="355.445859" y="13.958"/> + <use xlink:href="#glyph0-5" x="360.593534" y="13.958"/> + <use xlink:href="#glyph0-6" x="365.02191" y="13.958"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="371.743676" y="13.958"/> + <use xlink:href="#glyph0-17" x="374.123741" y="13.958"/> + <use xlink:href="#glyph0-19" x="379.271417" y="13.958"/> + <use xlink:href="#glyph0-20" x="384.419092" y="13.958"/> + <use xlink:href="#glyph0-8" x="389.566767" y="13.958"/> + <use xlink:href="#glyph0-9" x="393.164262" y="13.958"/> + <use xlink:href="#glyph0-29" x="396.982927" y="13.958"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-24" x="314.853" y="25.913"/> + <use xlink:href="#glyph0-2" x="320.19395" y="25.913"/> + <use xlink:href="#glyph0-2" x="322.574015" y="25.913"/> + <use xlink:href="#glyph0-9" x="324.95408" y="25.913"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="332.090291" y="25.913"/> + <use xlink:href="#glyph0-17" x="334.470356" y="25.913"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="342.945539" y="25.913"/> + <use xlink:href="#glyph0-5" x="348.093215" y="25.913"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-6" x="352.511628" y="25.913"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-21" x="359.243357" y="25.913"/> + <use xlink:href="#glyph0-13" x="366.092644" y="25.913"/> + <use xlink:href="#glyph0-22" x="372.87319" y="25.913"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-23" x="379.236302" y="25.913"/> + <use xlink:href="#glyph0-9" x="386.569772" y="25.913"/> + <use xlink:href="#glyph0-29" x="390.388437" y="25.913"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="311.552" y="37.868"/> + <use xlink:href="#glyph0-25" x="316.340026" y="37.868"/> + <use xlink:href="#glyph0-25" x="321.487701" y="37.868"/> + <use xlink:href="#glyph0-9" x="326.635376" y="37.868"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-9" x="333.771587" y="37.868"/> + <use xlink:href="#glyph0-3" x="337.590251" y="37.868"/> + <use xlink:href="#glyph0-30" x="339.970316" y="37.868"/> + <use xlink:href="#glyph0-17" x="344.951616" y="37.868"/> + <use xlink:href="#glyph0-7" x="350.099292" y="37.868"/> + <use xlink:href="#glyph0-8" x="354.887317" y="37.868"/> + <use xlink:href="#glyph0-20" x="358.484812" y="37.868"/> + <use xlink:href="#glyph0-6" x="363.632488" y="37.868"/> + <use xlink:href="#glyph0-5" x="367.036708" y="37.868"/> + <use xlink:href="#glyph0-9" x="371.465084" y="37.868"/> + <use xlink:href="#glyph0-29" x="375.283748" y="37.868"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="381.368905" y="37.868"/> + <use xlink:href="#glyph0-17" x="386.15693" y="37.868"/> + <use xlink:href="#glyph0-25" x="391.304606" y="37.868"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-24" x="313.884" y="49.823"/> + <use xlink:href="#glyph0-17" x="319.22495" y="49.823"/> + <use xlink:href="#glyph0-7" x="324.372625" y="49.823"/> + <use xlink:href="#glyph0-2" x="329.160651" y="49.823"/> + <use xlink:href="#glyph0-3" x="331.540716" y="49.823"/> + <use xlink:href="#glyph0-31" x="333.920781" y="49.823"/> + <use xlink:href="#glyph0-5" x="338.251523" y="49.823"/> + <use xlink:href="#glyph0-9" x="342.679899" y="49.823"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="349.816109" y="49.823"/> + <use xlink:href="#glyph0-5" x="354.963785" y="49.823"/> + <use xlink:href="#glyph0-6" x="359.392161" y="49.823"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="366.113927" y="49.823"/> + <use xlink:href="#glyph0-17" x="368.493992" y="49.823"/> + <use xlink:href="#glyph0-19" x="373.641667" y="49.823"/> + <use xlink:href="#glyph0-20" x="378.789343" y="49.823"/> + <use xlink:href="#glyph0-8" x="383.937018" y="49.823"/> + <use xlink:href="#glyph0-9" x="387.534513" y="49.823"/> + <use xlink:href="#glyph0-26" x="391.353178" y="49.823"/> +</g> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;" d="M 112.644531 64.734375 L 34.269531 64.734375 C 32.070312 64.734375 30.285156 66.515625 30.285156 68.71875 L 30.285156 110.5625 C 30.285156 112.761719 32.070312 114.546875 34.269531 114.546875 L 112.644531 114.546875 C 114.84375 114.546875 116.628906 112.761719 116.628906 110.5625 L 116.628906 68.71875 C 116.628906 66.515625 114.84375 64.734375 112.644531 64.734375 Z M 112.644531 64.734375 "/> +<g clip-path="url(#clip1)" clip-rule="nonzero"> +<path style="fill:none;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 39.187531 24.905625 L -39.187469 24.905625 C -41.386687 24.905625 -43.171844 23.124375 -43.171844 20.92125 L -43.171844 -20.9225 C -43.171844 -23.121719 -41.386687 -24.906875 -39.187469 -24.906875 L 39.187531 -24.906875 C 41.38675 -24.906875 43.171906 -23.121719 43.171906 -20.9225 L 43.171906 20.92125 C 43.171906 23.124375 41.38675 24.905625 39.187531 24.905625 Z M 39.187531 24.905625 " transform="matrix(1,0,0,-1,73.457,89.64)"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="37.094" y="75.167"/> + <use xlink:href="#glyph0-2" x="43.736065" y="75.167"/> + <use xlink:href="#glyph0-3" x="46.116131" y="75.167"/> + <use xlink:href="#glyph0-4" x="48.496196" y="75.167"/> + <use xlink:href="#glyph0-5" x="52.924571" y="75.167"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-5" x="60.670493" y="75.167"/> + <use xlink:href="#glyph0-32" x="65.098869" y="75.167"/> + <use xlink:href="#glyph0-8" x="69.692623" y="75.167"/> + <use xlink:href="#glyph0-6" x="73.290118" y="75.167"/> + <use xlink:href="#glyph0-7" x="76.694339" y="75.167"/> + <use xlink:href="#glyph0-4" x="81.482364" y="75.167"/> + <use xlink:href="#glyph0-8" x="85.91074" y="75.167"/> + <use xlink:href="#glyph0-9" x="89.508235" y="75.167"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="96.644445" y="75.167"/> + <use xlink:href="#glyph0-15" x="100.24194" y="75.167"/> + <use xlink:href="#glyph0-5" x="105.389616" y="75.167"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-17" x="36.852" y="87.122"/> + <use xlink:href="#glyph0-5" x="41.999675" y="87.122"/> + <use xlink:href="#glyph0-8" x="46.428051" y="87.122"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="49.746593" y="87.122"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="56.275085" y="87.122"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-6" x="60.987395" y="87.122"/> + <use xlink:href="#glyph0-33" x="64.391615" y="87.122"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-9" x="72.579876" y="87.122"/> + <use xlink:href="#glyph0-5" x="76.398541" y="87.122"/> + <use xlink:href="#glyph0-6" x="80.826916" y="87.122"/> + <use xlink:href="#glyph0-3" x="84.231137" y="87.122"/> + <use xlink:href="#glyph0-7" x="86.611202" y="87.122"/> + <use xlink:href="#glyph0-2" x="91.399228" y="87.122"/> + <use xlink:href="#glyph0-3" x="93.779293" y="87.122"/> + <use xlink:href="#glyph0-31" x="96.159358" y="87.122"/> + <use xlink:href="#glyph0-5" x="100.4901" y="87.122"/> + <use xlink:href="#glyph0-25" x="104.918476" y="87.122"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="41.217" y="99.077"/> + <use xlink:href="#glyph0-6" x="44.814495" y="99.077"/> + <use xlink:href="#glyph0-7" x="48.218715" y="99.077"/> + <use xlink:href="#glyph0-17" x="53.006741" y="99.077"/> + <use xlink:href="#glyph0-9" x="58.154416" y="99.077"/> + <use xlink:href="#glyph0-7" x="61.973081" y="99.077"/> + <use xlink:href="#glyph0-4" x="66.761106" y="99.077"/> + <use xlink:href="#glyph0-8" x="71.189482" y="99.077"/> + <use xlink:href="#glyph0-3" x="74.786977" y="99.077"/> + <use xlink:href="#glyph0-16" x="77.167042" y="99.077"/> + <use xlink:href="#glyph0-17" x="82.148342" y="99.077"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="90.613563" y="99.077"/> + <use xlink:href="#glyph0-17" x="95.401589" y="99.077"/> + <use xlink:href="#glyph0-25" x="100.549264" y="99.077"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-27" x="45.604" y="111.032"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-6" x="50.472723" y="111.032"/> + <use xlink:href="#glyph0-16" x="53.876943" y="111.032"/> + <use xlink:href="#glyph0-7" x="58.858243" y="111.032"/> + <use xlink:href="#glyph0-25" x="63.646269" y="111.032"/> + <use xlink:href="#glyph0-4" x="68.793944" y="111.032"/> + <use xlink:href="#glyph0-7" x="73.22232" y="111.032"/> + <use xlink:href="#glyph0-9" x="78.010345" y="111.032"/> + <use xlink:href="#glyph0-8" x="81.82901" y="111.032"/> + <use xlink:href="#glyph0-9" x="85.426505" y="111.032"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="92.562715" y="111.032"/> + <use xlink:href="#glyph0-8" x="94.94278" y="111.032"/> + <use xlink:href="#glyph0-26" x="98.540275" y="111.032"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -63.098187 -24.906875 L 63.097125 -24.906875 L 63.097125 24.905625 L -63.098187 24.905625 Z M -63.098187 -24.906875 " transform="matrix(1,0,0,-1,213.731,89.64)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="157.539" y="80.176"/> + <use xlink:href="#glyph0-2" x="164.181065" y="80.176"/> + <use xlink:href="#glyph0-3" x="166.561131" y="80.176"/> + <use xlink:href="#glyph0-4" x="168.941196" y="80.176"/> + <use xlink:href="#glyph0-5" x="173.369571" y="80.176"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-9" x="181.115493" y="80.176"/> + <use xlink:href="#glyph0-3" x="184.934157" y="80.176"/> + <use xlink:href="#glyph0-30" x="187.314223" y="80.176"/> + <use xlink:href="#glyph0-17" x="192.295523" y="80.176"/> + <use xlink:href="#glyph0-9" x="197.443198" y="80.176"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="204.589371" y="80.176"/> + <use xlink:href="#glyph0-15" x="208.186866" y="80.176"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-5" x="213.324579" y="80.176"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="221.080463" y="80.176"/> + <use xlink:href="#glyph0-6" x="224.677958" y="80.176"/> + <use xlink:href="#glyph0-7" x="228.082178" y="80.176"/> + <use xlink:href="#glyph0-17" x="232.870204" y="80.176"/> + <use xlink:href="#glyph0-9" x="238.017879" y="80.176"/> + <use xlink:href="#glyph0-7" x="241.836544" y="80.176"/> + <use xlink:href="#glyph0-4" x="246.624569" y="80.176"/> + <use xlink:href="#glyph0-8" x="251.052945" y="80.176"/> + <use xlink:href="#glyph0-3" x="254.65044" y="80.176"/> + <use xlink:href="#glyph0-16" x="257.030505" y="80.176"/> + <use xlink:href="#glyph0-17" x="262.011805" y="80.176"/> + <use xlink:href="#glyph0-29" x="267.15948" y="80.176"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="172.331" y="92.131"/> + <use xlink:href="#glyph0-25" x="177.119026" y="92.131"/> + <use xlink:href="#glyph0-25" x="182.266701" y="92.131"/> + <use xlink:href="#glyph0-9" x="187.414376" y="92.131"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="194.550587" y="92.131"/> + <use xlink:href="#glyph0-5" x="199.698262" y="92.131"/> + <use xlink:href="#glyph0-6" x="204.126638" y="92.131"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-9" x="210.848404" y="92.131"/> + <use xlink:href="#glyph0-3" x="214.667069" y="92.131"/> + <use xlink:href="#glyph0-30" x="217.047134" y="92.131"/> + <use xlink:href="#glyph0-17" x="222.028434" y="92.131"/> + <use xlink:href="#glyph0-7" x="227.176109" y="92.131"/> + <use xlink:href="#glyph0-8" x="231.964135" y="92.131"/> + <use xlink:href="#glyph0-20" x="235.56163" y="92.131"/> + <use xlink:href="#glyph0-6" x="240.709305" y="92.131"/> + <use xlink:href="#glyph0-5" x="244.113526" y="92.131"/> + <use xlink:href="#glyph0-9" x="248.541901" y="92.131"/> + <use xlink:href="#glyph0-29" x="252.360566" y="92.131"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="164.409" y="104.086"/> + <use xlink:href="#glyph0-17" x="169.197026" y="104.086"/> + <use xlink:href="#glyph0-25" x="174.344701" y="104.086"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-24" x="182.809922" y="104.086"/> + <use xlink:href="#glyph0-17" x="188.150872" y="104.086"/> + <use xlink:href="#glyph0-7" x="193.298547" y="104.086"/> + <use xlink:href="#glyph0-2" x="198.086573" y="104.086"/> + <use xlink:href="#glyph0-3" x="200.466638" y="104.086"/> + <use xlink:href="#glyph0-31" x="202.846703" y="104.086"/> + <use xlink:href="#glyph0-5" x="207.177446" y="104.086"/> + <use xlink:href="#glyph0-9" x="211.605821" y="104.086"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="218.742032" y="104.086"/> + <use xlink:href="#glyph0-5" x="223.889707" y="104.086"/> + <use xlink:href="#glyph0-6" x="228.318083" y="104.086"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="235.049812" y="104.086"/> + <use xlink:href="#glyph0-17" x="237.429877" y="104.086"/> + <use xlink:href="#glyph0-19" x="242.577552" y="104.086"/> + <use xlink:href="#glyph0-20" x="247.725228" y="104.086"/> + <use xlink:href="#glyph0-8" x="252.872903" y="104.086"/> + <use xlink:href="#glyph0-9" x="256.470398" y="104.086"/> + <use xlink:href="#glyph0-26" x="260.289062" y="104.086"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -63.09775 -24.906875 L 63.097563 -24.906875 L 63.097563 24.905625 L -63.09775 24.905625 Z M -63.09775 -24.906875 " transform="matrix(1,0,0,-1,354.004,89.64)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-12" x="299.556" y="80.176"/> + <use xlink:href="#glyph0-16" x="306.198065" y="80.176"/> + <use xlink:href="#glyph0-27" x="311.179365" y="80.176"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-9" x="319.644587" y="80.176"/> + <use xlink:href="#glyph0-3" x="323.463251" y="80.176"/> + <use xlink:href="#glyph0-30" x="325.843316" y="80.176"/> + <use xlink:href="#glyph0-17" x="330.824616" y="80.176"/> + <use xlink:href="#glyph0-9" x="335.972292" y="80.176"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="343.118465" y="80.176"/> + <use xlink:href="#glyph0-15" x="346.71596" y="80.176"/> + <use xlink:href="#glyph0-5" x="351.863635" y="80.176"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="359.609557" y="80.176"/> + <use xlink:href="#glyph0-6" x="363.207051" y="80.176"/> + <use xlink:href="#glyph0-7" x="366.611272" y="80.176"/> + <use xlink:href="#glyph0-17" x="371.399297" y="80.176"/> + <use xlink:href="#glyph0-9" x="376.546973" y="80.176"/> + <use xlink:href="#glyph0-7" x="380.365637" y="80.176"/> + <use xlink:href="#glyph0-4" x="385.153663" y="80.176"/> + <use xlink:href="#glyph0-8" x="389.582039" y="80.176"/> + <use xlink:href="#glyph0-3" x="393.179533" y="80.176"/> + <use xlink:href="#glyph0-16" x="395.559599" y="80.176"/> + <use xlink:href="#glyph0-17" x="400.540899" y="80.176"/> + <use xlink:href="#glyph0-29" x="405.688574" y="80.176"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="313.42" y="92.131"/> + <use xlink:href="#glyph0-25" x="318.208026" y="92.131"/> + <use xlink:href="#glyph0-25" x="323.355701" y="92.131"/> + <use xlink:href="#glyph0-9" x="328.503376" y="92.131"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="335.639587" y="92.131"/> + <use xlink:href="#glyph0-3" x="340.787262" y="92.131"/> + <use xlink:href="#glyph0-9" x="343.167327" y="92.131"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-9" x="350.3135" y="92.131"/> + <use xlink:href="#glyph0-3" x="354.132165" y="92.131"/> + <use xlink:href="#glyph0-30" x="356.51223" y="92.131"/> + <use xlink:href="#glyph0-17" x="361.49353" y="92.131"/> + <use xlink:href="#glyph0-7" x="366.641205" y="92.131"/> + <use xlink:href="#glyph0-8" x="371.429231" y="92.131"/> + <use xlink:href="#glyph0-20" x="375.026726" y="92.131"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-6" x="380.164439" y="92.131"/> + <use xlink:href="#glyph0-5" x="383.568659" y="92.131"/> + <use xlink:href="#glyph0-9" x="387.997035" y="92.131"/> + <use xlink:href="#glyph0-29" x="391.815699" y="92.131"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="305.499" y="104.086"/> + <use xlink:href="#glyph0-17" x="310.287026" y="104.086"/> + <use xlink:href="#glyph0-25" x="315.434701" y="104.086"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-24" x="323.899922" y="104.086"/> + <use xlink:href="#glyph0-17" x="329.240872" y="104.086"/> + <use xlink:href="#glyph0-7" x="334.388547" y="104.086"/> + <use xlink:href="#glyph0-2" x="339.176573" y="104.086"/> + <use xlink:href="#glyph0-3" x="341.556638" y="104.086"/> + <use xlink:href="#glyph0-31" x="343.936703" y="104.086"/> + <use xlink:href="#glyph0-5" x="348.267446" y="104.086"/> + <use xlink:href="#glyph0-9" x="352.695821" y="104.086"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="359.832032" y="104.086"/> + <use xlink:href="#glyph0-3" x="364.979707" y="104.086"/> + <use xlink:href="#glyph0-9" x="367.359772" y="104.086"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="374.505945" y="104.086"/> + <use xlink:href="#glyph0-17" x="376.88601" y="104.086"/> + <use xlink:href="#glyph0-19" x="382.033686" y="104.086"/> + <use xlink:href="#glyph0-20" x="387.181361" y="104.086"/> + <use xlink:href="#glyph0-8" x="392.329037" y="104.086"/> + <use xlink:href="#glyph0-9" x="395.926531" y="104.086"/> + <use xlink:href="#glyph0-26" x="399.745196" y="104.086"/> +</g> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -76.777875 29.734563 L -68.695844 29.734563 " transform="matrix(1,0,0,-1,213.731,59.133)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 150.234375 29.398438 C 148.695312 29.109375 146.191406 28.242188 144.457031 27.234375 L 144.457031 31.566406 C 146.191406 30.554688 148.695312 29.6875 150.234375 29.398438 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 63.495563 29.734563 L 71.577594 29.734563 " transform="matrix(1,0,0,-1,213.731,59.133)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 290.511719 29.398438 C 288.96875 29.109375 286.464844 28.242188 284.730469 27.234375 L 284.730469 31.566406 C 286.464844 30.554688 288.96875 29.6875 290.511719 29.398438 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 140.276813 3.652531 L 140.276813 -0.00371875 " transform="matrix(1,0,0,-1,213.731,59.133)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 354.007812 64.335938 C 354.296875 62.792969 355.160156 60.289062 356.171875 58.558594 L 351.839844 58.558594 C 352.851562 60.289062 353.71875 62.792969 354.007812 64.335938 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 76.780719 -30.507625 L 68.694781 -30.507625 " transform="matrix(1,0,0,-1,213.731,59.133)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 277.226562 89.640625 C 278.769531 89.929688 281.273438 90.796875 283.003906 91.808594 L 283.003906 87.472656 C 281.273438 88.484375 278.769531 89.351562 277.226562 89.640625 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -63.496625 -30.507625 L -91.504437 -30.507625 " transform="matrix(1,0,0,-1,213.731,59.133)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 117.027344 89.640625 C 118.566406 89.929688 121.070312 90.796875 122.804688 91.808594 L 122.804688 87.472656 C 121.070312 88.484375 118.566406 89.351562 117.027344 89.640625 "/> +</g> +</svg> diff --git a/bip-0174/coinjoin-workflow.tex b/bip-0174/coinjoin-workflow.tex new file mode 100644 index 0000000..e0516ff --- /dev/null +++ b/bip-0174/coinjoin-workflow.tex @@ -0,0 +1,59 @@ +% using the PGF/TikZ package with pdflatex +\documentclass{standalone} +\usepackage[utf8]{inputenc} +\usepackage[T1]{fontenc} +%~ \usepackage[english]{babel} +\usepackage[none]{hyphenat}% prevent hyphenation +\usepackage{lmodern} +\renewcommand*\familydefault{\sfdefault} +\usepackage{tikz} +\usetikzlibrary{shapes,arrows} +\tikzset{>=latex} +\begin{document} +% \sffamily{} + \tikzstyle{block_center} = + [rectangle, draw=black, thick, fill=white, + text width=12em, text centered, + minimum height=5em] + \tikzstyle{block_rounded} = [rectangle, + draw=black, thick, fill=white, + text width=8em, text centered, + minimum height=5em, + rounded corners] + \begin{tikzpicture}[auto] + % outlining the flowchart on a grid + \matrix[column sep=3ex,row sep=2ex]{ + \node [block_center] (0alice1) + {Alice creates a PSBT with only her inputs + with UTXOs filled in.\\Sends it to Bob.}; + & + \node [block_center] (1bob1) + {Bob adds his inputs and fills in his + UTXOs.}; + & + \node [block_center] (2carol1) + {Carol adds her inputs, fills in her + UTXOs, adds signatures, and finalizes her inputs.}; + \\ + \node [block_rounded] (5alice2) + {Alice extracts the network serialized + transaction and broadcasts it.}; + & + \node [block_center] (4alice1) + {Alice signs the transaction, adds her + signatures, and finalizes her inputs.}; + & + \node [block_center] (3bob2) + {Bob signs the transaction, adds his + signatures, and finalizes his inputs.}; + \\ + };% end matrix + % connecting nodes with paths + \draw[line width = 1pt, ->] + (0alice1) edge (1bob1) + (1bob1) edge (2carol1) + (2carol1) edge (3bob2) + (3bob2) edge (4alice1) + (4alice1) edge (5alice2); + \end{tikzpicture} +\end{document} diff --git a/bip-0174/multisig-workflow.svg b/bip-0174/multisig-workflow.svg new file mode 100644 index 0000000..951b49e --- /dev/null +++ b/bip-0174/multisig-workflow.svg @@ -0,0 +1,894 @@ +<?xml version="1.0" encoding="UTF-8"?> +<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="375.988pt" height="411.906pt" viewBox="0 0 375.988 411.906" version="1.1"> +<defs> +<g> +<symbol overflow="visible" id="glyph0-0"> +<path style="stroke:none;" d=""/> +</symbol> +<symbol overflow="visible" id="glyph0-1"> +<path style="stroke:none;" d="M 6.359375 0 L 3.765625 -6.921875 L 2.875 -6.921875 L 0.28125 0 L 1.015625 0 L 1.78125 -2.03125 L 4.6875 -2.03125 L 5.4375 0 Z M 4.46875 -2.59375 L 2 -2.59375 C 2.5 -4.015625 2.140625 -2.96875 2.640625 -4.390625 C 2.84375 -4.984375 3.15625 -5.828125 3.234375 -6.203125 C 3.265625 -6.0625 3.328125 -5.8125 3.5625 -5.15625 Z M 4.46875 -2.59375 "/> +</symbol> +<symbol overflow="visible" id="glyph0-2"> +<path style="stroke:none;" d="M 1.5625 0 L 1.5625 -6.921875 L 0.8125 -6.921875 L 0.8125 0 Z M 1.5625 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-3"> +<path style="stroke:none;" d="M 1.5625 0 L 1.5625 -4.421875 L 0.8125 -4.421875 L 0.8125 0 Z M 1.640625 -5.640625 L 1.640625 -6.53125 L 0.75 -6.53125 L 0.75 -5.640625 Z M 1.640625 -5.640625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-4"> +<path style="stroke:none;" d="M 4.140625 -0.40625 L 4.078125 -1.0625 C 3.5625 -0.671875 3.03125 -0.53125 2.515625 -0.53125 C 1.6875 -0.53125 1.140625 -1.25 1.140625 -2.21875 C 1.140625 -3 1.5 -3.953125 2.5625 -3.953125 C 3.078125 -3.953125 3.421875 -3.875 3.96875 -3.515625 L 4.09375 -4.171875 C 3.5 -4.5 3.15625 -4.59375 2.546875 -4.59375 C 1.171875 -4.59375 0.359375 -3.390625 0.359375 -2.21875 C 0.359375 -0.984375 1.265625 0.109375 2.515625 0.109375 C 3.046875 0.109375 3.59375 -0.03125 4.140625 -0.40625 Z M 4.140625 -0.40625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-5"> +<path style="stroke:none;" d="M 4.125 -2.1875 C 4.125 -2.515625 4.109375 -3.265625 3.734375 -3.875 C 3.3125 -4.484375 2.71875 -4.59375 2.359375 -4.59375 C 1.25 -4.59375 0.34375 -3.53125 0.34375 -2.25 C 0.34375 -0.9375 1.3125 0.109375 2.5 0.109375 C 3.125 0.109375 3.703125 -0.125 4.09375 -0.40625 L 4.03125 -1.0625 C 3.40625 -0.53125 2.734375 -0.5 2.515625 -0.5 C 1.71875 -0.5 1.078125 -1.203125 1.046875 -2.1875 Z M 3.5625 -2.734375 L 1.09375 -2.734375 C 1.25 -3.484375 1.78125 -3.984375 2.359375 -3.984375 C 2.875 -3.984375 3.421875 -3.65625 3.5625 -2.734375 Z M 3.5625 -2.734375 "/> +</symbol> +<symbol overflow="visible" id="glyph0-6"> +<path style="stroke:none;" d="M 1.796875 -0.015625 L 1.796875 -0.828125 L 0.96875 -0.828125 L 0.96875 0 L 1.21875 0 L 0.96875 1.25 L 1.375 1.25 Z M 1.796875 -0.015625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-7"> +<path style="stroke:none;" d="M 6.078125 -1.875 C 6.078125 -2.734375 5.21875 -3.453125 4.15625 -3.625 C 5.0625 -3.84375 5.8125 -4.421875 5.8125 -5.1875 C 5.8125 -6.09375 4.75 -6.921875 3.328125 -6.921875 L 0.96875 -6.921875 L 0.96875 0 L 3.59375 0 C 5.03125 0 6.078125 -0.890625 6.078125 -1.875 Z M 5.03125 -5.171875 C 5.03125 -4.578125 4.328125 -3.890625 2.953125 -3.890625 L 1.796875 -3.890625 L 1.796875 -6.359375 L 3.046875 -6.359375 C 4.15625 -6.359375 5.03125 -5.828125 5.03125 -5.171875 Z M 5.28125 -1.890625 C 5.28125 -1.140625 4.390625 -0.5625 3.3125 -0.5625 L 1.796875 -0.5625 L 1.796875 -3.296875 L 3.234375 -3.296875 C 4.296875 -3.296875 5.28125 -2.6875 5.28125 -1.890625 Z M 5.28125 -1.890625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-8"> +<path style="stroke:none;" d="M 4.671875 -2.1875 C 4.671875 -3.53125 3.671875 -4.59375 2.5 -4.59375 C 1.265625 -4.59375 0.296875 -3.5 0.296875 -2.1875 C 0.296875 -0.875 1.3125 0.109375 2.484375 0.109375 C 3.671875 0.109375 4.671875 -0.890625 4.671875 -2.1875 Z M 3.890625 -2.296875 C 3.890625 -1.109375 3.21875 -0.53125 2.484375 -0.53125 C 1.796875 -0.53125 1.078125 -1.09375 1.078125 -2.296875 C 1.078125 -3.5 1.828125 -3.984375 2.484375 -3.984375 C 3.1875 -3.984375 3.890625 -3.46875 3.890625 -2.296875 Z M 3.890625 -2.296875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-9"> +<path style="stroke:none;" d="M 4.78125 -2.21875 C 4.78125 -3.453125 4.109375 -4.53125 3.171875 -4.53125 C 2.78125 -4.53125 2.15625 -4.4375 1.5625 -3.953125 L 1.5625 -6.921875 L 0.8125 -6.921875 L 0.8125 0 L 1.59375 0 L 1.59375 -0.453125 C 1.828125 -0.234375 2.265625 0.109375 2.9375 0.109375 C 3.921875 0.109375 4.78125 -0.890625 4.78125 -2.21875 Z M 4 -2.21875 C 4 -0.921875 3.171875 -0.5 2.5625 -0.5 C 2.171875 -0.5 1.84375 -0.671875 1.59375 -1.140625 L 1.59375 -3.34375 C 1.75 -3.578125 2.109375 -3.921875 2.65625 -3.921875 C 3.25 -3.921875 4 -3.5 4 -2.21875 Z M 4 -2.21875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-10"> +<path style="stroke:none;" d="M 4.078125 0 L 4.078125 -2.875 C 4.078125 -3.890625 3.34375 -4.59375 2.4375 -4.59375 C 1.78125 -4.59375 1.328125 -4.4375 0.875 -4.171875 L 0.921875 -3.515625 C 1.453125 -3.875 1.9375 -4 2.4375 -4 C 2.90625 -4 3.296875 -3.609375 3.296875 -2.875 L 3.296875 -2.4375 C 1.796875 -2.421875 0.53125 -2 0.53125 -1.125 C 0.53125 -0.703125 0.8125 0.109375 1.671875 0.109375 C 1.8125 0.109375 2.75 0.09375 3.328125 -0.359375 L 3.328125 0 Z M 3.296875 -1.3125 C 3.296875 -1.125 3.296875 -0.875 2.953125 -0.6875 C 2.671875 -0.515625 2.296875 -0.5 2.1875 -0.5 C 1.703125 -0.5 1.25 -0.734375 1.25 -1.140625 C 1.25 -1.84375 2.875 -1.90625 3.296875 -1.9375 Z M 3.296875 -1.3125 "/> +</symbol> +<symbol overflow="visible" id="glyph0-11"> +<path style="stroke:none;" d="M 4.34375 0 L 4.34375 -2.96875 C 4.34375 -3.625 4.1875 -4.53125 2.96875 -4.53125 C 2.078125 -4.53125 1.578125 -3.859375 1.53125 -3.78125 L 1.53125 -4.484375 L 0.8125 -4.484375 L 0.8125 0 L 1.578125 0 L 1.578125 -2.4375 C 1.578125 -3.09375 1.828125 -3.921875 2.59375 -3.921875 C 3.546875 -3.921875 3.5625 -3.21875 3.5625 -2.90625 L 3.5625 0 Z M 4.34375 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-12"> +<path style="stroke:none;" d="M 4.328125 0 L 4.328125 -6.921875 L 3.578125 -6.921875 L 3.578125 -3.984375 C 3.046875 -4.421875 2.5 -4.53125 2.125 -4.53125 C 1.140625 -4.53125 0.359375 -3.5 0.359375 -2.21875 C 0.359375 -0.90625 1.125 0.109375 2.078125 0.109375 C 2.40625 0.109375 2.984375 0.015625 3.546875 -0.515625 L 3.546875 0 Z M 3.546875 -1.390625 C 3.546875 -1.25 3.53125 -1.0625 3.21875 -0.78125 C 2.984375 -0.578125 2.734375 -0.5 2.484375 -0.5 C 1.859375 -0.5 1.140625 -0.96875 1.140625 -2.203125 C 1.140625 -3.515625 2 -3.921875 2.578125 -3.921875 C 3.03125 -3.921875 3.328125 -3.703125 3.546875 -3.375 Z M 3.546875 -1.390625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-13"> +<path style="stroke:none;" d="M 5.859375 -0.453125 L 5.796875 -1.140625 C 5.5 -0.9375 5.21875 -0.75 4.875 -0.640625 C 4.5625 -0.53125 4.203125 -0.53125 3.875 -0.53125 C 3.21875 -0.53125 2.625 -0.875 2.21875 -1.390625 C 1.765625 -1.96875 1.546875 -2.71875 1.546875 -3.453125 C 1.546875 -4.203125 1.765625 -4.953125 2.21875 -5.546875 C 2.625 -6.046875 3.21875 -6.40625 3.875 -6.40625 C 4.171875 -6.40625 4.46875 -6.375 4.765625 -6.28125 C 5.0625 -6.1875 5.34375 -6.046875 5.609375 -5.859375 L 5.734375 -6.671875 C 5.4375 -6.796875 5.140625 -6.890625 4.8125 -6.953125 C 4.5 -7.015625 4.1875 -7.03125 3.875 -7.03125 C 2.984375 -7.03125 2.1875 -6.640625 1.59375 -5.984375 C 0.984375 -5.296875 0.65625 -4.390625 0.65625 -3.453125 C 0.65625 -2.53125 0.984375 -1.625 1.59375 -0.9375 C 2.1875 -0.296875 2.984375 0.109375 3.875 0.109375 C 4.21875 0.109375 4.5625 0.09375 4.90625 0 C 5.25 -0.09375 5.546875 -0.265625 5.859375 -0.453125 Z M 5.859375 -0.453125 "/> +</symbol> +<symbol overflow="visible" id="glyph0-14"> +<path style="stroke:none;" d="M 3.265625 -3.875 L 3.265625 -4.53125 C 2.375 -4.53125 1.828125 -4.03125 1.515625 -3.578125 L 1.515625 -4.484375 L 0.8125 -4.484375 L 0.8125 0 L 1.5625 0 L 1.5625 -2.140625 C 1.5625 -3.125 2.28125 -3.84375 3.265625 -3.875 Z M 3.265625 -3.875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-15"> +<path style="stroke:none;" d="M 6.65625 -4.421875 L 5.9375 -4.421875 L 5.296875 -2.3125 C 5.1875 -1.953125 4.890625 -0.96875 4.828125 -0.53125 C 4.78125 -0.84375 4.53125 -1.734375 4.359375 -2.296875 L 3.71875 -4.421875 L 3.015625 -4.421875 L 2.453125 -2.546875 C 2.34375 -2.203125 2 -1.0625 1.96875 -0.546875 L 1.953125 -0.546875 C 1.90625 -1.03125 1.578125 -2.15625 1.421875 -2.703125 L 0.890625 -4.421875 L 0.140625 -4.421875 L 1.5 0 L 2.296875 0 L 2.90625 -2.046875 C 3.046875 -2.515625 3.328125 -3.5 3.359375 -3.875 L 3.375 -3.875 C 3.390625 -3.59375 3.5625 -2.90625 3.6875 -2.46875 L 4.421875 0 L 5.296875 0 Z M 6.65625 -4.421875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-16"> +<path style="stroke:none;" d="M 3.59375 -1.28125 C 3.59375 -1.828125 3.21875 -2.15625 3.203125 -2.1875 C 2.8125 -2.546875 2.546875 -2.609375 2.046875 -2.6875 C 1.5 -2.796875 1.03125 -2.90625 1.03125 -3.390625 C 1.03125 -4 1.75 -4 1.890625 -4 C 2.203125 -4 2.734375 -3.96875 3.296875 -3.625 L 3.421875 -4.28125 C 2.90625 -4.515625 2.5 -4.59375 1.984375 -4.59375 C 1.734375 -4.59375 0.328125 -4.59375 0.328125 -3.296875 C 0.328125 -2.796875 0.625 -2.484375 0.875 -2.296875 C 1.171875 -2.078125 1.390625 -2.03125 1.9375 -1.921875 C 2.296875 -1.859375 2.875 -1.734375 2.875 -1.203125 C 2.875 -0.515625 2.09375 -0.515625 1.9375 -0.515625 C 1.140625 -0.515625 0.578125 -0.890625 0.40625 -1 L 0.28125 -0.328125 C 0.59375 -0.171875 1.140625 0.109375 1.953125 0.109375 C 2.140625 0.109375 2.6875 0.109375 3.109375 -0.203125 C 3.421875 -0.453125 3.59375 -0.84375 3.59375 -1.28125 Z M 3.59375 -1.28125 "/> +</symbol> +<symbol overflow="visible" id="glyph0-17"> +<path style="stroke:none;" d="M 4.34375 0 L 4.34375 -2.96875 C 4.34375 -3.625 4.1875 -4.53125 2.96875 -4.53125 C 2.359375 -4.53125 1.875 -4.234375 1.5625 -3.8125 L 1.5625 -6.921875 L 0.8125 -6.921875 L 0.8125 0 L 1.578125 0 L 1.578125 -2.4375 C 1.578125 -3.09375 1.828125 -3.921875 2.59375 -3.921875 C 3.546875 -3.921875 3.5625 -3.21875 3.5625 -2.90625 L 3.5625 0 Z M 4.34375 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-18"> +<path style="stroke:none;" d="M 3.3125 -0.265625 L 3.15625 -0.859375 C 2.890625 -0.640625 2.578125 -0.53125 2.25 -0.53125 C 1.890625 -0.53125 1.75 -0.828125 1.75 -1.359375 L 1.75 -3.84375 L 3.15625 -3.84375 L 3.15625 -4.421875 L 1.75 -4.421875 L 1.75 -5.6875 L 1.0625 -5.6875 L 1.0625 -4.421875 L 0.1875 -4.421875 L 0.1875 -3.84375 L 1.03125 -3.84375 L 1.03125 -1.1875 C 1.03125 -0.59375 1.171875 0.109375 1.859375 0.109375 C 2.546875 0.109375 3.0625 -0.140625 3.3125 -0.265625 Z M 3.3125 -0.265625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-19"> +<path style="stroke:none;" d="M 4.78125 -2.21875 C 4.78125 -3.421875 4.15625 -4.53125 3.203125 -4.53125 C 2.609375 -4.53125 2.03125 -4.328125 1.5625 -3.9375 L 1.5625 -4.421875 L 0.8125 -4.421875 L 0.8125 1.9375 L 1.59375 1.9375 L 1.59375 -0.453125 C 1.90625 -0.171875 2.34375 0.109375 2.9375 0.109375 C 3.90625 0.109375 4.78125 -0.875 4.78125 -2.21875 Z M 4 -2.21875 C 4 -1.203125 3.296875 -0.5 2.546875 -0.5 C 2.15625 -0.5 1.890625 -0.703125 1.6875 -0.96875 C 1.59375 -1.109375 1.59375 -1.140625 1.59375 -1.3125 L 1.59375 -3.3125 C 1.828125 -3.671875 2.21875 -3.890625 2.65625 -3.890625 C 3.40625 -3.890625 4 -3.140625 4 -2.21875 Z M 4 -2.21875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-20"> +<path style="stroke:none;" d="M 3.453125 -6.25 L 3.453125 -6.921875 C 3.34375 -6.953125 3.03125 -7.03125 2.65625 -7.03125 C 1.71875 -7.03125 1 -6.3125 1 -5.328125 L 1 -4.421875 L 0.265625 -4.421875 L 0.265625 -3.84375 L 1 -3.84375 L 1 0 L 1.75 0 L 1.75 -3.84375 L 2.84375 -3.84375 L 2.84375 -4.421875 L 1.71875 -4.421875 L 1.71875 -5.609375 C 1.71875 -6.34375 2.390625 -6.421875 2.65625 -6.421875 C 2.84375 -6.421875 3.125 -6.40625 3.453125 -6.25 Z M 3.453125 -6.25 "/> +</symbol> +<symbol overflow="visible" id="glyph0-21"> +<path style="stroke:none;" d="M 7.109375 0 L 7.109375 -2.96875 C 7.109375 -3.640625 6.953125 -4.53125 5.734375 -4.53125 C 5.140625 -4.53125 4.625 -4.25 4.25 -3.71875 C 4 -4.46875 3.296875 -4.53125 2.984375 -4.53125 C 2.265625 -4.53125 1.796875 -4.125 1.53125 -3.765625 L 1.53125 -4.484375 L 0.8125 -4.484375 L 0.8125 0 L 1.578125 0 L 1.578125 -2.4375 C 1.578125 -3.125 1.859375 -3.921875 2.59375 -3.921875 C 3.515625 -3.921875 3.5625 -3.28125 3.5625 -2.90625 L 3.5625 0 L 4.34375 0 L 4.34375 -2.4375 C 4.34375 -3.125 4.609375 -3.921875 5.359375 -3.921875 C 6.28125 -3.921875 6.328125 -3.28125 6.328125 -2.90625 L 6.328125 0 Z M 7.109375 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-22"> +<path style="stroke:none;" d="M 4.46875 0 L 4.46875 -0.703125 L 2.65625 -0.703125 C 2.546875 -0.703125 2.421875 -0.703125 2.296875 -0.703125 L 1.21875 -0.703125 C 1.53125 -0.984375 2.296875 -1.71875 2.609375 -2.015625 C 2.796875 -2.1875 3.296875 -2.609375 3.484375 -2.796875 C 3.9375 -3.234375 4.46875 -3.765625 4.46875 -4.609375 C 4.46875 -5.765625 3.671875 -6.765625 2.359375 -6.765625 C 1.21875 -6.765625 0.65625 -5.984375 0.421875 -5.125 C 0.53125 -4.953125 0.59375 -4.890625 0.609375 -4.859375 C 0.625 -4.84375 0.734375 -4.71875 0.828125 -4.578125 C 1.03125 -5.34375 1.3125 -6.125 2.21875 -6.125 C 3.15625 -6.125 3.65625 -5.375 3.65625 -4.59375 C 3.65625 -3.75 3.09375 -3.1875 2.5 -2.578125 L 1.734375 -1.875 L 0.5 -0.640625 L 0.5 0 Z M 4.46875 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-23"> +<path style="stroke:none;" d="M 2.75 -1.921875 L 2.75 -2.5 L 0.109375 -2.5 L 0.109375 -1.921875 Z M 2.75 -1.921875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-24"> +<path style="stroke:none;" d="M 4.5625 -1.796875 C 4.5625 -2.703125 3.859375 -3.3125 3.1875 -3.53125 C 3.9375 -3.9375 4.28125 -4.609375 4.28125 -5.25 C 4.28125 -6.09375 3.453125 -6.765625 2.46875 -6.765625 C 1.703125 -6.765625 0.984375 -6.359375 0.5625 -5.65625 L 0.921875 -5.125 C 1.203125 -5.828125 1.859375 -6.1875 2.46875 -6.1875 C 2.984375 -6.1875 3.46875 -5.875 3.46875 -5.25 C 3.46875 -4.640625 3.0625 -4.046875 2.453125 -3.90625 C 2.390625 -3.890625 2.375 -3.890625 1.671875 -3.84375 L 1.671875 -3.234375 L 2.375 -3.234375 C 3.453125 -3.234375 3.671875 -2.296875 3.671875 -1.796875 C 3.671875 -1.03125 3.203125 -0.390625 2.4375 -0.390625 C 1.75 -0.390625 0.96875 -0.734375 0.53125 -1.421875 L 0.421875 -0.8125 C 1.140625 0.125 2.0625 0.21875 2.46875 0.21875 C 3.671875 0.21875 4.5625 -0.75 4.5625 -1.796875 Z M 4.5625 -1.796875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-25"> +<path style="stroke:none;" d="M 7.71875 0 L 7.71875 -6.921875 L 6.578125 -6.921875 L 5.28125 -3.53125 C 4.9375 -2.625 4.46875 -1.390625 4.359375 -0.921875 L 4.34375 -0.921875 C 4.296875 -1.140625 4.171875 -1.5 4.03125 -1.921875 L 2.46875 -6.046875 L 2.125 -6.921875 L 1 -6.921875 L 1 0 L 1.78125 0 L 1.78125 -6.1875 C 1.84375 -5.859375 2.25 -4.78125 2.5 -4.09375 L 3.984375 -0.21875 L 4.703125 -0.21875 L 6.03125 -3.6875 L 6.515625 -4.953125 C 6.609375 -5.25 6.875 -5.96875 6.921875 -6.1875 L 6.9375 -6.1875 L 6.9375 0 Z M 7.71875 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-26"> +<path style="stroke:none;" d="M 4.34375 0 L 4.34375 -4.421875 L 3.5625 -4.421875 L 3.5625 -1.53125 C 3.5625 -0.78125 3 -0.4375 2.359375 -0.4375 C 1.65625 -0.4375 1.578125 -0.703125 1.578125 -1.125 L 1.578125 -4.421875 L 0.8125 -4.421875 L 0.8125 -1.09375 C 0.8125 -0.375 1.03125 0.109375 1.859375 0.109375 C 2.390625 0.109375 3.09375 -0.046875 3.59375 -0.484375 L 3.59375 0 Z M 4.34375 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-27"> +<path style="stroke:none;" d="M 4.828125 -3.90625 L 4.71875 -4.53125 C 4.03125 -4.53125 3.453125 -4.34375 3.15625 -4.21875 C 2.9375 -4.390625 2.609375 -4.53125 2.203125 -4.53125 C 1.34375 -4.53125 0.625 -3.8125 0.625 -2.90625 C 0.625 -2.546875 0.75 -2.1875 0.953125 -1.921875 C 0.65625 -1.515625 0.65625 -1.125 0.65625 -1.078125 C 0.65625 -0.8125 0.75 -0.53125 0.921875 -0.3125 C 0.40625 -0.015625 0.28125 0.453125 0.28125 0.703125 C 0.28125 1.453125 1.265625 2.046875 2.484375 2.046875 C 3.703125 2.046875 4.6875 1.46875 4.6875 0.703125 C 4.6875 -0.6875 3.03125 -0.6875 2.640625 -0.6875 L 1.765625 -0.6875 C 1.640625 -0.6875 1.1875 -0.6875 1.1875 -1.21875 C 1.1875 -1.328125 1.21875 -1.484375 1.296875 -1.578125 C 1.5 -1.421875 1.828125 -1.28125 2.203125 -1.28125 C 3.09375 -1.28125 3.796875 -2.03125 3.796875 -2.90625 C 3.796875 -3.390625 3.578125 -3.765625 3.46875 -3.90625 L 3.515625 -3.890625 C 3.734375 -3.890625 4 -3.9375 4.25 -3.9375 C 4.421875 -3.9375 4.828125 -3.90625 4.828125 -3.90625 Z M 3.09375 -2.90625 C 3.09375 -2.140625 2.625 -1.859375 2.203125 -1.859375 C 1.828125 -1.859375 1.3125 -2.078125 1.3125 -2.90625 C 1.3125 -3.734375 1.828125 -3.96875 2.203125 -3.96875 C 2.625 -3.96875 3.09375 -3.6875 3.09375 -2.90625 Z M 4 0.71875 C 4 1.15625 3.3125 1.484375 2.5 1.484375 C 1.6875 1.484375 0.984375 1.171875 0.984375 0.703125 C 0.984375 0.671875 0.984375 0.03125 1.75 0.03125 L 2.65625 0.03125 C 2.875 0.03125 4 0.03125 4 0.71875 Z M 4 0.71875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-28"> +<path style="stroke:none;" d="M 1.796875 0 L 1.796875 -0.828125 L 0.96875 -0.828125 L 0.96875 0 Z M 1.796875 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-29"> +<path style="stroke:none;" d="M 5.796875 -4.90625 C 5.796875 -5.96875 4.8125 -6.921875 3.4375 -6.921875 L 0.953125 -6.921875 L 0.953125 0 L 1.84375 0 L 1.84375 -2.875 L 3.515625 -2.875 C 4.75 -2.875 5.796875 -3.78125 5.796875 -4.90625 Z M 5 -4.90625 C 5 -4.109375 4.359375 -3.453125 3.21875 -3.453125 L 1.8125 -3.453125 L 1.8125 -6.359375 L 3.21875 -6.359375 C 4.3125 -6.359375 5 -5.75 5 -4.90625 Z M 5 -4.90625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-30"> +<path style="stroke:none;" d="M 4.96875 -1.890625 C 4.96875 -2.53125 4.671875 -3.015625 4.453125 -3.25 C 3.984375 -3.75 3.65625 -3.84375 2.734375 -4.0625 C 2.15625 -4.203125 2 -4.25 1.6875 -4.5 C 1.625 -4.5625 1.34375 -4.859375 1.34375 -5.296875 C 1.34375 -5.875 1.890625 -6.484375 2.796875 -6.484375 C 3.640625 -6.484375 4.109375 -6.15625 4.484375 -5.84375 L 4.640625 -6.640625 C 4.09375 -6.96875 3.53125 -7.140625 2.8125 -7.140625 C 1.421875 -7.140625 0.5625 -6.15625 0.5625 -5.171875 C 0.5625 -4.75 0.703125 -4.328125 1.09375 -3.90625 C 1.515625 -3.453125 1.953125 -3.34375 2.546875 -3.203125 C 3.390625 -2.984375 3.484375 -2.953125 3.765625 -2.71875 C 3.96875 -2.546875 4.1875 -2.21875 4.1875 -1.78125 C 4.1875 -1.125 3.640625 -0.46875 2.734375 -0.46875 C 2.328125 -0.46875 1.421875 -0.5625 0.59375 -1.28125 L 0.4375 -0.46875 C 1.3125 0.078125 2.109375 0.21875 2.734375 0.21875 C 4.0625 0.21875 4.96875 -0.78125 4.96875 -1.890625 Z M 4.96875 -1.890625 "/> +</symbol> +<symbol overflow="visible" id="glyph0-31"> +<path style="stroke:none;" d="M 6.421875 -6.203125 L 6.421875 -6.859375 L 0.359375 -6.859375 L 0.359375 -6.203125 L 1.6875 -6.203125 C 1.8125 -6.203125 1.9375 -6.21875 2.046875 -6.21875 L 2.953125 -6.21875 L 2.953125 0 L 3.84375 0 L 3.84375 -6.21875 L 4.71875 -6.21875 C 4.84375 -6.21875 4.96875 -6.203125 5.078125 -6.203125 Z M 6.421875 -6.203125 "/> +</symbol> +<symbol overflow="visible" id="glyph0-32"> +<path style="stroke:none;" d="M 5.90625 -2.328125 L 5.90625 -6.921875 L 5.140625 -6.921875 L 5.140625 -2.3125 C 5.140625 -1 4.296875 -0.34375 3.453125 -0.34375 C 2.640625 -0.34375 1.828125 -0.96875 1.828125 -2.3125 L 1.828125 -6.921875 L 0.9375 -6.921875 L 0.9375 -2.328125 C 0.9375 -0.875 2.109375 0.21875 3.453125 0.21875 C 4.78125 0.21875 5.90625 -0.875 5.90625 -2.328125 Z M 5.90625 -2.328125 "/> +</symbol> +<symbol overflow="visible" id="glyph0-33"> +<path style="stroke:none;" d="M 6.5 0 L 3.671875 -3.65625 L 6.078125 -6.921875 L 5.125 -6.921875 L 3.25 -4.3125 L 1.3125 -6.921875 L 0.28125 -6.921875 L 2.828125 -3.65625 L 0.140625 0 L 1.09375 0 L 3.25 -3.046875 L 5.46875 0 Z M 6.5 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-34"> +<path style="stroke:none;" d="M 6.765625 -3.4375 C 6.765625 -5.53125 5.328125 -7.140625 3.671875 -7.140625 C 1.96875 -7.140625 0.5625 -5.515625 0.5625 -3.4375 C 0.5625 -1.328125 2.03125 0.21875 3.65625 0.21875 C 5.328125 0.21875 6.765625 -1.34375 6.765625 -3.4375 Z M 5.875 -3.59375 C 5.875 -1.640625 4.8125 -0.421875 3.671875 -0.421875 C 2.5 -0.421875 1.453125 -1.671875 1.453125 -3.59375 C 1.453125 -5.40625 2.546875 -6.5 3.65625 -6.5 C 4.8125 -6.5 5.875 -5.375 5.875 -3.59375 Z M 5.875 -3.59375 "/> +</symbol> +<symbol overflow="visible" id="glyph0-35"> +<path style="stroke:none;" d="M 4.5625 -6.09375 L 4.5625 -6.921875 L 3.734375 -6.921875 L 3.734375 -6.09375 Z M 4.515625 0 L 4.515625 -4.421875 L 3.765625 -4.421875 L 3.765625 0 Z M 2.9375 -3.84375 L 2.9375 -4.421875 L 1.71875 -4.421875 L 1.71875 -5.625 C 1.71875 -6.265625 2.078125 -6.421875 2.328125 -6.421875 C 2.546875 -6.421875 2.765625 -6.34375 2.9375 -6.234375 L 2.9375 -6.921875 C 2.875 -6.9375 2.625 -7.03125 2.328125 -7.03125 C 1.59375 -7.03125 1 -6.328125 1 -5.328125 L 1 -4.421875 L 0.265625 -4.421875 L 0.265625 -3.84375 L 1 -3.84375 L 1 0 L 1.75 0 L 1.75 -3.84375 Z M 2.9375 -3.84375 "/> +</symbol> +<symbol overflow="visible" id="glyph0-36"> +<path style="stroke:none;" d="M 6.5 -6.921875 L 5.71875 -6.921875 L 4.390625 -3.515625 C 4.234375 -3.09375 3.484375 -1.171875 3.40625 -0.71875 L 3.390625 -0.71875 C 3.3125 -1.109375 2.875 -2.21875 2.796875 -2.453125 L 1.0625 -6.921875 L 0.140625 -6.921875 L 2.859375 0 L 3.78125 0 Z M 6.5 -6.921875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-37"> +<path style="stroke:none;" d="M 4.453125 -4.421875 L 3.703125 -4.421875 C 2.40625 -1.25 2.375 -0.796875 2.375 -0.5625 L 2.359375 -0.5625 C 2.296875 -1.234375 1.5 -3.09375 1.46875 -3.1875 L 0.921875 -4.421875 L 0.140625 -4.421875 L 2.078125 0 L 1.71875 0.890625 C 1.453125 1.46875 1.28125 1.46875 1.140625 1.46875 C 0.984375 1.46875 0.671875 1.4375 0.375 1.3125 L 0.421875 1.96875 C 0.640625 2.015625 0.921875 2.046875 1.140625 2.046875 C 1.5 2.046875 1.859375 1.921875 2.265625 0.90625 Z M 4.453125 -4.421875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-38"> +<path style="stroke:none;" d="M 3.1875 -6.25 L 3.1875 -6.921875 C 2.96875 -6.984375 2.71875 -7.03125 2.5 -7.03125 C 1.65625 -7.03125 1 -6.328125 1 -5.328125 L 1 -4.421875 L 0.265625 -4.421875 L 0.265625 -3.84375 L 1 -3.84375 L 1 0 L 1.75 0 L 1.75 -3.84375 L 2.9375 -3.84375 L 2.9375 -4.421875 L 1.71875 -4.421875 L 1.71875 -5.625 C 1.71875 -6.3125 2.234375 -6.421875 2.484375 -6.421875 C 2.640625 -6.421875 2.890625 -6.40625 3.1875 -6.25 Z M 7.28125 0 L 7.28125 -6.921875 L 6.546875 -6.921875 L 6.546875 0 Z M 5.703125 -3.84375 L 5.703125 -4.421875 L 4.5 -4.421875 L 4.5 -5.625 C 4.5 -6.265625 4.859375 -6.421875 5.109375 -6.421875 C 5.296875 -6.421875 5.515625 -6.359375 5.703125 -6.25 L 5.703125 -6.921875 C 5.640625 -6.9375 5.390625 -7.03125 5.109375 -7.03125 C 4.359375 -7.03125 3.78125 -6.328125 3.78125 -5.328125 L 3.78125 0 L 4.53125 0 L 4.53125 -3.84375 Z M 5.703125 -3.84375 "/> +</symbol> +<symbol overflow="visible" id="glyph0-39"> +<path style="stroke:none;" d="M 4.453125 -4.421875 L 3.703125 -4.421875 L 2.90625 -2.359375 C 2.703125 -1.796875 2.390625 -1 2.3125 -0.53125 L 2.296875 -0.53125 C 2.25 -0.890625 1.984375 -1.578125 1.890625 -1.84375 L 0.921875 -4.421875 L 0.140625 -4.421875 L 1.859375 0 L 2.734375 0 Z M 4.453125 -4.421875 "/> +</symbol> +<symbol overflow="visible" id="glyph0-40"> +<path style="stroke:none;" d="M 4 0 L 4 -0.625 L 2.546875 -0.625 C 2.421875 -0.625 2.296875 -0.609375 2.1875 -0.609375 L 1.328125 -0.609375 L 3.984375 -4.03125 L 3.984375 -4.421875 L 0.421875 -4.421875 L 0.421875 -3.84375 L 1.796875 -3.84375 C 1.921875 -3.84375 2.046875 -3.84375 2.15625 -3.84375 L 2.9375 -3.84375 L 0.28125 -0.40625 L 0.28125 0 Z M 4 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-41"> +<path style="stroke:none;" d="M 1.796875 -6.09375 L 1.796875 -6.921875 L 0.96875 -6.921875 L 0.96875 -6.09375 L 1.21875 -6.09375 L 0.96875 -4.84375 L 1.375 -4.84375 Z M 1.796875 -6.09375 "/> +</symbol> +<symbol overflow="visible" id="glyph0-42"> +<path style="stroke:none;" d="M 4.578125 0 L 2.59375 -2.28125 L 4.421875 -4.421875 L 3.59375 -4.421875 L 2.265625 -2.78125 L 0.890625 -4.421875 L 0.0625 -4.421875 L 1.9375 -2.28125 L 0 0 L 0.8125 0 L 2.265625 -1.875 L 3.765625 0 Z M 4.578125 0 "/> +</symbol> +<symbol overflow="visible" id="glyph0-43"> +<path style="stroke:none;" d="M 4.6875 0 L 2.796875 -2.71875 L 4.46875 -4.421875 L 3.578125 -4.421875 L 1.5625 -2.359375 L 1.5625 -6.921875 L 0.84375 -6.921875 L 0.84375 0 L 1.53125 0 L 1.53125 -1.40625 L 2.328125 -2.234375 L 3.875 0 Z M 4.6875 0 "/> +</symbol> +</g> +<clipPath id="clip1"> + <path d="M 136 335 L 246 335 L 246 411.90625 L 136 411.90625 Z M 136 335 "/> +</clipPath> +</defs> +<g id="surface1"> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -55.623594 -19.702 L 55.626406 -19.702 L 55.626406 19.70425 L -55.623594 19.70425 Z M -55.623594 -19.702 " transform="matrix(1,0,0,-1,191.315,23.423)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="148.074" y="13.958"/> + <use xlink:href="#glyph0-2" x="154.716065" y="13.958"/> + <use xlink:href="#glyph0-3" x="157.096131" y="13.958"/> + <use xlink:href="#glyph0-4" x="159.476196" y="13.958"/> + <use xlink:href="#glyph0-5" x="163.904571" y="13.958"/> + <use xlink:href="#glyph0-6" x="168.332947" y="13.958"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="174.418103" y="13.958"/> + <use xlink:href="#glyph0-8" x="181.060169" y="13.958"/> + <use xlink:href="#glyph0-9" x="186.041469" y="13.958"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="194.50669" y="13.958"/> + <use xlink:href="#glyph0-11" x="199.294715" y="13.958"/> + <use xlink:href="#glyph0-12" x="204.442391" y="13.958"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-13" x="212.917575" y="13.958"/> + <use xlink:href="#glyph0-10" x="219.28268" y="13.958"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="223.791753" y="13.958"/> + <use xlink:href="#glyph0-8" x="227.195973" y="13.958"/> + <use xlink:href="#glyph0-2" x="232.177273" y="13.958"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="151.313" y="25.914"/> + <use xlink:href="#glyph0-3" x="158.120445" y="25.914"/> + <use xlink:href="#glyph0-16" x="160.50051" y="25.914"/> + <use xlink:href="#glyph0-17" x="164.319174" y="25.914"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="172.784396" y="25.914"/> + <use xlink:href="#glyph0-8" x="176.38189" y="25.914"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="184.690699" y="25.914"/> + <use xlink:href="#glyph0-19" x="188.509363" y="25.914"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-5" x="193.926029" y="25.914"/> + <use xlink:href="#glyph0-11" x="198.354405" y="25.914"/> + <use xlink:href="#glyph0-12" x="203.50208" y="25.914"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-20" x="211.977264" y="25.914"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="215.011872" y="25.914"/> + <use xlink:href="#glyph0-8" x="218.416092" y="25.914"/> + <use xlink:href="#glyph0-21" x="223.397392" y="25.914"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="155.2" y="37.869"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-22" x="163.305571" y="37.869"/> + <use xlink:href="#glyph0-23" x="168.286871" y="37.869"/> + <use xlink:href="#glyph0-8" x="171.607406" y="37.869"/> + <use xlink:href="#glyph0-20" x="176.588706" y="37.869"/> + <use xlink:href="#glyph0-23" x="179.633277" y="37.869"/> + <use xlink:href="#glyph0-24" x="182.953811" y="37.869"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-25" x="191.262619" y="37.869"/> + <use xlink:href="#glyph0-26" x="199.979894" y="37.869"/> + <use xlink:href="#glyph0-2" x="205.12757" y="37.869"/> + <use xlink:href="#glyph0-18" x="207.507635" y="37.869"/> + <use xlink:href="#glyph0-3" x="211.10513" y="37.869"/> + <use xlink:href="#glyph0-16" x="213.485195" y="37.869"/> + <use xlink:href="#glyph0-3" x="217.30386" y="37.869"/> + <use xlink:href="#glyph0-27" x="219.683925" y="37.869"/> + <use xlink:href="#glyph0-28" x="224.665225" y="37.869"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -55.623594 -19.705344 L 55.626406 -19.705344 L 55.626406 19.704812 L -55.623594 19.704812 Z M -55.623594 -19.705344 " transform="matrix(1,0,0,-1,191.315,74.697)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="141.128" y="65.232"/> + <use xlink:href="#glyph0-2" x="147.770065" y="65.232"/> + <use xlink:href="#glyph0-3" x="150.150131" y="65.232"/> + <use xlink:href="#glyph0-4" x="152.530196" y="65.232"/> + <use xlink:href="#glyph0-5" x="156.958571" y="65.232"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-26" x="164.704493" y="65.232"/> + <use xlink:href="#glyph0-16" x="169.852168" y="65.232"/> + <use xlink:href="#glyph0-5" x="173.670833" y="65.232"/> + <use xlink:href="#glyph0-16" x="178.099209" y="65.232"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="185.245382" y="65.232"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-20" x="193.350953" y="65.232"/> + <use xlink:href="#glyph0-26" x="196.395523" y="65.232"/> + <use xlink:href="#glyph0-2" x="201.543199" y="65.232"/> + <use xlink:href="#glyph0-2" x="203.923264" y="65.232"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-11" x="209.620875" y="65.232"/> + <use xlink:href="#glyph0-8" x="214.76855" y="65.232"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-12" x="220.028803" y="65.232"/> + <use xlink:href="#glyph0-5" x="225.176479" y="65.232"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="232.9224" y="65.232"/> + <use xlink:href="#glyph0-8" x="236.519895" y="65.232"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-4" x="143.342" y="77.187"/> + <use xlink:href="#glyph0-14" x="147.770376" y="77.187"/> + <use xlink:href="#glyph0-5" x="151.174596" y="77.187"/> + <use xlink:href="#glyph0-10" x="155.602972" y="77.187"/> + <use xlink:href="#glyph0-18" x="160.390997" y="77.187"/> + <use xlink:href="#glyph0-5" x="163.988492" y="77.187"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="171.734414" y="77.187"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-29" x="179.839985" y="77.187"/> + <use xlink:href="#glyph0-30" x="186.20509" y="77.187"/> + <use xlink:href="#glyph0-7" x="191.740311" y="77.187"/> + <use xlink:href="#glyph0-31" x="198.382376" y="77.187"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="208.49043" y="77.187"/> + <use xlink:href="#glyph0-3" x="215.297875" y="77.187"/> + <use xlink:href="#glyph0-18" x="217.67794" y="77.187"/> + <use xlink:href="#glyph0-17" x="221.275435" y="77.187"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="229.740656" y="77.187"/> + <use xlink:href="#glyph0-2" x="234.528682" y="77.187"/> + <use xlink:href="#glyph0-2" x="236.908747" y="77.187"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="145.065" y="89.143"/> + <use xlink:href="#glyph0-11" x="147.445065" y="89.143"/> + <use xlink:href="#glyph0-19" x="152.592741" y="89.143"/> + <use xlink:href="#glyph0-26" x="157.740416" y="89.143"/> + <use xlink:href="#glyph0-18" x="162.888091" y="89.143"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-32" x="169.803132" y="89.143"/> + <use xlink:href="#glyph0-31" x="176.65242" y="89.143"/> + <use xlink:href="#glyph0-33" x="183.432965" y="89.143"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-34" x="189.796078" y="89.143"/> + <use xlink:href="#glyph0-16" x="197.129548" y="89.143"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-35" x="204.275721" y="89.143"/> + <use xlink:href="#glyph0-2" x="209.61667" y="89.143"/> + <use xlink:href="#glyph0-2" x="211.996736" y="89.143"/> + <use xlink:href="#glyph0-5" x="214.376801" y="89.143"/> + <use xlink:href="#glyph0-12" x="218.805176" y="89.143"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="227.270398" y="89.143"/> + <use xlink:href="#glyph0-11" x="229.650463" y="89.143"/> + <use xlink:href="#glyph0-28" x="234.798138" y="89.143"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -55.623594 -6.781125 L 55.626406 -6.781125 L 55.626406 6.781375 L -55.623594 6.781375 Z M -55.623594 -6.781125 " transform="matrix(1,0,0,-1,191.315,113.047)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-29" x="153.512" y="116.506"/> + <use xlink:href="#glyph0-30" x="159.877105" y="116.506"/> + <use xlink:href="#glyph0-7" x="165.412326" y="116.506"/> + <use xlink:href="#glyph0-31" x="172.054391" y="116.506"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-12" x="182.152482" y="116.506"/> + <use xlink:href="#glyph0-3" x="187.300158" y="116.506"/> + <use xlink:href="#glyph0-16" x="189.680223" y="116.506"/> + <use xlink:href="#glyph0-18" x="193.498888" y="116.506"/> + <use xlink:href="#glyph0-14" x="197.096382" y="116.506"/> + <use xlink:href="#glyph0-3" x="200.500603" y="116.506"/> + <use xlink:href="#glyph0-9" x="202.880668" y="116.506"/> + <use xlink:href="#glyph0-26" x="208.028343" y="116.506"/> + <use xlink:href="#glyph0-18" x="213.176019" y="116.506"/> + <use xlink:href="#glyph0-5" x="216.773514" y="116.506"/> + <use xlink:href="#glyph0-12" x="221.201889" y="116.506"/> + <use xlink:href="#glyph0-28" x="226.349565" y="116.506"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -55.625625 -12.75925 L 55.624375 -12.75925 L 55.624375 12.756375 L -55.625625 12.756375 Z M -55.625625 -12.75925 " transform="matrix(1,0,0,-1,65.985,151.397)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="21.555" y="148.879"/> + <use xlink:href="#glyph0-2" x="28.197065" y="148.879"/> + <use xlink:href="#glyph0-3" x="30.577131" y="148.879"/> + <use xlink:href="#glyph0-4" x="32.957196" y="148.879"/> + <use xlink:href="#glyph0-5" x="37.385571" y="148.879"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="45.131493" y="148.879"/> + <use xlink:href="#glyph0-3" x="48.950157" y="148.879"/> + <use xlink:href="#glyph0-27" x="51.330223" y="148.879"/> + <use xlink:href="#glyph0-11" x="56.311523" y="148.879"/> + <use xlink:href="#glyph0-16" x="61.459198" y="148.879"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="68.595408" y="148.879"/> + <use xlink:href="#glyph0-17" x="72.192903" y="148.879"/> + <use xlink:href="#glyph0-5" x="77.340579" y="148.879"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-29" x="85.096463" y="148.879"/> + <use xlink:href="#glyph0-30" x="91.461568" y="148.879"/> + <use xlink:href="#glyph0-7" x="96.996789" y="148.879"/> + <use xlink:href="#glyph0-31" x="103.638854" y="148.879"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="33.773" y="160.834"/> + <use xlink:href="#glyph0-3" x="40.580445" y="160.834"/> + <use xlink:href="#glyph0-18" x="42.96051" y="160.834"/> + <use xlink:href="#glyph0-17" x="46.558005" y="160.834"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-17" x="55.023226" y="160.834"/> + <use xlink:href="#glyph0-5" x="60.170901" y="160.834"/> + <use xlink:href="#glyph0-14" x="64.599277" y="160.834"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="71.321043" y="160.834"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="77.859498" y="160.834"/> + <use xlink:href="#glyph0-2" x="82.647523" y="160.834"/> + <use xlink:href="#glyph0-2" x="85.027588" y="160.834"/> + <use xlink:href="#glyph0-5" x="87.407653" y="160.834"/> + <use xlink:href="#glyph0-18" x="91.836029" y="160.834"/> + <use xlink:href="#glyph0-28" x="95.433524" y="160.834"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -55.623594 -12.75925 L 55.626406 -12.75925 L 55.626406 12.756375 L -55.623594 12.756375 Z M -55.623594 -12.75925 " transform="matrix(1,0,0,-1,191.315,151.397)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-7" x="148.628" y="148.879"/> + <use xlink:href="#glyph0-8" x="155.270065" y="148.879"/> + <use xlink:href="#glyph0-9" x="160.251365" y="148.879"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="168.716587" y="148.879"/> + <use xlink:href="#glyph0-3" x="172.535251" y="148.879"/> + <use xlink:href="#glyph0-27" x="174.915316" y="148.879"/> + <use xlink:href="#glyph0-11" x="179.896616" y="148.879"/> + <use xlink:href="#glyph0-16" x="185.044292" y="148.879"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="192.190465" y="148.879"/> + <use xlink:href="#glyph0-17" x="195.78796" y="148.879"/> + <use xlink:href="#glyph0-5" x="200.935635" y="148.879"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-29" x="208.681557" y="148.879"/> + <use xlink:href="#glyph0-30" x="215.046662" y="148.879"/> + <use xlink:href="#glyph0-7" x="220.581882" y="148.879"/> + <use xlink:href="#glyph0-31" x="227.223948" y="148.879"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="148.988" y="160.834"/> + <use xlink:href="#glyph0-3" x="155.795445" y="160.834"/> + <use xlink:href="#glyph0-18" x="158.17551" y="160.834"/> + <use xlink:href="#glyph0-17" x="161.773005" y="160.834"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-17" x="170.238226" y="160.834"/> + <use xlink:href="#glyph0-3" x="175.385901" y="160.834"/> + <use xlink:href="#glyph0-16" x="177.765966" y="160.834"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-30" x="184.912139" y="160.834"/> + <use xlink:href="#glyph0-29" x="190.44736" y="160.834"/> + <use xlink:href="#glyph0-36" x="196.812465" y="160.834"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="206.772076" y="160.834"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="213.300568" y="160.834"/> + <use xlink:href="#glyph0-2" x="218.088594" y="160.834"/> + <use xlink:href="#glyph0-2" x="220.468659" y="160.834"/> + <use xlink:href="#glyph0-5" x="222.848724" y="160.834"/> + <use xlink:href="#glyph0-18" x="227.2771" y="160.834"/> + <use xlink:href="#glyph0-28" x="230.874594" y="160.834"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -55.624469 -19.704563 L 55.625531 -19.704563 L 55.625531 19.705594 L -55.624469 19.705594 Z M -55.624469 -19.704563 " transform="matrix(1,0,0,-1,316.644,151.397)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-13" x="271.522" y="141.932"/> + <use xlink:href="#glyph0-10" x="277.887105" y="141.932"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="282.396178" y="141.932"/> + <use xlink:href="#glyph0-8" x="285.800398" y="141.932"/> + <use xlink:href="#glyph0-2" x="290.781698" y="141.932"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="296.479309" y="141.932"/> + <use xlink:href="#glyph0-3" x="300.297974" y="141.932"/> + <use xlink:href="#glyph0-27" x="302.678039" y="141.932"/> + <use xlink:href="#glyph0-11" x="307.659339" y="141.932"/> + <use xlink:href="#glyph0-16" x="312.807014" y="141.932"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="319.953187" y="141.932"/> + <use xlink:href="#glyph0-17" x="323.550682" y="141.932"/> + <use xlink:href="#glyph0-5" x="328.698358" y="141.932"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-29" x="336.444279" y="141.932"/> + <use xlink:href="#glyph0-30" x="342.809384" y="141.932"/> + <use xlink:href="#glyph0-7" x="348.344605" y="141.932"/> + <use xlink:href="#glyph0-31" x="354.98667" y="141.932"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="279.824" y="153.888"/> + <use xlink:href="#glyph0-3" x="286.631445" y="153.888"/> + <use xlink:href="#glyph0-18" x="289.01151" y="153.888"/> + <use xlink:href="#glyph0-17" x="292.609005" y="153.888"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="301.074226" y="153.888"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-4" x="309.18976" y="153.888"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="313.608173" y="153.888"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-21" x="318.599435" y="153.888"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-19" x="326.504759" y="153.888"/> + <use xlink:href="#glyph0-2" x="331.652434" y="153.888"/> + <use xlink:href="#glyph0-5" x="334.032499" y="153.888"/> + <use xlink:href="#glyph0-18" x="338.460875" y="153.888"/> + <use xlink:href="#glyph0-5" x="342.05837" y="153.888"/> + <use xlink:href="#glyph0-2" x="346.486745" y="153.888"/> + <use xlink:href="#glyph0-37" x="348.866811" y="153.888"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="267.882" y="165.843"/> + <use xlink:href="#glyph0-38" x="272.8633" y="165.843"/> + <use xlink:href="#glyph0-3" x="280.97186" y="165.843"/> + <use xlink:href="#glyph0-11" x="283.351925" y="165.843"/> + <use xlink:href="#glyph0-5" x="288.499601" y="165.843"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="296.245522" y="165.843"/> + <use xlink:href="#glyph0-3" x="300.064187" y="165.843"/> + <use xlink:href="#glyph0-27" x="302.444252" y="165.843"/> + <use xlink:href="#glyph0-11" x="307.425552" y="165.843"/> + <use xlink:href="#glyph0-3" x="312.573227" y="165.843"/> + <use xlink:href="#glyph0-11" x="314.953292" y="165.843"/> + <use xlink:href="#glyph0-27" x="320.100968" y="165.843"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-21" x="328.409776" y="165.843"/> + <use xlink:href="#glyph0-10" x="336.325062" y="165.843"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-4" x="341.103125" y="165.843"/> + <use xlink:href="#glyph0-17" x="345.531501" y="165.843"/> + <use xlink:href="#glyph0-3" x="350.679176" y="165.843"/> + <use xlink:href="#glyph0-11" x="353.059241" y="165.843"/> + <use xlink:href="#glyph0-5" x="358.206917" y="165.843"/> + <use xlink:href="#glyph0-28" x="362.635292" y="165.843"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -55.623594 -12.759375 L 55.626406 -12.759375 L 55.626406 12.75625 L -55.623594 12.75625 Z M -55.623594 -12.759375 " transform="matrix(1,0,0,-1,191.315,195.725)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-29" x="169.328" y="193.206"/> + <use xlink:href="#glyph0-30" x="175.693105" y="193.206"/> + <use xlink:href="#glyph0-7" x="181.228326" y="193.206"/> + <use xlink:href="#glyph0-31" x="187.870391" y="193.206"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="193.824041" y="193.206"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="200.960251" y="193.206"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="205.469324" y="193.206"/> + <use xlink:href="#glyph0-5" x="208.873544" y="193.206"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="154.84" y="205.161"/> + <use xlink:href="#glyph0-5" x="158.24422" y="205.161"/> + <use xlink:href="#glyph0-18" x="162.672596" y="205.161"/> + <use xlink:href="#glyph0-26" x="166.270091" y="205.161"/> + <use xlink:href="#glyph0-14" x="171.417766" y="205.161"/> + <use xlink:href="#glyph0-11" x="174.821987" y="205.161"/> + <use xlink:href="#glyph0-5" x="179.969662" y="205.161"/> + <use xlink:href="#glyph0-12" x="184.398038" y="205.161"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="192.863259" y="205.161"/> + <use xlink:href="#glyph0-8" x="196.460754" y="205.161"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="204.7596" y="205.161"/> + <use xlink:href="#glyph0-2" x="211.401665" y="205.161"/> + <use xlink:href="#glyph0-3" x="213.78173" y="205.161"/> + <use xlink:href="#glyph0-4" x="216.161796" y="205.161"/> + <use xlink:href="#glyph0-5" x="220.590171" y="205.161"/> + <use xlink:href="#glyph0-28" x="225.018547" y="205.161"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -55.623594 -19.701906 L 55.626406 -19.701906 L 55.626406 19.704344 L -55.623594 19.704344 Z M -55.623594 -19.701906 " transform="matrix(1,0,0,-1,191.315,240.052)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="150.246" y="230.588"/> + <use xlink:href="#glyph0-2" x="156.888065" y="230.588"/> + <use xlink:href="#glyph0-3" x="159.268131" y="230.588"/> + <use xlink:href="#glyph0-4" x="161.648196" y="230.588"/> + <use xlink:href="#glyph0-5" x="166.076571" y="230.588"/> + <use xlink:href="#glyph0-16" x="170.504947" y="230.588"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-4" x="177.641157" y="230.588"/> + <use xlink:href="#glyph0-8" x="182.069533" y="230.588"/> + <use xlink:href="#glyph0-21" x="187.050833" y="230.588"/> + <use xlink:href="#glyph0-9" x="194.966119" y="230.588"/> + <use xlink:href="#glyph0-3" x="200.113794" y="230.588"/> + <use xlink:href="#glyph0-11" x="202.493859" y="230.588"/> + <use xlink:href="#glyph0-5" x="207.641535" y="230.588"/> + <use xlink:href="#glyph0-16" x="212.069911" y="230.588"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="219.206121" y="230.588"/> + <use xlink:href="#glyph0-17" x="222.803616" y="230.588"/> + <use xlink:href="#glyph0-5" x="227.951291" y="230.588"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-29" x="153.304" y="242.543"/> + <use xlink:href="#glyph0-30" x="159.669105" y="242.543"/> + <use xlink:href="#glyph0-7" x="165.204326" y="242.543"/> + <use xlink:href="#glyph0-31" x="171.846391" y="242.543"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="177.800041" y="242.543"/> + <use xlink:href="#glyph0-28" x="181.618705" y="242.543"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="189.367616" y="242.543"/> + <use xlink:href="#glyph0-2" x="196.009681" y="242.543"/> + <use xlink:href="#glyph0-2" x="198.389746" y="242.543"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="204.087357" y="242.543"/> + <use xlink:href="#glyph0-11" x="206.467422" y="242.543"/> + <use xlink:href="#glyph0-19" x="211.615098" y="242.543"/> + <use xlink:href="#glyph0-26" x="216.762773" y="242.543"/> + <use xlink:href="#glyph0-18" x="221.910449" y="242.543"/> + <use xlink:href="#glyph0-16" x="225.507944" y="242.543"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-11" x="143.896" y="254.498"/> + <use xlink:href="#glyph0-8" x="149.043675" y="254.498"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="153.746023" y="254.498"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-17" x="163.871013" y="254.498"/> + <use xlink:href="#glyph0-10" x="169.018688" y="254.498"/> + <use xlink:href="#glyph0-39" x="173.806714" y="254.498"/> + <use xlink:href="#glyph0-5" x="178.400469" y="254.498"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-24" x="186.156353" y="254.498"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="194.455199" y="254.498"/> + <use xlink:href="#glyph0-3" x="198.273863" y="254.498"/> + <use xlink:href="#glyph0-27" x="200.653928" y="254.498"/> + <use xlink:href="#glyph0-11" x="205.635228" y="254.498"/> + <use xlink:href="#glyph0-10" x="210.782904" y="254.498"/> + <use xlink:href="#glyph0-18" x="215.570929" y="254.498"/> + <use xlink:href="#glyph0-26" x="219.168424" y="254.498"/> + <use xlink:href="#glyph0-14" x="224.3161" y="254.498"/> + <use xlink:href="#glyph0-5" x="227.72032" y="254.498"/> + <use xlink:href="#glyph0-16" x="232.148696" y="254.498"/> + <use xlink:href="#glyph0-28" x="235.96736" y="254.498"/> +</g> +<path style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -55.623594 -31.660406 L 55.626406 -31.660406 L 55.626406 31.659906 L -55.623594 31.659906 Z M -55.623594 -31.660406 " transform="matrix(1,0,0,-1,191.315,303.281)"/> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="154.972" y="281.862"/> + <use xlink:href="#glyph0-2" x="161.614065" y="281.862"/> + <use xlink:href="#glyph0-3" x="163.994131" y="281.862"/> + <use xlink:href="#glyph0-4" x="166.374196" y="281.862"/> + <use xlink:href="#glyph0-5" x="170.802571" y="281.862"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-35" x="178.548493" y="281.862"/> + <use xlink:href="#glyph0-11" x="183.889443" y="281.862"/> + <use xlink:href="#glyph0-10" x="189.037118" y="281.862"/> + <use xlink:href="#glyph0-2" x="193.825144" y="281.862"/> + <use xlink:href="#glyph0-3" x="196.205209" y="281.862"/> + <use xlink:href="#glyph0-40" x="198.585274" y="281.862"/> + <use xlink:href="#glyph0-5" x="202.916016" y="281.862"/> + <use xlink:href="#glyph0-16" x="207.344392" y="281.862"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="214.480602" y="281.862"/> + <use xlink:href="#glyph0-17" x="218.078097" y="281.862"/> + <use xlink:href="#glyph0-5" x="223.225773" y="281.862"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-29" x="142.969" y="293.817"/> + <use xlink:href="#glyph0-30" x="149.334105" y="293.817"/> + <use xlink:href="#glyph0-7" x="154.869326" y="293.817"/> + <use xlink:href="#glyph0-31" x="161.511391" y="293.817"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-9" x="171.609482" y="293.817"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-37" x="176.478205" y="293.817"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-4" x="184.399468" y="293.817"/> + <use xlink:href="#glyph0-14" x="188.827844" y="293.817"/> + <use xlink:href="#glyph0-5" x="192.232064" y="293.817"/> + <use xlink:href="#glyph0-10" x="196.66044" y="293.817"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="201.438503" y="293.817"/> + <use xlink:href="#glyph0-3" x="205.035998" y="293.817"/> + <use xlink:href="#glyph0-11" x="207.416063" y="293.817"/> + <use xlink:href="#glyph0-27" x="212.563739" y="293.817"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-5" x="220.872547" y="293.817"/> + <use xlink:href="#glyph0-10" x="225.300923" y="293.817"/> + <use xlink:href="#glyph0-4" x="230.088948" y="293.817"/> + <use xlink:href="#glyph0-17" x="234.517324" y="293.817"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="145.944" y="305.772"/> + <use xlink:href="#glyph0-11" x="148.324065" y="305.772"/> + <use xlink:href="#glyph0-19" x="153.471741" y="305.772"/> + <use xlink:href="#glyph0-26" x="158.619416" y="305.772"/> + <use xlink:href="#glyph0-18" x="163.767091" y="305.772"/> + <use xlink:href="#glyph0-41" x="167.364586" y="305.772"/> + <use xlink:href="#glyph0-16" x="170.132197" y="305.772"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-35" x="177.268407" y="305.772"/> + <use xlink:href="#glyph0-11" x="182.609357" y="305.772"/> + <use xlink:href="#glyph0-10" x="187.757032" y="305.772"/> + <use xlink:href="#glyph0-2" x="192.545058" y="305.772"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="198.242669" y="305.772"/> + <use xlink:href="#glyph0-4" x="202.061333" y="305.772"/> + <use xlink:href="#glyph0-14" x="206.489709" y="305.772"/> + <use xlink:href="#glyph0-3" x="209.893929" y="305.772"/> + <use xlink:href="#glyph0-19" x="212.273995" y="305.772"/> + <use xlink:href="#glyph0-18" x="217.42167" y="305.772"/> + <use xlink:href="#glyph0-30" x="221.019165" y="305.772"/> + <use xlink:href="#glyph0-3" x="226.554385" y="305.772"/> + <use xlink:href="#glyph0-27" x="228.934451" y="305.772"/> + <use xlink:href="#glyph0-28" x="233.915751" y="305.772"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-34" x="155.118" y="317.727"/> + <use xlink:href="#glyph0-11" x="162.45147" y="317.727"/> + <use xlink:href="#glyph0-5" x="167.599145" y="317.727"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="175.345067" y="317.727"/> + <use xlink:href="#glyph0-3" x="179.163731" y="317.727"/> + <use xlink:href="#glyph0-27" x="181.543797" y="317.727"/> + <use xlink:href="#glyph0-11" x="186.525097" y="317.727"/> + <use xlink:href="#glyph0-10" x="191.672772" y="317.727"/> + <use xlink:href="#glyph0-18" x="196.460797" y="317.727"/> + <use xlink:href="#glyph0-26" x="200.058292" y="317.727"/> + <use xlink:href="#glyph0-14" x="205.205968" y="317.727"/> + <use xlink:href="#glyph0-5" x="208.610188" y="317.727"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-20" x="216.35611" y="317.727"/> + <use xlink:href="#glyph0-8" x="219.40068" y="317.727"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="224.103027" y="317.727"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-5" x="144.906" y="329.682"/> + <use xlink:href="#glyph0-10" x="149.334376" y="329.682"/> + <use xlink:href="#glyph0-4" x="154.122401" y="329.682"/> + <use xlink:href="#glyph0-17" x="158.550777" y="329.682"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="167.015998" y="329.682"/> + <use xlink:href="#glyph0-11" x="169.396063" y="329.682"/> + <use xlink:href="#glyph0-19" x="174.543739" y="329.682"/> + <use xlink:href="#glyph0-26" x="179.691414" y="329.682"/> + <use xlink:href="#glyph0-18" x="184.83909" y="329.682"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="191.75413" y="329.682"/> + <use xlink:href="#glyph0-16" x="194.134195" y="329.682"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-12" x="201.280368" y="329.682"/> + <use xlink:href="#glyph0-14" x="206.428044" y="329.682"/> + <use xlink:href="#glyph0-8" x="209.832264" y="329.682"/> + <use xlink:href="#glyph0-19" x="214.813564" y="329.682"/> + <use xlink:href="#glyph0-19" x="219.96124" y="329.682"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-5" x="225.377905" y="329.682"/> + <use xlink:href="#glyph0-12" x="229.806281" y="329.682"/> + <use xlink:href="#glyph0-28" x="234.953956" y="329.682"/> +</g> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;" d="M 230.5 346.804688 L 152.128906 346.804688 C 149.925781 346.804688 148.144531 348.589844 148.144531 350.792969 L 148.144531 404.203125 C 148.144531 406.402344 149.925781 408.1875 152.128906 408.1875 L 230.5 408.1875 C 232.703125 408.1875 234.488281 406.402344 234.488281 404.203125 L 234.488281 350.792969 C 234.488281 348.589844 232.703125 346.804688 230.5 346.804688 Z M 230.5 346.804688 "/> +<g clip-path="url(#clip1)" clip-rule="nonzero"> +<path style="fill:none;stroke-width:0.79701;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 39.185 30.692312 L -39.186094 30.692312 C -41.389219 30.692312 -43.170469 28.907156 -43.170469 26.704031 L -43.170469 -26.706125 C -43.170469 -28.905344 -41.389219 -30.6905 -39.186094 -30.6905 L 39.185 -30.6905 C 41.388125 -30.6905 43.173281 -28.905344 43.173281 -26.706125 L 43.173281 26.704031 C 43.173281 28.907156 41.388125 30.692312 39.185 30.692312 Z M 39.185 30.692312 " transform="matrix(1,0,0,-1,191.315,377.497)"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="154.951" y="357.046"/> + <use xlink:href="#glyph0-2" x="161.593065" y="357.046"/> + <use xlink:href="#glyph0-3" x="163.973131" y="357.046"/> + <use xlink:href="#glyph0-4" x="166.353196" y="357.046"/> + <use xlink:href="#glyph0-5" x="170.781571" y="357.046"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-5" x="178.527493" y="357.046"/> + <use xlink:href="#glyph0-42" x="182.955869" y="357.046"/> + <use xlink:href="#glyph0-18" x="187.549623" y="357.046"/> + <use xlink:href="#glyph0-14" x="191.147118" y="357.046"/> + <use xlink:href="#glyph0-10" x="194.551339" y="357.046"/> + <use xlink:href="#glyph0-4" x="199.339364" y="357.046"/> + <use xlink:href="#glyph0-18" x="203.76774" y="357.046"/> + <use xlink:href="#glyph0-16" x="207.365235" y="357.046"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="214.501445" y="357.046"/> + <use xlink:href="#glyph0-17" x="218.09894" y="357.046"/> + <use xlink:href="#glyph0-5" x="223.246616" y="357.046"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-11" x="154.709" y="369.001"/> + <use xlink:href="#glyph0-5" x="159.856675" y="369.001"/> + <use xlink:href="#glyph0-18" x="164.285051" y="369.001"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="167.603593" y="369.001"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="174.132085" y="369.001"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="178.844395" y="369.001"/> + <use xlink:href="#glyph0-43" x="182.248615" y="369.001"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-16" x="190.436876" y="369.001"/> + <use xlink:href="#glyph0-5" x="194.255541" y="369.001"/> + <use xlink:href="#glyph0-14" x="198.683916" y="369.001"/> + <use xlink:href="#glyph0-3" x="202.088137" y="369.001"/> + <use xlink:href="#glyph0-10" x="204.468202" y="369.001"/> + <use xlink:href="#glyph0-2" x="209.256228" y="369.001"/> + <use xlink:href="#glyph0-3" x="211.636293" y="369.001"/> + <use xlink:href="#glyph0-40" x="214.016358" y="369.001"/> + <use xlink:href="#glyph0-5" x="218.3471" y="369.001"/> + <use xlink:href="#glyph0-12" x="222.775476" y="369.001"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="159.075" y="380.956"/> + <use xlink:href="#glyph0-14" x="162.672495" y="380.956"/> + <use xlink:href="#glyph0-10" x="166.076715" y="380.956"/> + <use xlink:href="#glyph0-11" x="170.864741" y="380.956"/> + <use xlink:href="#glyph0-16" x="176.012416" y="380.956"/> + <use xlink:href="#glyph0-10" x="179.831081" y="380.956"/> + <use xlink:href="#glyph0-4" x="184.619106" y="380.956"/> + <use xlink:href="#glyph0-18" x="189.047482" y="380.956"/> + <use xlink:href="#glyph0-3" x="192.644977" y="380.956"/> + <use xlink:href="#glyph0-8" x="195.025042" y="380.956"/> + <use xlink:href="#glyph0-11" x="200.006342" y="380.956"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-10" x="208.471563" y="380.956"/> + <use xlink:href="#glyph0-11" x="213.259589" y="380.956"/> + <use xlink:href="#glyph0-12" x="218.407264" y="380.956"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-9" x="164.845" y="392.911"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="169.713723" y="392.911"/> + <use xlink:href="#glyph0-8" x="173.117943" y="392.911"/> + <use xlink:href="#glyph0-10" x="178.099243" y="392.911"/> + <use xlink:href="#glyph0-12" x="182.887269" y="392.911"/> + <use xlink:href="#glyph0-4" x="188.034944" y="392.911"/> + <use xlink:href="#glyph0-10" x="192.46332" y="392.911"/> + <use xlink:href="#glyph0-16" x="197.251345" y="392.911"/> + <use xlink:href="#glyph0-18" x="201.07001" y="392.911"/> + <use xlink:href="#glyph0-16" x="204.667505" y="392.911"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-3" x="211.803715" y="392.911"/> + <use xlink:href="#glyph0-18" x="214.18378" y="392.911"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="159.532" y="404.866"/> + <use xlink:href="#glyph0-8" x="163.129495" y="404.866"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-18" x="171.428341" y="404.866"/> + <use xlink:href="#glyph0-17" x="175.025836" y="404.866"/> + <use xlink:href="#glyph0-5" x="180.173511" y="404.866"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-11" x="187.919432" y="404.866"/> + <use xlink:href="#glyph0-5" x="193.067108" y="404.866"/> + <use xlink:href="#glyph0-18" x="197.495484" y="404.866"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-15" x="200.823988" y="404.866"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-8" x="207.35248" y="404.866"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-14" x="212.054827" y="404.866"/> + <use xlink:href="#glyph0-43" x="215.459048" y="404.866"/> + <use xlink:href="#glyph0-28" x="220.329763" y="404.866"/> +</g> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -56.022031 92.906125 L -125.330625 92.906125 L -125.330625 72.913937 " transform="matrix(1,0,0,-1,191.315,205.953)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 65.984375 138.238281 C 66.273438 136.699219 67.140625 134.195312 68.152344 132.460938 L 63.816406 132.460938 C 64.828125 134.195312 65.695312 136.699219 65.984375 138.238281 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 0.00140625 162.429562 L 0.00140625 156.562375 " transform="matrix(1,0,0,-1,191.315,205.953)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 191.316406 54.59375 C 191.605469 53.050781 192.46875 50.546875 193.480469 48.8125 L 189.148438 48.8125 C 190.160156 50.546875 191.027344 53.050781 191.316406 54.59375 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 0.00140625 111.156125 L 0.00140625 105.285031 " transform="matrix(1,0,0,-1,191.315,205.953)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 191.316406 105.867188 C 191.605469 104.324219 192.46875 101.820312 193.480469 100.089844 L 189.148438 100.089844 C 190.160156 101.820312 191.027344 104.324219 191.316406 105.867188 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 0.00140625 85.730344 L 0.00140625 72.913937 " transform="matrix(1,0,0,-1,191.315,205.953)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 191.316406 138.238281 C 191.605469 136.699219 192.46875 134.195312 193.480469 132.460938 L 189.148438 132.460938 C 190.160156 134.195312 191.027344 136.699219 191.316406 138.238281 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 0.00140625 -2.925906 L 0.00140625 -8.797 " transform="matrix(1,0,0,-1,191.315,205.953)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 191.316406 219.949219 C 191.605469 218.410156 192.46875 215.90625 193.480469 214.171875 L 189.148438 214.171875 C 190.160156 215.90625 191.027344 218.410156 191.316406 219.949219 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 0.00140625 -54.20325 L 0.00140625 -60.070438 " transform="matrix(1,0,0,-1,191.315,205.953)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 191.316406 271.226562 C 191.605469 269.683594 192.46875 267.179688 193.480469 265.445312 L 189.148438 265.445312 C 190.160156 267.179688 191.027344 269.683594 191.316406 271.226562 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 0.00140625 -129.386844 L 0.00140625 -135.257938 " transform="matrix(1,0,0,-1,191.315,205.953)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 191.316406 346.410156 C 191.605469 344.867188 192.46875 342.363281 193.480469 340.632812 L 189.148438 340.632812 C 190.160156 342.363281 191.027344 344.867188 191.316406 346.410156 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -125.330625 41.402219 L -125.330625 32.6405 L 0.00140625 32.6405 L 0.00140625 23.386594 M 125.329531 34.453 L 125.329531 32.6405 L 0.00140625 32.6405 L 0.00140625 23.386594 M 56.024844 92.906125 L 125.329531 92.906125 L 125.329531 79.85925 " transform="matrix(1,0,0,-1,191.315,205.953)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 316.644531 131.292969 C 316.933594 129.753906 317.800781 127.25 318.8125 125.515625 L 314.480469 125.515625 C 315.492188 127.25 316.355469 129.753906 316.644531 131.292969 "/> +<path style="fill:none;stroke-width:0.99628;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 0.00140625 41.402219 L 0.00140625 28.585812 " transform="matrix(1,0,0,-1,191.315,205.953)"/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;" d="M 191.316406 182.566406 C 191.605469 181.027344 192.46875 178.523438 193.480469 176.789062 L 189.148438 176.789062 C 190.160156 178.523438 191.027344 181.027344 191.316406 182.566406 "/> +</g> +</svg> diff --git a/bip-0174/multisig-workflow.tex b/bip-0174/multisig-workflow.tex new file mode 100644 index 0000000..2b8744d --- /dev/null +++ b/bip-0174/multisig-workflow.tex @@ -0,0 +1,102 @@ +% using the PGF/TikZ package with pdflatex +\documentclass{standalone} +\usepackage[utf8]{inputenc} +\usepackage[T1]{fontenc} +%~ \usepackage[english]{babel} +\usepackage[none]{hyphenat}% prevent hyphenation +\usepackage{lmodern} +\renewcommand*\familydefault{\sfdefault} +\usepackage{tikz} +\usetikzlibrary{shapes,arrows} +\tikzset{>=latex} +%\pgfdeclarelayer{bg} % declare background layer +%\pgfsetlayers{bg,main} % set order of layers +\newcommand{\h}{\hspace{1em}} +\begin{document} +% \sffamily{} + \tikzstyle{block_center} = + [rectangle, draw=black, thick, fill=white, + text width=10.5em, text centered, + minimum height=1em] + \tikzstyle{block_rounded} = [rectangle, + draw=black, thick, fill=white, + text width=8em, text centered, + minimum height=5em, + rounded corners] + \begin{tikzpicture}[auto] + % outlining the flowchart on a grid + \matrix[column sep=3ex,row sep=2.5ex]{ + \h & + \node [block_center] (R1) + {Alice, Bob and Carol + wish to spend from a + 2-of-3 Multisig.}; + & \h \\ + \h & + \node [block_center] (R2) + {Alice uses a full node + to create a PSBT with + all input UTXOs filled in.}; + & \h \\ + \h & + \node [block_center] (R3) + {PSBT distributed.}; + & \h \\ + \node [block_center] (R4C1) + {Alice signs the + PSBT with her wallet.}; + & + \node [block_center] (R4C2) + {Bob signs the PSBT + with his SPV wallet.}; + & + \node [block_center] (R4C3) + {Carol signs the PSBT + with a completely + offline signing machine.}; + \\ + %~ \h & \node (blind) & \h \\ + \h & + \node [block_center] (R5) + {PSBTs are returned + to Alice.}; + & \h \\ + \h & + \node [block_center] (R6) + {Alices combines the + PSBTs. All inputs now + have 3 signatures.}; + & \h \\ + \h & + \node [block_center] (R7) + {Alice finalizes the PSBT + by creating each input's + final scriptSig. One signature + for each input is dropped.}; + & \h \\ + \h & + \node [block_rounded] (stop) + {Alice extracts the network + serialized transaction and + broadcasts it to the network.}; + & \h \\ + };% end matrix + % connecting nodes with paths +% \begin{pgfonlayer}{bg} + \draw[line width = 1pt, ->] + (R1) edge (R2) + (R2) edge (R3) + (R3) -| (R4C1) + (R3) edge (R4C2) + (R5) edge (R6) + (R6) edge (R7) + (R7) edge (stop); + % circumvent missing arrow + \draw[line width = 1pt, ->] + (R4C1) |-+(0,-2.2em)-| (R5) + (R4C2) edge (R5) + (R4C3) |-+(0,-2.2em)-| (R5) + (R3) -| (R4C3); +% \end{pgfonlayer} + \end{tikzpicture} +\end{document} 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-0176.mediawiki b/bip-0176.mediawiki new file mode 100644 index 0000000..8a49bfa --- /dev/null +++ b/bip-0176.mediawiki @@ -0,0 +1,57 @@ +<pre> + BIP: 176 + Title: Bits Denomination + Author: Jimmy Song <jaejoon@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0176 + Status: Draft + Type: Informational + Created: 2017-12-12 + License: BSD-2-Clause +</pre> + +== Abstract == +Bits is presented here as the standard term for 100 (one hundred) satoshis or 1/1,000,000 (one one-millionth) of a bitcoin. + +== Motivation == +The bitcoin price has grown over the years and once the price is past $10,000 USD or so, bitcoin amounts under $10 USD start having enough decimal places that it's difficult to tell whether the user is off by a factor of 10 or not. Switching the denomination to "bits" makes comprehension easier. For example, when BTC is $15,000 USD, $10.05 is a somewhat confusing 0.00067 BTC, versus 670 bits, which is a lot clearer. + +Additonally, reverse comparisons are easier as 59 bits being $1 is easier to comprehend for most people than 0.000059 BTC being $1. Similar comparisons can be made to other currencies: 1 yen being 0.8 bits, 1 won being 0.07 bits and so on. + +Potential benefits of utilizing "bits" include: + +# Reduce user error on small bitcoin amounts. +# Reduce unit bias for users that want a "whole" bitcoin. +# Allow easier comparisons of prices for most users. +# Allow easier bi-directional comparisons to fiat currencies. +# Allows all UTXO amounts to need at most 2 decimal places, which can be easier to handle. + +== Specification == +Definition: 1 bit = 100 satoshis. +Plural of "bit" is "bits". The terms "bit" and "bits" are not proper nouns and thus should not be capitalized unless used at the start of a sentence, etc. + +All bitcoin-denominated items are encouraged to also show the denomination in bits, either as the default or as an option. + +== Rationale == +As bitcoin grows in price versus fiat currencies, it's important to give users the ability to quickly and accurately calculate prices for transactions, savings and other economic activities. "Bits" have been used as a denomination within the Bitcoin ecosystem for some time. The idea of this BIP is to formalize this name. Additionally, "bits" is likely the only other denomination that will be needed for Bitcoin as 0.01 bit = 1 satoshi, meaning that two decimal places will be sufficient to describe any current utxo. + +Existing terms used in bitcoin such as satoshi, milli-bitcoin (mBTC) and bitcoin (BTC) do not conflict as they operate at different orders of magnitude. + +The term micro-bitcoin (µBTC) can continue to exist in tandem with the term "bits". + +== Backwards Compatibility == +Software such as the Bitcoin Core GUI currently use the µBTC denomination and can continue to do so. There is no obligation to switch to "bits". + +The term "bit" has many different definitions, but the ones of particular note are these: + +* 1 bit = 1/8 dollar (e.g. That candy cost me 2 bits) +* bit meaning some amount of data (e.g. The first bit of the version field is 0) +* bit meaning strength of a cryptographic algorithm (e.g. 256-bit ECDSA is used in Bitcoin) + +The first is a bit dated and isn't likely to confuse people dealing with Bitcoin. The second and third are computer science terms and context should be sufficient to figure out what the user of the word means. + +== Copyright == +This BIP is licensed under the BSD 2-clause license. + +== Credit == +It's hard to ascertain exactly who invented the term "bits", but the term has been around for a while and the author of this BIP does not take any credit for inventing the term.
\ No newline at end of file diff --git a/bip-0178.mediawiki b/bip-0178.mediawiki new file mode 100644 index 0000000..5522664 --- /dev/null +++ b/bip-0178.mediawiki @@ -0,0 +1,75 @@ +<pre> + BIP: 178 + Layer: Applications + Title: Version Extended WIF + Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> + Comments-Summary: Discouraged for implementation (one person) + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0178 + Status: Draft + Type: Standards Track + Created: 2018-04-04 + License: CC0-1.0 +</pre> + +== Abstract == + +An extension to the Wallet Import Format (WIF) to specify what kind of bitcoin address the private key corresponds to. + +== Motivation == + +There are several types of bitcoin addresses which can all be associated with a given private key: P2PKH (legacy <code>1...</code> format), P2SH-P2WPKH (SegWit public key inside P2SH), P2WPKH (bech32), etc. + +While private keys have a 1-byte suffix indicating whether the corresponding public key is compressed (<code>0x01</code>) or not (through suffix absence), there is no way of knowing what kind of bitcoin address were associated with the private key. As a result, when importing a private key, the wallet has to assume all kinds, and keep track of each possible alternative. + +By extending the suffix, we can specify what kind of bitcoin address was associated with a given private key. + +== Specification == + +Currently, private keys are stored as a uint256 (private key data) followed by an optional uint8 (compressed flag). The latter is extended to specify the address types: + +{|class="wikitable" style="text-align: center;" +|- +!Value +!Type +!Compr +!Clarification +|- +|No suffix||P2PKH_UNCOMPRESSED||No||Uncompressed legacy public key. Unknown public key format +|- +|<code>0x01</code>||P2PKH_COMPRESSED||Yes||Compressed legacy public key. Unknown public key format +|- +|<code>0x10</code>||P2PKH||Yes||Compressed legacy public key. Legacy public key format (<code>1...</code>) +|- +|<code>0x11</code>||P2WPKH||Yes||Bech32 format (native Segwit) +|- +|<code>0x12</code>||P2WPKH_P2SH||Yes||Segwit nested in BIP16 P2SH (<code>3...</code>) +|} + +When a wallet imports a private key, it will have two outcomes: + +* the key is using one of the legacy types, in which case all types must be accounted for +* the key is using one of the extended types, in which case the wallet need only track the specific corresponding address + +Note: the difference between `0x01` and `0x10` is that the former can correspond to any of the types above, whereas the latter *only* corresponds to a P2PKH (legacy non-segwit). + +== Compatibility == + +This proposal is not backwards compatible, in that software that does not recognize the new types will not understand the compressed flag. It would be trivial to change this, by keeping the 'uncompressed' state as it is (no suffix) and changing 'compressed' to be 'anything not 0', as opposed to 'the value 1'. + +The proposal ''is'' backwards compatible in that new wallet software will always understand the old WIF format, however. It will, as it does today, assume that any kind of bitcoin address is possible, and will have to track all of them, as it has to today. + +== Acknowledgements == + +This BIP is based on the initial proposal by Thomas Voegtlin (thomasv at electrum dot org) on the Bitcoin Dev mailing list<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html</ref> and the Electrum 3.0 implementation<ref>https://github.com/spesmilo/electrum/blob/82e88cb89df35288b80dfdbe071da74247351251/RELEASE-NOTES#L95-L108</ref> + +== Reference implementation == + +There is a partial implementation which adds, but does not use, the types described in this BIP here: https://github.com/bitcoin/bitcoin/pull/12869 + +== References == + +<references/> + +== Copyright == + +This document is licensed under the Creative Commons CC0 1.0 Universal 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-0197.mediawiki b/bip-0197.mediawiki new file mode 100644 index 0000000..8a34b04 --- /dev/null +++ b/bip-0197.mediawiki @@ -0,0 +1,155 @@ +<pre> + BIP: 197 + Layer: Applications + Title: Hashed Time-Locked Collateral Contract + Author: Matthew Black <matthew@atomicloans.io> + Tony Cai <tony@atomicloans.io> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0197 + Status: Draft + Type: Standards Track + Created: 2019-03-19 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This BIP describes a script for generalized debt agreement contract based on Hashed Time-Lock Contract (BIP 199) transactions according to the Atomic Loans specification (https://arxiv.org/pdf/1901.05117.pdf). For more details visit https://atomicloans.io. + +==Summary== + +A Hashed Time-Locked Collateral Contract (HTLCC) consists of two scripts that permit a designated party (the "borrower") to lock funds on the Bitcoin chain for a specified amount of time as collateral in a debt agreement where the loan principal is denominated in a currency on another blockchain. We denote the blockchain on which the loan principal is issued the principal blockchain. + +The purpose of each script is to enable the creation of a debt agreement between two parties (the "borrower" and the "lender"), where the collateral is locked in a P2SH, and can only be spent once the borrower repays the principal and interest in the debt agreement on the principal blockchain. In the case that the borrower does not repay, the borrower or lender can opt for liquidation of the collateral, which will involve the atomic swapping of collateral for the loan currency. In the case that at least one of the two parties don't opt for liquidation, then each party will be entitled to a percentage of the collateral, decided when the funds are initially locked in the P2SH. + +These funds are locked into two scripts. Refundable Collateral and Seizable Collateral scripts. The funds sent to these scripts represent the percentage of collateral that each party is entitled to in the case that repayment fails, and the parties don't opt for liquidation. + +The Refundable Collateral script takes the following form: + + OP_IF + OP_SIZE <secret b2 length> OP_EQUALVERIFY [HASHOP] <secret hash b2> OP_EQUALVERIFY OP_DUP OP_HASH160 <borrower pubkey hash> OP_EQUALVERIFY OP_CHECKSIG + OP_ELSE + OP_IF + <loan expiration num> [TIMEOUTOP] OP_DROP OP_SIZE OP_PUSHDATA(1) <secret a2 length> OP_EQUALVERIFY [HASHOP] <secret hash a2> OP_EQUALVERIFY OP_SIZE <secret b3 length> OP_EQUALVERIFY [HASHOP] <secret hash b3> OP_EQUALVERIFY OP_2 <borrower pubkey> <lender pubkey> OP_2 OP_CHECKMULTISIG + OP_ELSE + <liquidation expiration num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <borrower pubkey hash> OP_EQUALVERIFY OP_CHECKSIG + OP_ENDIF + OP_ENDIF + +The Seizable Collateral script takes the following form: + + OP_IF + OP_SIZE <secret b2 length> OP_EQUALVERIFY [HASHOP] <secret hash b2> OP_EQUALVERIFY OP_DUP OP_HASH160 <borrower pubkey hash> OP_EQUALVERIFY OP_CHECKSIG + OP_ELSE + OP_IF + <loan expiration num> [TIMEOUTOP] OP_DROP OP_SIZE <secret a2 length> OP_EQUALVERIFY [HASHOP] <secret hash a2> OP_EQUALVERIFY OP_SIZE <secret b3 length> OP_EQUALVERIFY [HASHOP] <secret hash b3> OP_EQUALVERIFY OP_2 <borrower pubkey> <lender pubkey> OP_2 OP_CHECKMULTISIG + OP_ELSE + OP_IF + <bidding expiration num> [TIMEOUTOP] OP_DROP OP_SIZE <secret a1 length> OP_EQUALVERIFY [HASHOP] <secret hash a1> OP_EQUALVERIFY OP_DUP OP_HASH160 <lender pubkey hash> OP_EQUALVERIFY OP_CHECKSIG + OP_ELSE + <seizure expiration num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <borrower pubkey hash> OP_EQUALVERIFY OP_CHECKSIG + OP_ENDIF + OP_ENDIF + OP_ENDIF + +[HASHOP] is either OP_SHA256 or OP_HASH160. + +[TIMEOUTOP] is either OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY. + +===Interaction=== + +* Alice (the "borrower") and Bob (the "lender") exchange public keys as well as two secret hashes A1, A2 created by Alice and three hashes B1, B2, B3 created by Bob. They then mutually agree upon a timeout threshold for the Loan Period, Liquidation Period, and Seizure Period. Alice constructs the script and P2SH address for the Refundable Collateral Contract and Seizable Collateral Contract. Bob constructs the script for the blockchain on which the loan principal will be issued - the principal blockchain. + +* Bob sends loan principal funds to the loan script on the principal blockchain + +* Alice sends funds to the Refundable Collateral P2SH address and the Seizable Collateral P2SH address. The amount of funds she sends to the two addresses will be determined beforehand off-chain between Alice and Bob. + +* Either +** Bob accepts locking of collateral by Alice and reveals B1, allowing Alice to withdraw the loan amount on the principal blockchain. +** Bob doesn't accept locking of collateral by Alice, and recovers the funds after the approve expiration while revealing B2, which allows Alice to refund the Refundable and Seizable collateral. + +** If Bob accepts the locking of collateral by Alice + +*** Either +**** Alice repays the loan by the end of the Loan Period and Bob reveals the secret to Alice by revealing it in the loan repayment acceptance transaction; OR +**** Alice defaults on the loan and Alice and Bob both opt for collateral liquidation, where any third-party is able to bid on the collateral. The winning bidder, Charlie, will subsequently receive the liquidated collateral by way of an Atomic Swap between the collateral funds (ie. BTC locked in both the Refundable Collateral P2SH and the Seizable Collateral P2SH) and the bid funds (ie. funds denominated in the loan currency, put forth by Charlie as part of his bid). This is done by both Alice and Bob signing a multisig and revealing A2 and B2; OR +**** Alice defaults on the loan and at least one of Alice or Bob opts out of collateral liquidation, then Alice recovers the Refundable Collateral funds and Bob spends the Seizable Collateral funds. +**** Alice defaults on the loan and at least one of Alice or Bob opts out of collateral liquidation. But Bob doesn't spend the Seizable Collateral funds, so Alice recovers both the Refundable Collateral funds and the Seizable Collateral funds. + +==Compatibility== + +BIP 197 is compatible with [ERC 1850](https://github.com/ethereum/EIPs/pull/1850) for [atomic loans](https://arxiv.org/pdf/1901.05117.pdf) with Ethereum. Can be extended in the future to be compatible with other HTLC and smart contract compatible chains. + +==Motivation== + +In many different protocols, the revealing of secrets is used as a settlement mechanism. HTLCC transactions are a safe way of exchanging secrets to advance the state of a debt agreement, due to the ability to recover a percentage of collateral funds from an uncooperative counterparty, and ensure principal + interest + liquidation fee is paid with a cooperative party. + +==Definitions== + +borrower: entity that locks collateral on the Bitcoin chain and receives loan amount on principal blockchain from lender following the approval of the borrower’s borrow request + +lender: entity that contributes funds to the Hashed Time-Locked Principal Contract (HTLPC) on the principal blockchain, to be borrowed by the borrower upon the locking of collateral on the Bitcoin chain and the lender’s approval + +repay: when the borrower pays back the principal + interest before loanExpiration + +default: when the borrower fails to pay back the principal + interest before the loanExpiration + +secret: random number chosen by the borrower or lender, revealed to allow the parties to change the state of the debt agreement + +secretHash: hash of the secret, used in the construction of HTLCC + +SecretA1: secret generated by the borrower, used to prove that the borrower has withdrawn the loan + +SecretA2: secret generated by the borrower, used to allow the bidder to withdraw the liquidated collateral funds + +SecretB1: secret generated by the lender, used to accept the locking of collateral by borrower, enabling borrower to withdraw the loan amount + +SecretB2: secret generated by the lender, used to refund themselves in the event they aren't satisfied with borrower’slocking of collateral. Also used to accept borrower’s repayment of principal plus interest + +SecretB3: secret generated by the lender, used to allow the bidder to withdraw the liquidated collateral funds + +SecretC: secret generated by the bidder, used to accept the signatures of the borrower and lender for authorizing the liquidation of collateral + +loan expiration num: timestamp before which the borrower must repay the loan; or otherwise risk the liquidation or seizure of their collateral + +bidding expiration num: timestamp that determines the amount of time allocated to bidding before seizure period occurs + +seizure expiration num: timestamp that determines the amount of time during which the lender can seize funds within the Seizable Collateral P2SH, after which the borrower can refund their corresponding amount of the collateral they are entitled to (ie. either just the funds within the Refundable Collateral P2SH, or both the Refundable Collateral and Seizable Collateral in the event where the lender failed to seize). + +===Approve Period=== +During this time, the lender deploys the HTLPC on the principal blockchain. Following this, the borrower locks their collateral on the Bitcoin blockchain in a HTLCC. The lender then either reveals secretB1 to signify that they are satisfied with the collateral, and the borrower can withdraw the loan by revealing secretA1. If the lender is not satisfied with the collateral locked by the borrower, the lender can refunds their loan amount by revealing secretB2, which will subsequently allow the borrower to refund the collateral amount they deposited. + +===Loan Period=== +Once the borrower has withdrawn the loan amount, the Loan Period begins. Once the Loan Period is finished, the borrower is expected to repay the loan. If they do, the lender can then accept the repayment by revealing secretB2, enabling the borrower to refund their collateral amount. In the case that the borrower defaults or does not repay the full principal plus interest amount, the lender can choose to not accept the loan repayment, and the parties can opt for liquidation of the collateral in the Bidding Period. + +===Bidding Period=== +In the case of a default or the lender not accepting the borrower repayment, the lender and borrower can opt for liquidation of the collateral through the process of third party bidders bidding on the collateral. The Bidding Period can be initiated by either the lender or the borrower. Once the bidding timeout occurs, the lender and borrower must each provide a signature, followed by secretC revealed by the winning bidder once they have checked that the signature is proper. Finally, the lender and borrower must each reveal secretA2 and secretB3 to allow the collateral to be withdrawn by the winning bidder. + +===Seizure Period=== +In the case that either the lender or borrower don’t accept the bid, the lender can seize a percentage of the collateral. The amount is dependent on the amount of collateral locked in the Seizable Collateral and Refundable Collateral script as described in this BIP. During this period, the borrower can also refund the funds locked in the Refundable Collateral script. + +===Refund Period=== +In the case that the lender does not seize the collateral locked in the Seizable Collateral script, then the borrower can refund the funds locked in the Refundable Collateral script. + +==Rationale== + +The rational for the following script checking the length of secrets pushed to the stack that are used with OP_SHA256 in the following script + + OP_SIZE <secret b2 length> OP_EQUALVERIFY + +is to ensure that the secret size is exactly a certain number of bytes long. + +This is especially important when this script is used alongside the HTLPC on other chains like Ethereum where the sha256 opcode only takes up 32 bytes and disregards the rest, there is a need to ensure that the length on the Bitcoin side is 32 bytes. + +==Backwards Compatibility== + +As this is a new standard for collateralized debt, there is no need for backward compatibility. Once this is accepted as a standard there are certain aspects of the contract that can be modified while still retaining backwards compatibility, such as removing the need to verify the size of the hash if being used with two blockchains with the same maximum block size, which would be backward compatible with the current script. + +==Implementation== + +https://github.com/AtomicLoans/chainabstractionlayer/blob/bitcoin-collateral-provider/src/providers/bitcoin/BitcoinCollateralProvider.js + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. diff --git a/bip-0199.mediawiki b/bip-0199.mediawiki new file mode 100644 index 0000000..e463c7f --- /dev/null +++ b/bip-0199.mediawiki @@ -0,0 +1,80 @@ +<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/bip-0301.mediawiki b/bip-0301.mediawiki new file mode 100644 index 0000000..d6056f2 --- /dev/null +++ b/bip-0301.mediawiki @@ -0,0 +1,226 @@ +<pre> + BIP: 301 + Layer: Consensus (soft fork) + Title: Blind Merged Mining (Consensus layer) + Author: Paul Sztorc <truthcoin@gmail.com> + CryptAxe <cryptaxe@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0301 + Status: Draft + Type: Standards Track + Created: 2019-07-23 + License: BSD-2-Clause +</pre> + +==Abstract== + + +Blind Merged Mining (BMM) is a way of mining optional extension blocks (ie, "asymmetric sidechains"). BMM produces weak guarantees that the block is valid, for *any* arbitrary set of rules; and yet it does so without requiring miners to actually do any validation on the block whatsoever. + +BMM actually is a process that spans two or more chains. Here we focus on the modifications to mainchain Bitcoin. For an explanation of the "whole picture", please see [http://www.truthcoin.info/blog/blind-merged-mining/ this post]. + +Our goal here, is to allow mainchain miners to trustlessly "sell" the act of finding a sidechain block. + + +==Motivation== + +Regular "Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin). However, traditional MM has two drawbacks: + +# Miners must run a full node of the other chain. (This is because [while miners can effortlessly create the block] miners will not create a valid payment to themselves, unless the block that they MM is a valid one. Therefore, miners must assemble a *valid* block first, then MM it.) +# Miners are paid on the other chain, not on the regular BTC mainchain. For example, miners who MM Namecoin will earn NMC (and they will need to sell the NMC for BTC, before selling the BTC in order to pay for electricity). + +BMM addresses both shortcomings. + + +==Specification== + +Note: This document uses the notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain counterpart. We also use "Simon" to refer to a Sidechain Full Node, and "Mary" to refer to a mainchain miner. + + +=== BMM Request === + +To buy the right to find a sidechain block, users broadcast BMM Requests. + +Here, these can take two forms. The first does not require the Lightning Network, but it does have new requirements for Immediate Expiration (see below). The second inherits Immediate Expiration from the Lightning Network itself, but requires extra preparation and a different/larger message. + +Both forms require that certain Critical Data will be committed to within the coinbase of the block that the transaction is included in (see BMM Accept). For the OnChain (non-Lightning) version, we have created a new extended serialization transaction type (very similar to how SegWit handles witness data (the witness stack)). + +==== Immediate Expiration ("Fill-or-Kill") ==== + +We would like to make special guarantees to the counterparties of this transaction. Specifically, instead of Simon making a "payment" to Mary, we prefer that Simon give Mary an "offer" (which she can either accept or decline). + +Crucially, we want Simon to safely make many offers to several different Mary's, in realtime (ie, quickly and off-chain). However, we ultimately want only one offer to be accepted, at most. In other words, we want Simon's offers to *immediately expire*. If only one offer can become a bona fide transaction, then Simon will feel comfortable making multiple offers all day long. Because all of the Simons are making many offers, the Marys collectively gain access to a large set of offers to choose from. + +==== OnChain BMM Request ==== + +OnChain BMMRs do not require the Lightning network, but they do have new requirements for validation. + +===== Structure ===== + +The following data is required: + +<pre> + 32-bytes - h* sideHeaderHash + ?~?-bytes - critical data extended serialization + 3-bytes - 0x00bf00 identifying bytes + 1-byte - nSidechain + 2-bytes - prevSideBlockRef + 4-bytes - prevMainHeaderBytes +</pre> + +sideHeaderHash comes from side:chain (side:nodes build side:blocks/headers). The identifying bytes are given here. nSidechain identifies which sidechain we are BMMing. By the time Blind Merged Mining can take place, it is known globally. + +prevBlockRef, is a little more complicated (next section). + +To qualify for inclusion in a block, BMM requests are subject to the following requirements: + +# Requests must match a corresponding "BMM Accept" (see last section of BIP). +# At most, only one Request is allowed in a main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must choose one single Request to include. +# The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only be valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about). + +===== prevBlockRef ===== + +prevBlockRef is an integer that counts the number of "skips" one must take in the side:chain in order to find the current side:block's parent block. This value is zero unless the sidechain is reorganizing (or skipping over invalid sidechain blocks). If a side:node wants to orphan the most-recent N blocks, the value of the current block will be equal to N; in the block after that it will be back to zero. + +<img src="bip-0301/bmm-dots-examples.png?raw=true" align="middle"></img> + +Above: Three blockchains, with different max length (small number), reorganization histories, and prevBlockRef numbers (larger numbers beneath blocks). The ordering given via each side:block's "prevSideBlockRef" will be isomorphic to an ordering given by each side:block's "prevSideHeaderHash" ("prevSideHeaderHash is the sidechain's equivalent of the mainchain's "prevBlockHash"). One can freely convert from one to the other. + +===== Extended Serialization ===== + +To impose new requirements at the transaction level, we borrow the dummy vin & "flag" trick from SegWit style transactions. Unless all of the requirements for sidechain critical data transactions are met by the block it is included in, the transaction is invalid. With SegWit, this extra data is the SegWit signature stack, and the extra requirements are the signatures' locations and validity. In the sidechain BMM critical data transactions, the extra data is the (nSidechain, h\*) pair, which must meet the first two requirements (above) as well as the main:blocknumber, which must meet the third requirement (above). + +<img src="bip-0301/witness-vs-critical.png?raw=true" align="middle"></img> + +Above: A chart showing normal txns, SegWit txns, and CriticalData txns. The specific SegWit txn can be seen [http://srv1.yogh.io/#tx:id:D4A99AE93DF6EE3D4E42CE69338DFC1D06CCD9B198666E98FF0588057378D3D9 here]. + +These types of transactions have slightly different mempool behavior, and should probably be kept in a second mempool. These txns are received, checked immediately, and if valid they are evaluated for inclusion in a block. If they are not able to be included in the specific requested block (if the block height requested has been surpassed by the chain tip), they are discarded. In fact, after any main:block is found, everything in this "second mempool" can be discarded as new payments will be created immediately for the next block height. (This includes cases where the blockchain reorganizes.) There is no re-evaluation of the txns in this mempool ever -- they are evaluated once and then either included or discarded. They never need to be rescanned. + +Interestingly, these payments will *always* be directed to main:miners from non-main:miners. Therefore, non-mining full nodes do not need to keep them in any mempool at all. Non-miner nodes can just wait for a block to be found, and check the txn then. These transactions more resemble a stock market's pit trade-offers (in contrast, regular Bitcoin txns are more like paper checks). + +==== Lightning BMM Request ==== + +Lightning BMMRs require Simons to have a LN-channel pathways open with Marys. This may not always be practical (or even possible), especially today. + +LN txns cannot make use of prevSideBlockRef, as no one knows for sure when (or if) they will be broadcast on-chain. Instead, they must use prevSideBlockHash. But they otherwise require the same data: + +<pre> + 4-bytes - Message header (0xD0520C6E) + 1-byte - sidechain number + 32-bytes - h* side:block hash + 32-bytes - prevSideBlockHash +</pre> + +Notice that, in OnChain BMMRs, Simon could reuse the same h\* all he wanted, because only one OnChain BMMR could be included per main:block per sidechain. However, on the LN no such rule can be enforced, as the goal is to push everything off-chain and include *zero* txns. So, we will never know what the Requests were, or how many had an effect on anything. + +Therefore, Simon will need to ensure that he '''gives each Mary a different h\*'''. Simon can easily do this, as he controls the side:block's contents and can simply increment a side:nonce -- this changes the side:block, and changes its hash (ie, changes h\*). + +With a unique h\* per Mary (or, more precisely, per channel), and at most 1 h\* making it into a block (per sidechain), Simon can ensure that he is charged, at most, one time. + +That's probably confusing, so here is an example, in which: Simon starts with 13 BTC, Mary starts with 40 BTC, the side:block's tx-fees currently total 7.1 BTC, and Simon is keeping 0.1 BTC for himself and paying 7 BTC to Mary. + +We start with (I): + +<pre> + Simon 13 in, Mary 40 in ; 53 in total + Simon's version [signed by Mary] + 13 ; to Simon if TimeLock=over; OR to Mary if SimonSig + 40 ; to Mary + Mary's version [signed by Simon] + 40 ; to me if TimeLock=over; OR to Simon if MarySig + 13 ; to Simon +</pre> + + +And both parties move, from there to (II): + +<pre> + Simon 13 in, Mary 40 in ; 53 in total + Simon's version [signed by Mary] + 6 ; to Simon if TimeLock=over; OR to Mary if SimonSig + 40 ; to Mary + 7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over + Mary's version [signed by Simon] + 40 ; to Mary if TimeLock=over; OR to Simon if MarySig + 6 ; to Simon + 7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over +</pre> + + +From here, if the h\* side:block in question is BMMed, they can proceed to (III): + +<pre> + Simon 13 in, Mary 40 in ; 53 in total + Simon's version [signed by Mary] + 6 ; to Simon if TimeLock=over; OR to Mary if SimonSig + 47 ; to Mary + Mary's version [signed by Simon] + 47 ; to me if TimeLock=over; OR to Simon if MarySig + 6 ; to Simon +</pre> + +If Simon proceeds immediately, he removes Mary's incentive to care about blocks being built on this side:block. If Simon's side:block is orphaned, he loses his 7 BTC. Simon can either play it safe, and wait for (for example) 100 side:blocks before moving on (ie, before moving on to the third LN txn, above); or else Simon can take the risk if he feels comfortable with it. + +If the h\* side:block is not found, then (II) and (III) are basically equivalent to each other. Simon and Mary could jointly reconstruct (I) and go back there, or they could proceed to a new version of II (with a different h\*, trying again with new side:block in the next main:block). + +Now that we have described Requests, we can describe how they are accepted. + +=== BMM Accept === + +For each BMM Request that a main:miner "accepts", main:miners must place an OP Return output into their main:coinbase txn. (We've changed the tx-standardness policy to allow multiple OP_RETURNs.) + +The following data is required in the "accept" OP_RETURN output: + 1-byte - OP_RETURN (0x6a) + 1-byte - Push the following 36 bytes (0x24) + 4-bytes - Message header (0xD3407053) + 32-bytes - h* + ~5-bytes - BMM identifier bytes + + +[https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L3377-L3470 Link to code]. + +If these OP_RETURN outputs are not present, then no BMM Requests have been accepted. (And, if they are not accepted, then they cannot be included in a main:block.) + + +==Backward compatibility== + +As a soft fork, older software will continue to operate without modification. As stated above, BMM asks nodes to track a set of ordered hashes, and to allow miners to "sell" the act of finding a sidechain block. Non-upgraded nodes will notice that this activity (specifically: data in coinbases, and new txns that have OP Returns and interesting message headers) is now taking place, but they will not understand any of it. Much like P2SH or a new OP Code, these old users will not be directly affected by the fork, as they will have no expectations of receiving payments of this kind. + +(As a matter of fact, the only people receiving money here all happen to be miners. So there is less reason than ever to expect compatibility problems.) + + +==Deployment== + +This BIP will be deployed by "version bits" BIP9 with the name "blindmm" and using bit 4. + +<pre> +// Deployment of Drivechains (BIPX, BIPY) +consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].bit = 4; +consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1579072881; // January 15th, 2020. +consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1610695281; // January 15th, 2021. +</pre> + + +==Reference Implementation== + +See: https://github.com/DriveNetTESTDRIVE/DriveNet + +Also, for interest, see an example sidechain here: https://github.com/drivechain-project/bitcoin/tree/sidechainBMM + + +==References== + +* http://www.drivechain.info/literature/index.html +* http://www.truthcoin.info/blog/blind-merged-mining/ +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014789.html +* http://www.truthcoin.info/images/bmm-outline.txt + + +==Thanks== + +Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Chris Stewart, Ben Goldhaber. + + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. diff --git a/bip-0301/bmm-dots-examples.png b/bip-0301/bmm-dots-examples.png Binary files differnew file mode 100644 index 0000000..70f11f6 --- /dev/null +++ b/bip-0301/bmm-dots-examples.png diff --git a/bip-0301/images.txt b/bip-0301/images.txt new file mode 100644 index 0000000..2fbbf63 --- /dev/null +++ b/bip-0301/images.txt @@ -0,0 +1 @@ +Images used as reference in the documentation. diff --git a/bip-0301/witness-vs-critical.png b/bip-0301/witness-vs-critical.png Binary files differnew file mode 100644 index 0000000..79c84b1 --- /dev/null +++ b/bip-0301/witness-vs-critical.png diff --git a/bip-0310.mediawiki b/bip-0310.mediawiki new file mode 100644 index 0000000..257e92a --- /dev/null +++ b/bip-0310.mediawiki @@ -0,0 +1,285 @@ +<pre> + BIP: 310 + Layer: Applications + Title: Stratum protocol extensions + Author: Pavel Moravec <pavel.moravec@braiins.cz> + Jan Čapek <jan.capek@braiins.cz> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0310 + Status: Draft + Type: Informational + Created: 2018-03-10 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This BIP provides a generic mechanism for specifying stratum protocol +extensions. At the same time, one of the important extensions that is +specified by this BIP is configuration of bits for "version rolling" +in nVersion field of bitcoin block header. + +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== + +The initial motivation for specifying some general support for stratum +protocol extensions was a need to allow miners to do so called +"version rolling", changing value in the first field of the Bitcoin +block header. + +Version rolling is backwards incompatible change to the stratum protocol +because the miner couldn't communicate different block version value to +the server in the original version of the stratum protocol. Similarly, +a server couldn't communicate safe bits for rolling to a miner. So +both miners and pools need to implement some protocol extension to +support version rolling. + +Typically, if a miner sends an unknown message to a server, the server +closes the connection (not all implementations do that but some +do). So it is not very safe to try to send unknown messages to +servers. + +We can use this opportunity to make one backwards incompatible +change to the protocol to support multiple extensions in the +future. In a way that a miner can advertise its capabilities and at +the same time it can request some needed features from the server. + +It is preferable that the same mechanism for feature negotiation can +be used for not yet known features. It SHOULD be easy to implement in +the mining software too. + +We introduce one new message to the stratum protocol ('''"mining.configure"''') which handles the initial configuration/negotiation of features in a generic way. So that adding features in the future can be done without a necessity to add new messages to stratum protocol. + +Each extension has its unique string name, so called '''extension code'''. + + +==Specification== +Currently, the following extensions are defined: + +* '''"version-rolling"''' +* '''"minimum-difficulty"''' +* '''"subscribe-extranonce"''' + + +===Additional data types=== + +The following names are used as type aliases, making the message +description easier. + +* '''TMask''' - case independent hexadecimal string of length 8, encoding an unsigned 32-bit integer (~<code>[0-9a-fA-F]{8}</code>) + +* '''TExtensionCode''' - non-empty string with a value equal to the name of some protocol extension. + +* '''TExtensionResult''' - <code>true</code> / <code>false</code> / ''String''. +** <code>true</code> = The requested feature is supported and its configuration understood and applied. +** <code>false</code> = The feature is not supported or unknown. +** ''String'' = Error message containing information about what went wrong. + + +===Request "mining.configure"=== + +This message (JSON RPC Request) SHOULD be the '''first message''' sent +by the miner after the connection with the server is established. The client +uses the message to advertise its features and to request/allow some +protocol extensions. + +The reason for it being the first is that we want the implementation and +possible interactions to be as easy and simple as possible. An extension +can define explicitly what does a repeated configuration of that +extension mean. + +Each extension code provides a namespace for its extension parameters +and extension return values. By convention, the names are formed from +extension codes by adding "." and a parameter name. The same applies +for the return values, which are transferred in a result map +too. E.g. "version-rolling.mask" is the name of the parameter "mask" of +extension "version-rolling". + +'''Parameters''': + +* '''extensions''' (REQUIRED, List of ''TExtensionCode'') +::- Each string in the list MUST be a valid extension code. The meaning of each code is described independently as part of the extension definition. A miner SHOULD advertise all its available features. + +* '''extension-parameters''' (REQUIRED, ''Map of (String -> Any)'') +::- Parameters of the requested/allowed extensions from the first parameter. + + +'''Return value''': + +* ''Map of (String -> Any)'' +::- Each code from the '''extensions''' list MUST have a defined return value (''TExtensionCode'' -> ''TExtensionResult''). This way the miner knows if the extension is activated or not. E.g. <code>{"version-rolling":false}</code> for unsupported version rolling. +::- Some extensions need additional information to be delivered to the miner. The return value map is used for this purpose. + + +Example request (new-lines added): + +<pre> + {"method": "mining.configure", + "id": 1, + "params": [["minimum-difficulty", "version-rolling"], + {"minimum-difficulty.value": 2048, + "version-rolling.mask": "1fffe000", "version-rolling.min-bit-count": 2}]} +</pre> + +(The miner requests extensions <code>"version-rolling"</code> and +<code>"minimum-difficulty"</code>. It sets the parameters according to the extensions' +definitions.) + +Example result (new-lines added): + +<pre> + {"error": null, + "id": 1, + "result": {"version-rolling": true, + "version-rolling.mask": "18000000", + "minimum-difficulty": true}} +</pre> + +=Defined extensions= + +==Extension "version-rolling"== + +This extension allows the miner to change the value of some bits in the +version field in the block header. Currently there are no standard bits +used for version rolling so they need to be negotiated between a +miner and a server. + +A miner sends the server a mask describing bits which the miner is +capable of changing. 1 = changeable bit, 0 = not changeable (<code>miner_mask</code>) +and a minimum number of bits that it needs for efficient version rolling. + +A server typically allows you to change only some of the version bits +(<code>server_mask</code>) and the rest of the version bits are +fixed. E.g. because the block needs to be valid or some signaling is +in place. + +The server responds to the configuration message by sending a mask +with common bits intersection of the miner's mask and its a mask +(<code>response = server_mask & miner_mask</code>) + +Example request (a miner capable of changing any 2 bits from a 16-bit mask): + + {"method": "mining.configure", "id": 1, "params": [["version-rolling"], {"version-rolling.mask": "1fffe000", "version-rolling.min-bit-count": 2}]} + + +Example result (success): + + {"error": null, "id": 1, "result": {"version-rolling": true, "version-rolling.mask": "18000000"}} + + +Example result (unknown extension): + + {"error": null, "id": 1, "result": {"version-rolling": false}} + + +'''Extension parameters''': + +* '''"version-rolling.mask"''' (OPTIONAL, ''TMask'', default value <code>"ffffffff"</code>) +::- Bits set to 1 can be changed by the miner. This value is expected +to be stable for the whole mining session. A miner doesn't have to +send the mask, in this case a default full mask is used. + +'''Extension return values''': + +* '''"version-rolling"''' (REQUIRED, ''TExtensionResult'') +::- When responded with <code>true</code>, the server will accept new parameter of '''"mining.submit"''', see later. + +* '''"version-rolling.mask"''' (REQUIRED, ''TMask'') +::- Bits set to 1 are allowed to be changed by the miner. If a miner changes bits with mask value 0, the server will reject the submit. +::- The server SHOULD return the largest mask possible (as many bits set to 1 as possible). This can be useful in a mining proxy setup when a proxy needs to negotiate the best mask for its future clients. There is a [Draft BIP](https://github.com/bitcoin/bips/pull/661/files) describing available nVersion bits. The server SHOULD pick a mask that preferably covers all bits specified in the BIP. + +* '''"version-rolling.min-bit-count"''' (REQUIRED, ''TMask'') +::- The miner also provides a minimum number of bits that it needs for efficient version rolling in hardware. Note that this parameter provides important diagnostic information to the pool server. If the requested bit count exceeds the limit of the pool server, the miner always has the chance to operate in a degraded mode without using full hashing power. The pool server SHOULD NOT terminate miner connection if this rare mismatch case occurs. + +===Notification '''"mining.set_version_mask"'''=== + +Server notifies the miner about a new mask valid for the +connection. This message can be sent at any time after the successful +setup of the version rolling extension by the "mining.configure" +message. The new mask is valid '''immediately''', so that the server +doesn't wait for the next job. + + +'''Parameters''': + +* ''mask'' (REQUIRED, ''TMask''): The meaning is the same as the '''"version-rolling.mask"''' return parameter. + +Example: + + {"params":["00003000"], "id":null, "method": "mining.set_version_mask"} + + +===Changes in request '''"mining.submit"'''=== + +Immediately after successful activation of the version-rolling extension +(result to '''"mining.configure"''' sent by server), the server MUST accept +an additional parameter of the message '''"mining.submit"'''. The client MUST +send one additional parameter, '''version_bits''' (6th parameter, after +''worker_name'', ''job_id'', ''extranonce2'', ''ntime'' and ''nonce''). + + +'''Additional parameters''': + +* ''version_bits'' (REQUIRED, ''TMask'') - Version bits set by miner. +::- Miner can set only bits corresponding to the set bits in the last received mask from the server either as response to "mining.configure" or "mining.set_version_mask" notification (<code>last_mask</code>). This must hold: + version_bits & ~last_mask == 0 +::- The server computes ''nVersion'' for the submit as follows: + nVersion = (job_version & ~last_mask) | (version_bits & last_mask) +where <code>job_version</code> is the block version sent to miner as part of job with id <code>job_id</code>. + +==Extension "minimum-difficulty"== + +This extension allows miner to request a minimum difficulty for the +connected machine. It solves a problem in the original stratum +protocol where there is no way how to communicate hard limit of the +connected device. + +'''Extension parameters''': +* '''"minimum-difficulty.value"''' (REQUIRED, ''Integer/Float'', >= 0) +::- The minimum difficulty value acceptable for the miner/connection. The value can be 0 for essentially disabling the feature. + +'''Extension return values''': +* '''"minimum-difficulty"''' (REQUIRED, ''TExtensionResult'') +::- Whether the minimum difficulty was accepted or not. +::- This extension can be configured multiple times by calling "mining.configure" with "minimum-difficulty" code again. + + +==Extension "subscribe-extranonce"== + +Parameter-less extension. Miner advertises its capability of receiving +message '''"mining.set_extranonce"''' message (useful for hash rate +routing scenarios). + +==Extension "info"== + +Miner provides additional text-based information. + +'''Extension parameters''': +* '''"info.connection-url"''' (OPTIONAL, ''String'') +::- Exact URL used by the mining software to connect to the stratum server. + +* '''"info.hw-version"''' (OPTIONAL, ''String'') +::- Manufacturer specific hardware revision string. + +* '''"info.sw-version"''' (OPTIONAL, ''String'') +::- Manufacturer specific software version + +* '''"info.hw-id"''' (OPTIONAL, ''String'') +::- Unique identifier of the mining device + +==Compatibility== + +Currently, there is a similar protocol feature '''mining.capabilities''' that +was intended for various protocol extensions. However, '''mining.configure''' +is incompatible with this feature as it requires a server response confirming +all accepted/negotatied extensions. The reason why we made it incompatible is +that '''mining.capabilities''' request has no associated response. + + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. diff --git a/bip-0320.mediawiki b/bip-0320.mediawiki new file mode 100644 index 0000000..9a32df6 --- /dev/null +++ b/bip-0320.mediawiki @@ -0,0 +1,68 @@ +<pre> + BIP: 320 + Title: nVersion bits for general purpose use + Author: BtcDrak <btcdrak@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0320 + Status: Draft + Type: Standards Track + Created: 2018-03-01 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This BIP reserves 16 bits of the block header nVersion field for general purpose use and removes their meaning for the purpose of version bits soft-fork signalling. + +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== + +There are a variety of things that miners may desire to use some of the nVersion field bits for. However, due to their use to coordinate miner activated soft-forks, full node software will generate false warnings about unknown soft forks if those bits are used for non soft fork signalling purposes. By reserving bits from the nVersion field for general use, node software can be updated to ignore those bits and therefore will not emit false warnings. Reserving 16 bits for general use leaves enough for 13 parallel soft-forks using version bits. + +===Example Uses=== + +The following are example cases that would benefit from using some of the bits from the nVersion field. This list is not exhaustive. + +Bitcoin mining hardware currently can exhaust the 32 bit nonce field in less than 200ms requiring the controller to distribute new jobs very frequently to each mining chip consuming a lot of bandwidth and CPU time. This can be greatly reduced by rolling more bits. Rolling too many bits from nTime is not ideal because it may distort the timestamps over a longer period. + +Version-rolling AsicBoost requires two bits from the nVersion field to calculate 4-way collisions. Any two bits can be used and mining equipment can negotiate which bits are to be used with mining pools via the Stratum "version-rolling" extension. + +==Specification== + +Sixteen bits from the block header nVersion field, starting from 13 and ending at 28 inclusive (0x1fffe000), are reserved for general use and removed from BIP8 and BIP9 specifications. A mask of 0xe0001fff should be applied to nVersion bits so bits 13-28 inclusive will be ignored for soft-fork signalling and unknown soft-fork warnings. + +This specification does not reserve specific bits for specific purposes. + +==Reference Implementation== + +https://github.com/btcdrak/bitcoin/commit/d12516e136d4a8952904a13eedc9f4225f35dc3b + +==Backwards Compatibility== + +Non-upgraded nodes will interpret the reserved bits of this proposal as signals for soft forks, and may additionally activate the warning system for unknown soft forks. + +This proposal does not require a soft fork to implement. + +At the time of writing no known soft forks are pending using any of 16 bits reserved in this BIP, and given that a non-trivial percentage of the hashrate is already making uses of those bits, future soft forks SHOULD NOT utilise those bits for activation signalling. + +==Acknowledgements== + +Timo Hanke and Sergio Lerner for originally proposing 15-bit extra nNonce2. + +==References== + +[[bip-0008.mediawiki|BIP8]] + +[[bip-0009.mediawiki|BIP9]] + +[https://arxiv.org/pdf/1604.00575.pdf AsicBoost white paper] + +[https://github.com/BlockheaderNonce2/bitcoin/wiki Blockheader Extra nNonce2 proposal] + +[https://github.com/slushpool/stratumprotocol/blob/master/stratum-extensions.mediawiki Stratum protocol extension BIP for version-rolling] + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki new file mode 100644 index 0000000..aaf5496 --- /dev/null +++ b/bip-0322.mediawiki @@ -0,0 +1,287 @@ +<pre> + BIP: 322 + Layer: Applications + Title: Generic Signed Message Format + Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322 + Status: Draft + Type: Standards Track + Created: 2018-09-10 + License: CC0-1.0 +</pre> + +== Abstract == + +A standard for interoperable generic signed messages based on the Bitcoin Script format. + +== Background == + +* Assume two actors, a prover <code>P</code> and a verifier <code>V</code>. +* <code>P</code> wants to prove that they own the private key <code>k</code> associated with a given address <code>A</code> (which in turn is derived from the pubkey <code>kG</code>). +* Let <code>V</code> generate a message <code>M</code> and hand this to <code>P</code>. +* <code>P</code> generates a signature <code>S</code> by signing the message <code>M</code> using <code>k</code>. Given <code>S</code>, <code>V</code> can prove that <code>P</code> has the private key associated with <code>A</code>. + +The astute reader will notice that the above is missing a critical part, namely the pubkey <code>kG</code>, without which the verifier cannot actually verify the message. The current message signing standard solves this via a cryptographic trick, wherein the signature <code>S</code> above is a special "recoverable signature" type. Given the message <code>M</code> and the signature <code>S</code>, it is then possible to recover the pubkey <code>kG</code>. The system thus derives the address for the pubkey <code>kG</code>, and if it does not match <code>A</code>, the proof is deemed invalid. + +While this is a neat trick, it unnecessarily restricts and complicates the message signing mechanism; for instance, it is currently not possible to sign a message for a P2SH address, because there is no pubkey to recover from the resulting signature. + +== Motivation == + +The current message signing standard only works for P2PKH (1...) addresses. By extending it to use a Bitcoin Script based approach, it could be made more generic without causing a too big burden on implementers, who most likely have access to Bitcoin Script interpreters already. + +== Specification == + +A new structure <code>SignatureProof</code> is added, which is a simple serializable scriptSig & witness container. + +Two actions "Sign" and "Verify" are defined along with one ''purpose'', "SignMessage", with the ability to expand in the future to add a potential "ProveFunds" purpose. + +=== SignatureProof container === + +{|class="wikitable" style="text-align: center;" +|- +!Type +!Length +!Name +!Comment +|- +|Uint32||4||version||BIP322 version format; must be equal to 1; if > 1, verifier must abort the verification process +|- +|Uint8||1||entries||number of proof entries<ref><strong>Why support multiple proofs?</strong> It is non-trivial to check a large number of individual proofs for duplicates. Software could be written to do so, but it seems more efficient to build this check into the specification itself.</ref> +|} + +The above is followed by [entries] number of signature entries: + +{|class="wikitable" style="text-align: center;" +|- +!Type +!Length +!Name +!Comment +|- +|VarInt||1-8||scriptsiglen||Number of bytes in scriptSig data +|- +|Uint8*||[scriptsiglen]||scriptsig||ScriptSig data +|- +|VarInt||1-8||witlen||Number of entries in witness stack +|- +|Uint8[]*||[witlen]||wit||Witness stack, as [witlen] uint8* vectors, each one prepended with a varint of its size +|} + +In some cases, the scriptsig or wit may be empty. If both are empty, the proof is incomplete. + +=== Result Codes === + +A verification call will return a result code according to the table below. + +{|class="wikitable" style="text-align: center;" +|- +!Code +!Description +|- +|INCOMPLETE||One or several of the given challenges had an empty proof. The prover may need some other entity to complete the proof. +|- +|INCONCLUSIVE||One or several of the given proofs was consensus-valid but policy-invalid. +|- +|VALID||All proofs were deemed valid. +|- +|INVALID||One or more of the given proofs were invalid +|- +|ERROR||An error was encountered +|} + +== Signing and Verifying == + +If the challenge consists of a single address and the address is in the P2PKH (legacy) format, sign using the legacy format (further information below). Otherwise continue as stated below. + +Let there be an empty set <code>inputs</code> which is populated and tested at each call to one of the actions below. + +=== Purpose: SignMessage === + +The "SignMessage" purpose generates a sighash based on a scriptPubKey and a message. It emits a VALID verification result code unless otherwise stated. + +# Return INVALID if scriptPubKey already exists in <code>inputs</code> set, otherwise insert it<ref><strong>Why track duplicates?</strong> Because a 3-entry proof is not proving 3 entries unless they are all distinct</ref> +# Define the message pre-image as the sequence "Bitcoin Signed Message:\n" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD) +# Let sighash = sha256(sha256(scriptPubKey || pre-image)) + +A private key may be used directly to sign a message. In this case, its P2WPKH bech32 address shall be derived, and used as the input. + +=== Action: Sign === + +The "Sign" action takes as input a purpose. It returns a signature or fails. + +# Obtain the sighash and scriptPubKey from the purpose; FAIL if not VALID +# Derive the private key privkey for the scriptPubKey; FAIL if not VALID +# Generate and return a signature sig with privkey=privkey, sighash=sighash + +The resulting signature proof should be encoded using base64 encoding. + +=== Action: Verify === + +The "Verify" action takes as input a standard flags value, a script sig, an optional witness, and a purpose. +It emits one of INCONCLUSIVE, VALID, INVALID, or ERROR. + +While omitted below, ERROR is returned if an unforeseen error occurs at any point in the process. A concrete example of this is if a legacy proof is given as input to a non-legacy address; the deserialization of the proof will fail in this case, and this should result in an ERROR result. + +# Obtain the sighash and scriptPubKey from the purpose; pass on result code if not VALID +# Verify Script with flags=consensus flags (currently P2SH, DERSIG, NULLDUMMY, CLTV, CSV, WITNESS), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash +# Return INVALID if verification fails +# Verify Script with flags=standard flags (above plus STRICTENC, MINIMALDATA, etc.), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash +# Return VALID if verification succeeds, otherwise return INCONCLUSIVE + +=== Multiple Proofs === + +When more than one proof is created or verified, repeat the operation for each proof, retaining the inputs set. As noted, if the same input appears more than once, the operation must fail accordingly. + +Note that the order of the entries in the proof must match the order of the entries given by the verifier. + +* If any of the proofs are empty during a verification process, skip the verification and set the INCOMPLETE flag +* If a verification call returns ERROR or INVALID, return ERROR or INVALID immediately, ignoring as yet unverified entries +* After all verifications complete, +** return INCONCLUSIVE if any verification call returned INCONCLUSIVE +** return INCOMPLETE if the INCOMPLETE flag is set +** return VALID + +== Legacy format == + +The legacy format is restricted to the legacy P2PKH address format, and restricted to one single challenge (address). + +Any other input (e.g. multiple addresses, or non-P2PKH address format(s)) must be signed using the new format described above. + +=== Signing === + +Given the P2PKH address <code>a</code> and the message <code>m</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>: + +# let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the pubkey <code>P</code>, contained in <code>a</code> +# let <code>x</code> be the private key associated with <code>P</code> so that <code>pkh(xG) = p</code> +# let <code>digest</code> be <code>SHA56d("Bitcoin Signed Message:\n"||m)</code> +# create a compact signature <code>sig</code> (aka "recoverable ECDSA signature") using <code>x</code> on <code>digest</code> + +The resulting proof is <code>sig</code>, serialized using the base64 encoding. + +=== Verifying === + +Given the P2PKH address <code>a</code>, the message <code>m</code>, the compact signature <code>sig</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>: + +# let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the pubkey <code>P</code>, contained in <code>a</code> +# let <code>digest</code> be <code>SHA56d("Bitcoin Signed Message:\n"||m)</code> +# attempt pubkey recovery for <code>digest</code> using the signature <code>sig</code> and store the resulting pubkey into <code>Q</code> +## fail verification if pubkey recovery above fails +# let <code>q</code> be the pubkey-hash <code>pkh(Q)</code> for the pubkey <code>Q</code> +# if <code>p == q</code>, the proof is valid, otherwise it is invalid + +== Compatibility == + +This specification is backwards compatible with the legacy signmessage/verifymessage specification through the special case as described above. + +== Rationale == + +<references/> + +== Reference implementation == + +# Pull request to Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/16440 + +== Acknowledgements == + +Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, and many others for their feedback on the specification. + +== References == + +# Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html + +== Copyright == + +This document is licensed under the Creative Commons CC0 1.0 Universal license. + +== Consensus and standard flags == + +Each flag is associated with some type of enforced rule (most often a soft fork). There are two sets of flags: consensus flags (which result in a block being rejected, if violated), and policy flags (which result in a transaction being accepted only if it is contained within an actual block, and rejected otherwise, if violated). The policy flags are a super-set of the consensus flags. + +BIP322 specifies that a proof that validates for both rulesets is valid, a proof that validates for consensus rules, but not for policy rules, is "inconclusive", and a proof that does not validate for consensus rules is "invalid" (regardless of policy rule validation). + +The ruleset sometimes changes. This BIP does not intend to be complete, nor does it indicate enforcement of rules, it simply lists the rules as they stand at the point of writing. + +=== Consensus rules === + +* P2SH: evaluate P2SH ([https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP16]) subscripts +* DERSIG: enforce strict DER ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]) compliance +* NULLDUMMY: enforce NULLDUMMY ([https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki BIP147]) +* CHECKLOCKTIMEVERIFY: enable CHECKLOCKTIMEVERIFY ([https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]) +* CHECKSEQUENCEVERIFY: enable CHECKSEQUENCEVERIFY ([https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112]) +* WITNESS: enable WITNESS ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) + +=== Policy rules === + +All of the above, plus (subject to change): + +* STRICTENC: non-strict DER signature or undefined hashtype +* MINIMALDATA: require minimal encodings for all push operations +* DISCOURAGE_UPGRADABLE_NOPS: discourage use of NOPs reserved for upgrades +* CLEANSTACK: require that only a single stack element remains after evaluation +* MINIMALIF: Segwit script only: require the argument of OP_IF/NOTIF to be exactly 0x01 or empty vector +* NULLFAIL: signature(s) must be empty vector if a CHECK(MULTI)SIG operation failed +* LOW_S: signature with S > order/2 in a checksig operation +* DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM: v1-16 witness programs are non-standard (i.e. forbidden) +* WITNESS_PUBKEYTYPE: public keys in segregated witness scripts must be compressed +* CONST_SCRIPTCODE: OP_CODESEPARATOR and FindAndDelete fail any non-segwit scripts + +== Test vectors == + +== Native segwit test vector == + +<pre> +address = bcrt1qe7nte4zk4ayly5tc53dtdjupgkz0lr8azx3rzz +scriptpubkey = 0014cfa6bcd456af49f25178a45ab6cb814584ff8cfd +message = hello +preimage = 0014cfa6bcd456af49f25178a45ab6cb814584ff8cfd426974636f696e205369 + 676e6564204d6573736167653a0a68656c6c6f + (scriptpubkey || "Bitcoin Signed Message:\nhello") +sighash = 790eef86c204f0bff969ff822121317aa34eff0215dbd30ccf031e7b2f3f0cc1 + (sha256d(preimage), displayed in big-endian) +</pre> + +The proof becomes: + +<pre> +HEX: 01000000010002473044022075b4fb40421d55c55462879cb352a85eeb3af2138d3f0290 + 2c9143f12870f5f70220119c2995c1661138142f3899c1fd6d1af7e790e0e081be72db9c + e7bf5b5b932901210290beccd02b73eca57467b2b6f1e47161a9b76a5e67586e7c1dee9e + a6e2dcd869 + +Base64: AQAAAAEAAkcwRAIgdbT7QEIdVcVUYoecs1KoXus68hONPwKQLJFD8Shw9fcCIBGcKZXBZhE4 + FC84mcH9bRr355Dg4IG+ctuc579bW5MpASECkL7M0Ctz7KV0Z7K28eRxYam3al5nWG58He6e + puLc2Gk= +</pre> + +Split into components: + +{|class="wikitable" style="text-align: center;" +|- +!Type +!Length +!Name +!Value +!Comment +|- +|Uint32||4||flags||<code>01000000</code>||proof format version +|- +|Uint8||1||entries||<code>01</code>||1 entry +|- +|VarInt||1-8||scriptsiglen||<code>00</code>||0 byte scriptsig +|- +|VarInt||1-8||wit entries||<code>02</code>||2 witness stack entries +|- +|VarInt||1-8||entry1len||<code>47</code>||71 byte entry +|- +|Uint8[71]||71||entry1||<code>3044022075b4fb40421d55c55462879cb352a85eeb3af213 +8d3f02902c9143f12870f5f70220119c2995c1661138142f +3899c1fd6d1af7e790e0e081be72db9ce7bf5b5b932901</code>||Witness stack item 1 +|- +|VarInt||1-8||entry2len||<code>21</code>||33 byte entry +|- +|Uint8[33]||33||entry2||<code>0290beccd02b73eca57467b2b6f1e47161a9b76a5e67586e +7c1dee9ea6e2dcd869</code>||Witness stack item 2 +|} + +The above test vector is for a bech32 P2WPKH (native segwit) address. (Once BIP solidifies, will add test vector for other types.) diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl index 5589abb..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 = ( @@ -87,6 +87,7 @@ my %DefinedLicenses = ( ); 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 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; @@ -121,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); @@ -147,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)$/; |
