diff options
| -rw-r--r-- | README.mediawiki | 28 | ||||
| -rw-r--r-- | bip-0087.mediawiki | 274 | ||||
| -rw-r--r-- | bip-0088.mediawiki | 229 | ||||
| -rw-r--r-- | bip-0129.mediawiki | 462 | ||||
| -rw-r--r-- | bip-0343.mediawiki | 62 |
5 files changed, 1055 insertions, 0 deletions
diff --git a/README.mediawiki b/README.mediawiki index 5ab7499..d8bcae6 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -434,6 +434,20 @@ Those proposing changes should consider that ultimately consent may rest with th | Ethan Kosakovsky | Informational | Draft +|- style="background-color: #ffffcf" +| [[bip-0087.mediawiki|87]] +| Applications +| Hierarchy for Deterministic Multisig Wallets +| Robert Spigler +| Standard +| Proposed +|- style="background-color: #ffffcf" +| [[bip-0088.mediawiki|88]] +| Applications +| Hierarchical Deterministic Path Templates +| Dmitry Petukhov +| Informational +| Proposed |- style="background-color: #cfffcf" | [[bip-0090.mediawiki|90]] | @@ -645,6 +659,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- style="background-color: #ffffcf" +| [[bip-0129.mediawiki|129]] +| Applications +| Bitcoin Secure Multisig Setup (BSMS) +| Hugo Nguyen, Peter Gray, Marko Bencun, Aaron Chen, Rodolfo Novak +| Standard +| Proposed +|- style="background-color: #ffffcf" | [[bip-0130.mediawiki|130]] | Peer Services | sendheaders message @@ -987,6 +1008,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Pieter Wuille, Jonas Nick, Anthony Towns | Standard | Draft +|- style="background-color: #ffffcf" +| [[bip-0343.mediawiki|343]] +| Consensus (soft fork) +| Mandatory activation of taproot deployment +| Shinobius, Michael Folkson +| Standard +| Proposed |- | [[bip-0350.mediawiki|350]] | Applications diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki new file mode 100644 index 0000000..d270027 --- /dev/null +++ b/bip-0087.mediawiki @@ -0,0 +1,274 @@ +<pre> + BIP: 87 + Layer: Applications + Title: Hierarchy for Deterministic Multisig Wallets + Author: Robert Spigler <RobertSpigler@ProtonMail.ch> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0087 + Status: Proposed + Type: Standards Track + Created: 2020-03-11 + License: BSD-2-Clause +</pre> + +==Abstract== + +This BIP defines a sane hierarchy for deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on), purpose scheme described in BIP-0043 (BIP43 from now on), and multi-account hierarchy described in BIP-0044 (BIP44 from now on). + +This BIP is a particular application of BIP43. + +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + +==Motivation== + +With the increase of more user friendly (offline) multisignature wallets, and adoption of new technologies such as [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 (Partially Signed Bitcoin Transactions)], it is necessary to create a common derivation scheme that makes use of all new technologies. + +As background, BIP 44/49/84 specifies: + +<pre> +m / purpose' / coin_type' / account' / change / address_index +</pre> + +where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively). Having a script-per-derivation for single sig wallets allows for easy backup and restore, with just the private key information. + +Multisignature wallets need more information to backup and restore (such as all cosigner public keys), and these per-script derivations are made redundant with descriptors, which provide that information (while also specifying a collection of output scripts). +A modern standardization is needed for multisig derivation paths. There are some in existence, but all have issues. For example, BIP45 specifies: + +<pre> +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. + +The second multisignature "standard" in use is m/48', which specifies: + +<pre> +m / purpose' / coin_type' / account' / script_type' / change / address_index +</pre> + +Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script. While it attempts to reduce maintainence work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, <code>script_type</code> list. + +The structure proposed later in this paper solves these issues and is quite comprehensive. It allows for the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party, multisignature, hierarchical deterministic wallet regardless of the script type <ref>'''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually). Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84). With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring. Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only.</ref>. + +This paper was inspired from BIP44. + +==Specification== + +===Key sorting=== + +Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> function) so that all possible multisignature addresses/scripts are derived from deterministically sorted public keys. + +===Path levels=== + +We should not be mixing keys and scripts in the same layer. The wallet should create extended private/public keys independent of the script type, whereas the descriptor language tells wallets to watch the multisig outputs with the specified public keys. + +We define the following 5 levels in the BIP32 path: + +<pre> +m / purpose' / coin_type' / account' / change / address_index +</pre> + +<code>h</code> or <code>'</code> in the path indicates that BIP32 hardened derivation is used. + +Each level has a special meaning, described in the chapters below. + +===Purpose=== + +Purpose is a constant set to <code>87'</code> following the BIP43 recommendation. +It indicates that the subtree of this node is used according to this specification. + +Hardened derivation is used at this level. + +===Coin type=== + +One master node (seed) can be used for multiple Bitcoin networks. +Sharing the same space for various networks has some disadvantages. + +This level creates a separate subtree for every network, avoiding reusing addresses across networks and improving privacy issues. + +Coin type <code>0</code> for mainnet and <code>1</code> for testnets (testnet, regtest, and signet). + +Hardened derivation is used at this level. + +===Account=== + +This level splits the key space into independent user identities, following the BIP44 pattern, so the wallet never mixes the coins across different accounts. + +Users can use these accounts to organize the funds in the same fashion as bank accounts; for donation purposes (where all addresses are considered public), for saving purposes, for common expenses, etc. + +Accounts are numbered from index <code>0</code> in sequentially increasing manner. +This number is used as child index in BIP32 derivation. + +Hardened derivation is used at this level. + +It is crucial that this level is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes. +For example, before sending a new key record to a coordinator, the wallet must increment the <code>account'</code> level. +This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and inbetween the same wallet types. + +===Change=== + +Constant <code>0</code> is used for external chain and constant <code>1</code> for internal chain (also known as change addresses). External chain is used for addresses that are meant to be visible outside of the wallet (e.g. for receiving payments). Internal chain is used for addresses which are not meant to be visible outside of the wallet and is used for return transaction change. + +Public derivation is used at this level. + +===Index=== + +Addresses are numbered from index <code>0</code> in sequentially increasing manner. +This number is used as child index in BIP32 derivation. + +Public derivation is used at this level. + +==Address Discovery== + +The multisig descriptors or descriptor template that is generated from the cosigners' combined key records should be used to generate and discover addresses. + +Please see [https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki BIP-0129 (Bitcoin Secure Multisig Setup)] for an introduction on descriptor templates. +The descriptor or descriptor template should contain the key origin information for maximum compatibility with BIP-0174. + +For example: + +The following descriptor template and derivation path restrictions: + +<code>wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/**,[xfpForB/87'/0'/0']XpubB/**))</code> + +<code>/0/*,/1/*</code> + +Expands to the two concrete descriptors: + +<code>wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/0/*,[xfpForB/87'/0'/0']XpubB/0/*))</code> + +<code>wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/1/*,[xfpForB/87'/0'/0']XpubB/1/*))</code> + +To discover addresses, import both the receiving and change descriptors; respect the gap limit described below. + +===Address Gap Limit=== + +Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain. + +Wallet software should warn when the user is trying to exceed the gap limit on an external descriptor by generating multiple unused addresses. + +==Backwards Compatibility== + +Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP. + +As wallets complying with this BIP are descriptor wallets, this therefore necessitates that the cosigners backup their private key information and the descriptor, in order to properly restore at a later time. This shouldn't be a user burden, since (to much user surprise), all cosigner public keys need to be supplied in addition to <code>M</code> seeds in any <code>M</code> of <code>N</code> multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection. + +==Rationale== + +<references/> + +==Examples== + +{| +|network +|account +|chain +|address +|path +|- +|mainnet +|first +|external +|first +|m / 87' / 0' / 0' / 0 / 0 +|- +|mainnet +|first +|external +|second +|m / 87' / 0' / 0' / 0 / 1 +|- +|mainnet +|first +|change +|first +|m / 87' / 0' / 0' / 1 / 0 +|- +|mainnet +|first +|change +|second +|m / 87' / 0' / 0' / 1 / 1 +|- +|mainnet +|second +|external +|first +|m / 87' / 0' / 1' / 0 / 0 +|- +|mainnet +|second +|external +|second +|m / 87' / 0' / 1' / 0 / 1 +|- +|testnet +|first +|external +|first +|m / 87' / 1' / 0' / 0 / 0 +|- +|testnet +|first +|external +|second +|m / 87' / 1' / 0' / 0 / 1 +|- +|testnet +|first +|change +|first +|m / 87' / 1' / 0' / 1 / 0 +|- +|testnet +|first +|change +|second +|m / 87' / 1' / 0' / 1 / 1 +|- +|testnet +|second +|external +|first +|m / 87' / 1' / 1' / 0 / 0 +|- +|testnet +|second +|external +|second +|m / 87' / 1' / 1' / 0 / 1 +|- +|testnet +|second +|change +|first +|m / 87' / 1' / 1' / 1 / 0 +|- +|testnet +|second +|change +|second +|m / 87' / 1' / 1' / 1 / 1 +|} + +==Reference Implementation== + +None at the moment. + +==Acknowledgement== + +Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, Sjors Provoost, and others for their feedback on the specification. + +==References== + +Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018630.html + +* [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032 (Hierarchical Deterministic Wallets)] +* [https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki BIP-0043 (Purpose Field for Deterministic Wallets)] +* [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP-0044 (Multi-Account Hierarchy for Deterministic Wallets)] +* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors] +* [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 (Partially Signed Bitcoin Transaction Format)] +* [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP-0067 (Deterministic Pay-to-script-hash multi-signature addresses through public key sorting)] +* [https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki BIP-0129 (Bitcoin Secure Multisig Setup)] diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki new file mode 100644 index 0000000..1f77c8e --- /dev/null +++ b/bip-0088.mediawiki @@ -0,0 +1,229 @@ +<pre> + BIP: 88 + Layer: Applications + Title: Hierarchical Deterministic Path Templates + Author: Dmitry Petukhov <dp@simplexum.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0088 + Status: Proposed + Type: Informational + Created: 2020-06-23 + License: BSD-2-Clause +</pre> + +==Abstract== + +This document describes a format for the representation of the templates that specify +the constraints that can be imposed on BIP32 derivation paths. + +The constraints specified by the templates allow to easily discern 'valid' paths, +that match the constraints, and 'invalid' paths, that exceed the constraints. + +==Copyright== + +This BIP is licensed under the 2-clause BSD license. + +==Motivation== + +BIP32 derivation path format is universal, and a number of schemes for derivation were proposed +in BIP43 and other documents, such as BIPs 44,45,49,84. The flexibility of the format also allowed +industry participants to implement custom derivation shemes that fit particular purposes, +but not necessarily useful in general. + +Even when existing BIPs for derivation schemes are used, their usage is not uniform across +the different wallets, in part because software vendors might have different considerations +and priorities when making decisions about derivation paths. This creates friction for users, +which might face problems when they try to access their coins using the wallet that derives +addresses differently than the one they used before. + +===Known solutions=== + +The problem is common enough to warrant the creation of a dedicated website +([https://walletsrecovery.org/ walletsrecovery.org]) that tracks paths used by different wallets. + +At the time of writing, this website has used their own format to succintly describe multiple +derivation paths. As far as author knows, it was the only publicitly used format to describe +path templates before introduction of this BIP. The format was not specified anywhere beside +the main page of the website. It used <code>|</code> to denote alternative derivation indexes +(example: <code>m/|44'|49'|84'/0'/0'</code>) or whole alternative paths (<code>m/44'/0'/0'|m/44'/1'/0'</code>). + +It was not declared as a template format to use for processing by software, and seems to be +an ad-hoc format only intended for illustration. In contrast to this ad-hoc format, the format +described in this BIP is intended for unambigouos parsing by software, and to be easily read by humans +at the same time. Humans can visually detect the 'templated' parts of the path more easily than the use +of <code>|</code> in the template could allow. Wider range of paths can be defined in a single template more +succintly and unambiguously. + +===Intended use and advantages=== + +Wallet software authors can use the proposed format to describe the derivation paths that +their software uses. This can improve user experience when switching to different wallet +software, restoring access to old wallets, etc. + +Unrestricted derivation path usage might be unsafe in certain contexts. In particular, when "change" +outputs of a transaction are sent to the addresses derived via paths unknown to the sender, the sender +might lose access to the whole change amount. + +A simplistic approach of hard-coding the checks for well-known paths into software and firmware leads +to reduced interoperability. Vendors cannot choose custom paths that are appropriate for +their particular, non-general-purpose applications, and are forced to shoehorn their solutions +into using well-known paths, or convince other vendors to support their custom paths. This approach +scales poorly. + +A flexible approach proposed in this document is to define a standard notation for "BIP32 path templates" +that succintly describes the constraints to impose on the derivation path. + +Wide support for these path templates will increase interoperability and flexibility of solutions, +and will allow vendors and individual developers to easily define their own custom restrictions. +This way, they will be able to deal with the risks of accidental or malicious use of unrestricted +derivation paths in a more flexible and precise manner. + +Well-known path templates can be pre-configured by default on devices and applications, +but users can have an option to turn off the templates that are not relevant to their uses. + +Having a standardized format for custom path templates will enable a common approach to be developed +in the enforcement of application-specific path restrictions in devices and applications. +One example of such an approach might be for devices to allow application-specific profiles +with path templates and possibly other custom parameters. Care must be taken to prevent the accidental +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. + +Template starts with optional prefix <code>m/</code>, and then one or more sections delimited by the slash character (<code>/</code>). + +Implementations MAY limit the maximum number of sections. + +Each section consists of ''index template'', optionally followed by the hardened marker: either an apostrophe (<code>'</code>) or letter <code>h</code>. + +Index template can be: + +* An integer value from 0 to 2147483647 ("Unit index template") +* A single <code>*</code> character, which denotes any value from 0 to 2147483647 ("Wildcard index template") +* The <code>{</code> character, followed by a number of ''index ranges'' delimited by commas (<code>,</code>), followed by <code>}</code> character ("Ranged index template") + +Implementations MAY limit the maximum number of index ranges within the Ranged index template. + +If an index template is immediately followed by hardened marker, this means that all values specified in this index template is to be increased by 2147483648 for the purposes of matching. + +Index range can be: + +* An integer value from 0 to 2147483647 ("Unit range") +* An integer value from 0 to 2147483647, followed by the <code>-</code> character, followed by another integer value from 0 to 2147483647 ("Non-unit range") + +For Non-unit range, value on the left side of the <code>-</code> character is the range_start, and the value on the right side of the <code>-</code> character is the range_end. + +For Unit range, we say that range_start is equal to range_end, even though there is no start/end in the Unit range. + +Unit index template contains a single index range, which is the Unit range + +Wildcard index template contains a single index range, and we say that its range_start is set to 0 and its range_end is set to 2147483647 + +Constraints: + +# To avoid ambiguity, whitespace MUST NOT appear within the path template. +# Commas within the Ranged index template MUST only appear in between index ranges. +# 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. +# 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. + +To achieve this, two extra rules are needed: + +* Within Ranged index template, subsequent range MUST NOT start with the value that is equal to the end of the previous range plus one. Thus, <code>{1,2,3-5}</code> is not allowed, and should be specified as <code>{1-5}</code> instead. This rule might make templates less convenient for frequent edits, though. + +* Only one type of hardened marker should be allowed (either <code>h</code> or <code>'</code>). + +Instead of requiring the second extra rule, implementations can simply replace one type of marker with another in the template strings before comparing them. + +==Full and partial templates== + +If the template starts with <code>m/</code>, that means that this is the "full" template, that matches the whole path. + +If the template does not start with <code>m/</code>, that means that this is a "partial" template, and it can be used to match a part of the path, in the contexts where this might be appropriate (for example, when constraints for the suffix of the path might be dynamic, while constraints for the prefix of the path are fixed). + +Full template can be combined with partial template, where partial template extends full template, +resulting in new, longer full template. + +Partial template can be combined with another partial template, resulting in new, longer partial template. + +Full template can not be combined with another full template. + +Implementations MUST support parsing full templates and matching paths against full templates. + +Implementations MAY support parsing partial templates and matching portions of the paths against partial templates, as well as combining the templates. + +==Parsing result== + +The result of successful parsing of a valid path template can be represented by a list of sections, where each section is a list of index ranges, where index range is a tuple of (range_start, range_end). The length of the list of sections is also referred to as the "length of the template". + +==Matching== + +The matching is to be performed against a list of integer values that represent a BIP32 path (or a portion of BIP32 path, for partial templates). The length of this list is referred to as the "length of the path". + +Non-hardened indexes in this list should be represented by values from 0 to 2147483647. + +Hardened indexes in this list should be represented by values from 2147483648 to 4294967295. + +The matching algorithm: + + 1. If the length of the path differs from the length of the template, fail + 2. For each value V at position N in the path: + If for all index ranges within the section at position N in the template, + value V is either less than range_start, or greater than range_end, fail + 3. Otherwise, succeed + +==Formal specification== + +The finite state machine (FSM) for the parser of the described template format, +and the matching formula are specified in TLA+ specification language at https://github.com/dgpv/bip32_template_parse_tplaplus_spec + +The specification can be used with TLC checker and accompanying script to generate test data for the implementations. + +==Implementations== + +While the formal specification specifies an FSM, which would be convenient for implementation without access to rich string handling facilities, when such facilities are available, the implementation might use the whole-string deconstruction approach where the templates are first split into sections, then sections are split into index templates, and then each index template are parsed individually. + +A FSM-based approach can be made close to the formal specification, though, and the test data generated with TLC checker would give much better coverage for a FSM based implementation. If the template string contains several errors, an implementation that uses deconstruction approach might detect some of these errors earlier than FSM-based implementation, and vise versa. + +At the moment, three implementations exist: + +* FSM implementation in C: https://github.com/dgpv/bip32_template_c_implementation +* FSM implementation in Python (micropython compatible): https://github.com/dgpv/bip32_template_python_implementation +* non-FSM implementation in python: BIP32PathTemplate class in bitcointx.core.key module of python-bitcointx library (https://github.com/Simplexum/python-bitcointx) + +==Compatibility== + +The full path template that only contains Unit index templates represents a fully valid BIP32 path. + +There's no other path template standards that is known to the author currently. + +There is a discussion on path templating for bitcoin script descriptors at https://github.com/bitcoin/bitcoin/issues/17190, which proposes the format <code>xpub...{0,1}/*</code>, of which the <code>{0,1}/*</code> part would correspond to the partial path template in the format of this BIP. + +==Examples== + +<code>m/{44,49,84}'/0'/0'/{0-1}/{0-50000}</code> specifies a full template that matches both external and internal chains of BIP44, BIP49 and BIP84 paths, with a constraint that the address index cannot be larger than 50000 + +Its representation after parsing can be (using Python syntax, ignoring full/partial distinction): + [[(2147483692, 2147483692), (2147483697, 2147483697), (2147483732, 2147483732)), + [(2147483648, 2147483648)], + [(2147483648, 2147483648)], + [(0, 1)], + [(0, 50000)]] + +<code>{0-2,33,123}/*</code> specifies a partial template that matches non-hardened values 0, 1, 2, 33, 123 as first index, and any non-hardened value at second index + +Its representation after parsing can be: + [[(0, 2), (33, 33), (123, 123)], [(0, 2147483647)]] + +<code>*h/0</code> specifies a partial template that matches any hardened index followed by any non-hardened index + +Its representation after parsing can be: + [[(2147483648, 4294967295)], [(0, 0)]] diff --git a/bip-0129.mediawiki b/bip-0129.mediawiki new file mode 100644 index 0000000..8719fe4 --- /dev/null +++ b/bip-0129.mediawiki @@ -0,0 +1,462 @@ +<pre> + BIP: 129 + Layer: Applications + Title: Bitcoin Secure Multisig Setup (BSMS) + Author: Hugo Nguyen <hugo@nunchuk.io> + Peter Gray <peter@coinkite.com> + Marko Bencun <marko@shiftcrypto.ch> + Aaron Chen <aarondongchen@gmail.com> + Rodolfo Novak <rodolfo@coinkite.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0129 + Status: Proposed + Type: Standards Track + Created: 2020-11-10 + License: BSD-2-Clause +</pre> + +==Introduction== + +===Abstract=== + +This document proposes a mechanism to set up multisig wallets securely. + +===Copyright=== + +This BIP is licensed under the 2-clause BSD license. + +===Motivation=== + +The Bitcoin multisig experience has been greatly streamlined under [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 +(Partially Signed Bitcoin Transaction)]. However, what is still missing is a standardized process for setting up multisig wallets securely across different vendors. + +There are a number of concerns when it comes to setting up a multisig wallet: + +# Whether the multisig configuration, such as Signer membership, script type, derivation paths and number of signatures required, is correct and not tampered with. +# Whether the keys or the multisig configuration are leaked during the setup. +# Whether the Signer persists the multisig configuration in their respective storage, and under what format. +# Whether the Signer's storage is tamper-proof. +# Whether the Signer subsequently uses the multisig configuration to generate and verify receive and change addresses. + +An attacker who can modify the multisig configuration can steal or hold funds for ransom by duping the user into sending funds to the wrong address. An attacker who cannot modify the configuration but can learn about the keys and/or the configuration can monitor transactions in the wallet, resulting in loss of privacy. + +This proposal seeks to address concerns #1, #2 and #3: to mitigate the risk of tampering during the initial setup phase, and to define an interoperable multisig configuration format. + +Concerns #4 and #5 should be handled by Signers and are out of scope of this proposal. + +==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]. + +===File Extensions=== +All descriptor and key records should have a <tt>.bsms</tt> file extension. Encrypted data should have a <tt>.dat</tt> extension. + +===Roles=== +====Coordinator==== + +The Coordinator initiates the multisig setup. The Coordinator determines what type of multisig is used and the exact policy script. If encryption is enabled, the Coordinator also distributes a shared secret or shared secrets to the parties involved for secure communication. The Coordinator gathers information from the Signers to generate a descriptor record. The Coordinator distributes the descriptor record back to the Signers. + +====Signer==== + +The Signer is any software or hardware that controls the private keys and can sign using those keys. The Signer is a participating member in the multisig. Its responsibilities include providing its key record -- which contains a public key or an Extended Public Key (XPUB) -- to the Coordinator, verifying that its <tt>KEY</tt> is included in the descriptor record and persisting the descriptor record in its storage. + +===Setup Process=== + +====Round 1==== + +=====Coordinator===== + +* The Coordinator creates a new multisig wallet creation session. The Coordinator constructs the multisig script and its policy parameters, such as the required number of signatures and the total number of Signers (<tt>M</tt> and <tt>N</tt>). +* The session should expire after some time period determined by the Coordinator, e.g., 24 hours. The timeout allows the encryption key to have lower entropy. +* If encryption is enabled, the Coordinator distributes a secret <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the [[#Encryption]] section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer. +* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0x00</tt>, and all the encryption/decryption steps below can be skipped. + +=====Signer===== + +* The Signer initiates the multisig wallet creation session by setting the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> is set. +* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the <tt>KEY</tt> at that derivation path. Alternatively, the Signer can choose a path on behalf of the user. If the Signer chooses the path, it should try to avoid reusing <tt>KEY</tt>s for different wallets. +* The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{KEY}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by using the private key associated with the public key or XPUB to sign the first four lines. The signature should follow [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], legacy format accepted. +* The Signer calculates the Message Authentication Code (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption. +* The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>. +* The Signer encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>. + +====Round 2==== + +=====Coordinator===== + +* The Coordinator gathers key records from all participating Signers. The Coordinator verifies that there are exactly <tt>N</tt> unique key records before the wallet setup session expires. +* For each key record, the Coordinator extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>. +* The Coordinator verifies that the included <tt>MAC</tt> is valid given the plaintext. +* The Coordinator verifies that the key records have compatible specification versions. +* The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>. +* If all key records look good, the Coordinator fills in all necessary information to generate a descriptor record. +* The first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be a descriptor or a descriptor template. The third line must be a comma-separated list of derivation path restrictions. The paths must start with <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. The fourth line must be the wallet's first address. If there are path restrictions, use the first address from the first path restriction. +* The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. +* The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>. +* The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>. +* The Coordinator sends the encrypted descriptor record to all participating Signers. + +=====Signer===== + +* The Signer imports the descriptor record. +* The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>. +* The Signer verifies that the included <tt>MAC</tt> is valid given the plaintext. +* The Signer verifies that it can support the included specification version. +* The Signer verifies that it can support the descriptor or descriptor template. +* The Signer checks that its <tt>KEY</tt> is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>s and not using shortcuts such as matching fingerprints, which is trivial to spoof. +* The Signer verifies that it is compatible with the derivation path restrictions. +* The Signer verifies that the wallet's first address is valid. +* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor or descriptor template must also be available for review upon user request. +* Parties must check with each other that all Signers have the same confirmation (except for the <tt>KEY</tt> positions). +* If all checks pass, the Signer must persist the descriptor record in its storage. + +This completes the setup. + +===Encryption=== + +====The Token==== +We define three modes of encryption. + +# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0x00</tt>. Encryption is disabled. +# <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce. +# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce. + +The <tt>TOKEN</tt> can be converted to one of these formats: +* A decimal number (recommended). The number must not exceed the maximum value of the nonce. +* A mnemonic phrase using [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list. This would be 6 words in <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> mnemonics. +* A QR code. +* Other formats. + +The flexibility in the data format allows each Signer to customize the User Experience based on its respective capabilities. + +====Key Derivation==== +The key derivation function is [https://tools.ietf.org/html/rfc2898 PBKDF2], with PRF = SHA512. Specifically: + +<tt>DKey = PBKDF2(PRF, Password, Salt, c, dkLen)</tt> + +Whereas: + +* PRF = SHA512 +* Password = "No SPOF" +* Salt = <tt>TOKEN</tt> +* c = 2048 +* dkLen = 256 +* DKey = Derived <tt>ENCRYPTION_KEY</tt> + +====Encryption Scheme==== +The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES-256-CTR]. + +<tt>MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)</tt> + +<tt>IV = First 16 bytes of MAC</tt> + +<tt>Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)</tt> + +<tt>Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)</tt> + +Whereas: +* DKey = <tt>ENCRYPTION_KEY</tt> +* HMAC_Key = SHA256(<tt>ENCRYPTION_KEY</tt>) +* Data = the plaintext, e.g. the entire key record in round 1 and the entire descriptor record in round 2 + +The <tt>MAC</tt> is to be sent along with the key and descriptor record, as specified above. Because it is a <tt>MAC</tt> over the entire plaintext, this is essentially an [https://en.wikipedia.org/wiki/Authenticated_encryption#Encrypt-and-MAC_(E&M) Encrypt-and-MAC] form of authenticated encryption. + +===Descriptor Template=== +The output descriptor language only supports one-dimensional lists. This proposal introduces a descriptor template to represent multi-dimensional lists: + +<tt>XPUB/**</tt> + +Whereas <tt>/**</tt> can be replaced by any number of derivation path restrictions. + +A descriptor template must be accompanied by derivation path restrictions. Signers should expand the template into concrete descriptors by replacing <tt>/**</tt> with the restrictions. + +For example, the following template and derivation path restrictions: +* <tt>wsh(sortedmulti(2,XPUB1/**,XPUB2/**))</tt> +* <tt>/0/*,/1/*</tt> + +Should translate to two concrete descriptors: +* <tt>wsh(sortedmulti(2,XPUB1/0/*,XPUB2/0/*))</tt> +* <tt>wsh(sortedmulti(2,XPUB1/1/*,XPUB2/1/*))</tt> + +==QR Codes== +For signers that use QR codes to transmit data, key and descriptor records can be converted to QR codes, following [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md the BCR standard]. + +Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md UR Type Definition for BIP44 Accounts] and [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md UR Type Definition for Bitcoin Output Descriptors] for more details. + +==Compatibility== +This specification is not backwards compatible with existing multisig implementations. + +BSMS is opt-in, meaning existing multisig implementations can continue working as-is, with the caveat that they are likely to have various pitfalls. Some of the problems with existing solutions have been described in the [[#Motivation]] section. + +To comply with this standard, a Signer must be able to persist the descriptor record in its storage. + +To use BSMS for a multisig wallet, the user should wait until all participating Signers in the multisig have implemented BSMS. + +==Security== + +This proposal introduces two layers of protection. The first one is a temporary, secret <tt>TOKEN</tt>. The second one is the confirmation of the wallet's first address. + +The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards. It is not recommended to use the same <tt>TOKEN</tt> for multiple wallet creation sessions. + +The wallet's first address, on the other hand, can be used to verify the integrity of the multisig configuration. An attacker who tampers with the multisig configuration must also change the wallet's first address. Parties must check with each other that all Signers confirm to the same address and policy parameters to reduce the chance of tampering. + +==Privacy== +Encryption helps improve the privacy of the wallet by avoiding sharing keys and descriptors in plaintext. + +If the parties wish to have stronger privacy, it is recommended to use a higher number of bits for the <tt>TOKEN</tt>, and to completely erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has been set up. + +==Test Vectors== + +===Mode: <tt>NO_ENCRYPTION</tt> with Public Keys=== +====ROUND 1==== +* Coordinator +** M-of-N: 1/2 +** ADDRESS_TYPE: NATIVE_SEGWIT +** TOKEN: 0x00 + +* Signer 1 +** MASTER_KEY_FINGERPRINT: 59865f44 +** PRIVATE_KEY (m/48'/0'/0'/2'): L5TXU4SdD9e6QGgBjxeegJKxt4FgATLG1TCnFM8JLyEkFuyHEqNM +** Public Key (m/48'/0'/0'/2'): 026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba +** Legacy signature +** <tt>signer_1_key.bsms</tt>: +<pre>BSMS 1.0 +00 +[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba +Signer 1 key +H6DXgqkCb353BDPkzppMFpOcdJZlpur0WRetQhIBqSn6DFzoQWBtm+ibP5wERDRNi0bxxev9B+FIvyQWq0s6im4=</pre> + +* Signer 2 +** MASTER_KEY_FINGERPRINT: b7044ca6 +** PRIVATE_KEY (m/48'/0'/0'/2'): KwT7BZDWjos4JAdfKi8NqF46Kj3rppTwN8KGhPbzmmugiZioFW3r +** Public Key (m/48'/0'/0'/2'): 030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062 +** Legacy signature +** <tt>signer_2_key.bsms</tt>: +<pre>BSMS 1.0 +00 +[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062 +Signer 2 key +H08mGNGN+NxX/snt+6eX2Q1HjjfDkOtotglshHi7xdsBdIrTVMCQbgQ5SdACNZ0B2AJcifK11nJj43SvaitSemI=</pre> + +====ROUND 2==== +* Coordinator +** <tt>my_multisig_wallet.bsms</tt>: +<pre>BSMS 1.0 +wsh(sortedmulti(1,[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba,[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062))#rzx9dffd +No path restrictions +bc1quqy523xu3l8che3s8vja8n33qtg0uyugr9l5z092s3wa50p8t7rqy6zumf</pre> + +===Mode: <tt>NO_ENCRYPTION</tt>=== +====ROUND 1==== +* Coordinator +** M-of-N: 2/2 +** ADDRESS_TYPE: NATIVE_SEGWIT +** TOKEN: 0x00 + +* Signer 1 +** MASTER_KEY_FINGERPRINT: 1cf0bf7e +** PRIVATE_KEY (m/48'/0'/0'/2'): L3q1sg7iso1L3QfzB1riC9bQpqMynWyBeuLLSKwCDGkHkahB7MgU +** XPUB (m/48'/0'/0'/2'): xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz +** Legacy signature +** <tt>signer_1_key.bsms</tt>: +<pre>BSMS 1.0 +00 +[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz +Signer 1 key +IB7v+qi1b+Xrwm/3bF+Rjl8QbIJ/FMQ40kUsOOQo1SqUWn5QlFWbBD8BKPRetfo1L1N7DmYjVscZNsmMrqRJGWw=</pre> + +* Signer 2 +** MASTER_KEY_FINGERPRINT: 4fc1dd4a +** PRIVATE_KEY (m/48'/0'/0'/2'): L4JNkJfLBDyWfTLbKJ1H3w56GUMsvdfjCkzRo5RHXfJ6bdHqm6cN +** XPUB (m/48'/0'/0'/2'): xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj +** Legacy signature +** <tt>signer_2_key.bsms</tt>: +<pre>BSMS 1.0 +00 +[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj +Signer 2 key +HzUa4Z76PFHMl54flIIF3XKiHZ+KbWjjxCEG5G3ZqZSqTd6OgTiFFLqq9PXJXdfYm6/cnL8IVWQgjFF9DQhIqQs=</pre> + +====ROUND 2==== +* Coordinator +** <tt>my_multisig_wallet.bsms</tt>: +<pre>BSMS 1.0 +wsh(sortedmulti(2,[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz/**,[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj/**)) +/0/*,/1/* +bc1qrgc6p3kylfztu06ysl752gwwuekhvtfh9vr7zg43jvu60mutamcsv948ej</pre> + +===Mode: <tt>STANDARD</tt> Encryption=== +====ROUND 1==== +* Coordinator +** M-of-N: 2/2 +** ADDRESS_TYPE: NATIVE_SEGWIT +** TOKEN (hex): a54044308ceac9b7 +*** TOKEN (decimal): 11907592390080907703 +*** TOKEN (mnemonic): pipe acquire around border prosper swift +** ENCRYPTION_KEY (hex): 7673ffd9efd70336a5442eda0b31457f7b6cdf7b42fe17f274434df55efa9839 + +* Signer 1 +** MASTER_KEY_FINGERPRINT: b7868815 +** PRIVATE_KEY (m/48'/0'/0'/2'): KyKvR9kf8r7ZVtdn3kB9ifipr6UKnTNTpWJkGZbHwARDCz5iZ39E +** XPUB (m/48'/0'/0'/2'): xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh +** Legacy signature +** <tt>signer_1_key.bsms</tt>: +<pre>BSMS 1.0 +a54044308ceac9b7 +[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh +Signer 1 key +H8DYht5P6ko0bQqDV6MtUxpzBSK+aVHxbvMavA5byvLrOlCEGmO1WFR7k2wu42J6dxXD8vrmDQSnGq5MTMMbZ98=</pre> + +* Signer 1 encryption +** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2 +** MAC (hex): fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc82706 +** IV (hex) : fbdbdb64e6a8231c342131d9f13dcd5a +** CIPHERTEXT (hex): 53f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816 +** <tt>signer_1_key.dat</tt>: <pre>fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc8270653f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816</pre> + +* Signer 2 +** MASTER_KEY_FINGERPRINT: eedff89a +** PRIVATE_KEY (m/48'/0'/0'/2'): Kz1ijnkDXmc65NWTYdg47DDaQgSGJAPfhJG9Unm36oqZPpPXuNR6 +** XPUB (m/48'/0'/0'/2'): xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o +** Legacy signature +** <tt>signer_2_key.bsms</tt>: +<pre>BSMS 1.0 +a54044308ceac9b7 +[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o +Signer 2 key +H/IHW5dMGYsrRdYEz3ux+kKnkWBtxHzfYkREpnYbco38VnMvIxCbDuf7iu6960qDhBLR/RLjlb9UPtLmCMbczDE=</pre> + +* Signer 2 encryption +** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2 +** MAC (hex): 383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae +** IV (hex) : 383d05b7351a2cef7cca2850450f5efb +** CIPHERTEXT (hex): 71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23 +** <tt>signer_2_key.dat</tt>: <pre>383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23</pre> + +====ROUND 2==== +*Coordinator +** <tt>my_multisig_wallet.bsms</tt>: +<pre>BSMS 1.0 +wsh(sortedmulti(2,[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh/**,[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o/**)) +/0/*,/1/* +bc1qhs4u273g4azq7kqqpe6vh5wfhasfmrq7nheyzsnq77humd7rwtkqagvakf</pre> + +*Coordinator encryption +** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2 +** MAC (hex): 734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a +** IV (hex) : 734ce791b466861945e1ef6f74c63fae +** CIPHERTEXT (hex): 273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc +** <tt>my_multisig_wallet.dat</tt>: <pre>734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc</pre> + +===Mode: <tt>EXTENDED</tt> Encryption=== +====ROUND 1==== +*Coordinator +** M-of-N: 2/3 +** ADDRESS_TYPE: NESTED_SEGWIT +** TOKEN for Signer 1 (hex): 108a2360adb302774eb521daebbeda5e +*** TOKEN (decimal): 21984902443033505423410071144203475550 +*** ENCRYPTION_KEY (hex): 63dc1e57dfdc21fa11109d5088be01fb8078a383d2296925ad2b7612b7179777 +** TOKEN for Signer 2 (hex): d3fabc873b98165254fe18a71b5335b0 +*** TOKEN (decimal): 281769005132501859744421970528095647152 +*** ENCRYPTION_KEY (hex): 3dc860a53471ec03af14617fef60921cf215b45a9d684462fa65b9d804ad3ee7 +** TOKEN for Signer 3 (hex): 78a7d5e7549453d719150de5459c9ce5 +*** TOKEN (decimal): 160378811550692397333855096016467696869 +*** ENCRYPTION_KEY (hex): 62b90b4c08c03a0ee872e57aae73f9acfafb6cc09d20b5c9bc0bafaef33619db + +* Signer 1 +** MASTER_KEY_FINGERPRINT: 793cc70b +** PRIVATE_KEY (m/48'/0'/0'/1'): L1ZEgZ4zNYxyNc8UyeqwyKW1UHVMp9sxwPgSi3s9SW8mc7KsiSwJ +** XPUB (m/48'/0'/0'/1'): xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj +** Legacy signature +** <tt>signer_1_key.bsms</tt>: +<pre>BSMS 1.0 +108a2360adb302774eb521daebbeda5e +[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj +Signer 1 key +ILG47LpCtjoD9UxL87jo5QFqA90t8g9fDQp/KBojdKgPPGB1pMx2bf9hPdORNZIOdCc/2+Gs6AOs3BEK9ubIuBw=</pre> + +* Signer 1 encryption +** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd +** MAC (hex): ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1 +** IV (hex) : ea12776c73de4bd5ea57c2d19eb8e0be +** CIPHERTEXT (hex): a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab +** <tt>signer_1_key.dat</tt>: <pre>ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab</pre> + +* Signer 2 +** MASTER_KEY_FINGERPRINT: b3118e52 +** PRIVATE_KEY (m/48'/0'/0'/1'): L4SnPjcHszMg3Wi2YYxEYnzM2zFeFkFr5NcLZ18YQeyJwaSFbTud +** XPUB (m/48'/0'/0'/1'): xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch +** Legacy signature +** <tt>signer_2_key.bsms</tt>: +<pre>BSMS 1.0 +d3fabc873b98165254fe18a71b5335b0 +[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch +Signer 2 key +IDK4d/oO0pgfrwRu4Zb8vqlPEmJb9aKT1K2CCnI3RKepVAKs3fZsBrypcCdQfUy1TG/3O5vAR3gjldxcCA1Wzg8=</pre> + +* Signer 2 encryption +** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57 +** MAC (hex): 4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718 +** IV (hex) : 4a3ff970d027010e83b4fbf2845a2390 +** CIPHERTEXT (hex): c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a +** <tt>signer_2_key.dat</tt>: <pre>4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a</pre> + +* Signer 3 +** MASTER_KEY_FINGERPRINT: 842bd2ed +** PRIVATE_KEY (m/48'/0'/0'/1'): L1ehZHpo2UFHc1yaBWDU4bKVycUwcU2TESm92wbfq6xK6qpZZJP6 +** XPUB (m/48'/0'/0'/1'): xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic +** Legacy signature +** <tt>signer_3_key.bsms</tt>: +<pre>BSMS 1.0 +78a7d5e7549453d719150de5459c9ce5 +[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic +Signer 3 key +IL77mML0xo/O9dJn0T5EpQLuyRPPrdpgVJbtsdAugW5iX0MQ3Ci0f8jVnXu68Xm07CYjYGKX8af72jmkQKhNud0=</pre> + +* Signer 3 encryption +** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26 +** MAC (hex): e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8 +** IV (hex) : e82cfcccbd4bd4d3b76e28133eecd13f +** CIPHERTEXT (hex): b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4 +** <tt>signer_3_key.dat</tt>: <pre>e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4</pre> + +====ROUND 2==== +* Coordinator +** <tt>my_multisig_wallet.bsms</tt>: +<pre>BSMS 1.0 +sh(wsh(multi(2,[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj/**,[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch/**,[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic/**))) +/0/*,/1/* +3GzMtFXahiu4TpGNGFc4bHMvAcvz5vVQrT</pre> + +* Send to Signer 1: +** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd +** MAC (hex): 01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025 +** IV (hex) : 01bf557b6d44b3fbf07f8ec155cbdec4 +** CIPHERTEXT (hex): 617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677 +** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677</pre> + +* Send to Signer 2: +** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57 +** MAC (hex): 974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b343092 +** IV (hex) : 974ba77900c43c463dadaa6eaf24aaeb +** CIPHERTEXT (hex): 86288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1 +** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b34309286288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1</pre> + +* Send to Signer 3: +** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26 +** MAC (hex): bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae +** IV (hex) : bb3c93b67d758f244de7ee73e5e61261 +** CIPHERTEXT (hex): 7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e +** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e</pre> + +==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. + +==References== + +Related mailing list threads: +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018732.html + diff --git a/bip-0343.mediawiki b/bip-0343.mediawiki new file mode 100644 index 0000000..3d2f392 --- /dev/null +++ b/bip-0343.mediawiki @@ -0,0 +1,62 @@ +<pre> + BIP: 343 + Layer: Consensus (soft fork) + Title: Mandatory activation of taproot deployment + Author: Shinobius <quantumedusa@gmail.com> + Michael Folkson <michaelfolkson@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0343 + Status: Proposed + Type: Standards Track + Created: 2021-04-25 + License: BSD-3-Clause + CC0-1.0 +</pre> + +==Abstract== + +This document specifies a BIP8 (LOT=true) deployment to activate taproot. + +==Motivation== + +The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus. + +==Specification== + +This BIP will begin an activation signaling period using bit 2 at blockheight 681408 with a minimum activation height of 709632 and an activation threshold of 90%. The signaling period will timeout at blockheight 760032 with a latest activation height of 762048. Lockinontimeout (LOT) is set to true so mandatory signaling will be enforced in the last signaling period before the timeout height. Blocks without the signaling bit 2 set run the risk of being rejected during this period if taproot is not locked in prior. This BIP will cease to be active when taproot is locked in. + +==Reference implementation== + +*[[https://github.com/BitcoinActivation/bitcoin]] + +==Backward Compatibility== + +As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts. They are strongly encouraged to upgrade in order to fully validate the new programs. + +==Compatibility with later alternative activations== + +The activation mechanism “Speedy Trial” as proposed by Russell O’Connor and outlined in this bitcoin-dev mailing list [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html post] by David Harding was released in Bitcoin Core. It is effectively a BIP8 activation mechanism with one exception: start height and timeout height were defined using median time past (MTP) rather than block heights. It uses signaling bit 2, was deployed between midnight April 24th 2021 and midnight August 11th 2021, has a minimum activation height of 709632 and intends to activate BIPs 340, 341, and 342. The BIP8(LOT=true) deployment is compatible with the “Speedy Trial” deployment in Bitcoin Core as there was not a discrepancy between MTP and block height for the defined start heights. + +The BIP8 (LOT=true) deployment has also been deliberately designed to be compatible with a future BIP8(LOT=false) or BIP8(LOT=true) deployment in Bitcoin Core assuming Bitcoin Core releases one of these activation mechanisms in the event of the Speedy Trial deployment failing to activate. + +==Rationale== + +The deployment of BIP148 demonstrated that multiple implementations with different activation mechanisms can incentivize the necessary actors to act so that the different deployments activate in sync. A BIP8 LOT=true deployment can run in parallel with other BIP8 activation mechanisms that have eventual mandatory signaling or no mandatory signaling. Eventual mandatory signaling ensures that miners cannot prevent the activation of a desired feature with community consensus indefinitely. + +==Acknowledgements== + +Thanks to Shaolin Fry and Luke Dashjr for their work on BIP148 and BIP8 which were important prerequisites for this proposal. + +==References== + +*[[bip-0008.mediawiki|BIP8 Version bits with lock-in by height]] +*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]] +*[[bip-0340.mediawiki|BIP340 Schnorr Signatures for secp256k1]] +*[[bip-0341.mediawiki|BIP341 Taproot: SegWit version 1 spending rules]] +*[[bip-0342.mediawiki|BIP342 Validation of Taproot Scripts]] +*[https://taproot.works/taproot-faq/ Taproot benefits] + +==Copyright== + +This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. + |