diff options
115 files changed, 12488 insertions, 1292 deletions
diff --git a/.github/workflows/github-action-checks.yml b/.github/workflows/github-action-checks.yml index bfc014b..8a7d2ac 100644 --- a/.github/workflows/github-action-checks.yml +++ b/.github/workflows/github-action-checks.yml @@ -5,15 +5,18 @@ jobs: Link-Format-Checks: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 + - uses: actions/checkout@v4 - run: scripts/link-format-chk.sh Build-Table-Checks: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 + - uses: actions/checkout@v4 - run: scripts/buildtable.pl >/tmp/table.mediawiki || exit 1 Diff-Checks: + name: "Diff Checks (fails until number assignment)" runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 + - uses: actions/checkout@v4 + with: + fetch-depth: 2 - run: scripts/diffcheck.sh diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..d939d2a --- /dev/null +++ b/.gitignore @@ -0,0 +1,6 @@ +bip-0174/coinjoin-workflow.aux +bip-0174/coinjoin-workflow.log +bip-0174/coinjoin-workflow.pdf +bip-0174/multisig-workflow.aux +bip-0174/multisig-workflow.log +bip-0174/multisig-workflow.pdf diff --git a/README.mediawiki b/README.mediawiki index 41c729d..455d522 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1,4 +1,4 @@ -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 (do <em>not</em> assign a number - read <a href="bip-0002.mediawiki">BIP 2</a> for the full process). After discussion, please open a PR. 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://groups.google.com/g/bitcoindev bitcoindev@googlegroups.com] mailing list (do <em>not</em> assign a number - read <a href="bip-0002.mediawiki">BIP 2</a> for the full process). 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. @@ -235,15 +235,15 @@ Those proposing changes should consider that ultimately consent may rest with th | Applications | Purpose Field for Deterministic Wallets | Marek Palatinus, Pavol Rusnak -| Informational +| Standard | Final -|- style="background-color: #ffffcf" +|- style="background-color: #cfffcf" | [[bip-0044.mediawiki|44]] | Applications | Multi-Account Hierarchy for Deterministic Wallets | Marek Palatinus, Pavol Rusnak | Standard -| Proposed +| Final |- style="background-color: #ffffcf" | [[bip-0045.mediawiki|45]] | Applications @@ -251,13 +251,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia | Standard | Proposed -|- +|- style="background-color: #cfffcf" | [[bip-0047.mediawiki|47]] | Applications | Reusable Payment Codes for Hierarchical Deterministic Wallets | Justus Ranvier | Informational -| Draft +| Final |- style="background-color: #ffffcf" | [[bip-0048.mediawiki|48]] | Applications @@ -270,7 +270,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Applications | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | Daniel Weigl -| Informational +| Standard | Final |- style="background-color: #cfffcf" | [[bip-0050.mediawiki|50]] @@ -434,13 +434,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Eric Lombrozo | Standard | Rejected -|- +|- style="background-color: #cfffcf" | [[bip-0084.mediawiki|84]] | Applications | Derivation scheme for P2WPKH based accounts | Pavol Rusnak -| Informational -| Draft +| Standard +| Final |- | [[bip-0085.mediawiki|85]] | Applications @@ -452,7 +452,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0086.mediawiki|86]] | Applications | Key Derivation for Single Key P2TR Outputs -| Andrew Chow +| Ava Chow | Standard | Draft |- style="background-color: #ffffcf" @@ -487,7 +487,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0093.mediawiki|93]] | Applications | codex32: Checksummed SSSS-aware BIP32 seeds -| Leon Olsson Curr, Pearlwort Sneed +| Leon Olsson Curr, Pearlwort Sneed, Andrew Poelstra | Informational | Draft |- @@ -627,7 +627,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0119.mediawiki|119]] | Consensus (soft fork) | CHECKTEMPLATEVERIFY -| Jeremy Rubin +| Jeremy Rubin, James O'Beirne | Standard | Draft |- style="background-color: #ffcfcf" @@ -714,13 +714,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Andy Chase | Process | Withdrawn -|- +|- style="background-color: #cfffcf" | [[bip-0133.mediawiki|133]] | Peer Services | feefilter message | Alex Morcos | Standard -| Draft +| Final |- style="background-color: #ffcfcf" | [[bip-0134.mediawiki|134]] | Consensus (hard fork) @@ -900,7 +900,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0174.mediawiki|174]] | Applications | Partially Signed Bitcoin Transaction Format -| Andrew Chow +| Ava Chow | Standard | Final |- style="background-color: #ffcfcf" @@ -1030,6 +1030,20 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0331.mediawiki|331]] +| Peer Services +| Ancestor Package Relay +| Gloria Zhao +| Standard +| Draft +|- +| [[bip-0337.mediawiki|337]] +| API/RPC +| Compressed Transactions +| Tom Briar +| Standard +| Draft +|- | [[bip-0338.mediawiki|338]] | Peer Services | Disable transaction relay message @@ -1072,12 +1086,26 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Final |- +| [[bip-0345.mediawiki|345]] +| Consensus (soft fork) +| OP_VAULT +| James O'Beirne, Greg Sanders, Anthony Towns +| Standard +| Draft +|- +| [[bip-0347.mediawiki|347]] +| Consensus (soft fork) +| OP_CAT in Tapscript +| Ethan Heilman, Armin Sabouri +| Standard +| Draft +|- style="background-color: #cfffcf" | [[bip-0350.mediawiki|350]] | Applications | Bech32m format for v1+ witness addresses | Pieter Wuille | Standard -| Draft +| Final |- | [[bip-0351.mediawiki|351]] | Applications @@ -1085,18 +1113,25 @@ Those proposing changes should consider that ultimately consent may rest with th | Alfred Hodler, Clark Moody | Informational | Draft +|- style="background-color: #ffffcf" +| [[bip-0352.mediawiki|352]] +| Applications +| Silent Payments +| josibake, Ruben Somsen +| Standard +| Proposed |- | [[bip-0370.mediawiki|370]] | Applications | PSBT Version 2 -| Andrew Chow +| Ava Chow | Standard | Draft |- | [[bip-0371.mediawiki|371]] | Applications | Taproot Fields for PSBT -| Andrew Chow +| Ava Chow | Standard | Draft |- @@ -1110,49 +1145,70 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0380.mediawiki|380]] | Applications | Output Script Descriptors General Operation -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0381.mediawiki|381]] | Applications | Non-Segwit Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0382.mediawiki|382]] | Applications | Segwit Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0383.mediawiki|383]] | Applications | Multisig Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0384.mediawiki|384]] | Applications | combo() Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0385.mediawiki|385]] | Applications | raw() and addr() Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow | Informational | Draft |- | [[bip-0386.mediawiki|386]] | Applications | tr() Output Script Descriptors -| Pieter Wuille, Andrew Chow +| Pieter Wuille, Ava Chow +| Informational +| Draft +|- +| [[bip-0387.mediawiki|387]] +| Applications +| Tapscript Multisig Output Script Descriptors +| Pieter Wuille, Ava Chow +| Informational +| Draft +|- style="background-color: #ffffcf" +| [[bip-0388.mediawiki|388]] +| Applications +| Wallet Policies for Descriptor Wallets +| Salvatore Ingala +| Standard +| Proposed +|- +| [[bip-0389.mediawiki|389]] +| Applications +| Multipath Descriptor Key Expressions +| Ava Chow | Informational | Draft |- diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki index c6eb950..4bdc23b 100644 --- a/bip-0002.mediawiki +++ b/bip-0002.mediawiki @@ -32,13 +32,13 @@ The BIP process begins with a new idea for Bitcoin. Each potential BIP must have Small enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a BIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker. Additionally, many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. -After investigating past work, the best way to proceed is by posting about the new idea to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list]. +After investigating past work, the best way to proceed is by posting about the new idea to the [https://groups.google.com/g/bitcoindev Bitcoin development mailing list]. Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. -Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list]. +Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://groups.google.com/g/bitcoindev Bitcoin development mailing list]. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the [https://github.com/bitcoin/bips BIPs git repository] as a pull request. This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until an editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers). @@ -67,8 +67,12 @@ If you are interested in assuming ownership of a BIP, send a message asking to t The current BIP editors are: +* Bryan Bishop ([[mailto:kanzure@gmail.com|kanzure@gmail.com]]) +* Jon Atack ([[mailto:jon@atack.com|jon@atack.com]]) * Luke Dashjr ([[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]]) -* Kalle Alm ([[mailto:karljohan-alm@garage.co.jp|karljohan-alm@garage.co.jp]]) +* Mark "Murch" Erhardt ([[mailto:murch@murch.one|murch@murch.one]]) +* Olaoluwa Osuntokun ([[mailto:laolu32@gmail.com|laolu32@gmail.com]]) +* Ruben Somsen ([[mailto:rsomsen@gmail.com|rsomsen@gmail.com]]) ===BIP Editor Responsibilities & Workflow=== @@ -98,11 +102,13 @@ The BIP editor will: The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and update BIP headers as appropriate. +BIP editors may also, at their option, unilaterally make and merge strictly-editorial changes to BIPs, such as correcting misspellings, fixing broken links, etc. + ==BIP format and structure== ===Specification=== -BIPs should be written in mediawiki format. +BIPs should be written in mediawiki or markdown format. Each BIP should have the following parts: @@ -409,7 +415,6 @@ Why is Public Domain no longer acceptable for new BIPs? * Non-image auxiliary files are permitted in the bip-XXXX subdirectory. * Email addresses are now required for authors. * The Post-History header may be provided as a link instead of a simple date. -* Markdown format is no longer permitted for BIPs. * The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions. ==See Also== diff --git a/bip-0009/states.gv b/bip-0009/states.gv new file mode 100644 index 0000000..9dc95c5 --- /dev/null +++ b/bip-0009/states.gv @@ -0,0 +1,22 @@ +/* There are many ways to compile this, but one of them is: + * + * $ dot -Tpng states.gv -o states.png + */ +digraph { + /* States. */ + DEFINED; FAILED; STARTED; LOCKED_IN; ACTIVE; + + /* Relationships between states, labeled where applicable. */ + DEFINED -> DEFINED; + DEFINED -> FAILED [label = "timeout ≤ MTP"]; + DEFINED -> STARTED [label = "starttime ≤ MTP < timeout"]; + FAILED -> FAILED; + STARTED -> STARTED; + STARTED -> FAILED [label = "timeout ≤ MTP"]; + STARTED -> LOCKED_IN [label = "(MTP < timeout) AND (threshold reached)"]; + LOCKED_IN -> ACTIVE [label = "Always"]; + ACTIVE -> ACTIVE; + + /* Visualization hack to unclutter output. */ + nodesep = 1.2; +} diff --git a/bip-0009/states.png b/bip-0009/states.png Binary files differindex 09312a1..2048ed8 100644 --- a/bip-0009/states.png +++ b/bip-0009/states.png diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki index 42071f3..289e3b0 100644 --- a/bip-0010.mediawiki +++ b/bip-0010.mediawiki @@ -93,10 +93,10 @@ The following is an example TxDP from Armory, produced while running on the test In this transaction, there are two inputs, one of 150 BTC and the other of 12 BTC. This transaction combines 162 BTC to create two outputs, one of 160 BTC, one 1.9995 BTC, and a tx fee of 0.0005. In this TxDP, both inputs have been signed, and thus could broadcast immediately. -The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpretted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP. +The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpreted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP. A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it is not the recommended method for combining TxDPs. == Reference Implementation == -This proposal was implemented and tested in the older versions of ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Implementation can be found in https://github.com/etotheipi/BitcoinArmory/blob/v0.91-beta/armoryengine/Transaction.py under the class PyTxDistProposal. However, as of verion 0.92 released in July 2014, Armory no longer uses this proposal for offline wallet transaction signing and has moved on to a new format. +This proposal was implemented and tested in the older versions of ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Implementation can be found in https://github.com/etotheipi/BitcoinArmory/blob/v0.91-beta/armoryengine/Transaction.py under the class PyTxDistProposal. However, as of version 0.92 released in July 2014, Armory no longer uses this proposal for offline wallet transaction signing and has moved on to a new format. diff --git a/bip-0012.mediawiki b/bip-0012.mediawiki index 70069d6..bd3d88c 100644 --- a/bip-0012.mediawiki +++ b/bip-0012.mediawiki @@ -43,11 +43,11 @@ OP_EVAL allows the receiver of bitcoins to specify how they can be spent when th If ''serialized script'' is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver. -The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilties. +The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilities. That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure. -There is a 1-confirmation attack on old clients that interepret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is: +There is a 1-confirmation attack on old clients that interpret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is: # Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients. # Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim. diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki index abd575c..fded420 100644 --- a/bip-0014.mediawiki +++ b/bip-0014.mediawiki @@ -28,7 +28,7 @@ Version bumping can also introduce incompatibilities and fracture the network. I By using a protocol version, we set all implementations on the network to a common standard. Everybody is able to agree within their confines what is protocol and what is implementation-dependent. A user agent string is offered as a 'vanity-plate' for clients to distinguish themselves in the network. -Separation of the network protocol from the implemention, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type). +Separation of the network protocol from the implementation, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type). User agents provide extra tracking information that is useful for keeping tabs on network data such as client implementations used or common architectures/operating-systems. In the rare case they may even provide an emergency method of shunning faulty clients that threaten network health- although this is strongly unrecommended and extremely bad form. The user agent does not provide a method for clients to work around and behave differently to different implementations, as this will lead to protocol fracturing. diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki index a6e4426..52a698f 100644 --- a/bip-0015.mediawiki +++ b/bip-0015.mediawiki @@ -348,7 +348,7 @@ By using DNS lookups, the MITM problem with IP transactions could be mitigated b === Namecoin ID === -This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retreives the structured data containing the bitcoin address(es) associated with this alias. +This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retrieves the structured data containing the bitcoin address(es) associated with this alias. Using a decentralised domain name system like Namecoin, means no external server or entity needs to be trusted unlike the other proposals listed here. This indicates a system with the advantage of having a high availability and ease of entry (no restrictions for users to create aliases). @@ -401,4 +401,4 @@ Any text can be put into the brackets, allowing merchants to adapt it to all the New features can be added later to support uncovered cases. -See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more informations. +See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more information. diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index 0fba9bc..9fa4823 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -37,7 +37,7 @@ Elements of the query component may contain characters outside the valid range. === ABNF grammar === -(See also [[#Simpler syntax|a simpler representation of syntax]]) +(See also [[#simpler-syntax|a simpler representation of syntax]]) bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ] bitcoinaddress = *base58 @@ -120,11 +120,6 @@ Some future version that has variables which are (currently) not understood but Characters must be URI encoded properly. -== Reference Implementations == -=== Bitcoin clients === -* Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858. +== Reference Implementation == -=== Libraries === -* Javascript - https://github.com/bitcoinjs/bip21 -* Java - https://github.com/SandroMachado/BitcoinPaymentURI -* Swift - https://github.com/SandroMachado/BitcoinPaymentURISwift +Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858. diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index b441658..0e6df24 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -25,7 +25,7 @@ This document describes hierarchical deterministic wallets (or "HD Wallets"): wa The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients. -The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree. +The specification consists of two parts. In the first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree. ==Copyright== @@ -37,7 +37,7 @@ The Bitcoin reference client uses randomly generated keys. In order to avoid the Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds). -However, deterministic wallets typically consist of a single "chain" of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive customer's payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root. +However, deterministic wallets typically consist of a single "chain" of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive customers' payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root. ==Specification: Key derivation== @@ -104,7 +104,7 @@ The function N((k, c)) → (K, c) computes the extended public key correspond To compute the public child key of a parent private key: * N(CKDpriv((k<sub>par</sub>, c<sub>par</sub>), i)) (works always). * CKDpub(N(k<sub>par</sub>, c<sub>par</sub>), i) (works only for non-hardened child keys). -The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further for more information. +The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further below for more information. ====Public parent key → private child key==== @@ -184,7 +184,7 @@ When a business has several independent offices, they can all use wallets derive ====Recurrent business-to-business transactions: N(m/i<sub>H</sub>/0)==== In case two business partners often transfer money, one can use the extended public key for the external chain of a specific account (M/i h/0) as a sort of "super address", allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment. -Such a mechanism could also be used by mining pool operators as variable payout address. +Such a mechanism could also be used by mining pool operators as a variable payout address. ====Unsecure money receiver: N(m/i<sub>H</sub>/0)==== @@ -212,7 +212,7 @@ Private and public keys must be kept safe as usual. Leaking a private key means Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys. One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. -It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts. +It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private keys never risks compromising the master or other accounts. ==Test Vectors== diff --git a/bip-0035.mediawiki b/bip-0035.mediawiki index 64edaf5..eccd381 100644 --- a/bip-0035.mediawiki +++ b/bip-0035.mediawiki @@ -16,7 +16,7 @@ Make a network node's transaction memory pool accessible via a new "mempool" mes ==Motivation== -Several use cases make it desireable to expose a network node's transaction memory pool: +Several use cases make it desirable to expose a network node's transaction memory pool: # SPV clients, wishing to obtain zero-confirmation transactions sent or received. # Miners, to avoid missing lucrative fees, downloading existing network transactions after a restart. # Remote network diagnostics. diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index 511b55a..ab1a158 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -36,10 +36,10 @@ Password and passphrase-protected private keys enable new practical use cases fo This proposal is hereby placed in the public domain. ==Rationale== -:'''''User story:''' As a Bitcoin user who uses paper wallets, I would like the ability to add encryption, so that my Bitcoin paper storage can be two factor: something I have plus something I know.'' -:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).'' -:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.'' -:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate. +:'' '''User story:''' As a Bitcoin user who uses paper wallets, I would like the ability to add encryption, so that my Bitcoin paper storage can be two factor: something I have plus something I know.'' +:'' '''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).'' +:'' '''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.'' +:'' '''User story:''' (EC-multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.'' ==Specification== This proposal makes use of the following functions and definitions: @@ -47,12 +47,12 @@ This proposal makes use of the following functions and definitions: *'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output. *'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash. *'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter. -*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve. -*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer. -*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem. +*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the secp256k1 elliptic curve. +*'''G, N''': Constants defined as part of the secp256k1 elliptic curve. G is an elliptic curve point, and N is a large positive integer. +*'''Base58Check''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem. ===Prefix=== -It is proposed that the resulting Base58Check-encoded string start with a '6'. The number '6' is intended to represent, from the perspective of the user, "a private key that needs something else to be usable" - an umbrella definition that could be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key. +It is proposed that the resulting Base58Check-encoded string start with a '6'. The number '6' is intended to represent, from the perspective of the user, "a private key that needs something else to be usable" - an umbrella definition that could be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in Wallet Import Format which denotes an unencrypted private key. It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed. @@ -170,7 +170,7 @@ To recalculate the address: # Derive ''passfactor'' using scrypt with ''ownerentropy'' and the user's passphrase and use it to recompute ''passpoint'' # Derive decryption key for ''pointb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownerentropy'' # Decrypt ''encryptedpointb'' to yield ''pointb'' -# ECMultiply ''pointb'' by ''passfactor''. Use the resulting EC point as a public key and hash it into ''address'' using either compressed or uncompressed public key methodology as specifid in ''flagbyte''. +# ECMultiply ''pointb'' by ''passfactor''. Use the resulting EC point as a public key and hash it into ''address'' using either compressed or uncompressed public key methodology as specified in ''flagbyte''. =====Decryption===== # Collect encrypted private key and passphrase from user. @@ -184,7 +184,7 @@ To recalculate the address: # Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect. ==Backwards compatibility== -Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities. +Backwards compatibility is minimally applicable since this is a new standard that at most extends Wallet Import Format. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and Wallet Import Format); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities. ==Suggestions for implementers of proposal with alt-chains== If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain. @@ -209,14 +209,10 @@ The preliminary values of 16384, 8, and 8 are hoped to offer the following prope ==Reference implementation== Added to alpha version of Casascius Bitcoin Address Utility for Windows available at: -* via https: https://casascius.com/btcaddress-alpha.zip -* at github: https://github.com/casascius/Bitcoin-Address-Utility +* https://github.com/casascius/Bitcoin-Address-Utility Click "Tools" then "PPEC Keygen" (provisional name) -==Other implementations== -* Javascript - https://github.com/bitcoinjs/bip38 - ==Test vectors== ===No compression, no EC multiply=== diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index d8a4d25..51fe33d 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -39,7 +39,7 @@ security is improved but the sentence length increases. We refer to the initial entropy length as ENT. The allowed size of ENT is 128-256 bits. First, an initial entropy of ENT bits is generated. A checksum is generated by -taking the first <pre>ENT / 32</pre> bits of its SHA256 hash. This checksum is +taking the first <code>ENT / 32</code> bits of its SHA256 hash. This checksum is appended to the end of the initial entropy. Next, these concatenated bits are split into groups of 11 bits, each encoding a number from 0-2047, serving as an index into a wordlist. Finally, we convert these numbers into words and @@ -138,67 +138,3 @@ Also see https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39. Reference implementation including wordlists is available from http://github.com/trezor/python-mnemonic - -==Other Implementations== - -Go: -* https://github.com/tyler-smith/go-bip39 - -Python: -* https://github.com/meherett/python-hdwallet - -Elixir: -* https://github.com/aerosol/mnemo - -Objective-C: -* https://github.com/nybex/NYMnemonic - -Haskell: -* https://github.com/haskoin/haskoin - -.NET (Standard): -* https://www.nuget.org/packages/dotnetstandard-bip39/ - -.NET C# (PCL): -* https://github.com/Thashiznets/BIP39.NET - -.NET C# (PCL): -* https://github.com/NicolasDorier/NBitcoin - -JavaScript: -* https://github.com/bitpay/bitcore/tree/master/packages/bitcore-mnemonic -* https://github.com/bitcoinjs/bip39 (used by [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/hd-wallet.js#L121-L146|blockchain.info]]) -* https://github.com/hujiulong/web-bip39 - -Java: -* https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/crypto/MnemonicCode.java - -Ruby: -* https://github.com/sreekanthgs/bip_mnemonic - -Rust: -* https://github.com/maciejhirsz/tiny-bip39/ -* https://github.com/koushiro/bip0039-rs - -Smalltalk: -* https://github.com/eMaringolo/pharo-bip39mnemonic - -Swift: -* https://github.com/CikeQiu/CKMnemonic -* https://github.com/yuzushioh/WalletKit -* https://github.com/pengpengliu/BIP39 -* https://github.com/matter-labs/web3swift/blob/develop/Sources/web3swift/KeystoreManager/BIP39.swift -* https://github.com/zcash-hackworks/MnemonicSwift -* https://github.com/ShenghaiWang/BIP39 - -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 - -Python: -* https://github.com/scgbckbone/btc-hd-wallet - -Dart: -* https://github.com/dart-bitcoin/bip39 diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index f2c173c..5acf87d 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/bip-0039/bip-0039-wordlists.md @@ -53,7 +53,7 @@ Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch 7. No words in the plural (except invariable words like "univers", or same spelling than singular like "heureux"). 8. No female adjectives (except words with same spelling for male and female adjectives like "magique"). 9. No words with several senses AND different spelling in speaking like "verre-vert", unless a word has a meaning much more popular than another like "perle" and "pairle". -10. No very similar words with 1 letter of difference. +10. No very similar words with only 1 letter of difference. 11. No essentially reflexive verbs (unless a verb is also a noun like "souvenir"). 12. No words with "ô;â;ç;ê;œ;æ;î;ï;û;ù;à;ë;ÿ". 13. No words ending by "é;ée;è;et;ai;ait". @@ -93,12 +93,12 @@ Words chosen using the following rules: 1. Words are 4-8 letters long. 2. Words can be uniquely determined typing the first 4 letters. -3. Only words containing all letters without diacritical marks. (It was the hardest task, because in one third of all Czech letters has diacritical marks.) +3. Only words containing all letters without diacritical marks. (It was the hardest task, because one third of all Czech letters has diacritical marks.) 4. Only nouns, verbs and adverbs, no other word types. All words are in basic form. 5. No personal names or geographical names. 6. No very similar words with 1 letter of difference. -7. Words are sorting according English alphabet (Czech sorting has difference in "ch"). -8. No words already used in other language mnemonic sets (english, italian, french, spanish). Letters with diacritical marks from these sets are counted as analogous letters without diacritical marks. +7. Words are sorted according to English alphabet (Czech sorting has difference in "ch"). +8. No words already used in other language mnemonic sets (english, italian, french, spanish). Letters with diacritical marks from these sets are counted as analogous letters without diacritical marks. ### Portuguese @@ -109,9 +109,9 @@ Credits: @alegotardo @bitmover-studio @brenorb @kuthullu @ninjastic @sabotag3x @ 3. No complex verb forms. 4. No plural words, unless there's no singular form. 5. No words with double spelling. -6. No words with the exact sound of another word with different spelling. +6. No words with the exact sound as another word with different spelling. 7. No offensive words. 8. No words already used in other language mnemonic sets. 9. The words which have not the same spelling in Brazil and in Portugal are excluded. -10. No words that remind negative/sad/bad things. -11. No very similar words with 1 letter of difference. +10. No words that remind one of negative/sad/bad things. +11. No very similar words with only 1 letter of difference. diff --git a/bip-0042.mediawiki b/bip-0042.mediawiki index 223076f..2c5de6d 100644 --- a/bip-0042.mediawiki +++ b/bip-0042.mediawiki @@ -15,7 +15,7 @@ Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillenium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years. -This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion Bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. +This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. To combat this, this document proposes a controversial change: making Bitcoin's monetary supply finite. diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki index 32e02b1..f07c94a 100644 --- a/bip-0043.mediawiki +++ b/bip-0043.mediawiki @@ -7,7 +7,7 @@ Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0043 Status: Final - Type: Informational + Type: Standards Track Created: 2014-04-24 </pre> diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index 4ddd56b..5db540c 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -6,7 +6,7 @@ Pavol Rusnak <stick@satoshilabs.com> Comments-Summary: Mixed review (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0044 - Status: Proposed + Status: Final Type: Standards Track Created: 2014-04-24 </pre> diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index af801f9..dc1f588 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -1,7 +1,7 @@ RECENT CHANGES: +* (15 Feb 2021) Finalize specification +* (28 Sep 2017) Adjust text to match test vectors * (19 Apr 2016) Define version 2 payment codes -* (17 Apr 2016) Clarify usage of outpoints in notification transactions -* (18 Dec 2015) Update explanations to resolve FAQs <pre> BIP: 47 @@ -10,11 +10,17 @@ RECENT CHANGES: Author: Justus Ranvier <justus@openbitcoinprivacyproject.org> Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0047 - Status: Draft + Status: Final Type: Informational Created: 2015-04-24 </pre> +==Status== + +This BIP can be be considered final in terms of enabling compatibility with wallets that implement version 1 and version 2 reusable payment codes, however future developments of the reusable payment codes specification will not be distributed via the BIP process. + +The Open Bitcoin Privacy Project RFC repo should be consulted for specifications related to version 3 or higher payment codes: https://github.com/OpenBitcoinPrivacyProject/rfc + ==Abstract== This BIP defines a technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse. @@ -150,7 +156,7 @@ It is assumed that Alice can easily obtain Bob's payment code via a suitable met Prior to the first time Alice initiates a transaction to Bob, Alice MUST inform Bob of her payment code via the following procedure: -Note: this procedure is used if Bob uses a version 1 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 1, see the appropriate section in this specification. +Note: this procedure is used if Bob uses a version 1 payment code (regardless of the version of Alice's payment code). If Bob's payment code is not version 1, see the appropriate section in this specification. # Alice constructs a transaction which sends a small quantity of bitcoins to Bob's notification address (notification transaction) ## The inputs selected for this transaction MUST NOT be easily associated with Alice's notification address @@ -158,7 +164,7 @@ Note: this procedure is used if Bob uses a version 1 payment code (regardless of ## Alice selects the private key corresponding to the designated pubkey: <pre>a</pre> ## Alice selects the public key associated with Bob's notification address: <pre>B, where B = bG</pre> ## Alice calculates a secret point: <pre>S = aB</pre> -## Alice calculates a 64 byte blinding factor: <pre>s = HMAC-SHA512(x, o)</pre> +## Alice calculates a 64 byte blinding factor: <pre>s = HMAC-SHA512(o, x)</pre> ### "x" is the x value of the secret point ### "o" is the outpoint being spent by the designated input # Alice serializes her payment code in binary form. @@ -229,7 +235,7 @@ The following actions are recommended to reduce this risk: <img src="bip-0047/reusable_payment_codes-04.png" /> <img src="bip-0047/reusable_payment_codes-05.png" /> # Bob is watching for incoming payments on B' ever since he received the notification transaction from Alice. -## Bob calculates n shared secrets with Alice, using the 0<sup>th</sup> public key derived Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window. +## Bob calculates n shared secrets with Alice, using the 0<sup>th</sup> public key derived from Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window. ## Bob calculates the ephemeral deposit addresses using the same procedure as Alice: <pre>B' = B + sG</pre> ## Bob calculate the private key for each ephemeral address as: <pre>b' = b + s</pre> <img src="bip-0047/reusable_payment_codes-02.png" /> diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki index 7d8d2c7..a13b437 100644 --- a/bip-0049.mediawiki +++ b/bip-0049.mediawiki @@ -6,7 +6,7 @@ Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0049 Status: Final - Type: Informational + Type: Standards Track Created: 2016-05-19 License: PD </pre> diff --git a/bip-0060.mediawiki b/bip-0060.mediawiki index 8e9f289..626a039 100644 --- a/bip-0060.mediawiki +++ b/bip-0060.mediawiki @@ -23,14 +23,14 @@ The implementation is problematic because the RelayTransactions flag is an optio One property of Bitcoin messages is their fixed number of fields. This keeps the format simple and easily understood. Adding optional fields to messages will cause deserialisation issues when other fields come after the optional one. -As an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict adherance to standard messages with field length compliance with every protocol version. +As an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict adherence to standard messages with field length compliance with every protocol version. Another property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader. ==Specification== === version === -When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version. +When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version. Payload: diff --git a/bip-0061.mediawiki b/bip-0061.mediawiki index b08739d..384c0ff 100644 --- a/bip-0061.mediawiki +++ b/bip-0061.mediawiki @@ -57,7 +57,7 @@ Every reject message begins with the following fields. Some messages append extr |} The human-readable string is intended only for debugging purposes; in particular, different implementations may -use different strings. The string should not be shown to users or used for anthing besides diagnosing +use different strings. The string should not be shown to users or used for anything besides diagnosing interoperability problems. The following reject code categories are used; in the descriptions below, "server" is the peer generating diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 793039d..a31cc3d 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -53,10 +53,10 @@ Hash the redeem script according to BIP-0016 to get the P2SH address. 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba ==Compatibility== -* Uncompressed keys are incompatible with this specificiation. A compatible implementation should not automatically compress keys. Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation. -* P2SH addressses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network. Also, it would cause a hard fork. +* Uncompressed keys are incompatible with this specification. A compatible implementation should not automatically compress keys. Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation. +* P2SH addresses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network. Also, it would cause a hard fork. * Implementations that do not conform with this BIP will have compatibility issues with strictly-compliant wallets. -* Implementations which do adopt this standard will be cross-compatible when choosing multisig addressses. +* Implementations which do adopt this standard will be cross-compatible when choosing multisig addresses. * If a group of users were not entirely compliant, there is the possibility that a participant will derive an address that the others will not recognize as part of the common multisig account. ==Test vectors== diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki index 1893f0e..3528725 100644 --- a/bip-0078.mediawiki +++ b/bip-0078.mediawiki @@ -143,7 +143,7 @@ If the receiver does not support the version of the sender, they should send an } </pre> -* <code>additionalfeeoutputindex=</code>, if the sender is willing to pay for increased fee, this indicate output can have its value substracted to pay for it. +* <code>additionalfeeoutputindex=</code>, if the sender is willing to pay for increased fee, this indicate output can have its value subtracted to pay for it. If the <code>additionalfeeoutputindex</code> is out of bounds or pointing to the payment output meant for the receiver, the receiver should ignore the parameter. See [[#fee-output|fee output]] for more information. @@ -198,7 +198,7 @@ It is advised to hard code the description of the well known error codes into th ===<span id="fee-output"></span>Fee output=== In some situation, the sender might want to pay some additional fee in the payjoin proposal. -If such is the case, the sender must use both [[#optional-params|optional parameters]] <code>additionalfeeoutputindex=</code> and <code>maxadditionalfeecontribution=</code> to indicate which output and how much the receiver can substract fee. +If such is the case, the sender must use both [[#optional-params|optional parameters]] <code>additionalfeeoutputindex=</code> and <code>maxadditionalfeecontribution=</code> to indicate which output and how much the receiver can subtract fee. There is several cases where a fee output is useful: @@ -273,7 +273,7 @@ The sender should check the payjoin proposal before signing it to prevent a mali * For each outputs in the proposal: ** Verify that no keypaths is in the PSBT output ** If the output is the [[#fee-output|fee output]]: -*** The amount that was substracted from the output's value is less than or equal to <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>. +*** The amount that was subtracted from the output's value is less than or equal to <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>. *** Make sure the actual contribution is only paying fee: The <code>actual contribution</code> is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT. *** Make sure the actual contribution is only paying for fee incurred by additional inputs: <code>actual contribution</code> is less than or equals to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (see [[#fee-output|Fee output]] section) ** If the output is the payment output and payment output substitution is allowed. @@ -344,7 +344,7 @@ On top of this the receiver can poison analysis by randomly faking a round amoun ===<span id="output-substitution"></span>Payment output substitution=== -Unless disallowed by sender explicitely via `disableoutputsubstitution=true` or by the BIP21 url via query parameter the `pjos=0`, the receiver is free to decrease the amount, remove, or change the scriptPubKey output paying to himself. +Unless disallowed by sender explicitly via `disableoutputsubstitution=true` or by the BIP21 url via query parameter the `pjos=0`, the receiver is free to decrease the amount, remove, or change the scriptPubKey output paying to himself. Note that if payment output substitution is disallowed, the reveiver can still increase the amount of the output. (See [[#reference-impl|the reference implementation]]) For example, if the sender's scriptPubKey type is P2WPKH while the receiver's payment output in the original PSBT is P2SH, then the receiver can substitute the payment output to be P2WPKH to match the sender's scriptPubKey type. @@ -413,7 +413,7 @@ Here is pseudo code of a sender implementation. The <code>signedPSBT</code> represents a PSBT which has been fully signed, but not yet finalized. We then prepare <code>originalPSBT</code> from the <code>signedPSBT</code> via the <code>CreateOriginalPSBT</code> function and get back the <code>proposal</code>. -While we verify the <code>proposal</code>, we also import into it informations about our own inputs and outputs from the <code>signedPSBT</code>. +While we verify the <code>proposal</code>, we also import into it information about our own inputs and outputs from the <code>signedPSBT</code>. At the end of this <code>RequestPayjoin</code>, the proposal is verified and ready to be signed. We logged the different PSBT involved, and show the result in our [[#test-vectors|test vectors]]. @@ -557,7 +557,7 @@ public async Task<PSBT> RequestPayjoin( if (output.OriginalTxOut == feeOutput) { var actualContribution = feeOutput.Value - proposedPSBTOutput.Value; - // The amount that was substracted from the output's value is less than or equal to maxadditionalfeecontribution + // The amount that was subtracted from the output's value is less than or equal to maxadditionalfeecontribution if (actualContribution > optionalParameters.MaxAdditionalFeeContribution) throw new PayjoinSenderException("The actual contribution is more than maxadditionalfeecontribution"); // Make sure the actual contribution is only paying fee @@ -642,7 +642,7 @@ A successful exchange with: {| class="wikitable" !InputScriptType -!Orginal PSBT Fee rate +!Original PSBT Fee rate !maxadditionalfeecontribution !additionalfeeoutputindex |- diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki index 0cade19..f367c71 100644 --- a/bip-0080.mediawiki +++ b/bip-0080.mediawiki @@ -35,7 +35,7 @@ Each level has a special meaning, described in the chapters below. ===Purpose=== -Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "80" with the most signifigant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification. +Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "80" with the most significant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification. Hardened derivation is used at this level. diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki index 96ac8d1..923917c 100644 --- a/bip-0081.mediawiki +++ b/bip-0081.mediawiki @@ -35,7 +35,7 @@ Each level has a special meaning, described in the chapters below. ===Purpose=== -Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "81" with the most signifigant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification. +Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "81" with the most significant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification. Hardened derivation is used at this level. diff --git a/bip-0083.mediawiki b/bip-0083.mediawiki index d7bbe8e..c669001 100644 --- a/bip-0083.mediawiki +++ b/bip-0083.mediawiki @@ -53,7 +53,7 @@ p //' n instead of p / 0' / n Rather than specifying upfront which path is to be used for a specific purpose (i.e. external invoicing vs. internal change), different applications can specify arbitrary parent nodes and derivation paths. This allows for nesting of sublevels to arbitrary depth with application-specified semantics. Rather than trying to specify use cases upfront, we leave the design completely open-ended. Different applications can exchange these mappings for interoperability. Eventually, if certain mappings become popular, application user interfaces can provide convenient shortcuts or use them as defaults. -Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (2<sup>31</sup> - 1) for this purpose. However, we believe doing so introduces more ideosyncracies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits. +Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (2<sup>31</sup> - 1) for this purpose. However, we believe doing so introduces more idiosyncrasies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits. ==Use Cases== diff --git a/bip-0084.mediawiki b/bip-0084.mediawiki index dc5a05d..e1e458c 100644 --- a/bip-0084.mediawiki +++ b/bip-0084.mediawiki @@ -5,8 +5,8 @@ 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 + Status: Final + Type: Standards Track Created: 2017-12-28 License: CC0-1.0 </pre> diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 6e7dd0e..7311d8a 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -96,18 +96,6 @@ OUTPUT * Python library implementation: [https://github.com/ethankosakovsky/bip85] * JavaScript library implementation: [https://github.com/hoganri/bip85-js] -===Other Implementations=== - -* JavaScript library implementation: [https://github.com/hoganri/bip85-js] - -* Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] - -* Ian Coleman's Mnemonic Code Converter: [https://github.com/iancoleman/bip39] and [https://iancoleman.io/bip39/] - -* AirGap Vault: [https://github.com/airgap-it/airgap-vault/commit/d64332fc2f332be622a1229acb27f621e23774d6] - -btc_hd_wallet: [https://github.com/scgbckbone/btc-hd-wallet] - ==Applications== The Application number defines how entropy will be used post processing. Some basic examples follow: @@ -244,7 +232,7 @@ INPUT: OUTPUT * DERIVED ENTROPY=ead0b33988a616cf6a497f1c169d9e92562604e38305ccd3fc96f2252c177682 -* DERIVED WIF=xprv9s21ZrQH143K2srSbCSg4m4kLvPMzcWydgmKEnMmoZUurYuBuYG46c6P71UGXMzmriLzCCBvKQWBUv3vPB3m1SATMhp3uEjXHJ42jFg7myX +* DERIVED XPRV=xprv9s21ZrQH143K2srSbCSg4m4kLvPMzcWydgmKEnMmoZUurYuBuYG46c6P71UGXMzmriLzCCBvKQWBUv3vPB3m1SATMhp3uEjXHJ42jFg7myX ===HEX=== Application number: 128169' @@ -262,6 +250,82 @@ INPUT: OUTPUT * DERIVED ENTROPY=492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c +===PWD BASE64=== +Application number: 707764' + +The derivation path format is: <code>m/83696968'/707764'/{pwd_len}'/{index}'</code> + +`20 <= pwd_len <= 86` + +[https://datatracker.ietf.org/doc/html/rfc4648 Base64] encode the all 64 bytes of entropy. +Remove any spaces or new lines inserted by Base64 encoding process. Slice base64 result string +on index 0 to `pwd_len`. This slice is the password. As `pwd_len` is limited to 86, passwords will not contain padding. + +Entropy calculation:<br> +R = 64 (base64 - do not count padding)<br> +L = pwd_len<br> +Entropy = log2(R ** L)<br> + +{| class="wikitable" style="margin:auto" +! pwd_length !! (cca) entropy +|- +| 20 || 120.0 +|- +| 24 || 144.0 +|- +| 32 || 192.0 +|- +| 64 || 384.0 +|- +| 86 || 516.0 +|} + +INPUT: +* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb +* PATH: m/83696968'/707764'/21'/0' + +OUTPUT +* DERIVED ENTROPY=d7ad61d4a76575c5bad773feeb40299490b224e8e5df6c8ad8fe3d0a6eed7b85ead9fef7bcca8160f0ee48dc6e92b311fc71f2146623cc6952c03ce82c7b63fe +* DERIVED PWD=dKLoepugzdVJvdL56ogNV + +===PWD BASE85=== +Application number: 707785' + +The derivation path format is: <code>m/83696968'/707785'/{pwd_len}'/{index}'</code> + +`10 <= pwd_len <= 80` + +Base85 encode the all 64 bytes of entropy. +Remove any spaces or new lines inserted by Base64 encoding process. Slice base85 result string +on index 0 to `pwd_len`. This slice is the password. `pwd_len` is limited to 80 characters. + +Entropy calculation:<br> +R = 85<br> +L = pwd_len<br> +Entropy = log2(R ** L)<br> + +{| class="wikitable" style="margin:auto" +! pwd_length !! (cca) entropy +|- +| 10 || 64.0 +|- +| 15 || 96.0 +|- +| 20 || 128.0 +|- +| 30 || 192.0 +|- +| 80 || 512.0 +|} + +INPUT: +* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb +* PATH: m/83696968'/707785'/12'/0' + +OUTPUT +* DERIVED ENTROPY=f7cfe56f63dca2490f65fcbf9ee63dcd85d18f751b6b5e1c1b8733af6459c904a75e82b4a22efff9b9e69de2144b293aa8714319a054b6cb55826a8e51425209 +* DERIVED PWD=_s`{TW89)i4` + ===RSA=== Application number: 828365' @@ -288,7 +352,7 @@ The resulting RSA key can be used to create a GPG key where the creation date MU Note on GPG key capabilities on smartcard/hardware devices: -GPG capable smart-cards SHOULD be be loaded as follows: The encryption slot SHOULD be loaded with the ENCRYPTION capable key; the authentication slot SHOULD be loaded with the AUTHENTICATION capable key. The signature capable slot SHOULD be loaded with the SIGNATURE capable key. +GPG capable smart-cards SHOULD be loaded as follows: The encryption slot SHOULD be loaded with the ENCRYPTION capable key; the authentication slot SHOULD be loaded with the AUTHENTICATION capable key. The signature capable slot SHOULD be loaded with the SIGNATURE capable key. However, depending on available slots on the smart-card, and preferred policy, the CERTIFY capable key MAY be flagged with CERTIFY and SIGNATURE capabilities and loaded into the SIGNATURE capable slot (for example where the smart-card has only three slots and the CERTIFY capability is required on the same card). In this case, the SIGNATURE capable sub-key would be disregarded because the CERTIFY capable key serves a dual purpose. diff --git a/bip-0086.mediawiki b/bip-0086.mediawiki index f724884..529f094 100644 --- a/bip-0086.mediawiki +++ b/bip-0086.mediawiki @@ -2,7 +2,7 @@ BIP: 86 Layer: Applications Title: Key Derivation for Single Key P2TR Outputs - Author: Andrew Chow <andrew@achow101.com> + Author: Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0086 Status: Draft diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki index d270027..308e852 100644 --- a/bip-0087.mediawiki +++ b/bip-0087.mediawiki @@ -40,7 +40,7 @@ A modern standardization is needed for multisig derivation paths. There are som m / purpose' / cosigner_index / change / address_index </pre> -BIP45 unecessarily demands a single script type (here, P2SH). In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner. This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>. Sorting public keys between cosigners in order to create the full derivation path, prior to sending the key record to the coordinator to create the descriptor, merely adds additional unnecessary communication rounds. +BIP45 unnecessarily demands a single script type (here, P2SH). In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner. This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>. Sorting public keys between cosigners in order to create the full derivation path, prior to sending the key record to the coordinator to create the descriptor, merely adds additional unnecessary communication rounds. The second multisignature "standard" in use is m/48', which specifies: diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki index 936f2ca..49be7db 100644 --- a/bip-0088.mediawiki +++ b/bip-0088.mediawiki @@ -89,7 +89,7 @@ installation of malicious or incorrect profiles, though. ==Specification== -The format for the template was choosen to make it easy to read, convenient and visually unambigous. +The format for the template was chosen to make it easy to read, convenient and visually unambigous. Template starts with optional prefix <code>m/</code>, and then one or more sections delimited by the slash character (<code>/</code>). @@ -127,13 +127,13 @@ Constraints: # To avoid ambiguity, an index range that matches a single value MUST be specified as Unit range. # To avoid ambiguity, an index range <code>0-2147483647</code> is not allowed, and MUST be specified as Wildcard index template instead # For Non-unit range, range_end MUST be larger than range_start. -# If there is more than one index range within the Ranged index template, range_start of the second and any subsequent range MUST be larger than the range_end of the preceeding range. +# If there is more than one index range within the Ranged index template, range_start of the second and any subsequent range MUST be larger than the range_end of the preceding range. # To avoid ambiguity, all representations of integer values larger than 0 MUST NOT start with character <code>0</code> (no leading zeroes allowed). # If hardened marker appears within any section in the path template, all preceding sections MUST also specify hardened matching. # To avoid ambiguity, if a hardened marker appears within any section in the path template, all preceding sections MUST also use the same hardened marker (either <code>h</code> or <code>'</code>). # To avoid ambiguity, trailing slashes (for example, <code>1/2/</code>) and duplicate slashes (for example, <code>0//1</code>) MUST NOT appear in the template. -It may be desireable to have fully unambiguous encoding, where for each valid path template string, there is no other valid template string that matches the exact same set of paths. This would enable someone to compare templates for equality through a simple string equality check, without any parsing. +It may be desirable to have fully unambiguous encoding, where for each valid path template string, there is no other valid template string that matches the exact same set of paths. This would enable someone to compare templates for equality through a simple string equality check, without any parsing. To achieve this, two extra rules are needed: diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index 8882e00..156eec0 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -56,7 +56,7 @@ development, diversity, etc) to fork the Bitcoin Core software and it's good that there's many alternative implementations of the protocol (forks of Bitcoin Core or written from scratch). -But sometimes a bug in the reimplementaion of the consensus +But sometimes a bug in the reimplementation of the consensus validation rules can prevent users of alternative implementation from following the longest (most work) valid chain. This can result in those users losing coins or being defrauded, making reimplementations diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki index 69b265b..4822d4a 100644 --- a/bip-0109.mediawiki +++ b/bip-0109.mediawiki @@ -37,7 +37,7 @@ In particular: * The coinbase scriptSig is not counted * Signature operations in un-executed branches of a Script are not counted -* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations. +* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisfied by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations. * Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit === Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block === diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index 63a7797..d6ed546 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -36,7 +36,7 @@ When executed, if any of the following conditions are true, the script interpret Otherwise, script execution will continue as if a NOP had been executed. -BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of the +BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of the output being spent; until that relative age has been reached any script execution pathway including the CHECKSEQUENCEVERIFY will fail to validate, causing the transaction not to be selected for inclusion in a block. diff --git a/bip-0114.mediawiki b/bip-0114.mediawiki index 410e84c..5b07137 100644 --- a/bip-0114.mediawiki +++ b/bip-0114.mediawiki @@ -111,7 +111,7 @@ The advantages of the current proposal are: * If different parties in a contract do not want to expose their scripts to each other, they may provide only <code>H(Subscript)</code> and keep the <code>Subscript</code> private until redemption. * If they are willing to share the actual scripts, they may combine them into one <code>Subscript</code> for each branch, saving some <code>nOpCount</code> and a few bytes of witness space. -The are some disadvantages, but only when the redemption condition is very complicated: +There are some disadvantages, but only when the redemption condition is very complicated: * It may require more branches than a general MAST design (as shown in the previous example) and take more witness space in redemption * Creation and storage of the MAST structure may take more time and space. However, such additional costs affect only the related parties in the contract but not any other Bitcoin users. diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index aa226d0..d661f4c 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -3,6 +3,7 @@ Layer: Consensus (soft fork) Title: CHECKTEMPLATEVERIFY Author: Jeremy Rubin <j@rubin.io> + James O'Beirne <vaults@au92.org> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0119 Status: Draft Type: Standards Track @@ -61,7 +62,7 @@ references. ==Detailed Specification== The below code is the main logic for verifying CHECKTEMPLATEVERIFY, described -in pythonic pseduocode. The canonical specification for the semantics of +in pythonic pseudocode. The canonical specification for the semantics of OP_CHECKTEMPLATEVERIFY as implemented in C++ in the context of Bitcoin Core can be seen in the reference implementation. @@ -88,7 +89,7 @@ def execute_bip_119(self): self.context.precomputed_ctv_data = self.context.tx.get_default_check_template_precomputed_data() # If the hashes do not match, return error - if stack[-1] != self.context.tx.get_default_check_template_hash(self.context.nIn, self.context.precomputed_ctv_data) + if stack[-1] != self.context.tx.get_default_check_template_hash(self.context.nIn, self.context.precomputed_ctv_data): return self.errors_with(errors.script_err_template_mismatch) return self.return_as_nop() @@ -225,12 +226,12 @@ A recent commit hash in that PR including tests and vectors can be found here ht Once the PR is merged, this BIP should be updated to point to the specific code released. Test vectors are available in [/bip-0119/vectors the bip-0119/vectors -directory] for checking compatibility with the refrence implementation and BIP. +directory] for checking compatibility with the reference implementation and BIP. ==Rationale== The goal of CHECKTEMPLATEVERIFY is to be minimal impact on the existing codebase -- in the -future, as we become aware of more complex but shown to be safe use cases new template types can be added. +future, as we become aware of more complex but shown to be safe use cases, new template types can be added. Below we'll discuss the rules one-by-one: @@ -250,7 +251,7 @@ Were these values not committed, it would be possible to delay the spending of an output arbitrarily as well as possible to change the TXID. Committing these values, rather than restricting them to specific values, is -more flexible as it permits users of CHECKTEMPLATEVERIFY the set the version and +more flexible as it permits users of CHECKTEMPLATEVERIFY to set the version and locktime as they please. =====Committing to the ScriptSigs Hash===== @@ -258,7 +259,7 @@ locktime as they please. The scriptsig in a segwit transaction must be exactly empty, unless it is a P2SH segwit transaction in which case it must be only the exact redeemscript. P2SH is incompatible (unless the P2SH hash is broken) with CHECKTEMPLATEVERIFY because the template hash must commit -to the ScriptSig, which must contain the redeemscript, which is a hash cycle. +to the ScriptSig, which must contain the redeemscript, which is a hash cycle. To prevent malleability when not using a segwit input, we also commit to the scriptsig. This makes it possible to use a 2 input CHECKTEMPLATEVERIFY with a legacy pre-signed diff --git a/bip-0126.mediawiki b/bip-0126.mediawiki index f498b1c..2c04eb4 100644 --- a/bip-0126.mediawiki +++ b/bip-0126.mediawiki @@ -14,7 +14,7 @@ When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner. While undesirable, these transactions are frequently unavoidable due to the natural fragmentation of wallet balances over time. -This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogenous input scripts. +This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogeneous input scripts. ==Copyright== @@ -23,8 +23,8 @@ This BIP is in the public domain. ==Definitions== * '''Heterogenous input script transaction (HIT)''': A transaction containing multiple inputs where the scripts of the previous transaction outputs being consumed are not identical (e.g. a transaction spending outputs which were sent to more than one Bitcoin address) -* '''Unavoidable heterogenous input script transaction''': A HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output -* '''Intentional heterogenous input script transaction''': A HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII) +* '''Unavoidable heterogeneous input script transaction''': A HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output +* '''Intentional heterogeneous input script transaction''': A HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII) Throughout this procedure, when input scripts are evaluated for uniqueness, "input script" should be interpreted to mean, "the script of the previous output referenced by an input to a transaction". @@ -33,10 +33,10 @@ Throughout this procedure, when input scripts are evaluated for uniqueness, "inp The recommendations in this document are designed to accomplish three goals: # Maximise the effectiveness of user-protecting protocols: Users may find that protection protocols are counterproductive if such transactions have a distinctive fingerprint which renders them ineffective. -# Minimise the adverse consequences of unavoidable heterogenous input transactions: If unavoidable HITs are indistinguishable from intentional HITs, a user creating an unavoidable HIT benefits from ambiguity with respect to graph analysis. +# Minimise the adverse consequences of unavoidable heterogeneous input transactions: If unavoidable HITs are indistinguishable from intentional HITs, a user creating an unavoidable HIT benefits from ambiguity with respect to graph analysis. # Limiting the effect on UTXO set growth: To date, non-standardized intentional HITs tend to increase the network's UTXO set with each transaction; this standard attempts to minimize this effect by standardizing unavoidable and intentional HITs to limit UTXO set growth. -In order to achieve these goals, this specification proposes a set of best practices for heterogenous input script transaction creation. These practices accommodate all applicable requirements of both intentional and unavoidable HITs while maximising the effectiveness of both in terms of preventing uncontrolled disclosure of PII. +In order to achieve these goals, this specification proposes a set of best practices for heterogeneous input script transaction creation. These practices accommodate all applicable requirements of both intentional and unavoidable HITs while maximising the effectiveness of both in terms of preventing uncontrolled disclosure of PII. In order to achieve this, two forms of HIT are proposed: Standard form and alternate form. @@ -44,13 +44,13 @@ In order to achieve this, two forms of HIT are proposed: Standard form and alter Applications which wish to comply both with this procedure and BIP69 should apply this procedure prior to applying BIP69. -==Standard form heterogenous input script transaction== +==Standard form heterogeneous input script transaction== ===Rules=== A HIT is Standard form if it adheres to all of the following rules: -# The number of unique output scripts must be equal to the number of unique inputs scripts (irrespective of the number of inputs and outputs). +# The number of unique output scripts must be equal to the number of unique input scripts (irrespective of the number of inputs and outputs). # All output scripts must be unique. # At least one pair of outputs must be of equal value. # The largest output in the transaction is a member of a set containing at least two identically-sized outputs. @@ -63,7 +63,7 @@ The requirement that all output scripts are unique prevents address reuse. Restr The requirement for at least one pair of outputs in an intentional HIT to be of equal value results in optimal behavior, and causes intentional HITs to resemble unavoidable HITs. -==Alternate form heterogenous input script transactions== +==Alternate form heterogeneous input script transactions== The formation of a standard form HIT is not possible in the following cases: @@ -88,7 +88,7 @@ Clients which create intentional HITs must have the capability to form alternate An HIT formed via the preceding procedure will adhere to the following conditions: -# The number of unique inputs scripts must exceed the number of output scripts. +# The number of unique input scripts must exceed the number of output scripts. # All output scripts must be unique. # At least one pair of outputs must be of equal value. ## "Standard outputs" refers to the set of outputs with equal value @@ -100,7 +100,7 @@ An HIT formed via the preceding procedure will adhere to the following condition ## The sum of the inputs in the set minus the value of the change output is equal to the standard value with a tolerance equal to the transaction fee. ## Change outputs with a value of zero (virtual change outputs) are permitted. The are defined for the purpose of testing whether or not a HIT adheres to this specification but are not present in the version of the transaction which is broadcast to the network. -==Non-compliant heterogenous input script transactions== +==Non-compliant heterogeneous input script transactions== If a user wishes to create an output that is larger than half the total size of their spendable outputs, or if their inputs are not distributed in a manner in which the alternate form procedure can be completed, then the user can not create a transaction which is compliant with this procedure. diff --git a/bip-0127.mediawiki b/bip-0127.mediawiki index 15c7755..87071d8 100644 --- a/bip-0127.mediawiki +++ b/bip-0127.mediawiki @@ -124,7 +124,7 @@ message FinalProof { // Bitcoin transaction. bytes proof_tx = 1; - // The metadata of the ouputs used in the proof transaction. + // The metadata of the outputs used in the proof transaction. repeated OutputMeta output_metadata = 2; } @@ -219,6 +219,7 @@ 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 +An implementation of the custom proof PSBTs is part of the [https://bitcoindevkit.org/ BDK], and can be found here: https://crates.io/crates/bdk-reserves == Footnotes == diff --git a/bip-0129.mediawiki b/bip-0129.mediawiki index 8719fe4..b5dfae8 100644 --- a/bip-0129.mediawiki +++ b/bip-0129.mediawiki @@ -47,11 +47,14 @@ Concerns #4 and #5 should be handled by Signers and are out of scope of this pro ==Specification== ===Prerequisites=== -This proposal assumes the parties in the multisig support [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032], [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and [https://tools.ietf.org/html/rfc3686 AES encryption]. +This proposal assumes the parties in the multisig support [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032], [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], [https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki BIP-0380 Output Script Descriptors] ([https://github.com/bitcoin/bips/blob/master/bip-0381.mediawiki BIP-0381],[https://github.com/bitcoin/bips/blob/master/bip-0382.mediawiki BIP-0382],[https://github.com/bitcoin/bips/blob/master/bip-0383.mediawiki BIP-0383]) and [https://tools.ietf.org/html/rfc3686 AES encryption]. ===File Extensions=== All descriptor and key records should have a <tt>.bsms</tt> file extension. Encrypted data should have a <tt>.dat</tt> extension. +===Newline=== +This specification uses line feed (LF) control character <tt>\n</tt>. + ===Roles=== ====Coordinator==== @@ -141,7 +144,7 @@ Whereas: * Password = "No SPOF" * Salt = <tt>TOKEN</tt> * c = 2048 -* dkLen = 256 +* dkLen = 256 bits (32 bytes) * DKey = Derived <tt>ENCRYPTION_KEY</tt> ====Encryption Scheme==== @@ -452,7 +455,7 @@ sh(wsh(multi(2,[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC2 ==Acknowledgement== -Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille, Salvatore Ingala, Andrew Chow and others for their feedback on the specification. +Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille, Salvatore Ingala, Ava Chow and others for their feedback on the specification. ==References== diff --git a/bip-0132.mediawiki b/bip-0132.mediawiki index e7aed29..173c919 100644 --- a/bip-0132.mediawiki +++ b/bip-0132.mediawiki @@ -48,7 +48,7 @@ The author doesn't believe this is a problem because a BIP cannot be forced on c == Process == -* '''Submit for Comments.''' The first BIP champion named in the proposal can call a "submit for comments" at any time by posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Dev Mailing List] mailling with the BIP number and a statement that the champion intends to immediately submit the BIP for comments. +* '''Submit for Comments.''' The first BIP champion named in the proposal can call a "submit for comments" at any time by posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Dev Mailing List] mailing with the BIP number and a statement that the champion intends to immediately submit the BIP for comments. ** The BIP must have been assigned BIP-number (i.e. been approved by the BIP editor) to be submitted for comments. * '''Comments.''' ** After a BIP has been submitted for comments, a two-week waiting period begins in which the community should transition from making suggestions about a proposal to publishing their opinions or concerns on the proposal. diff --git a/bip-0133.mediawiki b/bip-0133.mediawiki index c109f12..b37370d 100644 --- a/bip-0133.mediawiki +++ b/bip-0133.mediawiki @@ -5,7 +5,7 @@ Author: Alex Morcos <morcos@chaincode.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0133 - Status: Draft + Status: Final Type: Standards Track Created: 2016-02-13 License: PD diff --git a/bip-0137.mediawiki b/bip-0137.mediawiki index 19dd536..575440b 100644 --- a/bip-0137.mediawiki +++ b/bip-0137.mediawiki @@ -25,7 +25,7 @@ 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. +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, entrance 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== @@ -116,7 +116,7 @@ Since this format includes P2PKH keys, it is backwards compatible, but keep in m ==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. +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 determining a signature's validity. This BIP can also be updated as new signature formats emerge. ==Acknowledgements== diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index efdd9c9..117ca59 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -83,19 +83,23 @@ If all transactions in a block do not have witness data, the commitment is optio === Witness program === -A <code>scriptPubKey</code> (or <code>redeemScript</code> as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 40 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". +A <code>scriptPubKey</code> (or <code>redeemScript</code> as defined in BIP16/P2SH) that consists of a 1-byte push opcode (one of <code>OP_0,OP_1,OP_2,...,OP_16</code>) followed by a direct data push between 2 and 40 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". +In more detail, this means a <code>scriptPubKey</code> or <code>redeemScript</code> which consists of (in order): +* First, byte 0x00 (<code>OP_0</code>) or any byte between 0x51 (<code>OP_1</code>) and 0x60 (<code>OP_16</code>) inclusive (the version byte). +* Then, a byte ''L'' between 0x02 (push of 2 bytes) and 0x28 (push of 40 bytes) inclusive. +* Finally, ''L'' arbitrary bytes (the witness program). There are two cases in which witness validation logic are triggered. Each case determines the location of the witness version byte and program, as well as the form of the scriptSig: # Triggered by a <code>scriptPubKey</code> that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty or validation fails. (''"native witness program"'') # Triggered when a <code>scriptPubKey</code> is a P2SH script, and the BIP16 <code>redeemScript</code> pushed in the <code>scriptSig</code> is exactly a push of a version byte plus a push of a witness program. The <code>scriptSig</code> must be exactly a push of the BIP16 <code>redeemScript</code> or validation fails. (''"P2SH witness program"'') -If the version byte is 0, and the witness program is 20 bytes: +If the version byte is 0, and the witness program is 20 bytes (''L = 20''): * It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program. * The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key. * The HASH160 of the public key must match the 20-byte witness program. * After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack. -If the version byte is 0, and the witness program is 32 bytes: +If the version byte is 0, and the witness program is 32 bytes (''L = 32''): * It is interpreted as a pay-to-witness-script-hash (P2WSH) program. * The witness must consist of an input stack to feed to the script, followed by a serialized script (<code>witnessScript</code>). * The <code>witnessScript</code> (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the <code>witnessScript</code> must match the 32-byte witness program. @@ -276,7 +280,7 @@ These commitments could be included in the extensible commitment structure throu Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures. -Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity. +Examples of new script systems include Schnorr signatures, which reduce the size of multisig transactions dramatically; Lamport signatures, which are quantum computing resistant; and Merklized abstract syntax trees, which allow very compact witnesses for conditional scripts with extreme complexity. === Per-input lock-time and relative-lock-time === @@ -303,7 +307,7 @@ As a soft fork, older software will continue to operate without modification. N This BIP will be deployed by "version bits" BIP9 with the name "segwit" and using bit 1. -For Bitcoin mainnet, the BIP9 starttime will be midnight 15 november 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout will be midnight 15 november 2017 UTC (Epoch timestamp 1510704000). +For Bitcoin mainnet, the BIP9 starttime will be midnight 15 November 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout will be midnight 15 November 2017 UTC (Epoch timestamp 1510704000). For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800). diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 81763a0..9935eaa 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -39,12 +39,12 @@ A new transaction digest algorithm is defined, but only applicable to sigops in 9. nLocktime of the transaction (4-byte little endian) 10. sighash type of the signature (4-byte little endian) -Semantics of the original sighash types remain unchanged, except the followings: +Semantics of the original sighash types remain unchanged, except the following: # The way of serialization is changed; # All sighash types commit to the amount being spent by the signed input; # <code>FindAndDelete</code> of the signature is not applied to the <code>scriptCode</code>; # <code>OP_CODESEPARATOR</code>(s) after the last executed <code>OP_CODESEPARATOR</code> are not removed from the <code>scriptCode</code> (the last executed <code>OP_CODESEPARATOR</code> and any script before it are always removed); -# <code>SINGLE</code> does not commit to the input index. When <code>ANYONECANPAY</code> is not set, the semantics are unchanged since <code>hashPrevouts</code> and <code>outpoint</code> together implictly commit to the input index. When <code>SINGLE</code> is used with <code>ANYONECANPAY</code>, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index. +# <code>SINGLE</code> does not commit to the input index. When <code>ANYONECANPAY</code> is not set, the semantics are unchanged since <code>hashPrevouts</code> and <code>outpoint</code> together implicitly commit to the input index. When <code>SINGLE</code> is used with <code>ANYONECANPAY</code>, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index. The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. <ref name=wiki></ref> @@ -187,7 +187,7 @@ To ensure consistency in consensus-critical behaviour, developers should test th nHashType: 01000000 sigHash: c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670 - signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee + signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000 @@ -551,7 +551,7 @@ These examples show that <code>FindAndDelete</code> for the signature is not app nLockTime: 00000000 The input comes from a P2WSH witness program: - scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 200000 + scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 0.00200000 redeemScript : OP_CHECKSIGVERIFY <0x30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> ad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index 793c244..8bc1197 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -85,7 +85,7 @@ a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used Poly1305, also by Daniel Bernstein [4], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use 256 bit secret key. -The chacha20-poly1305@openssh.com specified and defined by openssh [5] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [6], but differs in the layout of data passed to the MAC and in the addition of encyption of the packet lengths. +The chacha20-poly1305@openssh.com specified and defined by openssh [5] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [6], but differs in the layout of data passed to the MAC and in the addition of encryption of the packet lengths. <code>K_1</code> must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki index 8200714..fad1746 100644 --- a/bip-0152.mediawiki +++ b/bip-0152.mediawiki @@ -211,7 +211,7 @@ There are several design goals for the Short ID calculation: SipHash is a secure, fast, and simple 64-bit MAC designed for network traffic authentication and collision-resistant hash tables. We truncate the output from SipHash-2-4 to 48 bits (see next section) in order to minimize space. The resulting 48-bit hash is certainly not large enough to avoid intentionally created individual collisons, but by using the block hash as a key to SipHash, an attacker cannot predict what keys will be used once their transactions are actually included in a relayed block. We mix in a per-connection 64-bit nonce to obtain independent short IDs on every connection, so that even block creators cannot control where collisions occur, and random collisions only ever affect a small number of connections at any given time. The mixing is done using SHA256(block_header || nonce), which is slow compared to SipHash, but only done once per block. It also adds the ability for nodes to choose the nonce in a better than random way to minimize collisions, though that is not necessary for correct behaviour. Conversely, nodes can also abuse this ability to increase their ability to introduce collisions in the blocks they relay themselves. However, they can already cause more problems by simply refusing to relay blocks. That is inevitable, and this design only seeks to prevent network-wide misbehavior. -====Random collision probabilty==== +====Random collision probability==== Thanks to the block-header-based SipHash keys, we can assume that the only collisions on links between honest nodes are random ones. diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki index 3e7b0d8..0ec6801 100644 --- a/bip-0155.mediawiki +++ b/bip-0155.mediawiki @@ -117,6 +117,11 @@ The list of reserved network IDs is as follows: | <code>CJDNS</code> | 16 | Cjdns overlay network address +|- +| <code>0x07</code> +| <code>YGGDRASIL</code> +| 16 +| Yggdrasil overlay network address |} Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to. @@ -184,6 +189,10 @@ I2P addresses MUST be sent with the <code>I2P</code> network ID, with the decode 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. +==Appendix E: Yggdrasil address encoding== + +Yggdrasil addresses are simply IPv6 addresses in the <code>0200::/7</code> range<ref>[https://yggdrasil-network.github.io/faq.html#will-yggdrasil-conflict-with-my-network-routing Yggdrasil FAQ]</ref>. They MUST be sent with the <code>YGGDRASIL</code> network ID. + ==References== <references/> diff --git a/bip-0158.mediawiki b/bip-0158.mediawiki index 8887d32..1fadcc7 100644 --- a/bip-0158.mediawiki +++ b/bip-0158.mediawiki @@ -39,9 +39,6 @@ that is designed to reduce the filter size for regular wallets. ''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 @@ -85,7 +82,7 @@ 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> +of <code>1 / 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 @@ -189,7 +186,7 @@ golomb_decode(stream, P: uint) -> uint64: 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>M</code>, the inverse of 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> @@ -312,6 +309,8 @@ complete serialization of a filter is: * <code>N</code>, encoded as a <code>CompactSize</code> * The bytes of the compressed filter itself +A zero element filter MUST be written as one byte containing zeroes. + ==== Signaling ==== This BIP allocates a new service bit: diff --git a/bip-0158/gentestvectors.go b/bip-0158/gentestvectors.go index 3435eb3..e51b984 100644 --- a/bip-0158/gentestvectors.go +++ b/bip-0158/gentestvectors.go @@ -207,7 +207,7 @@ func main() { prevOutputScripts, err := fetchPrevOutputScripts(client, block) if err != nil { - fmt.Println("Couldn't fetch prev output scipts: ", err) + fmt.Println("Couldn't fetch prev output scripts: ", err) return } diff --git a/bip-0173.mediawiki b/bip-0173.mediawiki index 1fdd8be..7087fff 100644 --- a/bip-0173.mediawiki +++ b/bip-0173.mediawiki @@ -11,6 +11,7 @@ Created: 2017-03-20 License: BSD-2-Clause Replaces: 142 + Superseded-By: 350 </pre> ==Introduction== @@ -403,3 +404,12 @@ separator). 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. + +==Disclosures (added 2024)== + +Due to an oversight in the design of bech32, this checksum scheme is not always +robust against +[[https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb|the insertion +and deletion of fewer than 5 consecutive characters]]. Due to this weakness, +[[bip-0350.mediawiki|BIP-350]] proposes using the scheme described in this BIP +only for Native Segwit v0 outputs. diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index f4c0807..95a5573 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -2,7 +2,7 @@ BIP: 174 Layer: Applications Title: Partially Signed Bitcoin Transaction Format - Author: Andrew Chow <achow101@gmail.com> + Author: Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174 Status: Final @@ -633,7 +633,7 @@ values are valid, then it does not matter which is chosen as either way the tran ===Proprietary Use Type=== For all global, per-input, and per-output maps, the type <tt>0xFC</tt> is reserved for proprietary use. -The proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifer, followed by the string identifier, then a subtype, and finally any key data. +The proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifier, followed by the string identifier, then a subtype, and finally any key data. The identifier can be any variable length string that software can use to identify whether the particular data in the proprietary type can be used by it. It can also be the empty string although this is not recommended. @@ -800,7 +800,7 @@ 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 +new types for key-value pairs. Backwards compatibility will still be maintained as those new types will be ignored and passed-through by signers which do not know about them. ===Version Numbers=== diff --git a/bip-0174/build.sh b/bip-0174/build.sh new file mode 100755 index 0000000..2de1e56 --- /dev/null +++ b/bip-0174/build.sh @@ -0,0 +1,9 @@ +#!/bin/bash + +pdflatex -output-format=pdf coinjoin-workflow.tex && \ +inkscape --with-gui --export-text-to-path \ + --export-plain-svg=coinjoin-workflow.svg coinjoin-workflow.pdf && \ +pdflatex -output-format=pdf multisig-workflow.tex && \ +inkscape --with-gui --export-text-to-path \ + --export-plain-svg=multisig-workflow.svg multisig-workflow.pdf && \ +echo '"success"' diff --git a/bip-0174/coinjoin-workflow.svg b/bip-0174/coinjoin-workflow.svg index 4c2a041..3b6b952 100644 --- a/bip-0174/coinjoin-workflow.svg +++ b/bip-0174/coinjoin-workflow.svg @@ -1,8 +1,54 @@ -<?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" style="background-color:white" version="1.1"> -<defs> -<g> +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<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:xlink="http://www.w3.org/1999/xlink" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="420.819pt" + height="122.694pt" + viewBox="0 0 420.819 122.694" + version="1.2" + id="svg1044" + sodipodi:docname="coinjoin-workflow.svg" + inkscape:version="0.92.4 (5da689c313, 2019-01-14)"> + <metadata + id="metadata1048"> + <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> + <sodipodi:namedview + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1" + objecttolerance="10" + gridtolerance="10" + guidetolerance="10" + inkscape:pageopacity="0" + inkscape:pageshadow="2" + inkscape:window-width="640" + inkscape:window-height="480" + id="namedview1046" + showgrid="false" + inkscape:zoom="0.50080914" + inkscape:cx="280.546" + inkscape:cy="81.796" + inkscape:window-x="0" + inkscape:window-y="0" + inkscape:window-maximized="0" + inkscape:current-layer="svg1044" /> +<defs id="defs109"> +<g id="g104"> <symbol overflow="visible" id="glyph0-0"> <path style="stroke:none;" d=""/> </symbol> @@ -107,7 +153,7 @@ </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 "/> + <path d="M 19 57 L 128 57 L 128 122.695312 L 19 122.695312 Z M 19 57 "/> </clipPath> </defs> <g id="surface1"> @@ -376,281 +422,1133 @@ <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 "/> +<path style=" stroke:none;fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;" d="M 112.644531 69.160156 L 34.269531 69.160156 C 32.070312 69.160156 30.285156 70.945312 30.285156 73.144531 L 30.285156 114.988281 C 30.285156 117.191406 32.070312 118.976562 34.269531 118.976562 L 112.644531 118.976562 C 114.84375 118.976562 116.628906 117.191406 116.628906 114.988281 L 116.628906 73.144531 C 116.628906 70.945312 114.84375 69.160156 112.644531 69.160156 Z M 112.644531 69.160156 "/> <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 "/> +<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.907844 L -39.187469 24.907844 C -41.386687 24.907844 -43.171844 23.122688 -43.171844 20.923469 L -43.171844 -20.920281 C -43.171844 -23.123406 -41.386687 -24.908562 -39.187469 -24.908562 L 39.187531 -24.908562 C 41.38675 -24.908562 43.171906 -23.123406 43.171906 -20.920281 L 43.171906 20.923469 C 43.171906 23.122688 41.38675 24.907844 39.187531 24.907844 Z M 39.187531 24.907844 " transform="matrix(1,0,0,-1,73.457,94.068)"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-1" x="37.094" y="79.595"/> + <use xlink:href="#glyph0-2" x="43.736065" y="79.595"/> + <use xlink:href="#glyph0-3" x="46.116131" y="79.595"/> + <use xlink:href="#glyph0-4" x="48.496196" y="79.595"/> + <use xlink:href="#glyph0-5" x="52.924571" y="79.595"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use xlink:href="#glyph0-5" x="60.670493" y="79.595"/> + <use xlink:href="#glyph0-32" x="65.098869" y="79.595"/> + <use xlink:href="#glyph0-8" x="69.692623" y="79.595"/> + <use xlink:href="#glyph0-6" x="73.290118" y="79.595"/> + <use xlink:href="#glyph0-7" x="76.694339" y="79.595"/> + <use xlink:href="#glyph0-4" x="81.482364" y="79.595"/> + <use xlink:href="#glyph0-8" x="85.91074" y="79.595"/> + <use xlink:href="#glyph0-9" x="89.508235" y="79.595"/> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use + xlink:href="#glyph0-8" + x="96.644445" + y="79.595" + id="use583" /> + <use + xlink:href="#glyph0-15" + x="100.24194" + y="79.595" + id="use585" /> + <use + xlink:href="#glyph0-5" + x="105.389616" + y="79.595" + id="use587" /> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use + xlink:href="#glyph0-17" + x="36.852" + y="91.55" + id="use591" /> + <use + xlink:href="#glyph0-5" + x="41.999675" + y="91.55" + id="use593" /> + <use + xlink:href="#glyph0-8" + x="46.428051" + y="91.55" + id="use595" /> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use + xlink:href="#glyph0-14" + x="49.746593" + y="91.55" + id="use599" /> +</g> +<g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> + <use + xlink:href="#glyph0-16" + x="56.275085" + y="91.55" + id="use603" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g611"> + <use + xlink:href="#glyph0-6" + x="60.987395" + y="91.55" + id="use607" /> + <use + xlink:href="#glyph0-33" + x="64.391615" + y="91.55" + id="use609" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g633"> + <use + xlink:href="#glyph0-9" + x="72.579876" + y="91.55" + id="use613" /> + <use + xlink:href="#glyph0-5" + x="76.398541" + y="91.55" + id="use615" /> + <use + xlink:href="#glyph0-6" + x="80.826916" + y="91.55" + id="use617" /> + <use + xlink:href="#glyph0-3" + x="84.231137" + y="91.55" + id="use619" /> + <use + xlink:href="#glyph0-7" + x="86.611202" + y="91.55" + id="use621" /> + <use + xlink:href="#glyph0-2" + x="91.399228" + y="91.55" + id="use623" /> + <use + xlink:href="#glyph0-3" + x="93.779293" + y="91.55" + id="use625" /> + <use + xlink:href="#glyph0-31" + x="96.159358" + y="91.55" + id="use627" /> + <use + xlink:href="#glyph0-5" + x="100.4901" + y="91.55" + id="use629" /> + <use + xlink:href="#glyph0-25" + x="104.918476" + y="91.55" + id="use631" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g657"> + <use + xlink:href="#glyph0-8" + x="41.217" + y="103.505" + id="use635" /> + <use + xlink:href="#glyph0-6" + x="44.814495" + y="103.505" + id="use637" /> + <use + xlink:href="#glyph0-7" + x="48.218715" + y="103.505" + id="use639" /> + <use + xlink:href="#glyph0-17" + x="53.006741" + y="103.505" + id="use641" /> + <use + xlink:href="#glyph0-9" + x="58.154416" + y="103.505" + id="use643" /> + <use + xlink:href="#glyph0-7" + x="61.973081" + y="103.505" + id="use645" /> + <use + xlink:href="#glyph0-4" + x="66.761106" + y="103.505" + id="use647" /> + <use + xlink:href="#glyph0-8" + x="71.189482" + y="103.505" + id="use649" /> + <use + xlink:href="#glyph0-3" + x="74.786977" + y="103.505" + id="use651" /> + <use + xlink:href="#glyph0-16" + x="77.167042" + y="103.505" + id="use653" /> + <use + xlink:href="#glyph0-17" + x="82.148342" + y="103.505" + id="use655" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g665"> + <use + xlink:href="#glyph0-7" + x="90.613563" + y="103.505" + id="use659" /> + <use + xlink:href="#glyph0-17" + x="95.401589" + y="103.505" + id="use661" /> + <use + xlink:href="#glyph0-25" + x="100.549264" + y="103.505" + id="use663" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g669"> + <use + xlink:href="#glyph0-27" + x="45.604" + y="115.46" + id="use667" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g689"> + <use + xlink:href="#glyph0-6" + x="50.472723" + y="115.46" + id="use671" /> + <use + xlink:href="#glyph0-16" + x="53.876943" + y="115.46" + id="use673" /> + <use + xlink:href="#glyph0-7" + x="58.858243" + y="115.46" + id="use675" /> + <use + xlink:href="#glyph0-25" + x="63.646269" + y="115.46" + id="use677" /> + <use + xlink:href="#glyph0-4" + x="68.793944" + y="115.46" + id="use679" /> + <use + xlink:href="#glyph0-7" + x="73.22232" + y="115.46" + id="use681" /> + <use + xlink:href="#glyph0-9" + x="78.010345" + y="115.46" + id="use683" /> + <use + xlink:href="#glyph0-8" + x="81.82901" + y="115.46" + id="use685" /> + <use + xlink:href="#glyph0-9" + x="85.426505" + y="115.46" + id="use687" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g697"> + <use + xlink:href="#glyph0-3" + x="92.562715" + y="115.46" + id="use691" /> + <use + xlink:href="#glyph0-8" + x="94.94278" + y="115.46" + id="use693" /> + <use + xlink:href="#glyph0-26" + x="98.540275" + y="115.46" + id="use695" /> +</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.908562 L 63.097125 -24.908562 L 63.097125 24.907844 L -63.098187 24.907844 Z M -63.098187 -24.908562 " + transform="matrix(1,0,0,-1,213.731,94.068)" + id="path699" /> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g711"> + <use + xlink:href="#glyph0-1" + x="157.539" + y="84.604" + id="use701" /> + <use + xlink:href="#glyph0-2" + x="164.181065" + y="84.604" + id="use703" /> + <use + xlink:href="#glyph0-3" + x="166.561131" + y="84.604" + id="use705" /> + <use + xlink:href="#glyph0-4" + x="168.941196" + y="84.604" + id="use707" /> + <use + xlink:href="#glyph0-5" + x="173.369571" + y="84.604" + id="use709" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g723"> + <use + xlink:href="#glyph0-9" + x="181.115493" + y="84.604" + id="use713" /> + <use + xlink:href="#glyph0-3" + x="184.934157" + y="84.604" + id="use715" /> + <use + xlink:href="#glyph0-30" + x="187.314223" + y="84.604" + id="use717" /> + <use + xlink:href="#glyph0-17" + x="192.295523" + y="84.604" + id="use719" /> + <use + xlink:href="#glyph0-9" + x="197.443198" + y="84.604" + id="use721" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g729"> + <use + xlink:href="#glyph0-8" + x="204.589371" + y="84.604" + id="use725" /> + <use + xlink:href="#glyph0-15" + x="208.186866" + y="84.604" + id="use727" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g733"> + <use + xlink:href="#glyph0-5" + x="213.324579" + y="84.604" + id="use731" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g759"> + <use + xlink:href="#glyph0-8" + x="221.080463" + y="84.604" + id="use735" /> + <use + xlink:href="#glyph0-6" + x="224.677958" + y="84.604" + id="use737" /> + <use + xlink:href="#glyph0-7" + x="228.082178" + y="84.604" + id="use739" /> + <use + xlink:href="#glyph0-17" + x="232.870204" + y="84.604" + id="use741" /> + <use + xlink:href="#glyph0-9" + x="238.017879" + y="84.604" + id="use743" /> + <use + xlink:href="#glyph0-7" + x="241.836544" + y="84.604" + id="use745" /> + <use + xlink:href="#glyph0-4" + x="246.624569" + y="84.604" + id="use747" /> + <use + xlink:href="#glyph0-8" + x="251.052945" + y="84.604" + id="use749" /> + <use + xlink:href="#glyph0-3" + x="254.65044" + y="84.604" + id="use751" /> + <use + xlink:href="#glyph0-16" + x="257.030505" + y="84.604" + id="use753" /> + <use + xlink:href="#glyph0-17" + x="262.011805" + y="84.604" + id="use755" /> + <use + xlink:href="#glyph0-29" + x="267.15948" + y="84.604" + id="use757" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g769"> + <use + xlink:href="#glyph0-7" + x="172.331" + y="96.559" + id="use761" /> + <use + xlink:href="#glyph0-25" + x="177.119026" + y="96.559" + id="use763" /> + <use + xlink:href="#glyph0-25" + x="182.266701" + y="96.559" + id="use765" /> + <use + xlink:href="#glyph0-9" + x="187.414376" + y="96.559" + id="use767" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g777"> + <use + xlink:href="#glyph0-15" + x="194.550587" + y="96.559" + id="use771" /> + <use + xlink:href="#glyph0-5" + x="199.698262" + y="96.559" + id="use773" /> + <use + xlink:href="#glyph0-6" + x="204.126638" + y="96.559" + id="use775" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g801"> + <use + xlink:href="#glyph0-9" + x="210.848404" + y="96.559" + id="use779" /> + <use + xlink:href="#glyph0-3" + x="214.667069" + y="96.559" + id="use781" /> + <use + xlink:href="#glyph0-30" + x="217.047134" + y="96.559" + id="use783" /> + <use + xlink:href="#glyph0-17" + x="222.028434" + y="96.559" + id="use785" /> + <use + xlink:href="#glyph0-7" + x="227.176109" + y="96.559" + id="use787" /> + <use + xlink:href="#glyph0-8" + x="231.964135" + y="96.559" + id="use789" /> + <use + xlink:href="#glyph0-20" + x="235.56163" + y="96.559" + id="use791" /> + <use + xlink:href="#glyph0-6" + x="240.709305" + y="96.559" + id="use793" /> + <use + xlink:href="#glyph0-5" + x="244.113526" + y="96.559" + id="use795" /> + <use + xlink:href="#glyph0-9" + x="248.541901" + y="96.559" + id="use797" /> + <use + xlink:href="#glyph0-29" + x="252.360566" + y="96.559" + id="use799" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g809"> + <use + xlink:href="#glyph0-7" + x="164.409" + y="108.514" + id="use803" /> + <use + xlink:href="#glyph0-17" + x="169.197026" + y="108.514" + id="use805" /> + <use + xlink:href="#glyph0-25" + x="174.344701" + y="108.514" + id="use807" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g827"> + <use + xlink:href="#glyph0-24" + x="182.809922" + y="108.514" + id="use811" /> + <use + xlink:href="#glyph0-17" + x="188.150872" + y="108.514" + id="use813" /> + <use + xlink:href="#glyph0-7" + x="193.298547" + y="108.514" + id="use815" /> + <use + xlink:href="#glyph0-2" + x="198.086573" + y="108.514" + id="use817" /> + <use + xlink:href="#glyph0-3" + x="200.466638" + y="108.514" + id="use819" /> + <use + xlink:href="#glyph0-31" + x="202.846703" + y="108.514" + id="use821" /> + <use + xlink:href="#glyph0-5" + x="207.177446" + y="108.514" + id="use823" /> + <use + xlink:href="#glyph0-9" + x="211.605821" + y="108.514" + id="use825" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g835"> + <use + xlink:href="#glyph0-15" + x="218.742032" + y="108.514" + id="use829" /> + <use + xlink:href="#glyph0-5" + x="223.889707" + y="108.514" + id="use831" /> + <use + xlink:href="#glyph0-6" + x="228.318083" + y="108.514" + id="use833" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g851"> + <use + xlink:href="#glyph0-3" + x="235.049812" + y="108.514" + id="use837" /> + <use + xlink:href="#glyph0-17" + x="237.429877" + y="108.514" + id="use839" /> + <use + xlink:href="#glyph0-19" + x="242.577552" + y="108.514" + id="use841" /> + <use + xlink:href="#glyph0-20" + x="247.725228" + y="108.514" + id="use843" /> + <use + xlink:href="#glyph0-8" + x="252.872903" + y="108.514" + id="use845" /> + <use + xlink:href="#glyph0-9" + x="256.470398" + y="108.514" + id="use847" /> + <use + xlink:href="#glyph0-26" + x="260.289062" + y="108.514" + id="use849" /> +</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.908562 L 63.097563 -24.908562 L 63.097563 24.907844 L -63.09775 24.907844 Z M -63.09775 -24.908562 " + transform="matrix(1,0,0,-1,354.004,94.068)" + id="path853" /> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g861"> + <use + xlink:href="#glyph0-12" + x="299.556" + y="84.604" + id="use855" /> + <use + xlink:href="#glyph0-16" + x="306.198065" + y="84.604" + id="use857" /> + <use + xlink:href="#glyph0-27" + x="311.179365" + y="84.604" + id="use859" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g873"> + <use + xlink:href="#glyph0-9" + x="319.644587" + y="84.604" + id="use863" /> + <use + xlink:href="#glyph0-3" + x="323.463251" + y="84.604" + id="use865" /> + <use + xlink:href="#glyph0-30" + x="325.843316" + y="84.604" + id="use867" /> + <use + xlink:href="#glyph0-17" + x="330.824616" + y="84.604" + id="use869" /> + <use + xlink:href="#glyph0-9" + x="335.972292" + y="84.604" + id="use871" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g881"> + <use + xlink:href="#glyph0-8" + x="343.118465" + y="84.604" + id="use875" /> + <use + xlink:href="#glyph0-15" + x="346.71596" + y="84.604" + id="use877" /> + <use + xlink:href="#glyph0-5" + x="351.863635" + y="84.604" + id="use879" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g907"> + <use + xlink:href="#glyph0-8" + x="359.609557" + y="84.604" + id="use883" /> + <use + xlink:href="#glyph0-6" + x="363.207051" + y="84.604" + id="use885" /> + <use + xlink:href="#glyph0-7" + x="366.611272" + y="84.604" + id="use887" /> + <use + xlink:href="#glyph0-17" + x="371.399297" + y="84.604" + id="use889" /> + <use + xlink:href="#glyph0-9" + x="376.546973" + y="84.604" + id="use891" /> + <use + xlink:href="#glyph0-7" + x="380.365637" + y="84.604" + id="use893" /> + <use + xlink:href="#glyph0-4" + x="385.153663" + y="84.604" + id="use895" /> + <use + xlink:href="#glyph0-8" + x="389.582039" + y="84.604" + id="use897" /> + <use + xlink:href="#glyph0-3" + x="393.179533" + y="84.604" + id="use899" /> + <use + xlink:href="#glyph0-16" + x="395.559599" + y="84.604" + id="use901" /> + <use + xlink:href="#glyph0-17" + x="400.540899" + y="84.604" + id="use903" /> + <use + xlink:href="#glyph0-29" + x="405.688574" + y="84.604" + id="use905" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g917"> + <use + xlink:href="#glyph0-7" + x="313.42" + y="96.559" + id="use909" /> + <use + xlink:href="#glyph0-25" + x="318.208026" + y="96.559" + id="use911" /> + <use + xlink:href="#glyph0-25" + x="323.355701" + y="96.559" + id="use913" /> + <use + xlink:href="#glyph0-9" + x="328.503376" + y="96.559" + id="use915" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g925"> + <use + xlink:href="#glyph0-15" + x="335.639587" + y="96.559" + id="use919" /> + <use + xlink:href="#glyph0-3" + x="340.787262" + y="96.559" + id="use921" /> + <use + xlink:href="#glyph0-9" + x="343.167327" + y="96.559" + id="use923" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g941"> + <use + xlink:href="#glyph0-9" + x="350.3135" + y="96.559" + id="use927" /> + <use + xlink:href="#glyph0-3" + x="354.132165" + y="96.559" + id="use929" /> + <use + xlink:href="#glyph0-30" + x="356.51223" + y="96.559" + id="use931" /> + <use + xlink:href="#glyph0-17" + x="361.49353" + y="96.559" + id="use933" /> + <use + xlink:href="#glyph0-7" + x="366.641205" + y="96.559" + id="use935" /> + <use + xlink:href="#glyph0-8" + x="371.429231" + y="96.559" + id="use937" /> + <use + xlink:href="#glyph0-20" + x="375.026726" + y="96.559" + id="use939" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g951"> + <use + xlink:href="#glyph0-6" + x="380.164439" + y="96.559" + id="use943" /> + <use + xlink:href="#glyph0-5" + x="383.568659" + y="96.559" + id="use945" /> + <use + xlink:href="#glyph0-9" + x="387.997035" + y="96.559" + id="use947" /> + <use + xlink:href="#glyph0-29" + x="391.815699" + y="96.559" + id="use949" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g959"> + <use + xlink:href="#glyph0-7" + x="305.499" + y="108.514" + id="use953" /> + <use + xlink:href="#glyph0-17" + x="310.287026" + y="108.514" + id="use955" /> + <use + xlink:href="#glyph0-25" + x="315.434701" + y="108.514" + id="use957" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g977"> + <use + xlink:href="#glyph0-24" + x="323.899922" + y="108.514" + id="use961" /> + <use + xlink:href="#glyph0-17" + x="329.240872" + y="108.514" + id="use963" /> + <use + xlink:href="#glyph0-7" + x="334.388547" + y="108.514" + id="use965" /> + <use + xlink:href="#glyph0-2" + x="339.176573" + y="108.514" + id="use967" /> + <use + xlink:href="#glyph0-3" + x="341.556638" + y="108.514" + id="use969" /> + <use + xlink:href="#glyph0-31" + x="343.936703" + y="108.514" + id="use971" /> + <use + xlink:href="#glyph0-5" + x="348.267446" + y="108.514" + id="use973" /> + <use + xlink:href="#glyph0-9" + x="352.695821" + y="108.514" + id="use975" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g985"> + <use + xlink:href="#glyph0-15" + x="359.832032" + y="108.514" + id="use979" /> + <use + xlink:href="#glyph0-3" + x="364.979707" + y="108.514" + id="use981" /> + <use + xlink:href="#glyph0-9" + x="367.359772" + y="108.514" + id="use983" /> +</g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1001"> + <use + xlink:href="#glyph0-3" + x="374.505945" + y="108.514" + id="use987" /> + <use + xlink:href="#glyph0-17" + x="376.88601" + y="108.514" + id="use989" /> + <use + xlink:href="#glyph0-19" + x="382.033686" + y="108.514" + id="use991" /> + <use + xlink:href="#glyph0-20" + x="387.181361" + y="108.514" + id="use993" /> + <use + xlink:href="#glyph0-8" + x="392.329037" + y="108.514" + id="use995" /> + <use + xlink:href="#glyph0-9" + x="395.926531" + y="108.514" + id="use997" /> + <use + xlink:href="#glyph0-26" + x="399.745196" + y="108.514" + id="use999" /> +</g> + <path + style="fill:none;stroke-width:1.59404;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M -76.777875 31.948563 L -68.320844 31.948563 " + transform="matrix(1,0,0,-1,213.731,61.347)" + id="path1003" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.055213 0.0012025 L 2.1724 1.477765 L 3.480994 0.0012025 L 2.1724 -1.479266 Z M 6.055213 0.0012025 " + transform="matrix(1,0,0,-1,142.2651,29.39964)" + id="path1005" /> + <path + style="fill:none;stroke-width:1.59404;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 63.495563 31.948563 L 71.952594 31.948563 " + transform="matrix(1,0,0,-1,213.731,61.347)" + id="path1007" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.05342 0.0012025 L 2.170608 1.477765 L 3.479201 0.0012025 L 2.170608 -1.479266 Z M 6.05342 0.0012025 " + transform="matrix(1,0,0,-1,282.54033,29.39964)" + id="path1009" /> + <path + style="fill:none;stroke-width:1.59404;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 140.276813 5.866531 L 140.276813 -2.5905 " + transform="matrix(1,0,0,-1,213.731,61.347)" + id="path1011" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.054396 0.0015925 L 2.171584 1.478155 L 3.480177 0.0015925 L 2.171584 -1.478876 Z M 6.054396 0.0015925 " + transform="matrix(0,1,1,0,354.00622,60.79326)" + id="path1013" /> + <path + style="fill:none;stroke-width:1.59404;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 76.780719 -32.723312 L 68.323688 -32.723312 " + transform="matrix(1,0,0,-1,213.731,61.347)" + id="path1015" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.056275 0.0014125 L 2.173463 1.477975 L 3.482056 0.0014125 L 2.173463 -1.479056 Z M 6.056275 0.0014125 " + transform="matrix(-1,0,0,1,285.1969,94.0689)" + id="path1017" /> + <path + style="fill:none;stroke-width:1.59404;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M -63.496625 -32.723312 L -91.879437 -32.723312 " + transform="matrix(1,0,0,-1,213.731,61.347)" + id="path1019" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.054734 0.0014125 L 2.171921 1.477975 L 3.480515 0.0014125 L 2.171921 -1.479056 Z M 6.054734 0.0014125 " + transform="matrix(-1,0,0,1,124.99614,94.0689)" + id="path1021" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M -76.777875 31.948563 L -68.711469 31.948563 " + transform="matrix(1,0,0,-1,213.731,61.347)" + id="path1023" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.402869 0.0012025 L 0.645056 2.540265 L 2.852088 0.0012025 L 0.645056 -2.541766 Z M 7.402869 0.0012025 " + transform="matrix(1,0,0,-1,142.2651,29.39964)" + id="path1025" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 63.495563 31.948563 L 71.561969 31.948563 " + transform="matrix(1,0,0,-1,213.731,61.347)" + id="path1027" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.401076 0.0012025 L 0.643264 2.540265 L 2.854201 0.0012025 L 0.643264 -2.541766 Z M 7.401076 0.0012025 " + transform="matrix(1,0,0,-1,282.54033,29.39964)" + id="path1029" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 140.276813 5.866531 L 140.276813 -2.199875 " + transform="matrix(1,0,0,-1,213.731,61.347)" + id="path1031" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.402052 0.0015925 L 0.64424 2.540655 L 2.855177 0.0015925 L 0.64424 -2.541376 Z M 7.402052 0.0015925 " + transform="matrix(0,1,1,0,354.00622,60.79326)" + id="path1033" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 76.780719 -32.723312 L 68.710406 -32.723312 " + transform="matrix(1,0,0,-1,213.731,61.347)" + id="path1035" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.403931 0.0014125 L 0.642213 2.540475 L 2.85315 0.0014125 L 0.642213 -2.541556 Z M 7.403931 0.0014125 " + transform="matrix(-1,0,0,1,285.1969,94.0689)" + id="path1037" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M -63.496625 -32.723312 L -91.488812 -32.723312 " + transform="matrix(1,0,0,-1,213.731,61.347)" + id="path1039" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.40239 0.0014125 L 0.644577 2.540475 L 2.855515 0.0014125 L 0.644577 -2.541556 Z M 7.40239 0.0014125 " + transform="matrix(-1,0,0,1,124.99614,94.0689)" + id="path1041" /> </g> </svg> diff --git a/bip-0174/coinjoin-workflow.tex b/bip-0174/coinjoin-workflow.tex index e0516ff..a325321 100644 --- a/bip-0174/coinjoin-workflow.tex +++ b/bip-0174/coinjoin-workflow.tex @@ -7,7 +7,7 @@ \usepackage{lmodern} \renewcommand*\familydefault{\sfdefault} \usepackage{tikz} -\usetikzlibrary{shapes,arrows} +\usetikzlibrary{shapes,arrows.meta} \tikzset{>=latex} \begin{document} % \sffamily{} @@ -22,7 +22,7 @@ rounded corners] \begin{tikzpicture}[auto] % outlining the flowchart on a grid - \matrix[column sep=3ex,row sep=2ex]{ + \matrix[column sep=3ex,row sep=3ex]{ \node [block_center] (0alice1) {Alice creates a PSBT with only her inputs with UTXOs filled in.\\Sends it to Bob.}; @@ -49,7 +49,13 @@ \\ };% end matrix % connecting nodes with paths - \draw[line width = 1pt, ->] + \draw [ultra thick, draw=black, -{Stealth[length=8pt]}] + (0alice1) edge (1bob1) + (1bob1) edge (2carol1) + (2carol1) edge (3bob2) + (3bob2) edge (4alice1) + (4alice1) edge (5alice2); + \draw [thin, white, -{Stealth[color=black, fill=white, length=8pt]}] (0alice1) edge (1bob1) (1bob1) edge (2carol1) (2carol1) edge (3bob2) diff --git a/bip-0174/multisig-workflow.svg b/bip-0174/multisig-workflow.svg index 8abe4c5..2d873b0 100644 --- a/bip-0174/multisig-workflow.svg +++ b/bip-0174/multisig-workflow.svg @@ -1,6 +1,47 @@ -<?xml version="1.0" encoding="UTF-8"?> +<?xml version="1.0" encoding="UTF-8" standalone="no"?> <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" style="background-color:white" version="1.1"> + viewBox="0 0 375.988 411.906" version="1.2" + 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:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + id="svg1424" + sodipodi:docname="multisig-workflow.svg" + inkscape:version="0.92.4 (5da689c313, 2019-01-14)"> + <metadata + id="metadata1428"> + <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> + <sodipodi:namedview + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1" + objecttolerance="10" + gridtolerance="10" + guidetolerance="10" + inkscape:pageopacity="0" + inkscape:pageshadow="2" + inkscape:window-width="640" + inkscape:window-height="480" + id="namedview1426" + showgrid="false" + inkscape:zoom="0.42970968" + inkscape:cx="250.65867" + inkscape:cy="274.604" + inkscape:window-x="0" + inkscape:window-y="0" + inkscape:window-maximized="0" + inkscape:current-layer="svg1424" /> <defs> <g> <symbol overflow="visible" id="glyph0-0"> @@ -192,277 +233,931 @@ <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> + <use + xlink:href="#glyph0-14" + x="215.011872" + y="25.914" + id="use221" /> + <use + xlink:href="#glyph0-8" + x="218.416092" + y="25.914" + id="use223" /> + <use + xlink:href="#glyph0-21" + x="223.397392" + y="25.914" + id="use225" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g231"> + <use + xlink:href="#glyph0-10" + x="155.2" + y="37.869" + id="use229" /> + </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> + <use + xlink:href="#glyph0-23" + x="168.286871" + y="37.869" + id="use235" /> + <use + xlink:href="#glyph0-8" + x="171.607406" + y="37.869" + id="use237" /> + <use + xlink:href="#glyph0-20" + x="176.588706" + y="37.869" + id="use239" /> + <use + xlink:href="#glyph0-23" + x="179.633277" + y="37.869" + id="use241" /> + <use + xlink:href="#glyph0-24" + x="182.953811" + y="37.869" + id="use243" /> + </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-26" + x="199.979894" + y="37.869" + id="use249" /> + <use + xlink:href="#glyph0-2" + x="205.12757" + y="37.869" + id="use251" /> + <use + xlink:href="#glyph0-18" + x="207.507635" + y="37.869" + id="use253" /> + <use + xlink:href="#glyph0-3" + x="211.10513" + y="37.869" + id="use255" /> + <use + xlink:href="#glyph0-16" + x="213.485195" + y="37.869" + id="use257" /> + <use + xlink:href="#glyph0-3" + x="217.30386" + y="37.869" + id="use259" /> + <use + xlink:href="#glyph0-27" + x="219.683925" + y="37.869" + id="use261" /> + <use + xlink:href="#glyph0-28" + x="224.665225" + y="37.869" + id="use263" /> + </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)" + id="path267" /> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g279"> + <use + xlink:href="#glyph0-1" + x="141.128" + y="65.232" + id="use269" /> + <use + xlink:href="#glyph0-2" + x="147.770065" + y="65.232" + id="use271" /> + <use + xlink:href="#glyph0-3" + x="150.150131" + y="65.232" + id="use273" /> + <use + xlink:href="#glyph0-4" + x="152.530196" + y="65.232" + id="use275" /> <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> + <use + xlink:href="#glyph0-26" + x="164.704493" + y="65.232" + id="use281" /> + <use + xlink:href="#glyph0-16" + x="169.852168" + y="65.232" + id="use283" /> + <use + xlink:href="#glyph0-5" + x="173.670833" + y="65.232" + id="use285" /> + <use + xlink:href="#glyph0-16" + x="178.099209" + y="65.232" + id="use287" /> + </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;" + id="g303"> + <use + xlink:href="#glyph0-20" + x="193.350953" + y="65.232" + id="use295" /> + <use + xlink:href="#glyph0-26" + x="196.395524" + y="65.232" + id="use297" /> + <use + xlink:href="#glyph0-2" + x="201.543199" + y="65.232" + id="use299" /> + <use + xlink:href="#glyph0-2" + x="203.923264" + y="65.232" + id="use301" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g309"> + <use + xlink:href="#glyph0-11" + x="209.620875" + y="65.232" + id="use305" /> + <use + xlink:href="#glyph0-8" + x="214.76855" + y="65.232" + id="use307" /> + </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> + <use + xlink:href="#glyph0-5" + x="225.176479" + y="65.232" + id="use313" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g321"> + <use + xlink:href="#glyph0-18" + x="232.9224" + y="65.232" + id="use317" /> + <use + xlink:href="#glyph0-8" + x="236.519895" + y="65.232" + id="use319" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g335"> + <use + xlink:href="#glyph0-4" + x="143.342" + y="77.187" + id="use323" /> + <use + xlink:href="#glyph0-14" + x="147.770376" + y="77.187" + id="use325" /> + <use + xlink:href="#glyph0-5" + x="151.174596" + y="77.187" + id="use327" /> + <use + xlink:href="#glyph0-10" + x="155.602972" + y="77.187" + id="use329" /> + <use + xlink:href="#glyph0-18" + x="160.390997" + y="77.187" + id="use331" /> + <use + xlink:href="#glyph0-5" + x="163.988492" + y="77.187" + id="use333" /> + </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;" + id="g349"> + <use + xlink:href="#glyph0-29" + x="179.839985" + y="77.187" + id="use341" /> + <use + xlink:href="#glyph0-30" + x="186.20509" + y="77.187" + id="use343" /> + <use + xlink:href="#glyph0-7" + x="191.740311" + y="77.187" + id="use345" /> + <use + xlink:href="#glyph0-31" + x="198.382376" + y="77.187" + id="use347" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g359"> + <use + xlink:href="#glyph0-15" + x="208.49043" + y="77.187" + id="use351" /> + <use + xlink:href="#glyph0-3" + x="215.297875" + y="77.187" + id="use353" /> + <use + xlink:href="#glyph0-18" + x="217.67794" + y="77.187" + id="use355" /> + <use + xlink:href="#glyph0-17" + x="221.275435" + y="77.187" + id="use357" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g367"> + <use + xlink:href="#glyph0-10" + x="229.740656" + y="77.187" + id="use361" /> + <use + xlink:href="#glyph0-2" + x="234.528682" + y="77.187" + id="use363" /> + <use + xlink:href="#glyph0-2" + x="236.908747" + y="77.187" + id="use365" /> + </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> + <use + xlink:href="#glyph0-18" + x="162.888091" + y="89.143" + id="use377" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g387"> + <use + xlink:href="#glyph0-32" + x="169.803132" + y="89.143" + id="use381" /> + <use + xlink:href="#glyph0-31" + x="176.65242" + y="89.143" + id="use383" /> + <use + xlink:href="#glyph0-33" + x="183.432965" + y="89.143" + id="use385" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g393"> + <use + xlink:href="#glyph0-34" + x="189.796078" + y="89.143" + id="use389" /> + <use + xlink:href="#glyph0-16" + x="197.129548" + y="89.143" + id="use391" /> + </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-2" + x="209.61667" + y="89.143" + id="use397" /> + <use + xlink:href="#glyph0-2" + x="211.996736" + y="89.143" + id="use399" /> + <use + xlink:href="#glyph0-5" + x="214.376801" + y="89.143" + id="use401" /> + <use + xlink:href="#glyph0-12" + x="218.805176" + y="89.143" + id="use403" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g413"> + <use + xlink:href="#glyph0-3" + x="227.270398" + y="89.143" + id="use407" /> <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"/> + <use + xlink:href="#glyph0-29" + x="153.512" + y="116.506" + id="use417" /> + <use + xlink:href="#glyph0-30" + x="159.877105" + y="116.506" + id="use419" /> + <use + xlink:href="#glyph0-7" + x="165.412326" + y="116.506" + id="use421" /> + <use + xlink:href="#glyph0-31" + x="172.054391" + y="116.506" + id="use423" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g451"> + <use + xlink:href="#glyph0-12" + x="182.152482" + y="116.506" + id="use427" /> + <use + xlink:href="#glyph0-3" + x="187.300158" + y="116.506" + id="use429" /> + <use + xlink:href="#glyph0-16" + x="189.680223" + y="116.506" + id="use431" /> + <use + xlink:href="#glyph0-18" + x="193.498888" + y="116.506" + id="use433" /> + <use + xlink:href="#glyph0-14" + x="197.096382" + y="116.506" + id="use435" /> + <use + xlink:href="#glyph0-3" + x="200.500603" + y="116.506" + id="use437" /> + <use + xlink:href="#glyph0-9" + x="202.880668" + y="116.506" + id="use439" /> + <use + xlink:href="#glyph0-26" + x="208.028343" + y="116.506" + id="use441" /> + <use + xlink:href="#glyph0-18" + x="213.176019" + y="116.506" + id="use443" /> + <use + xlink:href="#glyph0-5" + x="216.773514" + y="116.506" + id="use445" /> + <use + xlink:href="#glyph0-12" + x="221.201889" + y="116.506" + id="use447" /> + <use + xlink:href="#glyph0-28" + x="226.349565" + y="116.506" + id="use449" /> </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> + <use + xlink:href="#glyph0-2" + x="28.197065" + y="148.879" + id="use457" /> + <use + xlink:href="#glyph0-3" + x="30.577131" + y="148.879" + id="use459" /> + <use + xlink:href="#glyph0-4" + x="32.957196" + y="148.879" + id="use461" /> + <use + xlink:href="#glyph0-5" + x="37.385571" + y="148.879" + id="use463" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g477"> + <use + xlink:href="#glyph0-16" + x="45.131493" + y="148.879" + id="use467" /> + <use + xlink:href="#glyph0-3" + x="48.950157" + y="148.879" + id="use469" /> + <use + xlink:href="#glyph0-27" + x="51.330223" + y="148.879" + id="use471" /> + <use + xlink:href="#glyph0-11" + x="56.311523" + y="148.879" + id="use473" /> + <use + xlink:href="#glyph0-16" + x="61.459198" + y="148.879" + id="use475" /> + </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> + <use + xlink:href="#glyph0-17" + x="72.192903" + y="148.879" + id="use481" /> + <use + xlink:href="#glyph0-5" + x="77.340579" + y="148.879" + id="use483" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g495"> + <use + xlink:href="#glyph0-29" + x="85.096463" + y="148.879" + id="use487" /> + <use + xlink:href="#glyph0-30" + x="91.461568" + y="148.879" + id="use489" /> + <use + xlink:href="#glyph0-7" + x="96.996789" + y="148.879" + id="use491" /> + <use + xlink:href="#glyph0-31" + x="103.638854" + y="148.879" + id="use493" /> + </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> + <use + xlink:href="#glyph0-3" + x="40.580445" + y="160.834" + id="use499" /> + <use + xlink:href="#glyph0-18" + x="42.96051" + y="160.834" + id="use501" /> + <use + xlink:href="#glyph0-17" + x="46.558005" + y="160.834" + id="use503" /> + </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"/> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g517"> + <use + xlink:href="#glyph0-15" + x="71.321043" + y="160.834" + id="use515" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g531"> + <use + xlink:href="#glyph0-10" + x="77.859498" + y="160.834" + id="use519" /> + <use + xlink:href="#glyph0-2" + x="82.647523" + y="160.834" + id="use521" /> + <use + xlink:href="#glyph0-2" + x="85.027588" + y="160.834" + id="use523" /> + <use + xlink:href="#glyph0-5" + x="87.407653" + y="160.834" + id="use525" /> + <use + xlink:href="#glyph0-18" + x="91.836029" + y="160.834" + id="use527" /> <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;" + id="g541"> + <use + xlink:href="#glyph0-7" + x="148.628" + y="148.879" + id="use535" /> + <use + xlink:href="#glyph0-8" + x="155.270065" + y="148.879" + id="use537" /> + <use + xlink:href="#glyph0-9" + x="160.251365" + y="148.879" + id="use539" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g553"> + <use + xlink:href="#glyph0-16" + x="168.716587" + y="148.879" + id="use543" /> + <use + xlink:href="#glyph0-3" + x="172.535251" + y="148.879" + id="use545" /> + <use + xlink:href="#glyph0-27" + x="174.915316" + y="148.879" + id="use547" /> + <use + xlink:href="#glyph0-11" + x="179.896616" + y="148.879" + id="use549" /> + <use + xlink:href="#glyph0-16" + x="185.044292" + y="148.879" + id="use551" /> + </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> + <use + xlink:href="#glyph0-17" + x="195.78796" + y="148.879" + id="use557" /> + <use + xlink:href="#glyph0-5" + x="200.935635" + y="148.879" + id="use559" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g571"> + <use + xlink:href="#glyph0-29" + x="208.681557" + y="148.879" + id="use563" /> + <use + xlink:href="#glyph0-30" + x="215.046662" + y="148.879" + id="use565" /> + <use + xlink:href="#glyph0-7" + x="220.581882" + y="148.879" + id="use567" /> + <use + xlink:href="#glyph0-31" + x="227.223948" + y="148.879" + id="use569" /> + </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> + <use + xlink:href="#glyph0-3" + x="155.795445" + y="160.834" + id="use575" /> + <use + xlink:href="#glyph0-18" + x="158.17551" + y="160.834" + id="use577" /> + <use + xlink:href="#glyph0-17" + x="161.773005" + y="160.834" + id="use579" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g589"> + <use + xlink:href="#glyph0-17" + x="170.238226" + y="160.834" + id="use583" /> + <use + xlink:href="#glyph0-3" + x="175.385901" + y="160.834" + id="use585" /> + <use + xlink:href="#glyph0-16" + x="177.765966" + y="160.834" + id="use587" /> + </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-29" + x="190.44736" + y="160.834" + id="use593" /> + <use + xlink:href="#glyph0-36" + x="196.812465" + y="160.834" + id="use595" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g601"> + <use + xlink:href="#glyph0-15" + x="206.772076" + y="160.834" + id="use599" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g615"> + <use + xlink:href="#glyph0-10" + x="213.300568" + y="160.834" + id="use603" /> + <use + xlink:href="#glyph0-2" + x="218.088594" + y="160.834" + id="use605" /> + <use + xlink:href="#glyph0-2" + x="220.468659" + y="160.834" + id="use607" /> + <use + xlink:href="#glyph0-5" + x="222.848724" + y="160.834" + id="use609" /> <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> + <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)" + id="path617" /> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g623"> + <use + xlink:href="#glyph0-13" + x="271.522" + y="141.932" + id="use619" /> + <use + xlink:href="#glyph0-10" + x="277.887105" + y="141.932" + id="use621" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g631"> + <use + xlink:href="#glyph0-14" + x="282.396178" + y="141.932" + id="use625" /> + <use + xlink:href="#glyph0-8" + x="285.800398" + y="141.932" + id="use627" /> + <use + xlink:href="#glyph0-2" + x="290.781698" + y="141.932" + id="use629" /> + </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> + <use + xlink:href="#glyph0-3" + x="300.297974" + y="141.932" + id="use635" /> + <use + xlink:href="#glyph0-27" + x="302.678039" + y="141.932" + id="use637" /> + <use + xlink:href="#glyph0-11" + x="307.659339" + y="141.932" + id="use639" /> + <use + xlink:href="#glyph0-16" + x="312.807014" + y="141.932" + id="use641" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g651"> + <use + xlink:href="#glyph0-18" + x="319.953187" + y="141.932" + id="use645" /> + <use + xlink:href="#glyph0-17" + x="323.550682" + y="141.932" + id="use647" /> + <use + xlink:href="#glyph0-5" + x="328.698358" + y="141.932" + id="use649" /> + </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> + <use + xlink:href="#glyph0-30" + x="342.809384" + y="141.932" + id="use655" /> + <use + xlink:href="#glyph0-7" + x="348.344605" + y="141.932" + id="use657" /> + <use + xlink:href="#glyph0-31" + x="354.98667" + y="141.932" + id="use659" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g671"> + <use + xlink:href="#glyph0-15" + x="279.824" + y="153.888" + id="use663" /> + <use + xlink:href="#glyph0-3" + x="286.631445" + y="153.888" + id="use665" /> + <use + xlink:href="#glyph0-18" + x="289.01151" + y="153.888" + id="use667" /> + <use + xlink:href="#glyph0-17" + x="292.609005" + y="153.888" + id="use669" /> + </g> <g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> <use xlink:href="#glyph0-10" x="301.074226" y="153.888"/> </g> @@ -471,397 +1166,1381 @@ </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-21" x="318.589473" y="153.888"/> <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> + <use + xlink:href="#glyph0-18" + x="338.460875" + y="153.888" + id="use691" /> + <use + xlink:href="#glyph0-5" + x="342.05837" + y="153.888" + id="use693" /> + <use + xlink:href="#glyph0-2" + x="346.486745" + y="153.888" + id="use695" /> + <use + xlink:href="#glyph0-37" + x="348.866811" + y="153.888" + id="use697" /> + </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="280.97186" + y="165.843" + id="use705" /> + <use + xlink:href="#glyph0-11" + x="283.351925" + y="165.843" + id="use707" /> + <use + xlink:href="#glyph0-5" + x="288.499601" + y="165.843" + id="use709" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g727"> + <use + xlink:href="#glyph0-16" + x="296.245522" + y="165.843" + id="use713" /> + <use + xlink:href="#glyph0-3" + x="300.064187" + y="165.843" + id="use715" /> + <use + xlink:href="#glyph0-27" + x="302.444252" + y="165.843" + id="use717" /> + <use + xlink:href="#glyph0-11" + x="307.425552" + y="165.843" + id="use719" /> <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-10" x="336.315099" y="165.843"/> <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-17" + x="345.531501" + y="165.843" + id="use737" /> + <use + xlink:href="#glyph0-3" + x="350.679176" + y="165.843" + id="use739" /> + <use + xlink:href="#glyph0-11" + x="353.059241" + y="165.843" + id="use741" /> + <use + xlink:href="#glyph0-5" + x="358.206917" + y="165.843" + id="use743" /> <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;" + id="g759"> + <use + xlink:href="#glyph0-29" + x="169.328" + y="193.206" + id="use751" /> + <use + xlink:href="#glyph0-30" + x="175.693105" + y="193.206" + id="use753" /> + <use + xlink:href="#glyph0-7" + x="181.228326" + y="193.206" + id="use755" /> + <use + xlink:href="#glyph0-31" + x="187.870391" + y="193.206" + id="use757" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g763"> + <use + xlink:href="#glyph0-16" + x="193.824041" + y="193.206" + id="use761" /> + </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;" + id="g773"> + <use + xlink:href="#glyph0-14" + x="205.469324" + y="193.206" + id="use769" /> + <use + xlink:href="#glyph0-5" + x="208.873544" + y="193.206" + id="use771" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g791"> + <use + xlink:href="#glyph0-14" + x="154.84" + y="205.161" + id="use775" /> + <use + xlink:href="#glyph0-5" + x="158.24422" + y="205.161" + id="use777" /> + <use + xlink:href="#glyph0-18" + x="162.672596" + y="205.161" + id="use779" /> + <use + xlink:href="#glyph0-26" + x="166.270091" + y="205.161" + id="use781" /> + <use + xlink:href="#glyph0-14" + x="171.417766" + y="205.161" + id="use783" /> + <use + xlink:href="#glyph0-11" + x="174.821987" + y="205.161" + id="use785" /> + <use + xlink:href="#glyph0-5" + x="179.969662" + y="205.161" + id="use787" /> + <use + xlink:href="#glyph0-12" + x="184.398038" + y="205.161" + id="use789" /> + </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> + <use + xlink:href="#glyph0-8" + x="196.460754" + y="205.161" + id="use795" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g811"> + <use + xlink:href="#glyph0-1" + x="204.7596" + y="205.161" + id="use799" /> + <use + xlink:href="#glyph0-2" + x="211.401665" + y="205.161" + id="use801" /> + <use + xlink:href="#glyph0-3" + x="213.78173" + y="205.161" + id="use803" /> + <use + xlink:href="#glyph0-4" + x="216.161796" + y="205.161" + id="use805" /> + <use + xlink:href="#glyph0-5" + x="220.590171" + y="205.161" + id="use807" /> + <use + xlink:href="#glyph0-28" + x="225.018547" + y="205.161" + id="use809" /> + </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;" + id="g827"> + <use + xlink:href="#glyph0-1" + x="150.246" + y="230.588" + id="use815" /> + <use + xlink:href="#glyph0-2" + x="156.888065" + y="230.588" + id="use817" /> + <use + xlink:href="#glyph0-3" + x="159.268131" + y="230.588" + id="use819" /> + <use + xlink:href="#glyph0-4" + x="161.648196" + y="230.588" + id="use821" /> + <use + xlink:href="#glyph0-5" + x="166.076571" + y="230.588" + id="use823" /> + <use + xlink:href="#glyph0-16" + x="170.504947" + y="230.588" + id="use825" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g845"> + <use + xlink:href="#glyph0-4" + x="177.641157" + y="230.588" + id="use829" /> + <use + xlink:href="#glyph0-8" + x="182.069533" + y="230.588" + id="use831" /> + <use + xlink:href="#glyph0-21" + x="187.050833" + y="230.588" + id="use833" /> + <use + xlink:href="#glyph0-9" + x="194.966119" + y="230.588" + id="use835" /> + <use + xlink:href="#glyph0-3" + x="200.113794" + y="230.588" + id="use837" /> + <use + xlink:href="#glyph0-11" + x="202.493859" + y="230.588" + id="use839" /> + <use + xlink:href="#glyph0-5" + x="207.641535" + y="230.588" + id="use841" /> + <use + xlink:href="#glyph0-16" + x="212.069911" + y="230.588" + id="use843" /> + </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> + <use + xlink:href="#glyph0-17" + x="222.803616" + y="230.588" + id="use849" /> + <use + xlink:href="#glyph0-5" + x="227.951291" + y="230.588" + id="use851" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g863"> + <use + xlink:href="#glyph0-29" + x="153.304" + y="242.543" + id="use855" /> + <use + xlink:href="#glyph0-30" + x="159.669105" + y="242.543" + id="use857" /> + <use + xlink:href="#glyph0-7" + x="165.204326" + y="242.543" + id="use859" /> + <use + xlink:href="#glyph0-31" + x="171.846391" + y="242.543" + id="use861" /> + </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-28" + x="181.618705" + y="242.543" + id="use867" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g877"> + <use + xlink:href="#glyph0-1" + x="189.367616" + y="242.543" + id="use871" /> + <use + xlink:href="#glyph0-2" + x="196.009681" + y="242.543" + id="use873" /> + <use + xlink:href="#glyph0-2" + x="198.389746" + y="242.543" + id="use875" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g891"> + <use + xlink:href="#glyph0-3" + x="204.087357" + y="242.543" + id="use879" /> + <use + xlink:href="#glyph0-11" + x="206.467422" + y="242.543" + id="use881" /> <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> + <use + xlink:href="#glyph0-18" + x="221.910449" + y="242.543" + id="use887" /> + <use + xlink:href="#glyph0-16" + x="225.507944" + y="242.543" + id="use889" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g897"> + <use + xlink:href="#glyph0-11" + x="143.896" + y="254.498" + id="use893" /> + <use + xlink:href="#glyph0-8" + x="149.043675" + y="254.498" + id="use895" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g901"> + <use + xlink:href="#glyph0-15" + x="153.746023" + y="254.498" + id="use899" /> + </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-39" + x="173.806714" + y="254.498" + id="use907" /> + <use + xlink:href="#glyph0-5" + x="178.400469" + y="254.498" + id="use909" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g915"> + <use + xlink:href="#glyph0-24" + x="186.156353" + y="254.498" + id="use913" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g939"> + <use + xlink:href="#glyph0-16" + x="194.455199" + y="254.498" + id="use917" /> + <use + xlink:href="#glyph0-3" + x="198.273863" + y="254.498" + id="use919" /> <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> + <use + xlink:href="#glyph0-10" + x="210.782904" + y="254.498" + id="use925" /> + <use + xlink:href="#glyph0-18" + x="215.570929" + y="254.498" + id="use927" /> + <use + xlink:href="#glyph0-26" + x="219.168424" + y="254.498" + id="use929" /> + <use + xlink:href="#glyph0-14" + x="224.3161" + y="254.498" + id="use931" /> + <use + xlink:href="#glyph0-5" + x="227.72032" + y="254.498" + id="use933" /> + <use + xlink:href="#glyph0-16" + x="232.148696" + y="254.498" + id="use935" /> + <use + xlink:href="#glyph0-28" + x="235.96736" + y="254.498" + id="use937" /> + </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"/> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g953"> + <use + xlink:href="#glyph0-1" + x="154.972" + y="281.862" + id="use943" /> + <use + xlink:href="#glyph0-2" + x="161.614065" + y="281.862" + id="use945" /> + <use + xlink:href="#glyph0-3" + x="163.994131" + y="281.862" + id="use947" /> + <use + xlink:href="#glyph0-4" + x="166.374196" + y="281.862" + id="use949" /> + <use + xlink:href="#glyph0-5" + x="170.802571" + y="281.862" + id="use951" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g971"> + <use + xlink:href="#glyph0-35" + x="178.548493" + y="281.862" + id="use955" /> + <use + xlink:href="#glyph0-11" + x="183.889443" + y="281.862" + id="use957" /> <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-3" + x="196.205209" + y="281.862" + id="use963" /> + <use + xlink:href="#glyph0-40" + x="198.585274" + y="281.862" + id="use965" /> + <use + xlink:href="#glyph0-5" + x="202.916016" + y="281.862" + id="use967" /> + <use + xlink:href="#glyph0-16" + x="207.344392" + y="281.862" + id="use969" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g979"> + <use + xlink:href="#glyph0-18" + x="214.480602" + y="281.862" + id="use973" /> + <use + xlink:href="#glyph0-17" + x="218.078097" + y="281.862" + id="use975" /> + <use + xlink:href="#glyph0-5" + x="223.225773" + y="281.862" + id="use977" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g989"> <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-7" + x="154.869326" + y="293.817" + id="use985" /> + <use + xlink:href="#glyph0-31" + x="161.511391" + y="293.817" + id="use987" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g993"> + <use + xlink:href="#glyph0-9" + x="171.609482" + y="293.817" + id="use991" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g997"> + <use + xlink:href="#glyph0-37" + x="176.478205" + y="293.817" + id="use995" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1007"> + <use + xlink:href="#glyph0-4" + x="184.399468" + y="293.817" + id="use999" /> + <use + xlink:href="#glyph0-14" + x="188.827844" + y="293.817" + id="use1001" /> <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> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1017"> + <use + xlink:href="#glyph0-18" + x="201.438503" + y="293.817" + id="use1009" /> + <use + xlink:href="#glyph0-3" + x="205.035998" + y="293.817" + id="use1011" /> + <use + xlink:href="#glyph0-11" + x="207.416063" + y="293.817" + id="use1013" /> + <use + xlink:href="#glyph0-27" + x="212.563739" + y="293.817" + id="use1015" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1027"> + <use + xlink:href="#glyph0-5" + x="220.872547" + y="293.817" + id="use1019" /> + <use + xlink:href="#glyph0-10" + x="225.300923" + y="293.817" + id="use1021" /> + <use + xlink:href="#glyph0-4" + x="230.088948" + y="293.817" + id="use1023" /> + <use + xlink:href="#glyph0-17" + x="234.517324" + y="293.817" + id="use1025" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1043"> + <use + xlink:href="#glyph0-3" + x="145.944" + y="305.772" + id="use1029" /> + <use + xlink:href="#glyph0-11" + x="148.324065" + y="305.772" + id="use1031" /> + <use + xlink:href="#glyph0-19" + x="153.471741" + y="305.772" + id="use1033" /> + <use + xlink:href="#glyph0-26" + x="158.619416" + y="305.772" + id="use1035" /> + <use + xlink:href="#glyph0-18" + x="163.767091" + y="305.772" + id="use1037" /> + <use + xlink:href="#glyph0-41" + x="167.364586" + y="305.772" + id="use1039" /> + <use + xlink:href="#glyph0-16" + x="170.132197" + y="305.772" + id="use1041" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1053"> + <use + xlink:href="#glyph0-35" + x="177.268407" + y="305.772" + id="use1045" /> + <use + xlink:href="#glyph0-11" + x="182.609357" + y="305.772" + id="use1047" /> + <use + xlink:href="#glyph0-10" + x="187.757032" + y="305.772" + id="use1049" /> + <use + xlink:href="#glyph0-2" + x="192.545058" + y="305.772" + id="use1051" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1075"> + <use + xlink:href="#glyph0-16" + x="198.242669" + y="305.772" + id="use1055" /> + <use + xlink:href="#glyph0-4" + x="202.061333" + y="305.772" + id="use1057" /> + <use + xlink:href="#glyph0-14" + x="206.489709" + y="305.772" + id="use1059" /> + <use + xlink:href="#glyph0-3" + x="209.893929" + y="305.772" + id="use1061" /> + <use + xlink:href="#glyph0-19" + x="212.273995" + y="305.772" + id="use1063" /> + <use + xlink:href="#glyph0-18" + x="217.42167" + y="305.772" + id="use1065" /> + <use + xlink:href="#glyph0-30" + x="221.019165" + y="305.772" + id="use1067" /> + <use + xlink:href="#glyph0-3" + x="226.554385" + y="305.772" + id="use1069" /> + <use + xlink:href="#glyph0-27" + x="228.934451" + y="305.772" + id="use1071" /> + <use + xlink:href="#glyph0-28" + x="233.915751" + y="305.772" + id="use1073" /> + </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;" + id="g1103"> + <use + xlink:href="#glyph0-16" + x="175.345067" + y="317.727" + id="use1085" /> + <use + xlink:href="#glyph0-3" + x="179.163731" + y="317.727" + id="use1087" /> + <use + xlink:href="#glyph0-27" + x="181.543797" + y="317.727" + id="use1089" /> + <use + xlink:href="#glyph0-11" + x="186.525097" + y="317.727" + id="use1091" /> + <use + xlink:href="#glyph0-10" + x="191.672772" + y="317.727" + id="use1093" /> + <use + xlink:href="#glyph0-18" + x="196.460797" + y="317.727" + id="use1095" /> + <use + xlink:href="#glyph0-26" + x="200.058292" + y="317.727" + id="use1097" /> + <use + xlink:href="#glyph0-14" + x="205.205968" + y="317.727" + id="use1099" /> + <use + xlink:href="#glyph0-5" + x="208.610188" + y="317.727" + id="use1101" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1109"> + <use + xlink:href="#glyph0-20" + x="216.35611" + y="317.727" + id="use1105" /> + <use + xlink:href="#glyph0-8" + x="219.40068" + y="317.727" + id="use1107" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1113"> + <use + xlink:href="#glyph0-14" + x="224.103027" + y="317.727" + id="use1111" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1123"> + <use + xlink:href="#glyph0-5" + x="144.906" + y="329.682" + id="use1115" /> + <use + xlink:href="#glyph0-10" + x="149.334376" + y="329.682" + id="use1117" /> + <use + xlink:href="#glyph0-4" + x="154.122401" + y="329.682" + id="use1119" /> + <use + xlink:href="#glyph0-17" + x="158.550777" + y="329.682" + id="use1121" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1135"> + <use + xlink:href="#glyph0-3" + x="167.015998" + y="329.682" + id="use1125" /> + <use + xlink:href="#glyph0-11" + x="169.396063" + y="329.682" + id="use1127" /> + <use + xlink:href="#glyph0-19" + x="174.543739" + y="329.682" + id="use1129" /> + <use + xlink:href="#glyph0-26" + x="179.691414" + y="329.682" + id="use1131" /> + <use + xlink:href="#glyph0-18" + x="184.83909" + y="329.682" + id="use1133" /> + </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 + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1153"> + <use + xlink:href="#glyph0-12" + x="201.280368" + y="329.682" + id="use1143" /> + <use + xlink:href="#glyph0-14" + x="206.428044" + y="329.682" + id="use1145" /> + <use + xlink:href="#glyph0-8" + x="209.832264" + y="329.682" + id="use1147" /> + <use + xlink:href="#glyph0-19" + x="214.813564" + y="329.682" + id="use1149" /> + <use + xlink:href="#glyph0-19" + x="219.96124" + y="329.682" + id="use1151" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1161"> + <use + xlink:href="#glyph0-5" + x="225.377905" + y="329.682" + id="use1155" /> + <use + xlink:href="#glyph0-12" + x="229.806281" + y="329.682" + id="use1157" /> + <use + xlink:href="#glyph0-28" + x="234.953956" + y="329.682" + id="use1159" /> </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;" + id="g1179"> + <use + xlink:href="#glyph0-1" + x="154.951" + y="357.046" + id="use1169" /> + <use + xlink:href="#glyph0-2" + x="161.593065" + y="357.046" + id="use1171" /> + <use + xlink:href="#glyph0-3" + x="163.973131" + y="357.046" + id="use1173" /> + <use + xlink:href="#glyph0-4" + x="166.353196" + y="357.046" + id="use1175" /> + <use + xlink:href="#glyph0-5" + x="170.781571" + y="357.046" + id="use1177" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1197"> + <use + xlink:href="#glyph0-5" + x="178.527493" + y="357.046" + id="use1181" /> + <use + xlink:href="#glyph0-42" + x="182.955869" + y="357.046" + id="use1183" /> + <use + xlink:href="#glyph0-18" + x="187.549623" + y="357.046" + id="use1185" /> + <use + xlink:href="#glyph0-14" + x="191.147118" + y="357.046" + id="use1187" /> + <use + xlink:href="#glyph0-10" + x="194.551339" + y="357.046" + id="use1189" /> + <use + xlink:href="#glyph0-4" + x="199.339364" + y="357.046" + id="use1191" /> + <use + xlink:href="#glyph0-18" + x="203.76774" + y="357.046" + id="use1193" /> + <use + xlink:href="#glyph0-16" + x="207.365235" + y="357.046" + id="use1195" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1205"> + <use + xlink:href="#glyph0-18" + x="214.501445" + y="357.046" + id="use1199" /> + <use + xlink:href="#glyph0-17" + x="218.09894" + y="357.046" + id="use1201" /> + <use + xlink:href="#glyph0-5" + x="223.246616" + y="357.046" + id="use1203" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1213"> + <use + xlink:href="#glyph0-11" + x="154.709" + y="369.001" + id="use1207" /> + <use + xlink:href="#glyph0-5" + x="159.856675" + y="369.001" + id="use1209" /> + <use + xlink:href="#glyph0-18" + x="164.285051" + y="369.001" + id="use1211" /> + </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;" + id="g1221"> + <use + xlink:href="#glyph0-8" + x="174.132085" + y="369.001" + id="use1219" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1227"> + <use + xlink:href="#glyph0-14" + x="178.844395" + y="369.001" + id="use1223" /> + <use + xlink:href="#glyph0-43" + x="182.248615" + y="369.001" + id="use1225" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1249"> + <use + xlink:href="#glyph0-16" + x="190.436876" + y="369.001" + id="use1229" /> + <use + xlink:href="#glyph0-5" + x="194.255541" + y="369.001" + id="use1231" /> + <use + xlink:href="#glyph0-14" + x="198.683916" + y="369.001" + id="use1233" /> + <use + xlink:href="#glyph0-3" + x="202.088137" + y="369.001" + id="use1235" /> + <use + xlink:href="#glyph0-10" + x="204.468202" + y="369.001" + id="use1237" /> + <use + xlink:href="#glyph0-2" + x="209.256228" + y="369.001" + id="use1239" /> + <use + xlink:href="#glyph0-3" + x="211.636293" + y="369.001" + id="use1241" /> + <use + xlink:href="#glyph0-40" + x="214.016358" + y="369.001" + id="use1243" /> + <use + xlink:href="#glyph0-5" + x="218.3471" + y="369.001" + id="use1245" /> + <use + xlink:href="#glyph0-12" + x="222.775476" + y="369.001" + id="use1247" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1273"> + <use + xlink:href="#glyph0-18" + x="159.075" + y="380.956" + id="use1251" /> + <use + xlink:href="#glyph0-14" + x="162.672495" + y="380.956" + id="use1253" /> + <use + xlink:href="#glyph0-10" + x="166.076715" + y="380.956" + id="use1255" /> + <use + xlink:href="#glyph0-11" + x="170.864741" + y="380.956" + id="use1257" /> + <use + xlink:href="#glyph0-16" + x="176.012416" + y="380.956" + id="use1259" /> + <use + xlink:href="#glyph0-10" + x="179.831081" + y="380.956" + id="use1261" /> + <use + xlink:href="#glyph0-4" + x="184.619106" + y="380.956" + id="use1263" /> + <use + xlink:href="#glyph0-18" + x="189.047482" + y="380.956" + id="use1265" /> + <use + xlink:href="#glyph0-3" + x="192.644977" + y="380.956" + id="use1267" /> + <use + xlink:href="#glyph0-8" + x="195.025042" + y="380.956" + id="use1269" /> + <use + xlink:href="#glyph0-11" + x="200.006342" + y="380.956" + id="use1271" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1281"> + <use + xlink:href="#glyph0-10" + x="208.471563" + y="380.956" + id="use1275" /> + <use + xlink:href="#glyph0-11" + x="213.259589" + y="380.956" + id="use1277" /> + <use + xlink:href="#glyph0-12" + x="218.407264" + y="380.956" + id="use1279" /> + </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;" + id="g1305"> + <use + xlink:href="#glyph0-14" + x="169.713723" + y="392.911" + id="use1287" /> + <use + xlink:href="#glyph0-8" + x="173.117943" + y="392.911" + id="use1289" /> + <use + xlink:href="#glyph0-10" + x="178.099243" + y="392.911" + id="use1291" /> + <use + xlink:href="#glyph0-12" + x="182.887269" + y="392.911" + id="use1293" /> + <use + xlink:href="#glyph0-4" + x="188.034944" + y="392.911" + id="use1295" /> + <use + xlink:href="#glyph0-10" + x="192.46332" + y="392.911" + id="use1297" /> + <use + xlink:href="#glyph0-16" + x="197.251345" + y="392.911" + id="use1299" /> + <use + xlink:href="#glyph0-18" + x="201.07001" + y="392.911" + id="use1301" /> + <use + xlink:href="#glyph0-16" + x="204.667505" + y="392.911" + id="use1303" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1311"> + <use + xlink:href="#glyph0-3" + x="211.803715" + y="392.911" + id="use1307" /> + <use + xlink:href="#glyph0-18" + x="214.18378" + y="392.911" + id="use1309" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1317"> + <use + xlink:href="#glyph0-18" + x="159.532" + y="404.866" + id="use1313" /> + <use + xlink:href="#glyph0-8" + x="163.129495" + y="404.866" + id="use1315" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1325"> + <use + xlink:href="#glyph0-18" + x="171.428341" + y="404.866" + id="use1319" /> + <use + xlink:href="#glyph0-17" + x="175.025836" + y="404.866" + id="use1321" /> + <use + xlink:href="#glyph0-5" + x="180.173511" + y="404.866" + id="use1323" /> + </g> + <g + style="fill:rgb(0%,0%,0%);fill-opacity:1;" + id="g1333"> + <use + xlink:href="#glyph0-11" + x="187.919432" + y="404.866" + id="use1327" /> + <use + xlink:href="#glyph0-5" + x="193.067108" + y="404.866" + id="use1329" /> + <use + xlink:href="#glyph0-18" + x="197.495484" + y="404.866" + id="use1331" /> + </g> <g style="fill:rgb(0%,0%,0%);fill-opacity:1;"> <use xlink:href="#glyph0-15" x="200.823988" y="404.866"/> </g> @@ -873,23 +2552,173 @@ <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 "/> +<path style="fill:none;stroke-width:1.59404;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.538937 " transform="matrix(1,0,0,-1,191.315,205.953)"/> +<path style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 6.054429 0.000445 L 2.171616 1.477007 L 3.48021 0.000445 L 2.171616 -1.480024 Z M 6.054429 0.000445 " transform="matrix(0,1,1,0,65.98393,130.26979)"/> +<path style="fill:none;stroke-width:1.59404;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.187375 " transform="matrix(1,0,0,-1,191.315,205.953)"/> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.053411 0.00140625 L 2.170599 1.477969 L 3.479193 0.00140625 L 2.170599 -1.479062 Z M 6.053411 0.00140625 " + transform="matrix(0,1,1,0,191.315,46.62237)" + id="path1357" /> + <path + style="fill:none;stroke-width:1.59404;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 104.913937 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1359" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.056245 0.00140625 L 2.173433 1.477969 L 3.482026 0.00140625 L 2.173433 -1.479062 Z M 6.056245 0.00140625 " + transform="matrix(0,1,1,0,191.315,97.89688)" + id="path1361" /> + <path + style="fill:none;stroke-width:1.59404;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.538937 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1363" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.054429 0.00140625 L 2.171616 1.477969 L 3.48021 0.00140625 L 2.171616 -1.479062 Z M 6.054429 0.00140625 " + transform="matrix(0,1,1,0,191.315,130.26979)" + id="path1365" /> + <path + style="fill:none;stroke-width:1.59404;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 -9.172 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1367" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.055156 0.00140625 L 2.172344 1.477969 L 3.480938 0.00140625 L 2.172344 -1.479062 Z M 6.055156 0.00140625 " + transform="matrix(0,1,1,0,191.315,211.98)" + id="path1369" /> + <path + style="fill:none;stroke-width:1.59404;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.445438 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1371" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.054094 0.00140625 L 2.171281 1.477969 L 3.479875 0.00140625 L 2.171281 -1.479062 Z M 6.054094 0.00140625 " + transform="matrix(0,1,1,0,191.315,263.2545)" + id="path1373" /> + <path + style="fill:none;stroke-width:1.59404;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.629031 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1375" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.056464 0.00140625 L 2.173651 1.477969 L 3.478339 0.00140625 L 2.173651 -1.479062 Z M 6.056464 0.00140625 " + transform="matrix(0,1,1,0,191.315,338.43963)" + id="path1377" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M -56.022031 92.906125 L -125.330625 92.906125 L -125.330625 72.929562 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1379" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.402085 0.000445 L 0.644273 2.539507 L 2.85521 0.000445 L 0.644273 -2.542524 Z M 7.402085 0.000445 " + transform="matrix(0,1,1,0,65.98393,130.26979)" + id="path1381" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 0.00140625 162.429562 L 0.00140625 156.578 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1383" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.401068 0.00140625 L 0.643255 2.540469 L 2.854193 0.00140625 L 0.643255 -2.541562 Z M 7.401068 0.00140625 " + transform="matrix(0,1,1,0,191.315,46.62237)" + id="path1385" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 0.00140625 111.156125 L 0.00140625 105.300656 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1387" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.403901 0.00140625 L 0.642183 2.540469 L 2.85312 0.00140625 L 0.642183 -2.541562 Z M 7.403901 0.00140625 " + transform="matrix(0,1,1,0,191.315,97.89688)" + id="path1389" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 0.00140625 85.730344 L 0.00140625 72.929562 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1391" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.402085 0.00140625 L 0.644273 2.540469 L 2.85521 0.00140625 L 0.644273 -2.541562 Z M 7.402085 0.00140625 " + transform="matrix(0,1,1,0,191.315,130.26979)" + id="path1393" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 0.00140625 -2.925906 L 0.00140625 -8.781375 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1395" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.402813 0.00140625 L 0.645 2.540469 L 2.852031 0.00140625 L 0.645 -2.541562 Z M 7.402813 0.00140625 " + transform="matrix(0,1,1,0,191.315,211.98)" + id="path1397" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 0.00140625 -54.20325 L 0.00140625 -60.054813 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1399" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.40175 0.00140625 L 0.643938 2.540469 L 2.854875 0.00140625 L 0.643938 -2.541562 Z M 7.40175 0.00140625 " + transform="matrix(0,1,1,0,191.315,263.2545)" + id="path1401" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 0.00140625 -129.386844 L 0.00140625 -135.242313 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1403" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.40412 0.00140625 L 0.642401 2.540469 L 2.853339 0.00140625 L 0.642401 -2.541562 Z M 7.40412 0.00140625 " + transform="matrix(0,1,1,0,191.315,338.43963)" + id="path1405" /> + <path + style="fill:none;stroke-width:1.59404;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.48425 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1407" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.055376 -0.00153875 L 2.172564 1.47893 L 3.481158 -0.00153875 L 2.172564 -1.478101 Z M 6.055376 -0.00153875 " + transform="matrix(0,1,1,0,316.64607,123.32353)" + id="path1409" /> + <path + style="fill:none;stroke-width:1.59404;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.210812 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1411" /> + <path + style="fill-rule:nonzero;fill:rgb(0%,0%,0%);fill-opacity:1;stroke-width:1.34497;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 6.054314 0.00140625 L 2.171501 1.477969 L 3.480095 0.00140625 L 2.171501 -1.479062 Z M 6.054314 0.00140625 " + transform="matrix(0,1,1,0,191.315,174.59803)" + id="path1413" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);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.874875 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1415" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.403033 -0.00153875 L 0.64522 2.54143 L 2.852251 -0.00153875 L 0.64522 -2.540601 Z M 7.403033 -0.00153875 " + transform="matrix(0,1,1,0,316.64607,123.32353)" + id="path1417" /> + <path + style="fill:none;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(100%,100%,100%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 0.00140625 41.402219 L 0.00140625 28.601437 " + transform="matrix(1,0,0,-1,191.315,205.953)" + id="path1419" /> + <path + style="fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.3985;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" + d="M 7.40197 0.00140625 L 0.644158 2.540469 L 2.855095 0.00140625 L 0.644158 -2.541562 Z M 7.40197 0.00140625 " + transform="matrix(0,1,1,0,191.315,174.59803)" + id="path1421" /> </g> </svg> diff --git a/bip-0174/multisig-workflow.tex b/bip-0174/multisig-workflow.tex index 2b8744d..d2250cf 100644 --- a/bip-0174/multisig-workflow.tex +++ b/bip-0174/multisig-workflow.tex @@ -7,7 +7,7 @@ \usepackage{lmodern} \renewcommand*\familydefault{\sfdefault} \usepackage{tikz} -\usetikzlibrary{shapes,arrows} +\usetikzlibrary{shapes,arrows.meta} \tikzset{>=latex} %\pgfdeclarelayer{bg} % declare background layer %\pgfsetlayers{bg,main} % set order of layers @@ -83,7 +83,15 @@ };% end matrix % connecting nodes with paths % \begin{pgfonlayer}{bg} - \draw[line width = 1pt, ->] + \draw [ultra thick, draw=black, -{Stealth[length=8pt]}] + (R1) edge (R2) + (R2) edge (R3) + (R3) -| (R4C1) + (R3) edge (R4C2) + (R5) edge (R6) + (R6) edge (R7) + (R7) edge (stop); + \draw [thin, white, -{Stealth[color=black, fill=white, length=8pt]}] (R1) edge (R2) (R2) edge (R3) (R3) -| (R4C1) @@ -92,7 +100,12 @@ (R6) edge (R7) (R7) edge (stop); % circumvent missing arrow - \draw[line width = 1pt, ->] + \draw [ultra thick, draw=black, -{Stealth[length=8pt]}] + (R4C1) |-+(0,-2.2em)-| (R5) + (R4C2) edge (R5) + (R4C3) |-+(0,-2.2em)-| (R5) + (R3) -| (R4C3); + \draw [thin, white, -{Stealth[color=black, fill=white, length=8pt]}] (R4C1) |-+(0,-2.2em)-| (R5) (R4C2) edge (R5) (R4C3) |-+(0,-2.2em)-| (R5) diff --git a/bip-0176.mediawiki b/bip-0176.mediawiki index 60311c4..2f5ee9f 100644 --- a/bip-0176.mediawiki +++ b/bip-0176.mediawiki @@ -16,7 +16,7 @@ Bits is presented here as the standard term for 100 (one hundred) satoshis or 1/ == 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. +Additionally, reverse comparisons are easier as 59 bits being $1 is easier to comprehend for most people than 0.000059 BTC being $1. Similar comparisons can be made to other currencies: 1 yen being 0.8 bits, 1 won being 0.07 bits and so on. Potential benefits of utilizing "bits" include: diff --git a/bip-0197.mediawiki b/bip-0197.mediawiki index 427ff22..2cac042 100644 --- a/bip-0197.mediawiki +++ b/bip-0197.mediawiki @@ -79,7 +79,7 @@ The Seizable Collateral script takes the following form: ==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. +BIP 197 is compatible with [https://github.com/ethereum/EIPs/pull/1850 ERC 1850] for [https://arxiv.org/pdf/1901.05117.pdf atomic loans] with Ethereum. Can be extended in the future to be compatible with other HTLC and smart contract compatible chains. ==Motivation== diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki index 20d1936..e5048e7 100644 --- a/bip-0300.mediawiki +++ b/bip-0300.mediawiki @@ -75,54 +75,44 @@ D1 is a list of active sidechains. D1 is updated via M1 and M2. | Version number. |- | 3 -| String KeyID -| string -| Used to derive all sidechain deposit addresses. -|- -| 4<br /> -| Sidechain Private Key -| string -| The private key of the sidechain deposit script. -|- style="vertical-align:middle;" -| 5<br /> -| ScriptPubKey -| CScript -| Where the sidechain coins go. This always stays the same, even though the CTIP (UTXO) containing the coins is always changing. -|- style="vertical-align:middle;" -| 6 | Sidechain Name | string | A human-readable name of the sidechain. |- style="vertical-align:middle;" -| 7 +| 4 | Sidechain Description | string | A human-readable name description of the sidechain. |- style="vertical-align:middle;" -| 8 +| 5 | Hash1 - tarball hash | uint256 | Intended as the sha256 hash of the tar.gz of the canonical sidechain software. (This is not enforced anywhere by Bip300, and is for human purposes only.) |- style="vertical-align:middle;" -| 9 +| 6 | Hash2 - git commit hash | uint160 | Intended as the git commit hash of the canonical sidechain node software. (This is not enforced anywhere by Bip300, and is for human purposes only.) |- -| 10 +| 7 | Active | bool | Does this sidechain slot contain an active sidechain?<br /> |- style="vertical-align:middle;" -| 11 -| "CTIP" -- Part 1 "TxID" +| 8 +| Activation Status +| int , int +| The age of the proposal (in blocks); and the number of "fails" (a block that does NOT ack the sidechain). This is discarded after the sidechain activates. +|- style="vertical-align:middle;" +| 9 +| "CTIP" -- "TxID" | uint256 -| The CTIP, or "Critical (TxID, Index) Pair" is a variable for keeping track of where the sidechain's money is (ie, which member of the UTXO set). +| A UTXO that holds the sidechain's money. (Part 1 of 2). |- style="vertical-align:middle;" -| 12 -| "CTIP" -- Part 2 "Index" +| 10 +| "CTIP" -- "vout" | int32_t -| Of the CTIP, the second element of the pair: the Index. See #11 above. +| A UTXO that holds the sidechain's money. (Part 2 of 2). |} @@ -138,7 +128,7 @@ D2 is driven by M3, M4, M5, and M6. Those messages enforce the following princip # From one block to the next, the value in "ACKs" may either increase or decrease, by a maximum of 1 (see M4). # If a Bundle's "ACKs" reach 13150 or greater, it "succeeds" and its corresponding M6 message can be included in a block. # If the M6 of a Bundle is paid out, it is also removed. -# If a Bundle cannot possibly succeed ( 13500 - "ACKs" > "Blocks Remaining" ), it is removed immediately. +# If a Bundle cannot possibly succeed ( 13150 - "ACKs" > "Blocks Remaining" ), it is removed immediately. {| class="wikitable" @@ -158,19 +148,21 @@ D2 is driven by M3, M4, M5, and M6. Those messages enforce the following princip | A withdrawal attempt. Specifically, it is a "blinded transaction id" (ie, the double-Sha256 of a txn that has had two fields zeroed out, see M6) of a txn which could withdraw funds from a sidechain. |- | 3 -| ACKs (Work Score) +| Work Score (ACKs) | uint16_t -| The current ACK-counter, which is the total number of ACKs (the PoW that has been used to validate the Bundle). +| How many miner upvotes a withdrawal has. Starts at 0. Fastest possible rate of increase is 1 per block. |- | 4 -| Blocks Remaining (Age) +| Blocks Remaining | uint16_t -| The number of blocks which this Bundle has remaining to accumulate ACKs +| How long this bundle has left to live (measured in blocks). Starts at 26,300 and counts down. |} +D1, with all 256 slots active, reaches a maximum size of: 256 * ( 1 (map index) + 36 (outpoint) + 8 (amount) ) = 11,520 bytes. +D2, under normal conditions, would reach a size of: (38 bytes per withdrawal * 256 sidechains) = 9,728 bytes. - +It is possible to spam D2. A miner can add the max M3s (256) every block, forever. This costs 9,728 on-chain bytes per block, an opportunity cost of about 43 txns. It results in no benefit to the miner whatsoever. D2 will eventually hit a ceiling at 124.5568 MB. (By comparison, the Bitcoin UTXO set is about 7,000 MB.) When the attacker stops, D2 will eventually shrink back down to 9,728 bytes. === The Six New Bip300 Messages === @@ -188,19 +180,22 @@ M1 is a coinbase OP Return output containing the following: N-byte - The serialization of the sidechain. 1-byte nSidechain 4-byte nVersion - x-byte strKeyID - x-byte strPrivKey - x-byte scriptPubKey x-byte title x-byte description 32-byte hashID1 20-byte hashID2 -===== Examples ===== -<img src="bip-0300/m1-gui.jpg?raw=true" align="middle"></img> +M1 is invalid if: + +* It would add a duplicate entry to D1. +* There is already an M1 in this block. +* The sidechain serialization does not parse. + +Otherwise: + +* A new entry is added to D1, whose initial Activation Status is (age=0, fails=0). -<img src="bip-0300/m1-cli.png?raw=true" align="middle"></img> ==== M2 -- ACK Sidechain Proposal ==== @@ -208,14 +203,30 @@ M2 is a coinbase OP Return output containing the following: 1-byte - OP_RETURN (0x6a) 4-byte - Message header (0xD6E1C5BF) - 32-byte - sha256D hash of sidechain's serialization + 32-byte - the sha256D hash of sidechain's serialization + -===== Notes ===== +M2 is ignored if it doesn't parse, or if it is for a sidechain that doesn't exist. -The new M1/M2 validation rules are: +M2 is invalid if: -# Any miner can propose a new sidechain (M1) at any time. This procedure resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgment" of the sidechain (M2) in 90% of the following 2016 blocks. -# Bip300 comes with only 256 sidechain-slots. If all are used, it is possible to "overwrite" a sidechain. This requires vastly more M2 ACKs -- 50% of the following 26300 blocks must contain an M2. The possibility of overwrite, does not change the Bip300 security assumptions (because we already assume that the sidechain is vulnerable to miners, at a rate of 1 catastrophe per 13150 blocks). +* An M2 is already in this block. +* It tries to ACK two different M1s for the same slot. + +Otherwise: + +* The sidechain is "ACK"ed and does NOT get a "fail" for this block. (As it otherwise would.) + +A sidechain fails to activate if: + +* If the slot is unused: during the next 2016 blocks, it accumulates 201 fails. (Ie, 90% threshold). +* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails. (Ie, 50% threshold). + +( Thus we can overwrite a used sidechain slot. Bip300 sidechains are already vulnerable to one catastrophe per 13150 blocks (the invalid withdrawal) so this slot-overwrite option does not change the security assumptions. ) + +Otherwise, the sidechain activates (Active is set to TRUE). + +In the block in which the sidechain activates, the coinbase MUST include at least one 0-valued OP_DRIVECHAIN output. This output becomes the initial CTIP for the sidechain. @@ -227,7 +238,7 @@ For an M6 to be valid, it must be first "prepped" by one M3 and then 13,150+ M4s ===== What are Bundles? ===== -Sidechain withdrawals take the form of “Bundles” -- named because they "bundle up" many individual withdrawal-requests into a single rare layer1 transaction. +Sidechain withdrawals take the form of "Bundles" -- named because they "bundle up" many individual withdrawal-requests into a single rare layer1 transaction. Sidechain full nodes aggregate the withdrawal-requests into a big set. The sidechain calculates what M6 would have to look like, to pay all of these withdrawal-requests out. Finally, the sidechain calculates what the hash of this M6 would be. This 32-byte hash identifies the Bundle. @@ -248,11 +259,18 @@ M3 is a coinbase OP Return output containing the following: 1-byte - OP_RETURN (0x6a) 4-byte - Commitment header (0xD45AA943) 32-byte - The Bundle hash, to populate a new D2 entry + 1-byte - nSidechain (the slot number) + +M3 is ignored if it does not parse, or if it is for a sidechain that doesn't exist. + +M3 is invalid if: -The new validation rules pertaining to M3 are: +* This block already has an M3 for that nSidechain. +* A bundle with this hash is already in D2. +* A bundle with this hash already paid out. +* A bundle with this hash was rejected in the past. -# If the network detects a properly-formatted M3, it must add an entry to D2 in the very next block. The starting "Blocks Remaining" value is 26,299. The starting ACKs count is 1. -# Each block can only contain one M3 per sidechain. +Otherwise: M3 adds an entry to D2, with initial ACK score = 1 and initial Blocks Remaining = 26,299. (Merely being added to D2, does count as your first upvote.) Once a Bundle is in D2, how can we give it enough ACKs to make it valid? @@ -263,44 +281,199 @@ M4 is a coinbase OP Return output containing the following: 1-byte - OP_RETURN (0x6a) 4-byte - Commitment header (0xD77D1776) 1-byte - Version - n-byte - The vector describing the "upvoted" bundle-choice, for each sidechain. + n-byte - The "upvote vector" -- describes which bundle-choice is "upvoted", for each sidechain. -Version 0x01 uses one byte per sidechain, and applies in most cases. Version 0x02 uses two bytes per sidechain and applies in unusual situations where at least one sidechain has more than 256 distinct withdrawal-bundles in progress at one time. Other interesting versions are possible: 0x03 might say "do exactly what was done in the previous block" (which could consume a fixed 6 bytes total, regardless of how many sidechains). 0x04 might say "upvote everyone who is clearly in the lead" (which also would require a mere 6 bytes), and so forth. +The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm" as 0xFE (or 0xFFFE). Otherwise it simply indicates which withdrawal-bundle in the list, is the one to be "upvoted". + +For example: if there are two sidechains, and we wish to upvote the 7th bundle on sidechain #1 plus the 4th bundle on sidechain #2, then the upvote vector would be { 07, 04 }. And M4 would be [0x6A,D77D1776,00,0006,0003]. + +The version number allows us to shrink the upvote vector in many cases. +Version 0x00 omits the upvote vector entirely (ie, 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4. +Version 0x01 uses one byte per sidechain, and can be used while all ACKed withdrawals have an index under 256 (ie, 99.99%+ of the time). +Version 0x02 uses a full two bytes per sidechain (each encoded in little endian), but it always works no matter how many withdrawal proposals exist. +Version 0x03 omits the upvote vector, and instead upvotes only those withdrawals that are leading their rivals by at least 50 votes. If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed. -The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm" as 0xFE (or 0xFFFE). Otherwise it simply indicates which withdrawal-bundle in the list, is the one to be "upvoted". For example, if there are two sidechains, and we wish to upvote the 7th bundle on sidechain #1 plus the 4th bundle on sidechain #2, then the vector would be 0x0704. +For example, an upvote vector of { 2 , N/A, 1 } would be represented as [0x6A,D77D1776,01,01,00]. It means: "upvote the second bundle in sidechain #1; and the first bundle in sidechain #3" (iff sidechains #2 has no bundles proposed). -The M4 message will be invalid (and invalidate the block), if it tries to upvote a Bundle that doesn't exist (for example, trying to upvote the 7th bundle on sidechain #2, when sidechain #2 has only three bundles). If there are no Bundles at all (no one is trying to withdraw from any sidechain), then *any* M4 message present in the coinbase will be invalid. If M4 is NOT present in a block, then it is treated as "abstain". +An upvote vector of { N/A, N/A, 4 } would be [0x6A,D77D1776,01,03]. -The ACKed withdrawal will gain one point for its ACK field. Therefore, the ACK-counter of any Bundle can only change by (-1,0,+1). -Within a sidechain-group, upvoting one Bundle ("+1") requires you to downvote all other Bundles in that group. However, the minimum ACK-counter is zero. While only one Bundle can be upvoted at once; the whole group can all be unchanged at once ("abstain"), and they can all be downvoted at once ("alarm"). +The M4 message will be invalid (and invalidate the block), if: + +* It tries to upvote a Bundle that doesn't exist. (For example, trying to upvote the 7th bundle on sidechain #2, when sidechain #2 has only three bundles.) +* There are no Bundles at all, from any sidechain. + +If M4 is NOT present in a block, then it is treated as "abstain". + +If M4 is present and valid: each withdrawal-bundle that is ACKed, will gain one upvote. + +Important: Within a sidechain-group, upvoting one Bundle ("+1") automatically downvotes ("-1") all other Bundles in that group. However, the minimum ACK-counter is zero. While only one Bundle can be upvoted at once; the whole group can all be unchanged at once ("abstain"), and they can all be downvoted at once ("alarm"). + +For example: + +{| class="wikitable" +|- +! SC# +! Bundle Hash +! ACKs +! Blocks Remaining +|- +| 1 +| h1 +| 45 +| 22,109 +|- +| 1 +| h2 +| 12 +| 22,008 +|- +| 2 +| h3 +| 13 +| 22,999 +|- +| 2 +| h4 +| 8 +| 23,550<br /> +|- +| 2 +| h5 +| 2 +| 22,560 +|} + + +...in block 900,000 could become... + + +{| class="wikitable" +|- +! SC# +! Bundle Hash +! ACKs +! Blocks Remaining +|- +| 1 +| h1 +| 46 +| 22,108 +|- +| 1 +| h2 +| 11 +| 22,007 +|- +| 2 +| h3 +| 12 +| 22,998 +|- +| 2 +| h4 +| 9 +| 23,549<br /> +|- +| 2 +| h5 +| 1 +| 22,559 +|} + +...if M4 were [0x6A,D77D1776,00,0000,0001]. -Finally, we describe Deposits and Withdrawals. +Finally, we describe Deposits and Withdrawals. ==== M5 -- Deposit BTC to Sidechain ==== -Both M5 and M6 are regular Bitcoin txns. They are distinguished from regular txns (non-M5 non-M6 txns), when they select one of the special Bip300 CTIP UTXOs as one of their inputs (see D1). +Each sidechain stores all its BTC in one UTXO, called the "CTIP". + +By definition, an M5 is a transaction which spends the CTIP and '''increases''' the quantity of coins. An M6 is a transaction which spends the CTIP and '''decreases''' the quantity of coins in the CTIP. See [https://github.com/LayerTwo-Labs/mainchain/blob/391ab390adaa19f92871d769f8e120ca62c1cf14/src/validation.cpp#L688-L801 here]. + +Every time a deposit/withdrawal is made, the old CTIP is spent and a new one is created. (Deposits/Withdrawals never cause UTXO bloat.) At all times, the CTIP of each sidechain is cached in D1 (above). -All of a sidechain’s coins, are stored in one UTXO, called the "CTIP". Every time a deposit or withdrawal is made, the CTIP changes. Each deposit/withdrawal will select the sidechains CTIP, and generate a new CTIP. (Deposits/Withdrawals never cause UTXO bloat.) The current CTIP is cached in D1 (above). +Every M5 is valid, as long as: -If the '''quantity of coins''', in the from-CTIP-to-CTIP transaction, goes '''up''', (ie, if the user is adding coins), then the txn is treated as a Deposit (M5). Else it is treated as a Withdrawal (M6). See [https://github.com/drivechain-project/mainchain/blob/e37b008fafe0701b8313993c8b02ba41dc0f8a29/src/validation.cpp#L667-L780 here]. +* It has exactly one OP_DRIVECHAIN output -- this becomes the new CTIP. +* The new CTIP has '''more''' coins in it, than before. -As far as mainchain consensus is concerned, all deposits to a sidechain are always valid. ==== M6 -- Withdraw BTC from a Sidechain ==== We come, finally, to the critical matter: where users can take their money *out* of the sidechain. -First, M6 must obey the same CTIP rules of M5 (see immediately above). +M6 is invalid if: + +* The blinded hash of M6 does NOT match one of the approved Bundle-hashes. (In other words: M6 must first be approved by 13,150 upvotes.) +* The first output of M6 is NOT an OP_DRIVECHAIN. (This OP_DRIVECHAIN becomes the new CTIP. In other words: all non-withdrawn coins are paid back to the sidechain.) +* The second output is NOT a zero-value OP_RETURN script of exactly 10 bytes, of which 8 bytes are a serialized Bitcoin amount. +* The txn fee of M6 is NOT exactly equal to the amount of the previous bullet point. +* There are additional OP_DRIVECHAIN outputs after the first one. + +Else, M6 is valid. + +(The point of the latter two bullet points, is to allow the bundle hash to cover the L1 transaction fee.) -Second, an M6 is only valid for inclusion in a block, if its blinded TxID matches an "approved" Bundle hash (ie, one with an ACK score of 13150+). In other words, an M6 can only be included in a block, after the 3+ month (13150 block) ceremony. +===OP_DRIVECHAIN=== + +This proposal adds a single new opcode, OP_DRIVECHAIN, which has strict semantics for usage. +OP_NOP5 (0xb4) is redefined as OP_DRIVECHAIN if and only if the entire script is OP_DRIVECHAIN followed by a single-byte push and OP_TRUE (exactly 4 bytes). +The single-byte push contains the sidechain number. +Note that this is not a "script number", and cannot be OP_1..OP_16 or any other kind of push; it is also unsigned, and must not be padded even if over sidechain number 127. +The final OP_TRUE is to ensure this change remains a softfork: +without it, sidechain numbers 0 and 128 would cause the legacy script interpreter to fail. + +If an OP_DRIVECHAIN input is spent, the additional rules for M5 or M6 (see above) must be enforced. + +====Weight adjustments==== + +To account for the additional drivechain checks, each message adds to the block's weight: + +{|class="wikitable" +! Message !! Additional weight +|- +| M1 || 840 +|- +| M2 || 336 +|- +| M3 || 848 +|- +| M4 || ? +|- +| M5 || 340 +|- +| M6 || 352 +|} -Third, M6 must meet two accounting criteria, lest it be invalid: -# "Give change back to Escrow" -- The first output, TxOut0, must be paid back to the sidechain's Bip300 script. In other words, all non-withdrawn coins must be paid back into the sidechain. -# "No traditional txn fee" -- For this txn, the sum of all inputs must equal the sum of all outputs. No traditional tx fee is possible. (Of course, there is still a txn fee for miners: it is paid via an OP TRUE output in the Bundle.) We want the withdraw-ers to set the fee "inside" the Bundle, and ACK it over 3 months like everything else. +<!-- +get: 168 WU for 1 byte +delete: free? +create: 168 WU for 33 bytes +hash: 4 WU?? +search outputs: ? +permanent "proposal rejected" lookup: infinite?? +read prev block: a lot?? maybe store... +comparison: 4 WU? +encode script: ? + +M1: 3 get, 2 create +M2: 1 get, 1 delete, 1 create +M3: 3 get, 1 delete, 2 create, 2 hash + for each coinbase output: search for prior M3 for this sidechain + lookup if M3 was ever rejected or paid in the past + for each prior proposed withdrawal: (included in 1 get+delete+create) +M4: 1 get + + for every proposed withdraw, 1 get, 1 delete, 1 create, 1 add + v0 needs to read and parse previous block +M5/M6 OP_DRIVECHAIN spends require 2 additional input lookups + for each output: check for duplicate OP_DRIVECHAINs + amount comparison + M6: encode & compare fee amount, 2 hash, counter compare +--> ==Backward compatibility== @@ -331,7 +504,7 @@ See http://www.drivechain.info/literature/index.html ==Credits== -Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Chris Stewart, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Ben Goldhaber. +Thanks to everyone who contributed to the discussion, especially: Luke Dashjr, ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Chris Stewart, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Ben Goldhaber. ==Copyright== diff --git a/bip-0310.mediawiki b/bip-0310.mediawiki index 257e92a..34522be 100644 --- a/bip-0310.mediawiki +++ b/bip-0310.mediawiki @@ -190,7 +190,7 @@ send the mask, in this case a default full mask is used. * '''"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. +::- 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 [https://github.com/bitcoin/bips/pull/661/files Draft BIP] 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. @@ -276,7 +276,7 @@ Miner provides additional text-based information. 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 +all accepted/negotiated extensions. The reason why we made it incompatible is that '''mining.capabilities''' request has no associated response. diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index 55a751f..911d3c8 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -80,8 +80,6 @@ A full signature consists of the base64-encoding of the <code>to_sign</code> tra A signer may construct a proof of funds, demonstrating control of a set of UTXOs, by constructing a full signature as above, with the following modifications. -* <code>message_challenge</code> is unused and shall be set to <code>OP_TRUE</code> -* Similarly, <code>message_signature</code> is then empty. * All outputs that the signer wishes to demonstrate control of are included as additional inputs of <code>to_sign</code>, and their witness and scriptSig data should be set as though these outputs were actually being spent. Unlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to learn that the claimed inputs exist on the blockchain, and to learn their scriptPubKeys. diff --git a/bip-0324.mediawiki b/bip-0324.mediawiki index c0572a3..8050b15 100644 --- a/bip-0324.mediawiki +++ b/bip-0324.mediawiki @@ -112,17 +112,19 @@ Given a newly established connection (typically TCP/IP) between two v2 P2P nodes #** Generates a random ephemeral secp256k1 private key and sends a corresponding 64-byte ElligatorSwift<ref name="ellswift_paper">'''What is ElligatorSwift and why use it?''' The [https://eprint.iacr.org/2022/759.pdf SwiftEC paper] describes a method called ElligatorSwift which allows encoding elliptic curve points in a way that is indistinguishable from a uniformly distributed bitstream. While a random 256-bit string has about 50% chance of being a valid X coordinate on the secp256k1 curve, every 512-bit string is a valid ElligatorSwift encoding of a curve point, making the encoded point indistinguishable from random when using an encoder that can sample uniformly.</ref><ref name="ellswift_perf">'''How fast is ElligatorSwift?''' Our benchmarks show that ElligatorSwift encoded ECDH is about 50% more expensive than unencoded ECDH. Given the fast performance of ECDH and the low frequency of new connections, we found the performance trade-off acceptable for the pseudorandom bytestream and future censorship resistance it can enable.</ref>-encoded public key to the responder. #** May send up to 4095<ref name="why_4095_garbage">'''How was the limit of 4095 bytes garbage chosen?''' It is a balance between having sufficient freedom to hide information, and allowing it to be large enough so that the necessary 64 bytes of public key is small compared to it on the one hand, and bandwidth waste on the other hand.</ref> bytes of arbitrary data after their public key, called '''garbage''', providing a form of shapability and avoiding a recognizable pattern of exactly 64 bytes.<ref name="why_garbage">'''Why does the affordance for garbage exist in the protocol?''' The garbage strings after the public keys are needed for shapability of the handshake. Neither peer can send decoy packets before having received at least the other peer's public key, i.e., neither peer can send more than 64 bytes before having received 64 bytes.</ref> #* The responder: -#** Waits until one byte is received which does not match the 12 bytes consisting of the network magic followed by "version\x00". If the first 12 bytes do match, the connection is treated as using the v1 protocol instead.<ref name="why_no_prefix_check">'''What if a v2 initiator's public key starts accidentally with these 12 bytes?''' This is so unlikely (probability of ''2<sup>-96</sup>'') to happen randomly in the v2 protocol that the initiator does not need to specifically avoid it.</ref><ref>Bitcoin Core versions <=0.4.0 and >=22.0 ignore valid P2P messages that are received prior to a VERSION message. Bitcoin Core versions between 0.4.0 and 22.0 assign a misbehavior score to the peer upon receiving such messages. v2 clients implementing this proposal will interpret any message other than VERSION received as the first message to be the initiation of a v2 connection, and will result in disconnection for v1 initiators that send any message type other than VERSION as the first message. We are not aware of any implementations where this could pose a problem.</ref> +#** Waits until one byte is received which does not match the 16 bytes consisting of the network magic followed by "version\x00\x00\x00\x00\x00". If the first 16 bytes do match, the connection is treated as using the v1 protocol instead.<ref name="why_no_prefix_check">'''What if a v2 initiator's public key starts accidentally with these 16 bytes?''' This is so unlikely (probability of ''2<sup>-128</sup>'') to happen randomly in the v2 protocol that the initiator does not need to specifically avoid it. The optional detection of wrong-network v1 peers has a probability of ''2<sup>-96</sup>'', which is still negligible compared to random network failures.</ref><ref>Bitcoin Core versions <=0.4.0 and >=22.0 ignore valid P2P messages that are received prior to a VERSION message. Bitcoin Core versions between 0.4.0 and 22.0 assign a misbehavior score to the peer upon receiving such messages. v2 clients implementing this proposal will interpret any message other than VERSION received as the first message to be the initiation of a v2 connection, and will result in disconnection for v1 initiators that send any message type other than VERSION as the first message. We are not aware of any implementations where this could pose a problem.</ref> +#** If the first 4 received bytes do not match the network magic, but the 12 bytes after that do match the version message encoding above, implementations may interpret this as a v1 peer of a different network, and disconnect them. #** Similarly generates a random ephemeral private key and sends a corresponding 64-byte ElligatorSwift-encoded public key to the initiator. #** Similarly may send up to 4095 bytes of garbage data after their public key. #* Both parties: #** Receive (the remainder of) the full 64-byte public key from the other side. #** Use X-only<ref name="xonly_ecdh">'''Why use X-only ECDH?''' Using only the X coordinate provides the same security as using a full encoding of the secret curve point but allows for more efficient implementation by avoiding the need for square roots to compute Y coordinates.</ref> ECDH to compute a shared secret from their private key and the exchanged public keys<ref name="why_ecdh_pubkeys">'''Why is the shared secret computation a function of the exact 64-byte public encodings sent?''' This makes sure that an attacker cannot modify the public key encoding used without modifying the rest of the stream. If a third party wants the ability to modify stream bytes, they need to perform a full MitM attack on the connection.</ref>, and deterministically derive from the secret 4 '''encryption keys''' (two in each direction: one for packet lengths, one for content encryption), a '''session id''', and two 16-byte '''garbage terminators'''<ref>'''What length is sufficient for garbage terminators?''' The length of the garbage terminators determines the probability of accidental termination of a legitimate v2 connection due to garbage bytes (sent prior to ECDH) inadvertently including the terminator. 16 byte terminators with 4095 bytes of garbage yield a negligible probability of such collision which is likely orders of magnitude lower than random connection failure on the Internet.</ref><ref>'''What does a garbage terminator in the wild look like?''' <div>[[File:bip-0324/garbage_terminator.png|none|256px|A garbage terminator model TX-v2 in the wild... sent by the responder]]</div> </ref> (one in each direction) using HKDF-SHA256. -#** Send their 16-byte garbage terminator<ref name="why_garbage_term">'''Why does the protocol need a garbage terminator?''' While it is in principle possible to use the garbage authentication packet directly as a terminator (scan until a valid authentication packet follows), this would be significantly slower than just scanning for a fixed byte sequence, as it would require recomputing a Poly1305 tag after every received byte.</ref> followed by a '''garbage authentication packet'''<ref name="why_garbage_auth">'''Why does the protocol require a garbage authentication packet?''' Without the garbage authentication packet, the garbage would be modifiable by a third party without consequences. We want to force any active attacker to have to maintain a full protocol state. In addition, such malleability without the consequence of connection termination could enable protocol fingerprinting.</ref>, an '''encrypted packet''' (see further) with arbitrary '''contents''', and '''associated data''' equal to the garbage. +#** Send their 16-byte garbage terminator.<ref name="why_garbage_term">'''Why does the protocol need a garbage terminator?''' While it is in principle possible to use the first packet after the garbage directly as a terminator (scan until a valid packet follows), this would be significantly slower than just scanning for a fixed byte sequence, as it would require recomputing a Poly1305 tag after every received byte.</ref> #** Receive up to 4111 bytes, stopping when encountering the garbage terminator. -#** Receive an encrypted packet, verify that it decrypts correctly with associated data set to the garbage received, and then ignore its contents. -#* At this point, both parties have the same keys, and all further communication proceeds in the form of encrypted packets. Packets have an '''ignore bit''', which makes them '''decoy packets''' if set. Decoy packets are to be ignored by the receiver apart from verifying they decrypt correctly. Either peer may send such decoy packets at any point after this. These form the primary shapability mechanism in the protocol. How and when to use them is out of scope for this document. +#* At this point, both parties have the same keys, and all further communication proceeds in the form of '''encrypted packets'''. +#** Encrypted packets have an '''ignore bit''', which makes them '''decoy packets''' if set. Decoy packets are to be ignored by the receiver apart from verifying they decrypt correctly. Either peer may send such decoy packets at any point from here on. These form the primary shapability mechanism in the protocol. How and when to use them is out of scope for this document. +#** For each of the two directions, the first encrypted packet that will be sent in that direction (regardless of it being a decoy packet or not) will make use of the associated authenticated data (AAD) feature of the AEAD to authenticate the garbage that has been sent in that direction.<ref name="why_garbage_auth">'''Why does the protocol authenticate the garbage?''' Without garbage authentication, the garbage would be modifiable by a third party without consequences. We want to force any active attacker to have to maintain a full protocol state. In addition, such malleability without the consequence of connection termination could enable protocol fingerprinting.</ref> # The '''Version negotiation phase''', where parties negotiate what transport version they will use, as well as data defined by that version.<ref name="example_versions">'''What features could be added in future protocol versions?''' Examples of features that could be added in future versions include post-quantum cryptography upgrades to the handshake, and optional authentication.</ref> #* The responder: #** Sends a '''version packet''' with empty content, to indicate support for the v2 P2P protocol proposed by this document. Any other value for content is reserved for future versions. @@ -136,19 +138,19 @@ Given a newly established connection (typically TCP/IP) between two v2 P2P nodes To avoid the recognizable pattern of first messages being at least 64 bytes, a future backwards-compatible upgrade to this protocol may allow both peers to send their public key + garbage + garbage terminator in multiple rounds, slicing those bytes up into messages arbitrarily, as long as progress is guaranteed.<ref name="handshake_progress">'''How can progress be guaranteed in a backwards-compatible way?''' In order to guarantee progress, it must be ensured that no deadlock occurs, i.e., no state is reached in which each party waits for the other party indefinitely. For example, any upgrade that adheres to the following conditions will guarantee progress: -* The initiator must start by sending at least as many bytes as necessary to mismatch the magic/version 12 bytes prefix. -* The responder must start sending after having received at least one byte that mismatches that 12-byte prefix. +* The initiator must start by sending at least as many bytes as necessary to mismatch the magic/version 16 bytes prefix. +* The responder must start sending after having received at least one byte that mismatches that 16-byte prefix. * As soon as either party has received the other peer's garbage terminator, or has received 4095 bytes of garbage, they must send their own garbage terminator. (When either of these conditions is met, the other party has nothing to respond with anymore that would be needed to guarantee progress otherwise.) * Whenever either party receives any nonzero number of bytes, while not having sent their garbage terminator completely yet, they must send at least one byte in response without waiting for more bytes. -* After either party has sent their garbage terminator, they must also send the garbage authentication packet without waiting for more bytes, and transition to the version negotiation phase. +* After either party has sent their garbage terminator, they must transition to the version negotiation phase without waiting for more bytes. Since the protocol as specified here adheres to these conditions, any upgrade which also adheres to these conditions will be backwards-compatible.</ref> -Note that the version negotiation phase does not need to wait for the key exchange phase to complete; version packets can be sent immediately after sending the garbage authentication packet. So the first two phases together, jointly called '''the handshake''', comprise just 1.5 roundtrips: +Note that the version negotiation phase does not need to wait for the key exchange phase to complete; version packets can be sent immediately after sending the garbage terminator. So the first two phases together, jointly called '''the handshake''', comprise just 1.5 roundtrips: * the initiator sends public key + garbage -* the responder sends public key + garbage + garbage terminator + garbage authentication packet + version packet -* the initiator sends garbage terminator + garbage authentication packet + version packet +* the responder sends public key + garbage + garbage terminator + decoy packets (optional) + version packet +* the initiator sends garbage terminator + decoy packets (optional) + version packet '''Packet encryption overview''' @@ -181,26 +183,24 @@ As explained before, these messages are sent to set up the connection: ---------------------------------------------------------------------------------------------------- | Initiator Responder | | | - | x, ellswift_X = ellswift_create(initiating=True) | + | x, ellswift_X = ellswift_create() | | | - | --- ellswift_X + initiator_garbage (initiator_garbage_len bytes; max 4095) ---> | + | ---- ellswift_X + initiator_garbage (initiator_garbage_len bytes; max 4095) ---> | | | - | y, ellswift_Y = ellswift_create(initiating=False) | + | y, ellswift_Y = ellswift_create() | | ecdh_secret = v2_ecdh( | | y, ellswift_X, ellswift_Y, initiating=False) | | v2_initialize(initiator, ecdh_secret, initiating=False) | | | - | <-- ellswift_Y + responder_garbage (responder_garbage_len bytes; max 4095) + | - | responder_garbage_terminator (16 bytes) + | - | v2_enc_packet(initiator, b'', aad=responder_garbage) + | - | v2_enc_packet(initiator, RESPONDER_TRANSPORT_VERSION) --- | + | <--- ellswift_Y + responder_garbage (responder_garbage_len bytes; max 4095) + | + | responder_garbage_terminator (16 bytes) + | + | v2_enc_packet(initiator, RESPONDER_TRANSPORT_VERSION, aad=responder_garbage) ---- | | | | ecdh_secret = v2_ecdh(x, ellswift_Y, ellswift_X, initiating=True) | | v2_initialize(responder, ecdh_secret, initiating=True) | | | - | --- initiator_garbage_terminator (16 bytes) + | - | v2_enc_packet(responder, b'', aad=initiator_garbage) + | - | v2_enc_packet(responder, INITIATOR_TRANSPORT_VERSION) ---> | + | ---- initiator_garbage_terminator (16 bytes) + | + | v2_enc_packet(responder, INITIATOR_TRANSPORT_VERSION, aad=initiator_garbage) ---> | | | ---------------------------------------------------------------------------------------------------- </pre> @@ -333,51 +333,58 @@ To establish a v2 encrypted connection, the initiator generates an ephemeral sec <pre> def initiate_v2_handshake(peer, garbage_len): - peer.privkey_ours, peer.ellswift_ours = ellswift_create(initiating=True) + peer.privkey_ours, peer.ellswift_ours = ellswift_create() peer.sent_garbage = rand_bytes(garbage_len) send(peer, peer.ellswift_ours + peer.sent_garbage) </pre> -The responder generates an ephemeral keypair for itself and derives the shared ECDH secret (using the first 64 received bytes) which enables it to instantiate the encrypted transport. It then sends 64 bytes of the unencrypted ElligatorSwift encoding of its own public key and its own <code>responder_garbage</code> also of length <code>garbage_len < 4096</code>. If the first 12 bytes received match the v1 prefix, the v1 protocol is used instead. +The responder generates an ephemeral keypair for itself and derives the shared ECDH secret (using the first 64 received bytes) which enables it to instantiate the encrypted transport. It then sends 64 bytes of the unencrypted ElligatorSwift encoding of its own public key and its own <code>responder_garbage</code> also of length <code>garbage_len < 4096</code>. If the first 16 bytes received match the v1 prefix, the v1 protocol is used instead. <pre> TRANSPORT_VERSION = b'' NETWORK_MAGIC = b'\xf9\xbe\xb4\xd9' # Mainnet network magic; differs on other networks. -V1_PREFIX = NETWORK_MAGIC + b'version\x00' +V1_PREFIX = NETWORK_MAGIC + b'version\x00\x00\x00\x00\x00' def respond_v2_handshake(peer, garbage_len): peer.received_prefix = b"" - while len(peer.received_prefix) < 12: + while len(peer.received_prefix) < len(V1_PREFIX): peer.received_prefix += receive(peer, 1) if peer.received_prefix[-1] != V1_PREFIX[len(peer.received_prefix) - 1]: - peer.privkey_ours, peer.ellswift_ours = ellswift_create(initiating=False) + peer.privkey_ours, peer.ellswift_ours = ellswift_create() peer.sent_garbage = rand_bytes(garbage_len) send(peer, ellswift_Y + peer.sent_garbage) return use_v1_protocol() </pre> -Upon receiving the encoded responder public key, the initiator derives the shared ECDH secret and instantiates the encrypted transport. It then sends the derived 16-byte <code>initiator_garbage_terminator</code> followed by an authenticated, encrypted packet with empty contents<ref name="send_empty_garbauth">'''Does the content of the garbage authentication packet need to be empty?''' The receiver ignores the content of the garbage authentication packet, so its content can be anything, and it can in principle be used as a shaping mechanism too. There is however no need for that, as immediately afterward the initiator can start using decoy packets as (a much more flexible) shaping mechanism instead.</ref> to authenticate the garbage, and its own version packet. It then receives the responder's garbage and garbage authentication packet (delimited by the garbage terminator), and checks if the garbage is authenticated correctly. The responder performs very similar steps but includes the earlier received prefix bytes in the public key. As mentioned before, the encrypted packets for the '''version negotiation phase''' can be piggybacked with the garbage authentication packet to minimize roundtrips. +Upon receiving the encoded responder public key, the initiator derives the shared ECDH secret and instantiates the encrypted transport. It then sends the derived 16-byte <code>initiator_garbage_terminator</code>, optionally followed by an arbitrary number of decoy packets. Afterwards, it receives the responder's garbage (delimited by the garbage terminator). The responder performs very similar steps but includes the earlier received prefix bytes in the public key. Both the initiator and the responder set the AAD of the first encrypted packet they send after the garbage terminator (i.e., either an optional decoy packet or the version packet) to the garbage they have just sent, not including the garbage terminator. <pre> -def complete_handshake(peer, initiating): +def complete_handshake(peer, initiating, decoy_content_lengths=[]): received_prefix = b'' if initiating else peer.received_prefix ellswift_theirs = receive(peer, 64 - len(received_prefix)) + if not initiating and ellswift_theirs[4:16] == V1_PREFIX[4:16]: + # Looks like a v1 peer from the wrong network. + disconnect(peer) ecdh_secret = v2_ecdh(peer.privkey_ours, ellswift_theirs, peer.ellswift_ours, initiating=initiating) initialize_v2_transport(peer, ecdh_secret, initiating=True) - # Send garbage terminator + garbage authentication packet + version packet. - send(peer, peer.send_garbage_terminator + - v2_enc_packet(peer, b'', aad=peer.sent_garbage) + - v2_enc_packet(peer, TRANSPORT_VERSION)) + # Send garbage terminator + send(peer, peer.send_garbage_terminator) + # Optionally send decoy packets after garbage terminator. + aad = peer.sent_garbage + for decoy_content_len in decoy_content_lengths: + send(v2_enc_packet(peer, decoy_content_len * b'\x00', aad=aad)) + aad = b'' + # Send version packet. + send(v2_enc_packet(peer, TRANSPORT_VERSION, aad=aad)) # Skip garbage, until encountering garbage terminator. received_garbage = recv(peer, 16) for i in range(4096): if received_garbage[-16:] == peer.recv_garbage_terminator: - # Receive, decode, and ignore garbage authentication packet (decoy or not) - v2_receive_packet(peer, aad=received_garbage, skip_decoy=False) - # Receive, decode, and ignore version packet, skipping decoys - v2_receive_packet(peer) + # Receive, decode, and ignore version packet. + # This includes skipping decoys and authenticating the received garbage. + v2_receive_packet(peer, aad=received_garbage) return else: received_garbage += recv(peer, 1) @@ -396,7 +403,7 @@ Packet encryption is built on two existing primitives: * '''ChaCha20Poly1305''' is specified as <code>AEAD_CHACHA20_POLY1305</code> in [https://datatracker.ietf.org/doc/html/rfc8439#section-2.8 RFC 8439 section 2.8]. It is an authenticated encryption protocol with associated data (AEAD), taking a 256-bit key, 96-bit nonce, and an arbitrary-length byte array of associated authenticated data (AAD). Due to the built-in authentication tag, ciphertexts are 16 bytes longer than the corresponding plaintext. In what follows: ** <code>aead_chacha20_poly1305_encrypt(key, nonce, aad, plaintext)</code> refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', an arbitrary-length byte array ''aad'', and an arbitrary-length byte array ''plaintext'', and returns a byte array ''ciphertext'', 16 bytes longer than the plaintext. ** <code>aead_chacha20_poly1305_decrypt(key, nonce, aad, ciphertext)</code> refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', an arbitrary-length byte array ''aad'', and an arbitrary-length byte array ''ciphertext'', and returns either a byte array ''plaintext'' (16 bytes shorter than the ciphertext), or ''None'' in case the ciphertext was not a valid ChaCha20Poly1305 encryption of any plaintext with the specified ''key'', ''nonce'', and ''aad''. -* The '''ChaCha20 Block Function''' is specified in [https://datatracker.ietf.org/doc/html/rfc8439#section-2.8 RFC 8439 section 2.3]. It is a pseudorandom function (PRF) taking a 256-bit key, 96-bit nonce, and 32-bit counter, and outputs 64 pseudorandom bytes. It is the underlying building block on which ChaCha20 (and ultimately, ChaCha20Poly1305) is built. In what follows: +* The '''ChaCha20 Block Function''' is specified in [https://datatracker.ietf.org/doc/html/rfc8439#section-2.3 RFC 8439 section 2.3]. It is a pseudorandom function (PRF) taking a 256-bit key, 96-bit nonce, and 32-bit counter, and outputs 64 pseudorandom bytes. It is the underlying building block on which ChaCha20 (and ultimately, ChaCha20Poly1305) is built. In what follows: ** <code>chacha20_block(key, nonce, count)</code> refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', and an integer ''count'' in range ''0..2<sup>32</sup>-1'', and returns a byte array of length 64. These will be used for plaintext encryption and length encryption, respectively. @@ -490,17 +497,19 @@ def v2_enc_packet(peer, contents, aad=b'', ignore=False): <pre> CHACHA20POLY1305_EXPANSION = 16 -def v2_receive_packet(peer, aad=b'', skip_decoy=True): +def v2_receive_packet(peer, aad=b''): while True: enc_contents_len = receive(peer, LENGTH_FIELD_LEN) contents_len = int.from_bytes(peer.recv_L.crypt(enc_contents_len), 'little') aead_ciphertext = receive(peer, HEADER_LEN + contents_len + CHACHA20POLY1305_EXPANSION) - plaintext = peer.recv_P.decrypt(aead_ciphertext) + plaintext = peer.recv_P.decrypt(aad, aead_ciphertext) if plaintext is None: disconnect(peer) break + # Only the first packet is expected to have non-empty AAD. + aad = b'' header = plaintext[:HEADER_LEN] - if not (skip_decoy and header[0] & (1 << IGNORE_BIT_POS)): + if not (header[0] & (1 << IGNORE_BIT_POS)): return plaintext[HEADER_LEN:] </pre> @@ -554,12 +563,9 @@ The following table lists currently defined message type IDs: |<code>GETCFHEADERS</code>||<code>CFHEADERS</code>||<code>GETCFCHECKPT</code>||<code>CFCHECKPT</code> |- !+28 -|<code>ADDRV2</code>||<code>REQRECON</code>||<code>SKETCH</code>||<code>REQSKETCHEXT</code> +|<code>ADDRV2</code> |- -!+32 -|<code>RECONCILDIFF</code> -|- -!≥33 +!≥29 || colspan="4" | (undefined) |} diff --git a/bip-0324/test_sage_decoding.py b/bip-0324/test_sage_decoding.py index c26c334..1ec5fdf 100644 --- a/bip-0324/test_sage_decoding.py +++ b/bip-0324/test_sage_decoding.py @@ -5,8 +5,8 @@ Instructions: * Clone the SwiftEC repository, and enter the directory: git clone https://github.com/Jchavezsaab/SwiftEC - git checkout 5320a25035d91addde29d14164cce684b56a12ed cd SwiftEC + git checkout 5320a25035d91addde29d14164cce684b56a12ed * Generate parameters for the secp256k1 curve: diff --git a/bip-0324/xswiftec_test_vectors.csv b/bip-0324/xswiftec_test_vectors.csv deleted file mode 100644 index 985235f..0000000 --- a/bip-0324/xswiftec_test_vectors.csv +++ /dev/null @@ -1,33 +0,0 @@ -u,x,case0_t,case1_t,case2_t,case3_t,case4_t,case5_t,case6_t,case7_t -08da7c45cb204377e7e42249cda5713fa865116ddbb4cb5a1949b2e5b438a6ab,e087b707dabf2796b03b2fb4f976c3f2f5abb36110d00ef656432117f2c93f0a,,,,,,,, -0a6361b3a802f55cd5ae06101c88a1e216320fe11cc0cfe1d791eed08a1200fd,a0223bc98997647daf4d520129bdb66e4937a00d1533af1fa29645fb96fb5bb5,60a3ed14bd9df0bfb89ada9372a7b5790b123a66bf130f5788237e8cd5225de4,9c4ee4629f10220fda49532d0c859a539dec5148eefc78bf48d93d2828027a9c,fc5e72f042fd1792cbf88728a374a2cc1e03e1f9ec8813fa3692e497cfa7d5e6,cb39fac005f26dc0a383ea64cb9b3b0b26767f20232cae4486f32904df4f04e3,9f5c12eb42620f404765256c8d584a86f4edc59940ecf0a877dc81722add9e4b,63b11b9d60efddf025b6acd2f37a65ac6213aeb711038740b726c2d6d7fd8193,03a18d0fbd02e86d340778d75c8b5d33e1fc1e061377ec05c96d1b6730582649,34c6053ffa0d923f5c7c159b3464c4f4d98980dfdcd351bb790cd6fa20b0f74c -102b51b9765a56a3e899f7cf0ee38e5251f9c503b357b330a49183eb7b155604,102b51b9765a56a3e899f7cf0ee38e5251f9c503b357b330a49183eb7b155604,bdb5bd58ca96eae36147a6c55bc2bef2cee55a757ee193cb619edc8d3590f90a,bda953c1da02059350e740b83f59149628e0be50c24ac8dc6908a2225931b4a0,,,424a42a73569151c9eb8593aa43d410d311aa58a811e6c349e612371ca6f0325,4256ac3e25fdfa6caf18bf47c0a6eb69d71f41af3db5372396f75ddca6ce478f,, -2921a11f25dadaa24aa79a548e4e81508c2e5e56af2d833d65e2bcce448ce2f5,3a70c472406b83d9f1c4398b8ecef786499bc44a3b30c34ac30f2d8a418bffa3,b9c76c21d3fabb948fa0326bf9e999068e9eed56ee4e76cb81558aa26969c56c,ef7dd84338732a0cac3a8995f3bacf9b2896582b8d3317ed508e5d9a5a3447af,,,463893de2c05446b705fcd94061666f9716112a911b189347eaa755c969636c3,108227bcc78cd5f353c5766a0c453064d769a7d472cce812af71a264a5cbb480,, -33b67cb5385ceddad93d0ee960679041613bed34b8b4a5e6362fe7539ba2d3ce,0105c74958a165e016502eeb87835195505d89714c95272b6fa88fe6c60b33ac,,,069e1b3b155c6da989b9b6a8735bba3c5c1049dcf01fe4474772244db89cf9ca,c77b10bca540e95ee66c1f57ab6297787849a89b2b883116e700593e3c0fe66d,,,f961e4c4eaa39256764649578ca445c3a3efb6230fe01bb8b88ddbb147630265,3884ef435abf16a11993e0a8549d688787b65764d477cee918ffa6c0c3f015c2 -3a898eecdae167231275338e9a79153cbe53f7bf99943eeb72ee64e57bb58699,41ffd7362aaa7b90fe03936deeebe9afafd9c18967122d8f972db2c050d4f07b,60abf7ed2a7ffd3d2ac242a782331ea663d55ca157af994e5e964e9c79a0db40,3c3c39dc37753ab9160dfbc2e0596c3a5114784690caa1836e12036814453da3,adcd3f100de60723f127278998c591fbf081af8e0a77f2a9090bed67d8aa2aa3,,9f540812d58002c2d53dbd587dcce1599c2aa35ea85066b1a169b162865f20ef,c3c3c623c88ac546e9f2043d1fa693c5aeeb87b96f355e7c91edfc96ebbabe8c,5232c0eff219f8dc0ed8d876673a6e040f7e5071f5880d56f6f412972755d18c, -46e04d129d7b45d054469ce34e24069a1426b3e34f1b68a3d1bff1e070aee192,c6ce9611bd908c16eba5c599e5219de2d18d82c96aafb0180b23ee315513618f,,,,,,,, -47dc540c94ceb704a23875c11273e16bb0b8a87aed84de911f2133568115f254,13964717dbc998964d7c19ec3d9981fe1d4a9a80845552a98fb9352898532844,,,,,,,, -4cab73ce2a7e6220975001c8a354143267a3c1ce8bf7692313e654481e616a93,9114cf2edd3b53dbb6581290a5cca532db38b4e9ceeacc9b0437a0e49bf97211,903b600ed648d4ddc48f0f628829c8992c88fab44b692413fb8b3d783854f9a2,2952afe39557606d08c311345788a5071413580917207c86ea7cb829cf2f2c6d,05f414320d0c4004cff10f798c3fda6c4fc335b5a2db940993b3d78147a25c18,48e2531c7e3ec99f807210d6c5330114b4f04d7345535ca5a6e6abf478bdb723,6fc49ff129b72b223b70f09d77d63766d377054bb496dbec0474c286c7ab028d,d6ad501c6aa89f92f73ceecba8775af8ebeca7f6e8df8379158347d530d0cfc2,fa0bebcdf2f3bffb300ef08673c02593b03cca4a5d246bf66c4c287db85da017,b71dace381c136607f8def293accfeeb4b0fb28cbaaca35a5919540a8742450c -5aeca385d8b781825b07bbec7c858b7170426c88088935850bc13dd6402368a5,a5135c7a27487e7da4f84413837a748e8fbd9377f776ca7af43ec228bfdc938a,8da4f71fb2700758f623d73c24ac91747da43f2302fce16c8d438a769c63495f,6b8f345fc0a25a76455541ddbf2791ff4b943c98b16db2b6eb6cea94a6b19afb,,,725b08e04d8ff8a709dc28c3db536e8b825bc0dcfd031e9372bc7588639cb2d0,9470cba03f5da589baaabe2240d86e00b46bc3674e924d491493156a594e6134,, -707bf0b938f307b5c222e670598b865d5e1f8a8003df82c7abbf7c9f8fa4d720,8f840f46c70cf84a3ddd198fa67479a2a1e0757ffc207d385440835f705b250f,,,eab90fb459bace62d3ce8fbd69c9f1039f0627d0e93e2f42bffd87889cb236a4,157c26578b226c66daf8edfa56f7560f1131f41d1685175e6d76cc95b4f89f10,,,1546f04ba645319d2c31704296360efc60f9d82f16c1d0bd40027876634dc58b,ea83d9a874dd939925071205a908a9f0eece0be2e97ae8a1928933694b075d1f -766caa663e1025b9accd7ededd24fbc8193180e028eedae2f41d6bb0b1d36468,22825ee826f8b76c27220e43c79c884a8518bc20f4978cc15f83f9c48346a314,,,8fe95c178da66d1dd249ea6a4dc614a6d46d79c83cbc4beafee518090263e48a,7b044cb756eb207226db302ba05e164781c2f5161dccd72607282cb9ad86a282,,,7016a3e8725992e22db61595b239eb592b928637c343b415011ae7f5fd9c17a5,84fbb348a914df8dd924cfd45fa1e9b87e3d0ae9e23328d9f8d7d345527959ad -78a23af8da46b1b37e8767921a2d3f528fdc8eca37cea8aea775fd2b283d3776,73d5f35d96f3ce1ef5802ead8edc10787700c593b5e0ddcc3bfb2720b9d36de3,8465ad20bd0f2b4a2d37106769af46288a109bc10b527c3b033c930c0e4b1025,1b7f03bd2c915bb736622aec85601bcabec89268c98945e19a0de4126ed62524,,,7b9a52df42f0d4b5d2c8ef989650b9d775ef643ef4ad83c4fcc36cf2f1b4ec0a,e480fc42d36ea448c99dd5137a9fe43541376d973676ba1e65f21bec9129d70b,, -78b4be1f9eeef9da65c393e4385f67edd142709b400ca7d900bd952e0c3cf727,089329e17a58a91e71ffe6ddd851e8a352e85a29fcc289b34a3bfdeaf958fe91,,,6008d703955b38da0166bd975ad3535af3b701b2efdf653fc5e7e6eb6afff0a3,,,,9ff728fc6aa4c725fe994268a52caca50c48fe4d10209ac03a18191395000b8c, -7a2a7c0a81d1bd595dff09b918f8ecb5b5e8493654a4f83496956ed8eb017674,85d583f57e2e42a6a200f646e707134a4a17b6c9ab5b07cb696a912614fe85bb,,,,,,,, -913da1f8df6f8fd47593840d533ba0458cc9873996bf310460abb495b34c232a,a7803f8e02b70718443a06db502c67925640e936b3fa46dd2ed6b8f7c80fa329,67d916ba2cc154464d87ff4e0cfe3bb816b22a961831c2daf62597a8b0681e87,a4b84520f8853e5482ee7689732ed7dd7da59945d26edeee0bf5f55d3507192f,,,9826e945d33eabb9b27800b1f301c447e94dd569e7ce3d2509da68564f97dda8,5b47badf077ac1ab7d1189768cd12822825a66ba2d912111f40a0aa1caf8e300,, -96a296d224f285c67bee93c30f8a309157f0daa35dc5b87e410b78630a09cfc7,7684ab3b1a43e20a97a7b5520e5b5347841a7d95984fd76b2478a2b710f1a2ce,,,,,,,, -99be5efb88ca2013bd8e4eb035fd42d5245468fe9afa70d8ba9c1c419a48c4e8,08ee83ae5c7af0c9b2341e595fe347537272d94f2fe9f10b9a8f913279fc6230,,,,,,,, -9b4fb24edd6d1d8830e272398263cdbf026b97392cc35387b991dc0248a628f9,80e81d40a50b53712a8dac5f468b0903c05219544a56af70aa152ebf17887701,,,6e94af5a32ac100c5230f1e119c538742b7051934b02f3850522cff26bd32d97,e9bd309fbf041342311be3d5bab0b9d16c9f80c6640eb47e311d3178c2adc75d,,,916b50a5cd53eff3adcf0e1ee63ac78bd48fae6cb4fd0c7afadd300c942cce98,1642cf6040fbecbdcee41c2a454f462e93607f399bf14b81cee2ce863d5234d2 -9def996cb1ea87e596b6cadccca3839a352e99d9ce07e635cdb239f38ca294f8,294850a665ab014a0e75eb4b52ee66dd8a8d2b5e453074e58afacb5e019ee90a,b1a29367b95e1996f7e393fb389e7ace812d4135f6ddcdcd77467fc000dfca8c,a340aabc95b4000e3043ba6139178c450046c985fbf09676c440bc6430ddaa5b,4c4cd400d0be335dd651370c5565c2b742a298016212a8605187b3c0751a811e,d90fa208bbb5f3f6e16c5a42b419188ec1951c1eb358f04741b7b48df9e55f79,4e5d6c9846a1e669081c6c04c76185317ed2beca0922323288b9803eff2031a3,5cbf55436a4bfff1cfbc459ec6e873baffb9367a040f69893bbf439acf2251d4,b3b32bff2f41cca229aec8f3aa9a3d48bd5d67fe9ded579fae784c3e8ae57b11,26f05df7444a0c091e93a5bd4be6e7713e6ae3e14ca70fb8be484b71061a9cb6 -a2c4aed1cf757cd9a509734a267ffc7b1166b55f4c8f9c3e3550c56e743328fc,a2c4aed1cf757cd9a509734a267ffc7b1166b55f4c8f9c3e3550c56e743328fc,,,,,,,, -a8e437abf9c0e74dc6d51eabf2d261a00e785c7e21efeac1f322b610273ba066,5a64cce4be767964e7dba23e78e30149326c539353b647e0d5d7cc361943b13b,,,6f73bdd6b748790b5f788935ca02aee3b9e560c4ba6caf47d716fbde1dd6e92c,b1ff705694188e672f58c6a05eeecc379dd1b60fd3cb9f19fcb02b1d9cab4bc5,,,908c422948b786f4a08776ca35fd511c461a9f3b459350b828e90420e2291303,4e008fa96be77198d0a7395fa11133c8622e49f02c3460e6034fd4e16354b06a -bf60e4349cace6bce0d552e8d783428db66d0d649bd9e430a3627e2ee14ac839,409f1bcb635319431f2aad17287cbd724992f29b64261bcf5c9d81d01eb533f6,,,,,,,, -c0ba8a33ac67f44abff5984dfbb6f56c46b880ac2b86e1f23e7fa9c402c53ae7,4767c4cab0d08133980a8e66c3f93a055c8ae62f89a92f8dcfa47607cee0bc57,4c21052f5ffccadb4f707aa1cba828ef384d7861af1690c59d638dfee9f368e7,dbcc8fe22896478161452d44688a6b138050a4d0964470c175a521dcecc5519a,,,b3defad0a0033524b08f855e3457d710c7b2879e50e96f3a629c7200160c9348,2433701dd769b87e9ebad2bb977594ec7faf5b2f69bb8f3e8a5ade22133aaa95,, -cbe2268747c9c8072c7f9926f2288f270637dc55bb9d14d3368361d5e47d25be,0e4e25736b614910c4984843e606b1e229def08bfd672ab61e2707cde8248c6d,,,c30567184201fac8e1cb9e776d921e17d28cdb7333223abd1c8f860a16393df1,,,,3cfa98e7bdfe05371e346188926de1e82d73248cccddc542e37079f4e9c6be3e, -ceb827ad3d3884fd4d50ae6099d6d50c09a21e72ebd309708e8b69d93df19e55,a6a0c8c94462f16f1b92502c3d5f9d1618f12ffa756227d5b19b01b9373cd940,,,,,,,, -d57e9d4f5842134f140032eaf38b5333638e8c4b145fcf86a23d48d3e9acc0f8,2a8162b0a7bdecb0ebffcd150c74accc9c7173b4eba030795dc2b72b16533b37,349a9a592d2c56e5378ae869d646043fc09ffb8fe5fd9debd83a11274da08892,9875f58028cc991cafab9fb1183b350bc1d8d5ce5723813cc2b8434ed1a2100f,,,cb6565a6d2d3a91ac875179629b9fbc03f6004701a02621427c5eed7b25f739d,678a0a7fd73366e35054604ee7c4caf43e272a31a8dc7ec33d47bcb02e5dec20,, -d94e7f1e9bb1f8a9b90996ba12c461b84956f0e7f230145cc594c2f80b067aa0,b4f4632803cff65c013a566748cd3386d58cd3a28f5b4721056cbe9d278a67a4,,,fad51eda7d418ee2785df9f3788ac9152576312177fc0fd83c65036750581620,749259382784be63f86cc927a5defa6aa8cecb98e38d68f6b7a7e958303c94ad,,,052ae12582be711d87a2060c877536eada89cede8803f027c39afc97afa7e60f,8b6da6c7d87b419c079336d85a210595573134671c729709485816a6cfc36782 -e545d395bb3fd971f91bf9a2b6722831df704efae6c1aa9da0989ed0970b77bb,760486143a1d512da5219d3e5febc7c5c9990d21ca7a501ed23f86c91ddee4cf,,,090892960a84c69967fe5a5d014d3ca19173e4cb72a908586fbce9d1e531a265,42a47f65d00ff2004faa98865ee8ed4f8a9a5ddc9f75042d728de335664bb546,,,f6f76d69f57b39669801a5a2feb2c35e6e8c1b348d56f7a79043162d1ace59ca,bd5b809a2ff00dffb0556779a11712b07565a223608afbd28d721cc999b446e9 -e9f86cefcfd61558fe75da7d4ea48a6c82d93191c6d49579aab49f99e543dcad,5db7371325a7bb83b030691b2d87cd9f199f43d91e302568391ac48181b7cea6,,,,,,,, -eec4121f2a07b61aba16414812aa9afc39ab0a136360a5ace2240dc19b0464eb,0b623c5296c13218a1eb24e79d00b04bf15788f6c2f7ec100a4a16f1473124a2,,,,,,,, -f566cc6fccc657365c0197accf3a7d6f80f85209ff666ff774f4dcbc524aa842,0a9933903339a8c9a3fe685330c582907f07adf6009990088b0b2342adb553ed,3ab8dc4ecbc0441c685436ac0d76f16393769c353be6092bd6ec4ce094106bd8,3bd189b4ef3d1baa5610f2b14cb4a2b377eb171511e6f36ef6a05a2c7c52e368,1594764c6296402aadd123675d81f3505d35f2a52c52881568eadb7b675b53f0,c64fbf71138e66de8ce0abdf3b6f51d151ca8e1037ab5b979e62b2faa15be81c,c54723b1343fbbe397abc953f2890e9c6c8963cac419f6d42913b31e6bef9057,c42e764b10c2e455a9ef0d4eb34b5d4c8814e8eaee190c91095fa5d283ad18c7,ea6b89b39d69bfd5522edc98a27e0cafa2ca0d5ad3ad77ea9715248398a4a83f,39b0408eec719921731f5420c490ae2eae3571efc854a468619d4d045ea41413 diff --git a/bip-0327.mediawiki b/bip-0327.mediawiki index 07b40f5..4815f40 100644 --- a/bip-0327.mediawiki +++ b/bip-0327.mediawiki @@ -123,7 +123,7 @@ This is by design: All algorithms in this proposal handle multiple signers who ( and applications are not required to check for duplicate individual public keys. In fact, applications are recommended to omit checks for duplicate individual public keys in order to simplify error handling. Moreover, it is often impossible to tell at key aggregation which signer is to blame for the duplicate, i.e., which signer came up with an individual public key honestly and which disruptive signer copied it. -In contrast, MuSig2 is designed to identify disruptive signers at signing time (see [[#identifiying-disruptive-signers|Identifiying Disruptive Signers]]). +In contrast, MuSig2 is designed to identify disruptive signers at signing time (see [[#identifying-disruptive-signers|Identifying Disruptive Signers]]). While the algorithms in this proposal are able to handle duplicate individual public keys, there are scenarios where applications may choose to abort when encountering duplicates. For example, we can imagine a scenario where a single entity creates a MuSig2 setup with multiple signing devices. @@ -211,7 +211,7 @@ The bit can be obtained with ''GetPlainPubkey(keyagg_ctx)[0] & 1''. The following specification of the algorithms has been written with a focus on clarity. As a result, the specified algorithms are not always optimal in terms of computation and space. -In particular, some values are recomputed but can be cached in actual implementations (see [[#signing-flow|Signing Flow]]). +In particular, some values are recomputed but can be cached in actual implementations (see [[#general-signing-flow|General Signing Flow]]). === Notation === @@ -367,7 +367,7 @@ Algorithm ''ApplyTweak(keyagg_ctx, tweak, is_xonly_t)'': Algorithm ''NonceGen(sk, pk, aggpk, m, extra_in)'': * Inputs: ** The secret signing key ''sk'': a 32-byte array (optional argument) -** The individual public key ''pk'': a 33-byte array (see [[#modifications-to-nonce-generation|Modifications to Nonce Generation]] for the reason that this argument is mandatory) +** The individual public key ''pk'': a 33-byte array (see [[#signing-with-tweaked-individual-keys|Signing with Tweaked Individual Keys]] for the reason that this argument is mandatory) ** The x-only aggregate public key ''aggpk'': a 32-byte array (optional argument) ** The message ''m'': a byte array (optional argument)<ref name="mlen">In theory, the allowed message size is restricted because SHA256 accepts byte strings only up to size of 2^61-1 bytes (and because of the 8-byte length encoding).</ref> ** The auxiliary input ''extra_in'': a byte array with ''0 ≤ len(extra_in) ≤ 2<sup>32</sup>-1'' (optional argument) @@ -465,7 +465,7 @@ Algorithm ''Sign(secnonce, sk, session_ctx)'': * Fail if ''pk ≠ secnonce[64:97]'' * Let ''a = GetSessionKeyAggCoeff(session_ctx, P)''; fail if that fails<ref>Failing ''Sign'' when ''GetSessionKeyAggCoeff(session_ctx, P)'' fails is not necessary for unforgeability. It merely indicates to the caller that the scheme is not being used correctly.</ref> * Let ''g = 1'' if ''has_even_y(Q)'', otherwise let ''g = -1 mod n'' -* <div id="Sign negation"></div>Let ''d = g⋅gacc⋅d' mod n'' (See [[negation-of-the-secret-key-when-signing|Negation Of The Secret Key When Signing]]) +* <div id="Sign negation"></div>Let ''d = g⋅gacc⋅d' mod n'' (See [[#negation-of-the-secret-key-when-signing|Negation Of The Secret Key When Signing]]) * Let ''s = (k<sub>1</sub> + b⋅k<sub>2</sub> + e⋅a⋅d) mod n'' * Let ''psig = bytes(32, s)'' * Let ''pubnonce = cbytes(k<sub>1</sub>'⋅G) || cbytes(k<sub>2</sub>'⋅G)'' @@ -785,6 +785,8 @@ An exception to this rule is <code>MAJOR</code> version zero (0.y.z) which is fo The <code>MINOR</code> version is incremented whenever the inputs or the output of an algorithm changes in a backward-compatible way or new backward-compatible functionality is added. The <code>PATCH</code> version is incremented for other changes that are noteworthy (bug fixes, test vectors, important clarifications, etc.). +* '''1.0.1''' (2024-05-14): +** Fix minor issue in ''PartialSigVerify'' vectors. * '''1.0.0''' (2023-03-26): ** Number 327 was assigned to this BIP. * '''1.0.0-rc.4''' (2023-03-02): diff --git a/bip-0327/vectors/sign_verify_vectors.json b/bip-0327/vectors/sign_verify_vectors.json index b467640..f71c8dd 100644 --- a/bip-0327/vectors/sign_verify_vectors.json +++ b/bip-0327/vectors/sign_verify_vectors.json @@ -157,7 +157,7 @@ ], "verify_fail_test_cases": [ { - "sig": "97AC833ADCB1AFA42EBF9E0725616F3C9A0D5B614F6FE283CEAAA37A8FFAF406", + "sig": "FED54434AD4CFE953FC527DC6A5E5BE8F6234907B7C187559557CE87A0541C46", "key_indices": [0, 1, 2], "nonce_indices": [0, 1, 2], "msg_index": 0, @@ -165,7 +165,7 @@ "comment": "Wrong signature (which is equal to the negation of valid signature)" }, { - "sig": "68537CC5234E505BD14061F8DA9E90C220A181855FD8BDB7F127BB12403B4D3B", + "sig": "012ABBCB52B3016AC03AD82395A1A415C48B93DEF78718E62A7A90052FE224FB", "key_indices": [0, 1, 2], "nonce_indices": [0, 1, 2], "msg_index": 0, @@ -183,7 +183,7 @@ ], "verify_error_test_cases": [ { - "sig": "68537CC5234E505BD14061F8DA9E90C220A181855FD8BDB7F127BB12403B4D3B", + "sig": "012ABBCB52B3016AC03AD82395A1A415C48B93DEF78718E62A7A90052FE224FB", "key_indices": [0, 1, 2], "nonce_indices": [4, 1, 2], "msg_index": 0, @@ -196,7 +196,7 @@ "comment": "Invalid pubnonce" }, { - "sig": "68537CC5234E505BD14061F8DA9E90C220A181855FD8BDB7F127BB12403B4D3B", + "sig": "012ABBCB52B3016AC03AD82395A1A415C48B93DEF78718E62A7A90052FE224FB", "key_indices": [3, 1, 2], "nonce_indices": [0, 1, 2], "msg_index": 0, diff --git a/bip-0329.mediawiki b/bip-0329.mediawiki index 9a8b270..fc5da42 100644 --- a/bip-0329.mediawiki +++ b/bip-0329.mediawiki @@ -26,8 +26,10 @@ These standards are well supported and allow users to move easily between differ There is, however, no defined standard to transfer any labels the user may have applied to the transactions, addresses, public keys, inputs, outputs or xpubs in their wallet. The UTXO model that Bitcoin uses makes these labels particularly valuable as they may indicate the source of funds, whether received externally or as a result of change from a prior transaction. In both cases, care must be taken when spending to avoid undesirable leaks of private information. + Labels provide valuable guidance in this regard, and have even become mandatory when spending in several Bitcoin wallets. Allowing users to import and export their labels in a standardized way ensures that they do not experience lock-in to a particular wallet application. +In addition, many wallets allow unspent outputs to be frozen or made unspendable within the wallet. Since this wallet-related metadata is similar to labels and not captured elsewhere, it is also included in this format. ==Rationale== @@ -44,7 +46,7 @@ It is also a convenient format for command-line processing, which is often line- Further to the JSON Lines specification, an export of labels from a wallet must be a UTF-8 encoded text file, containing one record per line consisting of a valid JSON object. Lines are separated by <tt>\n</tt>. Multiline values are not permitted. -Each JSON object must contain 3 key/value pairs, defined as follows: +Each JSON object must contain 3 or 4 key/value pairs, defined as follows: {| class="wikitable" |- @@ -59,6 +61,12 @@ Each JSON object must contain 3 key/value pairs, defined as follows: |- | <tt>label</tt> | The label applied to the reference +|- +| <tt>origin</tt> +| Optional key origin information referencing the wallet associated with the label +|- +| <tt>spendable</tt> +| One of <tt>true</tt> or <tt>false</tt>, denoting if an output should be spendable by the wallet |} The reference is defined for each <tt>type</tt> as follows: @@ -94,6 +102,11 @@ The reference is defined for each <tt>type</tt> as follows: | <tt>xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8Nq...</tt> |} +Each JSON object must contain both <tt>type</tt> and <tt>ref</tt> properties. The <tt>label</tt>, <tt>origin</tt> and <tt>spendable</tt> properties are optional. If the <tt>label</tt> or <tt>spendable</tt> properties are omitted, the importing wallet should not alter these values. The <tt>origin</tt> property should only appear where type is <tt>tx</tt>, and the <tt>spendable</tt> property only where type is <tt>output</tt>. + +If present, the optional <tt>origin</tt> property must contain an abbreviated output descriptor (as defined by BIP380<ref>[https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki BIP-0380]</ref>) describing a BIP32 compatible originating wallet, including all key origin information but excluding any actual keys, any child path elements, or a checksum. +This property should be used to disambiguate transaction labels from different wallets contained in the same export, particularly when exporting multiple accounts derived from the same seed. + Care should be taken when exporting due to the privacy sensitive nature of the data. Encryption in transit over untrusted networks is highly recommended, and encryption at rest should also be considered. Unencrypted exports should be deleted as soon as possible. @@ -101,7 +114,7 @@ For security reasons no private key types are defined. ==Importing== -* An importing wallet may ignore records it does not store, and truncate labels if necessary. +* An importing wallet may ignore records it does not store, and truncate labels if necessary. A suggested default for maximum label length is 255 characters, and an importing wallet should consider warning the user if truncation is applied. * Wallets importing public key records may derive addresses from them to match against known wallet addresses. * Wallets importing extended public keys may match them against signers, for example in a multisig setup. @@ -114,12 +127,13 @@ However, importing wallets complying to this specification may ignore types not The following fragment represents a wallet label export: <pre> -{ "type": "tx", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd", "label": "Transaction" } +{ "type": "tx", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd", "label": "Transaction", "origin": "wpkh([d34db33f/84'/0'/0'])" } { "type": "addr", "ref": "bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c", "label": "Address" } { "type": "pubkey", "ref": "0283409659355b6d1cc3c32decd5d561abaac86c37a353b52895a5e6c196d6f448", "label": "Public Key" } { "type": "input", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:0", "label": "Input" } -{ "type": "output", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1", "label": "Output" } +{ "type": "output", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1", "label": "Output" , "spendable" : "false" } { "type": "xpub", "ref": "xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8", "label": "Extended Public Key" } +{ "type": "tx", "ref": "f546156d9044844e02b181026a1a407abfca62e7ea1159f87bbeaa77b4286c74", "label": "Account #1 Transaction", "origin": "wpkh([d34db33f/84'/0'/1'])" } </pre> ==Reference Implementation== diff --git a/bip-0330.mediawiki b/bip-0330.mediawiki index c24ea42..996f74e 100644 --- a/bip-0330.mediawiki +++ b/bip-0330.mediawiki @@ -210,7 +210,7 @@ The reconcildiff message is used by reconciliation initiator to announce transac | uint32[] || ask_shortids || The short IDs that the sender did not have. |} -Upon receipt a "reconcildiff" message with ''success=1'' (reconciliation success), a node sends an "inv" message for the transactions requested by 32-bit IDs (first vector) containing their wtxids (with parent transactions occuring before their dependencies). +Upon receipt a "reconcildiff" message with ''success=1'' (reconciliation success), a node sends an "inv" message for the transactions requested by 32-bit IDs (first vector) containing their wtxids (with parent transactions occurring before their dependencies). If ''success=0'' (reconciliation failure), receiver should announce all transactions from the reconciliation set via an "inv" message. In both cases, transactions the sender of the message thinks the receiver is missing are announced via an "inv" message. The regular "inv" deduplication should apply. diff --git a/bip-0330/minisketch.py b/bip-0330/minisketch.py index f64286f..5e39779 100755 --- a/bip-0330/minisketch.py +++ b/bip-0330/minisketch.py @@ -120,7 +120,7 @@ def find_roots_inner(p, a): return [] elif len(p) == 2: return [p[0]] - # Otherwise, split p in left*right using paramater a_vals[0]. + # Otherwise, split p in left*right using parameter a_vals[0]. t = poly_monic(poly_trace(p, a)) left = poly_gcd(list(p), t) right = poly_divmod(list(left), p) diff --git a/bip-0331.mediawiki b/bip-0331.mediawiki new file mode 100644 index 0000000..08927a2 --- /dev/null +++ b/bip-0331.mediawiki @@ -0,0 +1,430 @@ +<pre> + BIP: 331 + Layer: Peer Services + Title: Ancestor Package Relay + Author: Gloria Zhao <gloriajzhao@gmail.com> + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0331 + Status: Draft + Type: Standards Track + Created: 2022-08-08 + License: BSD-3-Clause + Post-History: 2022-05-17 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html [bitcoin-dev] post +</pre> + +==Abstract== + +Peer-to-peer protocol messages enabling nodes to request and relay the unconfirmed ancestor package +of a given transaction, and to request and relay transactions in batches. + +==Motivation== + +===Propagate High Feerate Transactions=== + +Since v0.13, Bitcoin Core has used ancestor packages instead of individual transactions to evaluate +the incentive compatibility of transactions in the mempool +<ref>[https://github.com/bitcoin/bitcoin/pull/7594 Add tracking of ancestor packages]</ref> and +selecting them for inclusion in blocks +<ref>[https://github.com/bitcoin/bitcoin/pull/7600 Select transactions using feerate-with-ancestors]</ref>. +Incentive-compatible mempool and miner policies help create a fair, fee-based market for block +space. While miners maximize transaction fees in order to earn higher block rewards, non-mining +users participating in transaction relay reap many benefits from employing policies that result in a +mempool with similar contents, including faster compact block relay and more accurate fee +estimation. Additionally, users may take advantage of mempool and miner policy to bump the priority +of their transactions by attaching high-fee descendants (Child Pays for Parent or CPFP). + +Only individually considering transactions for submission to the mempool creates a limitation in +the node's ability to determine which transactions to include in the mempool, since it cannot take +into account descendants until all the transactions are in the mempool. Similarly, it cannot use a +transaction's descendants when considering which of two conflicting transactions to keep (Replace by +Fee or RBF). + +When a user's transaction does not meet a mempool's minimum feerate and they cannot create a +replacement transaction directly, their transaction will simply be rejected by this mempool or +evicted if already included. They also cannot attach a descendant to pay for replacing a conflicting +transaction; it would be rejected for spending inputs that do not exist. + +This limitation harms users' ability to fee-bump their transactions. Further, it presents security and complexity +issues in contracting protocols which rely on presigned, time-sensitive transactions<ref>'''Examples of time-sensitive pre-signed transactions in L2 protocols.''' +* [https://github.com/lightning/bolts/blob/master/03-transactions.md#htlc-timeout-and-htlc-success-transactions HTCL-Timeout in LN Penalty] +* [https://github.com/revault/practical-revault/blob/master/transactions.md#cancel_tx Unvault Cancel in Revault] +* [https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md#refund-transaction Refund Transaction in Discreet Log Contracts] +* [https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1 Updates in Eltoo] +* [https://github.com/ElementsProject/peerswap/blob/master/docs/peer-protocol.md#claim-transaction Claim Transactions in PeerSwap] +</ref> to prevent cheating. +In other words, a key security assumption of many contracting protocols is that all parties can +propagate and confirm transactions in a timely manner. Increasing attention has been brought to +"pinning attacks," a type of censorship in which the attacker uses mempool policy restrictions to +prevent a transaction from being relayed or getting mined. +<ref>'''Concerns for pinning attacks in L2 protocols''' +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020458.html Greg Sanders, "Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning"] +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html Matt Corallo, "RBF Pinning with Counterparties and Competing Interest"] +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html Antoine Riard, "Pinning : The Good, The Bad, The Ugly"] +* [https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md Bastien Teinturier, "Pinning Attacks"] +* [https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1 Greg Sanders, "Eltoo Pinning"] +</ref> + +These transactions must meet a certain confirmation target to be effective, but their feerates +are negotiated well ahead of broadcast time. If the forecast feerate was too low and no +fee-bumping options are available, attackers can steal money from their counterparties. Always +overestimating fees may sidestep this issue (but only while mempool traffic is low and +predictable), but this solution is not guaranteed to work and wastes users' money. For some attacks, +the available defenses require nodes to have a bird's-eye view of Bitcoin nodes' mempools, which is +an unreasonable security requirement. + +Part of the solution is to enable nodes to consider packages of transactions as a unit, e.g. one or +more low-fee ancestor transactions with a high-fee descendant, instead of separately. A package-aware +mempool policy can help determine if it would actually be economically rational to accept a +transaction to the mempool if it doesn't meet fee requirements individually. Network-wide adoption +of these policies would create a more purely-feerate-based market for block space and allow +contracting protocols to adjust fees (and therefore mining priority) at broadcast time. + +Theoretically, developing a safe and incentive-compatible package mempool acceptance policy is +sufficient to solve this issue. Nodes could opportunistically accept packages (e.g. by trying +combinations of transactions rejected from their mempools), but this practice would likely be +inefficient at best and open new Denial of Service attacks at worst. As such, this proposal +suggests adding new p2p messages enabling nodes to request and share package-validation-related +information with one another, resulting in a more efficient and reliable way to propagate packages. + +===Handle Orphans Better=== + +Txid-based transaction relay is problematic since a transaction's witness may be malleated without +changing its txid; a node cannot use txid to deduplicate transactions it has already downloaded +or validated. Ideally, two nodes that both support BIP339 wtxid-based transaction relay shouldn't +ever need to use txid-based transaction relay. + +A single use case of txid-based relay remains: handling "orphan" transactions that spend output(s) +from an unconfirmed transaction the receiving node is unaware of. Orphan transactions are very +common for new nodes that have just completed Initial Block Download and do not have an up-to-date +mempool. Nodes also download transactions from multiple peers. If the peer from which a child +transaction was requested responds faster than the peer from which its parent was requested, that +child is seen as an orphan transaction. + +Nodes may handle orphans by storing them in a cache and requesting any missing parent(s) by txid +(prevouts specify txid, not wtxid). These parents may end up being orphans as well, if they also +spend unconfirmed inputs that the node is unaware of. This method of handling orphans is problematic +for two reasons: it requires nodes to allocate memory for unvalidated data received on the p2p +network and it relies on txid-based relay between two wtxid-relay peers. + +This proposal makes orphan resolution more efficient and no longer require txid-based relay. + +==Definitions== + +Given any two transactions Tx0 and Tx1 where Tx1 spends an output of Tx0, Tx0 is a '''parent''' of +Tx1 and Tx1 is a '''child''' of Tx0. + +A transaction's '''ancestors''' include, recursively, its parents, the parents of its parents, etc. +A transaction's '''descendants''' include, recursively, its children, the children of its children, +etc. A transaction's parent is its ancestor, but an ancestor is not necessarily a parent. + +A '''package''' is a list of transactions, representable by a connected Directed Acyclic +Graph (a directed edge exists between a transaction that spends the output of another transaction). +In this proposal, a package is limited to unconfirmed transactions. + +An '''ancestor package''' consists of an unconfirmed transaction with all of its unconfirmed +ancestors. + +In a '''topologically sorted''' package, each parent appears somewhere in the list before its child. + +==Specification== + +Ancestor Package Relay includes two parts: a package information round and a transaction data +download round. +The package information round is used to help a receiver learn what transactions are in a package and +decide whether they want to download them. The transaction data round is used to help a node download +multiple transactions in one message instead of as separate messages. +<ref>'''Why are package information and transaction data rounds both necessary?''' + +Several alternative designs were considered. One should measure alternative solutions based on the +resources used to communicate (not necessarily trustworthy) information: We would like to minimize +network bandwidth, avoid downloading a transaction more than once, avoid downloading transactions +that are eventually rejected, and minimize storage allocated for not-yet-validated transactions. + +<br /> + +'''No Package Information Round:''' One proposal is to just use the child's wtxid to refer to the +package and always send the entire package together, skipping the package information round. +However, this protocol would make it very likely for honest nodes to redownload duplicate +transactions. See the following example, where the high-feerate ancestors were already downloaded +and accepted individually. + +[[File:./bip-0331/no_package_info.png|600px]] +<br /> + +'''Package Information Only:''' Just having package information gives enough information for the +receiver to accept the packages. That is, rather than using "getpkgtxns" and "pkgtxns" messages, +send "getdata" and download the transactions individually. While this option is a potential fallback +if batched transaction download fails for some reason, it shouldn't be used as the default because +it always requires storage of unvalidated transactions. +[[File:./bip-0331/package_info_only.png|1000px]] +</ref> + +Package relay is negotiated between two peers during the version handshake using a "sendpackages" +message. The versions field within "sendpackages" is interpreted as a bitfield; peers may relay +multiple versions of packages. Package relay requires both peers to support wtxid-based relay +because package transactions are referenced by their wtxids. +<ref>'''Why do we need multiple versions? Why can't we just support arbitrary packages?''' +Attempting to support arbitrary packages in mempool validation may result in very complex logic, new +Denial of Service attack vectors, and policy limitations that could be leveraged to censor +transactions (aka "pinning attacks"). This protocol is extensible to support other types of +packages based on future desired use cases. Future package information messages may describe +different types of packages and/or contain more information than a list of wtxids, e.g. feerate or +relationships between transactions.</ref> +<ref>'''Why use a bitfield instead of a numbering system?''' +It should be possible to support some subset of the existing package types.</ref> + +[[File:./bip-0331/version_negotiation.png|400px]] + +Nodes indicate support for batched transaction data round ("getpkgtxns", "pkgtxns", and +"MSG_PKGTXNS") using the <code>PKG_RELAY_PKGTXNS = (1 << 0)</code> bit in their "sendpackages" +messages during version handshake. They indicate support for the ancestor package information +round ("ancpkginfo", "MSG_ANCPKGINFO") using the <code>PKG_RELAY_ANC = (1 << 1)</code> bit in their +"sendpackages" messages during version handshake. + +===Protocol Flow Examples=== + +This package relay protocol satisfies both use cases (orphan transaction handling and high-feerate +transaction paying for low-feerate ancestors). + +====Orphan Transaction Handling==== + +Upon receiving an orphan transaction, a node may request ancestor package information delineating +the wtxids of the transaction's unconfirmed ancestors. This is done without using txid-based relay. +The package information can be used to request transaction data. As these transactions are dependent +upon one another to be valid, the transactions can be requested and sent as a batch. + +Contrast this protocol with legacy orphan handling, which requires requesting the missing +transactions by their txids and may require new round trips for each generation of missing parents. +[[File:./bip-0331/orphan_handling_flow.png|1000px]] + +====Fee-Bumped Transactions==== + +Too-low-feerate transactions (i.e. below the node's minimum mempool feerate) with high-feerate +descendants can also be relayed this way. If the peers are using BIP133 fee filters and a +low-feerate transaction is below the node's fee filter, the sender will not announce it. The +high-feerate transaction will be sent by the sender, and received and handled as an orphan by the +receiver, the transactions are validated as a package, and so the protocol naturally works for this +use case. + +This does not mean BIP133 is required for package relay to work, provided that nodes do not +immediately reject transactions previously found to be too low feerate. If the low-feerate +transaction was sent and rejected, the receiver should later re-request and accept it after learning +that it is the ancestor of another transaction, and that they meet the receiver's mempool policy +requirements when validated together. + +[[File:./bip-0331/package_cpfp_flow.png|600px]] + +This protocol is receiver-initiated only; nodes do not proactively announce packages to their peers. +<ref>'''Why no sender-initiated protocol?''' Sender-initiated package +relay can, theoretically, save a round trip by notifying the receiver ahead of time that they will +probably need to request and validate a group of transactions together in order for them to be +accepted. As with any proactive communication, there is a chance that the receiver already knows +this information, so this network bandwidth may be wasted. Shortened latency is less significant +than wasted bandwidth. + +The logic used to decide when to announce a package proactively determines whether it is a net +increase or decrease for overall bandwidth usage. However, it is difficult to design anything to +save bandwidth without any idea of what its bandwidth usage actually looks like in practice. No +historical data is available, as one of the primary goals of this protocol is to enable +currently-rejected transactions to propagate. After deploying receiver-initiated package relay, we +can observe its usage and then introduce a sender-initiated package relay protocol informed by data +collected from the p2p network.</ref> + +===Combined Hash=== + +A "combined hash" serves as a unique "package id" for some list of transactions and helps provide a +meaningful but short "notfound" response to "getpkgtxns." + +The combined hash of a package of transactions is equal to the sha256 hash of each transaction's +wtxid concatenated in lexicographical order. + +===New Messages=== + +Four new protocol messages and two inv types are added. + +====sendpackages==== + +{| +| Field Name || Type || Size || Purpose +|- +|versions || uint64_t || 4 || Bit field that is 64 bits wide, denoting the package versions supported by the sender. +|- +|} + +# The "sendpackages" message has the structure defined above, with pchCommand == "sendpackages". + +# During version handshake, nodes should send one "sendpackages" message indicating they support package relay, with the versions field indicating which versions they support. + +# The "sendpackages" message MUST be sent before sending a "verack" message. If a "sendpackages" message is received after "verack", the sender may be disconnected. + +# Upon successful connection ("verack" sent by both peers), a node may relay packages with the peer if they did not set "fRelay" to false in the "version" message, both peers sent "wtxidrelay", and both peers sent "sendpackages" for matching version bit(s). Unknown bits (including versions==0) should be ignored. Peers should relay packages corresponding to versions that both sent "sendpackages" for.<ref>'''Is it ok to send "sendpackages" to a peer that specified fRelay=false in their "version" message?''' +Yes, this is allowed in order to reduce the number of negotiation steps. This means nodes can +announce features without first checking what the other peer has sent, and then apply negotiation +logic at the end based on what was sent and received. See [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020510.html this discussion]. +</ref> + +====ancpkginfo==== +{| +| Field Name || Type || Size || Purpose +|- +|txns_length||CompactSize||1 or 3 bytes|| The number of transactions provided. +|- +|txns||List of wtxids||txns_length * 32|| The wtxids of each transaction in the package. +|} + +# The "ancpkginfo" message has the structure defined above, with pchCommand == "ancpkginfo". + +# The "txns" field should contain a list of wtxids which constitute the ancestor package of the last wtxid. For the receiver's convenience, the sender should - but is not required to - sort the wtxids in topological order. The topological sort can be achieved by sorting the transactions by mempool acceptance order (if parents are always accepted before children). Apart from the last wtxid which is used to learn which transaction the message corresponds to, there is no enforced ordering. Nodes should not disconnect or punish a peer who provides a list not sorted in topological order.<ref>'''Why not include feerate information to help the receiver decide whether these transactions are worth downloading?''' +A simple feerate is typically insufficient; the receiver must also know the dependency +relationships between transactions and their respective sizes. +</ref><ref>'''Should a peer be punished if they provide incorrect package info, e.g. a list of unrelated transactions?''' +Ideally, there should be a way to enforce that peers are providing correct information to each +other. However, two peers may have different views of what a transaction's unconfirmed ancestors +are based on their chainstate. For example, during a reorg or when two blocks are found at the same +time, one peer may see a transaction as confirmed while the other peer does not. +As such, it is impossible to accurately enforce this without also knowing the peer's chainstate. +It was [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html originally proposed] +to include a block hash in "ancpkginfo" to avoid unwarranted disconnections. However, it does not +make much sense to stop or delay transaction data requests due to mismatched chainstates, and the +chainstate may change again between package information and transaction data rounds. Instead, +differences in chainstate should be handled at the validation level. The node has already spent +network bandwidth downloading these transactions; it should make a best effort to validate them. +See [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020558.html discussion]. +</ref><ref>'''Why not require topological order?''' +It is not possible to determine whether a list of transactions is topologically sorted without first +establishing that the list contains a full ancestor package. It is not possible to determine whether +a list of transactions contains a full ancestor package without knowing what the chainstate is. +</ref> + +# Upon receipt of a "ancpkginfo" message, the node may use it to request the transactions it does not already have (e.g. using "getpkgtxns" or "tx"). + +# Upon receipt of a malformed "ancpkginfo" message, the sender may be disconnected. An "ancpkginfo" message is malformed if it contains duplicate wtxids or conflicting transactions (spending the same inputs). The receiver may learn that a package info was malformed after downloading the transactions. + +# A node MUST NOT send a "ancpkginfo" message that has not been requested by the recipient. Upon receipt of an unsolicited "ancpkginfo", a node may disconnect the sender. + +# This message must only be used if both peers set <code>PKG_RELAY_ANC</code> in their "sendpackages" message. If an "ancpkginfo" message is received from a peer with which this type of package relay was not negotiated, no response should be sent and the sender may be disconnected. + +====MSG_ANCPKGINFO==== + +# A new inv type (MSG_ANCPKGINFO == 0x7) is added, for use only in getdata requests pertaining to ancestor packages. + +# As a getdata request type, it indicates that the sender wants an "ancpkginfo" containing all of the unconfirmed ancestors of a transaction, referenced by wtxid. + +# Upon receipt of a "getdata(MSG_ANCPKGINFO)" request, the node should respond with an "ancpkginfo" message corresponding to the transaction's unconfirmed ancestor package, or with "notfound". The wtxid of the requested transaction must be the last item in the "ancpkginfo" response list, as the last item is used to determine which transaction the "ancpkginfo" pertains to. + +# The inv type must only be used in a "getdata" message. An "inv(MSG_ANCPKGINFO)" must never be sent. If an "inv(MSG_ANCPKGINFO)" is received, the sender may be disconnected. + +# This inv type must only be used if both peers set <code>PKG_RELAY_ANC</code> in their "sendpackages" message. If a "getdata" message with type MSG_ANCPKGINFO is received from a peer with which this type of package relay was not negotiated, no response should be sent and the sender may be disconnected. + +====getpkgtxns==== + +{| +| Field Name || Type || Size || Purpose +|- +|txns_length||CompactSize||1 or 3 bytes|| The number of transactions requested. +|- +|txns||List of wtxids||txns_length * 32|| The wtxids of each transaction in the package. +|} + +# The "getpkgtxns" message has the structure defined above, with pchCommand == "getpkgtxns". + +# A "getpkgtxns" message should be used to request some list of transactions specified by witness transaction id. It indicates that the node wants to receive either all the specified transactions or none of them. This message is intended to allow nodes to avoid downloading and storing transactions that cannot be validated without each other. The list of transactions does not need to correspond to a previously-received ancpkginfo message. + +# Upon receipt of a "getpkgtxns" message, a node should respond with either a "pkgtxns" containing all of the requested transactions in the same order specified in the "getpkgtxns" request or one "notfound" message of type MSG_PKGTXNS and combined hash of all of the wtxids in the "getpkgtxns" request (only one "notfound" message and nothing else), indicating one or more of the transactions is unavailable. + +# A "getpkgtxns" message must contain at most 100 wtxids. Upon receipt of a "getpkgtxns" message with more than 100 wtxids, a node may ignore the message (to avoid calculating the combined hash) and disconnect the sender. + +# This message must only be used if both peers set <code>PKG_RELAY_PKGTXNS</code> in their "sendpackages" message. If a "getpkgtxns" message is received from a peer with which this type of package relay was not negotiated, no response should be sent and the sender may be disconnected. + +====pkgtxns==== + +{| +| Field Name || Type || Size || Purpose +|- +|txns_length||CompactSize||1 or 3 bytes|| The number of transactions provided. +|- +|txns||List of transactions||variable|| The transactions in the package. +|} + +# The "pkgtxns" message has the structure defined above, with pchCommand == "pkgtxns". + +# A "pkgtxns" message should contain the transaction data requested using "getpkgtxns". + +# A "pkgtxns" message should only be sent to a peer that requested the package using "getpkgtxns". If a node receives an unsolicited package, it may choose to validate the transactions or not, and the sender may be disconnected. + +# This message must only be used if both peers set <code>PKG_RELAY_PKGTXNS</code> in their "sendpackages" message. If a "pkgtxns" message is received from a peer with which this type of package relay was not negotiated, no response should be sent and the sender may be disconnected. + +====MSG_PKGTXNS==== + +# A new inv type (MSG_PKGTXNS == 0x6) is added, for use only in "notfound" messages pertaining to package transactions. + +# As a "notfound" type, it indicates that the sender is unable to send all the transactions requested in a prior "getpkgtxns" message. The hash used is equal to the combined hash of the wtxids in the getpkgtxns request. + +# This inv type should only be used in "notfound" messages, i.e. "inv(MSG_PKGTXNS)" and "getdata(MSG_PKGTXNS)" must never be sent. Upon receipt of an "inv" or "getdata" message of this type, the sender may be disconnected. + +# This inv type must only be used if both peers set <code>PKG_RELAY_PKGTXNS</code> in their "sendpackages" message. + +==Compatibility== + +Older clients remain fully compatible and interoperable after this change. Clients implementing this +protocol will only attempt to send and request packages if agreed upon during the version handshake. +<ref>'''Will package relay cause non-package relay nodes to waste bandwidth on low-feerate transactions?''' +If a node supports package relay, it may accept low-feerate transactions (e.g. paying zero fees) +into its mempool, but non-package relay nodes would most likely reject them. To mitigate bandwidth +waste, a package relay node should not announce descendants of below-fee-filter transactions to +non-package relay peers. +</ref> +<ref>'''Is Package Erlay possible?''' +A client using BIP330 reconciliation-based transaction relay (Erlay) is able to use package relay +without interference. After reconciliation, any transaction with unconfirmed ancestors may have +those ancestors resolved using ancestor package relay. +[[File:./bip-0331/package_erlay.png|700px]] +</ref> + +==Extensibility== + +This protocol can be extended to include more types of package information in the future, while +continuing to use the same messages for transaction data download. One would define a new package +information message (named "*pkginfo" in the diagram below), allocate its corresponding inv +type (named "*PKGINFO" in the diagram below), and specify how to signal support using the +versions field of "sendpackages" (an additional bit named "PKG_RELAY_*" in the diagram below). A +future version of package relay may allow a sender-initiated dialogue by specifying that the package +info type inv type can be used in an "inv" message. +<br /> +[[File:./bip-0331/sender_init_future_version.png|700px]] + +==Implementation== + +Sample implementation for Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/27742 + +A prerequisite for implementing a safe +package relay protocol is a mempool acceptance policy that safely validates packages of +transactions. +<ref>'''Package Mempool Acceptance Policy''' +Accepting packages from peers should not significantly increase a node's DoS attack surface; +processing packages should not permit waste or exhaustion of the node and network's resources. +Additionally, a sensible mempool acceptance policy should result in the most incentive-compatible +subset of the package in the mempool in order to avoid adding more pinning attacks or censorship +vectors. For example, It should not be assumed that packages are CPFPs. An ancestor package may +include a high-feerate parent and low-feerate child; the policy may choose to accept the parent but +not the child. If one or more transactions are policy-invalid, other transactions that are not +dependent upon them should still be considered. +</ref> + +==Acknowledgements== + +Thank you to Suhas Daftuar, John Newbery, Anthony Towns, Martin Zumsande, and others for input on the design. + +Thank you to Will Clark, Sergi Delgado, Fabian Jahr, John Newbery, Greg Sanders, Stéphan Vuylsteke, Pieter Wuille, and others for input on this document. + +Much of this work is inspired by ideas and code by Suhas Daftuar and Antoine Riard. +<ref>'''Prior Work on Package Relay''' +* [https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a Strawman Proposal] +* [https://github.com/bitcoin/bitcoin/issues/14895 Package relay design questions] +* [https://github.com/bitcoin/bitcoin/pull/16401 Add package acceptance logic to mempool] +* [https://github.com/bitcoin/bitcoin/pull/19621 [RFC] Package-relay: sender-initiated] +</ref> + +==References and Rationale== + +<references/> + diff --git a/bip-0331/no_package_info.png b/bip-0331/no_package_info.png Binary files differnew file mode 100644 index 0000000..54b20f9 --- /dev/null +++ b/bip-0331/no_package_info.png diff --git a/bip-0331/orphan_handling_flow.png b/bip-0331/orphan_handling_flow.png Binary files differnew file mode 100644 index 0000000..4588de8 --- /dev/null +++ b/bip-0331/orphan_handling_flow.png diff --git a/bip-0331/package_cpfp_flow.png b/bip-0331/package_cpfp_flow.png Binary files differnew file mode 100644 index 0000000..6b48c5d --- /dev/null +++ b/bip-0331/package_cpfp_flow.png diff --git a/bip-0331/package_erlay.png b/bip-0331/package_erlay.png Binary files differnew file mode 100644 index 0000000..fd3661f --- /dev/null +++ b/bip-0331/package_erlay.png diff --git a/bip-0331/package_info_only.png b/bip-0331/package_info_only.png Binary files differnew file mode 100644 index 0000000..2bd0272 --- /dev/null +++ b/bip-0331/package_info_only.png diff --git a/bip-0331/sender_init_future_version.png b/bip-0331/sender_init_future_version.png Binary files differnew file mode 100644 index 0000000..d4a2105 --- /dev/null +++ b/bip-0331/sender_init_future_version.png diff --git a/bip-0331/version_negotiation.png b/bip-0331/version_negotiation.png Binary files differnew file mode 100644 index 0000000..5b2f48c --- /dev/null +++ b/bip-0331/version_negotiation.png diff --git a/bip-0337.mediawiki b/bip-0337.mediawiki new file mode 100644 index 0000000..e87c5bc --- /dev/null +++ b/bip-0337.mediawiki @@ -0,0 +1,301 @@ +<pre> + BIP: 337 + Layer: API/RPC + Title: Compressed Transactions + Author: Tom Briar <tombriar11@protonmail.com> + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0337 + Status: Draft + Type: Standards Track + Created: 2024-02-01 + License: BSD-3-Clause + Post-History: https://github.com/bitcoin/bitcoin/pull/29134 + https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html +</pre> + +== Introduction == + +=== Abstract === +This document proposes a serialization scheme for compressing Bitcoin transactions. The compressed Bitcoin transactions can reach a serialized size of less than 50% of the original serialized transaction. One method for compressing involves reducing the transaction outpoints in a potentially lossy way. Therefore, it is an optional path for compression. Compressing the outpoints is necessary for compressed transactions to reach less than 70% of the original size. + +=== Motivation === +Typical Bitcoin transactions usually contain a large amount of white space and padding due to specific fields that are often one of a minimal number of possibilities. We can use this fact and a few similar methods to create an encoding for 90% of Bitcoin transactions that are roughly 25-50% smaller. + +There exists a working-in-progress app that allows the use of steganography to encode data in images to be passed around via various social media groups. When used in conjunction with this compression scheme and an elligator squared encryption, this would allow for a very secure and private form of broadcasting bitcoin transactions. + +=== Rationale === + +The four main methods to achieve a lower transaction size are: + +1. Packing transaction metadata before it and each of its inputs and outputs to determine the following data structure. + +2. Replacing 32-bit numeric values with either variable-length integers (VarInts) or compact integers (CompactSizes). + +3. Using compressed signatures and public key recovery upon decompression. + +4. Replacing the 36-byte Outpoint txid/vout pair with a block height and index. + + +=== Backwards Compatibility === + +There are no concerns with backwards compatibility. + +=== Specification === + +==== Primitives ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| CompactSize || 1-5 Bytes || For 0-253, encode the value directly in one byte. For 254-65535, encode 254 followed by two little-endian bytes. For 65536-(2^32-1), encode 255 followed by four little-endian bytes. +|- +| CompactSize Flag || 2 Bits || 1, 2, or 3 indicate literal values. 0 indicates that a CompactSize encoding of the value will follow. +|- +| VarInt || 1+ Bytes || 7-bit little-endian encoding, with each 7-bit word encoded in a byte. The highest bit of each byte is one if more bytes follow, and 0 for the last byte. +|- +| VLP-Bytestream || 2+ Bytes || A VarInt Length Prefixed Bytestream. It uses the prefixed VarInt to determine the length of the following byte stream. +|} + +==== General Schema ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Transaction metadata || 1 Bytes || Information on the structure of the transaction. See [[#transaction-metadata|Transaction Metadata]] +|- +| Version || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction version. +|- +| Input Count || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction input count. +|- +| Output Count || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction output count. +|- +| LockTime || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction LockTime. +|- +| Minimum Blockheight || 1-5 Bytes || If present according to the metadata field, a VarInt encoding of the minimum block height for transaction compressed inputs and LockTime. +|- +| Input Metadata+Output Metadata || 1+ Bytes || An encoding containing the metadata for all the inputs followed by all the outputs of the transaction. For each input, see [[#input-metadata|Input Metadata]], and for each output, see [[#output-metadata|Output Metadata]]. +|- +| Input Data || 66+ Bytes || See [[#input-data|Input Data]]. +|- +| Output Data || 3+ Bytes || See [[#output-data|Output Data]]. +|} + +<span id="transaction-metadata"></span> +==== Transaction Metadata ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Version || 2 Bits || A CompactSize flag for the transaction version. +|- +| Input Count || 2 Bits || A CompactSize flag for the transaction input count. +|- +| Output Count || 2 Bits || A CompactSize flag for the transaction output count. +|- +| LockTime || 1 Bit || A boolean to indicate if the transaction has a LockTime. +|- +| Minimum Blockheight || 1 Bit || A boolean to indicate if the transaction minimum block height is greater than zero. +|} + +<span id="input-metadata"></span> +==== Input Metadata ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Compressed Signature || 1 Bit || A Boolean do determine if this input's signature is compressed. The signature is only compressed for P2TR on a key spend and for P2SH when it is a wrapped P2SH-WPKH. +|- +| Standard Hash || 1 Bit || A Boolean to determine if this input's signature hash type is standard (0x00 for Taproot, 0x01 for Legacy/Segwit). +|- +| Standard Sequence || 2 Bits || A CompactSize flag for this input's sequence. Encode literal values as follows: 1 = 0x00000000, 2 = 0xFFFFFFFE, 3 = 0xFFFFFFFF. +|- +| Compressed OutPoint || 1 bit || A Boolean to determine if the input's outpoint is compressed. +|} + +<span id="output-metadata"></span> +==== Output Metadata ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Encoded Script Type || 3 Bits || [[#script-type-encoding|Encoded Script Type]]. +|} + +<span id="script-type-encoding"></span> +==== Script Type Encoding ==== + +{| class="wikitable" style="margin:auto" +|- +! Script Type !! Value +|- +| Uncompressed Custom Script || 0b000 +|- +| Uncompressed P2PK || 0b001 +|- +| Compressed P2PK || 0b010 +|- +| P2PKH || 0b011 +|- +| P2SH || 0b100 +|- +| P2WPKH || 0b101 +|- +| P2WSH || 0b110 +|- +| P2TR || 0b111 +|} + +<span id="input-data"></span> +==== Input Data ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Outpoint || 2-37 Bytes || The Outpoint Txid/Vout are determined to be compressed or otherwise by the "Compressed Outpoint" Boolean in the input metadata. For each compressed outpoint see [[#compressed-outpoint|Compressed Outpoint]]. For each uncompressed signature see [[#uncompressed-outpoint|Uncompressed Outpoint]]. +|- +| Signature || 64+ Bytes || The Signature is determined to be compressed or otherwise by the output script of the previous transaction. For each compressed signature see [[#compressed-signature|Compressed Signature]]. For each uncompressed signature see [[#uncompressed-signature|Uncompressed Signature]]. +|- +| Sequence || 0-5 Bytes || If present due to a non-standard sequence, a VarInt encoding of the sequence. +|} + +<span id="compressed-outpoint"></span> +==== Compressed Outpoint ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Txid Block Height || 1-5 Bytes || A VarInt containing the offset from Minimum Blockheight for this Txid. +|- +| Txid Block Index || 1-5 Bytes || A VarInt containing the flattened index from the Txid block height for the Vout. +|} + +<span id="uncompressed-outpoint"></span> +==== Uncompressed Outpoint ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Txid || 32 Bytes || Contains the 32 Byte Txid. +|- +| Vout || 1-5 Bytes || A CompactSize Containing the Vout of the Txid. +|} + + +<span id="compressed-signature"></span> +==== Compressed Signature ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Signature || 64 Bytes || Contains the 64 Byte signature. +|- +| Pubkey Hash || 0-20 Bytes || If input is P2SH-P2WPKH contains the 20 byte hash of the public key. +|- +| Hash Type || 0-1 Bytes || An Optional Byte containing the Hash Type if it was non-standard. +|} + +<span id="uncompressed-signature"></span> +==== Uncompressed Signature ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Signature || 2+ Bytes || A VLP-Bytestream containing the signature. +|} + +<span id="output-data"></span> +==== Output Data ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Output Script || 2+ Bytes || A VLP-Bytestream containing the output script. +|- +| Amount || 1-9 Bytes || A VarInt containing the output amount. +|} + +==== Ideal Transaction ==== + +The compression scheme was designed to be optimal for a "typical" transaction, spending a few close-in-age inputs and having one or two outputs. Here are size +values for such a transaction, which demonstrate the effectiveness of the compression. + +{| class="wikitable" style="margin:auto" +|- +! Field !! Requirements !! Savings Up To +|- +| Version || Less than four || 30 Bits +|- +| Input Count || Less than four || 30 Bits +|- +| Output Count || Less than four || 30 Bits +|- +| LockTime || 0 || 30 Bits +|- +| Input Sequence || 0x00, 0xFFFFFFFE, or 0xFFFFFFFF || 62 Bits For Each Input +|- +| Input Txid || Compressed Outpoint || 23 - 31 Bytes For Each Input +|- +| Input Vout || Compressed Outpoint || (-1) - 3 Bytes For Each Input +|- +| Input Signature || Non-custom Script Signing || 40 - 72 Bytes For Each Legacy Input +|- +| Input Hash Type || 0x00 for Taproot, 0x01 for Legacy || 7 Bits For Each Input +|- +| Output Script || Non-custom Scripts || 2 - 5 Bytes For Each Output +|- +| Output Amount || No Restrictions || (-1) - 7 Bytes For Each Output +|} + +=== Reference Implementation === + +This reference implementation adds two new RPC endpoints, compressrawtransaction and decompressrawtransaction. The first accepts a raw hex-encoded transaction and returns a compact hex-encoded transaction; also included in the output is a list of warnings to help ensure there are no unexpected uncompressed values. The second accepts a compact hex transaction and returns the uncompressed raw hex-encoded transaction. + +https://github.com/bitcoin/bitcoin/pull/29134 + +=== Test Vectors === + +==== Taproot ==== + +===== Uncompressed ===== +<code>020000000001017ad1d0cc314504ec06f1b5c786c50cf3cda30bd5be88cf08ead571b0ce7481fb0000000000fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226201408ce65b3170d3fbc68e3b6980650514dc53565f915d14351f83050ff50c8609495b7aa96271c3c99cdac1a92b1b45e77a4a870251fc1673596793adf2494565e500000000</code> + +===== Compressed ===== +<code>96b1ec7f968001b0218ce65b3170d3fbc68e3b6980650514dc53565f915d14351f83050ff50c8609495b7aa96271c3c99cdac1a92b1b45e77a4a870251fc1673596793adf2494565e58efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code> + +==== P2WPKH ==== + +===== Uncompressed ===== +<code>0200000000010144bcf05ab48b8789268a7ca07133241ad654c0739ac7165015b2d669eadb10ea0000000000fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226202473044022043ab639a98dfbc704f16a35bf25b8b72acb4cb928fd772285f1fcf63725caa85022001c9ff354504e7024708bce61f30370c8db13da8170cef4e8e4c4cdad0f71bfe0121030072484c24705512bfb1f7f866d95f808d81d343e552bc418113e1b9a1da0eb400000000</code> + +===== Compressed ===== +<code>96b1ec71968001932643ab639a98dfbc704f16a35bf25b8b72acb4cb928fd772285f1fcf63725caa8501c9ff354504e7024708bce61f30370c8db13da8170cef4e8e4c4cdad0f71bfe8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code> + +==== P2SH-P2WPKH ==== + +===== Uncompressed ===== +<code>0200000000010192fb2e4332b43dc9a73febba67f3b7d97ba890673cb08efde2911330f77bbdfc00000000171600147a1979232206857167b401fdac1ffbf33f8204fffdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226202473044022041eb682e63c25b85a5a400b11d41cf4b9c25f309090a5f3e0b69dc15426da90402205644ddc3d5179bab49cce4bf69ebfaeab1afa34331c1a0a70be2927d2836b0e8012103c483f1b1bd24dd23b3255a68d87ef9281f9d080fd707032ccb81c1cc56c5b00200000000</code> + +===== Compressed ===== +<code>96b1ec7c9e8001981641eb682e63c25b85a5a400b11d41cf4b9c25f309090a5f3e0b69dc15426da9045644ddc3d5179bab49cce4bf69ebfaeab1afa34331c1a0a70be2927d2836b0e87a1979232206857167b401fdac1ffbf33f8204ff8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code> + +==== P2PKH ==== + +===== Uncompressed ===== +<code>02000000015f5be26862482fe2fcc900f06ef26ee256fb205bc4773e5a402d0c1b88b82043000000006a473044022031a20f5d9212023b510599c9d53d082f8e07faaa2d51482e078f8e398cb50d770220635abd99220ad713a081c4f20b83cb3f491ed8bd032cb151a3521ed144164d9c0121027977f1b6357cead2df0a0a19570088a1eb9115468b2dfa01439493807d8f1294fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226200000000</code> + +===== Compressed ===== +<code>96b1ec7c968001981431a20f5d9212023b510599c9d53d082f8e07faaa2d51482e078f8e398cb50d77635abd99220ad713a081c4f20b83cb3f491ed8bd032cb151a3521ed144164d9c8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code> + + +== Acknowledgements == +Thank you to Andrew Poelstra, who helped invent and develop the ideas in the proposal and the code for reference implementation. diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki index c99b77a..85b7bac 100644 --- a/bip-0340.mediawiki +++ b/bip-0340.mediawiki @@ -62,7 +62,7 @@ Since we would like to avoid the fragility that comes with short hashes, the ''e '''Key prefixing''' Using the verification rule above directly makes Schnorr signatures vulnerable to "related-key attacks" in which a third party can convert a signature ''(R, s)'' for public key ''P'' into a signature ''(R, s + a⋅hash(R || m))'' for public key ''P + a⋅G'' and the same message ''m'', for any given additive tweak ''a'' to the signing key. This would render signatures insecure when keys are generated using [[bip-0032.mediawiki#public-parent-key--public-child-key|BIP32's unhardened derivation]] and other methods that rely on additive tweaks to existing keys such as Taproot. -To protect against these attacks, we choose ''key prefixed''<ref>A limitation of committing to the public key (rather than to a short hash of it, or not at all) is that it removes the ability for public key recovery or verifying signatures against a short public key hash. These constructions are generally incompatible with batch verification.</ref> Schnorr signatures which means that the public key is prefixed to the message in the challenge hash input. This changes the equation to ''s⋅G = R + hash(R || P || m)⋅P''. [https://eprint.iacr.org/2015/1135.pdf It can be shown] that key prefixing protects against related-key attacks with additive tweaks. In general, key prefixing increases robustness in multi-user settings, e.g., it seems to be a requirement for proving the MuSig multisignature scheme secure (see Applications below). +To protect against these attacks, we choose ''key prefixed''<ref>A limitation of committing to the public key (rather than to a short hash of it, or not at all) is that it removes the ability for public key recovery or verifying signatures against a short public key hash. These constructions are generally incompatible with batch verification.</ref> Schnorr signatures which means that the public key is prefixed to the message in the challenge hash input. This changes the equation to ''s⋅G = R + hash(R || P || m)⋅P''. [https://eprint.iacr.org/2015/1135.pdf It can be shown] that key prefixing protects against related-key attacks with additive tweaks. In general, key prefixing increases robustness in multi-user settings, e.g., it seems to be a requirement for proving multiparty signing protocols (such as MuSig, MuSig2, and FROST) secure (see Applications below). We note that key prefixing is not strictly necessary for transaction signatures as used in Bitcoin currently, because signed transactions indirectly commit to the public keys already, i.e., ''m'' contains a commitment to ''pk''. However, this indirect commitment should not be relied upon because it may change with proposals such as SIGHASH_NOINPUT ([[bip-0118.mediawiki|BIP118]]), and would render the signature scheme unsuitable for other purposes than signing transactions, e.g., [https://bitcoin.org/en/developer-reference#signmessage signing ordinary messages]. @@ -86,7 +86,7 @@ Despite halving the size of the set of valid public keys, implicit Y coordinates For example, without tagged hashing a BIP340 signature could also be valid for a signature scheme where the only difference is that the arguments to the hash function are reordered. Worse, if the BIP340 nonce derivation function was copied or independently created, then the nonce could be accidentally reused in the other scheme leaking the secret key. -This proposal suggests to include the tag by prefixing the hashed data with ''SHA256(tag) || SHA256(tag)''. Because this is a 64-byte long context-specific constant and the ''SHA256'' block size is also 64 bytes, optimized implementations are possible (identical to SHA256 itself, but with a modified initial state). Using SHA256 of the tag name itself is reasonably simple and efficient for implementations that don't choose to use the optimization. +This proposal suggests to include the tag by prefixing the hashed data with ''SHA256(tag) || SHA256(tag)''. Because this is a 64-byte long context-specific constant and the ''SHA256'' block size is also 64 bytes, optimized implementations are possible (identical to SHA256 itself, but with a modified initial state). Using SHA256 of the tag name itself is reasonably simple and efficient for implementations that don't choose to use the optimization. In general, tags can be arbitrary byte arrays, but are suggested to be textual descriptions in UTF-8 encoding. '''Final scheme''' As a result, our final scheme ends up using public key ''pk'' which is the X coordinate of a point ''P'' on the curve whose Y coordinate is even and signatures ''(r,s)'' where ''r'' is the X coordinate of a point ''R'' whose Y coordinate is even. The signature satisfies ''s⋅G = R + tagged_hash(r || pk || m)⋅P''. @@ -116,7 +116,7 @@ The following conventions are used, with constants as defined for [https://www.s *** Let ''y = c<sup>(p+1)/4</sup> mod p''. *** Fail if ''c ≠ y<sup>2</sup> mod p''. *** Return the unique point ''P'' such that ''x(P) = x'' and ''y(P) = y'' if ''y mod 2 = 0'' or ''y(P) = p-y'' otherwise. -** The function ''hash<sub>tag</sub>(x)'' where ''tag'' is a UTF-8 encoded tag name and ''x'' is a byte array returns the 32-byte hash ''SHA256(SHA256(tag) || SHA256(tag) || x)''. +** The function ''hash<sub>name</sub>(x)'' where ''x'' is a byte array returns the 32-byte hash ''SHA256(SHA256(tag) || SHA256(tag) || x)'', where ''tag'' is the UTF-8 encoding of ''name''. ==== Public Key Generation ==== @@ -138,7 +138,7 @@ As an alternative to generating keys randomly, it is also possible and safe to r Input: * The secret key ''sk'': a 32-byte array -* The message ''m'': a 32-byte array +* The message ''m'': a byte array * Auxiliary random data ''a'': a 32-byte array The algorithm ''Sign(sk, m)'' is defined as: @@ -165,7 +165,7 @@ It should be noted that various alternative signing algorithms can be used to pr '''Nonce exfiltration protection''' It is possible to strengthen the nonce generation algorithm using a second device. In this case, the second device contributes randomness which the actual signer provably incorporates into its nonce. This prevents certain attacks where the signer device is compromised and intentionally tries to leak the secret key through its nonce selection. -'''Multisignatures''' This signature scheme is compatible with various types of multisignature and threshold schemes such as [https://eprint.iacr.org/2018/068 MuSig], where a single public key requires holders of multiple secret keys to participate in signing (see Applications below). +'''Multisignatures''' This signature scheme is compatible with various types of multisignature and threshold schemes such as [https://eprint.iacr.org/2020/1261.pdf MuSig2], where a single public key requires holders of multiple secret keys to participate in signing (see Applications below). '''It is important to note that multisignature signing schemes in general are insecure with the ''rand'' generation from the default signing algorithm above (or any other deterministic method).''' '''Precomputed public key data''' For many uses the compressed 33-byte encoding of the public key corresponding to the secret key may already be known, making it easy to evaluate ''has_even_y(P)'' and ''bytes(P)''. As such, having signers supply this directly may be more efficient than recalculating the public key from the secret key. However, if this optimization is used and additionally the signature verification at the end of the signing algorithm is dropped for increased efficiency, signers must ensure the public key is correctly calculated and not taken from untrusted sources. @@ -174,7 +174,7 @@ It should be noted that various alternative signing algorithms can be used to pr Input: * The public key ''pk'': a 32-byte array -* The message ''m'': a 32-byte array +* The message ''m'': a byte array * A signature ''sig'': a 64-byte array The algorithm ''Verify(pk, m, sig)'' is defined as: @@ -197,7 +197,7 @@ Note that the correctness of verification relies on the fact that ''lift_x'' alw Input: * The number ''u'' of signatures * The public keys ''pk<sub>1..u</sub>'': ''u'' 32-byte arrays -* The messages ''m<sub>1..u</sub>'': ''u'' 32-byte arrays +* The messages ''m<sub>1..u</sub>'': ''u'' byte arrays * The signatures ''sig<sub>1..u</sub>'': ''u'' 64-byte arrays The algorithm ''BatchVerify(pk<sub>1..u</sub>, m<sub>1..u</sub>, sig<sub>1..u</sub>)'' is defined as: @@ -213,6 +213,50 @@ The algorithm ''BatchVerify(pk<sub>1..u</sub>, m<sub>1..u</sub>, sig<sub>1..u</s If all individual signatures are valid (i.e., ''Verify'' would return success for them), ''BatchVerify'' will always return success. If at least one signature is invalid, ''BatchVerify'' will return success with at most a negligible probability. +=== Usage Considerations === + +==== Messages of Arbitrary Size ==== + +The signature scheme specified in this BIP accepts byte strings of arbitrary size as input messages.<ref>In theory, the message size is restricted due to the fact that SHA256 accepts byte strings only up to size of 2^61-1 bytes.</ref> +It is understood that implementations may reject messages which are too large in their environment or application context, +e.g., messages which exceed predefined buffers or would otherwise cause resource exhaustion. + +Earlier revisions of this BIP required messages to be exactly 32 bytes. +This restriction puts a burden on callers +who typically need to perform pre-hashing of the actual input message by feeding it through SHA256 (or another collision-resistant cryptographic hash function) +to create a 32-byte digest which can be passed to signing or verification +(as for example done in [[bip-0341.mediawiki|BIP341]].) + +Since pre-hashing may not always be desirable, +e.g., when actual messages are shorter than 32 bytes,<ref>Another reason to omit pre-hashing is to protect against certain types of cryptanalytic advances against the hash function used for pre-hashing: If pre-hashing is used, an attacker that can find collisions in the pre-hashing function can necessarily forge signatures under chosen-message attacks. If pre-hashing is not used, an attacker that can find collisions in SHA256 (as used inside the signature scheme) may not be able to forge signatures. However, this seeming advantage is mostly irrelevant in the context of Bitcoin, which already relies on collision resistance of SHA256 in other places, e.g., for transaction hashes.</ref> +the restriction to 32-byte messages has been lifted. +We note that pre-hashing is recommended for performance reasons in applications that deal with large messages. +If large messages are not pre-hashed, +the algorithms of the signature scheme will perform more hashing internally. +In particular, the signing algorithm needs two sequential hashing passes over the message, +which means that the full message must necessarily be kept in memory during signing, +and large messages entail a runtime penalty.<ref>Typically, messages of 56 bytes or longer enjoy a performance benefit from pre-hashing, assuming the speed of SHA256 inside the signing algorithm matches that of the pre-hashing done by the calling application.</ref> + +==== Domain Separation ==== + +It is good cryptographic practice to use a key pair only for a single purpose. +Nevertheless, there may be situations in which it may be desirable to use the same key pair in multiple contexts, +i.e., to sign different types of messages within the same application +or even messages in entirely different applications +(e.g., a secret key may be used to sign Bitcoin transactions as well plain text messages). + +As a consequence, applications should ensure that a signed application message intended for one context is never deemed valid in a different context +(e.g., a signed plain text message should never be misinterpreted as a signed Bitcoin transaction, because this could cause unintended loss of funds). +This is called "domain separation" and it is typically realized by partitioning the message space. +Even if key pairs are intended to be used only within a single context, +domain separation is a good idea because it makes it easy to add more contexts later. + +As a best practice, we recommend applications to use exactly one of the following methods to pre-process application messages before passing it to the signature scheme: +* Either, pre-hash the application message using ''hash<sub>name</sub>'', where ''name'' identifies the context uniquely (e.g., "foo-app/signed-bar"), +* or prefix the actual message with a 33-byte string that identifies the context uniquely (e.g., the UTF-8 encoding of "foo-app/signed-bar", padded with null bytes to 33 bytes). + +As the two pre-processing methods yield different message sizes (32 bytes vs. at least 33 bytes), there is no risk of collision between them. + == Applications == There are several interesting applications beyond simple signatures. @@ -220,9 +264,9 @@ While recent academic papers claim that they are also possible with ECDSA, conse === Multisignatures and Threshold Signatures === -By means of an interactive scheme such as [https://eprint.iacr.org/2018/068 MuSig], participants can aggregate their public keys into a single public key which they can jointly sign for. This allows ''n''-of-''n'' multisignatures which, from a verifier's perspective, are no different from ordinary signatures, giving improved privacy and efficiency versus ''CHECKMULTISIG'' or other means. +By means of an interactive scheme such as [https://eprint.iacr.org/2020/1261.pdf MuSig2] ([[bip-0327.mediawiki|BIP327]]), participants can aggregate their public keys into a single public key which they can jointly sign for. This allows ''n''-of-''n'' multisignatures which, from a verifier's perspective, are no different from ordinary signatures, giving improved privacy and efficiency versus ''CHECKMULTISIG'' or other means. -Moreover, Schnorr signatures are compatible with [https://web.archive.org/web/20031003232851/http://www.research.ibm.com/security/dkg.ps distributed key generation], which enables interactive threshold signatures schemes, e.g., the schemes described by [http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps Stinson and Strobl (2001)] or [https://web.archive.org/web/20060911151529/http://theory.lcs.mit.edu/~stasio/Papers/gjkr03.pdf Gennaro, Jarecki and Krawczyk (2003)]. These protocols make it possible to realize ''k''-of-''n'' threshold signatures, which ensure that any subset of size ''k'' of the set of ''n'' signers can sign but no subset of size less than ''k'' can produce a valid Schnorr signature. However, the practicality of the existing schemes is limited: most schemes in the literature have been proven secure only for the case ''k-1 < n/2'', are not secure when used concurrently in multiple sessions, or require a reliable broadcast mechanism to be secure. Further research is necessary to improve this situation. +Moreover, Schnorr signatures are compatible with [https://en.wikipedia.org/wiki/Distributed_key_generation distributed key generation], which enables interactive threshold signatures schemes, e.g., the schemes by [http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps Stinson and Strobl (2001)], by [https://link.springer.com/content/pdf/10.1007/s00145-006-0347-3.pdf Gennaro, Jarecki, Krawczyk, and Rabin (2007)], or the [https://eprint.iacr.org/2020/852.pdf FROST] scheme including its variants such as [https://eprint.iacr.org/2023/899.pdf FROST3]. These protocols make it possible to realize ''k''-of-''n'' threshold signatures, which ensure that any subset of size ''k'' of the set of ''n'' signers can sign but no subset of size less than ''k'' can produce a valid Schnorr signature. === Adaptor Signatures === @@ -234,7 +278,7 @@ Adaptor signatures, beyond the efficiency and privacy benefits of encoding scrip === Blind Signatures === -A blind signature protocol is an interactive protocol that enables a signer to sign a message at the behest of another party without learning any information about the signed message or the signature. Schnorr signatures admit a very [http://publikationen.ub.uni-frankfurt.de/files/4292/schnorr.blind_sigs_attack.2001.pdf simple blind signature scheme] which is however insecure because it's vulnerable to [https://www.iacr.org/archive/crypto2002/24420288/24420288.pdf Wagner's attack]. A known mitigation is to let the signer abort a signing session with a certain probability, and the resulting scheme can be [https://eprint.iacr.org/2019/877 proven secure under non-standard cryptographic assumptions]. +A blind signature protocol is an interactive protocol that enables a signer to sign a message at the behest of another party without learning any information about the signed message or the signature. Schnorr signatures admit a very [http://publikationen.ub.uni-frankfurt.de/files/4292/schnorr.blind_sigs_attack.2001.pdf simple blind signature scheme] which is however insecure because it's vulnerable to [https://www.iacr.org/archive/crypto2002/24420288/24420288.pdf Wagner's attack]. Known mitigations are to let the signer abort a signing session with a certain probability, which can be [https://eprint.iacr.org/2019/877 proven secure under non-standard cryptographic assumptions], or [https://eprint.iacr.org/2022/1676.pdf to use zero-knowledge proofs]. Blind Schnorr signatures could for example be used in [https://github.com/ElementsProject/scriptless-scripts/blob/master/md/partially-blind-swap.md Partially Blind Atomic Swaps], a construction to enable transferring of coins, mediated by an untrusted escrow agent, without connecting the transactors in the public blockchain transaction graph. @@ -248,6 +292,8 @@ The reference implementation is for demonstration purposes only and not to be us To help implementors understand updates to this BIP, we keep a list of substantial changes. * 2022-08: Fix function signature of lift_x in reference code +* 2023-04: Allow messages of arbitrary size +* 2024-05: Update "Applications" section with more recent references == Footnotes == diff --git a/bip-0340/reference.py b/bip-0340/reference.py index 162bb88..b327e0a 100644 --- a/bip-0340/reference.py +++ b/bip-0340/reference.py @@ -96,8 +96,6 @@ def pubkey_gen(seckey: bytes) -> bytes: return bytes_from_point(P) def schnorr_sign(msg: bytes, seckey: bytes, aux_rand: bytes) -> bytes: - if len(msg) != 32: - raise ValueError('The message must be a 32-byte array.') d0 = int_from_bytes(seckey) if not (1 <= d0 <= n - 1): raise ValueError('The secret key must be an integer in the range 1..n-1.') @@ -121,8 +119,6 @@ def schnorr_sign(msg: bytes, seckey: bytes, aux_rand: bytes) -> bytes: return sig def schnorr_verify(msg: bytes, pubkey: bytes, sig: bytes) -> bool: - if len(msg) != 32: - raise ValueError('The message must be a 32-byte array.') if len(pubkey) != 32: raise ValueError('The public key must be a 32-byte array.') if len(sig) != 64: diff --git a/bip-0340/test-vectors.csv b/bip-0340/test-vectors.csv index a1a63e1..6723391 100644 --- a/bip-0340/test-vectors.csv +++ b/bip-0340/test-vectors.csv @@ -14,3 +14,7 @@ index,secret key,public key,aux_rand,message,signature,verification result,comme 12,,DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659,,243F6A8885A308D313198A2E03707344A4093822299F31D0082EFA98EC4E6C89,FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F69E89B4C5564D00349106B8497785DD7D1D713A8AE82B32FA79D5F7FC407D39B,FALSE,sig[0:32] is equal to field size
13,,DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659,,243F6A8885A308D313198A2E03707344A4093822299F31D0082EFA98EC4E6C89,6CFF5C3BA86C69EA4B7376F31A9BCB4F74C1976089B2D9963DA2E5543E177769FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141,FALSE,sig[32:64] is equal to curve order
14,,FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC30,,243F6A8885A308D313198A2E03707344A4093822299F31D0082EFA98EC4E6C89,6CFF5C3BA86C69EA4B7376F31A9BCB4F74C1976089B2D9963DA2E5543E17776969E89B4C5564D00349106B8497785DD7D1D713A8AE82B32FA79D5F7FC407D39B,FALSE,public key is not a valid X coordinate because it exceeds the field size
+15,0340034003400340034003400340034003400340034003400340034003400340,778CAA53B4393AC467774D09497A87224BF9FAB6F6E68B23086497324D6FD117,0000000000000000000000000000000000000000000000000000000000000000,,71535DB165ECD9FBBC046E5FFAEA61186BB6AD436732FCCC25291A55895464CF6069CE26BF03466228F19A3A62DB8A649F2D560FAC652827D1AF0574E427AB63,TRUE,message of size 0 (added 2022-12)
+16,0340034003400340034003400340034003400340034003400340034003400340,778CAA53B4393AC467774D09497A87224BF9FAB6F6E68B23086497324D6FD117,0000000000000000000000000000000000000000000000000000000000000000,11,08A20A0AFEF64124649232E0693C583AB1B9934AE63B4C3511F3AE1134C6A303EA3173BFEA6683BD101FA5AA5DBC1996FE7CACFC5A577D33EC14564CEC2BACBF,TRUE,message of size 1 (added 2022-12)
+17,0340034003400340034003400340034003400340034003400340034003400340,778CAA53B4393AC467774D09497A87224BF9FAB6F6E68B23086497324D6FD117,0000000000000000000000000000000000000000000000000000000000000000,0102030405060708090A0B0C0D0E0F1011,5130F39A4059B43BC7CAC09A19ECE52B5D8699D1A71E3C52DA9AFDB6B50AC370C4A482B77BF960F8681540E25B6771ECE1E5A37FD80E5A51897C5566A97EA5A5,TRUE,message of size 17 (added 2022-12)
+18,0340034003400340034003400340034003400340034003400340034003400340,778CAA53B4393AC467774D09497A87224BF9FAB6F6E68B23086497324D6FD117,0000000000000000000000000000000000000000000000000000000000000000,99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999,403B12B0D8555A344175EA7EC746566303321E5DBFA8BE6F091635163ECA79A8585ED3E3170807E7C03B720FC54C7B23897FCBA0E9D0B4A06894CFD249F22367,TRUE,message of size 100 (added 2022-12)
diff --git a/bip-0340/test-vectors.py b/bip-0340/test-vectors.py index d1bf6b2..317f2ec 100644 --- a/bip-0340/test-vectors.py +++ b/bip-0340/test-vectors.py @@ -249,6 +249,20 @@ def vector14(): return (None, pubkey, None, msg, sig, "FALSE", "public key is not a valid X coordinate because it exceeds the field size") +def varlen_vector(msg_int): + seckey = bytes_from_int(int(16 * "0340", 16)) + pubkey = pubkey_gen(seckey) + aux_rand = bytes_from_int(0) + msg = msg_int.to_bytes((msg_int.bit_length() + 7) // 8, "big") + sig = schnorr_sign(msg, seckey, aux_rand) + comment = "message of size %d (added 2022-12)" + return (seckey, pubkey, aux_rand, msg, sig, "TRUE", comment % len(msg)) + +vector15 = lambda : varlen_vector(0) +vector16 = lambda : varlen_vector(0x11) +vector17 = lambda : varlen_vector(0x0102030405060708090A0B0C0D0E0F1011) +vector18 = lambda : varlen_vector(int(100 * "99", 16)) + vectors = [ vector0(), vector1(), @@ -264,7 +278,11 @@ vectors = [ vector11(), vector12(), vector13(), - vector14() + vector14(), + vector15(), + vector16(), + vector17(), + vector18(), ] # Converts the byte strings of a test vector into hex strings diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 392ad67..639cec6 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -152,7 +152,7 @@ Satisfying any of these conditions is sufficient to spend the output. '''Initial steps''' The first step is determining what the internal key and the organization of the rest of the scripts should be. The specifics are likely application dependent, but here are some general guidelines: * When deciding between scripts with conditionals (<code>OP_IF</code> etc.) and splitting them up into multiple scripts (each corresponding to one execution path through the original script), it is generally preferable to pick the latter. * When a single condition requires signatures with multiple keys, key aggregation techniques like MuSig can be used to combine them into a single key. The details are out of scope for this document, but note that this may complicate the signing procedure. -* If one or more of the spending conditions consist of just a single key (after aggregation), the most likely one should be made the internal key. If no such condition exists, it may be worthwhile adding one that consists of an aggregation of all keys participating in all scripts combined; effectively adding an "everyone agrees" branch. If that is inacceptable, pick as internal key a point with unknown discrete logarithm. One example of such a point is ''H = lift_x(0x0250929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)'' which is [https://github.com/ElementsProject/secp256k1-zkp/blob/11af7015de624b010424273be3d91f117f172c82/src/modules/rangeproof/main_impl.h#L16 constructed] by taking the hash of the standard uncompressed encoding of the [https://www.secg.org/sec2-v2.pdf secp256k1] base point ''G'' as X coordinate. In order to avoid leaking the information that key path spending is not possible it is recommended to pick a fresh integer ''r'' in the range ''0...n-1'' uniformly at random and use ''H + rG'' as internal key. It is possible to prove that this internal key does not have a known discrete logarithm with respect to ''G'' by revealing ''r'' to a verifier who can then reconstruct how the internal key was created. +* If one or more of the spending conditions consist of just a single key (after aggregation), the most likely one should be made the internal key. If no such condition exists, it may be worthwhile adding one that consists of an aggregation of all keys participating in all scripts combined; effectively adding an "everyone agrees" branch. If that is inacceptable, pick as internal key a "Nothing Up My Sleeve" (NUMS) point, i.e., a point with unknown discrete logarithm. One example of such a point is ''H = lift_x(0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)'' which is [https://github.com/ElementsProject/secp256k1-zkp/blob/11af7015de624b010424273be3d91f117f172c82/src/modules/rangeproof/main_impl.h#L16 constructed] by taking the hash of the standard uncompressed encoding of the [https://www.secg.org/sec2-v2.pdf secp256k1] base point ''G'' as X coordinate. In order to avoid leaking the information that key path spending is not possible it is recommended to pick a fresh integer ''r'' in the range ''0...n-1'' uniformly at random and use ''H + rG'' as internal key. It is possible to prove that this internal key does not have a known discrete logarithm with respect to ''G'' by revealing ''r'' to a verifier who can then reconstruct how the internal key was created. * If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path. This can be achieved by computing the output key point as ''Q = P + int(hash<sub>TapTweak</sub>(bytes(P)))G''. <ref>'''Why should the output key always have a taproot commitment, even if there is no script path?''' If the taproot output key is an aggregate of keys, there is the possibility for a malicious party to add a script path without being noticed by the other parties. This allows to bypass the multiparty policy and to steal the coin. diff --git a/bip-0345.mediawiki b/bip-0345.mediawiki new file mode 100644 index 0000000..a6ead31 --- /dev/null +++ b/bip-0345.mediawiki @@ -0,0 +1,688 @@ +<pre> + BIP: 345 + Layer: Consensus (soft fork) + Title: OP_VAULT + Author: James O'Beirne <vaults@au92.org> + Greg Sanders <gsanders87@gmail.com> + Anthony Towns <aj@erisian.com.au> + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0345 + Status: Draft + Type: Standards Track + Created: 2023-02-03 + License: BSD-3-Clause + Post-History: 2023-01-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html [bitcoin-dev] OP_VAULT announcment + 2023-03-01: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-March/021510.html [bitcoin-dev] BIP for OP_VAULT +</pre> + + +== Introduction == + +This BIP proposes two new tapscript opcodes that add consensus support for a specialized +covenant: <code>OP_VAULT</code> and <code>OP_VAULT_RECOVER</code>. These opcodes, in conjunction with +<code>OP_CHECKTEMPLATEVERIFY</code> +([https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki BIP-0119]), +allow users to enforce a delay period before designated coins may be spent to +an arbitrary destination, with the exception of a prespecified "recovery" path. +At any time prior to final withdrawal, the coins can be spent to the +recovery path. + +=== Copyright === + +This document is licensed under the 3-clause BSD license. + + +=== Motivation === + +The hazard of custodying Bitcoin is well-known. Users of Bitcoin must go to +significant effort to secure their private keys, and hope that once provisioned +their custody system does not yield to any number of evolving and +persistent threats. Users have little means to intervene once a compromise is +detected. This proposal introduces a mechanism that significantly +mitigates the worst-case outcome of key compromise: coin loss. + +Introducing a way to intervene during unexpected spends allows users to +incorporate highly secure key storage methods or unusual fallback strategies +that are only exercised in the worst case, and which may otherwise be +operationally prohibitive. The goal of this proposal is to make this strategy +usable for custodians of any size with minimal complication. + +==== Example uses ==== + +A common configuration for an individual custodying Bitcoin is "single +signature and passphrase" using a hardware wallet. A user with such a +configuration might be concerned about the risk associated with relying on a +single manufacturer for key management, as well as physical access to the +hardware. + +This individual can use <code>OP_VAULT</code> to make use of a highly secure +key as the unlikely recovery path, while using their existing signing procedure +as the withdrawal trigger key with a configured spend delay of e.g. 1 day. + +The recovery path key can be of a highly secure nature that might otherwise +make it impractical for daily use. For example, the key could be generated in +some analog fashion, or on an old computer that is then destroyed, with the +private key replicated only in paper form. Or the key could be a 2-of-3 +multisig using devices from different manufacturers. Perhaps the key is +geographically or socially distributed. + +Since it can be any Bitcoin script policy, the recovery key can include a +number of spending conditions, e.g. a time-delayed fallback to an "easier" +recovery method, in case the highly secure key winds up being ''too'' highly +secure. + +The user can run software on their mobile device that monitors the blockchain +for spends of the vault outpoints. If the vaulted coins move in an unexpected +way, the user can immediately sweep them to the recovery path, but spending the +coins on a daily basis works in the same way it did prior to vaulting (aside +from the spend delay). + +Institutional custodians of Bitcoin may use vaults in similar fashion. + +===== Provable timelocks ===== + +This proposal provides a mitigation to the +[https://web.archive.org/web/20230210123933/https://xkcd.com/538/ "$5 wrench attack."] By +setting the spend delay to, say, a week, and using as the recovery path a +script that enforces a longer relative timelock, the owner of the vault can +prove that he is unable to access its value immediately. To the author's +knowledge, this is the only way to configure this defense without rolling +timelocked coins for perpetuity or relying on a trusted third party. + +== Goals == + +[[File:bip-0345/vaults-Basic.png|frame|center]] + +Vaults in Bitcoin have been discussed formally since 2016 +([http://fc16.ifca.ai/bitcoin/papers/MES16.pdf MES16]) and informally since [https://web.archive.org/web/20160220215151/https://bitcointalk.org/index.php?topic=511881.0 2014]. The value of +having a configurable delay period with recovery capability in light of an +unexpected spend has been widely recognized. + +The only way to implement vaults given the existing consensus rules, aside from +[https://github.com/revault emulating vaults with large multisig +configurations], is to use presigned transactions created with a one-time-use +key. This approach was first demonstrated +[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html in 2020]. + +Unfortunately, this approach has a number of practical shortcomings: +* generating and securely deleting ephemeral keys, which are used to emulate the vault covenant, is required, +* amounts and withdrawal patterns must be precommitted to, +* there is a necessity to precommit to an address that the funds must pass through on their way to the final withdrawal target, which is likely only known at unvault time, +* the particular fee management technique or wallet must be decided upon vault creation, +* coin loss follows if a vault address is reused, +* the transaction data that represents the "bearer asset" of the vault must be stored for perpetuity, otherwise value is lost, and +* the vault creation ceremony must be performed each time a new balance is to be deposited. + +The deployment of a "precomputed" covenant mechanism like +[https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki OP_CHECKTEMPLATEVERIFY] or +[https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_ANYPREVOUT] +would both remove the necessity to use an ephemeral key, since the +covenant is enforced on-chain, and lessen the burden of sensitive data storage, +since the necessary transactions can be generated from a set of compact +parameters. This approach was demonstrated [https://github.com/jamesob/simple-ctv-vault in +2022]. + +However, the limitations of precomputation still apply: amounts, +destinations, and fee management are all fixed. Funds must flow through a fixed +intermediary to their final destination. Batch operations, which may be vital +for successful recovery during fee spikes or short spend delay, are not possible. + +[[File:bip-0345/withdrawal-comparison.drawio.png|frame|center]] + +Having a "general" covenant mechanism that can encode arbitrary transactional +state machines would allow us to solve these issues, but at the cost of complex +and large scripts that would probably be duplicated many times over in the +blockchain. The particular design and deployment timeline of such a general +framework is also uncertain. This approach was demonstrated +[https://blog.blockstream.com/en-covenants-in-elements-alpha/ in 2016]. + +This proposal intends to address the problems outlined above by +providing a delay period/recovery path use with minimal transactional and +operational overhead using a specialized covenant. + +The design goals of the proposal are: + +* '''efficient reuse of an existing vault configuration.'''<ref>'''Why does this support address reuse?''' The proposal doesn't rely on or encourage address reuse, but certain uses are unsafe if address reuse cannot be handled - for example, if a custodian gives its users a vault address to deposit to, it cannot enforce that those users make a single deposit for each address.</ref> A single vault configuration, whether the same literal <code>scriptPubKey</code> or not, should be able to “receive” multiple deposits. + +* '''batched operations''' for recovery and withdrawal to allow managing multiple vault coins efficiently. + +* '''unbounded partial withdrawals''', which allows users to withdraw partial vault balances without having to perform the setup ceremony for a new vault. + +* '''dynamic unvault targets''', which allow the proposed withdrawal target for a vault to be specified at withdrawal time rather than when the vault is first created. This would remove the need for a prespecified, intermediate wallet that only exists to route unvaulted funds to their desired destination. + +* '''dynamic fee management''' that, like dynamic targets, defers the specification of fee rates and source to unvault time rather than vault creation time. + +These goals are accompanied by basic safety considerations (e.g. not being +vulnerable to mempool pinning) and a desire for concision, both in terms of the number +of outputs created as well as script sizes. + +This proposal is designed to be compatible with any future sighash modes (e.g. <code>SIGHASH_GROUP</code>) or fee management strategies (e.g. [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html transaction sponsors]) that may be introduced. Use of these opcodes will benefit from, but do not strictly rely on, [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html v3 transaction relay] and [https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki ephemeral anchors]. + +== Design == + +In typical usage, a vault is created by encumbering coins under a +taptree [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki (BIP-341)] +containing at least two leaves: one with an <code>OP_VAULT</code>-containing script that +facilitates the expected withdrawal process, and another leaf with +<code>OP_VAULT_RECOVER</code> which ensures the coins can be recovered +at any time prior to withdrawal finalization. + +The rules of <code>OP_VAULT</code> ensure the timelocked, interruptible +withdrawal by allowing a spending transaction to replace the +<code>OP_VAULT</code> tapleaf with a prespecified script template, allowing for +some parameters to be set at spend (trigger) time. All other leaves in the +taptree must be unchanged in the destination output, which preserves the recovery path as well as any +other spending conditions originally included in the vault. This is similar to +the <code>TAPLEAF_UPDATE_VERIFY</code> design that was proposed +[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html in 2021]. + +These tapleaf replacement rules, described more precisely below, ensure a +timelocked withdrawal, where the timelock is fixed by the original +<code>OP_VAULT</code> parameters, to a fixed set of outputs (via +<code>OP_CHECKTEMPLATEVERIFY</code><ref>'''Why is <code>OP_CHECKTEMPLATEVERIFY</code> (BIP-119) relied upon for this proposal?''' During the withdrawal process, the proposed final destination for value being withdrawn must be committed to. <code>OP_CTV</code> is the simplest, safest way to commit the spend of some coins to a particular set of outputs. An earlier version of this proposal attempted to use a simpler, but similar method, of locking the spend of coins to a set of outputs, but this method introduced txid malleability.<br />Note that if some other method of locking spends to a particular set of outputs should be deployed, that method can be used in the <code>OP_VAULT</code> <code><leaf-update-script-body></code> with no changes.</ref>) which is chosen when the withdrawal +process is triggered. + +While <code>OP_CHECKTEMPLATEVERIFY</code> is used in this proposal as the +preferred method to bind the proposed withdrawal to a particular set of final +outputs, <code>OP_VAULT</code> is composable with other (and future) opcodes to +facilitate other kinds of withdrawal processes. + +[[File:bip-0345/opvault.drawio.png|frame|center]] + + +=== Transaction types === + +The vault has a number of stages, some of them optional: + +* '''vault transaction''': encumbers some coins into a Taproot structure that includes at least one <code>OP_VAULT</code> leaf and one <code>OP_VAULT_RECOVER</code> leaf. + +* '''trigger transaction''': spends one or more <code>OP_VAULT</code>-tapleaf inputs into an output which is encumbered by a timelocked withdrawal to a fixed set of outputs, chosen at trigger time. This publicly broadcasts the intent to withdraw to some specific set of outputs.<br /><br />The trigger transaction may have an additional output which allocates some of the vault balance into a partial "revault," which simply encumbers the revaulted portion of the value into the same <code>scriptPubKey</code> as the <code>OP_VAULT</code>-containing input(s) being spent. + +* '''withdrawal transaction''': spends the timelocked, destination-locked trigger inputs into a compatible set of final withdrawal outputs (per, e.g., a <code>CHECKTEMPLATEVERIFY</code> hash), after the trigger inputs have matured per the spend delay. Timelocked CTV transactions are the motivating usage of OP_VAULT, but any script template can be specified during the creation of the vault. + +* '''recovery transaction''': spends one or more vault inputs via <code>OP_VAULT_RECOVER</code> tapleaf to the prespecified recovery path, which can be done at any point before the withdrawal transaction confirms. Each input can optionally require a witness satisfying a specified ''recovery authorization'' script, an optional script prefixing the <code>OP_VAULT_RECOVER</code> fragment. The use of recovery authorization has certain trade-offs discussed later. + + +=== Fee management === + +A primary consideration of this proposal is how fee management is handled. +Providing dynamic fee management is critical to the operation of a vault, since + +* precalculated fees are prone to making transactions unconfirmable in high fee environments, and +* a fee wallet that is prespecified might be compromised or lost before use. + +But dynamic fee management can introduce +[https://bitcoinops.org/en/topics/transaction-pinning/ pinning vectors]. Care +has been taken to avoid unnecessarily introducing these vectors when using the new +destination-based spending policies that this proposal introduces. + +Originally, this proposal had a hard dependency on reformed transaction +nVersion=3 policies, including ephemeral anchors, but it has since been revised +to simply benefit from these changes in policy as well as other potential fee +management mechanisms. + + +== Specification == + +The tapscript opcodes <code>OP_SUCCESS187</code> (<code>0xbb</code>) and +<code>OP_SUCCESS188</code> (<code>0xbc</code>) are constrained with new rules +to implement <code>OP_VAULT</code> and <code>OP_VAULT_RECOVER</code>, +respectively. + +=== <code>OP_VAULT</code> evaluation === + +When evaluating <code>OP_VAULT</code> (<code>OP_SUCCESS187</code>, +<code>0xbb</code>), the expected format of the stack, shown top to bottom, is: + +<source> +<leaf-update-script-body> +<push-count> +[ <push-count> leaf-update script data items ... ] +<trigger-vout-idx> +<revault-vout-idx> +<revault-amount> +</source> + +where + +* <code><leaf-update-script-body></code> is a minimally-encoded data push of a serialized script. <ref>In conjunction with the leaf-update data items, it dictates the tapleaf script in the output taptree that will replace the one currently executing.</ref> +** Otherwise, script execution MUST fail and terminate immediately. + +* <code><push-count></code> is an up to 4-byte minimally encoded <code>CScriptNum</code> indicating how many leaf-update script items should be popped off the stack. <ref>'''Why only prefix with data pushes?''' Prefixing the <code>leaf-update-script-body</code> with opcodes opens up the door to prefix OP_SUCCESSX opcodes, to name a single issue only, side-stepping the validation that was meant to be run by the committed script.</ref> +** If this value does not decode to a valid CScriptNum, script execution MUST fail and terminate immediately. +** If this value is less than 0, script execution MUST fail and terminate immediately. +** If there are fewer than 3 items following the <code><push-count></code> items on the stack, script execution MUST fail and terminate immediately. In other words, after popping <code><leaf-update-script-body></code>, there must be at least <code>3 + <push-count></code> items remaining on the stack. + +* The following <code><push-count></code> stack items are popped off the stack and prefixed as minimally-encoded push-data arguments to the <code><leaf-update-script-body></code> to construct the expected tapleaf replacement script. + +* <code><trigger-vout-idx></code> is an up to 4-byte minimally encoded <code>CScriptNum</code> indicating the index of the output which, in conjunction with an optional revault output, carries forward the value of this input, and has an identical taptree aside from the currently executing leaf. +** If this value does not decode to a valid CScriptNum, script execution MUST fail and terminate immediately. +** If this value is less than 0 or is greater than or equal to the number of outputs, script execution MUST fail and terminate immediately. + +* <code><revault-vout-idx></code> is an up to 4-byte minimally encoded <code>CScriptNum</code> optionally indicating the index of an output which, in conjunction with the trigger output, carries forward the value of this input, and has an identical scriptPubKey to the current input. +** If this value does not decode to a valid CScriptNum, script execution MUST fail and terminate immediately. +** If this value is greater than or equal to the number of outputs, script execution MUST fail and terminate immediately. +** If this value is negative and not equal to -1, script execution MUST fail and terminate immediately.<ref>'''Why is -1 the only allowable negative value for revault-vout-idx?''' A negative revault index indicates that no revault output exists; if this value were allowed to be any negative number, the witness could be malleated (and bloated) while a transaction is waiting for confirmation.</ref> + +* <code><revault-amount></code> is an up to 7-byte minimally encoded CScriptNum indicating the number of satoshis being revaulted. +** If this value does not decode to a valid CScriptNum, script execution MUST fail and terminate immediately. +** If this value is not greater than or equal to 0, script execution MUST fail and terminate immediately. +** If this value is non-zero but <code><revault-vout-idx></code> is negative, script execution MUST fail and terminate immediately. +** If this value is zero but <code><revault-vout-idx></code> is not -1, script execution MUST fail and terminate immediately. + +After the stack is parsed, the following validation checks are performed: + +* Decrement the per-script sigops budget (see [https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#user-content-Resource_limits BIP-0342]) by 60<ref>'''Why is the sigops cost for OP_VAULT set to 60?''' To determine the validity of a trigger output, OP_VAULT must perform an EC multiplication and hashing proportional to the length of the control block in order to generate the output's expected TapTweak. This has been measured to have a cost in the worst case (max length control block) of roughly twice a Schnorr verification. Because the hashing cost could be mitigated by caching midstate, the cost is 60 and not 100.</ref>; if the budget is brought below zero, script execution MUST fail and terminate immediately. +* Let the output designated by <code><trigger-vout-idx></code> be called ''triggerOut''. +* If the scriptPubKey of ''triggerOut'' is not a version 1 witness program, script execution MUST fail and terminate immediately. +* Let the script constructed by taking the <code><leaf-update-script-body></code> and prefixing it with minimally-encoded data pushes of the <code><push-count></code> leaf-update script data items be called the ''leaf-update-script''. +* If the scriptPubKey of ''triggerOut'' does not match that of a taptree that is identical to that of the currently evaluated input, but with the leaf script substituted for ''leaf-update-script'', script execution MUST fail and terminate immediately. +** Note: the parity bit of the resulting taproot output is allowed to vary, so both values for the new output must be checked. +* Let the output designated by <code><revault-vout-idx></code> (if the index value is non-negative) be called ''revaultOut''. +* If the scriptPubKey of ''revaultOut'' is not equal to the scriptPubKey of the input being spent, script execution MUST fail and terminate immediately. +* Implementation recommendation: if the sum of the amounts of ''triggerOut'' and ''revaultOut'' (if any) are not greater than or equal to the value of this input, script execution SHOULD fail and terminate immediately. This ensures that (at a minimum) the vaulted value for this input is carried through. +** Amount checks are ultimately done with deferred checks, but this check can help short-circuit obviously invalid spends. +* Queue a deferred check<ref>'''What is a deferred check and why does this proposal require them for correct script evaluation?''' A deferred check is a validation check that is executed only after all input scripts have been validated, and is based on aggregate information collected during each input's EvalScript run.<br /><br />Currently, the validity of each input is (usually) checked concurrently across all inputs in a transaction. Because this proposal allows batching the spend of multiple vault inputs into a single recovery or withdrawal output, we need a mechanism to ensure that all expected values per output can be summed and then checked. This necessitates the introduction of an "aggregating" set of checks which can only be executed after each input's script is evaluated. Note that similar functionality would be required for batch input validation or cross-input signature aggregation.</ref> that ensures the satoshis for this input's <code>nValue</code> minus <code><revault-amount></code> are included within the output <code>nValue</code> found at <code><trigger-vout-idx></code>. +* Queue a deferred check that ensures <code><revault-amount></code> satoshis, if non-zero, are included within the output's <code>nValue</code> found at <code><revault-vout-idx></code>. +** These deferred checks could be characterized in terms of the pseudocode below (in ''Deferred checks'') as<br /><code>TriggerCheck(input_amount, <revault-amount>, <trigger-vout-idx>, <revault-vout-idx>)</code>. + +If none of the conditions fail, a single true value (<code>0x01</code>) is left on the stack. + +=== <code>OP_VAULT_RECOVER</code> evaluation === + +When evaluating <code>OP_VAULT_RECOVER</code> (<code>OP_SUCCESS188</code>, +<code>0xbb</code>), the expected format of the stack, shown top to bottom, is: + +<source> +<recovery-sPK-hash> +<recovery-vout-idx> +</source> + +where + +* <code><recovery-sPK-hash></code> is a 32-byte data push. +** If this is not 32 bytes in length, script execution MUST fail and terminate immediately. +* <code><recovery-vout-idx></code> is an up to 4-byte minimally encoded <code>CScriptNum</code> indicating the index of the recovery output. +** If this value does not decode to a valid CScriptNum, script execution MUST fail and terminate immediately. +** If this value is less than 0 or is greater than or equal to the number of outputs, script execution MUST fail and terminate immediately. + +After the stack is parsed, the following validation checks are performed: + +* Let the output at index <code><recovery-vout-idx></code> be called ''recoveryOut''. +* If the scriptPubKey of ''recoveryOut'' does not have a tagged hash equal to <code><recovery-sPK-hash></code> (<code>tagged_hash("VaultRecoverySPK", recoveryOut.scriptPubKey) == recovery-sPK-hash</code>, where <code>tagged_hash()</code> is from the [https://github.com/bitcoin/bips/blob/master/bip-0340/reference.py BIP-0340 reference code]), script execution MUST fail and terminate immediately. +** Implementation recommendation: if ''recoveryOut'' does not have an <code>nValue</code> greater than or equal to this input's amount, the script SHOULD fail and terminate immediately. +* Queue a deferred check that ensures the <code>nValue</code> of ''recoveryOut'' contains the entire <code>nValue</code> of this input.<ref>'''How do recovery transactions pay for fees?''' If the recovery is unauthorized, fees are attached either via CPFP with an ephemeral anchor or as inputs which are solely spent to fees (i.e. no change output). If the recovery is authorized, fees can be attached in any manner, e.g. unrelated inputs and outputs or CPFP via anchor.</ref> +** This deferred check could be characterized in terms of the pseudocode below as <code>RecoveryCheck(<recovery-vout-idx>, input_amount)</code>. + +If none of the conditions fail, a single true value (<code>0x01</code>) is left on the stack. + +=== Deferred check evaluation === + +Once all inputs for a transaction are validated per the rules above, any +deferred checks queued MUST be evaluated. + +The Python pseudocode for this is as follows: + +<source lang="python"> +class TriggerCheck: + """Queued by evaluation of OP_VAULT (withdrawal trigger).""" + input_amount: int + revault_amount: int + trigger_vout_idx: int + revault_vout_idx: int + + +class RecoveryCheck: + """Queued by evaluation of OP_VAULT_RECOVER.""" + input_amount: int + vout_idx: int + + +def validate_deferred_checks(checks: [DeferredCheck], tx: Transaction) -> bool: + """ + Ensure that all value from vault inputs being triggered or recovered is preserved + in suitable output nValues. + """ + # Map to hold expected output values. + out_map: Dict[int, int] = defaultdict(lambda: 0) + + for c in checks: + if isinstance(c, TriggerCheck): + out_map[c.trigger_vout_idx] += (c.input_amount - c.revault_amount) + + if c.revault_amount > 0: + out_map[c.revault_vout_idx] += c.revault_amount + + elif isinstance(c, RecoveryCheck): + out_map[c.vout_idx] += c.input_amount + + for (vout_idx, amount_sats) in out_map.items(): + # Trigger/recovery value can be greater than the constituent vault input + # amounts. + if tx.vout[vout_idx].nValue < amount_sats: + return False + + return True +</source> + +If the above procedure, or an equivalent, returns false, script execution MUST fail and terminate +immediately. + +This ensures that all compatible vault inputs can be batched into shared +corresponding trigger or recovery outputs while preserving their entire input value. + + +== Policy changes == + +In order to prevent possible pinning attacks, recovery transactions must be replaceable. + +* When validating an <code>OP_VAULT_RECOVER</code> input being spent, the script MUST fail (by policy, not consensus) and terminate immediately if both<ref>'''Why are recovery transactions required to be replaceable?''' In the case of unauthorized recoveries, an attacker may attempt to pin recovery transactions by broadcasting a "rebundled" version with a low fee rate. Vault owners must be able to overcome this with replacement. In the case of authorized recovery, if an attacker steals the recovery authorization key, the attacker may try to pin the recovery transaction during theft. Requiring replaceability ensures that the owner can always raise the fee rate of the recovery transaction, even if they are RBF rule #3 griefed in the process.</ref> +*# the input is not marked as opt-in replaceable by having an nSequence number less than <code>0xffffffff - 1</code>, per [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP-0125], and +*# the version of the recovery transaction has an nVersion other than 3. + +If the script containing <code>OP_VAULT_RECOVER</code> is 34 bytes or less<ref>34 bytes is the length of a recovery script that consists solely of <code><recovery-sPK-hash> OP_VAULT_RECOVER</code>.</ref>, let +it be called "unauthorized," because there is no script guarding the recovery +process. In order to prevent pinning attacks in the case of unauthorized +recovery - since the spend of the input (and the structure of the +transaction) is not authorized by a signed signature message - the output structure of +unauthorized recovery transaction is limited. + +* If the recovery is unauthorized, the recovery transaction MUST (by policy) abide by the following constraints: +** If the spending transaction has more than two outputs, the script MUST fail and terminate immediately. +** If the spending transaction has two outputs, and the output which is not ''recoveryOut'' is not an [https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki ephemeral anchor], the script MUST fail and terminate immediately.<ref>'''Why can unauthorized recoveries only process a single recovery path?''' Because there is no signature required for unauthorized recoveries, if additional outputs were allowed, someone observing a recovery in the mempool would be able to rebundle and broadcast the recovery with a lower fee rate.</ref> + +== Implementation == + +A sample implementation is available on bitcoin-inquisition [https://github.com/jamesob/bitcoin/tree/2023-01-opvault-inq here], with an associated [https://github.com/bitcoin-inquisition/bitcoin/pull/21 pull request]. + + +== Applications == + +The specification above, perhaps surprisingly, does not specifically cover how a relative timelocked withdrawal process with a fixed target is implemented. The tapleaf update semantics specified in <code>OP_VAULT</code> as well as the output-based authorization enabled by <code>OP_VAULT_RECOVER</code> can be used to implement a vault, but they are incomplete without two other pieces: + +* a way to enforce relative timelocks, like <code>OP_CHECKSEQUENCEVERIFY</code>, and +* a way to enforce that proposed withdrawals are ultimately being spent to a precise set of outputs, like <code>OP_CHECKTEMPLATEVERIFY</code>. + +These two pieces are combined with the tapleaf update capabilities of +<code>OP_VAULT</code> to create a vault, described below. + +=== Creating a vault === + +In order to vault coins, they can be spent into a witness v1 <code>scriptPubKey</code> +that contains a taptree of the form + +<source> +tr(<internal-pubkey>, + leaves = { + recover: + <recovery-sPK-hash> OP_VAULT_RECOVER, + + trigger: + <trigger-auth-pubkey> OP_CHECKSIGVERIFY (i) + <spend-delay> 2 $leaf-update-script-body OP_VAULT, (ii) + + ... [ possibly other leaves ] + } +) +</source> +where +* <code>$leaf-update-script-body</code> is, for example, <code>OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY</code>. +** This is one example of a trigger script, but ''any'' script fragment can be used, allowing the creation of different types of vaults. For example, you could use <code>OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG</code> to do a time-delayed transfer of the coins to another key. This also future-proofs <code>OP_VAULT</code> for future scripting capabilities. +* The script fragment in <code>(i)</code> is called the "trigger authorization," because it gates triggering the withdrawal. This can be done in whatever manner the wallet designer would like. +* The script fragment in <code>(ii)</code> is the incomplete <code>OP_VAULT</code> invocation - it will be completed once the rest of the parameters (the CTV target hash, trigger vout index, and revault vout index) are provided by the trigger transaction witness. + +Typically, the internal key for the vault taproot output will be specified so +that it is controlled by the same descriptor as the recovery path, which +facilitates another (though probably unused) means of recovering the vault +output to the recovery path. This has the potential advantage of recovering the +coin without ever revealing it was a vault. + +Otherwise, the internal key can be chosen to be an unspendable NUMS point to +force execution of the taptree contents. + +=== Triggering a withdrawal === + +To make use of the vault, and spend it towards some output, we construct a spend +of the above <code>tr()</code> output that simply replaces the "trigger" leaf with the +full leaf-update script (in this case, a timelocked CTV script): + +<source> +Witness stack: + +- <revault-amount> +- <revault-vout-idx> (-1 if none) +- <trigger-vout-idx> +- <target-CTV-hash> +- <trigger-auth-pubkey-signature> +- [ "trigger" leaf script contents ] +- [ taproot control block prompting a script-path spend to "trigger" leaf ] + +Output scripts: + +[ + tr(<internal-pubkey>, + leaves = { + recover: + <recovery-sPK-hash> OP_VAULT_RECOVER, <-- unchanged + + trigger: + <target-CTV-hash> <spend-delay> + OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY <-- changed per the + leaf-update + rules of OP_VAULT + ... [ possibly other leaves ] + } + ), + + [ optional revault output with the + same sPK as the original vault output ], +] +</source> + +<code>OP_VAULT</code> has allowed the taptree to be transformed so that the trigger leaf +becomes a timelocked CTV script, which is what actually facilitates the announced +withdrawal. The withdrawal is interruptible by the recovery path because the +"recover" leaf is preserved exactly from the original taptree. + +Note that the CTV hash is specified at spend time using the witness stack, and +"locked in" via the <code>OP_VAULT</code> spend rules which assert its existence in the output. + +The vault funds can be recovered at any time prior to the spend of the +timelocked CTV script by way of a script-path spend using the "recover" leaf. + + +=== Recovery authorization === + +When configuring a vault, the user must decide if they want to have the +recovery process gated by a script fragment prefixing the +<code>OP_VAULT_RECOVER</code> instruction in the "recover" leaf. Its use +entails trade-offs. + +==== Unauthorized recovery ==== + +Unauthorized recovery simplifies vault use in that recovery never requires additional information aside from the location of the vault outpoints and the recovery path - the "authorization" is simply the reveal of the recovery path, i.e. the preimage of <code><recovery-sPK-hash></code>. + +But because this reveal is the only authorization necessary to spend the vault coins to recovery, the user must expect to recover all such vaults at once, since an observer can replay this recovery (provided they know the outpoints). + +Additionally, unauthorized recovery across multiple distinct recovery paths +cannot be done in the same transaction, and fee control is more constrained: +because the output structure is limited for unauthorized recovery, fee +management relies either on inputs which are completely spent to fees or the +use of the optional ephemeral anchor and package relay. + +These limitations are to avoid pinning attacks. + +==== Authorized recovery ==== + +With authorized recovery, the user must keep track of an additional piece of information: how to solve the recovery authorization script fragment when recovery is required. + +If this key is lost, the user will be unable to initiate the recovery process for their coins. If an attacker obtains the recovery key, they may grief the user during the recovery process by constructing a low fee rate recovery transaction and broadcasting it (though they will not be able to pin because of the replaceability requirement on recovery transactions). + +However, authorized recovery configurations have significant benefits. Batched recoveries are possible for vaults with otherwise incompatible recovery parameters. Fee management is much more flexible, since authorized recovery transactions are "free form" and unrelated inputs and outputs can be added, potentially to handle fees. + +==== Recommendation: use a simple, offline recovery authorization key seed ==== + +The benefits of batching and fee management that authorized recovery provides are significant. If the recovery authorization key falls into the hands of an attacker, the outcome is not catastrophic, whereas if the user loses their recovery authorization key as well as their trigger key, the result is likely coin loss. Consequently, the author's recommendation is to use a simple seed for the recovery authorization key that can be written down offline and replicated. + +Note that the recovery authorization key '''is not''' the recovery path key, and +this is '''much different''' than any recommendation on how to generate the +recovery path key itself. + +=== Address reuse and recovery === + +When creating a vault, four factors affect the resulting P2TR address: +# The internal pubkey (likely belonging to the recovery wallet) +# The recovery leaf +# The trigger leaf +# Any other leaves that exist in the taptree + +The end user has the option of varying certain contents along descriptors in +order to avoid reusing vault addresses without affecting key management, e.g. +the trigger authorization pubkeys. + +Note that when using unauthorized recovery, the reveal of the +recovery scriptPubKey will allow any observer to initiate the recovery process +for any vault with matching recovery params, provided they are able to locate +the vault outpoints. As a result, it is recommended to expect that +'''all outputs sharing an identical unauthorized <code><recovery-sPK-hash></code> should be recovered together'''. + +This situation can be avoided with a comparable key management model by varying +the generation of each vault's recovery scriptPubKey along a single descriptor, +but note that this will prevent recovering multiple separate vaults into a single +recovery output. + +Varying the internal pubkey will prevent batching the trigger of multiple vault +inputs into a single trigger output; consequently it is recommended that users +instead vary some component of the trigger leaf script if address reuse is +undesirable. Users could vary the trigger pubkey along a descriptor, keeping +the recovery path and internal-pubkey the same, which both avoids reusing +addresses and allows batched trigger and recovery operations. + +==== Recommendation: generate new recovery addresses for new trigger keys ==== + +If using unauthorized recovery, it is recommended that you do not share recovery scriptPubKeys +across separate trigger keys. If one trigger key is compromised, that will necessitate the (unauthorized) +recovery of all vaults with that trigger key, which will reveal the recovery path preimage. This +means that an observer might be able to initiate recovery for vaults controlled by an uncompromised +trigger key. + +==== Fee management ==== + +Fees can be managed in a variety of ways, but it's worth noting that both +trigger and recovery transactions must preserve the total value of vault +inputs, so vaulted values cannot be repurposed to pay for fees. This does not +apply to the withdrawal transaction, which can allocate value arbitrarily. + +In the case of vaults that use recovery authorization, all transactions can +"bring their own fees" in the form of unrelated inputs and outputs. These +transactions are also free to specify ephemeral anchors, once the related relay +policies are deployed. This means that vaults using recovery authorization have +no dependence on the deploy of v3 relay policy. + +For vaults using unauthorized recovery, the recovery +transaction relies on the use of either fully-spent fee inputs or an ephemeral +anchor output. This means that vaults which do not use recovery authorization +are essentially dependent on v3 transaction relay policy being deployed. + +=== Batching === + +==== During trigger ==== + +<code>OP_VAULT</code> outputs with the same taptree, aside from slightly +different trigger leaves, can be batched together in the same withdrawal +process. Two "trigger" leaves are compatible if they have the same +<code>OP_VAULT</code> arguments. + +Note that this allows the trigger authorization -- the script prefixing the +<code>OP_VAULT</code> invocation -- to differ while still allowing batching. + +Trigger transactions can act on multiple incompatible <code>OP_VAULT</code> +input sets, provided each set has a suitable associated ''triggerOut'' +output. + +Since <code>SIGHASH_DEFAULT</code> can be used to sign the trigger +authorization, unrelated inputs and outputs can be included, possibly to +facilitate fee management or the batch withdrawal of incompatible vaults. + +==== During withdrawal ==== + +During final withdrawal, multiple trigger outputs can be used towards the same +withdrawal transaction provided that they share identical +<code><target-CTV-hash></code> parameters. This facilitates batched +withdrawals. + +==== During recovery ==== + +<code>OP_VAULT_RECOVER</code> outputs with the same <code><recovery-sPK-hash></code> +can be recovered into the same output. + +Recovery-incompatible vaults which have authorized recovery can be recovered in +the same transaction, so long as each set (grouped by +<code><recovery-sPK-hash></code>) has an associated ''recoveryOut''. This allows +unrelated recoveries to share common fee management. + +=== Watchtowers === + +The value of vaults is contingent upon having monitoring in place that will +alert the owner when unexpected spends are taking place. This can be done in a +variety of ways, with varying degrees of automation and trust in the +watchtower. + +In the maximum-trust case, the watchtower can be fully aware of all vaulted +coins and has the means to initiate the recovery process if spends are not +pre-reported to the watchtower. + +In the minimum-trust case, the user can supply a probabilistic filter of which +coins they wish to monitor; the watchtower would then alert the user if any +coins matching the filter move, and the user would be responsible for ignoring +false positives and handling recovery initiation. + +=== Output descriptors === + +Output descriptors for vault-related outputs will be covered in a subsequent BIP. + +== Deployment == + +Activation mechanism is to be determined. + +This BIP should be deployed concurrently with BIP-0119 to enable full use of vaults. + +== Backwards compatibility == + +<code>OP_VAULT</code> and <code>OP_VAULT_RECOVER</code> replace, respectively, +the witness v1-only opcodes OP_SUCCESS187 and OP_SUCCESS188 with stricter +verification semantics. Consequently, scripts using those opcodes which +previously were valid will cease to be valid with this change. + +Stricter verification semantics for an OP_SUCCESSx opcode are a soft fork, so +existing software will be fully functional without upgrade except for mining +and block validation. + +Backwards compatibility considerations are very comparable to previous +deployments for OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY (see +[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP-0065] and +[https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP-0112]). + + +== Rationale == + +<references /> + +== References == + +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012470.html [bitcoin-dev] Bitcoin Vaults (2016)] +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html [bitcoin-dev] Simple lock/unlock mechanism (2018)] +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html [bitcoin-dev] On-chain vaults prototype (2020)] +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode (2021)] +* [https://arxiv.org/abs/2005.11776 Custody Protocols Using Bitcoin Vaults (2020)] +* [https://jameso.be/vaults.pdf Vaults and Covenants (2023)] + +== Acknowledgements == + +The author would like to thank + +* AJ Towns and Greg Sanders for discussion, numerous suggestions that improved the proposal, and advice. +* Jeremy Rubin for inspiration, advice, and mentorship. +* BL for discussion and insight. +* John Moffett for early feedback and a test case demonstrating a recursive script evaluation attack. +* Johan Halseth for providing conceptual review and pointing out a pinning attack. +* Pieter Wuille for implementation advice. diff --git a/bip-0345/opvault.drawio.png b/bip-0345/opvault.drawio.png Binary files differnew file mode 100644 index 0000000..702189d --- /dev/null +++ b/bip-0345/opvault.drawio.png diff --git a/bip-0345/vaults-Basic.png b/bip-0345/vaults-Basic.png Binary files differnew file mode 100644 index 0000000..591b633 --- /dev/null +++ b/bip-0345/vaults-Basic.png diff --git a/bip-0345/vaults.drawio b/bip-0345/vaults.drawio new file mode 100644 index 0000000..6f7fd4e --- /dev/null +++ b/bip-0345/vaults.drawio @@ -0,0 +1,1113 @@ +<mxfile host="app.diagrams.net" modified="2023-03-23T20:50:16.927Z" agent="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36" etag="MVPrlQq-FqlMbts0SwvB" version="21.1.0" type="device" pages="8"> + <diagram id="qHG0FeF2aWp-aiau7VVg" name="Basic flow"> + <mxGraphModel dx="2162" dy="1316" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0"> + <root> + <mxCell id="0" /> + <mxCell id="1" parent="0" /> + <mxCell id="b8DSxFJpJzC5LI19bmsF-5" value="" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="b8DSxFJpJzC5LI19bmsF-1" target="b8DSxFJpJzC5LI19bmsF-3" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-8" value="<div>Sign with trigger key</div>" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" parent="b8DSxFJpJzC5LI19bmsF-5" vertex="1" connectable="0"> + <mxGeometry x="-0.3102" y="-1" relative="1" as="geometry"> + <mxPoint x="1" y="6" as="offset" /> + </mxGeometry> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-6" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;strokeColor=default;dashed=1;" parent="1" source="b8DSxFJpJzC5LI19bmsF-1" target="b8DSxFJpJzC5LI19bmsF-2" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-7" value="Reveal recovery <br>scriptPubKey<br>and (if applicable)<br>satisfy recovery <br>auth. script" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" parent="b8DSxFJpJzC5LI19bmsF-6" vertex="1" connectable="0"> + <mxGeometry x="-0.17" y="2" relative="1" as="geometry"> + <mxPoint x="52" y="57" as="offset" /> + </mxGeometry> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-1" value="<div><span style="background-color: initial;"><b>Vault transaction</b></span></div><div><span style="background-color: initial;"><br></span></div><div><i style="background-color: initial;">&lt;recovery-params&gt;</i><br></div><div>&lt;<i>spend-delay</i>&gt;</div><div>&lt;<i>trigger-sPK-hash</i>&gt;<br></div><div><b style="border-color: var(--border-color);">OP_VAULT</b><br></div>" style="rounded=1;whiteSpace=wrap;html=1;labelPosition=center;verticalLabelPosition=middle;align=center;verticalAlign=middle;" parent="1" vertex="1"> + <mxGeometry x="190" y="250" width="140" height="100" as="geometry" /> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-2" value="<b>Recovery transaction<br></b><br>[outputs controlled <br>by recovery keys]" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="443" y="420" width="130" height="70" as="geometry" /> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-9" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;dashed=1;strokeColor=default;endArrow=none;endFill=0;rounded=1;" parent="1" source="b8DSxFJpJzC5LI19bmsF-3" edge="1"> + <mxGeometry relative="1" as="geometry"> + <mxPoint x="400" y="300" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="iAfIXZV-x1gRYHwice2W-8" value="Recover from trigger,<br style="font-size: 11px;">before withdrawal<br style="font-size: 11px;">confirms" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=11;" parent="b8DSxFJpJzC5LI19bmsF-9" vertex="1" connectable="0"> + <mxGeometry x="0.4001" y="-1" relative="1" as="geometry"> + <mxPoint x="-13" y="19" as="offset" /> + </mxGeometry> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-11" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=default;" parent="1" source="b8DSxFJpJzC5LI19bmsF-3" target="b8DSxFJpJzC5LI19bmsF-10" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-12" value="<div>Wait <i>spend-delay</i> blocks <b>&amp;&amp;</b><br></div><div>outputs match target hash<br></div>" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" parent="b8DSxFJpJzC5LI19bmsF-11" vertex="1" connectable="0"> + <mxGeometry x="-0.302" y="2" relative="1" as="geometry"> + <mxPoint x="1" y="4" as="offset" /> + </mxGeometry> + </mxCell> + <mxCell id="oT6HpDHtKCBb9ui_6_kA-1" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.001;exitY=0.406;exitDx=0;exitDy=0;entryX=0.001;entryY=0.595;entryDx=0;entryDy=0;dashed=1;endArrow=classic;endFill=1;entryPerimeter=0;exitPerimeter=0;" parent="1" source="b8DSxFJpJzC5LI19bmsF-3" target="b8DSxFJpJzC5LI19bmsF-1" edge="1"> + <mxGeometry relative="1" as="geometry"> + <Array as="points"> + <mxPoint x="90" y="441" /> + <mxPoint x="90" y="310" /> + </Array> + </mxGeometry> + </mxCell> + <mxCell id="oT6HpDHtKCBb9ui_6_kA-2" value="Optional <br>partial-balance<br>revault" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" parent="oT6HpDHtKCBb9ui_6_kA-1" vertex="1" connectable="0"> + <mxGeometry x="0.1091" y="1" relative="1" as="geometry"> + <mxPoint y="13" as="offset" /> + </mxGeometry> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-3" value="<div><b><span style="background-color: initial;">Trigger transaction</span><br></b></div><div><i style="background-color: initial;"><br></i></div><div><i style="background-color: initial;">&lt;recovery-params&gt;</i><br></div><div>&lt;<i>spend-delay</i>&gt;</div><div>&lt;<i>target-outputs-hash</i>&gt;<br></div><div><b style="border-color: var(--border-color);">OP_UNVAULT</b><br></div>" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="190" y="400" width="140" height="100" as="geometry" /> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-10" value="<b>Withdrawal transaction<br></b><br>[dynamically chosen target outputs]" style="rounded=1;whiteSpace=wrap;html=1;align=center;" parent="1" vertex="1"> + <mxGeometry x="190" y="567" width="140" height="73" as="geometry" /> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-14" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;exitPerimeter=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;strokeColor=default;" parent="1" source="b8DSxFJpJzC5LI19bmsF-13" target="b8DSxFJpJzC5LI19bmsF-1" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="b8DSxFJpJzC5LI19bmsF-13" value="" style="points=[[0.145,0.145,0],[0.5,0,0],[0.855,0.145,0],[1,0.5,0],[0.855,0.855,0],[0.5,1,0],[0.145,0.855,0],[0,0.5,0]];shape=mxgraph.bpmn.event;html=1;verticalLabelPosition=bottom;labelBackgroundColor=#ffffff;verticalAlign=top;align=center;perimeter=ellipsePerimeter;outlineConnect=0;aspect=fixed;outline=standard;symbol=general;rounded=1;" parent="1" vertex="1"> + <mxGeometry x="245" y="200" width="30" height="30" as="geometry" /> + </mxCell> + <mxCell id="BqwL7Yf8YW1r5e_O7xE0-1" value="" style="shadow=0;dashed=0;html=1;strokeColor=none;fillColor=#4495D1;labelPosition=center;verticalLabelPosition=bottom;verticalAlign=top;align=center;outlineConnect=0;shape=mxgraph.veeam.time;" parent="1" vertex="1"> + <mxGeometry x="158" y="512" width="30" height="30" as="geometry" /> + </mxCell> + <mxCell id="BqwL7Yf8YW1r5e_O7xE0-2" value="" style="sketch=0;pointerEvents=1;shadow=0;dashed=0;html=1;strokeColor=none;fillColor=#505050;labelPosition=center;verticalLabelPosition=bottom;verticalAlign=top;outlineConnect=0;align=center;shape=mxgraph.office.security.key_permissions;" parent="1" vertex="1"> + <mxGeometry x="183" y="358" width="15" height="33" as="geometry" /> + </mxCell> + <mxCell id="oT6HpDHtKCBb9ui_6_kA-7" value="" style="endArrow=none;html=1;rounded=1;entryX=1;entryY=0.25;entryDx=0;entryDy=0;exitX=0;exitY=0.25;exitDx=0;exitDy=0;" parent="1" source="b8DSxFJpJzC5LI19bmsF-1" target="b8DSxFJpJzC5LI19bmsF-1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="190" y="280" as="sourcePoint" /> + <mxPoint x="240" y="230" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="oT6HpDHtKCBb9ui_6_kA-8" value="" style="endArrow=none;html=1;rounded=1;entryX=1;entryY=0.25;entryDx=0;entryDy=0;exitX=0;exitY=0.25;exitDx=0;exitDy=0;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="190" y="427" as="sourcePoint" /> + <mxPoint x="330" y="427" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="oT6HpDHtKCBb9ui_6_kA-9" value="" style="endArrow=none;html=1;rounded=1;entryX=1;entryY=0.25;entryDx=0;entryDy=0;exitX=0;exitY=0.25;exitDx=0;exitDy=0;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="190" y="596" as="sourcePoint" /> + <mxPoint x="330" y="596" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="oT6HpDHtKCBb9ui_6_kA-10" value="" style="endArrow=none;html=1;rounded=1;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="443" y="446" as="sourcePoint" /> + <mxPoint x="573" y="446" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="LweIh1WkpCqs_c0vHIex-1" value="" style="endArrow=none;html=1;rounded=1;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="393" y="236" as="sourcePoint" /> + <mxPoint x="413" y="236" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="LweIh1WkpCqs_c0vHIex-2" value="Withdrawal path" style="text;strokeColor=none;align=left;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="415" y="221" width="90" height="30" as="geometry" /> + </mxCell> + <mxCell id="LweIh1WkpCqs_c0vHIex-3" value="" style="endArrow=none;html=1;rounded=1;dashed=1;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="393" y="252" as="sourcePoint" /> + <mxPoint x="413" y="252" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="LweIh1WkpCqs_c0vHIex-4" value="Optional path" style="text;strokeColor=none;align=left;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="416" y="237" width="90" height="30" as="geometry" /> + </mxCell> + <mxCell id="iAfIXZV-x1gRYHwice2W-2" value="" style="endArrow=classic;html=1;rounded=0;strokeColor=default;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="359" y="449.76" as="sourcePoint" /> + <mxPoint x="369" y="449.76" as="targetPoint" /> + <Array as="points"> + <mxPoint x="359" y="449.76" /> + </Array> + </mxGeometry> + </mxCell> + <mxCell id="iAfIXZV-x1gRYHwice2W-4" value="" style="endArrow=classic;html=1;rounded=0;strokeColor=default;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="399" y="299.76" as="sourcePoint" /> + <mxPoint x="409" y="299.76" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="iAfIXZV-x1gRYHwice2W-5" value="" style="endArrow=classic;html=1;rounded=0;strokeColor=default;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="150" y="440" as="sourcePoint" /> + <mxPoint x="140" y="440" as="targetPoint" /> + </mxGeometry> + </mxCell> + </root> + </mxGraphModel> + </diagram> + <diagram id="hQFg2SRqlWPJF2oUK6n1" name="Batch sweep"> + <mxGraphModel dx="1430" dy="1768" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0"> + <root> + <mxCell id="0" /> + <mxCell id="1" parent="0" /> + <mxCell id="DGUraX8pYsX29eg1CZX8-1" value="" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="636" y="415" width="138" height="160" as="geometry" /> + </mxCell> + <mxCell id="DGUraX8pYsX29eg1CZX8-2" value="" style="endArrow=none;html=1;rounded=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" parent="1" source="DGUraX8pYsX29eg1CZX8-1" target="DGUraX8pYsX29eg1CZX8-1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="660" y="519.5" as="sourcePoint" /> + <mxPoint x="710" y="469.5" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="DGUraX8pYsX29eg1CZX8-3" value="<b style="background-color: initial;"><br></b>" style="rounded=1;whiteSpace=wrap;html=1;align=left;" parent="1" vertex="1"> + <mxGeometry x="722" y="440" width="100" height="80" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-11" value="" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="380" y="300" width="138" height="122" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-12" value="" style="endArrow=none;html=1;rounded=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" parent="1" source="IMLKYxiTQTyD-2dyPs5i-11" target="IMLKYxiTQTyD-2dyPs5i-11" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="398" y="352" as="sourcePoint" /> + <mxPoint x="448" y="302" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-13" value="<b style="background-color: initial;"><br></b>" style="rounded=1;whiteSpace=wrap;html=1;align=left;" parent="1" vertex="1"> + <mxGeometry x="460" y="313" width="100" height="83" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-16" value="" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="400" y="499" width="115" height="138" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-17" value="" style="endArrow=none;html=1;rounded=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="435" y="637" as="sourcePoint" /> + <mxPoint x="435" y="499" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-18" value="<b style="background-color: initial;"><br></b>" style="rounded=1;whiteSpace=wrap;html=1;align=left;" parent="1" vertex="1"> + <mxGeometry x="457" y="516" width="100" height="101" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-27" value="" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="165" y="420" width="138" height="140" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-28" value="" style="endArrow=none;html=1;rounded=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="201" y="560" as="sourcePoint" /> + <mxPoint x="201" y="420" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-29" value="<b style="background-color: initial;"><br></b>" style="rounded=1;whiteSpace=wrap;html=1;align=left;" parent="1" vertex="1"> + <mxGeometry x="230" y="437" width="100" height="101" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-30" value="<p style="line-height: 40%;"><b>scriptPubKey</b></p><p style="border-color: var(--border-color); line-height: 4.8px;"><i style="border-color: var(--border-color);"><b style="border-color: var(--border-color);"><font style="border-color: var(--border-color);" color="#0066cc">recov-hash&nbsp;</font><font style="border-color: var(--border-color);" color="#00060d">...</font></b>&nbsp;</i></p><p style="border-color: var(--border-color); line-height: 4.8px;">&nbsp; OP_VAULT</p><p style="line-height: 40%;"><b style="background-color: initial;">amount</b></p><p style="line-height: 40%;"><span style="background-color: initial;">a3</span></p>" style="text;html=1;resizable=0;autosize=1;align=left;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;dashed=1;" parent="1" vertex="1"> + <mxGeometry x="461" y="513.5" width="100" height="110" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-31" value="" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="134" y="270" width="88" height="122" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-32" value="" style="endArrow=none;html=1;rounded=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="157" y="392" as="sourcePoint" /> + <mxPoint x="157" y="270" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-33" value="<b style="background-color: initial;"><br></b>" style="rounded=1;whiteSpace=wrap;html=1;align=left;" parent="1" vertex="1"> + <mxGeometry x="180" y="282" width="100" height="101" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-34" value="<p style="line-height: 40%;"><b>scriptPubKey</b></p><p style="line-height: 40%;"><span style="background-color: initial;"><i><b style=""><font color="#0066cc">recov-hash </font><font color="#00060d">...</font></b>&nbsp;</i></span></p><p style="line-height: 40%;"><span style="background-color: initial;">&nbsp; OP_VAULT</span></p><p style="line-height: 120%;"><b>amount</b><br>a1</p>" style="text;html=1;resizable=0;autosize=1;align=left;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;dashed=1;" parent="1" vertex="1"> + <mxGeometry x="183" y="271" width="100" height="120" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-52" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0;exitY=0.25;exitDx=0;exitDy=0;" parent="1" source="IMLKYxiTQTyD-2dyPs5i-38" edge="1"> + <mxGeometry relative="1" as="geometry"> + <mxPoint x="280" y="333" as="targetPoint" /> + <Array as="points"> + <mxPoint x="340" y="333" /> + </Array> + </mxGeometry> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-38" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="340" y="319" width="90" height="60" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-39" value="<p style="line-height: 40%;"><b>witness</b></p><p style="line-height: 40%;">[<i>trigger-key&nbsp;</i></p><p style="line-height: 40%;">&nbsp; signature]</p>" style="text;html=1;resizable=0;autosize=1;align=left;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;dashed=1;" parent="1" vertex="1"> + <mxGeometry x="353" y="310" width="90" height="80" as="geometry" /> + </mxCell> + <mxCell id="IMagvj_H5wSyhYbexlPS-2" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=0;exitY=0.5;exitDx=0;exitDy=0;entryX=1;entryY=0.5;entryDx=0;entryDy=0;" parent="1" target="IMLKYxiTQTyD-2dyPs5i-18" edge="1"> + <mxGeometry relative="1" as="geometry"> + <mxPoint x="600" y="538" as="sourcePoint" /> + </mxGeometry> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-54" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=0;exitY=0.25;exitDx=0;exitDy=0;entryX=1;entryY=0.5;entryDx=0;entryDy=0;" parent="1" target="IMLKYxiTQTyD-2dyPs5i-13" edge="1"> + <mxGeometry relative="1" as="geometry"> + <mxPoint x="600" y="448.5" as="sourcePoint" /> + <Array as="points"> + <mxPoint x="580" y="449" /> + <mxPoint x="580" y="355" /> + </Array> + </mxGeometry> + </mxCell> + <mxCell id="IMagvj_H5wSyhYbexlPS-1" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0;exitY=0.367;exitDx=0;exitDy=0;entryX=1;entryY=0.5;entryDx=0;entryDy=0;exitPerimeter=0;" parent="1" source="IMLKYxiTQTyD-2dyPs5i-43" edge="1"> + <mxGeometry relative="1" as="geometry"> + <mxPoint x="600" y="491.5" as="sourcePoint" /> + <mxPoint x="330" y="486.5" as="targetPoint" /> + <Array as="points"> + <mxPoint x="600" y="487" /> + <mxPoint x="465" y="487" /> + </Array> + </mxGeometry> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-43" value="Script-path reveal" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="600" y="473" width="90" height="35" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-20" value="<p style="line-height: 40%;"><b>scriptPubKey</b></p><p style="border-color: var(--border-color); line-height: 4.8px;"><i style="border-color: var(--border-color);"><b style="border-color: var(--border-color);"><font style="border-color: var(--border-color);" color="#0066cc">recov-hash&nbsp;</font><font style="border-color: var(--border-color);" color="#00060d">...</font></b>&nbsp;</i></p><p style="border-color: var(--border-color); line-height: 4.8px;"><span style="border-color: var(--border-color); background-color: initial;">&nbsp; OP_VAULT</span></p><p style="line-height: 120%;"><b>amount</b><br>a2</p>" style="text;html=1;resizable=0;autosize=1;align=left;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;dashed=1;" parent="1" vertex="1"> + <mxGeometry x="233" y="430" width="100" height="120" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-53" value="" style="group" parent="1" vertex="1" connectable="0"> + <mxGeometry x="465" y="307.5" width="120" height="95" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-15" value="<p style="line-height: 10%;"><b>scriptPubKey</b></p><p style="border-color: var(--border-color); line-height: 4.8px;"><i style="border-color: var(--border-color);"><b style="border-color: var(--border-color);"><font style="border-color: var(--border-color);" color="#0066cc">recov-hash&nbsp;</font><font style="border-color: var(--border-color);" color="#00060d">...</font></b>&nbsp;</i></p><p style="border-color: var(--border-color); line-height: 4.8px;"><span style="border-color: var(--border-color); background-color: initial;">&nbsp; OP_UNVAULT</span></p>" style="text;html=1;resizable=0;autosize=1;align=left;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;dashed=1;" parent="IMLKYxiTQTyD-2dyPs5i-53" vertex="1"> + <mxGeometry width="110" height="70" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-26" value="<p style="line-height: 10%;"><b>amount</b></p><p style="line-height: 10%;">a1</p>" style="text;html=1;resizable=0;autosize=1;align=left;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;dashed=1;" parent="IMLKYxiTQTyD-2dyPs5i-53" vertex="1"> + <mxGeometry y="45" width="70" height="50" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-60" value="" style="group" parent="1" vertex="1" connectable="0"> + <mxGeometry x="730" y="438" width="100" height="82" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-58" value="<p style="line-height: 20%;"><b>scriptPubKey</b></p><p style="line-height: 20%;"><i>[recovery-spk]</i></p>" style="text;html=1;resizable=0;autosize=1;align=left;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;dashed=1;" parent="IMLKYxiTQTyD-2dyPs5i-60" vertex="1"> + <mxGeometry width="100" height="50" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-59" value="<p style="line-height: 10%;"><b>amount</b></p><p style="line-height: 10%;">a1 + a2 + a3</p>" style="text;html=1;resizable=0;autosize=1;align=left;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;dashed=1;" parent="IMLKYxiTQTyD-2dyPs5i-60" vertex="1"> + <mxGeometry y="32" width="90" height="50" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-61" value="<i>Ephemeral anchor</i>" style="rounded=1;whiteSpace=wrap;html=1;dashed=1;" parent="1" vertex="1"> + <mxGeometry x="723.5" y="527" width="97" height="35" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-62" value="Recovered to interrupt unvault" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontSize=17;" parent="1" vertex="1"> + <mxGeometry x="277" y="268.5" width="250" height="30" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-63" value="Recovered while still vaulted" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontSize=17;" parent="1" vertex="1"> + <mxGeometry x="139" y="571" width="240" height="30" as="geometry" /> + </mxCell> + <mxCell id="IMLKYxiTQTyD-2dyPs5i-64" value="Batch recovery" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontSize=17;" parent="1" vertex="1"> + <mxGeometry x="635" y="380.5" width="140" height="30" as="geometry" /> + </mxCell> + <mxCell id="IMagvj_H5wSyhYbexlPS-9" value="output" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="723" y="273" width="90" height="21" as="geometry" /> + </mxCell> + <mxCell id="IMagvj_H5wSyhYbexlPS-10" value="optional output" style="rounded=1;whiteSpace=wrap;html=1;dashed=1;" parent="1" vertex="1"> + <mxGeometry x="723" y="302" width="90" height="21" as="geometry" /> + </mxCell> + <mxCell id="IMagvj_H5wSyhYbexlPS-11" value="input" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="723" y="332" width="90" height="22" as="geometry" /> + </mxCell> + <mxCell id="prdVbKwsFvf7KEGo0tpI-2" value="Script-path reveal" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="600" y="515" width="90" height="35" as="geometry" /> + </mxCell> + <mxCell id="T7j29g-1OFRtJtuNoE9x-1" value="Script-path reveal" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="600" y="434" width="90" height="35" as="geometry" /> + </mxCell> + </root> + </mxGraphModel> + </diagram> + <diagram id="x3-0X1WiPTrt-eOLsWqB" name="Recovery comparison"> + <mxGraphModel dx="1236" dy="1768" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0"> + <root> + <mxCell id="0" /> + <mxCell id="1" parent="0" /> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-3" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-1" target="QagaKE3Mm4n1A5BtnNWS-2" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-1" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="120" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-6" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-2" target="QagaKE3Mm4n1A5BtnNWS-5" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-2" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="200" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-4" value="<div>Presigned</div><div>vault<br></div>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="180" y="200" width="80" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-9" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-5" target="QagaKE3Mm4n1A5BtnNWS-8" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-5" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="280" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-7" value="Unvault" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="265" y="205" width="70" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-8" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="360" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-10" value="To recovery" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="335" y="205" width="90" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-11" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-12" target="QagaKE3Mm4n1A5BtnNWS-14" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-12" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="120" y="299" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-13" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-14" target="QagaKE3Mm4n1A5BtnNWS-16" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-14" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="200" y="299" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-15" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-16" target="QagaKE3Mm4n1A5BtnNWS-17" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-16" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="280" y="299" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-17" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="360" y="299" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-21" value="" style="group" parent="1" vertex="1" connectable="0"> + <mxGeometry x="240" y="260" width="40" height="60" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-18" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-21" vertex="1"> + <mxGeometry width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-19" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-21" vertex="1"> + <mxGeometry y="10" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-20" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-21" vertex="1"> + <mxGeometry y="20" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-22" value="<b>Precomputed vaults</b>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="210" y="168" width="140" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-23" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-24" target="QagaKE3Mm4n1A5BtnNWS-26" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-24" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="480" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-25" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-26" target="QagaKE3Mm4n1A5BtnNWS-29" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-26" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="560" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-27" value="<div>OP_VAULT</div>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontFamily=Courier New;" parent="1" vertex="1"> + <mxGeometry x="540" y="205" width="80" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-28" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-29" target="QagaKE3Mm4n1A5BtnNWS-31" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-29" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="640" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-30" value="OP_UNVAULT" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontFamily=Courier New;" parent="1" vertex="1"> + <mxGeometry x="615" y="205" width="90" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-31" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="720" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-32" value="To recovery" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="695" y="205" width="90" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-33" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-34" target="QagaKE3Mm4n1A5BtnNWS-36" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-34" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="480" y="299" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-35" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-36" target="QagaKE3Mm4n1A5BtnNWS-38" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-36" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="560" y="299" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-37" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-38" target="QagaKE3Mm4n1A5BtnNWS-31" edge="1"> + <mxGeometry relative="1" as="geometry"> + <mxPoint x="720" y="342" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-38" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="640" y="299" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-40" value="" style="group" parent="1" vertex="1" connectable="0"> + <mxGeometry x="600" y="260" width="40" height="60" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-41" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-40" vertex="1"> + <mxGeometry width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-42" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-40" vertex="1"> + <mxGeometry y="10" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-43" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-40" vertex="1"> + <mxGeometry y="20" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-44" value="<b>OP_VAULT</b>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontFamily=Courier New;" parent="1" vertex="1"> + <mxGeometry x="600" y="168" width="80" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-45" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-46" target="QagaKE3Mm4n1A5BtnNWS-48" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-46" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="120" y="449" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-47" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-48" target="QagaKE3Mm4n1A5BtnNWS-51" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-48" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="200" y="449" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-49" value="<div>Presigned</div><div>vault<br></div>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="180" y="409" width="80" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-51" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="280" y="449" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-52" value="To recovery" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="255" y="414" width="90" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-55" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-56" target="QagaKE3Mm4n1A5BtnNWS-58" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-56" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="120" y="503" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-57" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-58" target="QagaKE3Mm4n1A5BtnNWS-60" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-58" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="200" y="503" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-60" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="280" y="503" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-62" value="" style="group" parent="1" vertex="1" connectable="0"> + <mxGeometry x="238" y="467" width="40" height="60" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-63" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-62" vertex="1"> + <mxGeometry width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-64" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-62" vertex="1"> + <mxGeometry y="10" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-65" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-62" vertex="1"> + <mxGeometry y="20" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-66" value="<b>Precomputed vaults</b>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="210" y="377" width="140" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-67" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-68" target="QagaKE3Mm4n1A5BtnNWS-70" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-68" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="480" y="449" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-69" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-70" target="QagaKE3Mm4n1A5BtnNWS-73" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-70" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="560" y="449" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-71" value="<div>OP_VAULT</div>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontFamily=Courier New;" parent="1" vertex="1"> + <mxGeometry x="540" y="412" width="80" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-73" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="640" y="449" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-76" value="To recovery" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="615" y="412" width="90" height="30" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-77" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-78" target="QagaKE3Mm4n1A5BtnNWS-80" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-78" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="480" y="503" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-79" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="QagaKE3Mm4n1A5BtnNWS-80" target="QagaKE3Mm4n1A5BtnNWS-73" edge="1"> + <mxGeometry relative="1" as="geometry"> + <mxPoint x="640" y="551" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-80" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="560" y="503" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-83" value="" style="group" parent="1" vertex="1" connectable="0"> + <mxGeometry x="517" y="468" width="40" height="60" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-84" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-83" vertex="1"> + <mxGeometry width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-85" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-83" vertex="1"> + <mxGeometry y="10" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-86" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="QagaKE3Mm4n1A5BtnNWS-83" vertex="1"> + <mxGeometry y="20" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="QagaKE3Mm4n1A5BtnNWS-87" value="<b>OP_VAULT</b>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontFamily=Courier New;" parent="1" vertex="1"> + <mxGeometry x="600" y="377" width="80" height="30" as="geometry" /> + </mxCell> + </root> + </mxGraphModel> + </diagram> + <diagram id="51t3zBxVp8Nxi1LOdNUq" name="Withdrawal comparison"> + <mxGraphModel dx="1430" dy="1768" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0"> + <root> + <mxCell id="0" /> + <mxCell id="1" parent="0" /> + <mxCell id="ezkKjIhg79-38QoQ9XiY-1" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-2" target="ezkKjIhg79-38QoQ9XiY-4" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-2" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="120" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-3" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-4" target="ezkKjIhg79-38QoQ9XiY-7" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-4" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="190" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-5" value="<div>Presigned</div><div>vault<br></div>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="167" y="198" width="80" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-6" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-7" target="ezkKjIhg79-38QoQ9XiY-9" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-7" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="260" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-8" value="Unvault" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="243" y="202" width="70" height="30" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-78" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-9" target="ezkKjIhg79-38QoQ9XiY-77" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-9" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="335" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-10" value="<div>"Warm" <br></div><div>wallet<br></div>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="322" y="199" width="60" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-11" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-12" target="ezkKjIhg79-38QoQ9XiY-14" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-12" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="120" y="322" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-13" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-14" target="ezkKjIhg79-38QoQ9XiY-16" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-14" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="190" y="322" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-15" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-16" target="ezkKjIhg79-38QoQ9XiY-17" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-16" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="260" y="322" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-90" style="edgeStyle=none;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;fontFamily=Helvetica;" parent="1" source="ezkKjIhg79-38QoQ9XiY-17" target="ezkKjIhg79-38QoQ9XiY-80" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-17" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="335" y="322" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-18" value="" style="group" parent="1" vertex="1" connectable="0"> + <mxGeometry x="220" y="270" width="40" height="60" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-19" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="ezkKjIhg79-38QoQ9XiY-18" vertex="1"> + <mxGeometry width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-20" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="ezkKjIhg79-38QoQ9XiY-18" vertex="1"> + <mxGeometry y="10" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-21" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="ezkKjIhg79-38QoQ9XiY-18" vertex="1"> + <mxGeometry y="20" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-22" value="<b>Precomputed vaults</b>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;" parent="1" vertex="1"> + <mxGeometry x="210" y="158" width="140" height="30" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-23" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-24" target="ezkKjIhg79-38QoQ9XiY-26" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-24" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="519" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-25" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-26" target="ezkKjIhg79-38QoQ9XiY-29" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-26" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="599" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-27" value="<div>OP_VAULT</div>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontFamily=Courier New;" parent="1" vertex="1"> + <mxGeometry x="579" y="203" width="80" height="30" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-28" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-29" target="ezkKjIhg79-38QoQ9XiY-31" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-89" style="rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0;entryDx=0;entryDy=0;fontFamily=Helvetica;" parent="1" target="ezkKjIhg79-38QoQ9XiY-83" edge="1"> + <mxGeometry relative="1" as="geometry"> + <mxPoint x="740" y="260" as="sourcePoint" /> + </mxGeometry> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-29" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="690" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-31" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="769" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-33" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="ezkKjIhg79-38QoQ9XiY-34" target="ezkKjIhg79-38QoQ9XiY-36" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-34" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="519" y="322" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-35" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="ezkKjIhg79-38QoQ9XiY-36" target="ezkKjIhg79-38QoQ9XiY-29" edge="1"> + <mxGeometry relative="1" as="geometry"> + <mxPoint x="660" y="260" as="targetPoint" /> + <Array as="points"> + <mxPoint x="660" y="342" /> + <mxPoint x="660" y="260" /> + </Array> + </mxGeometry> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-36" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="599" y="322" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-39" value="" style="group" parent="1" vertex="1" connectable="0"> + <mxGeometry x="559" y="270" width="40" height="60" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-40" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="ezkKjIhg79-38QoQ9XiY-39" vertex="1"> + <mxGeometry width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-41" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="ezkKjIhg79-38QoQ9XiY-39" vertex="1"> + <mxGeometry y="10" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-42" value="" style="shape=waypoint;sketch=0;fillStyle=solid;size=6;pointerEvents=1;points=[];fillColor=none;resizable=0;rotatable=0;perimeter=centerPerimeter;snapToPoint=1;" parent="ezkKjIhg79-38QoQ9XiY-39" vertex="1"> + <mxGeometry y="20" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-43" value="<b>OP_VAULT</b>" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontFamily=Courier New;" parent="1" vertex="1"> + <mxGeometry x="639" y="158" width="80" height="30" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-77" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="414" y="240" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-80" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="414" y="322" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-83" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="769" y="290" width="40" height="40" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-84" value="Targets" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontFamily=Helvetica;" parent="1" vertex="1"> + <mxGeometry x="401" y="202" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="ezkKjIhg79-38QoQ9XiY-85" value="Targets" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontFamily=Helvetica;" parent="1" vertex="1"> + <mxGeometry x="758" y="203" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="hU3LCPZSUflRbzsWwJJh-1" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;" parent="1" vertex="1"> + <mxGeometry x="462" y="170" width="20" height="20" as="geometry" /> + </mxCell> + <mxCell id="hU3LCPZSUflRbzsWwJJh-2" value="=&nbsp; UTXO" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=11;" parent="1" vertex="1"> + <mxGeometry x="482" y="166" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="zbme-GfWksCJWwraIK2J-1" value=""Trigger"" style="text;html=1;resizable=0;autosize=1;align=center;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;fontFamily=Helvetica;" vertex="1" parent="1"> + <mxGeometry x="673" y="203" width="70" height="30" as="geometry" /> + </mxCell> + </root> + </mxGraphModel> + </diagram> + <diagram id="M-0T8bRLORY_nlIivCLq" name="Alt-vaults"> + <mxGraphModel dx="1236" dy="1160" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0"> + <root> + <mxCell id="0" /> + <mxCell id="1" parent="0" /> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-1" value="" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;" parent="1" source="-zpKa_FQ8lR9X4kw_iqW-5" target="-zpKa_FQ8lR9X4kw_iqW-9" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-2" value="<div>Sign with unvault key</div>" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" parent="-zpKa_FQ8lR9X4kw_iqW-1" vertex="1" connectable="0"> + <mxGeometry x="-0.3102" y="-1" relative="1" as="geometry"> + <mxPoint x="1" y="6" as="offset" /> + </mxGeometry> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-3" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;strokeColor=default;dashed=1;" parent="1" source="-zpKa_FQ8lR9X4kw_iqW-5" target="-zpKa_FQ8lR9X4kw_iqW-6" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-4" value="Reveal cold address" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" parent="-zpKa_FQ8lR9X4kw_iqW-3" vertex="1" connectable="0"> + <mxGeometry x="-0.17" y="2" relative="1" as="geometry"> + <mxPoint x="6" y="-8" as="offset" /> + </mxGeometry> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-5" value="<div><b>OP_VAULT</b></div><div>&lt;<i>cold-addr-hash</i>&gt;</div><div>&lt;<i>spend-delay</i>&gt;</div><div>&lt;<i>unvault-pk</i>&gt;<br></div>" style="rounded=1;whiteSpace=wrap;html=1;labelPosition=center;verticalLabelPosition=middle;align=center;verticalAlign=middle;" parent="1" vertex="1"> + <mxGeometry x="190" y="270" width="140" height="80" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-6" value="[recovery path]" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="460" y="285" width="120" height="50" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-7" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=default;" parent="1" source="-zpKa_FQ8lR9X4kw_iqW-9" target="-zpKa_FQ8lR9X4kw_iqW-10" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-8" value="<div>Wait <i>spend-delay</i> blocks <b>&amp;&amp;</b><br></div><div>outputs match target hash<br></div>" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" parent="-zpKa_FQ8lR9X4kw_iqW-7" vertex="1" connectable="0"> + <mxGeometry x="-0.302" y="2" relative="1" as="geometry"> + <mxPoint y="5" as="offset" /> + </mxGeometry> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-9" value="<div><b>OP_UNVAULT</b></div><div>&lt;<i>cold-addr-hash</i>&gt;</div><div>&lt;<i>spend-delay</i>&gt;</div><div>&lt;<i>target-outputs-hash</i>&gt;<br></div>" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="190" y="400" width="140" height="80" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-10" value="[arbitrary unvault target]" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="520" y="360" width="140" height="40" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-11" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;exitPerimeter=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;strokeColor=default;" parent="1" source="-zpKa_FQ8lR9X4kw_iqW-12" target="-zpKa_FQ8lR9X4kw_iqW-5" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-12" value="" style="points=[[0.145,0.145,0],[0.5,0,0],[0.855,0.145,0],[1,0.5,0],[0.855,0.855,0],[0.5,1,0],[0.145,0.855,0],[0,0.5,0]];shape=mxgraph.bpmn.event;html=1;verticalLabelPosition=bottom;labelBackgroundColor=#ffffff;verticalAlign=top;align=center;perimeter=ellipsePerimeter;outlineConnect=0;aspect=fixed;outline=standard;symbol=general;rounded=1;" parent="1" vertex="1"> + <mxGeometry x="245" y="220" width="30" height="30" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-13" value="" style="shadow=0;dashed=0;html=1;strokeColor=none;fillColor=#4495D1;labelPosition=center;verticalLabelPosition=bottom;verticalAlign=top;align=center;outlineConnect=0;shape=mxgraph.veeam.time;" parent="1" vertex="1"> + <mxGeometry x="505" y="425" width="30" height="30" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-14" value="" style="sketch=0;pointerEvents=1;shadow=0;dashed=0;html=1;strokeColor=none;fillColor=#505050;labelPosition=center;verticalLabelPosition=bottom;verticalAlign=top;outlineConnect=0;align=center;shape=mxgraph.office.security.key_permissions;" parent="1" vertex="1"> + <mxGeometry x="170" y="360" width="15" height="33" as="geometry" /> + </mxCell> + <mxCell id="-zpKa_FQ8lR9X4kw_iqW-15" value="" style="endArrow=none;dashed=1;html=1;rounded=0;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="330" y="420" as="sourcePoint" /> + <mxPoint x="390" y="310" as="targetPoint" /> + <Array as="points"> + <mxPoint x="390" y="420" /> + </Array> + </mxGeometry> + </mxCell> + </root> + </mxGraphModel> + </diagram> + <diagram id="9IyR_zxcH8IqVGAvo76N" name="Basic"> + <mxGraphModel dx="1236" dy="1768" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0"> + <root> + <mxCell id="0" /> + <mxCell id="1" parent="0" /> + <mxCell id="uh7-YCnJg2CyufrYdqnU-5" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" source="uh7-YCnJg2CyufrYdqnU-1" target="uh7-YCnJg2CyufrYdqnU-2" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="uh7-YCnJg2CyufrYdqnU-7" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=0;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;dashed=1;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" source="uh7-YCnJg2CyufrYdqnU-1" target="uh7-YCnJg2CyufrYdqnU-4" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="uh7-YCnJg2CyufrYdqnU-1" value="<div>User spends UTXO(s)<br></div><div>into vault<br></div>" style="rounded=1;whiteSpace=wrap;html=1;labelPosition=center;verticalLabelPosition=middle;align=center;verticalAlign=middle;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" vertex="1"> + <mxGeometry x="90" y="310" width="140" height="60" as="geometry" /> + </mxCell> + <mxCell id="uh7-YCnJg2CyufrYdqnU-6" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" source="uh7-YCnJg2CyufrYdqnU-2" target="uh7-YCnJg2CyufrYdqnU-3" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="KdfuowOYJgZ3zCW8n2jm-2" value="<div>After some</div><div>delay<br></div>" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=1;points=[];movable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="uh7-YCnJg2CyufrYdqnU-6" vertex="1" connectable="0"> + <mxGeometry x="-0.2" y="-1" relative="1" as="geometry"> + <mxPoint x="15" y="-1" as="offset" /> + </mxGeometry> + </mxCell> + <mxCell id="uh7-YCnJg2CyufrYdqnU-10" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.25;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;dashed=1;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" source="uh7-YCnJg2CyufrYdqnU-2" target="uh7-YCnJg2CyufrYdqnU-4" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="uh7-YCnJg2CyufrYdqnU-2" value="<div>Unvault attempt<br></div><div>is triggered</div>" style="rounded=1;whiteSpace=wrap;html=1;labelPosition=center;verticalLabelPosition=middle;align=center;verticalAlign=middle;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" vertex="1"> + <mxGeometry x="260" y="310" width="140" height="60" as="geometry" /> + </mxCell> + <mxCell id="uh7-YCnJg2CyufrYdqnU-3" value="<div>Withdrawal is finalized<br></div>" style="rounded=1;whiteSpace=wrap;html=1;labelPosition=center;verticalLabelPosition=middle;align=center;verticalAlign=middle;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" vertex="1"> + <mxGeometry x="500" y="310" width="140" height="60" as="geometry" /> + </mxCell> + <mxCell id="uh7-YCnJg2CyufrYdqnU-4" value="<div>Vaulted coins <br></div><div>swept to prespecified</div><div>recovery path<br></div>" style="rounded=1;whiteSpace=wrap;html=1;labelPosition=center;verticalLabelPosition=middle;align=center;verticalAlign=middle;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" vertex="1"> + <mxGeometry x="340" y="230" width="140" height="60" as="geometry" /> + </mxCell> + <mxCell id="KdfuowOYJgZ3zCW8n2jm-1" value="" style="shadow=0;dashed=0;html=1;strokeColor=none;fillColor=#4495D1;labelPosition=center;verticalLabelPosition=bottom;verticalAlign=top;align=center;outlineConnect=0;shape=mxgraph.veeam.time;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" vertex="1"> + <mxGeometry x="446" y="360" width="20" height="20" as="geometry" /> + </mxCell> + <mxCell id="4beDPwlwmHm2dIG_X1VO-2" value="" style="endArrow=none;html=1;rounded=1;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="520" y="259" as="sourcePoint" /> + <mxPoint x="540" y="259" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="4beDPwlwmHm2dIG_X1VO-3" value="Expected path" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" vertex="1"> + <mxGeometry x="542" y="244" width="90" height="30" as="geometry" /> + </mxCell> + <mxCell id="4beDPwlwmHm2dIG_X1VO-4" value="" style="endArrow=none;html=1;rounded=1;dashed=1;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="520" y="275" as="sourcePoint" /> + <mxPoint x="540" y="275" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="4beDPwlwmHm2dIG_X1VO-5" value="Recovery path" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;movable=1;resizable=1;rotatable=1;deletable=1;editable=1;locked=0;connectable=1;" parent="1" vertex="1"> + <mxGeometry x="543" y="260" width="90" height="30" as="geometry" /> + </mxCell> + </root> + </mxGraphModel> + </diagram> + <diagram id="jRtaY6zHFwBRHzIYjIhC" name="Page-7"> + <mxGraphModel dx="2162" dy="1316" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0"> + <root> + <mxCell id="0" /> + <mxCell id="1" parent="0" /> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-56" value="" style="rounded=1;whiteSpace=wrap;html=1;dashed=1;strokeColor=#4D4D4D;fontFamily=Courier New;fontSize=20;" parent="1" vertex="1"> + <mxGeometry x="308" y="660" width="232" height="100" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-50" value="" style="rounded=1;whiteSpace=wrap;html=1;dashed=1;strokeColor=#4D4D4D;fontFamily=Courier New;fontSize=20;" parent="1" vertex="1"> + <mxGeometry x="57" y="380" width="413" height="230" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-48" value="" style="rounded=1;whiteSpace=wrap;html=1;dashed=1;strokeColor=#4D4D4D;fontFamily=Courier New;fontSize=20;" parent="1" vertex="1"> + <mxGeometry x="590" y="380" width="230" height="221" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-46" value="" style="rounded=1;whiteSpace=wrap;html=1;strokeColor=#4D4D4D;fontFamily=Courier New;fontSize=8;dashed=1;" parent="1" vertex="1"> + <mxGeometry x="182" y="102.5" width="509" height="183.5" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-19" value="" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="445" y="169.5" width="120" height="100" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-2" value="&nbsp;[trigger auth]&nbsp;<i>&lt;spend-delay&gt;</i> 2 "OP_CSV OP_DROP OP_CTV" <b>OP_VAULT&nbsp;</b>" style="rounded=1;whiteSpace=wrap;html=1;align=right;fontFamily=Courier New;verticalAlign=bottom;strokeColor=#336600;" parent="1" vertex="1"> + <mxGeometry x="199" y="187.5" width="471" height="30" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-20" value="" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="288" y="488" width="120" height="100" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-21" value="&nbsp;<i> <font color="#994c00">&lt;CTV-hash&gt;</font>&nbsp;&lt;spend-delay&gt;</i>&nbsp;OP_CSV OP_DROP OP_CTV&nbsp;" style="rounded=1;whiteSpace=wrap;html=1;align=right;fontFamily=Courier New;verticalAlign=bottom;strokeColor=#B01E1E;" parent="1" vertex="1"> + <mxGeometry x="80" y="508" width="380" height="30" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-22" value="[recovery auth]<i> &lt;recovery-sPK-hash&gt;</i> <b>OP_VAULT_RECOVER&nbsp;<br></b>" style="rounded=1;whiteSpace=wrap;html=1;align=right;fontFamily=Courier New;verticalAlign=bottom;strokeColor=#007FFF;" parent="1" vertex="1"> + <mxGeometry x="80" y="545" width="380" height="30" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-18" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0.394;entryY=0.97;entryDx=0;entryDy=0;entryPerimeter=0;fontFamily=Courier New;fontSize=22;" parent="1" source="Y65zMmu6unbP29DxbX5J-24" target="Y65zMmu6unbP29DxbX5J-25" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-24" value="<i>&lt;internal-pubkey&gt;</i>" style="rounded=1;whiteSpace=wrap;html=1;align=center;" parent="1" vertex="1"> + <mxGeometry x="139" y="483" width="120" height="16.5" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-25" value="TR" style="ellipse;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="239" y="444.5" width="100" height="28.5" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-17" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=0;exitY=0.5;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;fontFamily=Courier New;fontSize=22;" parent="1" source="Y65zMmu6unbP29DxbX5J-26" target="Y65zMmu6unbP29DxbX5J-25" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-26" value="Tapleaves" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="1" vertex="1"> + <mxGeometry x="290" y="481" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-27" value="<i>withdrawal</i>" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="1" vertex="1"> + <mxGeometry x="80" y="499" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-28" value="<i>recover<br></i>" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="1" vertex="1"> + <mxGeometry x="75" y="536" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-29" value="" style="shape=flexArrow;endArrow=classic;html=1;rounded=1;fontFamily=Courier New;fontSize=9;endWidth=7.5;endSize=4.325;strokeColor=#336600;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="310" y="300" as="sourcePoint" /> + <mxPoint x="263" y="366" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-30" value="script-path spend of <i style="font-size: 11px;"><font color="#336600" style="font-size: 11px;">trigger</font></i>&nbsp;leaf,<br style="font-size: 11px;">supplying <font color="#cc6600" style="font-size: 11px;">CTV hash </font>in witness,<br style="font-size: 11px;">satisfying trigger auth" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=11;" parent="1" vertex="1"> + <mxGeometry x="97" y="305" width="167" height="43" as="geometry" /> + </mxCell> + <mxCell id="Y65zMmu6unbP29DxbX5J-33" value="script-path spend of <i style="font-size: 11px;"><font color="#007fff" style="font-size: 11px;">recover</font></i>&nbsp;leaf, satisfying recovery authorization <br style="font-size: 11px;">script, if specified" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=11;" parent="1" vertex="1"> + <mxGeometry x="640" y="295.5" width="140" height="64" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-12" value="OP_VAULT allows templated replacement of its leaf during spend (green to red) - otherwise taptree unchanged" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;fontStyle=0" parent="1" vertex="1"> + <mxGeometry x="251" y="398" width="202" height="30" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-13" value="" style="endArrow=classic;html=1;rounded=1;fontFamily=Courier New;fontSize=22;strokeColor=#007FFF;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="570" y="300" as="sourcePoint" /> + <mxPoint x="642" y="360" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-21" value="&nbsp;[recovery auth] <i>&lt;recovery-sPK-hash&gt;</i> <b>OP_VAULT_RECOVER&nbsp;<br></b>" style="rounded=1;whiteSpace=wrap;html=1;align=right;fontFamily=Courier New;verticalAlign=bottom;strokeColor=#007FFF;" parent="1" vertex="1"> + <mxGeometry x="199" y="226.5" width="471" height="30" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-22" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0.394;entryY=0.97;entryDx=0;entryDy=0;entryPerimeter=0;fontFamily=Courier New;fontSize=22;" parent="1" source="nh3bwgDFfLlpKYWmzqJt-23" target="nh3bwgDFfLlpKYWmzqJt-24" edge="1"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-23" value="<i>&lt;internal-pubkey&gt;</i>" style="rounded=1;whiteSpace=wrap;html=1;align=center;" parent="1" vertex="1"> + <mxGeometry x="289" y="164.5" width="120" height="16.5" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-24" value="TR" style="ellipse;whiteSpace=wrap;html=1;" parent="1" vertex="1"> + <mxGeometry x="389" y="126" width="100" height="28.5" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-26" value="Tapleaves" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="1" vertex="1"> + <mxGeometry x="444" y="162.5" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-27" value="<i>trigger</i>" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="1" vertex="1"> + <mxGeometry x="188" y="180.5" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-28" value="<i>recover<br></i>" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" parent="1" vertex="1"> + <mxGeometry x="191" y="217.5" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-29" value="1" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=8;fontFamily=Courier New;" parent="1" vertex="1"> + <mxGeometry x="444" y="139.5" width="12" height="10" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-30" value="2" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=8;fontFamily=Courier New;" parent="1" vertex="1"> + <mxGeometry x="270" y="449" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-37" value="<p style="border-color: var(--border-color); line-height: 2.4px;"><i style="border-color: var(--border-color);"><font style="border-color: var(--border-color);" color="#cc6600">[transaction</font></i><i style="background-color: initial; border-color: var(--border-color);"><font style="border-color: var(--border-color);" color="#cc6600">&nbsp;satisfying&nbsp;</font></i></p><p style="border-color: var(--border-color); line-height: 2.4px;"><i style="border-color: var(--border-color);"><font style="border-color: var(--border-color);" color="#cc6600">&nbsp; CTV hash]</font></i></p>" style="rounded=1;whiteSpace=wrap;html=1;align=center;" parent="1" vertex="1"> + <mxGeometry x="339" y="695" width="171" height="50" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-43" value="" style="endArrow=classic;html=1;rounded=1;fontFamily=Courier New;fontSize=22;strokeColor=#CC0000;fontColor=#CC0000;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="266" y="620" as="sourcePoint" /> + <mxPoint x="300" y="660" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-44" value="timelocked CTV spend to predefined destination" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=11;" parent="1" vertex="1"> + <mxGeometry x="150" y="654" width="120" height="40" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-47" value="1. initial vault" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=20;fontStyle=2;fontColor=#808080;" parent="1" vertex="1"> + <mxGeometry x="199.5" y="104.5" width="131" height="28" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-49" value="recovery" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=20;fontStyle=2;fontColor=#808080;" parent="1" vertex="1"> + <mxGeometry x="688" y="378" width="131" height="28" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-51" value="2. trigger" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=20;fontStyle=2;fontColor=#808080;" parent="1" vertex="1"> + <mxGeometry x="50" y="380.5" width="131" height="28" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-52" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;fontFamily=Courier New;fontSize=20;" parent="1" edge="1"> + <mxGeometry relative="1" as="geometry"> + <mxPoint x="565.0000000000002" y="340" as="sourcePoint" /> + <mxPoint x="565.0000000000002" y="340" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-53" value="" style="group" parent="1" vertex="1" connectable="0"> + <mxGeometry x="610" y="418.5" width="210" height="160" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-1" value="" style="rounded=1;whiteSpace=wrap;html=1;" parent="nh3bwgDFfLlpKYWmzqJt-53" vertex="1"> + <mxGeometry x="22.105263157894736" width="127.10526315789473" height="160" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-3" value="<b style="background-color: initial;"><br></b>" style="rounded=1;whiteSpace=wrap;html=1;align=left;" parent="nh3bwgDFfLlpKYWmzqJt-53" vertex="1"> + <mxGeometry x="101.31578947368422" y="14" width="92.10526315789473" height="80" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-5" value="" style="group;fontSize=9;" parent="nh3bwgDFfLlpKYWmzqJt-53" vertex="1" connectable="0"> + <mxGeometry x="105.6842105263158" y="14" width="101.31578947368422" height="82" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-6" value="<p style="line-height: 20%; font-size: 11px;"><b style=""><font style="font-size: 11px;">scriptPubKey</font></b></p><p style="line-height: 20%; font-size: 11px;"><i style=""><font style="font-size: 11px;">[recovery-spk]</font></i></p>" style="text;html=1;resizable=0;autosize=1;align=left;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;dashed=1;" parent="nh3bwgDFfLlpKYWmzqJt-5" vertex="1"> + <mxGeometry x="-2" width="100" height="50" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-7" value="<p style="line-height: 10%; font-size: 11px;"><b style=""><font style="font-size: 11px;">amount</font></b></p><p style="line-height: 10%; font-size: 11px;"><font style="font-size: 11px;"><i>[full vault amount]</i></font></p>" style="text;html=1;resizable=0;autosize=1;align=left;verticalAlign=middle;points=[];fillColor=none;strokeColor=none;rounded=0;dashed=1;" parent="nh3bwgDFfLlpKYWmzqJt-5" vertex="1"> + <mxGeometry x="-2" y="32" width="110" height="50" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-8" value="<i><font style="font-size: 11px;">Ephemeral anchor</font></i>" style="rounded=1;whiteSpace=wrap;html=1;dashed=1;" parent="nh3bwgDFfLlpKYWmzqJt-53" vertex="1"> + <mxGeometry x="102.69736842105263" y="107" width="89.34210526315789" height="35" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-11" value="Script-path reveal" style="rounded=0;whiteSpace=wrap;html=1;fontSize=10;" parent="nh3bwgDFfLlpKYWmzqJt-53" vertex="1"> + <mxGeometry y="30" width="64.47368421052632" height="35" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-2" value="" style="endArrow=none;html=1;rounded=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" parent="nh3bwgDFfLlpKYWmzqJt-53" source="nh3bwgDFfLlpKYWmzqJt-1" target="nh3bwgDFfLlpKYWmzqJt-1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="540.6578947368422" y="505" as="sourcePoint" /> + <mxPoint x="586.7105263157895" y="455" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-57" value="3. withdrawal" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=20;fontStyle=2;fontColor=#808080;" parent="1" vertex="1"> + <mxGeometry x="395" y="660" width="131" height="28" as="geometry" /> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-61" value="" style="endArrow=classic;html=1;rounded=1;strokeColor=#000000;fontFamily=Courier New;fontSize=11;fontColor=#808080;exitX=0.098;exitY=-0.004;exitDx=0;exitDy=0;exitPerimeter=0;entryX=0.663;entryY=0.984;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" source="nh3bwgDFfLlpKYWmzqJt-19" target="nh3bwgDFfLlpKYWmzqJt-24" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="446.5" y="176" as="sourcePoint" /> + <mxPoint x="496.5" y="126" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="nh3bwgDFfLlpKYWmzqJt-62" value="" style="endArrow=classic;html=1;rounded=1;fontFamily=Courier New;fontSize=22;strokeColor=#007FFF;" parent="1" edge="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="490" y="440" as="sourcePoint" /> + <mxPoint x="570" y="440" as="targetPoint" /> + </mxGeometry> + </mxCell> + </root> + </mxGraphModel> + </diagram> + <diagram id="gvPKSLqK7s9hnQgXeOr3" name="Page-8"> + <mxGraphModel dx="547" dy="897" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0"> + <root> + <mxCell id="0" /> + <mxCell id="1" parent="0" /> + <mxCell id="IdHh1SD0108lOCAqlYyb-2" value="" style="rounded=1;whiteSpace=wrap;html=1;dashed=1;strokeColor=#4D4D4D;fontFamily=Courier New;fontSize=20;" vertex="1" parent="1"> + <mxGeometry x="223" y="387" width="427" height="230" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-4" value="" style="rounded=1;whiteSpace=wrap;html=1;strokeColor=#4D4D4D;fontFamily=Courier New;fontSize=8;dashed=1;" vertex="1" parent="1"> + <mxGeometry x="182" y="102.5" width="509" height="183.5" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-48" value="" style="endArrow=classic;html=1;rounded=1;strokeColor=#000000;fontFamily=Courier New;fontSize=11;fontColor=#808080;entryX=0.544;entryY=1.002;entryDx=0;entryDy=0;entryPerimeter=0;exitX=0.1;exitY=0.583;exitDx=0;exitDy=0;exitPerimeter=0;" edge="1" parent="1" source="IdHh1SD0108lOCAqlYyb-26" target="IdHh1SD0108lOCAqlYyb-25"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="450" y="178" as="sourcePoint" /> + <mxPoint x="496.5" y="126" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-5" value="" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="1"> + <mxGeometry x="445" y="169.5" width="120" height="100" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-6" value="&nbsp;[trigger auth]&nbsp;<i>&lt;spend-delay&gt;</i> 2 "OP_CSV OP_DROP OP_CTV" <b>OP_VAULT&nbsp;</b>" style="rounded=1;whiteSpace=wrap;html=1;align=right;fontFamily=Courier New;verticalAlign=bottom;strokeColor=#336600;" vertex="1" parent="1"> + <mxGeometry x="199" y="187.5" width="471" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-7" value="" style="rounded=1;whiteSpace=wrap;html=1;" vertex="1" parent="1"> + <mxGeometry x="454" y="495" width="120" height="100" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-8" value="&nbsp;<i> <font color="#994c00">&lt;CTV-hash&gt;</font>&nbsp;&lt;spend-delay&gt;</i>&nbsp;OP_CSV OP_DROP OP_CTV&nbsp;" style="rounded=1;whiteSpace=wrap;html=1;align=right;fontFamily=Courier New;verticalAlign=bottom;strokeColor=#B01E1E;" vertex="1" parent="1"> + <mxGeometry x="240" y="515" width="386" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-9" value="[recovery auth]<i> &lt;recovery-sPK-hash&gt;</i> <b>OP_VAULT_RECOVER&nbsp;<br></b>" style="rounded=1;whiteSpace=wrap;html=1;align=right;fontFamily=Courier New;verticalAlign=bottom;strokeColor=#007FFF;" vertex="1" parent="1"> + <mxGeometry x="240" y="552" width="386" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-10" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0.394;entryY=0.97;entryDx=0;entryDy=0;entryPerimeter=0;fontFamily=Courier New;fontSize=22;" edge="1" parent="1" source="IdHh1SD0108lOCAqlYyb-11" target="IdHh1SD0108lOCAqlYyb-12"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-11" value="<i>&lt;internal-pubkey&gt;</i>" style="rounded=1;whiteSpace=wrap;html=1;align=center;" vertex="1" parent="1"> + <mxGeometry x="305" y="490" width="120" height="16.5" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-12" value="TR" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1"> + <mxGeometry x="405" y="451.5" width="100" height="28.5" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-13" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=0;exitY=0.5;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;fontFamily=Courier New;fontSize=22;" edge="1" parent="1" source="IdHh1SD0108lOCAqlYyb-14" target="IdHh1SD0108lOCAqlYyb-12"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-14" value="Tapleaves" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="1"> + <mxGeometry x="456" y="488" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-15" value="<i>withdrawal</i>" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="1"> + <mxGeometry x="239" y="506" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-16" value="<i>recover<br></i>" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="1"> + <mxGeometry x="235" y="543" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-17" value="" style="shape=flexArrow;endArrow=classic;html=1;rounded=1;fontFamily=Courier New;fontSize=9;endWidth=7.5;endSize=4.325;strokeColor=#336600;" edge="1" parent="1"> + <mxGeometry width="50" height="50" relative="1" as="geometry"> + <mxPoint x="438" y="301" as="sourcePoint" /> + <mxPoint x="438" y="371" as="targetPoint" /> + </mxGeometry> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-18" value="script-path spend of <i style="font-size: 11px;"><font color="#336600" style="font-size: 11px;">trigger</font></i>&nbsp;leaf,<br style="font-size: 11px;">supplying <font color="#cc6600" style="font-size: 11px;">CTV hash </font>in witness,<br style="font-size: 11px;">satisfying trigger auth" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=11;" vertex="1" parent="1"> + <mxGeometry x="248" y="310" width="167" height="43" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-20" value="OP_VAULT allows templated replacement of its leaf during spend (green to red) - otherwise taptree unchanged" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=10;fontStyle=0" vertex="1" parent="1"> + <mxGeometry x="417" y="405" width="202" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-22" value="&nbsp;[recovery auth] <i>&lt;recovery-sPK-hash&gt;</i> <b>OP_VAULT_RECOVER&nbsp;<br></b>" style="rounded=1;whiteSpace=wrap;html=1;align=right;fontFamily=Courier New;verticalAlign=bottom;strokeColor=#007FFF;" vertex="1" parent="1"> + <mxGeometry x="199" y="226.5" width="471" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-23" style="edgeStyle=orthogonalEdgeStyle;rounded=1;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0.394;entryY=0.97;entryDx=0;entryDy=0;entryPerimeter=0;fontFamily=Courier New;fontSize=22;" edge="1" parent="1" source="IdHh1SD0108lOCAqlYyb-24" target="IdHh1SD0108lOCAqlYyb-25"> + <mxGeometry relative="1" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-24" value="<i>&lt;internal-pubkey&gt;</i>" style="rounded=1;whiteSpace=wrap;html=1;align=center;" vertex="1" parent="1"> + <mxGeometry x="289" y="164.5" width="120" height="16.5" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-25" value="TR" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1"> + <mxGeometry x="389" y="126" width="100" height="28.5" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-26" value="Tapleaves" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="1"> + <mxGeometry x="444" y="162.5" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-27" value="<i>trigger</i>" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="1"> + <mxGeometry x="188" y="180.5" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-28" value="<i>recover<br></i>" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=9;" vertex="1" parent="1"> + <mxGeometry x="191" y="217.5" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-29" value="1" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=8;fontFamily=Courier New;" vertex="1" parent="1"> + <mxGeometry x="444" y="139.5" width="12" height="10" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-30" value="2" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=8;fontFamily=Courier New;" vertex="1" parent="1"> + <mxGeometry x="436" y="456" width="60" height="30" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-34" value="1. initial vault" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=20;fontStyle=2;fontColor=#808080;" vertex="1" parent="1"> + <mxGeometry x="199.5" y="104.5" width="131" height="28" as="geometry" /> + </mxCell> + <mxCell id="IdHh1SD0108lOCAqlYyb-36" value="2. trigger" style="text;strokeColor=none;align=center;fillColor=none;html=1;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=20;fontStyle=2;fontColor=#808080;" vertex="1" parent="1"> + <mxGeometry x="216" y="389.5" width="131" height="28" as="geometry" /> + </mxCell> + </root> + </mxGraphModel> + </diagram> +</mxfile> diff --git a/bip-0345/withdrawal-comparison.drawio.png b/bip-0345/withdrawal-comparison.drawio.png Binary files differnew file mode 100644 index 0000000..8a76d20 --- /dev/null +++ b/bip-0345/withdrawal-comparison.drawio.png diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki new file mode 100644 index 0000000..981af81 --- /dev/null +++ b/bip-0347.mediawiki @@ -0,0 +1,113 @@ +<pre> + BIP: 347 + Layer: Consensus (soft fork) + Title: OP_CAT in Tapscript + Author: Ethan Heilman <ethan.r.heilman@gmail.com> + Armin Sabouri <arminsdev@gmail.com> + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0347 + Status: Draft + Type: Standards Track + Created: 2023-12-11 + License: BSD-3-Clause + Post-History: 2023-10-21: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022049.html [bitcoin-dev] Proposed BIP for OP_CAT +</pre> + +==Abstract== + +This BIP introduces OP_CAT as a tapscript opcode which allows the concatenation of two values on the stack. OP_CAT would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal). This is the same opcode value used by the original OP_CAT. + +== Copyright == + +This document is licensed under the 3-clause BSD license. + +==Specification== + +When evaluated, the OP_CAT instruction: +# Pops the top two values off the stack, +# concatenates the popped values together in stack order, +# and then pushes the concatenated value on the top of the stack. + +Given the stack ''<nowiki>[x1, x2]</nowiki>'', where ''x2'' is at the top of the stack, OP_CAT will push ''x1 || x2'' onto the stack. By ''||'' we denote concatenation. OP_CAT fails if there are fewer than two values on the stack or if a concatenated value would have a combined size greater than the maximum script element size of 520 bytes. + +This opcode would be activated via a soft fork by redefining the tapscript opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal) to OP_CAT. + +==Motivation== + +Bitcoin Tapscript lacks a general purpose way of combining objects on the stack, restricting the expressiveness and power of Tapscript. This prevents, among many other things, the ability to construct and evaluate merkle trees and other hashed data structures in Tapscript. OP_CAT, by adding a general purpose way to concatenate stack values, would overcome this limitation and greatly increase the functionality of Tapscript. + +OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modular, and useful opcode in the spirit of Unix <ref>R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf</ref>. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable: + +* Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT, they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. <ref>R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf</ref> +* Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with up to 4,294,967,296 public keys. This also enables generalized logical spend conditions. <ref> P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/</ref> +* Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. <ref>J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html</ref> It has been proposed that if ECDSA is broken or a powerful computer was on the horizon, there might be an effort to protect ownership of bitcoins by allowing people to mark their taproot outputs as "script-path only" and then move their coins into such outputs with a leaf in the script tree requiring a Lamport signature. It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot. +* Non-equivocation contracts <ref>T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://web.archive.org/web/20221023121048/https://publications.cispa.saarland/565/1/penalizing.pdf</ref> in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols. +* Vaults <ref>M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf</ref> which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in <ref>A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html</ref> OP_CAT is sufficient to build vaults in Bitcoin. +* Replicating CheckSigFromStack <ref>A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298</ref> which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures <ref>R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md</ref>. + +OP_CAT was available in early versions of Bitcoin. +In 2010, a single commit disabled OP_CAT, along with another 15 opcodes. +Folklore states that OP_CAT was removed in this commit because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script. +For example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack element whose size was greater than 1 terabyte assuming no maximum stack element size. As Bitcoin at that time had a maximum stack element size of 5000 bytes, the effect of this expansion was limited to 5000 bytes. +This is no longer an issue because tapscript enforces a maximum stack element size of 520 bytes. + + +==Rationale== + +Our decision to reenable OP_CAT by redefining a tapscript OP_SUCCESSx opcode to OP_CAT was motivated to leverage the tapscript softfork opcode upgrade path introduced in [[bip-0342.mediawiki|BIP342]]. + +We specifically choose to use OP_SUCCESS126 rather than another OP_SUCCESSx as OP_SUCCESS126 uses the same opcode value (126 in decimal and 0x7e in hexadecimal) that was used for OP_CAT prior to it being disabled in Bitcoin. This removes a potential source of confusion that would exist if we had a opcode value different from the one used in the original OP_CAT opcode. + +While the OP_SUCCESSx opcode upgrade path could enable us to increase the stack element size while reenabling OP_CAT, we wanted to separate the decision to change the stack element size limit from the decision to reenable OP_CAT. This BIP takes no position in favor or against increasing the stack element size limit. + +==Backwards Compatibility== + +OP_CAT usage in a non-tapscript script will continue to trigger the SCRIPT_ERR_DISABLED_OPCODE. The only change would be to OP_CAT usage in tapscript. This change to tapscript would be activated as a soft fork that redefines an OP_SUCCESSx opcode (OP_SUCCESS126) to OP_CAT. + +==Reference implementation== + +<pre> +case OP_CAT: +{ + if (stack.size() < 2) + return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); + valtype& vch1 = stacktop(-2); + valtype& vch2 = stacktop(-1); + if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE) + return set_error(serror, SCRIPT_ERR_PUSH_SIZE); + vch1.insert(vch1.end(), vch2.begin(), vch2.end()); + stack.pop_back(); +} +break; +</pre> + + +The value of <code>MAX_SCRIPT_ELEMENT_SIZE</code> is 520. + +This implementation is inspired by the original implementation of [https://github.com/bitcoin/bitcoin/blob/01cd2fdaf3ac6071304ceb80fb7436ac02b1059e/script.cpp#L381-L393 OP_CAT as it existed in the Bitcoin codebase] prior to the commit "misc changes" 4bd188c<ref>S. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefR94</ref> which disabled it: + +<pre> +case OP_CAT: +{ + // (x1 x2 -- out) + if (stack.size() < 2) + return false; + valtype& vch1 = stacktop(-2); + valtype& vch2 = stacktop(-1); + vch1.insert(vch1.end(), vch2.begin(), vch2.end()); + stack.pop_back(); + if (stacktop(-1).size() > 5000) + return false; +} +break; +</pre> + +An alternative implementation of OP_CAT can be found in Elements <ref>Roose S., Elements Project, "Re-enable several disabled opcodes", 2019, https://github.com/ElementsProject/elements/commit/13e1103abe3e328c5a4e2039b51a546f8be6c60a#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R740-R759</ref>. + +==References== + +<references/> + +==Acknowledgements== + +We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill, +Tim Ruffing and Johan T. Halseth for their feedback, review and helpful comments. diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki index 9873d80..439b2a2 100644 --- a/bip-0350.mediawiki +++ b/bip-0350.mediawiki @@ -5,7 +5,7 @@ Author: Pieter Wuille <pieter@wuille.net> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0350 - Status: Draft + Status: Final Type: Standards Track Created: 2020-12-16 License: BSD-2-Clause diff --git a/bip-0352.mediawiki b/bip-0352.mediawiki new file mode 100644 index 0000000..0eff355 --- /dev/null +++ b/bip-0352.mediawiki @@ -0,0 +1,493 @@ +<pre> + BIP: 352 + Layer: Applications + Title: Silent Payments + Author: josibake <josibake@protonmail.com> + Ruben Somsen <rsomsen@gmail.com> + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0352 + Status: Proposed + Type: Standards Track + Created: 2023-03-09 + License: BSD-2-Clause + Post-History: 2022-03-13: https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8 [gist] Original proposal + 2022-03-28: https://gnusha.org/pi/bitcoindev/CAPv7TjbXm953U2h+-12MfJ24YqOM5Kcq77_xFTjVK+R2nf-nYg@mail.gmail.com/ [bitcoin-dev] Silent Payments – Non-interactive private payments with no on-chain overhead + 2022-10-11: https://gnusha.org/pi/bitcoindev/P_21MLHGJicZ-hkbC4DGu86c5BtNKiH8spY4TOw5FJsfimdi_6VyHzU_y-s1mZsOcC2FA3EW_6w6W5qfV9dRK_7AvTAxDlwVfU-yhWZPEuo=@protonmail.com/ [bitcoin-dev] Silent Payment v4 (coinjoin support added) + 2023-08-04: https://gnusha.org/pi/bitcoindev/ZM03twumu88V2NFH@petertodd.org/ [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time +</pre> + +== Introduction == + +=== Abstract === + +This document specifies a protocol for static payment addresses in Bitcoin without on-chain linkability of payments or a need for on-chain notifications. + +=== Copyright === + +This BIP is licensed under the BSD 2-clause license. + +=== Motivation === + +Using a new address for each Bitcoin transaction is a crucial aspect of maintaining privacy. This often requires a secure interaction between sender and receiver, so that the receiver can hand out a fresh address, a batch of fresh addresses, or a method for the sender to generate addresses on-demand, such as an xpub. + +However, interaction is often infeasible and in many cases undesirable. To solve for this, various protocols have been proposed which use a static payment address and notifications sent via the blockchain<ref name="out_of_band_notifications">'''Why not use out-of-band notifications''' Out-of-band notifications (e.g. using something other than the Bitcoin blockchain) have been proposed as a way of addressing the privacy and cost concerns of using the Bitcoin blockchain as a messaging layer. This, however, simply moves the privacy and cost concerns somewhere else and increases the risk of losing money due to a notification not being reliably delivered, or even censored, and makes this notification data critical for backup to recover funds.</ref>. These protocols eliminate the need for interaction, but at the expense of increased costs for one-time payments and a noticeable footprint in the blockchain, potentially revealing metadata about the sender and receiver. Notification schemes also allow the receiver to link all payments from the same sender, compromising sender privacy. + +This proposal aims to address the limitations of these current approaches by presenting a solution that eliminates the need for interaction, eliminates the need for notifications, and protects both sender and receiver privacy. These benefits come at the cost of requiring wallets to scan the blockchain in order to detect payments. This added requirement is generally feasible for full nodes but poses a challenge for light clients. While it is possible today to implement a privacy-preserving light client at the cost of increased bandwidth, light client support is considered an area of open research (see [[#appendix-a-light-client-support|Appendix A: Light Client Support]]). + +The design keeps collaborative transactions such as CoinJoins and inputs with MuSig and FROST keys in mind, but it is recommended that the keys of all inputs of a transaction belong to the same entity as there is no formal proof that the protocol is secure in a collaborative setting. + +== Goals == + +We aim to present a protocol which satisfies the following properties: + +* No increase in the size or cost of transactions +* Resulting transactions blend in with other bitcoin transactions and can't be distinguished +* Transactions can't be linked to a silent payment address by an outside observer +* No sender-receiver interaction required +* No linking of multiple payments to the same sender +* Each silent payment goes to a unique address, avoiding accidental address reuse +* Supports payment labeling +* Uses existing seed phrase or descriptor methods for backup and recovery +* Separates scanning and spending responsibilities +* Compatible with other spending protocols, such as CoinJoin +* Light client/SPV wallet support +* Protocol is upgradeable + +== Overview == + +We first present an informal overview of the protocol. In what follows, uppercase letters represent public keys, lowercase letters represent private keys, ''||'' refers to byte concatenation, ''·'' refers to elliptic curve scalar multiplication, ''G'' represents the generator point for secp256k1, and ''n'' represents the curve order for secp256k1. Each section of the overview is incomplete on its own and is meant to build on the previous section in order to introduce and briefly explain each aspect of the protocol. For the full protocol specification, see [[#specification|Specification]]. + +''' Simple case ''' + +Bob publishes a public key ''B'' as a silent payment address. Alice discovers Bob's silent payment address, selects a UTXO with private key ''a'', public key ''A'' and creates a destination output ''P'' for Bob in the following manner: + +* Let ''P = B + hash(a·B)·G'' +* Encode ''P'' as a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output + +Since ''a·B == b·A'' ([https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman Elliptic-curve Diffie–Hellman]), Bob scans with his private key ''b'' by collecting the input public keys for each transaction with at least one unspent taproot output and performing the ECDH calculation until ''P'' is found (i.e. calculating ''P = B + hash(b·A)·G'' and seeing that ''P'' is present in the transaction outputs). + +''' Creating more than one output ''' + +In order to allow Alice to create more than one output for Bob<ref name="why_more_than_one_output">'''Why allow for more than one output?''' Allowing Alice to break her payment to Bob into multiple amounts opens up a number of privacy improving techniques for Alice, making the transaction look like a CoinJoin or better hiding the change amount by splitting both the payment and change outputs into multiple amounts. It also allows for Alice and Carol to both have their own unique output paying Bob in the event they are in a collaborative transaction and both paying Bob's silent payment address.</ref>, we include an integer in the following manner: + +* Let ''k = 0'' +* Let ''P<sub>0</sub> = B + hash(a·B || k)·G'' +* For additional outputs: +** Increment ''k'' by one (''k++'') +** Let ''P<sub>i</sub> = B + hash(a·B || k)·G'' + +Bob detects this output the same as before by searching for ''P<sub>0</sub> = B + hash(b·A || 0)·G''. Once he detects the first output, he must: + +* Check for ''P<sub>1</sub> = B + hash(b·A || 1)·G'' +* If ''P<sub>1</sub>'' is not found, stop +* If ''P<sub>1</sub>'' is found, continue to check for ''P<sub>2</sub>'' and so on until an additional output is not found + +Since Bob will only perform these subsequent checks after a transaction with at least one output paying him is found, the increase to his overall scanning requirement is negligible. It should also be noted that the order in which these outputs appear in the transaction does not affect the outcome. + +''' Preventing address reuse ''' + +If Alice were to use a different UTXO from the same public key ''A'' for a subsequent payment to Bob, she would end up deriving the same destinations ''P<sub>i</sub>''. To prevent this, Alice should include an input hash in the following manner: + +* Let ''input_hash = hash(outpoint || A)''<ref name="why_include_A">'''Why include A in the input hash calculation?''' By committing to A in input hash, this ensures that the sender cannot maliciously choose a private key ''a′'' in a subsequent transaction where ''a′ = input_hash·a / input_hash′'', which would force address reuse in the protocol.</ref> +* Let ''P<sub>0</sub> = B + hash(input_hash·a·B || 0)·G'' + +Bob must calculate the same ''input_hash'' when scanning. + +''' Using all inputs ''' + +In our simplified example we have been referring to Alice's transactions as having only one input ''A'', but in reality a Bitcoin transaction can have many inputs. Instead of requiring Alice to pick a particular input and requiring Bob to check each input separately, we can instead require Alice to perform the tweak with the sum of the input public keys<ref name="other_inputs">'''What about inputs without public keys?''' Inputs without public keys can still be spent in the transaction but are simply ignored in the silent payments protocol.</ref>. This significantly reduces Bob's scanning requirement, makes light client support more feasible<ref name="using_all_inputs">'''How does using all inputs help light clients?''' If Alice uses a random input for the tweak, Bob necessarily has to have access to and check all transaction inputs, which requires performing an ECC multiplication per input. If instead Alice performs the tweak with the sum of the input public keys, Bob only needs the summed 33 byte public key per transaction and only does one ECC multiplication per transaction. Bob can then use BIP158 block filters to determine if any of the outputs exist in a block and thus avoids downloading transactions which don't belong to him. It is still an open question as to how Bob can source the 33 bytes per transaction in a trustless manner, see [[#appendix-a-light-client-support|Appendix A: Light Client Support]] for more details.</ref>, and protects Alice's privacy in collaborative transaction protocols such as CoinJoin<ref name=""all_inputs_and_coinjoin">'''Why does using all inputs matter for CoinJoin?''' If Alice uses a random input to create the output for Bob, this necessarily reveals to Bob which input Alice has control of. If Alice is paying Bob as part of a CoinJoin, this would reveal which input belongs to her, degrading the anonymity set of the CoinJoin and giving Bob more information about Alice. If instead all inputs are used, Bob has no way of knowing which input(s) belong to Alice. This comes at the cost of increased complexity as the CoinJoin participants now need to coordinate to create the silent payment output and would need to use [https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 Blind Diffie–Hellman] to prevent the other participants from learning who Alice is paying. Note it is currently not recommended to use this protocol for CoinJoins due to a lack of a formal security proof.</ref>. + +Alice performs the tweak with the sum of her input private keys in the following manner: + +* Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>'' +* Let ''input_hash = hash(outpoint<sub>L</sub> || A)'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically<ref name="why_smallest_outpoint">'''Why use the lexicographically smallest outpoint for the hash?''' Recall that the purpose of including the input hash is so that the sender and receiver can both come up with a deterministic nonce that ensures that a unique address is generated each time, even when reusing the same scriptPubKey as an input. Choosing the smallest outpoint lexicographically satisifes this requirement, while also ensuring that the generated output is not dependent on the final ordering of inputs in the transaction. Using a single outpoint also works well with memory constrained devices (such as hardware signing devices) as it does not require the device to have the entire transaction in memory in order to generate the silent payment output.</ref> +* Let ''a = a<sub>1</sub> + a<sub>2</sub> + ... + a<sub>n</sub>'' +* Let ''P<sub>0</sub> = B + hash(input_hash·a·B || 0)·G'' + +''' Spend and Scan Key ''' + +Since Bob needs his private key ''b'' to check for incoming payments, this requires ''b'' to be exposed to an online device. To minimize the risks involved, Bob can instead publish an address of the form ''(B<sub>scan</sub>, B<sub>spend</sub>)''. This allows Bob to keep ''b<sub>spend</sub>'' in offline cold storage and perform the scanning with the public key ''B<sub>spend</sub>'' and private key ''b<sub>scan</sub>''. Alice performs the tweak using both of Bob's public keys in the following manner: + +* Let ''P<sub>0</sub> = B<sub>spend</sub> + hash(input_hash·a·B<sub>scan</sub> || 0)·G'' + +Bob detects this payment by calculating ''P<sub>0</sub> = B<sub>spend</sub> + hash(input_hash·b<sub>scan</sub>·A || 0)·G'' with his online device and can spend from his cold storage signing device using ''(b<sub>spend</sub> + hash(input_hash·b<sub>scan</sub>·A || 0)) mod n'' as the private key. + +''' Labels ''' + +For a single silent payment address of the form ''(B<sub>scan</sub>, B<sub>spend</sub>)'', Bob may wish to differentiate incoming payments. Naively, Bob could publish multiple silent payment addresses, but this would require him to scan for each one, which becomes prohibitively expensive. Instead, Bob can label his spend public key ''B<sub>spend</sub>'' with an integer ''m'' in the following way: + +* Let ''B<sub>m</sub> = B<sub>spend</sub> + hash(b<sub>scan</sub> || m)·G'' where m is an incrementable integer starting from 1 +* Publish ''(B<sub>scan</sub>, B<sub>1</sub>)'', ''(B<sub>scan</sub>, B<sub>2</sub>)'' etc. + +Alice performs the tweak as before using one of the published ''(B<sub>scan</sub>, B<sub>m</sub>)'' pairs. Bob detects the labeled payment in the following manner: + +* Let ''P<sub>0</sub> = B<sub>spend</sub> + hash(input_hash·b<sub>scan</sub>·A || 0)·G'' +* Subtract ''P<sub>0</sub>'' from each of the transaction outputs and check if the remainder matches any of the labels (''hash(b<sub>scan</sub> || 1)·G'', ''hash(b<sub>scan</sub> || 2)·G'' etc.) that the wallet has previously used + +It is important to note that an outside observer can easily deduce that each published ''(B<sub>scan</sub>, B<sub>m</sub>)'' pair is owned by the same entity as each published address will have ''B<sub>scan</sub>'' in common. As such, labels are not meant as a way for Bob to manage separate identities, but rather a way for Bob to determine the source of an incoming payment. + +''' Labels for change ''' + +Bob can also use labels for managing his own change outputs. We reserve ''m = 0'' for this use case. This gives Bob an alternative to using BIP32 for managing change, while still allowing him to know which of his unspent outputs were change when recovering his wallet from the master key. It is important that the wallet never hands out the label with ''m = 0'' in order to ensure nobody else can create payments that are wrongly labeled as change. + +While the use of labels is optional, every receiving silent payments wallet should at least scan for the change label when recovering from backup in order to ensure maximum cross-compatibility. + +== Specification == + +We use the following functions and conventions: + +* ''outpoint'' (36 bytes): the <code>COutPoint</code> of an input (32-byte txid, least significant byte first || 4-byte vout, least significant byte first)<ref name="why_little_endian">'''Why are outpoints little-endian?''' Despite using big endian throughout the rest of the BIP, outpoints are sorted and hashed matching their transaction serialization, which is little-endian. This allows a wallet to parse a serialized transaction for use in silent payments without needing to re-order the bytes when computing the input hash. Note: despite outpoints being stored and serialized as little-endian, the transaction hash (txid) is always displayed as big-endian.</ref> +* ser<sub>32</sub>(i): serializes a 32-bit unsigned integer ''i'' as a 4-byte sequence, most significant byte first. +* ser<sub>256</sub>(p): serializes the integer p as a 32-byte sequence, most significant byte first. +* ser<sub>P</sub>(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1's compressed form: (0x02 or 0x03) || ser<sub>256</sub>(x), where the header byte depends on the parity of the omitted Y coordinate. + +For everything not defined above, we use the notation from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#specification BIP340]. This includes the ''hash<sub>tag</sub>(x)'' notation to refer to ''SHA256(SHA256(tag) || SHA256(tag) || x)''. + +=== Versions === + +This document defines version 0 (''sp1q''). Version is communicated through the address in the same way as bech32 addresses (see [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP173]. Future upgrades to silent payments will require a new version. As much as possible, future upgrades should support receiving from older wallets (e.g. a silent payments v0 wallet can send to both v0 and v1 addresses). Any changes that break compatibility with older silent payment versions should be a new BIP. + +Future silent payments versions will use the following scheme: + +{| class="wikitable" +|- +! +!0 +!1 +!2 +!3 +!4 +!5 +!6 +!7 +!Compatibility +|- +!+0 +|q||p||z||r||y||9||x||8||rowspan="4" | backwards compatible +|- +!+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|| - +|} + +''v31'' (l) is reserved for a backwards incompatible change, if needed. For silent payments v0: + +* If the receiver's silent payment address version is: +** ''v0'': check that the data part is exactly 66-bytes. Otherwise, fail +** ''v1'' through ''v30'': read the first 66-bytes of the data part and discard the remaining bytes +** ''v31'': fail +* Receiver addresses are always [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot outputs<ref name="why_taproot">'''Why only taproot outputs?''' Providing too much optionality for the protocol makes it difficult to implement and can be at odds with the goal of providing the best privacy. Limiting to taproot outputs helps simplify the implementation significantly while also putting users in the best eventual anonymity set.</ref> +* The sender should sign with one of the sighash flags ''DEFAULT'', ''ALL'', ''SINGLE'', ''NONE'' (''ANYONECANPAY'' is unsafe). It is strongly recommended implementations use ''SIGHASH_ALL'' (''SIGHASH_DEFAULT'' for taproot inputs) when possible<ref name="why_not_sighash_anyonecanpay">'''Why is it unsafe to use ''SIGHASH_ANYONECANPAY''?''' Since the output address for the receiver is derived from the sum of the [[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]] public keys, the inputs must not change once the sender has signed the transaction. If the inputs are allowed to change after the fact, the receiver will not be able to calculate the shared secret needed to find and spend the output. It is currently an open question on how a future version of silent payments could be made to work with new sighash flags such as ''SIGHASH_GROUP'' and ''SIGHASH_ANYPREVOUT''.</ref> +* Inputs used to derive the shared secret are from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list + +=== Scanning silent payment eligible transactions === + +For silent payments v0 a transaction MUST be scanned if and only if all of the following are true: + +* The transaction contains at least one BIP341 taproot output (note: spent transactions optionally can be skipped by only considering transactions with at least one unspent taproot output) +* The transaction has at least one input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list +* The transaction does not spend an output with SegWit version > 1<ref name="skip_txs_with_unknown_prevouts">'''Why skip transactions that spend SegWit version > 1?''' Skipping transactions that spend unknown output scripts allows us to have a clean upgrade path for silent payments by avoiding the need to scan the same transaction multiple times with different rule sets. If a new SegWit version is added in the future and silent payments v1 is released with support, we would want to avoid having to first scan the transaction with the silent payment v0 rules and then again with the silent payment v1 rules. Note: this restriction only applies to the inputs of a transaction.</ref> + +=== Address encoding === + +A silent payment address is constructed in the following manner: + +* Let ''B<sub>scan</sub>, b<sub>scan</sub> = Receiver's scan public key and corresponding private key'' +* Let ''B<sub>spend</sub>, b<sub>spend</sub> = Receiver's spend public key and corresponding private key'' +* Let ''B<sub>m</sub> = B<sub>spend</sub> + hash<sub>BIP0352/Label</sub>(ser<sub>256</sub>(b<sub>scan</sub>) || ser<sub>32</sub>(m))·G'', where ''hash<sub>BIP0352/Label</sub>(ser<sub>256</sub>(b<sub>scan</sub>) || ser<sub>32</sub>(m))·G'' is an optional integer tweak for labeling +** If no label is applied then ''B<sub>m</sub> = B<sub>spend</sub>'' +* The final address is a [https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki Bech32m] encoding of: +** The human-readable part "sp" for mainnet, "tsp" for testnets (e.g. signet, testnet) +** The data-part values: +*** The character "q", to represent a silent payment address of version 0 +*** The 66-byte concatenation of the receiver's public keys, ''ser<sub>P</sub>(B<sub>scan</sub>) || ser<sub>P</sub>(B<sub>m</sub>)'' + +Note: [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP173] imposes a 90 character limit for Bech32 segwit addresses and limits versions to 0 through 16, whereas a silent payment address requires ''at least'' 117 characters<ref name="why_117_chars"> ''' Why do silent payment addresses need at least 117 characters?''' A silent payment address is a bech32m encoding comprised of the following parts: + + +* HRP [2-3 characters] +* separator [1 character] +* version [1-2 characters] +* payload, 66 bytes concatenated pubkeys [ceil(66*8/5) = 106 characters] +* checksum [6 characters] + + +For a silent payments v0 address, this results in a 117-character address when using a 3-character HRP. Future versions of silent payment addresses may add to the payload, which is why a 1023-character limit is suggested.</ref> and allows versions up to 31. Additionally, since higher versions may add to the data field, it is recommended implementations use a limit of 1023 characters (see [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#checksum-design BIP173: Checksum design] for more details). + +=== Inputs For Shared Secret Derivation === + +While any UTXO with known output scripts can be used to fund the transaction, the sender and receiver MUST use inputs from the following list when deriving the shared secret: + +* ''P2TR'' +* ''P2WPKH'' +* ''P2SH-P2WPKH'' +* ''P2PKH'' + +Inputs with conditional branches or multiple public keys (e.g. ''CHECKMULTISIG'') are excluded from shared secret derivation as this introduces malleability and would allow a sender to re-sign with a different set of public keys after the silent payment output has been derived. This is not a concern when the sender controls all of the inputs, but is an issue for CoinJoins and other collaborative protocols, where a malicious participant can participate in deriving the silent payment address with one set of keys and then re-broadcast the transaction with signatures for a different set of public keys. P2TR can have hidden conditional branches (script path), but we work around this by using only the output public key. + +For all of the output types listed, only X-only and compressed public keys are permitted<ref name="why_only_compressed_public_keys">''' Why only compressed public keys ''' Uncompressed and hybrid public keys are less common than compressed keys and generally considered to be a bad idea due to their blockspace inefficiency. Additionally, [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#restrictions-on-public-key-type BIP143] recommends restricting P2WPKH inputs to compressed keys as a default policy.</ref>. + +''' P2TR ''' + +'' Keypath spend '' + + witness: <signature> + scriptSig: (empty) + scriptPubKey: 1 <32-byte-x-only-key> + (0x5120{32-byte-x-only-key}) + +The sender uses the private key corresponding to the taproot output key (i.e. the tweaked private key). This can be a single private key or an aggregate key (e.g. taproot outputs using MuSig or FROST)<ref name="musig_frost_support">'''Are key aggregation techniques like FROST and MuSig supported?''' While we do not recommend it due to lack of a security proof (except if all participants are trusted or are the same entity), any taproot output able to do a key path theoretically is supported. Any offline key aggregation technique can be used, such as FROST or MuSig. This would require participants to perform the ECDH step collaboratively e.g. ''ECDH = a<sub>1</sub>·B<sub>scan</sub> + a<sub>2</sub>·B<sub>scan</sub> + ... + a<sub>t</sub>·B<sub>scan</sub>'' and ''P = B<sub>spend</sub> + hash(input_hash·ECDH || 0)·G''. Additionally, it may be necessary for the participants to provide a DLEQ proof to ensure they are not acting maliciously.</ref>. The receiver obtains the public key from the ''scriptPubKey'' (i.e. the taproot output key). + +'' Script path spend '' + + witness: <optional witness items> <leaf script> <control block> + scriptSig: (empty) + scriptPubKey: 1 <32-byte-x-only-key> + (0x5120{32-byte-x-only-key}) + +Same as a keypath spend, the sender MUST use the private key corresponding to the taproot output key. If this key is not available, the output cannot be included as an input to the transaction. Same as a keypath spend, the receiver obtains the public key from the ''scriptPubKey'' (i.e. the taproot output key)<ref name="why_always_output_pubkey">''' Why not skip all taproot script path spends? ''' This causes malleability issues for CoinJoins. If the silent payments protocol skipped taproot script path spends, this would allow an attacker to join a CoinJoin round, participate in deriving the silent payment address using the tweaked private key for a key path spend, and then broadcast their own version of the transaction using the script path spend. If the receiver were to only consider key path spends, they would skip the attacker's script path spend input when deriving the shared secret and not be able to find the funds. Additionally, there may be scenarios where the sender can perform ECDH with the key path private key but spends the output using the script path.</ref>. + +The one exception is script path spends that use NUMS point ''H'' as their internal key (where ''H'' is constructed by taking the hash of the standard uncompressed encoding of the secp256k1 base point ''G'' as X coordinate, see [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#constructing-and-spending-taproot-outputs BIP341: Constructing and spending Taproot outputs] for more details), in which case the input will be skipped for the purposes of shared secret derivation<ref name="why_ignore_h">'''Why skip outputs with H as the internal taproot key?''' If use cases get popularized where the taproot key path cannot be used, these outputs can still be included without getting in the way of making a silent payment, provided they specifically use H as their internal taproot key.</ref>. The receiver determines whether or not to skip the input by checking in the control block if the taproot internal key is equal to ''H''. + +''' P2WPKH ''' + + witness: <signature> <33-byte-compressed-key> + scriptSig: (empty) + scriptPubKey: 0 <20-byte-key-hash> + (0x0014{20-byte-key-hash}) + +The sender performs the tweak using the private key for the output and the receiver obtains the public key as the last witness item. + +''' P2SH-P2WPKH ''' + + witness: <signature> <33-byte-compressed-key> + scriptSig: <0 <20-byte-key-hash>> + (0x160014{20-byte-key-hash}) + scriptPubKey: HASH160 <20-byte-script-hash> EQUAL + (0xA914{20-byte-script-hash}87) + +The sender performs the tweak using the private key for the nested ''P2WPKH'' output and the receiver obtains the public key as the last witness item. + +''' P2PKH ''' + + scriptSig: <signature> <33-byte-compressed-key> + scriptPubKey: OP_DUP HASH160 <20-byte-key-hash> OP_EQUALVERIFY OP_CHECKSIG + (0x76A914{20-byte-key-hash}88AC) + +The receiver obtains the public key from the ''scriptSig''. The receiver MUST parse the ''scriptSig'' for the public key, even if the ''scriptSig'' does not match the template specified (e.g. <code><dummy> OP_DROP <Signature> <Public Key></code>). This is to address the [https://en.bitcoin.it/wiki/Transaction_malleability third-party malleability of ''P2PKH'' ''scriptSigs'']. + +=== Input hash === + +The sender and receiver MUST calculate an input hash for the transaction in the following manner: + +* Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>'', where each ''A<sub>i</sub>'' is the public key of an input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list<ref name="why_include_A"></ref> +* Let ''input_hash = hash<sub>BIP0352/Inputs</sub>(outpoint<sub>L</sub> || A)'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically by txid and vout used in the transaction<ref name="why_smallest_outpoint"></ref> + +=== Sender === + +==== Selecting inputs ==== + +The sending wallet performs coin selection as usual with the following restrictions: + +* At least one input MUST be from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list +* Exclude inputs with SegWit version > 1 (see ''[[#scanning-silent-payment-eligible-transactions|Scanning silent payment eligible transactions]]'') +* For each taproot output spent the sending wallet MUST have access to the private key corresponding to the taproot output key, unless ''H'' is used as the internal public key + +==== Creating outputs ==== + +After the inputs have been selected, the sender can create one or more outputs for one or more silent payment addresses in the following manner: + +* Generate the ''input_hash'' with the smallest outpoint lexicographically, using the method described above +* Collect the private keys for each input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list +* For each private key ''a<sub>i</sub>'' corresponding to a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output, check that the private key produces a point with an even Y coordinate and negate the private key if not<ref name="why_negate_taproot_private_keys">'''Why do taproot private keys need to be checked?''' Recall from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] that each X-only public key has two corresponding private keys, ''d'' and ''n - d''. To maintain parity between sender and receiver, it is necessary to use the private key corresponding to the even Y coordinate when performing the ECDH step since the receiver will assume the even Y coordinate when summing the taproot X-only public keys.</ref> +* Let ''a = a<sub>1</sub> + a<sub>2</sub> + ... + a<sub>n</sub>'', where each ''a<sub>i</sub>'' has been negated if necessary +* Group receiver silent payment addresses by ''B<sub>scan</sub>'' (e.g. each group consists of one ''B<sub>scan</sub>'' and one or more ''B<sub>m</sub>'') +* For each group: +** Let ''ecdh_shared_secret = input_hash·a·B<sub>scan</sub>'' +** Let ''k = 0'' +** For each ''B<sub>m</sub>'' in the group: +*** Let ''t<sub>k</sub> = hash<sub>BIP0352/SharedSecret</sub>(ser<sub>P</sub>(ecdh_shared_secret) || ser<sub>32</sub>(k))'' +**** If ''t<sub>k</sub>'' is not valid tweak, i.e., if ''t<sub>k</sub> = 0'' or ''t<sub>k</sub>'' is larger or equal to the secp256k1 group order, fail +*** Let ''P<sub>mn</sub> = B<sub>m</sub> + t<sub>k</sub>·G'' +*** Encode ''P<sub>mn</sub>'' as a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output +*** Optionally, repeat with k++ to create additional outputs for the current ''B<sub>m</sub>'' +*** If no additional outputs are required, continue to the next ''B<sub>m</sub>'' with ''k++''<ref name="why_not_the_same_tn">''' Why not re-use ''t<sub>k</sub>'' when paying different labels to the same receiver?''' If paying the same entity but to two separate labeled addresses in the same transaction without incrementing ''k'', an outside observer could subtract the two output values and observe that this value is the same as the difference between two published silent payment addresses and learn who the recipient is.</ref> +** Optionally, if the sending wallet implements receiving silent payments, it can create change outputs by sending to its own silent payment address using label ''m = 0'', following the steps above + +=== Receiver === + +==== Key Derivation ==== + +Two keys are needed to create a silent payments address: the spend key and the scan key. To ensure compatibility, wallets MAY use BIP32 derivation with the following derivation paths for the spend and scan key. When using BIP32 derivation, wallet software MUST use hardened derivation<ref name="bip32_derivation">'''Why use BIP32 hardened derivation?''' Using BIP32 derivation allows users to add silent payments to an existing master seed. It also ensures that a user's silent payment funds are recoverable in any BIP32/BIP43 compatible wallet. Using hardened derivation ensures that it is safe to export the scan private key without exposing the master key or spend private key.</ref> for both the spend and scan key. + +A scan and spend key pair using BIP32 derivation are defined (taking inspiration from [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP44]) in the following manner: + + scan_private_key: m / purpose' / coin_type' / account' / 1' / 0 + spend_private_key: m / purpose' / coin_type' / account' / 0' / 0 + +<code>purpose</code> is a constant set to ''352'' following the BIP43 recommendation. Refer to [https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki BIP43] and [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP44] for more details. + +==== Scanning ==== + +If each of the checks in ''[[#scanning-silent-payment-eligible-transactions|Scanning silent payment eligible transactions]]'' passes, the receiving wallet must: + +* Generate the ''input_hash'' with the smallest outpoint lexicographically, using the method described above +* Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>'', where each ''A<sub>i</sub>'' is the public key of an input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list +* Let ''ecdh_shared_secret = input_hash·b<sub>scan</sub>·A'' +* Check for outputs: +** Let ''outputs_to_check'' be the taproot output keys from all taproot outputs in the transaction (spent and unspent). +** Starting with ''k = 0'': +*** Let ''t<sub>k</sub> = hash<sub>BIP0352/SharedSecret</sub>(ser<sub>P</sub>(ecdh_shared_secret) || ser<sub>32</sub>(k))'' +**** If ''t<sub>k</sub>'' is not valid tweak, i.e., if ''t<sub>k</sub> = 0'' or ''t<sub>k</sub>'' is larger or equal to the secp256k1 group order, fail +*** Compute ''P<sub>k</sub> = B<sub>spend</sub> + t<sub>k</sub>·G'' +*** For each ''output'' in ''outputs_to_check'': +**** If ''P<sub>k</sub>'' equals ''output'': +***** Add ''P<sub>k</sub>'' to the wallet +***** Remove ''output'' from ''outputs_to_check'' and rescan ''outputs_to_check'' with ''k++'' +**** Else, check for labels (always check for the change label, i.e. ''hash<sub>BIP0352/Label</sub>(ser<sub>256</sub>(b<sub>scan</sub>) || ser<sub>32</sub>(m))'' where ''m = 0'')<ref name="precompute_labels">''' Why precompute labels?''' Precomputing the labels is not strictly necessary: a wallet could track the max number of labels it has used (call it ''M'') and scan for labels by adding ''hash(b<sub>scan</sub> || m)·G'' to ''P<sub>0</sub>'' for each label ''m'' up to ''M'' and comparing to the transaction outputs. This is more performant than precomputing the labels and checking via subtraction in cases where the number of eligible outputs exceeds the number of labels in use. In practice this will mainly apply to users that choose never to use labels, or users that use a single label for generating silent payment change outputs. If using a large number of labels, the wallet would need to add all possible labels to each output. This ends up being ''n·M'' additions, where ''n'' is the number of outputs in the transaction and ''M'' is the number of labels in the wallet. By precomputing the labels, the wallet only needs to compute ''hash(b<sub>scan</sub> || m)·G'' once when creating the labeled address and can determine if a label was used via a lookup, rather than adding each label to each output.</ref>: +***** Compute ''label = output - P<sub>k</sub>'' +***** Check if ''label'' exists in the list of labels used by the wallet +***** If a match is found: +****** Add ''P<sub>k</sub> + label'' to the wallet +****** Remove ''output'' from ''outputs_to_check'' and rescan ''outputs_to_check'' with ''k++'' +***** If a label is not found, negate ''output'' and check a second time<ref name="negate_output">''' Why negate the output?''' Unfortunately taproot outputs are X-only, meaning we don't know what the correct Y coordinate is. This causes this specific calculation to fail 50% of the time, so we need to repeat it with the other Y coordinate by negating the output.</ref> +*** If no matches are found, stop + +==== Spending ==== + +Recall that a silent payment output is of the form ''B<sub>spend</sub> + t<sub>k</sub>·G + hash<sub>BIP0352/Label</sub>(ser<sub>256</sub>(b<sub>scan</sub>) || ser<sub>32</sub>(m))·G'', where ''hash<sub>BIP0352/Label</sub>(ser<sub>256</sub>(b<sub>scan</sub>) || ser<sub>32</sub>(m))·G'' is an optional label. To spend a silent payment output: + +* Let ''d = (b<sub>spend</sub> + t<sub>k</sub> + hash<sub>BIP0352/Label</sub>(ser<sub>256</sub>(b<sub>scan</sub>) || ser<sub>32</sub>(m))) mod n'', where ''hash<sub>BIP0352/Label</sub>(ser<sub>256</sub>(b<sub>scan</sub>) || ser<sub>32</sub>(m))'' is the optional label +* Spend the [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] output with the private key ''d'' + +==== Backup and Recovery ==== + +Since each silent payment output address is derived independently, regular backups are recommended. When recovering from a backup, the wallet will need to scan since the last backup to detect new payments. + +If using a seed/seed phrase only style backup, the user can recover the wallet's unspent outputs from the UTXO set (i.e. only scanning transactions with at least one unspent taproot output) and can recover the full wallet history by scanning the blockchain starting from the wallet birthday. If a wallet uses labels, this information SHOULD be included in the backup. If the user does not know whether labels were used, it is strongly recommended they always precompute and check a large number of labels (e.g. 100k labels) to use when re-scanning. This ensures that the wallet can recover all funds from only a seed/seed phrase backup. The change label should simply always be scanned for, even when no other labels were used. This ensures the use of a change label is not critical for backups and maximizes cross-compatibility. + +== Backward Compatibility == + +Silent payments introduces a new address format and protocol for sending and as such is not compatible with older wallet software or wallets which have not implemented the silent payments protocol. + +== Test Vectors == + +A [[bip-0352/send_and_receive_test_vectors.json|collection of test vectors in JSON format]] are provided, along with a [[bip-0352/reference.py|python reference implementation]]. Each test vector consists of a sending test case and corresponding receiving test case. This is to allow sending and receiving to be implemented separately. To ensure determinism while testing, sort the array of ''B<sub>m</sub>'' by amount (see the [[bip-0352/reference.py|reference implementation]]). Test cases use the following schema: + +''' test_case ''' + + { + "comment": "Comment describing the behavior being tested", + "sending": [<array of sender test objects>], + "receiving": [<array of recipient test objects>], + } + +''' sender ''' + + { + "given": { + "vin": [<array of vin objects with an added field for the private key. These objects are structured to match the `vin` output field from `getrawtransaction verbosity=2`>], + "recipients": [<array of strings, where each string is a bech32m encoding representing a silent payment address>] + }, + "expected": { + "outputs": [<array of strings, where each string is a hex encoding of 32-byte X-only public key; contains all possible output sets, test must match a subset of size `n_outputs`>], + "n_outputs": <integer for the exact number of expected outputs>, + }, + } + +''' recipient ''' + + { + "given": { + "vin": [<array of vin objects. These objects are structured to match the `vin` output field from `getrawtransaction verbosity=2`>], + "key_material": { + "scan_priv_key": <hex encoded scan private key>, + "spend_priv_key": <hex encoded spend private key>, + } + "labels": [<array of ints, representing labels the receiver has used>], + }, + "expected": { + "addresses": [<array of bech32m strings, one for the silent payment address and each labeled address (if used)>], + "outputs": [<array of outputs with tweak and signature; contains all possible output sets, tester must match a subset of size `n_outputs`> + { + "priv_key_tweak": <hex encoded private key tweak data>, + "pub_key": <hex encoded X-only public key>, + "signature": <hex encoded signature for the output (produced with spend_priv_key + priv_key_tweak)> + }, + ... + ], + "n_outputs": <integer for the exact number of expected outputs> + } + } + +Wallets should include inputs not in the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list when testing to ensure that only inputs from the list are being used for shared secret derivation. Additionally, receiving wallets should include non-silent payment outputs for themselves in testing to ensure silent payments scanning does not interfere with regular outputs detection. + +=== Functional tests === + +Below is a list of functional tests which should be included in sending and receiving implementations. + +==== Sending ==== + +* Ensure taproot outputs are excluded during coin selection if the sender does not have access to the key path private key (unless using ''H'' as the taproot internal key) +* Ensure the silent payment address is re-derived if inputs are added or removed during RBF + +==== Receiving ==== + +* Ensure the public key can be extracted from non-standard ''P2PKH'' scriptSigs +* Ensure taproot script path spends are included, using the taproot output key (unless ''H'' is used as the taproot internal key) +* Ensure the scanner can extract the public key from each of the input types supported (e.g. ''P2WPKH'', ''P2SH-P2WPKH'', etc.) + +== Appendix A: Light Client Support == + +This section proposes a few ideas for how light clients could support scanning for incoming silent payments (sending is fairly straightforward) in ways that preserve bandwidth and privacy. While this is out of scope for the current BIP, it is included to motivate further research into this topic. In this context, a light client refers to any bitcoin wallet client which does not process blocks and does not have a direct connection to a node which does process blocks (e.g. a full node). Based on this definition, clients that directly connect to a personal electrum server or a bitcoin node are not light clients. + +This distinction makes the problem for light clients more clear: light clients need a way to source the necessary data for performing the tweaks and a way of determining if any of the generated outputs exist in a block. + +=== Tweak Data === + +Recall that a silent payment eligible transaction follows [[#scanning-silent-payment-eligible-transactions|certain conditions]] and should have at least one unspent taproot output. Full nodes (or any index server backed by a full node, such as electrum server) can build an index which collects all of the eligible public keys for a silent payments eligible transaction, sums them up, multiplies the sum by the ''input_hash'', and serves them to clients. This would be 33 bytes per silent payment eligible transaction. + +For a typical bitcoin block of ~3500 txs, lets assume every transaction is a silent payments eligible transaction. This means a client would need to request ''33 bytes * 3500'' of data per block (roughly 100 kB per block). If a client were to request data for every block, this would amount to ~450 MB per month, assuming 100% taproot usage and all outputs remain unspent for > 1 month. As of today, these numbers are closer to 2–10 kB per block (10–50 MB per month)<ref name="appendix_data">''' Data for Appendix A ''' These numbers are based on data from January 2023 until June 2023 (the last 6 months of data at time time of writing). See [https://github.com/josibake/bitcoin-data-analysis/blob/main/notebooks/silent-payments-light-client-data.ipynb Silent payments light client data] for the full analysis.</ref>. + +=== Transaction cut-through === + +It is unlikely a light client would need to scan every block and as such can take advantage of transaction cut-through, depending on how often they choose to scan for new blocks. Empirically, ~75% of transactions with at least one unspent taproot output will have spent all taproot UTXOs in 326 blocks or less<ref name="appendix_data"></ref>. This means a client which only scans once every 3 days could ''significantly'' cut down on the number of blocks and the number of transactions per block that they need to request by only asking for data on transactions that were created since their last scan and that still have at least one unspent taproot output as of the current block height. Assuming 100% taproot usage, a client that scans once a month would likely only need around 50 MB worth of data. Based on current taproot adoption, a light client scanning once every 3 days would use roughly 15 MB per month and a client scanning once per month would use less than 5 MB per month. + +[[File:bip-0352/scan_data_downloader_per_month.png]] + +=== BIP158 === + +Once a light client has the tweak data for a block, they can determine whether or not an output to them exists in the block using BIP158 block filters. Per BIP158, they would then request the entire block and add the transaction to their wallet, though it maybe be possible to only request the prevout txids and vouts for all transactions with at least one taproot output, along with the scriptPubKeys and amounts. This would allow the client to download the necessary data for constructing a spending transaction, without downloading the entire block. How this affects the security assumptions of BIP158 is an open question. + +=== Out-of-band notifications === + +Assuming a secure messaging protocol exists, the sender can send an encrypted (using the scan public key of the silent payment address) notification to the receiver with the following information: +* The spend public key (communicates the label) +* The shared secret portion of the private key (i.e ''hash(ecdh_shared_secret || k)'') +* The outpoint and amount (so it's immediately spendable) + +It is important to note that these notifications are not required. At any point, the receiver can fall back to scanning for silent payment transactions if they don't trust the notifications they are receiving, are being spammed with fake notifications, or if they are concerned that they are not receiving notifications. + +A malicious notification could potentially cause the following issues: + +* You did not actually receive money to the stated key +** This can be probabilistically resolved by matching the key against the BIP158 block filters and assuming it's not a false positive, or fully resolved by downloading the block +* You received money but the outpoint or amount is incorrect, so attempts to spend it will fail or cause you to overpay fees +** There doesn't seem to be much motivation for malicious senders to ever do this, but light clients need to take into account that this can occur and should ideally check for it by downloading the block +* The private key is correct but it wasn't actually derived using the silent payment protocol, causing recovery from back-up to fail (unsafe - no implementation should ever allow this) +** This can be detected by downloading the tweak data of the corresponding block and should be resolved by immediately spending the output + +Wallet designers can choose which tradeoffs they find appropriate. For example, a wallet could check the block filter to at least probabilistically confirm the likely existence of the UTXO, thus efficiently cutting down on spam. The payment could then be marked as unconfirmed until a scan is performed and the existence of the UTXO in accordance to the silent payment specification is verified. + + +== Acknowledgements == + +This document is the result of many discussions and contains contributions by a number of people. The authors wish to thank all those who provided valuable feedback and reviews, including the participants of the [https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae BIP47 Prague discussion], the [https://github.com/josibake/silent-payments-workshop Advancing Bitcoin silent payments Workshop], and [https://btctranscripts.com/bitcoin-core-dev-tech/2023-04/2023-04-26-silent-payments/ coredev]. The authors would like to also thank [https://github.com/w0xlt w0xlt] for writing the initial implementation of silent payments. + +== Rationale and References == +<references/> + diff --git a/bip-0352/bech32m.py b/bip-0352/bech32m.py new file mode 100644 index 0000000..795e153 --- /dev/null +++ b/bip-0352/bech32m.py @@ -0,0 +1,135 @@ +# Copyright (c) 2017, 2020 Pieter Wuille +# +# Permission is hereby granted, free of charge, to any person obtaining a copy +# of this software and associated documentation files (the "Software"), to deal +# in the Software without restriction, including without limitation the rights +# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +# copies of the Software, and to permit persons to whom the Software is +# furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice shall be included in +# all copies or substantial portions of the Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN +# THE SOFTWARE. + +"""Reference implementation for Bech32/Bech32m and segwit addresses.""" + + +from enum import Enum + +class Encoding(Enum): + """Enumeration type to list the various supported encodings.""" + BECH32 = 1 + BECH32M = 2 + +CHARSET = "qpzry9x8gf2tvdw0s3jn54khce6mua7l" +BECH32M_CONST = 0x2bc830a3 + +def bech32_polymod(values): + """Internal function that computes the Bech32 checksum.""" + generator = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3] + chk = 1 + for value in values: + top = chk >> 25 + chk = (chk & 0x1ffffff) << 5 ^ value + for i in range(5): + chk ^= generator[i] if ((top >> i) & 1) else 0 + return chk + + +def bech32_hrp_expand(hrp): + """Expand the HRP into values for checksum computation.""" + return [ord(x) >> 5 for x in hrp] + [0] + [ord(x) & 31 for x in hrp] + + +def bech32_verify_checksum(hrp, data): + """Verify a checksum given HRP and converted data characters.""" + const = bech32_polymod(bech32_hrp_expand(hrp) + data) + if const == 1: + return Encoding.BECH32 + if const == BECH32M_CONST: + return Encoding.BECH32M + return None + +def bech32_create_checksum(hrp, data, spec): + """Compute the checksum values given HRP and data.""" + values = bech32_hrp_expand(hrp) + data + const = BECH32M_CONST if spec == Encoding.BECH32M else 1 + polymod = bech32_polymod(values + [0, 0, 0, 0, 0, 0]) ^ const + return [(polymod >> 5 * (5 - i)) & 31 for i in range(6)] + + +def bech32_encode(hrp, data, spec): + """Compute a Bech32 string given HRP and data values.""" + combined = data + bech32_create_checksum(hrp, data, spec) + return hrp + '1' + ''.join([CHARSET[d] for d in combined]) + +def bech32_decode(bech): + """Validate a Bech32/Bech32m string, and determine HRP and data.""" + if ((any(ord(x) < 33 or ord(x) > 126 for x in bech)) or + (bech.lower() != bech and bech.upper() != bech)): + return (None, None, None) + bech = bech.lower() + pos = bech.rfind('1') + + # remove the requirement that bech32m be less than 90 chars + if pos < 1 or pos + 7 > len(bech): + return (None, None, None) + if not all(x in CHARSET for x in bech[pos+1:]): + return (None, None, None) + hrp = bech[:pos] + data = [CHARSET.find(x) for x in bech[pos+1:]] + spec = bech32_verify_checksum(hrp, data) + if spec is None: + return (None, None, None) + return (hrp, data[:-6], spec) + +def convertbits(data, frombits, tobits, pad=True): + """General power-of-2 base conversion.""" + acc = 0 + bits = 0 + ret = [] + maxv = (1 << tobits) - 1 + max_acc = (1 << (frombits + tobits - 1)) - 1 + for value in data: + if value < 0 or (value >> frombits): + return None + acc = ((acc << frombits) | value) & max_acc + bits += frombits + while bits >= tobits: + bits -= tobits + ret.append((acc >> bits) & maxv) + if pad: + if bits: + ret.append((acc << (tobits - bits)) & maxv) + elif bits >= frombits or ((acc << (tobits - bits)) & maxv): + return None + return ret + + +def decode(hrp, addr): + """Decode a segwit address.""" + hrpgot, data, spec = bech32_decode(addr) + if hrpgot != hrp: + return (None, None) + decoded = convertbits(data[1:], 5, 8, False) + if decoded is None or len(decoded) < 2: + return (None, None) + if data[0] > 16: + return (None, None) + return (data[0], decoded) + + +def encode(hrp, witver, witprog): + """Encode a segwit address.""" + spec = Encoding.BECH32 if witver == 0 else Encoding.BECH32M + ret = bech32_encode(hrp, [witver] + convertbits(witprog, 8, 5), spec) + if decode(hrp, ret) == (None, None): + return None + return ret diff --git a/bip-0352/bitcoin_utils.py b/bip-0352/bitcoin_utils.py new file mode 100644 index 0000000..443c096 --- /dev/null +++ b/bip-0352/bitcoin_utils.py @@ -0,0 +1,158 @@ +import hashlib +import struct +from io import BytesIO +from secp256k1 import ECKey +from typing import Union + + +def from_hex(hex_string): + """Deserialize from a hex string representation (e.g. from RPC)""" + return BytesIO(bytes.fromhex(hex_string)) + + +def ser_uint32(u: int) -> bytes: + return u.to_bytes(4, "big") + + +def ser_uint256(u): + return u.to_bytes(32, 'little') + + +def deser_uint256(f): + return int.from_bytes(f.read(32), 'little') + + +def deser_txid(txid: str): + # recall that txids are serialized little-endian, but displayed big-endian + # this means when converting from a human readable hex txid, we need to first + # reverse it before deserializing it + dixt = "".join(map(str.__add__, txid[-2::-2], txid[-1::-2])) + return bytes.fromhex(dixt) + + +def deser_compact_size(f: BytesIO): + view = f.getbuffer() + nbytes = view.nbytes; + view.release() + if (nbytes == 0): + return 0 # end of stream + + nit = struct.unpack("<B", f.read(1))[0] + if nit == 253: + nit = struct.unpack("<H", f.read(2))[0] + elif nit == 254: + nit = struct.unpack("<I", f.read(4))[0] + elif nit == 255: + nit = struct.unpack("<Q", f.read(8))[0] + return nit + + +def deser_string(f: BytesIO): + nit = deser_compact_size(f) + return f.read(nit) + + +def deser_string_vector(f: BytesIO): + nit = deser_compact_size(f) + r = [] + for _ in range(nit): + t = deser_string(f) + r.append(t) + return r + + +class COutPoint: + __slots__ = ("hash", "n",) + + def __init__(self, hash=b"", n=0,): + self.hash = hash + self.n = n + + def serialize(self): + r = b"" + r += self.hash + r += struct.pack("<I", self.n) + return r + + def deserialize(self, f): + self.hash = f.read(32) + self.n = struct.unpack("<I", f.read(4))[0] + + +class VinInfo: + __slots__ = ("outpoint", "scriptSig", "txinwitness", "prevout", "private_key") + + def __init__(self, outpoint=None, scriptSig=b"", txinwitness=None, prevout=b"", private_key=None): + if outpoint is None: + self.outpoint = COutPoint() + else: + self.outpoint = outpoint + if txinwitness is None: + self.txinwitness = CTxInWitness() + else: + self.txinwitness = txinwitness + if private_key is None: + self.private_key = ECKey() + else: + self.private_key = private_key + self.scriptSig = scriptSig + self.prevout = prevout + + +class CScriptWitness: + __slots__ = ("stack",) + + def __init__(self): + # stack is a vector of strings + self.stack = [] + + def is_null(self): + if self.stack: + return False + return True + + +class CTxInWitness: + __slots__ = ("scriptWitness",) + + def __init__(self): + self.scriptWitness = CScriptWitness() + + def deserialize(self, f: BytesIO): + self.scriptWitness.stack = deser_string_vector(f) + return self + + def is_null(self): + return self.scriptWitness.is_null() + + +def hash160(s: Union[bytes, bytearray]) -> bytes: + return hashlib.new("ripemd160", hashlib.sha256(s).digest()).digest() + + +def is_p2tr(spk: bytes) -> bool: + if len(spk) != 34: + return False + # OP_1 OP_PUSHBYTES_32 <32 bytes> + return (spk[0] == 0x51) & (spk[1] == 0x20) + + +def is_p2wpkh(spk: bytes) -> bool: + if len(spk) != 22: + return False + # OP_0 OP_PUSHBYTES_20 <20 bytes> + return (spk[0] == 0x00) & (spk[1] == 0x14) + + +def is_p2sh(spk: bytes) -> bool: + if len(spk) != 23: + return False + # OP_HASH160 OP_PUSHBYTES_20 <20 bytes> OP_EQUAL + return (spk[0] == 0xA9) & (spk[1] == 0x14) & (spk[-1] == 0x87) + + +def is_p2pkh(spk: bytes) -> bool: + if len(spk) != 25: + return False + # OP_DUP OP_HASH160 OP_PUSHBYTES_20 <20 bytes> OP_EQUALVERIFY OP_CHECKSIG + return (spk[0] == 0x76) & (spk[1] == 0xA9) & (spk[2] == 0x14) & (spk[-2] == 0x88) & (spk[-1] == 0xAC) diff --git a/bip-0352/reference.py b/bip-0352/reference.py new file mode 100755 index 0000000..c98dac8 --- /dev/null +++ b/bip-0352/reference.py @@ -0,0 +1,335 @@ +#!/usr/bin/env python3 +# For running the test vectors, run this script: +# ./reference.py send_and_receive_test_vectors.json + +import hashlib +import json +from typing import List, Tuple, Dict, cast +from sys import argv, exit +from functools import reduce +from itertools import permutations + +# local files +from bech32m import convertbits, bech32_encode, decode, Encoding +from secp256k1 import ECKey, ECPubKey, TaggedHash, NUMS_H +from bitcoin_utils import ( + deser_txid, + from_hex, + hash160, + is_p2pkh, + is_p2sh, + is_p2wpkh, + is_p2tr, + ser_uint32, + COutPoint, + CTxInWitness, + VinInfo, + ) + + +def get_pubkey_from_input(vin: VinInfo) -> ECPubKey: + if is_p2pkh(vin.prevout): + # skip the first 3 op_codes and grab the 20 byte hash + # from the scriptPubKey + spk_hash = vin.prevout[3:3 + 20] + for i in range(len(vin.scriptSig), 0, -1): + if i - 33 >= 0: + # starting from the back, we move over the scriptSig with a 33 byte + # window (to match a compressed pubkey). we hash this and check if it matches + # the 20 byte has from the scriptPubKey. for standard scriptSigs, this will match + # right away because the pubkey is the last item in the scriptSig. + # if its a non-standard (malleated) scriptSig, we will still find the pubkey if its + # a compressed pubkey. + # + # note: this is an incredibly inefficient implementation, for demonstration purposes only. + pubkey_bytes = vin.scriptSig[i - 33:i] + pubkey_hash = hash160(pubkey_bytes) + if pubkey_hash == spk_hash: + pubkey = ECPubKey().set(pubkey_bytes) + if (pubkey.valid) & (pubkey.compressed): + return pubkey + if is_p2sh(vin.prevout): + redeem_script = vin.scriptSig[1:] + if is_p2wpkh(redeem_script): + pubkey = ECPubKey().set(vin.txinwitness.scriptWitness.stack[-1]) + if (pubkey.valid) & (pubkey.compressed): + return pubkey + if is_p2wpkh(vin.prevout): + txin = vin.txinwitness + pubkey = ECPubKey().set(txin.scriptWitness.stack[-1]) + if (pubkey.valid) & (pubkey.compressed): + return pubkey + if is_p2tr(vin.prevout): + witnessStack = vin.txinwitness.scriptWitness.stack + if (len(witnessStack) >= 1): + if (len(witnessStack) > 1 and witnessStack[-1][0] == 0x50): + # Last item is annex + witnessStack.pop() + + if (len(witnessStack) > 1): + # Script-path spend + control_block = witnessStack[-1] + # control block is <control byte> <32 byte internal key> and 0 or more <32 byte hash> + internal_key = control_block[1:33] + if (internal_key == NUMS_H.to_bytes(32, 'big')): + # Skip if NUMS_H + return ECPubKey() + + pubkey = ECPubKey().set(vin.prevout[2:]) + if (pubkey.valid) & (pubkey.compressed): + return pubkey + + + return ECPubKey() + + +def get_input_hash(outpoints: List[COutPoint], sum_input_pubkeys: ECPubKey) -> bytes: + lowest_outpoint = sorted(outpoints, key=lambda outpoint: outpoint.serialize())[0] + return TaggedHash("BIP0352/Inputs", lowest_outpoint.serialize() + cast(bytes, sum_input_pubkeys.get_bytes(False))) + + + +def encode_silent_payment_address(B_scan: ECPubKey, B_m: ECPubKey, hrp: str = "tsp", version: int = 0) -> str: + data = convertbits(cast(bytes, B_scan.get_bytes(False)) + cast(bytes, B_m.get_bytes(False)), 8, 5) + return bech32_encode(hrp, [version] + cast(List[int], data), Encoding.BECH32M) + + +def generate_label(b_scan: ECKey, m: int) -> bytes: + return TaggedHash("BIP0352/Label", b_scan.get_bytes() + ser_uint32(m)) + + +def create_labeled_silent_payment_address(b_scan: ECKey, B_spend: ECPubKey, m: int, hrp: str = "tsp", version: int = 0) -> str: + G = ECKey().set(1).get_pubkey() + B_scan = b_scan.get_pubkey() + B_m = B_spend + generate_label(b_scan, m) * G + labeled_address = encode_silent_payment_address(B_scan, B_m, hrp, version) + + return labeled_address + + +def decode_silent_payment_address(address: str, hrp: str = "tsp") -> Tuple[ECPubKey, ECPubKey]: + _, data = decode(hrp, address) + if data is None: + return ECPubKey(), ECPubKey() + B_scan = ECPubKey().set(data[:33]) + B_spend = ECPubKey().set(data[33:]) + + return B_scan, B_spend + + +def create_outputs(input_priv_keys: List[Tuple[ECKey, bool]], input_hash: bytes, recipients: List[str], hrp="tsp") -> List[str]: + G = ECKey().set(1).get_pubkey() + negated_keys = [] + for key, is_xonly in input_priv_keys: + k = ECKey().set(key.get_bytes()) + if is_xonly and k.get_pubkey().get_y() % 2 != 0: + k.negate() + negated_keys.append(k) + + a_sum = sum(negated_keys) + silent_payment_groups: Dict[ECPubKey, List[ECPubKey]] = {} + for recipient in recipients: + B_scan, B_m = decode_silent_payment_address(recipient, hrp=hrp) + if B_scan in silent_payment_groups: + silent_payment_groups[B_scan].append(B_m) + else: + silent_payment_groups[B_scan] = [B_m] + + outputs = [] + for B_scan, B_m_values in silent_payment_groups.items(): + ecdh_shared_secret = input_hash * a_sum * B_scan + k = 0 + for B_m in B_m_values: + t_k = TaggedHash("BIP0352/SharedSecret", ecdh_shared_secret.get_bytes(False) + ser_uint32(k)) + P_km = B_m + t_k * G + outputs.append(P_km.get_bytes().hex()) + k += 1 + + return list(set(outputs)) + + +def scanning(b_scan: ECKey, B_spend: ECPubKey, A_sum: ECPubKey, input_hash: bytes, outputs_to_check: List[ECPubKey], labels: Dict[str, str] = {}) -> List[Dict[str, str]]: + G = ECKey().set(1).get_pubkey() + ecdh_shared_secret = input_hash * b_scan * A_sum + k = 0 + wallet = [] + while True: + t_k = TaggedHash("BIP0352/SharedSecret", ecdh_shared_secret.get_bytes(False) + ser_uint32(k)) + P_k = B_spend + t_k * G + for output in outputs_to_check: + if P_k == output: + wallet.append({"pub_key": P_k.get_bytes().hex(), "priv_key_tweak": t_k.hex()}) + outputs_to_check.remove(output) + k += 1 + break + elif labels: + m_G_sub = output - P_k + if m_G_sub.get_bytes(False).hex() in labels: + P_km = P_k + m_G_sub + wallet.append({ + "pub_key": P_km.get_bytes().hex(), + "priv_key_tweak": (ECKey().set(t_k).add( + bytes.fromhex(labels[m_G_sub.get_bytes(False).hex()]) + )).get_bytes().hex(), + }) + outputs_to_check.remove(output) + k += 1 + break + else: + output.negate() + m_G_sub = output - P_k + if m_G_sub.get_bytes(False).hex() in labels: + P_km = P_k + m_G_sub + wallet.append({ + "pub_key": P_km.get_bytes().hex(), + "priv_key_tweak": (ECKey().set(t_k).add( + bytes.fromhex(labels[m_G_sub.get_bytes(False).hex()]) + )).get_bytes().hex(), + }) + outputs_to_check.remove(output) + k += 1 + break + else: + break + return wallet + + +if __name__ == "__main__": + if len(argv) != 2 or argv[1] in ('-h', '--help'): + print("Usage: ./reference.py send_and_receive_test_vectors.json") + exit(0) + + with open(argv[1], "r") as f: + test_data = json.loads(f.read()) + + # G , needed for generating the labels "database" + G = ECKey().set(1).get_pubkey() + for case in test_data: + print(case["comment"]) + # Test sending + for sending_test in case["sending"]: + given = sending_test["given"] + expected = sending_test["expected"] + + vins = [ + VinInfo( + outpoint=COutPoint(hash=deser_txid(input["txid"]), n=input["vout"]), + scriptSig=bytes.fromhex(input["scriptSig"]), + txinwitness=CTxInWitness().deserialize(from_hex(input["txinwitness"])), + prevout=bytes.fromhex(input["prevout"]["scriptPubKey"]["hex"]), + private_key=ECKey().set(bytes.fromhex(input["private_key"])), + ) + for input in given["vin"] + ] + # Conver the tuples to lists so they can be easily compared to the json list of lists from the given test vectors + input_priv_keys = [] + input_pub_keys = [] + for vin in vins: + pubkey = get_pubkey_from_input(vin) + if not pubkey.valid: + continue + input_priv_keys.append(( + vin.private_key, + is_p2tr(vin.prevout), + )) + input_pub_keys.append(pubkey) + + sending_outputs = [] + if (len(input_pub_keys) > 0): + A_sum = reduce(lambda x, y: x + y, input_pub_keys) + input_hash = get_input_hash([vin.outpoint for vin in vins], A_sum) + sending_outputs = create_outputs(input_priv_keys, input_hash, given["recipients"], hrp="sp") + + # Note: order doesn't matter for creating/finding the outputs. However, different orderings of the recipient addresses + # will produce different generated outputs if sending to multiple silent payment addresses belonging to the + # same sender but with different labels. Because of this, expected["outputs"] contains all possible valid output sets, + # based on all possible permutations of recipient address orderings. Must match exactly one of the possible output sets. + assert(any(set(sending_outputs) == set(lst) for lst in expected["outputs"])), "Sending test failed" + else: + assert(sending_outputs == expected["outputs"][0] == []), "Sending test failed" + + # Test receiving + msg = hashlib.sha256(b"message").digest() + aux = hashlib.sha256(b"random auxiliary data").digest() + for receiving_test in case["receiving"]: + given = receiving_test["given"] + expected = receiving_test["expected"] + outputs_to_check = [ + ECPubKey().set(bytes.fromhex(p)) for p in given["outputs"] + ] + vins = [ + VinInfo( + outpoint=COutPoint(hash=deser_txid(input["txid"]), n=input["vout"]), + scriptSig=bytes.fromhex(input["scriptSig"]), + txinwitness=CTxInWitness().deserialize(from_hex(input["txinwitness"])), + prevout=bytes.fromhex(input["prevout"]["scriptPubKey"]["hex"]), + ) + for input in given["vin"] + ] + # Check that the given inputs for the receiving test match what was generated during the sending test + receiving_addresses = [] + b_scan = ECKey().set(bytes.fromhex(given["key_material"]["scan_priv_key"])) + b_spend = ECKey().set( + bytes.fromhex(given["key_material"]["spend_priv_key"]) + ) + B_scan = b_scan.get_pubkey() + B_spend = b_spend.get_pubkey() + receiving_addresses.append( + encode_silent_payment_address(B_scan, B_spend, hrp="sp") + ) + if given["labels"]: + for label in given["labels"]: + receiving_addresses.append( + create_labeled_silent_payment_address( + b_scan, B_spend, m=label, hrp="sp" + ) + ) + + # Check that the silent payment addresses match for the given BIP32 seed and labels dictionary + assert (receiving_addresses == expected["addresses"]), "Receiving addresses don't match" + input_pub_keys = [] + for vin in vins: + pubkey = get_pubkey_from_input(vin) + if not pubkey.valid: + continue + input_pub_keys.append(pubkey) + + add_to_wallet = [] + if (len(input_pub_keys) > 0): + A_sum = reduce(lambda x, y: x + y, input_pub_keys) + input_hash = get_input_hash([vin.outpoint for vin in vins], A_sum) + pre_computed_labels = { + (generate_label(b_scan, label) * G).get_bytes(False).hex(): generate_label(b_scan, label).hex() + for label in given["labels"] + } + add_to_wallet = scanning( + b_scan=b_scan, + B_spend=B_spend, + A_sum=A_sum, + input_hash=input_hash, + outputs_to_check=outputs_to_check, + labels=pre_computed_labels, + ) + + # Check that the private key is correct for the found output public key + for output in add_to_wallet: + pub_key = ECPubKey().set(bytes.fromhex(output["pub_key"])) + full_private_key = b_spend.add(bytes.fromhex(output["priv_key_tweak"])) + if full_private_key.get_pubkey().get_y() % 2 != 0: + full_private_key.negate() + + sig = full_private_key.sign_schnorr(msg, aux) + assert pub_key.verify_schnorr(sig, msg), f"Invalid signature for {pub_key}" + output["signature"] = sig.hex() + + # Note: order doesn't matter for creating/finding the outputs. However, different orderings of the recipient addresses + # will produce different generated outputs if sending to multiple silent payment addresses belonging to the + # same sender but with different labels. Because of this, expected["outputs"] contains all possible valid output sets, + # based on all possible permutations of recipient address orderings. Must match exactly one of the possible found output + # sets in expected["outputs"] + generated_set = {frozenset(d.items()) for d in add_to_wallet} + expected_set = {frozenset(d.items()) for d in expected["outputs"]} + assert generated_set == expected_set, "Receive test failed" + + + print("All tests passed") diff --git a/bip-0352/scan_data_downloader_per_month.png b/bip-0352/scan_data_downloader_per_month.png Binary files differnew file mode 100644 index 0000000..ffcd0dd --- /dev/null +++ b/bip-0352/scan_data_downloader_per_month.png diff --git a/bip-0352/secp256k1.py b/bip-0352/secp256k1.py new file mode 100644 index 0000000..0ccbc4e --- /dev/null +++ b/bip-0352/secp256k1.py @@ -0,0 +1,696 @@ +# Copyright (c) 2019 Pieter Wuille +# Distributed under the MIT software license, see the accompanying +# file COPYING or http://www.opensource.org/licenses/mit-license.php. +"""Test-only secp256k1 elliptic curve implementation + +WARNING: This code is slow, uses bad randomness, does not properly protect +keys, and is trivially vulnerable to side channel attacks. Do not use for +anything but tests.""" +import random +import hashlib +import hmac + +def TaggedHash(tag, data): + ss = hashlib.sha256(tag.encode('utf-8')).digest() + ss += ss + ss += data + return hashlib.sha256(ss).digest() + +def modinv(a, n): + """Compute the modular inverse of a modulo n + + See https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm#Modular_integers. + """ + t1, t2 = 0, 1 + r1, r2 = n, a + while r2 != 0: + q = r1 // r2 + t1, t2 = t2, t1 - q * t2 + r1, r2 = r2, r1 - q * r2 + if r1 > 1: + return None + if t1 < 0: + t1 += n + return t1 + +def jacobi_symbol(n, k): + """Compute the Jacobi symbol of n modulo k + + See http://en.wikipedia.org/wiki/Jacobi_symbol + + For our application k is always prime, so this is the same as the Legendre symbol.""" + assert k > 0 and k & 1, "jacobi symbol is only defined for positive odd k" + n %= k + t = 0 + while n != 0: + while n & 1 == 0: + n >>= 1 + r = k & 7 + t ^= (r == 3 or r == 5) + n, k = k, n + t ^= (n & k & 3 == 3) + n = n % k + if k == 1: + return -1 if t else 1 + return 0 + +def modsqrt(a, p): + """Compute the square root of a modulo p when p % 4 = 3. + + The Tonelli-Shanks algorithm can be used. See https://en.wikipedia.org/wiki/Tonelli-Shanks_algorithm + + Limiting this function to only work for p % 4 = 3 means we don't need to + iterate through the loop. The highest n such that p - 1 = 2^n Q with Q odd + is n = 1. Therefore Q = (p-1)/2 and sqrt = a^((Q+1)/2) = a^((p+1)/4) + + secp256k1's is defined over field of size 2**256 - 2**32 - 977, which is 3 mod 4. + """ + if p % 4 != 3: + raise NotImplementedError("modsqrt only implemented for p % 4 = 3") + sqrt = pow(a, (p + 1)//4, p) + if pow(sqrt, 2, p) == a % p: + return sqrt + return None + +def int_or_bytes(s): + "Convert 32-bytes to int while accepting also int and returning it as is." + if isinstance(s, bytes): + assert(len(s) == 32) + s = int.from_bytes(s, 'big') + elif not isinstance(s, int): + raise TypeError + return s + +class EllipticCurve: + def __init__(self, p, a, b): + """Initialize elliptic curve y^2 = x^3 + a*x + b over GF(p).""" + self.p = p + self.a = a % p + self.b = b % p + + def affine(self, p1): + """Convert a Jacobian point tuple p1 to affine form, or None if at infinity. + + An affine point is represented as the Jacobian (x, y, 1)""" + x1, y1, z1 = p1 + if z1 == 0: + return None + inv = modinv(z1, self.p) + inv_2 = (inv**2) % self.p + inv_3 = (inv_2 * inv) % self.p + return ((inv_2 * x1) % self.p, (inv_3 * y1) % self.p, 1) + + def has_even_y(self, p1): + """Whether the point p1 has an even Y coordinate when expressed in affine coordinates.""" + return not (p1[2] == 0 or self.affine(p1)[1] & 1) + + def negate(self, p1): + """Negate a Jacobian point tuple p1.""" + x1, y1, z1 = p1 + return (x1, (self.p - y1) % self.p, z1) + + def on_curve(self, p1): + """Determine whether a Jacobian tuple p is on the curve (and not infinity)""" + x1, y1, z1 = p1 + z2 = pow(z1, 2, self.p) + z4 = pow(z2, 2, self.p) + return z1 != 0 and (pow(x1, 3, self.p) + self.a * x1 * z4 + self.b * z2 * z4 - pow(y1, 2, self.p)) % self.p == 0 + + def is_x_coord(self, x): + """Test whether x is a valid X coordinate on the curve.""" + x_3 = pow(x, 3, self.p) + return jacobi_symbol(x_3 + self.a * x + self.b, self.p) != -1 + + def lift_x(self, x): + """Given an X coordinate on the curve, return a corresponding affine point.""" + x_3 = pow(x, 3, self.p) + v = x_3 + self.a * x + self.b + y = modsqrt(v, self.p) + if y is None: + return None + return (x, y, 1) + + def double(self, p1): + """Double a Jacobian tuple p1 + + See https://en.wikibooks.org/wiki/Cryptography/Prime_Curve/Jacobian_Coordinates - Point Doubling""" + x1, y1, z1 = p1 + if z1 == 0: + return (0, 1, 0) + y1_2 = (y1**2) % self.p + y1_4 = (y1_2**2) % self.p + x1_2 = (x1**2) % self.p + s = (4*x1*y1_2) % self.p + m = 3*x1_2 + if self.a: + m += self.a * pow(z1, 4, self.p) + m = m % self.p + x2 = (m**2 - 2*s) % self.p + y2 = (m*(s - x2) - 8*y1_4) % self.p + z2 = (2*y1*z1) % self.p + return (x2, y2, z2) + + def add_mixed(self, p1, p2): + """Add a Jacobian tuple p1 and an affine tuple p2 + + See https://en.wikibooks.org/wiki/Cryptography/Prime_Curve/Jacobian_Coordinates - Point Addition (with affine point)""" + x1, y1, z1 = p1 + x2, y2, z2 = p2 + assert(z2 == 1) + # Adding to the point at infinity is a no-op + if z1 == 0: + return p2 + z1_2 = (z1**2) % self.p + z1_3 = (z1_2 * z1) % self.p + u2 = (x2 * z1_2) % self.p + s2 = (y2 * z1_3) % self.p + if x1 == u2: + if (y1 != s2): + # p1 and p2 are inverses. Return the point at infinity. + return (0, 1, 0) + # p1 == p2. The formulas below fail when the two points are equal. + return self.double(p1) + h = u2 - x1 + r = s2 - y1 + h_2 = (h**2) % self.p + h_3 = (h_2 * h) % self.p + u1_h_2 = (x1 * h_2) % self.p + x3 = (r**2 - h_3 - 2*u1_h_2) % self.p + y3 = (r*(u1_h_2 - x3) - y1*h_3) % self.p + z3 = (h*z1) % self.p + return (x3, y3, z3) + + def add(self, p1, p2): + """Add two Jacobian tuples p1 and p2 + + See https://en.wikibooks.org/wiki/Cryptography/Prime_Curve/Jacobian_Coordinates - Point Addition""" + x1, y1, z1 = p1 + x2, y2, z2 = p2 + # Adding the point at infinity is a no-op + if z1 == 0: + return p2 + if z2 == 0: + return p1 + # Adding an Affine to a Jacobian is more efficient since we save field multiplications and squarings when z = 1 + if z1 == 1: + return self.add_mixed(p2, p1) + if z2 == 1: + return self.add_mixed(p1, p2) + z1_2 = (z1**2) % self.p + z1_3 = (z1_2 * z1) % self.p + z2_2 = (z2**2) % self.p + z2_3 = (z2_2 * z2) % self.p + u1 = (x1 * z2_2) % self.p + u2 = (x2 * z1_2) % self.p + s1 = (y1 * z2_3) % self.p + s2 = (y2 * z1_3) % self.p + if u1 == u2: + if (s1 != s2): + # p1 and p2 are inverses. Return the point at infinity. + return (0, 1, 0) + # p1 == p2. The formulas below fail when the two points are equal. + return self.double(p1) + h = u2 - u1 + r = s2 - s1 + h_2 = (h**2) % self.p + h_3 = (h_2 * h) % self.p + u1_h_2 = (u1 * h_2) % self.p + x3 = (r**2 - h_3 - 2*u1_h_2) % self.p + y3 = (r*(u1_h_2 - x3) - s1*h_3) % self.p + z3 = (h*z1*z2) % self.p + return (x3, y3, z3) + + def mul(self, ps): + """Compute a (multi) point multiplication + + ps is a list of (Jacobian tuple, scalar) pairs. + """ + r = (0, 1, 0) + for i in range(255, -1, -1): + r = self.double(r) + for (p, n) in ps: + if ((n >> i) & 1): + r = self.add(r, p) + return r + +SECP256K1_FIELD_SIZE = 2**256 - 2**32 - 977 +SECP256K1 = EllipticCurve(SECP256K1_FIELD_SIZE, 0, 7) +SECP256K1_G = (0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8, 1) +SECP256K1_ORDER = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 +SECP256K1_ORDER_HALF = SECP256K1_ORDER // 2 +NUMS_H = 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0 + +class ECPubKey(): + """A secp256k1 public key""" + + def __init__(self): + """Construct an uninitialized public key""" + self.valid = False + + def __repr__(self): + return self.get_bytes().hex() + + def __eq__(self, other): + assert isinstance(other, ECPubKey) + return self.get_bytes() == other.get_bytes() + + def __hash__(self): + return hash(self.get_bytes()) + + def set(self, data): + """Construct a public key from a serialization in compressed or uncompressed DER format or BIP340 format""" + if (len(data) == 65 and data[0] == 0x04): + p = (int.from_bytes(data[1:33], 'big'), int.from_bytes(data[33:65], 'big'), 1) + self.valid = SECP256K1.on_curve(p) + if self.valid: + self.p = p + self.compressed = False + elif (len(data) == 33 and (data[0] == 0x02 or data[0] == 0x03)): + x = int.from_bytes(data[1:33], 'big') + if SECP256K1.is_x_coord(x): + p = SECP256K1.lift_x(x) + # if the oddness of the y co-ord isn't correct, find the other + # valid y + if (p[1] & 1) != (data[0] & 1): + p = SECP256K1.negate(p) + self.p = p + self.valid = True + self.compressed = True + else: + self.valid = False + elif (len(data) == 32): + x = int.from_bytes(data[0:32], 'big') + if SECP256K1.is_x_coord(x): + p = SECP256K1.lift_x(x) + # if the oddness of the y co-ord isn't correct, find the other + # valid y + if p[1]%2 != 0: + p = SECP256K1.negate(p) + self.p = p + self.valid = True + self.compressed = True + else: + self.valid = False + else: + self.valid = False + return self + + @property + def is_compressed(self): + return self.compressed + + @property + def is_valid(self): + return self.valid + + def get_y(self): + return SECP256K1.affine(self.p)[1] + + def get_x(self): + return SECP256K1.affine(self.p)[0] + + def get_bytes(self, bip340=True): + assert(self.valid) + p = SECP256K1.affine(self.p) + if p is None: + return None + if bip340: + return bytes(p[0].to_bytes(32, 'big')) + elif self.compressed: + return bytes([0x02 + (p[1] & 1)]) + p[0].to_bytes(32, 'big') + else: + return bytes([0x04]) + p[0].to_bytes(32, 'big') + p[1].to_bytes(32, 'big') + + def verify_ecdsa(self, sig, msg, low_s=True): + """Verify a strictly DER-encoded ECDSA signature against this pubkey. + + See https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm for the + ECDSA verifier algorithm""" + assert(self.valid) + + # Extract r and s from the DER formatted signature. Return false for + # any DER encoding errors. + if (sig[1] + 2 != len(sig)): + return False + if (len(sig) < 4): + return False + if (sig[0] != 0x30): + return False + if (sig[2] != 0x02): + return False + rlen = sig[3] + if (len(sig) < 6 + rlen): + return False + if rlen < 1 or rlen > 33: + return False + if sig[4] >= 0x80: + return False + if (rlen > 1 and (sig[4] == 0) and not (sig[5] & 0x80)): + return False + r = int.from_bytes(sig[4:4+rlen], 'big') + if (sig[4+rlen] != 0x02): + return False + slen = sig[5+rlen] + if slen < 1 or slen > 33: + return False + if (len(sig) != 6 + rlen + slen): + return False + if sig[6+rlen] >= 0x80: + return False + if (slen > 1 and (sig[6+rlen] == 0) and not (sig[7+rlen] & 0x80)): + return False + s = int.from_bytes(sig[6+rlen:6+rlen+slen], 'big') + + # Verify that r and s are within the group order + if r < 1 or s < 1 or r >= SECP256K1_ORDER or s >= SECP256K1_ORDER: + return False + if low_s and s >= SECP256K1_ORDER_HALF: + return False + z = int.from_bytes(msg, 'big') + + # Run verifier algorithm on r, s + w = modinv(s, SECP256K1_ORDER) + u1 = z*w % SECP256K1_ORDER + u2 = r*w % SECP256K1_ORDER + R = SECP256K1.affine(SECP256K1.mul([(SECP256K1_G, u1), (self.p, u2)])) + if R is None or R[0] != r: + return False + return True + + def verify_schnorr(self, sig, msg): + assert(len(msg) == 32) + assert(len(sig) == 64) + assert(self.valid) + r = int.from_bytes(sig[0:32], 'big') + if r >= SECP256K1_FIELD_SIZE: + return False + s = int.from_bytes(sig[32:64], 'big') + if s >= SECP256K1_ORDER: + return False + e = int.from_bytes(TaggedHash("BIP0340/challenge", sig[0:32] + self.get_bytes() + msg), 'big') % SECP256K1_ORDER + R = SECP256K1.mul([(SECP256K1_G, s), (self.p, SECP256K1_ORDER - e)]) + if not SECP256K1.has_even_y(R): + return False + if ((r * R[2] * R[2]) % SECP256K1_FIELD_SIZE) != R[0]: + return False + return True + + def __add__(self, other): + """Adds two ECPubKey points.""" + assert isinstance(other, ECPubKey) + assert self.valid + assert other.valid + ret = ECPubKey() + ret.p = SECP256K1.add(other.p, self.p) + ret.valid = True + ret.compressed = self.compressed + return ret + + def __radd__(self, other): + """Allows this ECPubKey to be added to 0 for sum()""" + if other == 0: + return self + else: + return self + other + + def __mul__(self, other): + """Multiplies ECPubKey point with a scalar(int/32bytes/ECKey).""" + if isinstance(other, ECKey): + assert self.valid + assert other.secret is not None + multiplier = other.secret + else: + # int_or_bytes checks that other is `int` or `bytes` + multiplier = int_or_bytes(other) + + assert multiplier < SECP256K1_ORDER + multiplier = multiplier % SECP256K1_ORDER + ret = ECPubKey() + ret.p = SECP256K1.mul([(self.p, multiplier)]) + ret.valid = True + ret.compressed = self.compressed + return ret + + def __rmul__(self, other): + """Multiplies a scalar(int/32bytes/ECKey) with an ECPubKey point""" + return self * other + + def __sub__(self, other): + """Subtract one point from another""" + assert isinstance(other, ECPubKey) + assert self.valid + assert other.valid + ret = ECPubKey() + ret.p = SECP256K1.add(self.p, SECP256K1.negate(other.p)) + ret.valid = True + ret.compressed = self.compressed + return ret + + def tweak_add(self, tweak): + assert(self.valid) + t = int_or_bytes(tweak) + if t >= SECP256K1_ORDER: + return None + tweaked = SECP256K1.affine(SECP256K1.mul([(self.p, 1), (SECP256K1_G, t)])) + if tweaked is None: + return None + ret = ECPubKey() + ret.p = tweaked + ret.valid = True + ret.compressed = self.compressed + return ret + + def mul(self, data): + """Multiplies ECPubKey point with scalar data.""" + assert self.valid + other = ECKey() + other.set(data, True) + return self * other + + def negate(self): + self.p = SECP256K1.affine(SECP256K1.negate(self.p)) + +def rfc6979_nonce(key): + """Compute signing nonce using RFC6979.""" + v = bytes([1] * 32) + k = bytes([0] * 32) + k = hmac.new(k, v + b"\x00" + key, 'sha256').digest() + v = hmac.new(k, v, 'sha256').digest() + k = hmac.new(k, v + b"\x01" + key, 'sha256').digest() + v = hmac.new(k, v, 'sha256').digest() + return hmac.new(k, v, 'sha256').digest() + +class ECKey(): + """A secp256k1 private key""" + + def __init__(self): + self.valid = False + + def __repr__(self): + return str(self.secret) + + def __eq__(self, other): + assert isinstance(other, ECKey) + return self.secret == other.secret + + def __hash__(self): + return hash(self.secret) + + def set(self, secret, compressed=True): + """Construct a private key object from either 32-bytes or an int secret and a compressed flag.""" + secret = int_or_bytes(secret) + + self.valid = (secret > 0 and secret < SECP256K1_ORDER) + if self.valid: + self.secret = secret + self.compressed = compressed + return self + + def generate(self, compressed=True): + """Generate a random private key (compressed or uncompressed).""" + self.set(random.randrange(1, SECP256K1_ORDER).to_bytes(32, 'big'), compressed) + return self + + def get_bytes(self): + """Retrieve the 32-byte representation of this key.""" + assert(self.valid) + return self.secret.to_bytes(32, 'big') + + def as_int(self): + return self.secret + + def from_int(self, secret, compressed=True): + self.valid = (secret > 0 and secret < SECP256K1_ORDER) + if self.valid: + self.secret = secret + self.compressed = compressed + + def __add__(self, other): + """Add key secrets. Returns compressed key.""" + assert isinstance(other, ECKey) + assert other.secret > 0 and other.secret < SECP256K1_ORDER + assert self.valid is True + ret_data = ((self.secret + other.secret) % SECP256K1_ORDER).to_bytes(32, 'big') + ret = ECKey() + ret.set(ret_data, True) + return ret + + def __radd__(self, other): + """Allows this ECKey to be added to 0 for sum()""" + if other == 0: + return self + else: + return self + other + + def __sub__(self, other): + """Subtract key secrets. Returns compressed key.""" + assert isinstance(other, ECKey) + assert other.secret > 0 and other.secret < SECP256K1_ORDER + assert self.valid is True + ret_data = ((self.secret - other.secret) % SECP256K1_ORDER).to_bytes(32, 'big') + ret = ECKey() + ret.set(ret_data, True) + return ret + + def __mul__(self, other): + """Multiply a private key by another private key or multiply a public key by a private key. Returns compressed key.""" + if isinstance(other, ECKey): + assert other.secret > 0 and other.secret < SECP256K1_ORDER + assert self.valid is True + ret_data = ((self.secret * other.secret) % SECP256K1_ORDER).to_bytes(32, 'big') + ret = ECKey() + ret.set(ret_data, True) + return ret + elif isinstance(other, ECPubKey): + return other * self + else: + # ECKey().set() checks that other is an `int` or `bytes` + assert self.valid + second = ECKey().set(other, self.compressed) + return self * second + + def __rmul__(self, other): + return self * other + + def add(self, data): + """Add key to scalar data. Returns compressed key.""" + other = ECKey() + other.set(data, True) + return self + other + + def mul(self, data): + """Multiply key secret with scalar data. Returns compressed key.""" + other = ECKey() + other.set(data, True) + return self * other + + def negate(self): + """Negate a private key.""" + assert self.valid + self.secret = SECP256K1_ORDER - self.secret + + @property + def is_valid(self): + return self.valid + + @property + def is_compressed(self): + return self.compressed + + def get_pubkey(self): + """Compute an ECPubKey object for this secret key.""" + assert(self.valid) + ret = ECPubKey() + p = SECP256K1.mul([(SECP256K1_G, self.secret)]) + ret.p = p + ret.valid = True + ret.compressed = self.compressed + return ret + + def sign_ecdsa(self, msg, low_s=True, rfc6979=False): + """Construct a DER-encoded ECDSA signature with this key. + + See https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm for the + ECDSA signer algorithm.""" + assert(self.valid) + z = int.from_bytes(msg, 'big') + # Note: no RFC6979 by default, but a simple random nonce (some tests rely on distinct transactions for the same operation) + if rfc6979: + k = int.from_bytes(rfc6979_nonce(self.secret.to_bytes(32, 'big') + msg), 'big') + else: + k = random.randrange(1, SECP256K1_ORDER) + R = SECP256K1.affine(SECP256K1.mul([(SECP256K1_G, k)])) + r = R[0] % SECP256K1_ORDER + s = (modinv(k, SECP256K1_ORDER) * (z + self.secret * r)) % SECP256K1_ORDER + if low_s and s > SECP256K1_ORDER_HALF: + s = SECP256K1_ORDER - s + # Represent in DER format. The byte representations of r and s have + # length rounded up (255 bits becomes 32 bytes and 256 bits becomes 33 + # bytes). + rb = r.to_bytes((r.bit_length() + 8) // 8, 'big') + sb = s.to_bytes((s.bit_length() + 8) // 8, 'big') + return b'\x30' + bytes([4 + len(rb) + len(sb), 2, len(rb)]) + rb + bytes([2, len(sb)]) + sb + + def sign_schnorr(self, msg, aux=None): + """Create a Schnorr signature (see BIP340).""" + if aux is None: + aux = bytes(32) + + assert self.valid + assert len(msg) == 32 + assert len(aux) == 32 + + t = (self.secret ^ int.from_bytes(TaggedHash("BIP0340/aux", aux), 'big')).to_bytes(32, 'big') + kp = int.from_bytes(TaggedHash("BIP0340/nonce", t + self.get_pubkey().get_bytes() + msg), 'big') % SECP256K1_ORDER + assert kp != 0 + R = SECP256K1.affine(SECP256K1.mul([(SECP256K1_G, kp)])) + k = kp if SECP256K1.has_even_y(R) else SECP256K1_ORDER - kp + e = int.from_bytes(TaggedHash("BIP0340/challenge", R[0].to_bytes(32, 'big') + self.get_pubkey().get_bytes() + msg), 'big') % SECP256K1_ORDER + return R[0].to_bytes(32, 'big') + ((k + e * self.secret) % SECP256K1_ORDER).to_bytes(32, 'big') + + def tweak_add(self, tweak): + """Return a tweaked version of this private key.""" + assert(self.valid) + t = int_or_bytes(tweak) + if t >= SECP256K1_ORDER: + return None + tweaked = (self.secret + t) % SECP256K1_ORDER + if tweaked == 0: + return None + ret = ECKey() + ret.set(tweaked.to_bytes(32, 'big'), self.compressed) + return ret + +def generate_key_pair(secret=None, compressed=True): + """Convenience function to generate a private-public key pair.""" + d = ECKey() + if secret: + d.set(secret, compressed) + else: + d.generate(compressed) + + P = d.get_pubkey() + return d, P + +def generate_bip340_key_pair(): + """Convenience function to generate a BIP0340 private-public key pair.""" + d = ECKey() + d.generate() + P = d.get_pubkey() + if P.get_y()%2 != 0: + d.negate() + P.negate() + return d, P + +def generate_schnorr_nonce(): + """Generate a random valid BIP340 nonce. + + See https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki. + This implementation ensures the y-coordinate of the nonce point is even.""" + kp = random.randrange(1, SECP256K1_ORDER) + assert kp != 0 + R = SECP256K1.affine(SECP256K1.mul([(SECP256K1_G, kp)])) + k = kp if R[1] % 2 == 0 else SECP256K1_ORDER - kp + k_key = ECKey() + k_key.set(k.to_bytes(32, 'big'), True) + return k_key diff --git a/bip-0352/send_and_receive_test_vectors.json b/bip-0352/send_and_receive_test_vectors.json new file mode 100644 index 0000000..f9b205b --- /dev/null +++ b/bip-0352/send_and_receive_test_vectors.json @@ -0,0 +1,2673 @@ +[ + { + "comment": "Simple send: two inputs", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "48304602210086783ded73e961037e77d49d9deee4edc2b23136e9728d56e4491c80015c3a63022100fda4c0f21ea18de29edbce57f7134d613e044ee150a89e2e64700de2d4e83d4e2103bd85685d03d111699b15d046319febe77f8de5286e9e512703cdee1bf3be3792", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914d9317c66f54ff0a152ec50b1d19c25be50c8e15988ac" + } + }, + "private_key": "93f5ed907ad5b2bdbbdcb5d9116ebc0a4e1f92f910d5260237fa45a9408aad16" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "3e9fce73d4e77a4809908e3c3a2e54ee147b9312dc5044a193d1fc85de46e3c1" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "48304602210086783ded73e961037e77d49d9deee4edc2b23136e9728d56e4491c80015c3a63022100fda4c0f21ea18de29edbce57f7134d613e044ee150a89e2e64700de2d4e83d4e2103bd85685d03d111699b15d046319febe77f8de5286e9e512703cdee1bf3be3792", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914d9317c66f54ff0a152ec50b1d19c25be50c8e15988ac" + } + } + } + ], + "outputs": [ + "3e9fce73d4e77a4809908e3c3a2e54ee147b9312dc5044a193d1fc85de46e3c1" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "f438b40179a3c4262de12986c0e6cce0634007cdc79c1dcd3e20b9ebc2e7eef6", + "pub_key": "3e9fce73d4e77a4809908e3c3a2e54ee147b9312dc5044a193d1fc85de46e3c1", + "signature": "74f85b856337fbe837643b86f462118159f93ac4acc2671522f27e8f67b079959195ccc7a5dbee396d2909f5d680d6e30cda7359aa2755822509b70d6b0687a1" + } + ] + } + } + ] + }, + { + "comment": "Simple send: two inputs, order reversed", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "48304602210086783ded73e961037e77d49d9deee4edc2b23136e9728d56e4491c80015c3a63022100fda4c0f21ea18de29edbce57f7134d613e044ee150a89e2e64700de2d4e83d4e2103bd85685d03d111699b15d046319febe77f8de5286e9e512703cdee1bf3be3792", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914d9317c66f54ff0a152ec50b1d19c25be50c8e15988ac" + } + }, + "private_key": "93f5ed907ad5b2bdbbdcb5d9116ebc0a4e1f92f910d5260237fa45a9408aad16" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "3e9fce73d4e77a4809908e3c3a2e54ee147b9312dc5044a193d1fc85de46e3c1" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "48304602210086783ded73e961037e77d49d9deee4edc2b23136e9728d56e4491c80015c3a63022100fda4c0f21ea18de29edbce57f7134d613e044ee150a89e2e64700de2d4e83d4e2103bd85685d03d111699b15d046319febe77f8de5286e9e512703cdee1bf3be3792", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914d9317c66f54ff0a152ec50b1d19c25be50c8e15988ac" + } + } + } + ], + "outputs": [ + "3e9fce73d4e77a4809908e3c3a2e54ee147b9312dc5044a193d1fc85de46e3c1" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "f438b40179a3c4262de12986c0e6cce0634007cdc79c1dcd3e20b9ebc2e7eef6", + "pub_key": "3e9fce73d4e77a4809908e3c3a2e54ee147b9312dc5044a193d1fc85de46e3c1", + "signature": "74f85b856337fbe837643b86f462118159f93ac4acc2671522f27e8f67b079959195ccc7a5dbee396d2909f5d680d6e30cda7359aa2755822509b70d6b0687a1" + } + ] + } + } + ] + }, + { + "comment": "Simple send: two inputs from the same transaction", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 3, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 7, + "scriptSig": "48304602210086783ded73e961037e77d49d9deee4edc2b23136e9728d56e4491c80015c3a63022100fda4c0f21ea18de29edbce57f7134d613e044ee150a89e2e64700de2d4e83d4e2103bd85685d03d111699b15d046319febe77f8de5286e9e512703cdee1bf3be3792", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914d9317c66f54ff0a152ec50b1d19c25be50c8e15988ac" + } + }, + "private_key": "93f5ed907ad5b2bdbbdcb5d9116ebc0a4e1f92f910d5260237fa45a9408aad16" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "79e71baa2ba3fc66396de3a04f168c7bf24d6870ec88ca877754790c1db357b6" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 3, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 7, + "scriptSig": "48304602210086783ded73e961037e77d49d9deee4edc2b23136e9728d56e4491c80015c3a63022100fda4c0f21ea18de29edbce57f7134d613e044ee150a89e2e64700de2d4e83d4e2103bd85685d03d111699b15d046319febe77f8de5286e9e512703cdee1bf3be3792", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914d9317c66f54ff0a152ec50b1d19c25be50c8e15988ac" + } + } + } + ], + "outputs": [ + "79e71baa2ba3fc66396de3a04f168c7bf24d6870ec88ca877754790c1db357b6" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "4851455bfbe1ab4f80156570aa45063201aa5c9e1b1dcd29f0f8c33d10bf77ae", + "pub_key": "79e71baa2ba3fc66396de3a04f168c7bf24d6870ec88ca877754790c1db357b6", + "signature": "10332eea808b6a13f70059a8a73195808db782012907f5ba32b6eae66a2f66b4f65147e2b968a1678c5f73d57d5d195dbaf667b606ff80c8490eac1f3b710657" + } + ] + } + } + ] + }, + { + "comment": "Simple send: two inputs from the same transaction, order reversed", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 7, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 3, + "scriptSig": "48304602210086783ded73e961037e77d49d9deee4edc2b23136e9728d56e4491c80015c3a63022100fda4c0f21ea18de29edbce57f7134d613e044ee150a89e2e64700de2d4e83d4e2103bd85685d03d111699b15d046319febe77f8de5286e9e512703cdee1bf3be3792", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914d9317c66f54ff0a152ec50b1d19c25be50c8e15988ac" + } + }, + "private_key": "93f5ed907ad5b2bdbbdcb5d9116ebc0a4e1f92f910d5260237fa45a9408aad16" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "f4c2da807f89cb1501f1a77322a895acfb93c28e08ed2724d2beb8e44539ba38" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 7, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 3, + "scriptSig": "48304602210086783ded73e961037e77d49d9deee4edc2b23136e9728d56e4491c80015c3a63022100fda4c0f21ea18de29edbce57f7134d613e044ee150a89e2e64700de2d4e83d4e2103bd85685d03d111699b15d046319febe77f8de5286e9e512703cdee1bf3be3792", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914d9317c66f54ff0a152ec50b1d19c25be50c8e15988ac" + } + } + } + ], + "outputs": [ + "f4c2da807f89cb1501f1a77322a895acfb93c28e08ed2724d2beb8e44539ba38" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "ab0c9b87181bf527879f48db9f14a02233619b986f8e8f2d5d408ce68a709f51", + "pub_key": "f4c2da807f89cb1501f1a77322a895acfb93c28e08ed2724d2beb8e44539ba38", + "signature": "398a9790865791a9db41a8015afad3a47d60fec5086c50557806a49a1bc038808632b8fe679a7bb65fc6b455be994502eed849f1da3729cd948fc7be73d67295" + } + ] + } + } + ] + }, + { + "comment": "Outpoint ordering byte-lexicographically vs. vout-integer", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 1, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 256, + "scriptSig": "48304602210086783ded73e961037e77d49d9deee4edc2b23136e9728d56e4491c80015c3a63022100fda4c0f21ea18de29edbce57f7134d613e044ee150a89e2e64700de2d4e83d4e2103bd85685d03d111699b15d046319febe77f8de5286e9e512703cdee1bf3be3792", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914d9317c66f54ff0a152ec50b1d19c25be50c8e15988ac" + } + }, + "private_key": "93f5ed907ad5b2bdbbdcb5d9116ebc0a4e1f92f910d5260237fa45a9408aad16" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "a85ef8701394b517a4b35217c4bd37ac01ebeed4b008f8d0879f9e09ba95319c" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 1, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 256, + "scriptSig": "48304602210086783ded73e961037e77d49d9deee4edc2b23136e9728d56e4491c80015c3a63022100fda4c0f21ea18de29edbce57f7134d613e044ee150a89e2e64700de2d4e83d4e2103bd85685d03d111699b15d046319febe77f8de5286e9e512703cdee1bf3be3792", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914d9317c66f54ff0a152ec50b1d19c25be50c8e15988ac" + } + } + } + ], + "outputs": [ + "a85ef8701394b517a4b35217c4bd37ac01ebeed4b008f8d0879f9e09ba95319c" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "c8ac0292997b5bca98b3ebd99a57e253071137550f270452cd3df8a3e2266d36", + "pub_key": "a85ef8701394b517a4b35217c4bd37ac01ebeed4b008f8d0879f9e09ba95319c", + "signature": "c036ee38bfe46aba03234339ae7219b31b824b52ef9d5ce05810a0d6f62330dedc2b55652578aa5bdabf930fae941acd839d5a66f8fce7caa9710ccb446bddd1" + } + ] + } + } + ] + }, + { + "comment": "Single recipient: multiple UTXOs from the same public key", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "548ae55c8eec1e736e8d3e520f011f1f42a56d166116ad210b3937599f87f566" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + } + ], + "outputs": [ + "548ae55c8eec1e736e8d3e520f011f1f42a56d166116ad210b3937599f87f566" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "f032695e2636619efa523fffaa9ef93c8802299181fd0461913c1b8daf9784cd", + "pub_key": "548ae55c8eec1e736e8d3e520f011f1f42a56d166116ad210b3937599f87f566", + "signature": "f238386c5d5e5444f8d2c75aabbcb28c346f208c76f60823f5de3b67b79e0ec72ea5de2d7caec314e0971d3454f122dda342b3eede01b3857e83654e36b25f76" + } + ] + } + } + ] + }, + { + "comment": "Single recipient: taproot only inputs with even y-values", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140c459b671370d12cfb5acee76da7e3ba7cc29b0b4653e3af8388591082660137d087fdc8e89a612cd5d15be0febe61fc7cdcf3161a26e599a4514aa5c3e86f47b", + "prevout": { + "scriptPubKey": { + "hex": "51205a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140bd1e708f92dbeaf24a6b8dd22e59c6274355424d62baea976b449e220fd75b13578e262ab11b7aa58e037f0c6b0519b66803b7d9decaa1906dedebfb531c56c1", + "prevout": { + "scriptPubKey": { + "hex": "5120782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338" + } + }, + "private_key": "fc8716a97a48ba9a05a98ae47b5cd201a25a7fd5d8b73c203c5f7b6b6b3b6ad7" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "de88bea8e7ffc9ce1af30d1132f910323c505185aec8eae361670421e749a1fb" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140c459b671370d12cfb5acee76da7e3ba7cc29b0b4653e3af8388591082660137d087fdc8e89a612cd5d15be0febe61fc7cdcf3161a26e599a4514aa5c3e86f47b", + "prevout": { + "scriptPubKey": { + "hex": "51205a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140bd1e708f92dbeaf24a6b8dd22e59c6274355424d62baea976b449e220fd75b13578e262ab11b7aa58e037f0c6b0519b66803b7d9decaa1906dedebfb531c56c1", + "prevout": { + "scriptPubKey": { + "hex": "5120782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338" + } + } + } + ], + "outputs": [ + "de88bea8e7ffc9ce1af30d1132f910323c505185aec8eae361670421e749a1fb" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "3fb9ce5ce1746ced103c8ed254e81f6690764637ddbc876ec1f9b3ddab776b03", + "pub_key": "de88bea8e7ffc9ce1af30d1132f910323c505185aec8eae361670421e749a1fb", + "signature": "c5acd25a8f021a4192f93bc34403fd8b76484613466336fb259c72d04c169824f2690ca34e96cee86b69f376c8377003268fda56feeb1b873e5783d7e19bcca5" + } + ] + } + } + ] + }, + { + "comment": "Single recipient: taproot only with mixed even/odd y-values", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140c459b671370d12cfb5acee76da7e3ba7cc29b0b4653e3af8388591082660137d087fdc8e89a612cd5d15be0febe61fc7cdcf3161a26e599a4514aa5c3e86f47b", + "prevout": { + "scriptPubKey": { + "hex": "51205a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "", + "txinwitness": "01400a4d0dca6293f40499394d7eefe14a1de11e0e3454f51de2e802592abf5ee549042a1b1a8fb2e149ee9dd3f086c1b69b2f182565ab6ecf599b1ec9ebadfda6c5", + "prevout": { + "scriptPubKey": { + "hex": "51208c8d23d4764feffcd5e72e380802540fa0f88e3d62ad5e0b47955f74d7b283c4" + } + }, + "private_key": "1d37787c2b7116ee983e9f9c13269df29091b391c04db94239e0d2bc2182c3bf" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "77cab7dd12b10259ee82c6ea4b509774e33e7078e7138f568092241bf26b99f1" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140c459b671370d12cfb5acee76da7e3ba7cc29b0b4653e3af8388591082660137d087fdc8e89a612cd5d15be0febe61fc7cdcf3161a26e599a4514aa5c3e86f47b", + "prevout": { + "scriptPubKey": { + "hex": "51205a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "", + "txinwitness": "01400a4d0dca6293f40499394d7eefe14a1de11e0e3454f51de2e802592abf5ee549042a1b1a8fb2e149ee9dd3f086c1b69b2f182565ab6ecf599b1ec9ebadfda6c5", + "prevout": { + "scriptPubKey": { + "hex": "51208c8d23d4764feffcd5e72e380802540fa0f88e3d62ad5e0b47955f74d7b283c4" + } + } + } + ], + "outputs": [ + "77cab7dd12b10259ee82c6ea4b509774e33e7078e7138f568092241bf26b99f1" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "f5382508609771068ed079b24e1f72e4a17ee6d1c979066bf1d4e2a5676f09d4", + "pub_key": "77cab7dd12b10259ee82c6ea4b509774e33e7078e7138f568092241bf26b99f1", + "signature": "ff65833b8fd1ed3ef9d0443b4f702b45a3f2dd457ba247687e8207745c3be9d2bdad0ab3f07118f8b2efc6a04b95f7b3e218daf8a64137ec91bd2fc67fc137a5" + } + ] + } + } + ] + }, + { + "comment": "Single recipient: taproot input with even y-value and non-taproot input", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140c459b671370d12cfb5acee76da7e3ba7cc29b0b4653e3af8388591082660137d087fdc8e89a612cd5d15be0febe61fc7cdcf3161a26e599a4514aa5c3e86f47b", + "prevout": { + "scriptPubKey": { + "hex": "51205a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "463044021f24e010c6e475814740ba24c8cf9362c4db1276b7f46a7b1e63473159a80ec30221008198e8ece7b7f88e6c6cc6bb8c86f9f00b7458222a8c91addf6e1577bcf7697e2103e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9148cbc7dfe44f1579bff3340bbef1eddeaeb1fc97788ac" + } + }, + "private_key": "8d4751f6e8a3586880fb66c19ae277969bd5aa06f61c4ee2f1e2486efdf666d3" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "30523cca96b2a9ae3c98beb5e60f7d190ec5bc79b2d11a0b2d4d09a608c448f0" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140c459b671370d12cfb5acee76da7e3ba7cc29b0b4653e3af8388591082660137d087fdc8e89a612cd5d15be0febe61fc7cdcf3161a26e599a4514aa5c3e86f47b", + "prevout": { + "scriptPubKey": { + "hex": "51205a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "463044021f24e010c6e475814740ba24c8cf9362c4db1276b7f46a7b1e63473159a80ec30221008198e8ece7b7f88e6c6cc6bb8c86f9f00b7458222a8c91addf6e1577bcf7697e2103e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9148cbc7dfe44f1579bff3340bbef1eddeaeb1fc97788ac" + } + } + } + ], + "outputs": [ + "30523cca96b2a9ae3c98beb5e60f7d190ec5bc79b2d11a0b2d4d09a608c448f0" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "b40017865c79b1fcbed68896791be93186d08f47e416b289b8c063777e14e8df", + "pub_key": "30523cca96b2a9ae3c98beb5e60f7d190ec5bc79b2d11a0b2d4d09a608c448f0", + "signature": "d1edeea28cf1033bcb3d89376cabaaaa2886cbd8fda112b5c61cc90a4e7f1878bdd62180b07d1dfc8ffee1863c525a0c7b5bcd413183282cfda756cb65787266" + } + ] + } + } + ] + }, + { + "comment": "Single recipient: taproot input with odd y-value and non-taproot input", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "01400a4d0dca6293f40499394d7eefe14a1de11e0e3454f51de2e802592abf5ee549042a1b1a8fb2e149ee9dd3f086c1b69b2f182565ab6ecf599b1ec9ebadfda6c5", + "prevout": { + "scriptPubKey": { + "hex": "51208c8d23d4764feffcd5e72e380802540fa0f88e3d62ad5e0b47955f74d7b283c4" + } + }, + "private_key": "1d37787c2b7116ee983e9f9c13269df29091b391c04db94239e0d2bc2182c3bf" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "463044021f24e010c6e475814740ba24c8cf9362c4db1276b7f46a7b1e63473159a80ec30221008198e8ece7b7f88e6c6cc6bb8c86f9f00b7458222a8c91addf6e1577bcf7697e2103e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9148cbc7dfe44f1579bff3340bbef1eddeaeb1fc97788ac" + } + }, + "private_key": "8d4751f6e8a3586880fb66c19ae277969bd5aa06f61c4ee2f1e2486efdf666d3" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "359358f59ee9e9eec3f00bdf4882570fd5c182e451aa2650b788544aff012a3a" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "01400a4d0dca6293f40499394d7eefe14a1de11e0e3454f51de2e802592abf5ee549042a1b1a8fb2e149ee9dd3f086c1b69b2f182565ab6ecf599b1ec9ebadfda6c5", + "prevout": { + "scriptPubKey": { + "hex": "51208c8d23d4764feffcd5e72e380802540fa0f88e3d62ad5e0b47955f74d7b283c4" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "463044021f24e010c6e475814740ba24c8cf9362c4db1276b7f46a7b1e63473159a80ec30221008198e8ece7b7f88e6c6cc6bb8c86f9f00b7458222a8c91addf6e1577bcf7697e2103e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9148cbc7dfe44f1579bff3340bbef1eddeaeb1fc97788ac" + } + } + } + ], + "outputs": [ + "359358f59ee9e9eec3f00bdf4882570fd5c182e451aa2650b788544aff012a3a" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "a2f9dd05d1d398347c885d9c61a64d18a264de6d49cea4326bafc2791d627fa7", + "pub_key": "359358f59ee9e9eec3f00bdf4882570fd5c182e451aa2650b788544aff012a3a", + "signature": "96038ad233d8befe342573a6e54828d863471fb2afbad575cc65271a2a649480ea14912b6abbd3fbf92efc1928c036f6e3eef927105af4ec1dd57cb909f360b8" + } + ] + } + } + ] + }, + { + "comment": "Multiple outputs: multiple outputs, same recipient", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "e976a58fbd38aeb4e6093d4df02e9c1de0c4513ae0c588cef68cda5b2f8834ca", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "e976a58fbd38aeb4e6093d4df02e9c1de0c4513ae0c588cef68cda5b2f8834ca", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "d97e442d110c0bdd31161a7bb6e7862e038d02a09b1484dfbb463f2e0f7c9230", + "pub_key": "e976a58fbd38aeb4e6093d4df02e9c1de0c4513ae0c588cef68cda5b2f8834ca", + "signature": "29bd25d0f808d7fcd2aa6d5ed206053899198397506c301b218a9e47a3d7070af03e903ff718978d50d1b6b9af8cc0e313d84eda5d5b1e8e85e5516d630bbeb9" + }, + { + "priv_key_tweak": "33ce085c3c11eaad13694aae3c20301a6c83382ec89a7cde96c6799e2f88805a", + "pub_key": "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac", + "signature": "335667ca6cae7a26438f5cfdd73b3d48fa832fa9768521d7d5445f22c203ab0d74ed85088f27d29959ba627a4509996676f47df8ff284d292567b1beef0e3912" + } + ] + } + } + ] + }, + { + "comment": "Multiple outputs: multiple outputs, multiple recipients", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv", + "sp1qqgrz6j0lcqnc04vxccydl0kpsj4frfje0ktmgcl2t346hkw30226xqupawdf48k8882j0strrvcmgg2kdawz53a54dd376ngdhak364hzcmynqtn", + "sp1qqgrz6j0lcqnc04vxccydl0kpsj4frfje0ktmgcl2t346hkw30226xqupawdf48k8882j0strrvcmgg2kdawz53a54dd376ngdhak364hzcmynqtn" + ] + }, + "expected": { + "outputs": [ + [ + "2e847bb01d1b491da512ddd760b8509617ee38057003d6115d00ba562451323a", + "841792c33c9dc6193e76744134125d40add8f2f4a96475f28ba150be032d64e8", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "2e847bb01d1b491da512ddd760b8509617ee38057003d6115d00ba562451323a", + "841792c33c9dc6193e76744134125d40add8f2f4a96475f28ba150be032d64e8", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac" + ], + "key_material": { + "spend_priv_key": "9902c3c56e84002a7cd410113a9ab21d142be7f53cf5200720bb01314c5eb920", + "scan_priv_key": "060b751d7892149006ed7b98606955a29fe284a1e900070c0971f5fb93dbf422" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgrz6j0lcqnc04vxccydl0kpsj4frfje0ktmgcl2t346hkw30226xqupawdf48k8882j0strrvcmgg2kdawz53a54dd376ngdhak364hzcmynqtn" + ], + "outputs": [ + { + "priv_key_tweak": "72cd082cccb633bf85240a83494b32dc943a4d05647a6686d23ad4ca59c0ebe4", + "pub_key": "2e847bb01d1b491da512ddd760b8509617ee38057003d6115d00ba562451323a", + "signature": "38745f3d9f5eef0b1cfb17ca314efa8c521efab28a23aa20ec5e3abb561d42804d539906dce60c4ee7977966184e6f2cab1faa0e5377ceb7148ec5218b4e7878" + }, + { + "priv_key_tweak": "2f17ea873a0047fc01ba8010fef0969e76d0e4283f600d48f735098b1fee6eb9", + "pub_key": "841792c33c9dc6193e76744134125d40add8f2f4a96475f28ba150be032d64e8", + "signature": "c26f4e3cf371b90b840f48ea0e761b5ec31883ed55719f9ef06a90e282d85f565790ab780a3f491bc2668cc64e944dca849d1022a878cdadb8d168b8da4a6da3" + } + ] + } + } + ] + }, + { + "comment": "Receiving with labels: label with even parity", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjex54dmqmmv6rw353tsuqhs99ydvadxzrsy9nuvk74epvee55drs734pqq" + ] + }, + "expected": { + "outputs": [ + [ + "d014d4860f67d607d60b1af70e0ee236b99658b61bb769832acbbe87c374439a" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "d014d4860f67d607d60b1af70e0ee236b99658b61bb769832acbbe87c374439a" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [ + 2, + 3, + 1001337 + ] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjex54dmqmmv6rw353tsuqhs99ydvadxzrsy9nuvk74epvee55drs734pqq", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqsg59z2rppn4qlkx0yz9sdltmjv3j8zgcqadjn4ug98m3t6plujsq9qvu5n", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgq7c2zfthc6x3a5yecwc52nxa0kfd20xuz08zyrjpfw4l2j257yq6qgnkdh5" + ], + "outputs": [ + { + "priv_key_tweak": "51d4e9d0d482b5700109b4b2e16ff508269b03d800192a043d61dca4a0a72a52", + "pub_key": "d014d4860f67d607d60b1af70e0ee236b99658b61bb769832acbbe87c374439a", + "signature": "c30fa63bad6f0a317f39a773a5cbf0b0f8193c71dfebba05ee6ae4ed28e3775e6e04c3ea70a83703bb888122855dc894cab61692e7fd10c9b3494d479a60785e" + } + ] + } + } + ] + }, + { + "comment": "Receiving with labels: label with odd parity", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqsg59z2rppn4qlkx0yz9sdltmjv3j8zgcqadjn4ug98m3t6plujsq9qvu5n" + ] + }, + "expected": { + "outputs": [ + [ + "67626aebb3c4307cf0f6c39ca23247598fabf675ab783292eb2f81ae75ad1f8c" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "67626aebb3c4307cf0f6c39ca23247598fabf675ab783292eb2f81ae75ad1f8c" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [ + 2, + 3, + 1001337 + ] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjex54dmqmmv6rw353tsuqhs99ydvadxzrsy9nuvk74epvee55drs734pqq", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqsg59z2rppn4qlkx0yz9sdltmjv3j8zgcqadjn4ug98m3t6plujsq9qvu5n", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgq7c2zfthc6x3a5yecwc52nxa0kfd20xuz08zyrjpfw4l2j257yq6qgnkdh5" + ], + "outputs": [ + { + "priv_key_tweak": "6024ae214876356b8d917716e7707d267ae16a0fdb07de2a786b74a7bbcddead", + "pub_key": "67626aebb3c4307cf0f6c39ca23247598fabf675ab783292eb2f81ae75ad1f8c", + "signature": "a86d554d0d6b7aa0907155f7e0b47f0182752472fffaeddd68da90e99b9402f166fd9b33039c302c7115098d971c1399e67c19e9e4de180b10ea0b9d6f0db832" + } + ] + } + } + ] + }, + { + "comment": "Receiving with labels: large label integer", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgq7c2zfthc6x3a5yecwc52nxa0kfd20xuz08zyrjpfw4l2j257yq6qgnkdh5" + ] + }, + "expected": { + "outputs": [ + [ + "7efa60ce78ac343df8a013a2027c6c5ef29f9502edcbd769d2c21717fecc5951" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "7efa60ce78ac343df8a013a2027c6c5ef29f9502edcbd769d2c21717fecc5951" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [ + 2, + 3, + 1001337 + ] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjex54dmqmmv6rw353tsuqhs99ydvadxzrsy9nuvk74epvee55drs734pqq", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqsg59z2rppn4qlkx0yz9sdltmjv3j8zgcqadjn4ug98m3t6plujsq9qvu5n", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgq7c2zfthc6x3a5yecwc52nxa0kfd20xuz08zyrjpfw4l2j257yq6qgnkdh5" + ], + "outputs": [ + { + "priv_key_tweak": "e336b92330c33030285ce42e4115ad92d5197913c88e06b9072b4a9b47c664a2", + "pub_key": "7efa60ce78ac343df8a013a2027c6c5ef29f9502edcbd769d2c21717fecc5951", + "signature": "c9e80dd3bdd25ca2d352ce77510f1aed37ba3509dc8cc0677f2d7c2dd04090707950ce9dd6c83d2a428063063aff5c04f1744e334f661f2fc01b4ef80b50f739" + } + ] + } + } + ] + }, + { + "comment": "Multiple outputs with labels: un-labeled and labeled address; same recipient", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqaxww2fnhrx05cghth75n0qcj59e3e2anscr0q9wyknjxtxycg07y3pevyj", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac" + ], + [ + "83dc944e61603137294829aed56c74c9b087d80f2c021b98a7fae5799000696c", + "e976a58fbd38aeb4e6093d4df02e9c1de0c4513ae0c588cef68cda5b2f8834ca" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [ + 1 + ] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqaxww2fnhrx05cghth75n0qcj59e3e2anscr0q9wyknjxtxycg07y3pevyj" + ], + "outputs": [ + { + "priv_key_tweak": "43100f89f1a6bf10081c92b473ffc57ceac7dbed600b6aba9bb3976f17dbb914", + "pub_key": "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "signature": "15c92509b67a6c211ebb4a51b7528d0666e6720de2343b2e92cfb97942ca14693c1f1fdc8451acfdb2644039f8f5c76114807fdc3d3a002d8a46afab6756bd75" + }, + { + "priv_key_tweak": "33ce085c3c11eaad13694aae3c20301a6c83382ec89a7cde96c6799e2f88805a", + "pub_key": "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac", + "signature": "335667ca6cae7a26438f5cfdd73b3d48fa832fa9768521d7d5445f22c203ab0d74ed85088f27d29959ba627a4509996676f47df8ff284d292567b1beef0e3912" + } + ] + } + } + ] + }, + { + "comment": "Multiple outputs with labels: multiple outputs for labeled address; same recipient", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqaxww2fnhrx05cghth75n0qcj59e3e2anscr0q9wyknjxtxycg07y3pevyj", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqaxww2fnhrx05cghth75n0qcj59e3e2anscr0q9wyknjxtxycg07y3pevyj" + ] + }, + "expected": { + "outputs": [ + [ + "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "83dc944e61603137294829aed56c74c9b087d80f2c021b98a7fae5799000696c" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "83dc944e61603137294829aed56c74c9b087d80f2c021b98a7fae5799000696c" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [ + 1 + ] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqaxww2fnhrx05cghth75n0qcj59e3e2anscr0q9wyknjxtxycg07y3pevyj" + ], + "outputs": [ + { + "priv_key_tweak": "43100f89f1a6bf10081c92b473ffc57ceac7dbed600b6aba9bb3976f17dbb914", + "pub_key": "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "signature": "15c92509b67a6c211ebb4a51b7528d0666e6720de2343b2e92cfb97942ca14693c1f1fdc8451acfdb2644039f8f5c76114807fdc3d3a002d8a46afab6756bd75" + }, + { + "priv_key_tweak": "9d5fd3b91cac9ddfea6fc2e6f9386f680e6cee623cda02f53706306c081de87f", + "pub_key": "83dc944e61603137294829aed56c74c9b087d80f2c021b98a7fae5799000696c", + "signature": "db0dfacc98b6a6fcc67cc4631f080b1ca38c60d8c397f2f19843f8f95ec91594b24e47c5bd39480a861c1209f7e3145c440371f9191fb96e324690101eac8e8e" + } + ] + } + } + ] + }, + { + "comment": "Multiple outputs with labels: un-labeled, labeled, and multiple outputs for labeled address; same recipients", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqaxww2fnhrx05cghth75n0qcj59e3e2anscr0q9wyknjxtxycg07y3pevyj", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjyh2ju7hd5gj57jg5r9lev3pckk4n2shtzaq34467erzzdfajfggty6aa5", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjyh2ju7hd5gj57jg5r9lev3pckk4n2shtzaq34467erzzdfajfggty6aa5" + ] + }, + "expected": { + "outputs": [ + [ + "006a02c308ccdbf3ac49f0638f6de128f875db5a213095cf112b3b77722472ae", + "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "ae1a780c04237bd577283c3ddb2e499767c3214160d5a6b0767e6b8c278bd701", + "ca64abe1e0f737823fb9a94f597eed418fb2df77b1317e26b881a14bb594faaa" + ], + [ + "006a02c308ccdbf3ac49f0638f6de128f875db5a213095cf112b3b77722472ae", + "3edf1ff6657c6e69568811bd726a7a7f480493aa42161acfe8dd4f44521f99ed", + "7ee1543ed5d123ffa66fbebc128c020173eb490d5fa2ba306e0c9573a77db8f3", + "ca64abe1e0f737823fb9a94f597eed418fb2df77b1317e26b881a14bb594faaa" + ], + [ + "006a02c308ccdbf3ac49f0638f6de128f875db5a213095cf112b3b77722472ae", + "7ee1543ed5d123ffa66fbebc128c020173eb490d5fa2ba306e0c9573a77db8f3", + "83dc944e61603137294829aed56c74c9b087d80f2c021b98a7fae5799000696c", + "ae1a780c04237bd577283c3ddb2e499767c3214160d5a6b0767e6b8c278bd701" + ], + [ + "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "3c54444944d176437644378c23efb999ab6ab1cacdfe1dc1537b607e3df330e2", + "ca64abe1e0f737823fb9a94f597eed418fb2df77b1317e26b881a14bb594faaa", + "f4569fc5f69c10f0082cfbb8e072e6266ec55f69fba8cffca4cbb4c144b7e59b" + ], + [ + "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "ae1a780c04237bd577283c3ddb2e499767c3214160d5a6b0767e6b8c278bd701", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac", + "f4569fc5f69c10f0082cfbb8e072e6266ec55f69fba8cffca4cbb4c144b7e59b" + ], + [ + "3c54444944d176437644378c23efb999ab6ab1cacdfe1dc1537b607e3df330e2", + "602e10e6944107c9b48bd885b493676578c935723287e0ab2f8b7f136862568e", + "7ee1543ed5d123ffa66fbebc128c020173eb490d5fa2ba306e0c9573a77db8f3", + "ca64abe1e0f737823fb9a94f597eed418fb2df77b1317e26b881a14bb594faaa" + ], + [ + "3c54444944d176437644378c23efb999ab6ab1cacdfe1dc1537b607e3df330e2", + "7ee1543ed5d123ffa66fbebc128c020173eb490d5fa2ba306e0c9573a77db8f3", + "83dc944e61603137294829aed56c74c9b087d80f2c021b98a7fae5799000696c", + "f4569fc5f69c10f0082cfbb8e072e6266ec55f69fba8cffca4cbb4c144b7e59b" + ], + [ + "3edf1ff6657c6e69568811bd726a7a7f480493aa42161acfe8dd4f44521f99ed", + "7ee1543ed5d123ffa66fbebc128c020173eb490d5fa2ba306e0c9573a77db8f3", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac", + "f4569fc5f69c10f0082cfbb8e072e6266ec55f69fba8cffca4cbb4c144b7e59b" + ], + [ + "3edf1ff6657c6e69568811bd726a7a7f480493aa42161acfe8dd4f44521f99ed", + "ca64abe1e0f737823fb9a94f597eed418fb2df77b1317e26b881a14bb594faaa", + "e976a58fbd38aeb4e6093d4df02e9c1de0c4513ae0c588cef68cda5b2f8834ca", + "f4569fc5f69c10f0082cfbb8e072e6266ec55f69fba8cffca4cbb4c144b7e59b" + ], + [ + "602e10e6944107c9b48bd885b493676578c935723287e0ab2f8b7f136862568e", + "7ee1543ed5d123ffa66fbebc128c020173eb490d5fa2ba306e0c9573a77db8f3", + "ae1a780c04237bd577283c3ddb2e499767c3214160d5a6b0767e6b8c278bd701", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac" + ], + [ + "602e10e6944107c9b48bd885b493676578c935723287e0ab2f8b7f136862568e", + "ae1a780c04237bd577283c3ddb2e499767c3214160d5a6b0767e6b8c278bd701", + "ca64abe1e0f737823fb9a94f597eed418fb2df77b1317e26b881a14bb594faaa", + "e976a58fbd38aeb4e6093d4df02e9c1de0c4513ae0c588cef68cda5b2f8834ca" + ], + [ + "83dc944e61603137294829aed56c74c9b087d80f2c021b98a7fae5799000696c", + "ae1a780c04237bd577283c3ddb2e499767c3214160d5a6b0767e6b8c278bd701", + "e976a58fbd38aeb4e6093d4df02e9c1de0c4513ae0c588cef68cda5b2f8834ca", + "f4569fc5f69c10f0082cfbb8e072e6266ec55f69fba8cffca4cbb4c144b7e59b" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "006a02c308ccdbf3ac49f0638f6de128f875db5a213095cf112b3b77722472ae", + "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "ae1a780c04237bd577283c3ddb2e499767c3214160d5a6b0767e6b8c278bd701", + "ca64abe1e0f737823fb9a94f597eed418fb2df77b1317e26b881a14bb594faaa" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [ + 1, + 1337 + ] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqaxww2fnhrx05cghth75n0qcj59e3e2anscr0q9wyknjxtxycg07y3pevyj", + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjyh2ju7hd5gj57jg5r9lev3pckk4n2shtzaq34467erzzdfajfggty6aa5" + ], + "outputs": [ + { + "priv_key_tweak": "4e3352fbe0505c25e718d96007c259ef08db34f8c844e4ff742d9855ff03805a", + "pub_key": "006a02c308ccdbf3ac49f0638f6de128f875db5a213095cf112b3b77722472ae", + "signature": "6eeae1ea9eb826e3d0e812f65937100e0836ea188c04f36fabc4981eda29de8d3d3529390a0a8b3d830f7bca4f5eae5994b9788ddaf05ad259ffe26d86144b4b" + }, + { + "priv_key_tweak": "43100f89f1a6bf10081c92b473ffc57ceac7dbed600b6aba9bb3976f17dbb914", + "pub_key": "39f42624d5c32a77fda80ff0acee269afec601d3791803e80252ae04e4ffcf4c", + "signature": "15c92509b67a6c211ebb4a51b7528d0666e6720de2343b2e92cfb97942ca14693c1f1fdc8451acfdb2644039f8f5c76114807fdc3d3a002d8a46afab6756bd75" + }, + { + "priv_key_tweak": "bf709f98d4418f8a67e738154ae48818dad44689cd37fbc070891a396dd1c633", + "pub_key": "ae1a780c04237bd577283c3ddb2e499767c3214160d5a6b0767e6b8c278bd701", + "signature": "42a19fd8a63dde1824966a95d65a28203e631e49bf96ca5dae1b390e7a0ace2cc8709c9b0c5715047032f57f536a3c80273cbecf4c05be0b5456c183fa122c06" + }, + { + "priv_key_tweak": "736f05e4e3072c3b8656bedef2e9bf54cbcaa2b6fe5320d3e86f5b96874dda71", + "pub_key": "ca64abe1e0f737823fb9a94f597eed418fb2df77b1317e26b881a14bb594faaa", + "signature": "2e61bb3d79418ecf55f68847cf121bfc12d397b39d1da8643246b2f0a9b96c3daa4bfe9651beb5c9ce20e1f29282c4566400a4b45ee6657ec3b18fdc554da0b4" + } + ] + } + } + ] + }, + { + "comment": "Single recipient: use silent payments for sender change", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv", + "sp1qqw6vczcfpdh5nf5y2ky99kmqae0tr30hgdfg88parz50cp80wd2wqqlv6saelkk5snl4wfutyxrchpzzwm8rjp3z6q7apna59z9huq4x754e5atr" + ] + }, + "expected": { + "outputs": [ + [ + "be368e28979d950245d742891ae6064020ba548c1e2e65a639a8bb0675d95cff", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "be368e28979d950245d742891ae6064020ba548c1e2e65a639a8bb0675d95cff", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac" + ], + "key_material": { + "spend_priv_key": "b8f87388cbb41934c50daca018901b00070a5ff6cc25a7e9e716a9d5b9e4d664", + "scan_priv_key": "11b7a82e06ca2648d5fded2366478078ec4fc9dc1d8ff487518226f229d768fd" + }, + "labels": [ + 0 + ] + }, + "expected": { + "addresses": [ + "sp1qqw6vczcfpdh5nf5y2ky99kmqae0tr30hgdfg88parz50cp80wd2wqqauj52ymtc4xdkmx3tgyhrsemg2g3303xk2gtzfy8h8ejet8fz8jcw23zua", + "sp1qqw6vczcfpdh5nf5y2ky99kmqae0tr30hgdfg88parz50cp80wd2wqqlv6saelkk5snl4wfutyxrchpzzwm8rjp3z6q7apna59z9huq4x754e5atr" + ], + "outputs": [ + { + "priv_key_tweak": "80cd767ed20bd0bb7d8ea5e803f8c381293a62e8a073cf46fb0081da46e64e1f", + "pub_key": "be368e28979d950245d742891ae6064020ba548c1e2e65a639a8bb0675d95cff", + "signature": "7fbd5074cf1377273155eefafc7c330cb61b31da252f22206ac27530d2b2567040d9af7808342ed4a09598c26d8307446e4ed77079e6a2e61fea736e44da5f5a" + } + ] + } + }, + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "be368e28979d950245d742891ae6064020ba548c1e2e65a639a8bb0675d95cff", + "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "33ce085c3c11eaad13694aae3c20301a6c83382ec89a7cde96c6799e2f88805a", + "pub_key": "f207162b1a7abc51c42017bef055e9ec1efc3d3567cb720357e2b84325db33ac", + "signature": "335667ca6cae7a26438f5cfdd73b3d48fa832fa9768521d7d5445f22c203ab0d74ed85088f27d29959ba627a4509996676f47df8ff284d292567b1beef0e3912" + } + ] + } + } + ] + }, + { + "comment": "Single recipient: taproot input with NUMS point", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "0440c459b671370d12cfb5acee76da7e3ba7cc29b0b4653e3af8388591082660137d087fdc8e89a612cd5d15be0febe61fc7cdcf3161a26e599a4514aa5c3e86f47b22205a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5ac21c150929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac00150", + "prevout": { + "scriptPubKey": { + "hex": "5120da6f0595ecb302bbe73e2f221f05ab10f336b06817d36fd28fc6691725ddaa85" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140bd1e708f92dbeaf24a6b8dd22e59c6274355424d62baea976b449e220fd75b13578e262ab11b7aa58e037f0c6b0519b66803b7d9decaa1906dedebfb531c56c1", + "prevout": { + "scriptPubKey": { + "hex": "5120782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338" + } + }, + "private_key": "fc8716a97a48ba9a05a98ae47b5cd201a25a7fd5d8b73c203c5f7b6b6b3b6ad7" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 1, + "scriptSig": "", + "txinwitness": "0340268d31a9276f6380107d5321cafa6d9e8e5ea39204318fdc8206b31507c891c3bbcea3c99e2208d73bd127a8e8c5f1e45a54f1bd217205414ddb566ab7eda0092220e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85dac21c150929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0", + "prevout": { + "scriptPubKey": { + "hex": "51200a3c9365ceb131f89b0a4feb6896ebd67bb15a98c31eaa3da143bb955a0f3fcb" + } + }, + "private_key": "8d4751f6e8a3586880fb66c19ae277969bd5aa06f61c4ee2f1e2486efdf666d3" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "79e79897c52935bfd97fc6e076a6431a0c7543ca8c31e0fc3cf719bb572c842d" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "0440c459b671370d12cfb5acee76da7e3ba7cc29b0b4653e3af8388591082660137d087fdc8e89a612cd5d15be0febe61fc7cdcf3161a26e599a4514aa5c3e86f47b22205a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5ac21c150929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac00150", + "prevout": { + "scriptPubKey": { + "hex": "5120da6f0595ecb302bbe73e2f221f05ab10f336b06817d36fd28fc6691725ddaa85" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140bd1e708f92dbeaf24a6b8dd22e59c6274355424d62baea976b449e220fd75b13578e262ab11b7aa58e037f0c6b0519b66803b7d9decaa1906dedebfb531c56c1", + "prevout": { + "scriptPubKey": { + "hex": "5120782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 1, + "scriptSig": "", + "txinwitness": "0340268d31a9276f6380107d5321cafa6d9e8e5ea39204318fdc8206b31507c891c3bbcea3c99e2208d73bd127a8e8c5f1e45a54f1bd217205414ddb566ab7eda0092220e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85dac21c150929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0", + "prevout": { + "scriptPubKey": { + "hex": "51200a3c9365ceb131f89b0a4feb6896ebd67bb15a98c31eaa3da143bb955a0f3fcb" + } + } + } + ], + "outputs": [ + "79e79897c52935bfd97fc6e076a6431a0c7543ca8c31e0fc3cf719bb572c842d" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "3ddec3232609d348d6b8b53123b4f40f6d4f5398ca586f087b0416ec3b851496", + "pub_key": "79e79897c52935bfd97fc6e076a6431a0c7543ca8c31e0fc3cf719bb572c842d", + "signature": "d7d06e3afb68363031e4eb18035c46ceae41bdbebe7888a4754bc9848c596436869aeaecff0527649a1f458b71c9ceecec10b535c09d01d720229aa228547706" + } + ] + } + } + ] + }, + { + "comment": "Pubkey extraction from malleated p2pkh", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 1, + "scriptSig": "0075473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 2, + "scriptSig": "5163473045022100e7d26e77290b37128f5215ade25b9b908ce87cc9a4d498908b5bb8fd6daa1b8d022002568c3a8226f4f0436510283052bfb780b76f3fe4aa60c4c5eb118e43b187372102e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d67483046022100c0d3c851d3bd562ae93d56bcefd735ea57c027af46145a4d5e9cac113bfeb0c2022100ee5b2239af199fa9b7aa1d98da83a29d0a2cf1e4f29e2f37134ce386d51c544c2102ad0f26ddc7b3fcc340155963b3051b85289c1869612ecb290184ac952e2864ec68", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914c82c5ec473cbc6c86e5ef410e36f9495adcf979988ac" + } + }, + "private_key": "72b8ae09175ca7977f04993e651d88681ed932dfb92c5158cdf0161dd23fda6e" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "4612cdbf845c66c7511d70aab4d9aed11e49e48cdb8d799d787101cdd0d53e4f" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 1, + "scriptSig": "0075473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 2, + "scriptSig": "5163473045022100e7d26e77290b37128f5215ade25b9b908ce87cc9a4d498908b5bb8fd6daa1b8d022002568c3a8226f4f0436510283052bfb780b76f3fe4aa60c4c5eb118e43b187372102e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d67483046022100c0d3c851d3bd562ae93d56bcefd735ea57c027af46145a4d5e9cac113bfeb0c2022100ee5b2239af199fa9b7aa1d98da83a29d0a2cf1e4f29e2f37134ce386d51c544c2102ad0f26ddc7b3fcc340155963b3051b85289c1869612ecb290184ac952e2864ec68", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914c82c5ec473cbc6c86e5ef410e36f9495adcf979988ac" + } + } + } + ], + "outputs": [ + "4612cdbf845c66c7511d70aab4d9aed11e49e48cdb8d799d787101cdd0d53e4f" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "10bde9781def20d7701e7603ef1b1e5e71c67bae7154818814e3c81ef5b1a3d3", + "pub_key": "4612cdbf845c66c7511d70aab4d9aed11e49e48cdb8d799d787101cdd0d53e4f", + "signature": "6137969f810e9e8ef6c9755010e808f5dd1aed705882e44d7f0ae64eb0c509ec8b62a0671bee0d5914ac27d2c463443e28e999d82dc3d3a4919f093872d947bb" + } + ] + } + } + ] + }, + { + "comment": "P2PKH and P2WPKH Uncompressed Keys are skipped", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b974104782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c3799373233387c5343bf58e23269e903335b958a12182f9849297321e8d710e49a8727129cab", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9144b92ac4ac6fe6212393894addda332f2e47a315688ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 1, + "scriptSig": "", + "txinwitness": "02473045022100e7d26e77290b37128f5215ade25b9b908ce87cc9a4d498908b5bb8fd6daa1b8d022002568c3a8226f4f0436510283052bfb780b76f3fe4aa60c4c5eb118e43b187374104e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d6fe8190e189be57d0d5bcd17dbcbcd04c9b4a1c5f605b10d5c90abfcc0d12884", + "prevout": { + "scriptPubKey": { + "hex": "00140423f731a07491364e8dce98b7c00bda63336950" + } + }, + "private_key": "72b8ae09175ca7977f04993e651d88681ed932dfb92c5158cdf0161dd23fda6e" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "67fee277da9e8542b5d2e6f32d660a9bbd3f0e107c2d53638ab1d869088882d6" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a91419c2f3ae0ca3b642bd3e49598b8da89f50c1416188ac" + } + } + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b974104782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c3799373233387c5343bf58e23269e903335b958a12182f9849297321e8d710e49a8727129cab", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9144b92ac4ac6fe6212393894addda332f2e47a315688ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 1, + "scriptSig": "", + "txinwitness": "02473045022100e7d26e77290b37128f5215ade25b9b908ce87cc9a4d498908b5bb8fd6daa1b8d022002568c3a8226f4f0436510283052bfb780b76f3fe4aa60c4c5eb118e43b187374104e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d6fe8190e189be57d0d5bcd17dbcbcd04c9b4a1c5f605b10d5c90abfcc0d12884", + "prevout": { + "scriptPubKey": { + "hex": "00140423f731a07491364e8dce98b7c00bda63336950" + } + } + } + ], + "outputs": [ + "67fee277da9e8542b5d2e6f32d660a9bbd3f0e107c2d53638ab1d869088882d6" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "688fa3aeb97d2a46ae87b03591921c2eaf4b505eb0ddca2733c94701e01060cf", + "pub_key": "67fee277da9e8542b5d2e6f32d660a9bbd3f0e107c2d53638ab1d869088882d6", + "signature": "72e7ad573ac23255d4651d5b0326a200496588acb7a4894b22092236d5eda6a0a9a4d8429b022c2219081fefce5b33795cae488d10f5ea9438849ed8353624f2" + } + ] + } + } + ] + }, + { + "comment": "Skip invalid P2SH inputs", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "16001419c2f3ae0ca3b642bd3e49598b8da89f50c14161", + "txinwitness": "02483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "prevout": { + "scriptPubKey": { + "hex": "a9148629db5007d5fcfbdbb466637af09daf9125969387" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 1, + "scriptSig": "1600144b92ac4ac6fe6212393894addda332f2e47a3156", + "txinwitness": "02473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b974104782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c3799373233387c5343bf58e23269e903335b958a12182f9849297321e8d710e49a8727129cab", + "prevout": { + "scriptPubKey": { + "hex": "a9146c9bf136fbb7305fd99d771a95127fcf87dedd0d87" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 2, + "scriptSig": "00493046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d601483045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b97014c695221025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be52103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c3799373233382102e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d53ae", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "a9141044ddc6cea09e4ac40fbec2ba34ad62de6db25b87" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [ + "67fee277da9e8542b5d2e6f32d660a9bbd3f0e107c2d53638ab1d869088882d6" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "16001419c2f3ae0ca3b642bd3e49598b8da89f50c14161", + "txinwitness": "02483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d621025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5", + "prevout": { + "scriptPubKey": { + "hex": "a9148629db5007d5fcfbdbb466637af09daf9125969387" + } + } + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 1, + "scriptSig": "1600144b92ac4ac6fe6212393894addda332f2e47a3156", + "txinwitness": "02473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b974104782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c3799373233387c5343bf58e23269e903335b958a12182f9849297321e8d710e49a8727129cab", + "prevout": { + "scriptPubKey": { + "hex": "a9146c9bf136fbb7305fd99d771a95127fcf87dedd0d87" + } + } + }, + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 2, + "scriptSig": "00493046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d601483045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b97014c695221025a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be52103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c3799373233382102e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d53ae", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "a9141044ddc6cea09e4ac40fbec2ba34ad62de6db25b87" + } + } + } + ], + "outputs": [ + "67fee277da9e8542b5d2e6f32d660a9bbd3f0e107c2d53638ab1d869088882d6" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [ + { + "priv_key_tweak": "688fa3aeb97d2a46ae87b03591921c2eaf4b505eb0ddca2733c94701e01060cf", + "pub_key": "67fee277da9e8542b5d2e6f32d660a9bbd3f0e107c2d53638ab1d869088882d6", + "signature": "72e7ad573ac23255d4651d5b0326a200496588acb7a4894b22092236d5eda6a0a9a4d8429b022c2219081fefce5b33795cae488d10f5ea9438849ed8353624f2" + } + ] + } + } + ] + }, + { + "comment": "Recipient ignores unrelated outputs", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140c459b671370d12cfb5acee76da7e3ba7cc29b0b4653e3af8388591082660137d087fdc8e89a612cd5d15be0febe61fc7cdcf3161a26e599a4514aa5c3e86f47b", + "prevout": { + "scriptPubKey": { + "hex": "51205a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgrz6j0lcqnc04vxccydl0kpsj4frfje0ktmgcl2t346hkw30226xqupawdf48k8882j0strrvcmgg2kdawz53a54dd376ngdhak364hzcmynqtn" + ] + }, + "expected": { + "outputs": [ + [ + "841792c33c9dc6193e76744134125d40add8f2f4a96475f28ba150be032d64e8" + ] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "", + "txinwitness": "0140c459b671370d12cfb5acee76da7e3ba7cc29b0b4653e3af8388591082660137d087fdc8e89a612cd5d15be0febe61fc7cdcf3161a26e599a4514aa5c3e86f47b", + "prevout": { + "scriptPubKey": { + "hex": "51205a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b972103782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9147cdd63cc408564188e8e472640e921c7c90e651d88ac" + } + } + } + ], + "outputs": [ + "841792c33c9dc6193e76744134125d40add8f2f4a96475f28ba150be032d64e8", + "782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [] + } + } + ] + }, + { + "comment": "No valid inputs, sender generates no outputs", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d641045a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5c61836c9b1688ba431f7ea3039742251f62f0dca3da1bee58a47fa9b456c2d52", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914460e8b41545d2dbe7e0671f0f573e2232814260a88ac" + } + }, + "private_key": "eadc78165ff1f8ea94ad7cfdc54990738a4c53f6e0507b42154201b8e5dff3b1" + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b974104782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c3799373233387c5343bf58e23269e903335b958a12182f9849297321e8d710e49a8727129cab", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9144b92ac4ac6fe6212393894addda332f2e47a315688ac" + } + }, + "private_key": "0378e95685b74565fa56751b84a32dfd18545d10d691641b8372e32164fad66a" + } + ], + "recipients": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ] + }, + "expected": { + "outputs": [ + [] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16", + "vout": 0, + "scriptSig": "483046022100ad79e6801dd9a8727f342f31c71c4912866f59dc6e7981878e92c5844a0ce929022100fb0d2393e813968648b9753b7e9871d90ab3d815ebf91820d704b19f4ed224d641045a1e61f898173040e20616d43e9f496fba90338a39faa1ed98fcbaeee4dd9be5c61836c9b1688ba431f7ea3039742251f62f0dca3da1bee58a47fa9b456c2d52", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a914460e8b41545d2dbe7e0671f0f573e2232814260a88ac" + } + } + }, + { + "txid": "a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d", + "vout": 0, + "scriptSig": "473045022100a8c61b2d470e393279d1ba54f254b7c237de299580b7fa01ffcc940442ecec4502201afba952f4e4661c40acde7acc0341589031ba103a307b886eb867b23b850b974104782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c3799373233387c5343bf58e23269e903335b958a12182f9849297321e8d710e49a8727129cab", + "txinwitness": "", + "prevout": { + "scriptPubKey": { + "hex": "76a9144b92ac4ac6fe6212393894addda332f2e47a315688ac" + } + } + } + ], + "outputs": [ + "782eeb913431ca6e9b8c2fd80a5f72ed2024ef72a3c6fb10263c379937323338", + "e0ec4f64b3fa2e463ccfcf4e856e37d5e1e20275bc89ec1def9eb098eff1f85d" + ], + "key_material": { + "spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3", + "scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv" + ], + "outputs": [] + } + } + ] + } +]
\ No newline at end of file diff --git a/bip-0370.mediawiki b/bip-0370.mediawiki index cb59801..98f1800 100644 --- a/bip-0370.mediawiki +++ b/bip-0370.mediawiki @@ -2,7 +2,7 @@ BIP: 370 Layer: Applications Title: PSBT Version 2 - Author: Andrew Chow <achow101@gmail.com> + Author: Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0370 Status: Draft @@ -248,7 +248,7 @@ Before any input or output may be added, the constructor must check the PSBT_GLO Inputs may only be added if the Inputs Modifiable flag is True. Outputs may only be added if the Outputs Modifiable flag is True. -When an input or output is added, the corresponding PSBT_GLOBAL_INPUT_COUNT or PSBT_GLOBAL_OUTPUT_COUNT must be incremeted to reflect the number of inputs and outputs in the PSBT. +When an input or output is added, the corresponding PSBT_GLOBAL_INPUT_COUNT or PSBT_GLOBAL_OUTPUT_COUNT must be incremented to reflect the number of inputs and outputs in the PSBT. When an input is added, it must have PSBT_IN_PREVIOUS_TXID and PSBT_IN_OUTPUT_INDEX set. When an output is added, it must have PSBT_OUT_VALUE and PSBT_OUT_OUTPUT_SCRIPT set. If the input has a required timelock, Constructors must set the requisite timelock field. diff --git a/bip-0371.mediawiki b/bip-0371.mediawiki index 599aa54..45b69f8 100644 --- a/bip-0371.mediawiki +++ b/bip-0371.mediawiki @@ -2,7 +2,7 @@ BIP: 371 Layer: Applications Title: Taproot Fields for PSBT - Author: Andrew Chow <andrew@achow101.com> + Author: Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0371 Status: Draft diff --git a/bip-0380.mediawiki b/bip-0380.mediawiki index 16a2cf4..27b7908 100644 --- a/bip-0380.mediawiki +++ b/bip-0380.mediawiki @@ -3,7 +3,7 @@ Layer: Applications Title: Output Script Descriptors General Operation Author: Pieter Wuille <pieter@wuille.net> - Andrew Chow <andrew@achow101.com> + Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0380 Status: Draft @@ -26,7 +26,7 @@ This BIP is licensed under the BSD 2-clause license. Bitcoin wallets traditionally have stored a set of keys which are later serialized and mutated to produce the output scripts that the wallet watches and the addresses it provides to users. Typically backups have consisted of solely the private keys, nowadays primarily in the form of BIP 39 mnemonics. -However this backup solution is insuffient, especially since the introduction of Segregated Witness which added new output types. +However this backup solution is insufficient, especially since the introduction of Segregated Witness which added new output types. Given just the private keys, it is not possible for restored wallets to know which kinds of output scripts and addresses to produce. This has lead to incompatibilities between wallets when restoring a backup or exporting data for a watch only wallet. @@ -199,6 +199,63 @@ def descsum_create(s): </pre> +==Test Vectors== + +The following tests cover the checksum and character set: + +* Valid checksum: <tt>raw(deadbeef)#89f8spxm</tt> +* No checksum: <tt>raw(deadbeef)</tt> +* Missing checksum: <tt>raw(deadbeef)#</tt> +* Too long checksum (9 chars): <tt>raw(deadbeef)#89f8spxmx</tt> +* Too short checksum (7 chars): <tt>raw(deadbeef)#89f8spx</tt> +* Error in payload: <tt>raw(deedbeef)#89f8spxm</tt> +* Error in checksum: <tt>raw(deedbeef)##9f8spxm</tt> +* Invalid characters in payload: <tt>raw(Ü)#00000000</tt> + +The following tests cover key expressions: + +Valid expressions: + +* Compressed public key: <tt>0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* Uncompressed public key: <tt>04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235</tt> +* Public key with key origin: <tt>[deadbeef/0h/0h/0h]0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* Public key with key origin (<tt>'</tt> as hardened indicator): <tt>[deadbeef/0'/0'/0']0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* Public key with key origin (mixed hardened indicator): <tt>[deadbeef/0'/0h/0']0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* WIF uncompressed private key <tt>5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss</tt> +* WIF compressed private key <tt>L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1</tt> +* Extended public key: <tt>xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL</tt> +* Extended public key with key origin: <tt>[deadbeef/0h/1h/2h]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL</tt> +* Extended public key with derivation: <tt>[deadbeef/0h/1h/2h]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/3/4/5</tt> +* Extended public key with derivation and children: <tt>[deadbeef/0h/1h/2h]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/3/4/5/*</tt> +* Extended public key with hardened derivation and unhardened children: <tt>xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/3h/4h/5h/*</tt> +* Extended public key with hardened derivation and children: <tt>xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/3h/4h/5h/*h</tt> +* Extended public key with key origin, hardened derivation and children: <tt>[deadbeef/0h/1h/2]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/3h/4h/5h/*h</tt> +* Extended private key: <tt>xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc</tt> +* Extended private key with key origin: <tt>[deadbeef/0h/1h/2h]xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc</tt> +* Extended private key with derivation: <tt>[deadbeef/0h/1h/2h]xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc/3/4/5</tt> +* Extended private key with derivation and children: <tt>[deadbeef/0h/1h/2h]xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc/3/4/5/*</tt> +* Extended private key with hardened derivation and unhardened children: <tt>xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc/3h/4h/5h/*</tt> +* Extended private key with hardened derivation and children: <tt>xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc/3h/4h/5h/*h</tt> +* Extended private key with key origin, hardened derivation and children: <tt>[deadbeef/0h/1h/2]xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc/3h/4h/5h/*h</tt> + +Invalid expression: + +* Children indicator in key origin: <tt>[deadbeef/0h/0h/0h/*]0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* Trailing slash in key origin: <tt>[deadbeef/0h/0h/0h/]0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* Too short fingerprint: <tt>[deadbef/0h/0h/0h]0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* Too long fingerprint: <tt>[deadbeeef/0h/0h/0h]0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* Invalid hardened indicators: <tt>[deadbeef/0f/0f/0f]0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* Invalid hardened indicators: <tt>[deadbeef/0H/0H/0H]0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* Invalid hardened indicators: <tt>[deadbeef/-0/-0/-0]0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600</tt> +* Private key with derivation: <tt>L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1/0</tt> +* Private key with derivation children: <tt>L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1/*</tt> +* Derivation index out of range: <tt>xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/2147483648</tt> +* Invalid derivation index: <tt>xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/1aa</tt> +* Multiple key origins: <tt>[aaaaaaaa][aaaaaaaa]xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/2147483647'/0</tt> +* Missing key origin start: <tt>aaaaaaaa]xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/2147483647'/0</tt> +* Non hex fingerprint: <tt>[gaaaaaaa]xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/2147483647'/0</tt> +* Key origin with no public key: <tt>[deadbeef]</tt> + ==Backwards Compatibility== Output script descriptors are an entirely new language which is not compatible with any existing software. diff --git a/bip-0381.mediawiki b/bip-0381.mediawiki index f439597..bfda2c8 100644 --- a/bip-0381.mediawiki +++ b/bip-0381.mediawiki @@ -3,7 +3,7 @@ Layer: Applications Title: Non-Segwit Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> - Andrew Chow <andrew@achow101.com> + Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0381 Status: Draft @@ -70,7 +70,49 @@ OP_HASH160 <SCRIPT_hash160> OP_EQUAL ==Test Vectors== -TBD +Valid descriptors followed by the scripts they produce. Descriptors involving derived child keys will have the 0th, 1st, and 2nd scripts listed. + +* <tt>pk(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1)</tt> +** <tt>2103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bdac</tt> +* <tt>pk(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)</tt> +** <tt>2103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bdac</tt> +* <tt>pkh([deadbeef/1/2'/3/4']L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1)</tt> +** <tt>76a9149a1c78a507689f6f54b847ad1cef1e614ee23f1e88ac</tt> +* <tt>pkh([deadbeef/1/2'/3/4']03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)</tt> +** <tt>76a9149a1c78a507689f6f54b847ad1cef1e614ee23f1e88ac</tt> +* <tt>pkh([deadbeef/1/2h/3/4h]03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)</tt> +** <tt>76a9149a1c78a507689f6f54b847ad1cef1e614ee23f1e88ac</tt> +* <tt>pk(5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss)</tt> +** <tt>4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235ac</tt> +* <tt>pk(04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235)</tt> +** <tt>4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235ac</tt> +* <tt>pkh(5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss)</tt> +** <tt>76a914b5bd079c4d57cc7fc28ecf8213a6b791625b818388ac</tt> +* <tt>pkh(04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235)</tt> +** <tt>76a914b5bd079c4d57cc7fc28ecf8213a6b791625b818388ac</tt> +* <tt>sh(pk(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1))</tt> +** <tt>a9141857af51a5e516552b3086430fd8ce55f7c1a52487</tt> +* <tt>sh(pk(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +** <tt>a9141857af51a5e516552b3086430fd8ce55f7c1a52487</tt> +* <tt>sh(pkh(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1))</tt> +** <tt>a9141a31ad23bf49c247dd531a623c2ef57da3c400c587</tt> +* <tt>sh(pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +** <tt>a9141a31ad23bf49c247dd531a623c2ef57da3c400c587</tt> +* <tt>pkh(xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/2147483647'/0)</tt> +** <tt>76a914ebdc90806a9c4356c1c88e42216611e1cb4c1c1788ac</tt> +* <tt>pkh([bd16bee5/2147483647h]xpub69H7F5dQzmVd3vPuLKtcXJziMEQByuDidnX3YdwgtNsecY5HRGtAAQC5mXTt4dsv9RzyjgDjAQs9VGVV6ydYCHnprc9vvaA5YtqWyL6hyds/0)</tt> +** <tt>76a914ebdc90806a9c4356c1c88e42216611e1cb4c1c1788ac</tt> +* <tt>pk(xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L/0)</tt> +** <tt>210379e45b3cf75f9c5f9befd8e9506fb962f6a9d185ac87001ec44a8d3df8d4a9e3ac</tt> +* <tt>pk(xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/0)</tt> +** <tt>210379e45b3cf75f9c5f9befd8e9506fb962f6a9d185ac87001ec44a8d3df8d4a9e3ac</tt> + +Invalid descriptors + +* <tt>pk()</tt> only accepts key expressions: <tt>pk(pk(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +* <tt>pkh()</tt> only accepts key expressions: <tt>pkh(pk(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +* <tt>sh()</tt> only acceps script expressions: <tt>sh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)</tt> +* <tt>sh()</tt> is top level only: <tt>sh(sh(pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)))</tt> ==Backwards Compatibility== diff --git a/bip-0382.mediawiki b/bip-0382.mediawiki index 768079e..bb1951d 100644 --- a/bip-0382.mediawiki +++ b/bip-0382.mediawiki @@ -3,7 +3,7 @@ Layer: Applications Title: Segwit Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> - Andrew Chow <andrew@achow101.com> + Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0382 Status: Draft @@ -57,7 +57,52 @@ OP_0 <SCRIPT_sha256> ==Test Vectors== -TBD +Valid descriptors followed by the scripts they produce. Descriptors involving derived child keys will have the 0th, 1st, and 2nd scripts listed. + +* <tt>wpkh(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1)</tt> +** <tt>00149a1c78a507689f6f54b847ad1cef1e614ee23f1e</tt> +* <tt>wpkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)</tt> +** <tt>00149a1c78a507689f6f54b847ad1cef1e614ee23f1e</tt> +* <tt>wpkh([ffffffff/13']xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt/1/2/0)</tt> +** <tt>0014326b2249e3a25d5dc60935f044ee835d090ba859</tt> +* <tt>wpkh([ffffffff/13']xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/1/2/*)</tt> +** <tt>0014326b2249e3a25d5dc60935f044ee835d090ba859</tt> +** <tt>0014af0bd98abc2f2cae66e36896a39ffe2d32984fb7</tt> +** <tt>00141fa798efd1cbf95cebf912c031b8a4a6e9fb9f27</tt> +* <tt>sh(wpkh(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/10/20/30/40/*'))</tt> +** <tt>a9149a4d9901d6af519b2a23d4a2f51650fcba87ce7b87</tt> +** <tt>a914bed59fc0024fae941d6e20a3b44a109ae740129287</tt> +** <tt>a9148483aa1116eb9c05c482a72bada4b1db24af654387</tt> +* <tt>sh(wpkh(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/10/20/30/40/*h))</tt> +** <tt>a9149a4d9901d6af519b2a23d4a2f51650fcba87ce7b87</tt> +** <tt>a914bed59fc0024fae941d6e20a3b44a109ae740129287</tt> +** <tt>a9148483aa1116eb9c05c482a72bada4b1db24af654387</tt> +* <tt>wsh(pkh(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1))</tt> +** <tt>0020338e023079b91c58571b20e602d7805fb808c22473cbc391a41b1bd3a192e75b</tt> +* <tt>wsh(pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +** <tt>0020338e023079b91c58571b20e602d7805fb808c22473cbc391a41b1bd3a192e75b</tt> +* <tt>wsh(pk(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1))</tt> +** <tt>00202e271faa2325c199d25d22e1ead982e45b64eeb4f31e73dbdf41bd4b5fec23fa</tt> +* <tt>wsh(pk(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +** <tt>00202e271faa2325c199d25d22e1ead982e45b64eeb4f31e73dbdf41bd4b5fec23fa</tt> +* <tt>sh(wsh(pkh(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1)))</tt> +** <tt>a914b61b92e2ca21bac1e72a3ab859a742982bea960a87</tt> +* <tt>sh(wsh(pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)))</tt> +** <tt>a914b61b92e2ca21bac1e72a3ab859a742982bea960a87</tt> + +Invalid descriptors with descriptions + +* Uncompressed public key in <tt>wpkh()</tt>: <tt>wpkh(5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss)</tt> +* Uncompressed public key in <tt>wpkh()</tt>: <tt>sh(wpkh(5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss))</tt> +* Uncompressed public key in <tt>wpkh()</tt>: <tt>wpkh(04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235)</tt> +* Uncompressed public key in <tt>wpkh()</tt>: <tt>sh(wpkh(04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235))</tt> +* Uncompressed public keys under <tt>wsh()</tt>: <tt>wsh(pk(5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss))</tt> +* Uncompressed public keys under <tt>wsh()</tt>: <tt>wsh(pk(04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235))</tt> +* <tt>wpkh()</tt> nested in <tt>wsh()</tt>: <tt>wsh(wpkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +* <tt>wsh()</tt> nested in <tt>wsh()</tt>: <tt>wsh(wsh(pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)))</tt> +* <tt>wsh()</tt> nested in <tt>wsh()</tt>: <tt>sh(wsh(wsh(pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))))</tt> +* Script in <tt>wpkh()</tt>: <tt>wpkh(wsh(pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)))</tt> +* Key in <tt>wsh()</tt>: <tt>wsh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)</tt> ==Backwards Compatibility== diff --git a/bip-0383.mediawiki b/bip-0383.mediawiki index 92e86e3..66e2f16 100644 --- a/bip-0383.mediawiki +++ b/bip-0383.mediawiki @@ -3,7 +3,7 @@ Layer: Applications Title: Multisig Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> - Andrew Chow <andrew@achow101.com> + Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0383 Status: Draft @@ -65,7 +65,37 @@ This changes the keys in lockstep and allows for output scripts to be indexed in ==Test Vectors== -TBD +Valid descriptors followed by the scripts they produce. Descriptors involving derived child keys will have the 0th, 1st, and 2nd scripts listed. + +* <tt>multi(1,L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1,5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss)</tt> +** <tt>512103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea23552ae</tt> +* <tt>multi(1,03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd,04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235)</tt> +** <tt>512103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea23552ae</tt> +* <tt>sortedmulti(1,04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235,03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)</tt> +** <tt>512103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea23552ae</tt> +* <tt>sh(multi(2,[00000000/111'/222]xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc,xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L/0))</tt> +** <tt>a91445a9a622a8b0a1269944be477640eedc447bbd8487</tt> +* <tt>sortedmulti(2,xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/0/0/*)</tt> +** <tt>5221025d5fc65ebb8d44a5274b53bac21ff8307fec2334a32df05553459f8b1f7fe1b62102fbd47cc8034098f0e6a94c6aeee8528abf0a2153a5d8e46d325b7284c046784652ae</tt> +** <tt>52210264fd4d1f5dea8ded94c61e9641309349b62f27fbffe807291f664e286bfbe6472103f4ece6dfccfa37b211eb3d0af4d0c61dba9ef698622dc17eecdf764beeb005a652ae</tt> +** <tt>5221022ccabda84c30bad578b13c89eb3b9544ce149787e5b538175b1d1ba259cbb83321024d902e1a2fc7a8755ab5b694c575fce742c48d9ff192e63df5193e4c7afe1f9c52ae</tt> +* <tt>wsh(multi(2,xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/2147483647'/0,xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt/1/2/*,xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/10/20/30/40/*'))</tt> +** <tt>0020b92623201f3bb7c3771d45b2ad1d0351ea8fbf8cfe0a0e570264e1075fa1948f</tt> +** <tt>002036a08bbe4923af41cf4316817c93b8d37e2f635dd25cfff06bd50df6ae7ea203</tt> +** <tt>0020a96e7ab4607ca6b261bfe3245ffda9c746b28d3f59e83d34820ec0e2b36c139c</tt> +* <tt>sh(wsh(multi(16,03669b8afcec803a0d323e9a17f3ea8e68e8abe5a278020a929adbec52421adbd0,0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600,0362a74e399c39ed5593852a30147f2959b56bb827dfa3e60e464b02ccf87dc5e8,0261345b53de74a4d721ef877c255429961b7e43714171ac06168d7e08c542a8b8,02da72e8b46901a65d4374fe6315538d8f368557dda3a1dcf9ea903f3afe7314c8,0318c82dd0b53fd3a932d16e0ba9e278fcc937c582d5781be626ff16e201f72286,0297ccef1ef99f9d73dec9ad37476ddb232f1238aff877af19e72ba04493361009,02e502cfd5c3f972fe9a3e2a18827820638f96b6f347e54d63deb839011fd5765d,03e687710f0e3ebe81c1037074da939d409c0025f17eb86adb9427d28f0f7ae0e9,02c04d3a5274952acdbc76987f3184b346a483d43be40874624b29e3692c1df5af,02ed06e0f418b5b43a7ec01d1d7d27290fa15f75771cb69b642a51471c29c84acd,036d46073cbb9ffee90473f3da429abc8de7f8751199da44485682a989a4bebb24,02f5d1ff7c9029a80a4e36b9a5497027ef7f3e73384a4a94fbfe7c4e9164eec8bc,02e41deffd1b7cce11cde209a781adcffdabd1b91c0ba0375857a2bfd9302419f3,02d76625f7956a7fc505ab02556c23ee72d832f1bac391bcd2d3abce5710a13d06,0399eb0a5487515802dc14544cf10b3666623762fbed2ec38a3975716e2c29c232)))</tt> +** <tt>a9147fc63e13dc25e8a95a3cee3d9a714ac3afd96f1e87</tt> +* <tt>wsh(multi(20,KzoAz5CanayRKex3fSLQ2BwJpN7U52gZvxMyk78nDMHuqrUxuSJy,KwGNz6YCCQtYvFzMtrC6D3tKTKdBBboMrLTsjr2NYVBwapCkn7Mr,KxogYhiNfwxuswvXV66eFyKcCpm7dZ7TqHVqujHAVUjJxyivxQ9X,L2BUNduTSyZwZjwNHynQTF14mv2uz2NRq5n5sYWTb4FkkmqgEE9f,L1okJGHGn1kFjdXHKxXjwVVtmCMR2JA5QsbKCSpSb7ReQjezKeoD,KxDCNSST75HFPaW5QKpzHtAyaCQC7p9Vo3FYfi2u4dXD1vgMiboK,L5edQjFtnkcf5UWURn6UuuoFrabgDQUHdheKCziwN42aLwS3KizU,KzF8UWFcEC7BYTq8Go1xVimMkDmyNYVmXV5PV7RuDicvAocoPB8i,L3nHUboKG2w4VSJ5jYZ5CBM97oeK6YuKvfZxrefdShECcjEYKMWZ,KyjHo36dWkYhimKmVVmQTq3gERv3pnqA4xFCpvUgbGDJad7eS8WE,KwsfyHKRUTZPQtysN7M3tZ4GXTnuov5XRgjdF2XCG8faAPmFruRF,KzCUbGhN9LJhdeFfL9zQgTJMjqxdBKEekRGZX24hXdgCNCijkkap,KzgpMBwwsDLwkaC5UrmBgCYaBD2WgZ7PBoGYXR8KT7gCA9UTN5a3,KyBXTPy4T7YG4q9tcAM3LkvfRpD1ybHMvcJ2ehaWXaSqeGUxEdkP,KzJDe9iwJRPtKP2F2AoN6zBgzS7uiuAwhWCfGdNeYJ3PC1HNJ8M8,L1xbHrxynrqLKkoYc4qtoQPx6uy5qYXR5ZDYVYBSRmCV5piU3JG9,KzRedjSwMggebB3VufhbzpYJnvHfHe9kPJSjCU5QpJdAW3NSZxYS,Kyjtp5858xL7JfeV4PNRCKy2t6XvgqNNepArGY9F9F1SSPqNEMs3,L2D4RLHPiHBidkHS8ftx11jJk1hGFELvxh8LoxNQheaGT58dKenW,KyLPZdwY4td98bKkXqEXTEBX3vwEYTQo1yyLjX2jKXA63GBpmSjv))</tt> +** <tt>0020376bd8344b8b6ebe504ff85ef743eaa1aa9272178223bcb6887e9378efb341ac</tt> +* <tt>sh(wsh(multi(20,KzoAz5CanayRKex3fSLQ2BwJpN7U52gZvxMyk78nDMHuqrUxuSJy,KwGNz6YCCQtYvFzMtrC6D3tKTKdBBboMrLTsjr2NYVBwapCkn7Mr,KxogYhiNfwxuswvXV66eFyKcCpm7dZ7TqHVqujHAVUjJxyivxQ9X,L2BUNduTSyZwZjwNHynQTF14mv2uz2NRq5n5sYWTb4FkkmqgEE9f,L1okJGHGn1kFjdXHKxXjwVVtmCMR2JA5QsbKCSpSb7ReQjezKeoD,KxDCNSST75HFPaW5QKpzHtAyaCQC7p9Vo3FYfi2u4dXD1vgMiboK,L5edQjFtnkcf5UWURn6UuuoFrabgDQUHdheKCziwN42aLwS3KizU,KzF8UWFcEC7BYTq8Go1xVimMkDmyNYVmXV5PV7RuDicvAocoPB8i,L3nHUboKG2w4VSJ5jYZ5CBM97oeK6YuKvfZxrefdShECcjEYKMWZ,KyjHo36dWkYhimKmVVmQTq3gERv3pnqA4xFCpvUgbGDJad7eS8WE,KwsfyHKRUTZPQtysN7M3tZ4GXTnuov5XRgjdF2XCG8faAPmFruRF,KzCUbGhN9LJhdeFfL9zQgTJMjqxdBKEekRGZX24hXdgCNCijkkap,KzgpMBwwsDLwkaC5UrmBgCYaBD2WgZ7PBoGYXR8KT7gCA9UTN5a3,KyBXTPy4T7YG4q9tcAM3LkvfRpD1ybHMvcJ2ehaWXaSqeGUxEdkP,KzJDe9iwJRPtKP2F2AoN6zBgzS7uiuAwhWCfGdNeYJ3PC1HNJ8M8,L1xbHrxynrqLKkoYc4qtoQPx6uy5qYXR5ZDYVYBSRmCV5piU3JG9,KzRedjSwMggebB3VufhbzpYJnvHfHe9kPJSjCU5QpJdAW3NSZxYS,Kyjtp5858xL7JfeV4PNRCKy2t6XvgqNNepArGY9F9F1SSPqNEMs3,L2D4RLHPiHBidkHS8ftx11jJk1hGFELvxh8LoxNQheaGT58dKenW,KyLPZdwY4td98bKkXqEXTEBX3vwEYTQo1yyLjX2jKXA63GBpmSjv)))</tt> +** <tt>a914c2c9c510e9d7f92fd6131e94803a8d34a8ef675e87</tt> + +Invalid descriptors + +* More than 15 keys in P2SH multisig: <tt>sh(multi(16,03669b8afcec803a0d323e9a17f3ea8e68e8abe5a278020a929adbec52421adbd0,0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600,0362a74e399c39ed5593852a30147f2959b56bb827dfa3e60e464b02ccf87dc5e8,0261345b53de74a4d721ef877c255429961b7e43714171ac06168d7e08c542a8b8,02da72e8b46901a65d4374fe6315538d8f368557dda3a1dcf9ea903f3afe7314c8,0318c82dd0b53fd3a932d16e0ba9e278fcc937c582d5781be626ff16e201f72286,0297ccef1ef99f9d73dec9ad37476ddb232f1238aff877af19e72ba04493361009,02e502cfd5c3f972fe9a3e2a18827820638f96b6f347e54d63deb839011fd5765d,03e687710f0e3ebe81c1037074da939d409c0025f17eb86adb9427d28f0f7ae0e9,02c04d3a5274952acdbc76987f3184b346a483d43be40874624b29e3692c1df5af,02ed06e0f418b5b43a7ec01d1d7d27290fa15f75771cb69b642a51471c29c84acd,036d46073cbb9ffee90473f3da429abc8de7f8751199da44485682a989a4bebb24,02f5d1ff7c9029a80a4e36b9a5497027ef7f3e73384a4a94fbfe7c4e9164eec8bc,02e41deffd1b7cce11cde209a781adcffdabd1b91c0ba0375857a2bfd9302419f3,02d76625f7956a7fc505ab02556c23ee72d832f1bac391bcd2d3abce5710a13d06,0399eb0a5487515802dc14544cf10b3666623762fbed2ec38a3975716e2c29c232))</tt> +* Invalid threshold: <tt>multi(a,03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd,04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235)</tt> +* Threshold of 0: <tt>multi(0,03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd,04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235)</tt> +* Threshold larger than keys: <tt>multi(3,L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1,5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss)</tt> ==Backwards Compatibility== diff --git a/bip-0384.mediawiki b/bip-0384.mediawiki index e735d74..ba12b55 100644 --- a/bip-0384.mediawiki +++ b/bip-0384.mediawiki @@ -3,7 +3,7 @@ Layer: Applications Title: combo() Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> - Andrew Chow <andrew@achow101.com> + Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0384 Status: Draft @@ -35,7 +35,38 @@ If the key is/has a compressed public key, then P2WPKH and P2SH-P2WPKH scripts a ==Test Vectors== -TBD +Valid descriptors followed by the scripts they produce. Descriptors involving derived child keys will have the 0th, and 1st scripts in additional sub-bullets. + +* <tt>combo(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1)</tt> +** <tt>2103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bdac</tt> +** <tt>76a9149a1c78a507689f6f54b847ad1cef1e614ee23f1e88ac</tt> +** <tt>00149a1c78a507689f6f54b847ad1cef1e614ee23f1e</tt> +** <tt>a91484ab21b1b2fd065d4504ff693d832434b6108d7b87</tt> +* <tt>combo(04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235)</tt> +** <tt>4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235ac</tt> +** <tt>76a914b5bd079c4d57cc7fc28ecf8213a6b791625b818388ac</tt> +* <tt>combo([01234567]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL)</tt> +** <tt>2102d2b36900396c9282fa14628566582f206a5dd0bcc8d5e892611806cafb0301f0ac</tt> +** <tt>76a91431a507b815593dfc51ffc7245ae7e5aee304246e88ac</tt> +** <tt>001431a507b815593dfc51ffc7245ae7e5aee304246e</tt> +** <tt>a9142aafb926eb247cb18240a7f4c07983ad1f37922687</tt> +* <tt>combo(xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334/*)</tt> +** Child 0 +*** <tt>2102df12b7035bdac8e3bab862a3a83d06ea6b17b6753d52edecba9be46f5d09e076ac</tt> +*** <tt>76a914f90e3178ca25f2c808dc76624032d352fdbdfaf288ac</tt> +*** <tt>0014f90e3178ca25f2c808dc76624032d352fdbdfaf2</tt> +*** <tt>a91408f3ea8c68d4a7585bf9e8bda226723f70e445f087</tt> +** Child 1 +*** <tt>21032869a233c9adff9a994e4966e5b821fd5bac066da6c3112488dc52383b4a98ecac</tt> +*** <tt>76a914a8409d1b6dfb1ed2a3e8aa5e0ef2ff26b15b75b788ac</tt> +*** <tt>0014a8409d1b6dfb1ed2a3e8aa5e0ef2ff26b15b75b7</tt> +*** <tt>a91473e39884cb71ae4e5ac9739e9225026c99763e6687</tt> + +Invalid descriptors + +* <tt>combo()</tt> in <tt>sh</tt> : <tt>sh(combo(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +* <tt>combo()</tt> in <tt>wsh</tt> : <tt>wsh(combo(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +* Script in <tt>combo()</tt>: <tt>combo(pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> ==Backwards Compatibility== diff --git a/bip-0385.mediawiki b/bip-0385.mediawiki index 5c46d75..3e922b3 100644 --- a/bip-0385.mediawiki +++ b/bip-0385.mediawiki @@ -3,7 +3,7 @@ Layer: Applications Title: raw() and addr() Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> - Andrew Chow <andrew@achow101.com> + Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0385 Status: Draft @@ -44,7 +44,25 @@ The output script produced by this descriptor is the output script produced by t ==Test Vectors== -TBD +Valid descriptors followed by the scripts they produce. + +* <tt>raw(deadbeef)</tt> +** <tt>deadbeef</tt> +* <tt>raw(512103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea23552ae)</tt> +** <tt>512103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea23552ae</tt> +* <tt>raw(a9149a4d9901d6af519b2a23d4a2f51650fcba87ce7b87)</tt> +** <tt>a9149a4d9901d6af519b2a23d4a2f51650fcba87ce7b87</tt> +* <tt>addr(3PUNyaW7M55oKWJ3kDukwk9bsKvryra15j)</tt> +** <tt>a914eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee87</tt> + +Invalid descriptors + +* Non-hex script: <tt>raw(asdf)</tt> +* Invalid address: <tt>addr(asdf)</tt> +* <tt>raw</tt> nested in <tt>sh</tt>: <tt>sh(raw(deadbeef))</tt> +* <tt>raw</tt> nested in <tt>wsh</tt>: <tt>wsh(raw(deadbeef))</tt> +* <tt>addr</tt> nested in <tt>sh</tt>: <tt>sh(addr(3PUNyaW7M55oKWJ3kDukwk9bsKvryra15j))</tt> +* <tt>addr</tt> nested in <tt>wsh</tt>: <tt>wsh(addr(3PUNyaW7M55oKWJ3kDukwk9bsKvryra15j))</tt> ==Backwards Compatibility== diff --git a/bip-0386.mediawiki b/bip-0386.mediawiki index d90e801..759887d 100644 --- a/bip-0386.mediawiki +++ b/bip-0386.mediawiki @@ -3,7 +3,7 @@ Layer: Applications Title: tr() Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> - Andrew Chow <andrew@achow101.com> + Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0386 Status: Draft @@ -84,7 +84,28 @@ An additional key expression is defined only for use within a <tt>tr()</tt> desc ==Test Vectors== -TBD +Valid descriptors followed by the scripts they produce. Descriptors involving derived child keys will have the 0th, 1st, and 2nd scripts listed. + +* <tt>tr(a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)</tt> +** <tt>512077aab6e066f8a7419c5ab714c12c67d25007ed55a43cadcacb4d7a970a093f11</tt> +* <tt>tr(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1)</tt> +** <tt>512077aab6e066f8a7419c5ab714c12c67d25007ed55a43cadcacb4d7a970a093f11</tt> +* <tt>tr(xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc/0/*,pk(xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc/1/*))</tt> +** <tt>512078bc707124daa551b65af74de2ec128b7525e10f374dc67b64e00ce0ab8b3e12</tt> +** <tt>512001f0a02a17808c20134b78faab80ef93ffba82261ccef0a2314f5d62b6438f11</tt> +** <tt>512021024954fcec88237a9386fce80ef2ced5f1e91b422b26c59ccfc174c8d1ad25</tt> +* <tt>tr(a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd,pk(669b8afcec803a0d323e9a17f3ea8e68e8abe5a278020a929adbec52421adbd0))</tt> +** <tt>512017cf18db381d836d8923b1bdb246cfcd818da1a9f0e6e7907f187f0b2f937754</tt> +* <tt>tr(a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd,{pk(xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334/0),{{pk(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL),pk(02df12b7035bdac8e3bab862a3a83d06ea6b17b6753d52edecba9be46f5d09e076)},pk(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1)}})</tt> +** <tt>512071fff39599a7b78bc02623cbe814efebf1a404f5d8ad34ea80f213bd8943f574</tt> + +Invalid Descriptors + +* Uncompressed private key: <tt>tr(5kyzdueo39z3fprtux2qbbwgnnp5ztd7yyr2sc1j299sbcnwjss)</tt> +* Uncompressed public key: <tt>tr(04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235)</tt> +* <tt>tr()</tt> nested in <tt>wsh</tt>: <tt>wsh(tr(a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +* <tt>tr()</tt> nested in <tt>sh</tt>: <tt>sh(tr(a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +* <tt>pkh()</tt> nested in <tt>tr</tt>: <tt>tr(a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd, pkh(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1))</tt> ==Backwards Compatibility== diff --git a/bip-0387.mediawiki b/bip-0387.mediawiki new file mode 100644 index 0000000..5c039b8 --- /dev/null +++ b/bip-0387.mediawiki @@ -0,0 +1,101 @@ +<pre> + BIP: 387 + Layer: Applications + Title: Tapscript Multisig Output Script Descriptors + Author: Pieter Wuille <pieter@wuille.net> + Ava Chow <me@achow101.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0387 + Status: Draft + Type: Informational + Created: 2024-04-17 + License: BSD-2-Clause +</pre> + +==Abstract== + +This document specifies <tt>multi_a()</tt> and <tt>sortedmulti_a()</tt> output script descriptors. +Like BIP 383's <tt>multi()</tt> and <tt>sortedmulti()</tt>, both functions take a threshold and one +or more public keys and produce a multisig script. The primary distinction is that <tt>multi_a()</tt> +and <tt>sortedmulti_a()</tt> only produce tapscripts and are only allowed in a tapscript context. + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + +==Motivation== + +The most common complex script used in Bitcoin is a threshold multisig. +These expressions allow specifying multisig scripts as a descriptor. + +==Specification== + +Two new script expressions are defined: <tt>multi_a()</tt> and <tt>sortedmulti_a()</tt>. +Both expressions produce the scripts of the same template and take the same arguments. +They are written as <tt>multi_a(k,KEY_1,KEY_2,...,KEY_n)</tt>. +<tt>k</tt> is the threshold - the number of keys that must sign the input for the script to be valid. +<tt>KEY_1,KEY_2,...,KEY_n</tt> are the key expressions for the multisig. <tt>k</tt> must be less than or equal to <tt>n</tt>. + +<tt>multi_a()</tt> and <tt>sortedmulti_a()</tt> expressions can only be used inside of a <tt>tr()</tt> descriptor. +The maximum number of keys is 999. + +The output script produced also depends on the value of <tt>k</tt>. If <tt>k</tt> is less than or equal to 16: +<pre> +KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD OP_k OP_NUMEQUAL +</pre> + +if <tt>k</tt> is greater than 16: +<pre> +KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD k OP_NUMEQUAL +</pre> + +===<tt>sortedmulti_a()</tt>=== + +The only change for <tt>sortedmulti_a()</tt> is that the x-only public keys are sorted lexicographically prior to the creation of the output script. +This sorting is on the keys that are to be put into the output script, i.e. after all extended keys are derived. + +===Multiple Extended Keys</tt>=== + +When one or more of the key expressions in a <tt>multi_a()</tt> or <tt>sortedmulti_a()</tt> expression are extended keys, the derived keys use the same child index. +This changes the keys in lockstep and allows for output scripts to be indexed in the same way that the derived keys are indexed. + +==Test Vectors== + +Valid descriptors followed by the scripts they produce. Descriptors involving derived child keys will have the 0th, 1st, and 2nd scripts listed. + +* <tt>tr(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1,multi_a(1,KzoAz5CanayRKex3fSLQ2BwJpN7U52gZvxMyk78nDMHuqrUxuSJy))</tt> +** <tt>5120eb5bd3894327d75093891cc3a62506df7d58ec137fcd104cdd285d67816074f3</tt> +* <tt>tr(a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd,multi_a(1,669b8afcec803a0d323e9a17f3ea8e68e8abe5a278020a929adbec52421adbd0))</tt> +** <tt>5120eb5bd3894327d75093891cc3a62506df7d58ec137fcd104cdd285d67816074f3</tt> +* <tt>tr(50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0,multi_a(2,[00000000/111'/222]xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc,xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L/0))</tt> +** <tt>51202eea93581594a43c0c8423b70dc112e5651df63984d108d4fc8ccd3b63b4eafa</tt> +* <tt>tr(50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0,sortedmulti_a(2,[00000000/111'/222]xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc,xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L/0))</tt> +** <tt>512016fa6a6ba7e98c54b5bf43b3144912b78a61b60b02f6a74172b8dcb35b12bc30</tt> +* <tt>tr(50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0,sortedmulti_a(2,xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/0/0/*))</tt> +** <tt>5120abd47468515223f58a1a18edfde709a7a2aab2b696d59ecf8c34f0ba274ef772</tt> +** <tt>5120fe62e7ed20705bd1d3678e072bc999acb014f07795fa02cb8f25a7aa787e8cbd</tt> +** <tt>51201311093750f459039adaa2a5ed23b0f7a8ae2c2ffb07c5390ea37e2fb1050b41</tt> +* <tt>tr(50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0,multi_a(2,xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/2147483647'/0,xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt/1/2/*,xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/10/20/30/40/*'))</tt> +** <tt>5120e4c8f2b0a7d3a688ac131cb03248c0d4b0a59bbd4f37211c848cfbd22a981192</tt> +** <tt>5120827faedaa21e52fca2ac83b53afd1ab7d4d1e6ce67ff42b19f2723d48b5a19ab</tt> +** <tt>5120647495ed09de61a3a324704f9203c130d655bf3141f9b748df8f7be7e9af55a4</tt> + +Invalid descriptors + +* Unsupported top level: <tt>multi_a(1,03669b8afcec803a0d323e9a17f3ea8e68e8abe5a278020a929adbec52421adbd0)</tt> +* Unsupported <tt>sh()</tt> context: <tt>sh(multi_a(1,03669b8afcec803a0d323e9a17f3ea8e68e8abe5a278020a929adbec52421adbd0))</tt> +* Unsupported <tt>wsh()</tt> context: <tt>wsh(multi_a(1,03669b8afcec803a0d323e9a17f3ea8e68e8abe5a278020a929adbec52421adbd0))</tt> +* Invalid threshold: <tt>tr(50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0,multi_a(a,03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +* Threshold of 0: <tt>tr(50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0,multi_a(0,03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> +* Uncompressed pubkey: <tt>tr(50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0,multi_a(1,04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235))</tt> +* Threshold larger than keys: <tt>tr(50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0,multi_a(3,L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1,5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss))</tt> + +==Backwards Compatibility== + +<tt>multi_a()</tt> and <tt>sortedmulti_a()</tt> descriptors use the format and general operation specified in [[bip-0380.mediawiki|380]]. +As these are wholly new descriptors, they are not compatible with any implementation. +However, the scripts produced are standard scripts, so existing software are likely to be familiar with them. + +==Reference Implementation== + +<tt>multi_a()</tt> and <tt>sortedmulti_a()</tt> descriptors were implemented in Bitcoin Core in https://github.com/bitcoin/bitcoin/pull/24043 and have been available since version 24.0. diff --git a/bip-0388.mediawiki b/bip-0388.mediawiki new file mode 100644 index 0000000..dc1b508 --- /dev/null +++ b/bip-0388.mediawiki @@ -0,0 +1,306 @@ +<pre> + BIP: 388 + Layer: Applications + Title: Wallet Policies for Descriptor Wallets + Author: Salvatore Ingala <salvatoshi@protonmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0388 + Status: Proposed + Type: Standards Track + Created: 2022-11-16 + License: BSD-2-Clause + Post-History: 2022-05-10: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020423.html +</pre> + +== Abstract == + +Wallet policies build on top of output script descriptors to represent the types of descriptors that are typically used to represent "accounts" in a software wallet, or a hardware signing device, in a compact, reviewable way. A wallet policy always represents exactly two descriptors, which produce the receive and change addresses that are logically part of the same account. + +We simplify the language to suit devices with limited memory, where even keeping the entire descriptor in memory could be a major hurdle, by reducing the generality of descriptors to just the essential features and by separating the extended pubkeys and other key information from the descriptor. + +This results in a more compact representation and simplifies the inspection of the policy by the user. + +The compilation of wallet policies to the corresponding descriptor is trivial, and the reverse process is easy for supported descriptors, because the language is kept similar to that of output script descriptors. + +== Copyright == + +This BIP is licensed under the BSD 2-clause license. + +== Motivation == + +''[[bip-0380.mediawiki|Output Script Descriptors]]'' were introduced in Bitcoin Core as a way to represent collections of output scripts. It is a general and flexible language, designed to catch all the possible use-cases of bitcoin wallets (that is, if you know the script and you have the necessary keys, it will be possible to sign transactions with any descriptor-based software wallet). + +Unfortunately, descriptors are not a perfect match for the typical usage of hardware signing devices (often also called ''hardware wallets''). Most of them have some of the following limitations when compared to a general-purpose machine running Bitcoin Core: + +* they are embedded devices with limited RAM, and computational power; +* they cannot import additional private keys (that is, they can only sign with keys derived from a single seed via [[bip-0032.mediawiki|BIP-32]]); +* they have limited storage, or they might not have persistent storage at all (''stateless design''). + +Moreover, other limitations like the limited size of the screen might affect what design choices are available in practice. Therefore, minimizing the amount of information shown on-screen is important for a good user experience. The ability for the user to completely validate on-screen the kind of script used (and each of the involved keys) is crucial for secure usage, as the machine that is interacting with the hardware signer (and running the software wallet) is considered untrusted. + +A more native, compact representation of the wallet receive and change addresses might also benefit the UX of software wallets when they use descriptors (possibly with miniscript) for representing complex locking conditions. + +We remark that wallet policies are not related to the ''policy'' language, a higher level language that can be compiled to miniscript. + +=== Security and UX concerns for hardware signing devices === + +The usage of complex scripts presents challenges in terms of both security and user experience for a hardware signing device. + +==== Security issues ==== + +Hardware signing devices strive to guarantee that no action can be performed without the user’s consent as long as the user correctly verifies the information that is shown on the device’s screen before approving. + +This must hold even in scenarios where the attacker has full control of the machine that is connected to the signing device, and can execute arbitrary requests, or tamper with the legitimate user's requests. + +Therefore, it is not at all trivial to allow complex scripts, especially if they contain keys that belong to third parties. +The hardware signing device must guarantee that the user knows precisely what "policy" is being used to spend the funds, and that any "unspent" funds (if any) that is sent to a change address will be protected by the same policy. + +This makes it impossible for an attacker to surreptitiously modify the policy, therefore stealing or burning the user's funds. + +==== UX issues ==== + +Miniscript (and taproot trees) allow substantially more complex spending policies. It is a challenge to ensure that the user can practically verify such spending policies per the screen. + +We set two fundamental design goals: +* Minimize the amount of information that is shown on screen - so that the user can actually validate it. +* Minimize the number of times the user has to validate such information. + +Designing a secure protocol for the coordination of a descriptor wallet among distant parties is also a challenging problem that is out of scope in this document. See [[bip-0129.mediawiki|BIP-129 (Bitcoin Secure Multisig Setup)]] for an approach designed for multisignature wallets. Regardless of the approach, the ability for the user to carefully verify all the details of the spending policies using the hardware signer's screen is a prerequisite for security in adversarial environments. + +=== Policy registration as a solution === + +A solution to address the security concerns, and part of the UX concerns, is to have a registration flow for the wallet policy in the hardware signing device. The ''wallet policy'' must contain enough information to generate all the relevant addresses/scripts, and for the hardware signing device to identify the keys that it controls and that are needed to spend the funds sent to those addresses. + +Before a new policy is used for the first time, the user will register a wallet policy into the hardware device. While the details of the process are out of scope in this document, the flow should be something similar to the following: + +# The software wallet initiates a ''wallet policy registration'' on the hardware signing device; the information should include the wallet policy, but also a unique ''name'' that identifies the policy. +# The device shows the wallet policy to the user using the secure screen. +# After inspecting the policy and comparing it with a trusted source (for example a printed backup), the user approves the policy. +# If stateful, the hardware signing device persists the policy in its permanent memory; if stateless, it returns a "proof of registration". + +The '''proof of registration''' will allow the hardware signer to verify that a certain policy was indeed previously approved by the user, and is therefore safe to use without repeating the expensive user verification procedure. The details of how to create a proof of registration are out of scope for this document; using a Message Authentication Code on a hash committing to the wallet policy, its name and any additional metadata is an effective solution if correctly executed. + +Once a policy is registered, the hardware signing device can perform the typical operations securely: +* generating receive and change addresses; +* showing addresses on the secure screen; +* sign transactions spending from a wallet, while correctly identifying change addresses and computing the transaction fees. + +Before any of the actions mentioned above, the hardware signing device will retrieve the policy from its permanent storage if stateful; if stateless it will validate the proof of registration before using the wallet policy provided by the client. + +Once the previously registered policy is correctly identified and approved by the user (for example by showing its name), and as long as the policy registration was executed securely, hardware signing devices can provide a user experience similar to the usual one for single-signature transactions. + +=== Avoiding blowup in descriptor size === + +While reusing a pubkey in different branches of a miniscript is explicitly forbidden by miniscript (as it has certain negative security implications), it is still reasonable to reuse the same xpub in multiple places, albeit with different final steps of derivation (so that the actual pubkeys that are used in the script are indeed different). + +In fact, there are many reasonable spending policies with a quadratic size in the number of participants. For example, using Taproot, a 3-of-5 multisignature wallet could use: +* a key path with a 5-of-5 MuSig2 aggregated key +* a script tree with 11 leaves: +** 10 different scripts using a 3-of-3 MuSig2 aggregated key, plus +** a final leaf with a fallback 3-of-5 multisignature using <tt>multi_a</tt> (in case interactive signing is not available). + +With each xpub being 118 bytes long, the repetition of xpubs makes the descriptor become extremely large. + +Replacing the common part of the key with a short key placeholder and organizing all the key expressions in a separate list helps to keep the size of the wallet policy small, which is crucial to allow human inspection during the registration flow. + +== Specification == + +This section formally defines wallet policies, and how they relate to output script descriptors. + +=== Formal definition === + +A ''wallet policy'' is composed by a ''wallet descriptor template'', together with a vector of ''key information items''. + +==== Wallet descriptor template ==== + +A ''wallet descriptor template'' is a <tt>SCRIPT</tt> expression. + +<tt>SCRIPT</tt> expressions: +* <tt>sh(SCRIPT)</tt> (top level only): P2SH embed the argument. +* <tt>wsh(SCRIPT)</tt> (top level or inside <tt>sh</tt> only): P2WSH embed the argument. +* <tt>pkh(KP)</tt> (not inside <tt>tr</tt>): P2PKH output for the given public key. +* <tt>wpkh(KP)</tt> (top level or inside <tt>sh</tt> only): P2WPKH output for the given compressed pubkey. +* <tt>multi(k,KP_1,KP_2,...,KP_n)</tt> (inside <tt>sh</tt> or <tt>wsh</tt> only): ''k''-of-''n'' multisig script. +* <tt>sortedmulti(k,KP_1,KP_2,...,KP_n)</tt> (inside <tt>sh</tt> or <tt>wsh</tt> only): ''k''-of-''n'' multisig script with keys sorted lexicographically in the resulting script. +* <tt>tr(KP)</tt> or <tt>tr(KP,TREE)</tt> (top level only): P2TR output with the specified key as internal key, and optionally a tree of script paths. +* any valid miniscript template (inside <tt>wsh</tt> or <tt>tr</tt> only). + +<tt>TREE</tt> expressions: +* any <tt>SCRIPT</tt> expression +* An open brace <tt>{</tt>, a <tt>TREE</tt> expression, a comma <tt>,</tt>, a <tt>TREE</tt> expression, and a closing brace <tt>}</tt> + + +<tt>KP</tt> expressions (key placeholders) consist of +* a single character <tt>@</tt> +* followed by a non-negative decimal number, with no leading zeros (except for <tt>@0</tt>) +* ''always'' followed by either: +** the string <tt>/**</tt>, or +** a string of the form <tt>/<NUM;NUM>/*</tt>, for two distinct decimal numbers <tt>NUM</tt> representing unhardened derivations, or +** any of the additional, implementation-specific valid derivation path patterns (see [[#optional-derivation-paths|Optional derivation paths]] below). + +The <tt>/**</tt> in the placeholder template represents commonly used paths for receive/change addresses, and is equivalent to <tt><0;1>/*</tt>. + +Note that while [[bip-0389.mediawiki|BIP-389]] allows multipath <tt>/<NUM;NUM;...;NUM></tt> expressions with an arbitrary number of options, this specification restricts it to exactly 2 choices (with the typical meaning of receive/change addresses). + +The placeholder <tt>@i</tt> for some number ''i'' represents the ''i''-th key in the vector of key information items (which must be of size at least ''i + 1'', or the wallet policy is invalid). + +Note: while descriptor templates for miniscript are not formally defined in this version of the document (pending standardization), it is straightforward to adapt this approach by adding additional <tt>SCRIPT</tt> expressions. + +==== Key information vector ==== + +Each element of the key origin information vector is a <tt>KEY</tt> expression. + +* Optionally, key origin information, consisting of: +** An open bracket <tt>[</tt> +** Exactly 8 hex characters for the fingerprint of the master key from which this key is derived from (see [[bip-0032.mediawiki|BIP-32]] for details) +** Followed by zero or more <tt>/NUM'</tt> or <tt>/NUM</tt> path elements to indicate hardened or unhardened derivation steps between the fingerprint and the xpub that follows +** A closing bracket <tt>]</tt> +* Followed by the actual key, which is a serialized extended public key (as defined in [[bip-0032.mediawiki|BIP-32]]). + +==== Additional rules ==== + +A wallet policy must have at least one key placeholder and the corresponding key. + +The public keys obtained by deserializing elements of the key information vector must be pairwise distinct<ref>'''Why must public keys be distinct?''' Reusing pubkeys could be insecure in the context of wallet policies containing [https://bitcoin.sipa.be/miniscript/ miniscript]. Avoiding repeated public keys altogether avoids the problem at the source.</ref>. + +If two key placeholders are <tt>@i/<M;N>/*</tt> and <tt>@i/<P;Q>/*</tt> for the same index <tt>i</tt>, then the sets <tt>{M, N}</tt> and <tt>{P, Q}</tt> must be disjoint. + +The key information vector should be ordered so that placeholder <tt>@i</tt> never appears for the first time before an occurrence of <tt>@j</tt> for some <tt>j < i</tt>; for example, the first placeholder is always <tt>@0</tt>, the next one is <tt>@1</tt>, etc. + +=== Descriptor derivation === + +From a wallet descriptor template (and the associated vector of key information items), one can therefore obtain the corresponding multipath descriptor by: + +* replacing each key placeholder with the corresponding key origin +information; +* replacing every <tt>/**</tt> with <tt>/<0;1>/*</tt>. + +For example, the wallet descriptor <tt>pkh(@0/**)</tt> with key information +<tt>["[d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL"]</tt> +produces the following multipath descriptor: + +<tt>pkh([d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/<0;1>/*)</tt> + +=== Implementation guidelines === + +It is acceptable to implement only a subset of the possible wallet policies defined by this standard. It is recommended that any limitations are clearly documented. + +Implementations can add additional metadata that is stored together with the wallet policy for the purpose of wallet policy registration and later usage. Metadata can be vendor-specific and is out of the scope of this document. + +Any implementation in a software wallet that allows wallet policies not matching any of the specifications in [[bip-0044.mediawiki|BIP-44]], [[bip-0049.mediawiki|BIP-49]], [[bip-0084.mediawiki|BIP-84]], [[bip-0086.mediawiki|BIP-86]] (especially if involving external cosigners) should put great care into a process for backing up the wallet policy that represents the account. In fact, unlike standard single-signature scenarios, the seed alone is no longer enough to discover wallet policies with existing funds, and the loss of the backup is likely to lead to permanent loss of funds. Unlike the seed, leaking such backups only affects the privacy of the user, but it does not allow the attacker to steal funds. + +Avoiding key reuse among different wallet accounts is also extremely important, but out of scope for this document. + +=== Optional derivation paths === + +In order to allow supporting legacy derivation schemes (for example, using simply <tt>/*</tt> instead of the more common <tt>/<M;N>/*</tt> scheme most software wallets use today), or other schemes that are not covered in this document, implementations might choose to permit additional derivation patterns for the key placeholder (<tt>KP</tt>) expressions. + +However, care needs to be taken in view of the following considerations: + +* Allowing derivation schemes with a different length or cardinality in the same wallet policy would make it difficult to guarantee that there are no repeated pubkeys for every possible address generated by the policy. For example, <tt>@0/<0;1>/*</tt> and <tt>@1/*</tt> would generate the same pubkeys if the second public key in the key information vector is one of the first two unhardened children of the first public key. This could cause malleability with potential security implications (for example, in policies containing miniscript). +* Allowing naked pubkeys with no <tt>/*</tt> suffix (for example a descriptor template like <tt>wsh(multi(2,@0,@1/<0;1>/*))</tt>) would cause a pubkey to be repeated in every output generated from the policy, which would result in a total loss of privacy. + +== Examples == + +In the examples in this section, the vector of key information items is omitted. See the test vectors below for complete examples. + +Common single-signature account patterns: +* <tt>pkh(@0/**)</tt> (legacy). +* <tt>wpkh(@0/**)</tt> (native segwit). +* <tt>sh(wpkh(@0/**))</tt> (nested segwit). +* <tt>tr(@0/**)</tt> (taproot single-signature account). + +Common multisignature schemes: +* <tt>wsh(multi(2,@0/**,@1/**))</tt> - SegWit 2-of-2 multisignature, keys in order. +* <tt>sh(sortedmulti(2,@0/**,@1/**,@2/**))</tt> - Legacy 2-of-3 multisignature, sorted keys. + +Some miniscript policies in <tt>wsh</tt>: +* <tt>wsh(and_v(v:pk(@0/**),or_d(pk(@1/**),older(12960))))</tt> - Trust-minimized second factor, degrading to a single signature after about 90 days. +* <tt>wsh(thresh(3,pk(@0/**),s:pk(@1/**),s:pk(@2/**),sln:older(12960)))</tt> - A 3-of-3 wallet that becomes a 2-of-3 if coins are not spent for about 90 days. +* <tt>wsh(or_d(pk(@0/**),and_v(v:multi(2,@1/**,@2/**,@3/**),older(65535))))</tt> - A singlesig wallet with automatic inheritance to a timelocked 2-of-3 multisig of family members. + +== Test Vectors == + +=== Valid policies === + +[[bip-0044.mediawiki|BIP-44]], first account + Descriptor template: pkh(@0/**) + Keys info: ["[6738736c/44'/0'/0']xpub6Br37sWxruYfT8ASpCjVHKGwgdnYFEn98DwiN76i2oyY6fgH1LAPmmDcF46xjxJr22gw4jmVjTE2E3URMnRPEPYyo1zoPSUba563ESMXCeb"] + Descriptor: pkh([6738736c/44'/0'/0']xpub6Br37sWxruYfT8ASpCjVHKGwgdnYFEn98DwiN76i2oyY6fgH1LAPmmDcF46xjxJr22gw4jmVjTE2E3URMnRPEPYyo1zoPSUba563ESMXCeb) +<br> +[[bip-0049.mediawiki|BIP-49]], second account + Descriptor template: sh(wpkh(@0/**)) + Keys info: ["[6738736c/49'/0'/1']xpub6Bex1CHWGXNNwGVKHLqNC7kcV348FxkCxpZXyCWp1k27kin8sRPayjZUKDjyQeZzGUdyeAj2emoW5zStFFUAHRgd5w8iVVbLgZ7PmjAKAm9"] + Descriptor: sh(wpkh([6738736c/49'/0'/1']xpub6Bex1CHWGXNNwGVKHLqNC7kcV348FxkCxpZXyCWp1k27kin8sRPayjZUKDjyQeZzGUdyeAj2emoW5zStFFUAHRgd5w8iVVbLgZ7PmjAKAm9)) +<br> +[[bip-0084.mediawiki|BIP-84]], third account + Descriptor template: wpkh(@0/**) + Keys info: ["[6738736c/84'/0'/2']xpub6CRQzb8u9dmMcq5XAwwRn9gcoYCjndJkhKgD11WKzbVGd932UmrExWFxCAvRnDN3ez6ZujLmMvmLBaSWdfWVn75L83Qxu1qSX4fJNrJg2Gt"] + Descriptor: wpkh([6738736c/84'/0'/2']xpub6CRQzb8u9dmMcq5XAwwRn9gcoYCjndJkhKgD11WKzbVGd932UmrExWFxCAvRnDN3ez6ZujLmMvmLBaSWdfWVn75L83Qxu1qSX4fJNrJg2Gt) +<br> +[[bip-0086.mediawiki|BIP-86]], first account + Descriptor template: tr(@0/**) + Keys info: ["[6738736c/86'/0'/0']xpub6CryUDWPS28eR2cDyojB8G354izmx294BdjeSvH469Ty3o2E6Tq5VjBJCn8rWBgesvTJnyXNAJ3QpLFGuNwqFXNt3gn612raffLWfdHNkYL"] + Descriptor: tr([6738736c/86'/0'/0']xpub6CryUDWPS28eR2cDyojB8G354izmx294BdjeSvH469Ty3o2E6Tq5VjBJCn8rWBgesvTJnyXNAJ3QpLFGuNwqFXNt3gn612raffLWfdHNkYL) +<br> +[[bip-0048.mediawiki|BIP-48]] P2WSH multisig + Descriptor template: wsh(sortedmulti(2,@0/**,@1/**)) + Keys info: ["[6738736c/48'/0'/0'/2']xpub6FC1fXFP1GXLX5TKtcjHGT4q89SDRehkQLtbKJ2PzWcvbBHtyDsJPLtpLtkGqYNYZdVVAjRQ5kug9CsapegmmeRutpP7PW4u4wVF9JfkDhw", "[b2b1f0cf/48'/0'/0'/2']xpub6EWhjpPa6FqrcaPBuGBZRJVjzGJ1ZsMygRF26RwN932Vfkn1gyCiTbECVitBjRCkexEvetLdiqzTcYimmzYxyR1BZ79KNevgt61PDcukmC7"] + Descriptor: wsh(sortedmulti(2,[6738736c/48'/0'/0'/2']xpub6FC1fXFP1GXLX5TKtcjHGT4q89SDRehkQLtbKJ2PzWcvbBHtyDsJPLtpLtkGqYNYZdVVAjRQ5kug9CsapegmmeRutpP7PW4u4wVF9JfkDhw,[b2b1f0cf/48'/0'/0'/2']xpub6EWhjpPa6FqrcaPBuGBZRJVjzGJ1ZsMygRF26RwN932Vfkn1gyCiTbECVitBjRCkexEvetLdiqzTcYimmzYxyR1BZ79KNevgt61PDcukmC7)) +<br> +Miniscript: A 3-of-3 that becomes a 2-of-3 after 90 days + Descriptor template: wsh(thresh(3,pk(@0/**),s:pk(@1/**),s:pk(@2/**),sln:older(12960))) + Keys info: ["[6738736c/48'/0'/0'/100']xpub6FC1fXFP1GXQpyRFfSE1vzzySqs3Vg63bzimYLeqtNUYbzA87kMNTcuy9ubr7MmavGRjW2FRYHP4WGKjwutbf1ghgkUW9H7e3ceaPLRcVwa", "[b2b1f0cf/44'/0'/0'/100']xpub6EYajCJHe2CK53RLVXrN14uWoEttZgrRSaRztujsXg7yRhGtHmLBt9ot9Pd5ugfwWEu6eWyJYKSshyvZFKDXiNbBcoK42KRZbxwjRQpm5Js", "[a666a867/44'/0'/0'/100']xpub6Dgsze3ujLi1EiHoCtHFMS9VLS1UheVqxrHGfP7sBJ2DBfChEUHV4MDwmxAXR2ayeytpwm3zJEU3H3pjCR6q6U5sP2p2qzAD71x9z5QShK2"] + Descriptor: wsh(thresh(3,pk([6738736c/48'/0'/0'/100']xpub6FC1fXFP1GXQpyRFfSE1vzzySqs3Vg63bzimYLeqtNUYbzA87kMNTcuy9ubr7MmavGRjW2FRYHP4WGKjwutbf1ghgkUW9H7e3ceaPLRcVwa/<0,1>/*),s:pk([b2b1f0cf/44'/0'/0'/100']xpub6EYajCJHe2CK53RLVXrN14uWoEttZgrRSaRztujsXg7yRhGtHmLBt9ot9Pd5ugfwWEu6eWyJYKSshyvZFKDXiNbBcoK42KRZbxwjRQpm5Js/<0,1>/*),s:pk([a666a867/44'/0'/0'/100']xpub6Dgsze3ujLi1EiHoCtHFMS9VLS1UheVqxrHGfP7sBJ2DBfChEUHV4MDwmxAXR2ayeytpwm3zJEU3H3pjCR6q6U5sP2p2qzAD71x9z5QShK2/<0,1>/*),sln:older(12960))) +<br> +Miniscript: A singlesig wallet with automatic inheritance to a timelocked 2-of-3 multisig + Descriptor template: wsh(or_d(pk(@0/**),and_v(v:multi(2,@1/**,@2/**,@3/**),older(65535)))) + Keys info: ["[6738736c/48'/0'/0'/100']xpub6FC1fXFP1GXQpyRFfSE1vzzySqs3Vg63bzimYLeqtNUYbzA87kMNTcuy9ubr7MmavGRjW2FRYHP4WGKjwutbf1ghgkUW9H7e3ceaPLRcVwa", "[b2b1f0cf/44'/0'/0'/100']xpub6EYajCJHe2CK53RLVXrN14uWoEttZgrRSaRztujsXg7yRhGtHmLBt9ot9Pd5ugfwWEu6eWyJYKSshyvZFKDXiNbBcoK42KRZbxwjRQpm5Js", "[a666a867/44'/0'/0'/100']xpub6Dgsze3ujLi1EiHoCtHFMS9VLS1UheVqxrHGfP7sBJ2DBfChEUHV4MDwmxAXR2ayeytpwm3zJEU3H3pjCR6q6U5sP2p2qzAD71x9z5QShK2", "[bb641298/44'/0'/0'/100']xpub6Dz8PHFmXkYkykQ83ySkruky567XtJb9N69uXScJZqweYiQn6FyieajdiyjCvWzRZ2GoLHMRE1cwDfuJZ6461YvNRGVBJNnLA35cZrQKSRJ"] + Descriptor: wsh(or_d(pk([6738736c/48'/0'/0'/100']xpub6FC1fXFP1GXQpyRFfSE1vzzySqs3Vg63bzimYLeqtNUYbzA87kMNTcuy9ubr7MmavGRjW2FRYHP4WGKjwutbf1ghgkUW9H7e3ceaPLRcVwa),and_v(v:multi(2,[b2b1f0cf/44'/0'/0'/100']xpub6EYajCJHe2CK53RLVXrN14uWoEttZgrRSaRztujsXg7yRhGtHmLBt9ot9Pd5ugfwWEu6eWyJYKSshyvZFKDXiNbBcoK42KRZbxwjRQpm5Js,[a666a867/44'/0'/0'/100']xpub6Dgsze3ujLi1EiHoCtHFMS9VLS1UheVqxrHGfP7sBJ2DBfChEUHV4MDwmxAXR2ayeytpwm3zJEU3H3pjCR6q6U5sP2p2qzAD71x9z5QShK2,[bb641298/44'/0'/0'/100']xpub6Dz8PHFmXkYkykQ83ySkruky567XtJb9N69uXScJZqweYiQn6FyieajdiyjCvWzRZ2GoLHMRE1cwDfuJZ6461YvNRGVBJNnLA35cZrQKSRJ),older(65535)))) +<br> +Taproot wallet policy with sortedmulti_a and a miniscript leaf + Descriptor template: tr(@0/**,{sortedmulti_a(1,@0/<2;3>/*,@1/**),or_b(pk(@2/**),s:pk(@3/**))}) + Keys info: ["[6738736c/48'/0'/0'/100']xpub6FC1fXFP1GXQpyRFfSE1vzzySqs3Vg63bzimYLeqtNUYbzA87kMNTcuy9ubr7MmavGRjW2FRYHP4WGKjwutbf1ghgkUW9H7e3ceaPLRcVwa", "xpub6Fc2TRaCWNgfT49nRGG2G78d1dPnjhW66gEXi7oYZML7qEFN8e21b2DLDipTZZnfV6V7ivrMkvh4VbnHY2ChHTS9qM3XVLJiAgcfagYQk6K", "xpub6GxHB9kRdFfTqYka8tgtX9Gh3Td3A9XS8uakUGVcJ9NGZ1uLrGZrRVr67DjpMNCHprZmVmceFTY4X4wWfksy8nVwPiNvzJ5pjLxzPtpnfEM", "xpub6GjFUVVYewLj5no5uoNKCWuyWhQ1rKGvV8DgXBG9Uc6DvAKxt2dhrj1EZFrTNB5qxAoBkVW3wF8uCS3q1ri9fueAa6y7heFTcf27Q4gyeh6"] + Descriptor: tr([6738736c/48'/0'/0'/100']xpub6FC1fXFP1GXQpyRFfSE1vzzySqs3Vg63bzimYLeqtNUYbzA87kMNTcuy9ubr7MmavGRjW2FRYHP4WGKjwutbf1ghgkUW9H7e3ceaPLRcVwa/<0;1>/*,{sortedmulti_a(1,xpub6FC1fXFP1GXQpyRFfSE1vzzySqs3Vg63bzimYLeqtNUYbzA87kMNTcuy9ubr7MmavGRjW2FRYHP4WGKjwutbf1ghgkUW9H7e3ceaPLRcVwa/<2;3>/*,xpub6Fc2TRaCWNgfT49nRGG2G78d1dPnjhW66gEXi7oYZML7qEFN8e21b2DLDipTZZnfV6V7ivrMkvh4VbnHY2ChHTS9qM3XVLJiAgcfagYQk6K/<0;1>/*),or_b(pk(xpub6GxHB9kRdFfTqYka8tgtX9Gh3Td3A9XS8uakUGVcJ9NGZ1uLrGZrRVr67DjpMNCHprZmVmceFTY4X4wWfksy8nVwPiNvzJ5pjLxzPtpnfEM/<0;1>/*),s:pk(xpub6GjFUVVYewLj5no5uoNKCWuyWhQ1rKGvV8DgXBG9Uc6DvAKxt2dhrj1EZFrTNB5qxAoBkVW3wF8uCS3q1ri9fueAa6y7heFTcf27Q4gyeh6/<0;1>/*))}) +<br> + +=== Invalid policies === + +The following descriptor templates are invalid: + +* <tt>pkh(@0)</tt>: Key placeholder with no path following it +* <tt>pkh(@0/0/**)</tt>: Key placeholder with an explicit path present +* <tt>sh(multi(1,@1/**,@0/**))</tt>: Key placeholders out of order +* <tt>sh(multi(1,@0/**,@2/**))</tt>: Skipped key placeholder <tt>@1</tt> +* <tt>sh(multi(1,@0/**,@0/**))</tt>: Repeated keys with the same path expression +* <tt>sh(multi(1,@0/<0;1>/*,@0/<1;2>/*))</tt>: Non-disjoint multipath expressions (<tt>@0/1/*</tt> appears twice) +* <tt>sh(multi(1,@0/**,xpub6AHA9hZDN11k2ijHMeS5QqHx2KP9aMBRhTDqANMnwVtdyw2TDYRmF8PjpvwUFcL1Et8Hj59S3gTSMcUQ5gAqTz3Wd8EsMTmF3DChhqPQBnU/<0;1>/*))</tt>: Expression with a non-KP key present +* <tt>pkh(@0/<0;1;2>/*)</tt>: Solved cardinality > 2 + +Remark: some of the examples of invalid descriptor templates may be valid via optional extensions. + +== Backwards Compatibility == + +The <tt>@</tt> character used for key placeholders is not part of the syntax of output script descriptors, therefore any valid descriptor with at least one <tt>KEY</tt> expression is not a valid descriptor template. Vice versa, any descriptor template with at least one key placeholder is not a valid output script descriptor. + +Adoption of wallet policies in software and hardware wallets is opt-in. Conversion from wallet policies to the corresponding descriptors is programmatically extremely easy, and conversion from descriptors to wallet policies (when respecting the required patterns) can be automated. See the reference implementation below for some examples of conversion. + +Software wallets are recommended to allow exporting plain descriptors for the purposes of interoperability with software not using wallet policies. + +== Reference Implementation == + +Wallet policies are implemented in +* the [https://github.com/LedgerHQ/app-bitcoin-new Ledger bitcoin application] since version 2.1.0; +* the [https://github.com/digitalbitbox/bitbox02-firmware BitBox02 firmware] since version v9.15.0; +* [https://github.com/Blockstream/Jade Blockstream Jade] since version v1.0.24, via [https://github.com/ElementsProject/libwally-core libwally-core] v1.0.0. + +For development and testing purposes, we provide a [[bip-0388/wallet_policies.py|Python 3.7 reference implementation]] of simple classes to handle wallet policies, and the conversion to/from output script descriptors. +The reference implementation is for demonstration purposes only and not to be used in production environments. + +==Footnotes== + +<references /> + +== Acknowledgments == + +The authors would like to thank the people who provided feedback in the bitcoin-dev list, and in person. diff --git a/bip-0388/wallet_policies.py b/bip-0388/wallet_policies.py new file mode 100755 index 0000000..4cd5031 --- /dev/null +++ b/bip-0388/wallet_policies.py @@ -0,0 +1,202 @@ +#!/usr/bin/env python3 + +from typing import Iterable, List, Mapping, Tuple, Generator + + +def find_all(text: str, pattern: str, start: int = 0) -> Generator[int, None, None]: + """Generates all the positions of `pattern` as a substring of `text`, starting from index at least `start`.""" + while True: + start = text.find(pattern, start) + if start == -1: + return + yield start + start += len(pattern) + + +def find_first(text: str, start_pos: int, patterns: Iterable[str]) -> int: + """Returns the position of the first occurrence of any of the elements in `patterns` as a substring of `text`, + or -1 if none of the patterns is found.""" + matches = (text.find(x, start_pos) for x in patterns) + return min((x for x in matches if x != -1), default=-1) + + +def find_key_end_position(desc: str, start_pos: int) -> int: + """Assuming that `start_pos` is the beginning of a KEY expression (and not musig), finds the position of the end + of the key expression, excluding (if present) the final derivation steps after an xpub. This is the information + that goes into an entry of the vector of key information of the wallet policy.""" + + has_orig_info = True if desc[start_pos] == '[' else False + + if has_orig_info: + closing_bracket_pos = desc.find("]", start_pos) + if closing_bracket_pos == -1: + raise Exception("Invalid descriptor: could not find closing ']'") + key_pos_start = closing_bracket_pos + 1 + else: + key_pos_start = start_pos + + # find the earliest occurrence of ",", a ")" or a "/" (it must find at least 1) + end_pos = find_first(desc, key_pos_start, [",", ")", "/"]) + if end_pos == -1: + raise Exception( + "Invalid descriptor: cannot find the end of key expression") + + return end_pos + + +class WalletPolicy(object): + """Simple class to represent wallet policies. This is a toy implementation that does not parse the descriptor + template. A more robust implementation would build the abstract syntax tree of the template and of the descriptor, + allowing one to detect errors, and manipulate it semantically instead of relying on string manipulation.""" + + def __init__(self, descriptor_template: str, keys_info: List[str]): + self.descriptor_template = descriptor_template + self.keys_info = keys_info + + def to_descriptor(self) -> str: + """Converts a wallet policy into the descriptor (with the /<M,N> syntax, if present).""" + + desc = self.descriptor_template + + # replace each "/**" with "/<0;1>/*" + desc = desc.replace("/**", "/<0;1>/*") + + # process all the @N expressions in decreasing order. This guarantees that string replacements + # works as expected (as any prefix expression is processed after). + for i in reversed(range(len(self.keys_info))): + desc = desc.replace(f"@{i}", self.keys_info[i]) + + # there should not be any remaining "@" expressions + if desc.find("@") != -1: + return Exception("Invalid descriptor template: contains invalid key index") + + return desc + + @classmethod + def from_descriptor(cls, descriptor: str) -> 'WalletPolicy': + """Converts a "reasonable" descriptor (with the /<M,N> syntax) into the corresponding wallet policy.""" + + # list of pairs of integers, where the tuple (m,n) with m < n means a key expression starts at + # m (inclusive) and at n (exclusive) + key_expressions: List[Tuple[int, int]] = [] + + key_with_orig_pos_start = None + + def parse_key_expressions(only_first=False, handle_musig=False): + # Starting at the position in `key_with_orig_pos_start`, parses a number of key expressions, and updates + # the `key_expressions` array accordingly. + # If `only_first` is `True`, it stops after parsing a single key expression. + # If `handle_musig` is `True`, and a key expression is a `musig` operator, it recursively parses + # the keys in the musig expression. `musig` inside `musig` is not allowed. + + nonlocal key_with_orig_pos_start + if key_with_orig_pos_start is None: + raise Exception("Unexpected error") + + while True: + if handle_musig and descriptor[key_with_orig_pos_start:].startswith("musig"): + closing_parenthesis_pos = find_first( + descriptor, key_with_orig_pos_start, [")"]) + if closing_parenthesis_pos == -1: + raise Exception( + "Invalid descriptor: musig without closing parenthesis") + key_with_orig_pos_start = key_with_orig_pos_start + \ + len("musig(") + parse_key_expressions( + only_first=False, handle_musig=False) + + key_pos_end = closing_parenthesis_pos + 1 + else: + key_pos_end = find_key_end_position( + descriptor, key_with_orig_pos_start) + key_expressions.append( + (key_with_orig_pos_start, key_pos_end)) + + if descriptor[key_pos_end] == '/': + # find the actual end (comma or closing parenthesis) + key_pos_end = find_first( + descriptor, key_pos_end, [",", ")"]) + if key_pos_end == -1: + raise Exception( + "Invalid descriptor: unterminated key expression") + + if descriptor[key_pos_end] == ',': + # There is another key expression, repeat from after the comma + key_with_orig_pos_start = key_pos_end + 1 + else: + break + + if only_first: + break + + # operators for which the KEY is the first argument + operators_key_first = ["pk", "pkh", "pk_h", "pk_k", "tr"] + # operators for which the KEY is everything except the first argument + operators_key_all_but_first = [ + "multi", "sortedmulti", "multi_a", "sortedmulti_a"] + for op in operators_key_first + operators_key_all_but_first: + for op_pos_start in find_all(descriptor, op + "("): + + # ignore if not a whole word (otherwise "sortedmulti" would be found inside "multi") + if op_pos_start > 0 and 'a' <= desc[op_pos_start - 1] <= 'z': + continue + + if op in operators_key_all_but_first: + # skip the first argument (we now it's not a KEY expression, so it does not have a comma) + first_comma_pos = descriptor.find(",", op_pos_start) + if first_comma_pos == -1: + raise Exception( + "Invalid descriptor: multi, sortedmulti, multi_a and sortedmulti_a must have at least two arguments") + key_with_orig_pos_start = 1 + first_comma_pos + else: + # other operators, the first argument is already a KEY expression + key_with_orig_pos_start = op_pos_start + len(op) + 1 + + only_first = op in operators_key_first + parse_key_expressions( + only_first=only_first, handle_musig=True) + + result: List[str] = [] + keys: List[str] = [] + keys_to_idx: Mapping[str, int] = {} + + prev_end = 0 + for start, end in sorted(key_expressions): + result.append(descriptor[prev_end:start]) + + key = descriptor[start:end] + if key not in keys_to_idx: + idx = len(keys) + keys.append(key) + keys_to_idx[key] = idx + else: + idx = keys_to_idx[key] + result.append(f"@{idx}") + + prev_end = end + + result.append(descriptor[prev_end:]) + + return cls("".join(result), keys) + + +if __name__ == "__main__": + descriptors = [ + "pkh([d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/**)", + "wsh(multi(1,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/**,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/**))", + "tr([12345678/44'/0'/0']xpub6BVZ6JrGsWsUbpP74S8rnz13hVFDtYtKyuTTEYPNSF6GFpDFpL1YXWg3BpwpUWAnsZZ7Qe3XKz7GL3BEx3RQVq61cxqSkjceq25S1xFKFVa,{pk(xpub6AGdromjXf5yf3m7ndaCoR9Ac3UjwTvQ7QQkZoyoh2vfGE9i1AwB2vCbvjTpBL1KRERUsGszg63SVNXsHZU3CiykQqtZPrdXKMdaG2vs6uu),pk(xpub6AnhdkteWC4kPQvkY3QQXGmDCMfmFoYzEQ7FwRFa4BQ1a22k4VL4BD3Jdcog2Sf2KzBscXXAdPRMgjCBDeq6bAryqnMaWX2FaVUGPxWMLDh)})", + "tr(xpub6AEWqA1MNRzBBXenkug4NtNguDKTNcXoKQj8fU9VQyid38yikruFRffjoDm9UEaHGEJ6jQxjYdWWZRxR7Xy5ePrQNjohXJuNzkRNSiiBUcE,sortedmulti_a(2,[11223344/44'/0'/0']xpub6AyJhEKxcPaPnYNuA7VBeUQ24v6mEzzPSX5AJm3TSyg1Zsti7rnGKy1Hg6JAdXKF4QUmFZbby9p97AjBNm2VFCEec2ip5C9JntyxosmCeMW,xpub6AQVHBgieCHpGo4GhpGAo4v9v7hfr2Kr4D8ZQJqJwbEyZwtW3pWYSLRQyrNYbTzpoq6XpFtaKZGnEGUMtiydCgqsJDAZNqs9L5QDNKqUBsV))", + "tr([11111111/44'/0'/0']xpub6CLZSUDtcUhJVDoPSY8pSRKi4W1RSSLBgwZ2AYmwTH9Yv5tPVFHZxJBUQ27QLLwHej6kfo9DQQbwaHmpXsQq59CjtsE2gNLHmojwgMrsQNe/**,{and_v(v:pk([22222222/44'/0'/0']xpub6CiztfGsUxmpwkWe6gvz8d5VHyFLDoiPpeUfWmQ2vWAhQL3Z1hhEc6PE4irFs4bzjS7dCB4yyinaubrCpFJq4bcKGCD4jjqTxaWiKAJ7mvJ/**),older(52596)),multi_a(2,[33333333/44'/0'/0']xpub6DTZd6od7is2wxXndmE7zaUifzFPwVKshVSGEZedfTJtUjfLyhy4hgCW15hvxRpGaDmtiFoJKaCEaSRfXrQBuYRx18zwquy46dwBsJnsrz2/**,[44444444/44'/0'/0']xpub6BnK4wFbPeLZM4VNjoUA4yLCru6kCT3bhDJNBhbzHLGp1fmgK6muz27h4drixJZeHG8vSS5U5EYyE3gE8ozG94iNg3NDYE8M5YafvhzhMR9/**)})", + "tr(musig([33333333/44'/0'/0']xpub6DTZd6od7is2wxXndmE7zaUifzFPwVKshVSGEZedfTJtUjfLyhy4hgCW15hvxRpGaDmtiFoJKaCEaSRfXrQBuYRx18zwquy46dwBsJnsrz2,[44444444/44'/0'/0']xpub6BnK4wFbPeLZM4VNjoUA4yLCru6kCT3bhDJNBhbzHLGp1fmgK6muz27h4drixJZeHG8vSS5U5EYyE3gE8ozG94iNg3NDYE8M5YafvhzhMR9)/**,{and_v(v:pk([22222222/44'/0'/0']xpub6CiztfGsUxmpwkWe6gvz8d5VHyFLDoiPpeUfWmQ2vWAhQL3Z1hhEc6PE4irFs4bzjS7dCB4yyinaubrCpFJq4bcKGCD4jjqTxaWiKAJ7mvJ/**),older(52596)),pk([11111111/44'/0'/0']xpub6CLZSUDtcUhJVDoPSY8pSRKi4W1RSSLBgwZ2AYmwTH9Yv5tPVFHZxJBUQ27QLLwHej6kfo9DQQbwaHmpXsQq59CjtsE2gNLHmojwgMrsQNe/**)})", + ] + + for desc in descriptors: + # Demoes the conversion from a "sane" descriptor to a wallet policy + print(f"Descriptor:\n{desc}") + wp = WalletPolicy.from_descriptor(desc) + print(f"Policy descriptor template:\n{wp.descriptor_template}") + print(f"Keys:\n{wp.keys_info}") + print("======================================================\n") + + # Converting back to descriptors also works, as long as we take care of /** + assert wp.to_descriptor().replace("/<0;1>/*", "/**") == desc diff --git a/bip-0389.mediawiki b/bip-0389.mediawiki new file mode 100644 index 0000000..500d7e3 --- /dev/null +++ b/bip-0389.mediawiki @@ -0,0 +1,109 @@ +<pre> + BIP: 389 + Layer: Applications + Title: Multipath Descriptor Key Expressions + Author: Ava Chow <me@achow101.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0389 + Status: Draft + Type: Informational + Created: 2022-07-26 + License: BSD-2-Clause +</pre> + +==Abstract== + +This document specifies a modification to Key Expressions of Descriptors that are described in BIP 380. +This modification allows Key Expressions to indicate BIP 32 derivation path steps that can have multiple values. + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. + +==Motivation== + +Descriptors can describe the scripts that are used in a wallet, but wallets often require at least two descriptors for all of the scripts that they watch for. +Wallets typically have one descriptor for producing receiving addresses, and the other for change addresses. +These descriptors are often extremely similar - they produce the same types of scripts, derive keys from the same master key, and use derivation paths that are almost identical. +The only differences are in the derivation path where one of the steps will be different between the descriptors. +Thus it is useful to have a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. + +==Specification== + +For extended keys and their derivations paths in a Key Expression, BIP 380 states: + +* <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded extended private key (as defined in BIP 32) +** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path elements indicating BIP 32 derivation steps to be taken after the given extended key. +** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final step to denote all direct unhardened or hardened children. + +This is modifed to state: + +* <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded extended private key (as defined in BIP 32) +** Followed by zero or more <tt>/NUM</tt> (may be followed by <tt>h</tt>, <tt>H</tt>, or <tt>'</tt> to indicate a hardened step) path elements indicating BIP 32 derivation steps to be taken after the given extended key. +** Followed by zero or one <tt>/<NUM;NUM</tt> (each <tt>NUM</tt> may be followed by <tt>h</tt>, <tt>H</tt>, or <tt>'</tt> to indicate a hardened step) path element indicating a tuple of BIP 32 derivation steps to be taken after the given extended key. +*** Followed by zero or more <tt>;NUM</tt> (may be followed by <tt>h</tt>, <tt>H</tt>, or <tt>'</tt> to indicate a hardened step) additional tuple values of BIP 32 derivation steps +*** Followed by a single <tt>>/</tt> +** Followed by zero or more <tt>/NUM</tt> (may be followed by <tt>h</tt>, <tt>H</tt>, or <tt>'</tt> to indicate a hardened step) path elements indicating BIP 32 derivation steps to be taken after the given extended key. +** Optionally followed by a single <tt>/*</tt> (may be followed by <tt>h</tt>, <tt>H</tt>, or <tt>'</tt> to indicate a hardened step) final step to denote all direct unhardened or hardened children. + +When a <tt>/<NUM;NUM;...;NUM></tt> is encountered, parsers should account for a presence of multiple descriptors where the first descriptor uses the first <tt>NUM</tt>, and a second descriptor uses the second <tt>NUM</tt>, and so on, until each <tt>NUM</tt> is accounted for in the production of public keys, scripts, and addresses, as well as descriptor import and export operations. +Descriptors that contain multiple Key Expressions that each have a <tt>/<NUM;NUM;...;NUM></tt> must have tuples of exactly the same length so that they are derived in lockstep in the same way that <tt>/*</tt> paths in multiple Key expressions are handled. + +The common use case for this is to represent descriptors for producing receiving and change addresses. +When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses, and the second descriptor for producing change addresses. +For this use case, the element will commonly be the value <tt>/<0;1></tt> + +Note that only one <tt>/<NUM;NUM;...;NUM></tt> specifier is allowed in a Key Expression. + +==Test Vectors== + +Valid multipath descriptors followed by the descriptors they expand into as sub-bullets + +* <tt>pk(xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/<0;1>)</tt> +** <tt>pk(xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/0)</tt> +** <tt>pk(xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/1)</tt> +* <tt>pkh(xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/<2147483647h;0>/0)</tt> +** <tt>pkh(xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/2147483647h/0)</tt> +** <tt>pkh(xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/0/0)</tt> +* <tt>wpkh([ffffffff/13h]xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/<1;3>/2/*</tt> +** <tt>wpkh([ffffffff/13h]xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/1/2/*)</tt> +** <tt>wpkh([ffffffff/13h]xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/3/2/*)</tt> +* <tt>multi(2,xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/<1;2>/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/<3;4>/0/*)</tt> +** <tt>multi(2,xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/3/0/*)</tt> +** <tt>multi(2,xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/2/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/4/0/*)</tt> +* <tt>pkh(xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/<0;1;2>)</tt> +** <tt>pkh(xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/0)</tt> +** <tt>pkh(xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1)</tt> +** <tt>pkh(xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/2)</tt> +* <tt>sh(multi(2,xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/<1;2;3>/0/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/0/*,xpub661MyMwAqRbcGDZQUKLqmWodYLcoBQnQH33yYkkF3jjxeLvY8qr2wWGEWkiKFaaQfJCoi3HeEq3Dc5DptfbCyjD38fNhSqtKc1UHaP4ba3t/0/0/<3;4;5>/*))</tt> +** <tt>sh(multi(2,xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/0/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/0/*,xpub661MyMwAqRbcGDZQUKLqmWodYLcoBQnQH33yYkkF3jjxeLvY8qr2wWGEWkiKFaaQfJCoi3HeEq3Dc5DptfbCyjD38fNhSqtKc1UHaP4ba3t/0/0/3/*))</tt> +** <tt>sh(multi(2,xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/2/0/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/0/*,xpub661MyMwAqRbcGDZQUKLqmWodYLcoBQnQH33yYkkF3jjxeLvY8qr2wWGEWkiKFaaQfJCoi3HeEq3Dc5DptfbCyjD38fNhSqtKc1UHaP4ba3t/0/0/4/*))</tt> +** <tt>sh(multi(2,xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/3/0/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y/0/*,xpub661MyMwAqRbcGDZQUKLqmWodYLcoBQnQH33yYkkF3jjxeLvY8qr2wWGEWkiKFaaQfJCoi3HeEq3Dc5DptfbCyjD38fNhSqtKc1UHaP4ba3t/0/0/5/*))</tt> + +Invalid descriptors + +* Multiple multipath specifiers: <tt>pkh(xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/<0;1>/<2;3>)</tt> +* Multipath specifier in origin: <tt>pkh([deadbeef/<0;1>]xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/0)</tt> +* Multipath specifiers of mismatched lengths: <tt>tr(xpub661MyMwAqRbcF3yVrV2KyYetLMYA5mCbv4BhrKwUrFE9LZM6JRR1AEt8Jq4V4C8LwtTke6YEEdCZqgXp85YRk2j74EfJKhe3QybQ9kcUjs4/<6;7;8;9>/*,{pk(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/<1;2;3>/0/*),pk(xpub661MyMwAqRbcGDZQUKLqmWodYLcoBQnQH33yYkkF3jjxeLvY8qr2wWGEWkiKFaaQfJCoi3HeEq3Dc5DptfbCyjD38fNhSqtKc1UHaP4ba3t/0/0/<3;4;5>/*)})</tt> +* Multipath specifiers of mismatched lengths: <tt>sh(multi(2,xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc/<1;2;3>/0/*,xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L/0/*,xprv9s21ZrQH143K3jUwNHoqQNrtzJnJmx4Yup8NkNLdVQCymYbPbJXnPhwkfTfxZfptcs3rLAPUXS39oDLgrNKQGwbGsEmJJ8BU3RzQuvShEG4/0/0/<3;4>/*))</tt> +* Empty multipath specifier: <tt>wpkh(xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/<>/*)</tt> +* Missing multipath start: <tt>wpkh(xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/0>/*)</tt> +* Missing multipath end: <tt>wpkh(xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/<0/*)</tt> +* Missing index in multipath specifier: <tt>wpkh(xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/<0;>/*)</tt> + +==Backwards Compatibility== + +This is an addition to the Key Expressions defined in BIP 380. +Key Expressions using the format described in BIP 380 are compatible with this modification and parsers that implement this will still be able to parse such descriptors. +However as this is an addition to Key Expressions, older parsers will not be able to understand such descriptors. + +This modification to Key Expressions uses two new characters: <tt><</tt> and <tt>;</tt>. +These are part of the descriptor character set and so are covered by the checksum algorithm. +As these are previously unused characters, old parsers will not accidentally mistake them for indicating something else. + +This proposal is in contrast to similar proposals such as BIP 88 which allow for multiple derivation indexes in a single element. +This limitation exists in order to reduce the number of descriptors that are expanded, avoid confusion about how to expand the descriptor, and avoid having expanded descriptors that users are not expecting. + +==Reference Implementation== + +https://github.com/bitcoin/bitcoin/pull/22838 diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl index 292f1ee..4923a9e 100755 --- a/scripts/buildtable.pl +++ b/scripts/buildtable.pl @@ -96,6 +96,9 @@ my %emails; my $bipnum = 0; while (++$bipnum <= $topbip) { my $fn = sprintf "bip-%04d.mediawiki", $bipnum; + if (!-e $fn) { + $fn = sprintf "bip-%04d.md", $bipnum; + } -e $fn || next; open my $F, "<$fn"; while (<$F> !~ m[^(?:\xef\xbb\xbf)?<pre>$]) { diff --git a/scripts/diffcheck.sh b/scripts/diffcheck.sh index 4e4c459..aa9f557 100755 --- a/scripts/diffcheck.sh +++ b/scripts/diffcheck.sh @@ -1,5 +1,6 @@ #!/bin/bash +scripts/buildtable.pl >/tmp/table.mediawiki 2> /dev/null diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true @@ -8,6 +9,8 @@ if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null echo "$newdiff" exit 1 fi + echo "README table matches expected table from BIP files" else echo 'Cannot build previous commit table for comparison' + exit 1 fi diff --git a/scripts/link-format-chk.sh b/scripts/link-format-chk.sh index e3f0f6d..9493765 100755 --- a/scripts/link-format-chk.sh +++ b/scripts/link-format-chk.sh @@ -8,16 +8,14 @@ ECODE=0 FILES="" -for fname in $(git diff --name-only HEAD $(git merge-base HEAD master)); do - if [[ $fname == *.mediawiki ]]; then - GRES=$(grep -n '](http' $fname) - if [ "$GRES" != "" ]; then - if [ $ECODE -eq 0 ]; then - >&2 echo "Github Mediawiki format writes link as [URL text], not as [text](url):" - fi - ECODE=1 - echo "- $fname:$GRES" +for fname in *.mediawiki; do + GRES=$(grep -n '](http' $fname) + if [ "$GRES" != "" ]; then + if [ $ECODE -eq 0 ]; then + >&2 echo "Github Mediawiki format writes link as [URL text], not as [text](url):" fi + ECODE=1 + echo "- $fname:$GRES" fi done exit $ECODE |
