diff options
| -rw-r--r-- | README.mediawiki | 35 | ||||
| -rw-r--r-- | bip-0002.mediawiki | 23 | ||||
| -rw-r--r-- | bip-0008.mediawiki | 21 | ||||
| -rw-r--r-- | bip-0008/states.dot | 3 | ||||
| -rw-r--r-- | bip-0008/states.png | bin | 46310 -> 60743 bytes | |||
| -rw-r--r-- | bip-0008/states.svg | 82 | ||||
| -rw-r--r-- | bip-0009.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0039.mediawiki | 3 | ||||
| -rw-r--r-- | bip-0085.mediawiki | 34 | ||||
| -rw-r--r-- | bip-0087.mediawiki | 274 | ||||
| -rw-r--r-- | bip-0088.mediawiki | 229 | ||||
| -rw-r--r-- | bip-0118.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0129.mediawiki | 462 | ||||
| -rw-r--r-- | bip-0136.mediawiki | 898 | ||||
| -rw-r--r-- | bip-0174.mediawiki | 231 | ||||
| -rw-r--r-- | bip-0325.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0340.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0340/speedup-batch.png | bin | 11914 -> 0 bytes | |||
| -rw-r--r-- | bip-0341.mediawiki | 42 | ||||
| -rw-r--r-- | bip-0342.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0343.mediawiki | 62 | ||||
| -rw-r--r-- | bip-0370.mediawiki | 305 |
22 files changed, 2403 insertions, 323 deletions
diff --git a/README.mediawiki b/README.mediawiki index 106c455..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 @@ -994,6 +1022,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Pieter Wuille | Standard | Draft +|- +| [[bip-0370.mediawiki|370]] +| Applications +| PSBT Version 2 +| Andrew Chow +| Standard +| Draft |} <!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --> diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki index 3bf5aec..c6eb950 100644 --- a/bip-0002.mediawiki +++ b/bip-0002.mediawiki @@ -41,14 +41,14 @@ It also helps to make sure the idea is applicable to the entire community and no 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]. 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 the editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers). +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). BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here. It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones. -When the BIP draft is complete, the BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository. -The BIP editor will not unreasonably reject a BIP. +When the BIP draft is complete, a BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository. +The BIP editors will not unreasonably reject a BIP. Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. @@ -61,16 +61,19 @@ The BIP author may update the draft as necessary in the git repository. Updates It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP. -If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :). +If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editors. If the original author doesn't respond to email in a timely manner, the BIP editors will make a unilateral decision (it's not like such decisions can't be reversed :). ===BIP Editors=== -The current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]]. +The current BIP editors are: + +* Luke Dashjr ([[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]]) +* Kalle Alm ([[mailto:karljohan-alm@garage.co.jp|karljohan-alm@garage.co.jp]]) ===BIP Editor Responsibilities & Workflow=== -The BIP editor subscribes to the Bitcoin development mailing list. -Off-list BIP-related correspondence should be sent (or CC'd) to luke_bipeditor@dashjr.org. +The BIP editors subscribe to the Bitcoin development mailing list. +Off-list BIP-related correspondence should be sent (or CC'd) to the BIP editors. For each new BIP that comes in an editor does the following: @@ -186,13 +189,13 @@ The typical paths of the status of BIPs are as follows: <img src="bip-0002/process.png"></img> Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. -The BIP editor may also change the status to Deferred when no progress is being made on the BIP. +A BIP editor may also change the status to Deferred when no progress is being made on the BIP. A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status. BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph. -An Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list. +A Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list. When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed. @@ -326,7 +329,7 @@ For example, a preamble might include the following License header: In this case, the BIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement. -It is also possible to license source code differently from the BIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below. +It is also possible to license source code differently from the BIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below. For example, a preamble specifying the optional License-Code header might look like: diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 7b61eaa..d357401 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -39,6 +39,7 @@ Each soft fork deployment is specified by the following per-chain parameters (fu # The '''startheight''' specifies the height of the first block at which the bit gains its meaning. # The '''timeoutheight''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is considered failed on all descendants of the block. # The '''threshold''' specifies the minimum number of block per retarget period which indicate lock-in of the soft fork during the subsequent period. +# The '''minimum_activation_height''' specifies the height of the first block at which the soft fork is allowed to become active. # The '''lockinontimeout''' boolean if set to true, blocks are required to signal in the final period, ensuring the soft fork has locked in by timeoutheight. ===Selection guidelines=== @@ -47,15 +48,16 @@ The following guidelines are suggested for selecting these parameters for a soft # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number. # '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes. -# '''startheight''' should be set to some block height in the future when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. It should be rounded up to the next height which begins a retarget period for simplicity. +# '''startheight''' should be set to some block height in the future. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after software with parameters is expected to be released. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state. # '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''. # '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet. +# '''minimum_activation_height''' should be set to several retarget periods in the future if the '''startheight''' is to be very soon after software with parameters is expected to be released. '''minimum_activation_height''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. This allows more time to be spent in the LOCKED_IN state so that nodes can upgrade. This may be set to 0 to have the LOCKED_IN state be a single retarget period. # '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.) A later deployment using the same bit is possible as long as the startheight is after the previous one's timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software. -'''startheight''' and '''timeoutheight''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4096 blocks (2 retarget intervals) after '''startheight'''. +'''startheight''', '''timeoutheight''', and '''minimum_activation_height''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4032 blocks (2 retarget intervals) after '''startheight'''. ===States=== @@ -64,8 +66,8 @@ With each block and soft fork, we associate a deployment state. The possible sta # '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment. # '''STARTED''' for blocks at or beyond the startheight. # '''MUST_SIGNAL''' for one retarget period prior to the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is true. -# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED (or MUST_SIGNAL) blocks of which at least threshold have the associated bit set in nVersion. -# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period. +# '''LOCKED_IN''' for at least one retarget period after the first retarget period with STARTED (or MUST_SIGNAL) blocks of which at least threshold have the associated bit set in nVersion. A soft fork remains in LOCKED_IN until at least '''minimum_activation_height''' is reached. +# '''ACTIVE''' for all blocks after the LOCKED_IN state. # '''FAILED''' for all blocks after the timeoutheight if LOCKED_IN is not reached. ===Bit flags=== @@ -93,7 +95,8 @@ During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget <img src="bip-0008/states.png" align="middle"></img> -Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight''', and ACTIVE will be reached no later than at a height of '''timeoutheight + 2016'''. +Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight'''. +Regardless of the value of '''lockinontimeout''', if LOCKED_IN is reached, ACTIVE will be reached either one retarget period later, or at '''minimum_activation_height''', whichever comes later. The genesis block has state DEFINED for each deployment, by definition. @@ -153,10 +156,14 @@ If we have finished a period of MUST_SIGNAL, we transition directly to LOCKED_IN case MUST_SIGNAL: return LOCKED_IN; -After a retarget period of LOCKED_IN, we automatically transition to ACTIVE. +After at least one retarget period of LOCKED_IN, we automatically transition to ACTIVE if the minimum activation height is reached. Otherwise LOCKED_IN continues. case LOCKED_IN: - return ACTIVE; + if (block.height >= minimum_activation_height) { + return ACTIVE; + } else { + return LOCKED_IN; + } And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached. diff --git a/bip-0008/states.dot b/bip-0008/states.dot index aa919ff..8615978 100644 --- a/bip-0008/states.dot +++ b/bip-0008/states.dot @@ -7,7 +7,8 @@ digraph { "DEFINED" -> "STARTED" [label="height >= start_height"]; "STARTED" -> "MUST_SIGNAL" [label="height + 2016 >= timeoutheight AND lockinontimeout"]; "STARTED" -> "FAILED" [label="height >= timeoutheight\nAND\nNOT lockinontimeout"]; - "LOCKED_IN" -> "ACTIVE" [label="always"]; + "LOCKED_IN" -> "ACTIVE" [label="height >= minimum_activation_height"]; + "LOCKED_IN":se -> "LOCKED_IN":ne [label="height < minimum_activation_height"]; "MUST_SIGNAL" -> "LOCKED_IN" [label="always"]; edge [weight = 1]; diff --git a/bip-0008/states.png b/bip-0008/states.png Binary files differindex 6477ed3..f15efdb 100644 --- a/bip-0008/states.png +++ b/bip-0008/states.png diff --git a/bip-0008/states.svg b/bip-0008/states.svg index 3503c34..63fe634 100644 --- a/bip-0008/states.svg +++ b/bip-0008/states.svg @@ -1,14 +1,13 @@ <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> -<!-- Generated by graphviz version 2.42.3 (20191010.1750) +<!-- Generated by graphviz version 2.46.1 (0) --> -<!-- Title: %3 Pages: 1 --> -<svg width="563pt" height="348pt" - viewBox="0.00 0.00 563.00 348.37" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> +<!-- Pages: 1 --> +<svg width="937pt" height="348pt" + viewBox="0.00 0.00 937.00 348.37" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 344.37)"> -<title>%3</title> -<polygon fill="white" stroke="transparent" points="-4,4 -4,-344.37 559,-344.37 559,4 -4,4"/> +<polygon fill="white" stroke="transparent" points="-4,4 -4,-344.37 933,-344.37 933,4 -4,4"/> <!-- DEFINED --> <g id="node1" class="node"> <title>DEFINED</title> @@ -16,7 +15,7 @@ <text text-anchor="middle" x="72" y="-312.05" font-family="Arial" font-size="14.00">DEFINED</text> </g> <!-- DEFINED->DEFINED --> -<g id="edge8" class="edge"> +<g id="edge9" class="edge"> <title>DEFINED:sw->DEFINED:nw</title> <path fill="none" stroke="black" d="M18,-297.75C12,-287.25 0,-287.25 0,-315.75 0,-334.01 4.92,-340.57 10.04,-340.17"/> <polygon fill="black" stroke="black" points="12.41,-342.75 18,-333.75 8.02,-337.3 12.41,-342.75"/> @@ -32,10 +31,10 @@ <title>DEFINED->STARTED</title> <path fill="none" stroke="black" d="M72,-297.55C72,-285.91 72,-270.3 72,-256.99"/> <polygon fill="black" stroke="black" points="75.5,-256.93 72,-246.93 68.5,-256.93 75.5,-256.93"/> -<text text-anchor="middle" x="133" y="-268.55" font-family="Times,serif" font-size="14.00">height >= start_height</text> +<text text-anchor="middle" x="155" y="-268.55" font-family="Times,serif" font-size="14.00">height >= start_height</text> </g> <!-- STARTED->STARTED --> -<g id="edge9" class="edge"> +<g id="edge10" class="edge"> <title>STARTED:sw->STARTED:nw</title> <path fill="none" stroke="black" d="M18,-210.75C12,-200.25 0,-200.25 0,-228.75 0,-247.01 4.92,-253.57 10.04,-253.17"/> <polygon fill="black" stroke="black" points="12.41,-255.75 18,-246.75 8.02,-250.3 12.41,-255.75"/> @@ -43,15 +42,15 @@ <!-- MUST_SIGNAL --> <g id="node3" class="node"> <title>MUST_SIGNAL</title> -<path fill="#a0a0ff" stroke="black" stroke-width="2" d="M543,-246.75C543,-246.75 459,-246.75 459,-246.75 453,-246.75 447,-240.75 447,-234.75 447,-234.75 447,-222.75 447,-222.75 447,-216.75 453,-210.75 459,-210.75 459,-210.75 543,-210.75 543,-210.75 549,-210.75 555,-216.75 555,-222.75 555,-222.75 555,-234.75 555,-234.75 555,-240.75 549,-246.75 543,-246.75"/> -<text text-anchor="middle" x="501" y="-225.05" font-family="Arial" font-size="14.00">MUST_SIGNAL</text> +<path fill="#a0a0ff" stroke="black" stroke-width="2" d="M634,-246.75C634,-246.75 550,-246.75 550,-246.75 544,-246.75 538,-240.75 538,-234.75 538,-234.75 538,-222.75 538,-222.75 538,-216.75 544,-210.75 550,-210.75 550,-210.75 634,-210.75 634,-210.75 640,-210.75 646,-216.75 646,-222.75 646,-222.75 646,-234.75 646,-234.75 646,-240.75 640,-246.75 634,-246.75"/> +<text text-anchor="middle" x="592" y="-225.05" font-family="Arial" font-size="14.00">MUST_SIGNAL</text> </g> <!-- STARTED->MUST_SIGNAL --> <g id="edge2" class="edge"> <title>STARTED->MUST_SIGNAL</title> -<path fill="none" stroke="black" d="M126.33,-228.75C205.44,-228.75 352.08,-228.75 436.54,-228.75"/> -<polygon fill="black" stroke="black" points="436.77,-232.25 446.77,-228.75 436.77,-225.25 436.77,-232.25"/> -<text text-anchor="middle" x="286.5" y="-235.55" font-family="Times,serif" font-size="14.00">height + 2016 >= timeoutheight AND lockinontimeout</text> +<path fill="none" stroke="black" d="M126.18,-228.75C222.75,-228.75 424.19,-228.75 527.64,-228.75"/> +<polygon fill="black" stroke="black" points="527.94,-232.25 537.94,-228.75 527.94,-225.25 527.94,-232.25"/> +<text text-anchor="middle" x="332" y="-235.55" font-family="Times,serif" font-size="14.00">height + 2016 >= timeoutheight AND lockinontimeout</text> </g> <!-- FAILED --> <g id="node4" class="node"> @@ -64,57 +63,64 @@ <title>STARTED->FAILED</title> <path fill="none" stroke="black" d="M72,-210.28C72,-191.69 72,-161.99 72,-140.25"/> <polygon fill="black" stroke="black" points="75.5,-140 72,-130 68.5,-140 75.5,-140"/> -<text text-anchor="middle" x="139" y="-181.55" font-family="Times,serif" font-size="14.00">height >= timeoutheight</text> -<text text-anchor="middle" x="139" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text> -<text text-anchor="middle" x="139" y="-151.55" font-family="Times,serif" font-size="14.00">NOT lockinontimeout</text> +<text text-anchor="middle" x="162.5" y="-181.55" font-family="Times,serif" font-size="14.00">height >= timeoutheight</text> +<text text-anchor="middle" x="162.5" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text> +<text text-anchor="middle" x="162.5" y="-151.55" font-family="Times,serif" font-size="14.00">NOT lockinontimeout</text> </g> <!-- LOCKED_IN --> <g id="node5" class="node"> <title>LOCKED_IN</title> -<path fill="#ffffa0" stroke="black" stroke-width="2" d="M543,-129.75C543,-129.75 459,-129.75 459,-129.75 453,-129.75 447,-123.75 447,-117.75 447,-117.75 447,-105.75 447,-105.75 447,-99.75 453,-93.75 459,-93.75 459,-93.75 543,-93.75 543,-93.75 549,-93.75 555,-99.75 555,-105.75 555,-105.75 555,-117.75 555,-117.75 555,-123.75 549,-129.75 543,-129.75"/> -<text text-anchor="middle" x="501" y="-108.05" font-family="Arial" font-size="14.00">LOCKED_IN</text> +<path fill="#ffffa0" stroke="black" stroke-width="2" d="M634,-129.75C634,-129.75 550,-129.75 550,-129.75 544,-129.75 538,-123.75 538,-117.75 538,-117.75 538,-105.75 538,-105.75 538,-99.75 544,-93.75 550,-93.75 550,-93.75 634,-93.75 634,-93.75 640,-93.75 646,-99.75 646,-105.75 646,-105.75 646,-117.75 646,-117.75 646,-123.75 640,-129.75 634,-129.75"/> +<text text-anchor="middle" x="592" y="-108.05" font-family="Arial" font-size="14.00">LOCKED_IN</text> </g> <!-- STARTED->LOCKED_IN --> -<g id="edge6" class="edge"> +<g id="edge7" class="edge"> <title>STARTED->LOCKED_IN</title> -<path fill="none" stroke="black" d="M126.15,-214.34C151.63,-207.94 182.41,-200.1 210,-192.75 281.79,-173.62 299.35,-167.41 371,-147.75 392.5,-141.85 416.03,-135.49 437.09,-129.83"/> -<polygon fill="black" stroke="black" points="438.14,-133.17 446.89,-127.19 436.32,-126.41 438.14,-133.17"/> -<text text-anchor="middle" x="434" y="-181.55" font-family="Times,serif" font-size="14.00">height < timeoutheight</text> -<text text-anchor="middle" x="434" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text> -<text text-anchor="middle" x="434" y="-151.55" font-family="Times,serif" font-size="14.00">threshold reached</text> +<path fill="none" stroke="black" d="M126.08,-218.75C163.11,-212.29 213.23,-202.95 257,-192.75 329.78,-175.79 346.33,-165.17 419,-147.75 454.78,-139.17 495.06,-130.94 527.74,-124.62"/> +<polygon fill="black" stroke="black" points="528.47,-128.04 537.63,-122.72 527.15,-121.17 528.47,-128.04"/> +<text text-anchor="middle" x="503.5" y="-181.55" font-family="Times,serif" font-size="14.00">height < timeoutheight</text> +<text text-anchor="middle" x="503.5" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text> +<text text-anchor="middle" x="503.5" y="-151.55" font-family="Times,serif" font-size="14.00">threshold reached</text> </g> <!-- MUST_SIGNAL->LOCKED_IN --> -<g id="edge5" class="edge"> +<g id="edge6" class="edge"> <title>MUST_SIGNAL->LOCKED_IN</title> -<path fill="none" stroke="black" d="M501,-210.28C501,-191.69 501,-161.99 501,-140.25"/> -<polygon fill="black" stroke="black" points="504.5,-140 501,-130 497.5,-140 504.5,-140"/> -<text text-anchor="middle" x="520" y="-166.55" font-family="Times,serif" font-size="14.00">always</text> +<path fill="none" stroke="black" d="M592,-210.28C592,-191.69 592,-161.99 592,-140.25"/> +<polygon fill="black" stroke="black" points="595.5,-140 592,-130 588.5,-140 595.5,-140"/> +<text text-anchor="middle" x="616.5" y="-166.55" font-family="Times,serif" font-size="14.00">always</text> </g> <!-- FAILED->FAILED --> -<g id="edge11" class="edge"> +<g id="edge12" class="edge"> <title>FAILED:sw->FAILED:nw</title> <path fill="none" stroke="black" d="M18,-93.75C12,-83.25 0,-83.25 0,-111.75 0,-130.01 4.92,-136.57 10.04,-136.17"/> <polygon fill="black" stroke="black" points="12.41,-138.75 18,-129.75 8.02,-133.3 12.41,-138.75"/> </g> <!-- FAILED->LOCKED_IN --> +<!-- LOCKED_IN->LOCKED_IN --> +<g id="edge5" class="edge"> +<title>LOCKED_IN:se->LOCKED_IN:ne</title> +<path fill="none" stroke="black" d="M646,-93.75C652,-83.25 664,-83.25 664,-111.75 664,-130.01 659.08,-136.57 653.96,-136.17"/> +<polygon fill="black" stroke="black" points="655.98,-133.3 646,-129.75 651.59,-138.75 655.98,-133.3"/> +<text text-anchor="middle" x="796.5" y="-108.05" font-family="Times,serif" font-size="14.00">height < minimum_activation_height</text> +</g> <!-- ACTIVE --> <g id="node6" class="node"> <title>ACTIVE</title> -<path fill="#a0ffa0" stroke="black" stroke-width="2" d="M543,-42.75C543,-42.75 459,-42.75 459,-42.75 453,-42.75 447,-36.75 447,-30.75 447,-30.75 447,-18.75 447,-18.75 447,-12.75 453,-6.75 459,-6.75 459,-6.75 543,-6.75 543,-6.75 549,-6.75 555,-12.75 555,-18.75 555,-18.75 555,-30.75 555,-30.75 555,-36.75 549,-42.75 543,-42.75"/> -<text text-anchor="middle" x="501" y="-21.05" font-family="Arial" font-size="14.00">ACTIVE</text> +<path fill="#a0ffa0" stroke="black" stroke-width="2" d="M634,-42.75C634,-42.75 550,-42.75 550,-42.75 544,-42.75 538,-36.75 538,-30.75 538,-30.75 538,-18.75 538,-18.75 538,-12.75 544,-6.75 550,-6.75 550,-6.75 634,-6.75 634,-6.75 640,-6.75 646,-12.75 646,-18.75 646,-18.75 646,-30.75 646,-30.75 646,-36.75 640,-42.75 634,-42.75"/> +<text text-anchor="middle" x="592" y="-21.05" font-family="Arial" font-size="14.00">ACTIVE</text> </g> <!-- LOCKED_IN->ACTIVE --> <g id="edge4" class="edge"> <title>LOCKED_IN->ACTIVE</title> -<path fill="none" stroke="black" d="M501,-93.55C501,-81.91 501,-66.3 501,-52.99"/> -<polygon fill="black" stroke="black" points="504.5,-52.93 501,-42.93 497.5,-52.93 504.5,-52.93"/> -<text text-anchor="middle" x="520" y="-64.55" font-family="Times,serif" font-size="14.00">always</text> +<path fill="none" stroke="black" d="M592,-93.55C592,-81.91 592,-66.3 592,-52.99"/> +<polygon fill="black" stroke="black" points="595.5,-52.93 592,-42.93 588.5,-52.93 595.5,-52.93"/> +<text text-anchor="middle" x="730.5" y="-64.55" font-family="Times,serif" font-size="14.00">height >= minimum_activation_height</text> </g> <!-- ACTIVE->ACTIVE --> -<g id="edge10" class="edge"> +<g id="edge11" class="edge"> <title>ACTIVE:sw->ACTIVE:nw</title> -<path fill="none" stroke="black" d="M447,-6.75C441,3.75 429,3.75 429,-24.75 429,-43.01 433.92,-49.57 439.04,-49.17"/> -<polygon fill="black" stroke="black" points="441.41,-51.75 447,-42.75 437.02,-46.3 441.41,-51.75"/> +<path fill="none" stroke="black" d="M538,-6.75C532,3.75 520,3.75 520,-24.75 520,-43.01 524.92,-49.57 530.04,-49.17"/> +<polygon fill="black" stroke="black" points="532.41,-51.75 538,-42.75 528.02,-46.3 532.41,-51.75"/> </g> </g> </svg> diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index f90919a..c9fcd6f 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -19,9 +19,9 @@ This document specifies a proposed change to the semantics of the 'version' fiel ==Motivation== -BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled. +[[bip-0034.mediawiki|BIP 34]] introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled. -In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66 and BIP 65, which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary. +In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in [[bip-0066.mediawiki|BIP 66]] and [[bip-0065.mediawiki|BIP 65]], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary. ==Specification== @@ -195,7 +195,7 @@ If versionbits is being used, "version" MUST be within the versionbits range of Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character. -Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113. +Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs [[bip-0016.mediawiki|16]], [[bip-0065.mediawiki|65]], [[bip-0066.mediawiki|66]], [[bip-0068.mediawiki|68]], [[bip-0112.mediawiki|112]], and [[bip-0113.mediawiki|113]]. If a client does not understand a rule without the prefix, it may use it unmodified for mining. On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction). A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified. diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index ab1c3b8..9d38248 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -188,3 +188,6 @@ C++: C (with Python/Java/Javascript bindings): * https://github.com/ElementsProject/libwally-core + +Python: +* https://github.com/scgbckbone/btc-hd-wallet diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index cbd3a2a..b0131c3 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -35,19 +35,19 @@ The terminology related to keychains used in the wild varies widely, for example ==Motivation== -Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human friendly serialization of the BIP32 root key (or BIP32 extended keys in general) which makes paper backups or manually restoring the key more error-prone. BIP39 was designed solve this problem but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic. +Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human friendly serialization of the BIP32 root key (or BIP32 extended keys in general) which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic. -Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support of BIP32 extended private keys so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenarios are particularly satisfactory for security reasons. For example, some wallets may be inherently less secure like hot wallets on smartphones, Join Market servers, Lightning Network nodes. Having multiple seeds is far from desirable especially for those who rely on split key or redundancy backups in different geological locations. Adding is necessarily difficult and may result in users being more lazy with subsequent keys, such that compromises security or leads to key loss. +Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenarios are particularly satisfactory for security reasons. For example, some wallets may be inherently less secure like hot wallets on smartphones, Join Market servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys. -There is added complication with wallets that implement other standards, or no standards at all. Bitcoin Core wallet uses a WIF as the ''hdseed'', and yet other wallets use different mnemonic schemes like Electrum to derive the BIP32 root key. Other cryptocurrencies like Monero also use a different mnemonic scheme entirely. +There is added complication with wallets that implement other standards, or no standards at all. Bitcoin Core wallet uses a WIF as the ''hdseed'', and yet other wallets like Electrum use different mnemonic schemes to derive the BIP32 root key. Other cryptocurrencies like Monero also use an entirely different mnemonic scheme. -Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" to derive a mnemonic/seed, and then process the mnemonic into a BIP32 key, or private key. We can use BIP32 itself to derive the "initial entropy" to then recreate the same mnemonic or seed according the specific application standard of the target wallet. We can use a BIP44 like categorization to ensure unitform derivation according to the target application type. +Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" to derive a mnemonic/seed, and then process the mnemonic into a BIP32 key, or private key. We can use BIP32 itself to derive the "initial entropy" to then recreate the same mnemonic or seed according to the specific application standard of the target wallet. We can use a BIP44-like categorization to ensure uniform derivation according to the target application type. ==Specification== We assume a single BIP32 master root key. This specification is not concerned with how this was derived (e.g. directly or via a mnemonic scheme such as BIP39). -For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation truncating the rest +For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation truncating the rest. The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231]. @@ -87,7 +87,7 @@ xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu OUTPUT * DERIVED KEY=cca20ccb0e9a90feb0912870c3323b24874b0ca3d8018c4b96d0b97c0e82ded0 -* DERIVED ENTROPY=6bea85e51a05e6dbaf2ccee05097758213807997ba936589cef01c8f19c0079f395a0cd045efa3438677f3ef9ad34c9a68506626c5a17e51ed5e177852ee7fdc +* DERIVED ENTROPY=efecfbccffea313214232d29e71563d941229afb4338c21f9517c41aaa0d16f00b83d2a09ef747e7a64e8e2bd5a14869e693da66ce94ac2da570ab7ee48618f7 * DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111 @@ -102,20 +102,24 @@ OUTPUT * 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/] + +btc_hd_wallet: [https://github.com/scgbckbone/btc-hd-wallet] + ==Applications== -Application number define how entropy will be used post processing. Some basic examples follow: +The Application number defines how entropy will be used post processing. Some basic examples follow: -Derivation path uses the format <code>m/83696968'/{app_no}'/{index}'</code> where ''{app_no}'' path for the application, and ''{index}'' in the index. +Derivation path uses the format <code>m/83696968'/{app_no}'/{index}'</code> where ''{app_no}'' is the path for the application, and ''{index}'' is the index. ===BIP39=== Application number: 39' -Truncate trailing (least significant) bytes of the entropy to the number of bits required to map to the relevant word length 128 bits for 12 words, 256 bits for 24 words. +Truncate trailing (least significant) bytes of the entropy to the number of bits required to map to the relevant word length: 128 bits for 12 words, 256 bits for 24 words. The derivation path format is: <code>m/83696968'/39'/{language}'/{words}'/{index}'</code> -Example a BIP39 mnemonic with 12 English words (first index) would have the path <code>m/83696968'/39'/0'/12'/0'</code> the next key would be <code>m/83696968'/39'/0'/12'/1'</code> etc. +Example: a BIP39 mnemonic with 12 English words (first index) would have the path <code>m/83696968'/39'/0'/12'/0'</code>, the next key would be <code>m/83696968'/39'/0'/12'/1'</code> etc. Language Table @@ -284,17 +288,17 @@ 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. -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 dual purpose. +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. ==Backwards Compatibility== This specification is not backwards compatible with any other existing specification. -This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived, as such this standard is allows it to derive wallets with initialization schemes like BIP39 or Electrum wallet style mnemonics. +This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived. As such, this standard is able to derive wallets with initialization schemes like BIP39 or Electrum wallet style mnemonics. ==Discussion== -The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (k) be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This acts in an abundance of caution to ward off unwanted side effects should k be used for a dual purpose, including as a nonce hash(k), where undesirable and unforeseen interactions could occur. +The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur. ==Acknowledgements== @@ -306,10 +310,10 @@ BIP32, BIP39 ==Footnotes== -[1] There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users should iterate to the next index). +[1] There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users to iterate to the next index). From BIP32: -> In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or ≥ n, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2<sup>127</sup>.) +In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or ≥ n, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2<sup>127</sup>.) ==Copyright== 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-0118.mediawiki b/bip-0118.mediawiki index 1b2f27c..afbfde6 100644 --- a/bip-0118.mediawiki +++ b/bip-0118.mediawiki @@ -92,7 +92,7 @@ Any participant can take a transaction and rewrite it by changing the hash reference to the previous output, without invalidating the signatures. This allows transactions to be bound to any output that matches the -value committed to in the <tt>witness</tt> and whose <tt>witnessProgram</tt>, +value committed to in the signature and whose <tt>witnessProgram</tt>, combined with the spending transaction's <tt>witness</tt> returns <tt>true</tt>. Previously, all information in the transaction was committed in the 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-0136.mediawiki b/bip-0136.mediawiki index f94171d..1caa027 100644 --- a/bip-0136.mediawiki +++ b/bip-0136.mediawiki @@ -16,312 +16,814 @@ == Introduction == === Abstract === -This document proposes a convenient human useable format, '''"TxRef"''', as a standard way to refer to a transaction position within the Bitcoin Blockchain, and optionally a particular outpoint index within the referred transaction. The primary purpose of this format is to allow users to refer to a confirmed transaction (and optionally an outpoint index within) in a standard, reliable, and concise way. +This document proposes a convenient, human usable encoding to refer to a '''confirmed transaction position''' within the Bitcoin blockchain--known as '''"TxRef"'''. The primary purpose of this encoding is to allow users to refer to a confirmed transaction (and optionally, a particular outpoint index within the transaction) in a standard, reliable, and concise way. -''Please note: Unlike TxID where there is strong cryptographic link between the ID and the actual transaction, TxRef only provides a weak link to a particular transaction. TxRef locates an offset within a blockchain for a transaction, that may - or may not - point to an actual transaction, which in fact may change with reorganisations. We recommend that TxRef's should be not used for positions within the blockchain having a maturity less than 100 blocks.'' +''Please note: Unlike a transaction ID, '''"TxID"''', where there is a strong cryptographic link between the ID and the actual transaction, a '''TxRef''' only provides a weak link to a particular transaction. A '''TxRef''' locates an offset within a blockchain for a transaction, that may - or may not - point to an actual transaction, which in fact may change with reorganisations. We recommend that '''TxRef'''s should be not used for positions within the blockchain having a maturity less than 100 blocks.'' + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [https://tools.ietf.org/html/rfc2119 RFC 2119]. === Copyright === This BIP is licensed under the 2-clause BSD license. === Motivation === -Since the first version of Bitcoin, TxID's (Transaction Identifiers) have been a core part of the consensus protocol and have been routinely used to identify individual transactions between users. +Since the first version of Bitcoin, '''TxID'''s have been a core part of the consensus protocol and are routinely used to identify individual transactions between users. However, for many use-cases they have practical limitations: -* TxIDs are expensive for full nodes to lookup (requiring either a linear scan of the blockchain, or an expensive TxID index). -* TxIDs require third-party services for SPV wallets to lookup. -* TxIDs are very long HEX encoded values (64 characters long). +* '''TxID'''s are expensive for full nodes to lookup (requiring either a linear scan of the blockchain, or an expensive '''TxID''' index). +* '''TxID'''s require third-party services for SPV wallets to lookup. +* '''TxID'''s are 64 character HEX encoded values. -For transactions that have been embedded in the blockchain, it is possible to reference them not by their TxID, but by their location within the blockchain itself. The encoding can be made friendly for occasional human transcription. In this document, we propose a standard for doing this. +It is possible to reference transactions not only by their '''TxID''', but by their location within the blockchain itself. Rather than use the 64 character '''TxID''', an encoding of the position coordinates can be made friendly for occasional human transcription. In this document, we propose a standard for doing this. === Examples === -These examples are for Bitcoin Transactions. -* Genesis Coinbase Transaction (Transaction #0 of Block #0): <tt>tx1:rqqq-qqqq-qmhu-qhp</tt> -* Transaction #2205 of Block #466793: <tt>tx1:rjk0-uqay-zsrw-hqe</tt> + +{| class="wikitable" +|- +! Block # !! Transaction # !! Outpoint # !! TxRef !! TxID +|- +| 0 || 0 || 0 || tx1:rqqq‑qqqq‑qwtv‑vjr || 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b +|- +| 170 || 1 || 0 || tx1:r52q‑qqpq‑qpty‑cfg || f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 +|- +| 456789 || 1234 || 1 || tx1:y29u‑mqjx‑ppqq‑sfp2‑tt || 6fb8960f70667dc9666329728a19917937896fc476dfc54a3e802e887ecb4e82 +|} == Specification == -A '''confirmed transaction position reference''', or '''TxRef''', is a reference to a particular location within the blockchain, specified by the block height and a transaction index within the block, and optionally a outpoint index within the transaction. +A '''confirmed transaction position reference''', or '''TxRef''', is a reference to a particular location within the blockchain, specified by the block height and a transaction index within the block, and optionally, an outpoint index within the transaction. ''Please Note: All values in this specification are encoded in little-endian format.'' -=== Transaction Position Reference Considerations === -A TxRef may reference a location that doesn't exist because: +=== TxRef Considerations === +It is possible for a '''TxRef''' to reference a transaction that doesn't really exist because: -* The specified block hasn't yet been mined. Or, +* The specified block hasn't yet been mined. * The transaction index is greater than the total number of transactions included within the specified block. * The optional outpoint index is greater than the total outpoints contained within the transaction. -Therefore, implementers must be careful not to display TxRef's to users prematurely: +Therefore, implementers must be careful not to display '''TxRef'''s to users prematurely: + +* Applications MUST NOT display '''TxRef'''s for transactions with less than 6 confirmations. +* Application MUST show a warning for '''TxRef'''s for transactions with less than 100 confirmations. +** This warning SHOULD state that in the case of a large reorganisation, the '''TxRef'''s displayed may point to a different transaction, or to no transaction at all. + +=== TxRef Format === + +'''TxRef''' MUST use the '''Bech32m'''<ref>'''Why use Bech32 Encoding for Confirmed Transaction References?''' The error detection and correction properties of this encoding format make it very attractive. We expect that it will be reasonable for software to correct a maximum of two characters; however, we haven’t specified this yet.</ref> encoding as defined in [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-0173] and later refined in [https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki BIP-0350]. The Bech32m encoding consists of: -* Applications MUST NOT display TxRef's for transactions with less than 6 confirmations. -* Application MUST show a warning for TxRef's for transactions with less than 100 confirmations. -** This warning SHOULD state that in the case of a large reorganisation, the TxRefs Displayed may point to a different transaction, or to no transaction at all. +==== Human-Readable Part ==== + +The '''HRP''' can be thought of as a label. We have chosen labels to distinguish between Main, Test, and Regtest networks: +* Mainnet: '''"tx"'''. +* Testnet: '''"txtest"'''. +* Regtest: '''"txrt"'''. + +==== Separator ==== + +The separator is the character '''"1"'''. + +==== Data Part ==== + +The data part for a '''TxRef''' consists of the transaction's block height, transaction index within the block, and optionally, an outpoint index. Specific encoding details for the data are given below. + +''Please note: other specifications, such as [https://w3c-ccg.github.io/did-spec/ the Decentralized Identifiers spec], have implicitly encoded the information contained within the HRP elsewhere. In this case they may choose to not include the HRP as specified here.'' + +==== Readability ==== + +To increase portability and readability, additional separator characters SHOULD be added to the '''TxRef''': + +* A Colon<ref>'''Why add a colon here?''' This allows it to conform better with W3C URN/URL standards.</ref> '''":"''' added after the separator character '1'. +* Hyphens<ref>'''Why hyphens within the TxRef?''' As '''TxRef'''s are short, we expect that they will be quoted via voice or written by hand. The inclusion of hyphens every 4 characters breaks up the string and means people don't lose their place so easily.</ref> '''"-"''' added after every 4 characters beyond the colon. === Encoding === -TxRef uses standard Bech32<ref name=":0">'''Why use Bech32 Encoding for Confirmed Transaction References?''' The error detection and correction properties of this encoding format make it very attractive. We expect that it will be reasonable for software to correct a maximum of two characters; however, we haven’t specified this yet.</ref> encoding as defined in [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-173] and therefore consists of: +Encoding a '''TxRef''' requires 4 or 5 pieces of data: a magic code denoting which network is being used; a version number (currently always 0); the block height of the block containing the transaction; the index of the transaction within the block; and optionally, the index of the outpoint within the transaction. Only a certain number of bits are supported for each of these values, see the following table for details. + +{| class="wikitable" +! +!Description +!Possible Data Type +!'''# of Bits used''' +!Values +|- +| style="background: #99DDFF; color: black; text-align : center;" | Magic Code +|Chain Namespacing Code +|uint8 +| style="background: #99DDFF; color: black; text-align : center;" | 5 +|'''3''': Mainnet<br>'''4''': Mainnet with Outpoint<br>'''6''': Testnet<br>'''7''': Testnet with Outpoint<br>'''0''': Regtest<br>'''1''': Regtest with Outpoint +|- +| style="background: #DDDDDD; color: black; text-align : center;" | Version +|For Future Use +|uint8 +| style="background: #DDDDDD; color: black; text-align : center;" | 1 +|Must be '''0''' +|- +| style="background: #EEDD88; color: black; text-align : center;" | Block<br>Height +|The Block Height of the Tx +|uint32 +| style="background: #EEDD88; color: black; text-align : center;" | 24 +|Block 0 to Block 16777215 +|- +| style="background: #FFAABB; color: black; text-align : center;" | Transaction<br>Index +|The index of the Tx inside the block +|uint16, uint32 +| style="background: #FFAABB; color: black; text-align : center;" | 15 +|Tx 0 to Tx 32767 +|- +| style="background: #BBCC33; color: black; text-align : center;" | Outpoint<br>Index +|The index of the Outpoint inside the Tx +|uint16, uint32 +| style="background: #BBCC33; color: black; text-align : center;" | 15 +|Outpoint 0 to Outpoint 32767 +|} -* Human-readable Part, or "HRP", that provides namespacing. We have chosen to distinguish between Main and Test Networks: -** For Any Mainnet Network: '''"tx"'''. -** For Any Testnet Network: '''"txtest"'''. -** Please see [https://github.com/satoshilabs/slips/blob/master/slip-0173.md SLIP-0173 : Registered human-readable parts for BIP-0173] for a full list of HRP's including these two and others relating to other projects. -* Separator: '''"1"'''. -* Data Part. +==== Magic Notes ==== +The magic code provides namespacing between chains: -Please note: other specifications, such as [https://w3c-ccg.github.io/did-spec/ the Decentralized Identifiers spec], have implicitly encoded the information contained within the HRP elsewhere. In this case they may choose to not include the HRP as specified here. +* For Mainnet the magic code is: '''0x3''', leading to an '''"r"''' character when encoded. +* For Mainnet with Outpoint Encoded the magic code is: '''0x4''', leading to a '''"y"''' character when encoded. +* For Testnet the magic code is: '''0x6''', leading to an '''"x"''' character when encoded. +* For Testnet with Outpoint Encoded the magic code is: '''0x7''', leading to an '''"8"''' character when encoded. +* For Regtest the magic code is: '''0x0''', leading to a '''"q"''' character when encoded. +* For Regtest with Outpoint Encoded the magic code is: '''0x1''', leading to a '''"p"''' character when encoded. -To increase portability and readability additional separators SHOULD be added: +==== Encoding Example ==== -* A Colon<ref>'''Why add a colon here?''' This allows it to conform better with W3C URN/URL standards.</ref> '''":"''' added after '1'. -* Hyphens<ref>'''Why hyphens within the TxRef?''' As TxRef's are short, we expect that they will be quoted via voice or written by hand. The inclusion of hyphens every 4 characters breaks up the string and means people don't lose their place so easily.</ref> '''"-"''' added after every 4 characters beyond the colon. +We want to encode a '''TxRef''' that refers to Transaction #1234 of Block #456789 on the Mainnet chain. We use this data in preparation for the Bech32 encoding algorithm: -All non-bech32-alphabet characters after the bech32 code separator MUST be ignored/removed when parsing (except for terminating characters).<ref>'''Why strip all non-bech32-alphabet characters?''' We do not wish to expect the users to keep their TxRef's in good unicode form (hyphens, colons, invisible spaces, random unicode characters, etc). We expect them to copy, paste, write by-hand, write in a mix of character sets, etc. Parsers should automatically correct for all sorts of these common errors. -</ref> {| class="wikitable" -|+Text Encoding of the TxRef ! -!Bit -!Character -!Characters -!Value +!Decimal<br>Value +!Binary<br>Value +!'''# of Bits<br>used''' +!Bit Indexes and Values +|- +| style="background: #99DDFF; color: black; text-align : center;" | Magic<br>Code +| style="background: #99DDFF; color: black; text-align : center;" | 3 +|00000011 +| style="background: #99DDFF; color: black; text-align : center;" | 5 +|(mc04, mc03, mc02, mc01, mc00) = (0, 0, 0, 1, 1) +|- +| style="background: #DDDDDD; color: black; text-align : center;" | Version +| style="background: #DDDDDD; color: black; text-align : center;" | 0 +|00000000 +| style="background: #DDDDDD; color: black; text-align : center;" | 1 +|(v0) = (0) +|- +| style="background: #EEDD88; color: black; text-align : center;" | Block<br>Height +| style="background: #EEDD88; color: black; text-align : center;" | 456789 +|00000110<br>11111000<br>01010101 +| style="background: #EEDD88; color: black; text-align : center;" | 24 +|(bh23, bh22, bh21, bh20, bh19, bh18, bh17, bh16) = (0, 0, 0, 0, 0, 1, 1, 0)<br>(bh15, bh14, bh13, bh12, bh11, bh10, bh09, bh08) = (1, 1, 1, 1, 1, 0, 0, 0)<br>(bh07, bh06, bh05, bh04, bh03, bh02, bh01, bh00) = (0, 1, 0, 1, 0, 1, 0, 1) +|- +| style="background: #FFAABB; color: black; text-align : center;" | Transaction<br>Index +| style="background: #FFAABB; color: black; text-align : center;" | 1234 +|00000100<br>11010010 +| style="background: #FFAABB; color: black; text-align : center;" | 15 +|(ti14, ti13, ti12, ti11, ti10, ti09, ti08) = (0, 0, 0, 0, 1, 0, 0)<br>(ti07, ti06, ti05, ti04, ti03, ti02, ti01, ti00) = (1, 1, 0, 1, 0, 0, 1, 0) +|} + +As shown in the last column, we take the necessary bits of each binary value and copy them into nine unsigned chars illustrated in the next table. We only set the lower five bits of each unsigned char as the bech32 algorithm only uses those bits. + +{| class="wikitable" style="text-align: center" +! +! +!style="width:2em"|7 +!style="width:2em"|6 +!style="width:2em"|5 +!style="width:2em"|4 +!style="width:2em"|3 +!style="width:2em"|2 +!style="width:2em"|1 +!style="width:2em"|0 +! +!Decimal<br>Value +!Bech32<br>Character |- -|Human Readable Part +| || || || || || || || || || || || || +|- +| rowspan="2" | data[0] || Index +|na +|na +|na +| style="background: #99DDFF; color: black; text-align : center;" | mc04 +| style="background: #99DDFF; color: black; text-align : center;" | mc03 +| style="background: #99DDFF; color: black; text-align : center;" | mc02 +| style="background: #99DDFF; color: black; text-align : center;" | mc01 +| style="background: #99DDFF; color: black; text-align : center;" | mc00 +| +| | -|1 – 2 -|2 -|Bitcoin Mainnet: "'''tx'''", Bitcoin Testnet: "'''txtest'''" |- -|Separator +|Value +|0 +|0 +|0 +|0 +|0 +|0 +|1 +|1 | |3 -|1 -|"'''1'''" +|r +|- +| || || || || || || || || || || || |- -|Colon +| rowspan="2" | data[1] || Index +|na +|na +|na +| style="background: #EEDD88; color: black; text-align : center;" | bh03 +| style="background: #EEDD88; color: black; text-align : center;" | bh02 +| style="background: #EEDD88; color: black; text-align : center;" | bh01 +| style="background: #EEDD88; color: black; text-align : center;" | bh00 +| style="background: #DDDDDD; color: black; text-align : center;" | v0 | -|4 +| +| +|- +|Value +|0 +|0 +|0 +|0 +|1 +|0 |1 -|"''':'''" +|0 +| +|10 +|2 |- -|Data -|0 – 19 -|5 – 8 -|4 +| || || || || || || || || || || || +|- +| rowspan="2" | data[2] || Index +|na +|na +|na +| style="background: #EEDD88; color: black; text-align : center;" | bh08 +| style="background: #EEDD88; color: black; text-align : center;" | bh07 +| style="background: #EEDD88; color: black; text-align : center;" | bh06 +| style="background: #EEDD88; color: black; text-align : center;" | bh05 +| style="background: #EEDD88; color: black; text-align : center;" | bh04 +| +| | |- -|Hyphen +|Value +|0 +|0 +|0 +|0 +|0 +|1 +|0 +|1 | +|5 |9 +|- +| || || || || || || || || || || || +|- +| rowspan="2" | data[3] || Index +|na +|na +|na +| style="background: #EEDD88; color: black; text-align : center;" | bh13 +| style="background: #EEDD88; color: black; text-align : center;" | bh12 +| style="background: #EEDD88; color: black; text-align : center;" | bh11 +| style="background: #EEDD88; color: black; text-align : center;" | bh10 +| style="background: #EEDD88; color: black; text-align : center;" | bh09 +| +| +| +|- +|Value +|0 +|0 +|0 |1 -|"'''-'''" -|} -The Data - Hyphen pattern is repeated for the entire length of data, ( a hyphen is inserted after every encoded 20 bits or 4 data characters). -=== Data === - -Depending on if an optional transaction outpoint is included, there can be 75 or 90 bits of data encoded in the string above. These bits are defined in this manner: - -{| class="wikitable" -|+TxRef Binary Format for Bitcoin Mainnet and Bitcoin Testnet: -! -!'''Bit''' -!'''Bit(s)''' -!'''Type''' -!'''Values''' -!'''Notes''' -|- -|Magic Code -|0 – 4 -|5 -|Chain Namespacing Code -|'''0x3''' for Bitcoin Mainnet. -'''0x4''' for Bitcoin Mainnet with Outpoint. -'''0x6''' for Bitcoin Testnet. -'''0x7''' for Bitcoin Testnet with Outpoint. +|1 +|1 +|0 +|0 | +|28 +|u |- -|Version -|5 +| || || || || || || || || || || || +|- +| rowspan="2" | data[4] || Index +|na +|na +|na +| style="background: #EEDD88; color: black; text-align : center;" | bh18 +| style="background: #EEDD88; color: black; text-align : center;" | bh17 +| style="background: #EEDD88; color: black; text-align : center;" | bh16 +| style="background: #EEDD88; color: black; text-align : center;" | bh15 +| style="background: #EEDD88; color: black; text-align : center;" | bh14 +| +| +| +|- +|Value +|0 +|0 +|0 +|1 +|1 +|0 +|1 |1 -|For Future Use -|Must be '''0x0''' | +|27 +|m |- -|Block Height -|6 – 29 -|24 -|The Block Height of the Tx -|Block 0 (genesis) to block 16777215 -|Until Year ~2328 +| || || || || || || || || || || || |- -|Transaction Index -|30 – 44 -|15 -|The index of the Tx inside the block -|Tx 0 (coinbase) to Tx position 32767 -|Max Tx's in block is 16665 +| rowspan="2" | data[5] || Index +|na +|na +|na +| style="background: #EEDD88; color: black; text-align : center;" | bh23 +| style="background: #EEDD88; color: black; text-align : center;" | bh22 +| style="background: #EEDD88; color: black; text-align : center;" | bh21 +| style="background: #EEDD88; color: black; text-align : center;" | bh20 +| style="background: #EEDD88; color: black; text-align : center;" | bh19 +| +| +| +|- +|Value +|0 +|0 +|0 +|0 +|0 +|0 +|0 +|0 +| +|0 +|q +|- +| || || || || || || || || || || || +|- +| rowspan="2" | data[6] || Index +|na +|na +|na +| style="background: #FFAABB; color: black; text-align : center;" | ti04 +| style="background: #FFAABB; color: black; text-align : center;" | ti03 +| style="background: #FFAABB; color: black; text-align : center;" | ti02 +| style="background: #FFAABB; color: black; text-align : center;" | ti01 +| style="background: #FFAABB; color: black; text-align : center;" | ti00 +| +| +| +|- +|Value +|0 +|0 +|0 +|1 +|0 +|0 +|1 +|0 +| +|18 +|j +|- +| || || || || || || || || || || || +|- +| rowspan="2" | data[7] || Index +|na +|na +|na +| style="background: #FFAABB; color: black; text-align : center;" | ti09 +| style="background: #FFAABB; color: black; text-align : center;" | ti08 +| style="background: #FFAABB; color: black; text-align : center;" | ti07 +| style="background: #FFAABB; color: black; text-align : center;" | ti06 +| style="background: #FFAABB; color: black; text-align : center;" | ti05 +| +| +| +|- +|Value +|0 +|0 +|0 +|0 +|0 +|1 +|1 +|0 +| +|6 +|x +|- +| || || || || || || || || || || || +|- +| rowspan="2" | data[8] || Index +|na +|na +|na +| style="background: #FFAABB; color: black; text-align : center;" | ti14 +| style="background: #FFAABB; color: black; text-align : center;" | ti13 +| style="background: #FFAABB; color: black; text-align : center;" | ti12 +| style="background: #FFAABB; color: black; text-align : center;" | ti11 +| style="background: #FFAABB; color: black; text-align : center;" | ti10 +| +| +| +|- +|Value +|0 +|0 +|0 +|0 +|0 +|0 +|0 +|1 +| +|1 +|p |} -If the magic code is '''0x4''' or '''0x7''', an optional outpoint is included in the encoding: + +The Bech32 algorithm encodes the nine unsigned chars above and computes a checksum of those chars and encodes that as well--this gives a six character checksum (in this case, '''utt3p0''') which is appended to the final '''TxRef'''. The final '''TxRef''' given is: '''tx1:r29u-mqjx-putt-3p0''' and is illustrated in the following table: + +TxRef character indexes and descriptions +{| class="wikitable" style="text-align: top" +!style="width:2em"|Index +!style="width:2em"|0 +!style="width:2em"|1 +!style="width:2em"|2 +!style="width:2em"|3 +!style="width:2em"|4 +!style="width:2em"|5 +!style="width:2em"|6 +!style="width:2em"|7 +!style="width:2em"|8 +!style="width:2em"|9 +!style="width:2em"|10 +!style="width:2em"|11 +!style="width:2em"|12 +!style="width:2em"|13 +!style="width:2em"|14 +!style="width:2em"|15 +!style="width:2em"|16 +!style="width:2em"|17 +!style="width:2em"|18 +!style="width:2em"|19 +!style="width:2em"|20 +!style="width:2em"|21 +|- +|Char: +| style="background: #BBCCEE; color: black; text-align : center;" | t +| style="background: #BBCCEE; color: black; text-align : center;" | x +| style="background: #FFCCCC; color: black; text-align : center;" | 1 +| style="background: #CCDDAA; color: black; text-align : center;" | : +| style="background: #EEEEBB; color: black; text-align : center;" | r +| style="background: #EEEEBB; color: black; text-align : center;" | 2 +| style="background: #EEEEBB; color: black; text-align : center;" | 9 +| style="background: #EEEEBB; color: black; text-align : center;" | u +| style="background: #CCDDAA; color: black; text-align : center;" | - +| style="background: #EEEEBB; color: black; text-align : center;" | m +| style="background: #EEEEBB; color: black; text-align : center;" | q +| style="background: #EEEEBB; color: black; text-align : center;" | j +| style="background: #EEEEBB; color: black; text-align : center;" | x +| style="background: #CCDDAA; color: black; text-align : center;" | - +| style="background: #EEEEBB; color: black; text-align : center;" | p +| style="background: #EEEEBB; color: black; text-align : center;" | u +| style="background: #EEEEBB; color: black; text-align : center;" | t +| style="background: #EEEEBB; color: black; text-align : center;" | t +| style="background: #CCDDAA; color: black; text-align : center;" | - +| style="background: #EEEEBB; color: black; text-align : center;" | 3 +| style="background: #EEEEBB; color: black; text-align : center;" | p +| style="background: #EEEEBB; color: black; text-align : center;" | 0 +|} + +==== Outpoint Index ==== + +Some uses of '''TxRef''' may want to refer to a specific outpoint of the transaction. In the previous example, since we did not specify the outpoint index, the '''TxRef''' '''tx1:r29u-mqjx-putt-3p0''' implicitly references the first (index 0) outpoint of the 1234th transaction in the 456789th block in the blockchain. + +If instead, for example, we want to reference the second (index 1) outpoint, we need to change the magic code from '''3''' to '''4''' and would include the following in the data to be encoded: {| class="wikitable" -|+Optional Outpoint Index Encoding: ! -!'''Bit''' -!'''Bit(s)''' -!'''Type''' -!'''Values''' -!'''Notes''' -|- -|Outpoint Index -|45 – 59 -|15 -|The index of the Outpoint inside the Tx -|Outpoint 0 to Outpoint Position 32767 -| +!Decimal<br>Value +!Binary<br>Value +!'''# of Bits<br>used''' +!Bit Indexes and Values +|- +| style="background: #99DDFF; color: black; text-align : center;" | Magic<br>Code +| style="background: #99DDFF; color: black; text-align : center;" | 4 +|00000100 +| style="background: #99DDFF; color: black; text-align : center;" | 5 +|(mc04, mc03, mc02, mc01, mc00) = (0, 0, 1, 0, 0) +|- +| style="background: #BBCC33; color: black; text-align : center;" | Outpoint Index +| style="background: #BBCC33; color: black; text-align : center;" | 1 +|00000000 00000001 +| style="background: #BBCC33; color: black; text-align : center;" | 15 +|(op14, op13, op12, op11, op10, op09, op08) = (0, 0, 0, 0, 0, 0, 0)<br>(op07, op06, op05, op04, op03, op02, op01, op00) = (0, 0, 0, 0, 0, 0, 0, 1) |} -We include the 30-bit checksum last: -{| class="wikitable" -|+Bech32 Checksum Encoding: +{| class="wikitable" style="text-align: center" +! ! -!'''Bit''' -!'''Bit(s)''' -!'''Type''' -!'''Values''' -!'''Notes''' +!style="width:2em"|7 +!style="width:2em"|6 +!style="width:2em"|5 +!style="width:2em"|4 +!style="width:2em"|3 +!style="width:2em"|2 +!style="width:2em"|1 +!style="width:2em"|0 +! +!Decimal<br>Value +!Bech32<br>Character +|- +| || || || || || || || || || || || || +|- +| rowspan="2" | data[0] || Index +|na +|na +|na +| style="background: #99DDFF; color: black; text-align : center;" | mc04 +| style="background: #99DDFF; color: black; text-align : center;" | mc03 +| style="background: #99DDFF; color: black; text-align : center;" | mc02 +| style="background: #99DDFF; color: black; text-align : center;" | mc01 +| style="background: #99DDFF; color: black; text-align : center;" | mc00 +| +| +| +|- +|Value +|0 +|0 +|0 +|0 +|0 +|1 +|0 +|0 +| +|4 +|y +|- +| || || || || || || || || || || || |- -|Checksum -|45 – 74 or 60 – 89 -|30 -|Bech32 Checksum +| rowspan="2" | data[9] || Index +|na +|na +|na +| style="background: #BBCC33; color: black; text-align : center;" | op04 +| style="background: #BBCC33; color: black; text-align : center;" | op03 +| style="background: #BBCC33; color: black; text-align : center;" | op02 +| style="background: #BBCC33; color: black; text-align : center;" | op01 +| style="background: #BBCC33; color: black; text-align : center;" | op00 | | +| +|- +|Value +|0 +|0 +|0 +|0 +|0 +|0 +|0 +|1 +| +|1 +|p +|- +| || || || || || || || || || || || +|- +| rowspan="2" | data[10] || Index +|na +|na +|na +| style="background: #BBCC33; color: black; text-align : center;" | op09 +| style="background: #BBCC33; color: black; text-align : center;" | op08 +| style="background: #BBCC33; color: black; text-align : center;" | op07 +| style="background: #BBCC33; color: black; text-align : center;" | op06 +| style="background: #BBCC33; color: black; text-align : center;" | op05 +| +| +| +|- +|Value +|0 +|0 +|0 +|0 +|0 +|0 +|0 +|0 +| +|0 +|q +|- +| || || || || || || || || || || || +|- +| rowspan="2" | data[11] || Index +|na +|na +|na +| style="background: #BBCC33; color: black; text-align : center;" | op14 +| style="background: #BBCC33; color: black; text-align : center;" | op13 +| style="background: #BBCC33; color: black; text-align : center;" | op12 +| style="background: #BBCC33; color: black; text-align : center;" | op11 +| style="background: #BBCC33; color: black; text-align : center;" | op10 +| +| +| +|- +| Value +|0 +|0 +|0 +|0 +|0 +|0 +|0 +|0 +| +|0 +|q |} -==== Magic Notes: ==== -The magic code provides namespacing between chains. 5-bit magic codes are used for the Bitcoin Mainnet and the Bitcoin Testnet. (it may be significantly longer for other projects/chains): - -* For Bitcoin Mainnet the magic code is: '''0x3''', leading to an '''"r"''' character when encoded. -* For Bitcoin Mainnet with Outpoint Encoded the magic code is: '''0x4''', leading to an '''"y"''' character when encoded. -* For Bitcoin Testnet the magic code is: '''0x6''', leading to an '''"x"''' character when encoded. -* For Bitcoin Testnet with Outpoint Encoded the magic code is: '''0x7''', leading to an '''"8"''' character when encoded. +After Bech32 encoding all twelve unsigned chars above, we get the checksum: '''sfp2tt'''. The final '''TxRef''' given is: '''tx1:y29u-mqjx-ppqq-sfp2-tt''' and is illustrated in the following table: + +TxRef character indexes and descriptions +{| class="wikitable" style="text-align: top" +!style="width:2em"|Index +!style="width:2em"|0 +!style="width:2em"|1 +!style="width:2em"|2 +!style="width:2em"|3 +!style="width:2em"|4 +!style="width:2em"|5 +!style="width:2em"|6 +!style="width:2em"|7 +!style="width:2em"|8 +!style="width:2em"|9 +!style="width:2em"|10 +!style="width:2em"|11 +!style="width:2em"|12 +!style="width:2em"|13 +!style="width:2em"|14 +!style="width:2em"|15 +!style="width:2em"|16 +!style="width:2em"|17 +!style="width:2em"|18 +!style="width:2em"|19 +!style="width:2em"|20 +!style="width:2em"|21 +!style="width:2em"|22 +!style="width:2em"|23 +!style="width:2em"|24 +!style="width:2em"|25 +|- +|Char: +| style="background: #BBCCEE; color: black; text-align : center;" | t +| style="background: #BBCCEE; color: black; text-align : center;" | x +| style="background: #FFCCCC; color: black; text-align : center;" | 1 +| style="background: #CCDDAA; color: black; text-align : center;" | : +| style="background: #EEEEBB; color: black; text-align : center;" | y +| style="background: #EEEEBB; color: black; text-align : center;" | 2 +| style="background: #EEEEBB; color: black; text-align : center;" | 9 +| style="background: #EEEEBB; color: black; text-align : center;" | u +| style="background: #CCDDAA; color: black; text-align : center;" | - +| style="background: #EEEEBB; color: black; text-align : center;" | m +| style="background: #EEEEBB; color: black; text-align : center;" | q +| style="background: #EEEEBB; color: black; text-align : center;" | j +| style="background: #EEEEBB; color: black; text-align : center;" | x +| style="background: #CCDDAA; color: black; text-align : center;" | - +| style="background: #EEEEBB; color: black; text-align : center;" | p +| style="background: #EEEEBB; color: black; text-align : center;" | p +| style="background: #EEEEBB; color: black; text-align : center;" | q +| style="background: #EEEEBB; color: black; text-align : center;" | q +| style="background: #CCDDAA; color: black; text-align : center;" | - +| style="background: #EEEEBB; color: black; text-align : center;" | s +| style="background: #EEEEBB; color: black; text-align : center;" | f +| style="background: #EEEEBB; color: black; text-align : center;" | p +| style="background: #EEEEBB; color: black; text-align : center;" | 2 +| style="background: #CCDDAA; color: black; text-align : center;" | - +| style="background: #EEEEBB; color: black; text-align : center;" | t +| style="background: #EEEEBB; color: black; text-align : center;" | t +|} -Codes '''0x0''', '''0x1''', '''0x2''', '''0x5''', are also reserved for future use within the Bitcoin project. -''Any other chain MUST NOT start their magic code with any value between 0x0 and 0x7 inclusive.'' +=== Decoding === -Other magic codes will be specified in SLIP-XXXX "TxRef for Non-Bitcoin Chains and Networks". +The Bech32 spec defines 32 valid characters as its "alphabet". All non-Bech32-alphabet characters present in a '''TxRef''' after the Bech32 separator character MUST be ignored/removed when parsing (except for terminating characters). We do not wish to expect the users to keep their '''TxRef'''s in good form and '''TxRef'''s may contains hyphens, colons, invisible spaces, uppercase or random characters. We expect users to copy, paste, write by-hand, write in a mix of character sets, etc. Parsers SHOULD attempt to correct for these and other common errors, reporting to the user any '''TxRef'''s that violate a proper Bech32 encoding. -=== Compatibility === -There are no known compatibility issues. +As of early 2021, '''TxRef''' has been in limited use for a couple of years and it is possible that there are some '''TxRef'''s in use which were created with the original specification of Bech32 before the Bech32m refinement was codified. Due to this possibility, a '''TxRef''' parser SHOULD be able to decode both Bech32m and Bech32 encoded '''TxRef'''s. In such a case, a '''TxRef''' parser SHOULD display or somehow notify the user that they are using an obsolete '''TxRef''' and that they should upgrade it to the Bech32m version. Additionally, the parser MAY also display the Bech32m version. == Rationale == <references /> == Reference implementations == + C Reference Implementation (supports magic codes 0x3 and 0x6): https://github.com/jonasschnelli/bitcoin_txref_code Go Reference Implementation (supports magic codes 0x3 and 0x6): https://github.com/kulpreet/txref -C++ Reference Implementation (support magic codes 0x3, 0x4, 0x6, 0x7): https://github.com/dcdpr/btcr-DID-method/ +C++ Reference Implementation (supports magic codes 0x3, 0x4, 0x6, 0x7, 0x0 and 0x1): https://github.com/dcdpr/libtxref/ -== Appendices == +Java Reference Implementation (supports magic codes 0x3, 0x4, 0x6, 0x7, 0x0 and 0x1): https://github.com/dcdpr/libtxref-java/ -=== Test Vectors === -There are two sets of Test Vectors included here: - -* Bech32 Encoding Test Vectors. These are to test if a implementation accepts the encoding, with the correct human readable part, and separator. -* Bitcoin TxRef Test Vectors. These test the full specification, in particular, correct values for block height and the transaction index. +== Appendices == -==== Bech32 Encoding (for TxRef). ==== -''Please Note: All test vectors are shown to help test if a string is compliant or not. All real-life applications (such as for Bitcoin) should comply with the Bitcoin Test Vectors listed Below.'' +=== Test Examples === -The following strings have a valid Human Readable Part and Bech32 Checksum. -* <tt>TX1A12UEL5L</tt> -* <tt>tx1an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs</tt> -* <tt>tx1abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw</tt> -* <tt>tx11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j</tt> +The following examples show values for various combinations on mainnet and testnet; encoding block height, transaction index, and an optional output index. -The following list gives invalid TxRef's and the reason for their invalidity. -* <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty</tt>: Invalid human-readable part -* <tt>tx1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5</tt>: Invalid checksum +==== TxRef ==== +The following list gives properly encoded mainnet '''TxRef'''s and the decoded hex values (block height, transaction index) -==== Bitcoin TxRef (mainnet and testnet) ==== -The following list gives properly encoded Bitcoin mainnet TxRef's and the values in hex. (block height, transaction index) +* <tt>tx1:rqqq-qqqq-qwtv-vjr</tt>: <tt>(0x0, 0x0)</tt> +* <tt>tx1:rqqq-qqll-lj68-7n2</tt>: <tt>(0x0, 0x7FFF)</tt> +* <tt>tx1:r7ll-llqq-qats-vx9</tt>: <tt>(0xFFFFFF, 0x0)</tt> +* <tt>tx1:r7ll-llll-lp6m-78v</tt>: <tt>(0xFFFFFF, 0x7FFF)</tt> -* <tt>tx1:rqqq-qqqq-qmhu-qhp</tt>: <tt>(0x0, 0x0)</tt> -* <tt>tx1:rqqq-qqll-l8xh-jkg</tt>: <tt>(0x0, 0x7FFF)</tt> -* <tt>tx1:r7ll-llqq-qghq-qr8</tt>: <tt>(0xFFFFFF, 0x0)</tt> -* <tt>tx1:r7ll-llll-l5xt-jzw</tt>: <tt>(0xFFFFFF, 0x7FFF)</tt> +The following list gives properly encoded testnet '''TxRef'''s and the decoded hex values (block height, transaction index) -The following list gives properly encoded Bitcoin testnet TxRef's and the values in hex. (block height, transaction index) +* <tt>txtest1:xqqq-qqqq-qrrd-ksa</tt>: <tt>(0x0, 0x0)</tt> +* <tt>txtest1:xqqq-qqll-lljx-y35</tt>: <tt>(0x0, 0x7FFF)</tt> +* <tt>txtest1:x7ll-llqq-qsr3-kym</tt>: <tt>(0xFFFFFF, 0x0)</tt> +* <tt>txtest1:x7ll-llll-lvj6-y9j</tt>: <tt>(0xFFFFFF, 0x7FFF)</tt> -* <tt>txtest1:xqqq-qqqq-qkla-64l</tt>: <tt>(0x0, 0x0)</tt> -* <tt>txtest1:xqqq-qqll-l2wk-g5k</tt>: <tt>(0x0, 0x7FFF)</tt> -* <tt>txtest1:x7ll-llqq-q9lp-6pe</tt>: <tt>(0xFFFFFF, 0x0)</tt> -* <tt>txtest1:x7ll-llll-lew2-gqs</tt>: <tt>(0xFFFFFF, 0x7FFF)</tt> +The following list gives valid (sometimes strangely formatted) '''TxRef'''s and the decoded values (block height, transaction index)* +* <tt>tx1:r29u-mqjx-putt-3p0</tt>: <tt>(456789, 1234)</tt> +* <tt>TX1R29UMQJXPUTT3P0</tt>: <tt>(456789, 1234)</tt> +* <tt>tx1 r29u mqjx putt 3p0</tt>: <tt>(456789, 1234)</tt> +* <tt>tx1!r29u/mqj*x-putt^^3p0</tt>: <tt>(456789, 1234)</tt> -The following list gives valid (though strangely formatted) Bitcoin TxRef's and the values in hex. (block height, transaction index) -* <tt>tx1:rjk0-uqay-zsrw-hqe</tt>: <tt>(0x71F69, 0x89D)</tt> -* <tt>TX1RJK0UQAYZSRWHQE</tt>: <tt>(0x71F69, 0x89D)</tt> -* <tt>TX1RJK0--UQaYZSRw----HQE</tt>: <tt>(0x71F69, 0x89D)</tt> -* <tt>tx1 rjk0 uqay zsrw hqe</tt>: <tt>(0x71F69, 0x89D)</tt> -* <tt>tx1!rjk0\uqay*zsrw^^hqe</tt>: <tt>(0x71F69, 0x89D)</tt> +The following list gives invalid '''TxRef'''s and the reason for their invalidity. +* <tt>tx1:t7ll-llll-lcq3-aj4</tt>: Magic 0xB instead of 0x3. +* <tt>tx1:rlll-llll-lu9m-00x</tt>: Version 1 instead of 0. +* <tt>tx1:r7ll-llll-lqfu-gss2</tt>: Valid Bech32, but ten 5 bit unsigned chars instead of nine. +* <tt>tx1:r7ll-llll-rt5h-wz</tt>: Valid Bech32, but eight 5 bit unsigned chars instead of nine. +* <tt>tx1:r7ll-LLLL-lp6m-78v</tt>: Invalid Bech32 due to mixed case. Would decode correctly otherwise. -The following list gives invalid Bitcoin TxRef's and the reason for their invalidity. -* <tt>tx1:t7ll-llll-ldup-3hh</tt>: Magic 0xB instead of 0x3. <tt>(0xFFFFFF, 0x7FFF)</tt> -* <tt>tx1:rlll-llll-lfet-r2y</tt>: Version 1 instead of 0. <tt>(0xFFFFFF, 0x7FFF)</tt> -* <tt>tx1:rjk0-u5ng-gghq-fkg7</tt>: Valid Bech32, but 10x5bit packages instead of 8. -* <tt>tx1:rjk0-u5qd-s43z</tt>: Valid Bech32, but 6x5bit packages instead of 8. +==== TxRef with Outpoints ==== +The following list gives properly encoded mainnet '''TxRef'''s with Outpoints and the decoded values (block height, transaction index, outpoint index) -==== Bitcoin TxRef with Outpoints (mainnet and testnet) ==== -The following list gives properly encoded Bitcoin mainnet TxRef's with Outpoints and the values in hex. (block height, transaction index, TXO index) +* <tt>tx1:yqqq-qqqq-qqqq-rvum-0c</tt>: <tt>(0x0, 0x0, 0x0)</tt> +* <tt>tx1:yqqq-qqll-lqqq-en8x-05</tt>: <tt>(0x0, 0x7FFF, 0x0)</tt> +* <tt>tx1:y7ll-llqq-qqqq-ggjg-w6</tt>: <tt>(0xFFFFFF, 0x0, 0x0)</tt> +* <tt>tx1:y7ll-llll-lqqq-jhf4-wk</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x0)</tt> -* <tt>tx1:yqqq-qqqq-qqqq-ksvh-26</tt>: <tt>(0x0, 0x0, 0x0)</tt> -* <tt>tx1:yqqq-qqll-lqqq-v0h2-2k</tt>: <tt>(0x0, 0x7FFF, 0x0)</tt> -* <tt>tx1:y7ll-llqq-qqqq-a5zy-tc</tt>: <tt>(0xFFFFFF, 0x0, 0x0)</tt> -* <tt>tx1:y7ll-llll-lqqq-8tee-t5</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x0)</tt> +* <tt>tx1:yqqq-qqqq-qpqq-pw4v-kq</tt>: <tt>(0x0, 0x0, 0x1)</tt> +* <tt>tx1:yqqq-qqll-lpqq-m3w3-kv</tt>: <tt>(0x0, 0x7FFF, 0x1)</tt> +* <tt>tx1:y7ll-llqq-qpqq-22ml-hz</tt>: <tt>(0xFFFFFF, 0x0, 0x1)</tt> +* <tt>tx1:y7ll-llll-lpqq-s4qz-hw</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x1)</tt> -* <tt>tx1:yqqq-qqqq-qpqq-5j9q-nz</tt>: <tt>(0x0, 0x0, 0x1)</tt> -* <tt>tx1:yqqq-qqll-lpqq-wd7a-nw</tt>: <tt>(0x0, 0x7FFF, 0x1)</tt> -* <tt>tx1:y7ll-llqq-qpqq-lktn-jq</tt>: <tt>(0xFFFFFF, 0x0, 0x1)</tt> -* <tt>tx1:y7ll-llll-lpqq-9fsw-jv</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x1)</tt> +* <tt>tx1:y29u-mqjx-ppqq-sfp2-tt</tt>: <tt>(456789, 1234, 1)</tt> -* <tt>tx1:yjk0-uqay-zrfq-g2cg-t8</tt>: <tt>(0x71F69, 0x89D, 0x123)</tt> -* <tt>tx1:yjk0-uqay-zu4x-nk6u-pc</tt>: <tt>(0x71F69, 0x89D, 0x1ABC)</tt> -The following list gives properly encoded Bitcoin testnet TxRef's with Outpoints and the values in hex. (block height, transaction index, TXO index) +The following list gives properly encoded testnet '''TxRef'''s with Outpoints and the decoded values (block height, transaction index, outpoint index) -* <tt>txtest1:8qqq-qqqq-qqqq-cgru-fa</tt>: <tt>(0x0, 0x0, 0x0)</tt> -* <tt>txtest1:8qqq-qqll-lqqq-zhcp-f3</tt>: <tt>(0x0, 0x7FFF, 0x0)</tt> -* <tt>txtest1:87ll-llqq-qqqq-nvd0-gl</tt>: <tt>(0xFFFFFF, 0x0, 0x0)</tt> -* <tt>txtest1:87ll-llll-lqqq-fnkj-gn</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x0)</tt> +* <tt>txtest1:8qqq-qqqq-qqqq-d5ns-vl</tt>: <tt>(0x0, 0x0, 0x0)</tt> +* <tt>txtest1:8qqq-qqll-lqqq-htgd-vn</tt>: <tt>(0x0, 0x7FFF, 0x0)</tt> +* <tt>txtest1:87ll-llqq-qqqq-xsar-da</tt>: <tt>(0xFFFFFF, 0x0, 0x0)</tt> +* <tt>txtest1:87ll-llll-lqqq-u0x7-d3</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x0)</tt> -* <tt>txtest1:8qqq-qqqq-qpqq-622t-s9</tt>: <tt>(0x0, 0x0, 0x1)</tt> -* <tt>txtest1:8qqq-qqll-lpqq-q43k-sf</tt>: <tt>(0x0, 0x7FFF, 0x1)</tt> -* <tt>txtest1:87ll-llqq-qpqq-3wyc-38</tt>: <tt>(0xFFFFFF, 0x0, 0x1)</tt> -* <tt>txtest1:87ll-llll-lpqq-t3l9-3t</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x1)</tt> +* <tt>txtest1:8qqq-qqqq-qpqq-0k68-48</tt>: <tt>(0x0, 0x0, 0x1)</tt> +* <tt>txtest1:8qqq-qqll-lpqq-4fp6-4t</tt>: <tt>(0x0, 0x7FFF, 0x1)</tt> +* <tt>txtest1:87ll-llqq-qpqq-yj55-59</tt>: <tt>(0xFFFFFF, 0x0, 0x1)</tt> +* <tt>txtest1:87ll-llll-lpqq-7d0f-5f</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x1)</tt> -* <tt>txtest1:8jk0-uqay-zrfq-xjhr-gq</tt>: <tt>(0x71F69, 0x89D, 0x123)</tt> -* <tt>txtest1:8jk0-uqay-zu4x-aw4h-zl</tt>: <tt>(0x71F69, 0x89D, 0x1ABC)</tt> +* <tt>txtest1:829u-mqjx-ppqq-73wp-gv</tt>: <tt>(456789, 1234, 1)</tt> -=== Bitcoin TxRef Payload Value Choice: === +=== TxRef Payload Value Choices: === Some calculations showing why we chose these particular bit-length of the block height and transaction index. ==== Block Height Value: ==== -24-bit: between 0, and 0xFFFFFF (16,777,216 blocks). +24 bits: value can be between 0, and 0xFFFFFF (16777216 blocks). -*There are ~52,500 blocks every year, leading to ~319 years of blocks addressable. -*Therefore before year 2328 this specification should be extended. (We think that we have plenty of time). +* In early April, 2021, there have been 677700 blocks +* There are roughly (365 days * 24 hours * 6 blocks / hour) = 52560 blocks every year, implying about (16777216 - 677700) / 52560 = 306 more years of addressable blocks. +* Some time before year 2327 this specification should be extended. ==== Tx Position Value: ==== -15-bit: between 0x0, and 0x7FFF. (32,768 transactions). +15 bits: value can be between 0x0, and 0x7FFF (32768 transactions). -*The ''realistic'' smallest Tx is 83 Bytes: Max 12047 tx in a block. +*The ''realistic'' smallest Tx is 83 Bytes for maximum 12047 tx in a block. **4B version + 1B tx_in count + 36B previous_output + 1B script length + 0B signature script + 4B sequence + 1B tx_out count + 8B amount + 1B script length + 23B pubkey script + 4B lock_time = 83B -*The ''extreme'' smallest Tx is 60 Byte's: Max 16665 tx in a block. +*The ''extreme'' smallest Tx is 60 Bytes for maximum 16665 tx in a block. **4B version + 1B tx_in count + 36B previous_output + 1B script length + 0B signature script + 4B sequence + 1B tx_out count + 8B amount + 1B script length + 0B pubkey script + 4B lock_time = 60B == Acknowledgements == diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 9f6ad41..9434ce6 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -74,13 +74,11 @@ Where: : Magic bytes which are ASCII for psbt <ref>'''Why use 4 bytes for psbt?''' The transaction format needed to start with a 5 byte header which uniquely identifies it. The first bytes were chosen to be the ASCII for psbt because that stands for -Partially Signed Bitcoin Transaction. </ref> followed by a separator of <tt>0xFF</tt> -<ref>'''Why Use a separator after the magic bytes?''' The separator +Partially Signed Bitcoin Transaction. </ref> followed by a separator of <tt>0xFF</tt><ref>'''Why Use a separator after the magic bytes?''' The separator is part of the 5 byte header for PSBT. This byte is a separator of <tt>0xff</tt> because this will cause any non-PSBT unserializer to fail to properly unserialize the PSBT as a normal transaction. Likewise, since the 5 byte header is fixed, no transaction -in the non-PSBT format will be able to be unserialized by a PSBT unserializer.</ref>. This integer must be serialized -in most significant byte order. +in the non-PSBT format will be able to be unserialized by a PSBT unserializer.</ref>. This integer must be serialized in most significant byte order. The currently defined global types are as follows: @@ -115,9 +113,75 @@ The currently defined global types are as follows: | The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key. | | -| 0 +| 0, 2 | 174 |- +| Transaction Version +| <tt>PSBT_GLOBAL_TX_VERSION = 0x02</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| The 32-bit little endian signed integer representing the version number of the transaction being created. Note that this is not the same as the PSBT version number specified by the PSBT_GLOBAL_VERSION field. +| 2 +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- +| Fallback Locktime +| <tt>PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime. +| +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- +| Input Count +| <tt>PSBT_GLOBAL_INPUT_COUNT = 0x04</tt> +| None +| No key data +| <tt><compact size uint></tt> +| Compact size unsigned integer representing the number of inputs in this PSBT. +| 2 +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- +| Output Count +| <tt>PSBT_GLOBAL_OUTPUT_COUNT = 0x05</tt> +| None +| No key data +| <tt><compact size uint></tt> +| Compact size unsigned integer representing the number of outputs in this PSBT. +| 2 +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- +| Transaction Modifiable Flags +| <tt>PSBT_GLOBAL_TX_MODIFIABLE = 0x06</tt> +| None +| No key data +| <tt><single byte boolean> <single byte boolean> <bitvector></tt> +| A single byte boolean (0 for False, 1 for True) representing whether inputs can be modified, followed by a single byte boolean representing whether outputs can be modified. +| +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- +| SIGHASH_SINGLE Inputs +| <tt>PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS = 0x07</tt> +| None +| No key data +| <tt><bit vector></tt> +| A bit vector representing which input indexes use SIGHASH_SINGLE. If the bit for an index is set to 1, then the input and output pair at that index are tied together with SIGHASH_SINGLE and must be moved together. +| +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- | PSBT Version Number | <tt>PSBT_GLOBAL_VERSION = 0xFB</tt> | None @@ -126,7 +190,7 @@ The currently defined global types are as follows: | The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0. | | -| 0 +| 0, 2 | 174 |- | Proprietary Use Type @@ -137,7 +201,7 @@ The currently defined global types are as follows: | Any value data as defined by the proprietary type user. | | -| 0 +| 0, 2 | 174 |} @@ -163,18 +227,18 @@ The currently defined per-input types are defined as follows: | The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref> | | -| 0 +| 0, 2 | 174 |- | Witness UTXO | <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt> | None | No key data -| <tt><64-bit uint> <scriptPubKeylen> <scriptPubKey></tt> +| <tt><64-bit int> <scriptPubKeylen> <scriptPubKey></tt> | The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt> | | -| 0 +| 0, 2 | 174 |- | Partial Signature @@ -185,7 +249,7 @@ The currently defined per-input types are defined as follows: | The signature as would be pushed to the stack from a scriptSig or witness. | | -| 0 +| 0, 2 | 174 |- | Sighash Type @@ -196,7 +260,7 @@ The currently defined per-input types are defined as follows: | The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature. | | -| 0 +| 0, 2 | 174 |- | Redeem Script @@ -207,7 +271,7 @@ The currently defined per-input types are defined as follows: | The redeemScript for this input if it has one. | | -| 0 +| 0, 2 | 174 |- | Witness Script @@ -218,7 +282,7 @@ The currently defined per-input types are defined as follows: | The witnessScript for this input if it has one. | | -| 0 +| 0, 2 | 174 |- | BIP 32 Derivation Path @@ -229,7 +293,7 @@ The currently defined per-input types are defined as follows: | The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input. | | -| 0 +| 0, 2 | 174 |- | Finalized scriptSig @@ -240,7 +304,7 @@ The currently defined per-input types are defined as follows: | The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. | | -| 0 +| 0, 2 | 174 |- | Finalized scriptWitness @@ -251,7 +315,7 @@ The currently defined per-input types are defined as follows: | The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. | | -| 0 +| 0, 2 | 174 |- | Proof-of-reserves commitment @@ -262,7 +326,7 @@ The currently defined per-input types are defined as follows: | The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. | | -| 0 +| 0, 2 | [[bip-0127.mediawiki|127]] |- | RIPEMD160 preimage @@ -273,7 +337,7 @@ The currently defined per-input types are defined as follows: | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>RIPEMD160</tt> algorithm | | -| 0 +| 0, 2 | 174 |- | SHA256 preimage @@ -284,7 +348,7 @@ The currently defined per-input types are defined as follows: | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm | | -| 0 +| 0, 2 | 174 |- | HASH160 preimage @@ -295,7 +359,7 @@ The currently defined per-input types are defined as follows: | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm followed by the <tt>RIPEMD160</tt> algorithm | | -| 0 +| 0, 2 | 174 |- | HASH256 preimage @@ -306,9 +370,64 @@ The currently defined per-input types are defined as follows: | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm twice | | -| 0 +| 0, 2 | 174 |- +| Previous TXID +| <tt>PSBT_IN_PREVIOUS_TXID = 0x0e</tt> +| None +| No key data +| <tt><txid></tt> +| 32 byte txid of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent. +| 2 +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- +| Spent Output Index +| <tt>PSBT_IN_OUTPUT_INDEX = 0x0f</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| 32 bit little endian integer representing the index of the output being spent in the transaction with the txid of PSBT_IN_PREVIOUS_TXID. +| 2 +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- +| Sequence Number +| <tt>PSBT_IN_SEQUENCE = 0x10</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| The 32 bit unsigned little endian integer for the sequence number of this input. If omitted, the sequence number is assumed to be the final sequence number (0xffffffff). +| +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- +| Required Time-based Locktime +| <tt>PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| 32 bit unsigned little endian integer greater than or equal to 500000000 representing the minimum Unix timestamp that this input requires to be set as the transaction's lock time. +| +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- +| Required Height-based Locktime +| <tt>PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12</tt> +| None +| No key data +| <tt><32-bit uiht></tt> +| 32 bit unsigned little endian integer less than 500000000 representing the minimum block height that this input requires to be set as the transaction's lock time. +| +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- | Proprietary Use Type | <tt>PSBT_IN_PROPRIETARY = 0xFC</tt> | <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> @@ -317,7 +436,7 @@ The currently defined per-input types are defined as follows: | Any value data as defined by the proprietary type user. | | -| 0 +| 0, 2 | 174 |} @@ -345,7 +464,7 @@ determine which outputs are change outputs and verify that the change is returni | The redeemScript for this output if it has one. | | -| 0 +| 0, 2 | 174 |- | Witness Script @@ -356,7 +475,7 @@ determine which outputs are change outputs and verify that the change is returni | The witnessScript for this output if it has one. | | -| 0 +| 0, 2 | 174 |- | BIP 32 Derivation Path @@ -367,9 +486,31 @@ determine which outputs are change outputs and verify that the change is returni | The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output. | | -| 0 +| 0, 2 | 174 |- +| Output Amount +| <tt>PSBT_OUT_AMOUNT = 0x03</tt> +| None +| No key data +| <tt><64-bit int></tt> +| 64 bit signed little endian integer representing the output's amount in satoshis. +| 2 +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- +| Output Script +| <tt>PSBT_OUT_SCRIPT = 0x03</tt> +| None +| No key data +| <tt><script></tt> +| The script for this output, also known as the scriptPubKey. Must be omitted in PSBTv0. Must be provided in PSBTv2. +| 2 +| 0 +| 2 +| [[bip-psb2.mediawiki|psbt2]] +|- | Proprietary Use Type | <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt> | <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> @@ -378,7 +519,7 @@ determine which outputs are change outputs and verify that the change is returni | Any value data as defined by the proprietary type user. | | -| 0 +| 0, 2 | 174 |} @@ -494,9 +635,9 @@ for input,i in enumerate(psbt.inputs): assert(sha256d(non_witness_utxo) == psbt.tx.input[i].prevout.hash) if redeemScript.exists: assert(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey == P2SH(redeemScript)) - sign_non_witness(redeemScript) + sign_non_witness(redeemScript, i) else: - sign_non_witness(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey) + sign_non_witness(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey, i) else if witness_utxo.exists: if redeemScript.exists: assert(witness_utxo.scriptPubKey == P2SH(redeemScript)) @@ -504,10 +645,10 @@ for input,i in enumerate(psbt.inputs): else: script = witness_utxo.scriptPubKey if IsP2WPKH(script): - sign_witness(P2PKH(script[2:22])) + sign_witness(P2PKH(script[2:22]), i) else if IsP2WSH(script): assert(script == P2WSH(witnessScript)) - sign_witness(witnessScript) + sign_witness(witnessScript, i) else: assert False </pre> @@ -687,6 +828,10 @@ The following are invalid PSBTs: ** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d06d57f8a8751ae00</pre> ** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnQbVf4qHUa4A</pre> +* Case: PSBT with unsigned tx serialized with witness serialization format +** Bytes in Hex: <pre>70736274ff01007802000000000101268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc78700b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000000000</pre> +** Base64 String: <pre>cHNidP8BAHgCAAAAAAEBJoFxNx7f8oXpN63upLN7eAAMBWbLs61kZBcTykIXG/YAAAAAAP7///8C09/1BQAAAAAZdqkU0MWZA8W6woaHYOkP1SGkZlqnZSCIrADh9QUAAAAAF6kUNUXm4zuDLEcFDyTT7rk8nAOUi8eHALMuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAAAA</pre> + The following are valid PSBTs: * Case: PSBT with one P2PKH input. Outputs are empty @@ -714,13 +859,21 @@ The following are valid PSBTs: ** Base64 String: <pre>cHNidP8BAFICAAAAAZ38ZijCbFiZ/hvT3DOGZb/VXXraEPYiCXPfLTht7BJ2AQAAAAD/////AfA9zR0AAAAAFgAUezoAv9wU0neVwrdJAdCdpu8TNXkAAAAATwEENYfPAto/0AiAAAAAlwSLGtBEWx7IJ1UXcnyHtOTrwYogP/oPlMAVZr046QADUbdDiH7h1A3DKmBDck8tZFmztaTXPa7I+64EcvO8Q+IM2QxqT64AAIAAAACATwEENYfPAto/0AiAAAABuQRSQnE5zXjCz/JES+NTzVhgXj5RMoXlKLQH+uP2FzUD0wpel8itvFV9rCrZp+OcFyLrrGnmaLbyZnzB1nHIPKsM2QxqT64AAIABAACAAAEBKwBlzR0AAAAAIgAgLFSGEmxJeAeagU4TcV1l82RZ5NbMre0mbQUIZFuvpjIBBUdSIQKdoSzbWyNWkrkVNq/v5ckcOrlHPY5DtTODarRWKZyIcSEDNys0I07Xz5wf6l0F1EFVeSe+lUKxYusC4ass6AIkwAtSriIGAp2hLNtbI1aSuRU2r+/lyRw6uUc9jkO1M4NqtFYpnIhxENkMak+uAACAAAAAgAAAAAAiBgM3KzQjTtfPnB/qXQXUQVV5J76VQrFi6wLhqyzoAiTACxDZDGpPrgAAgAEAAIAAAAAAACICA57/H1R6HV+S36K6evaslxpL0DukpzSwMVaiVritOh75EO3kXMUAAACAAAAAgAEAAIAA</pre> * Case: PSBT with unknown types in the inputs. -** Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0000</pre> -** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAA=</pre> +** Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f0000</pre> +** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAA=</pre> * Case: PSBT with `PSBT_GLOBAL_XPUB`. ** Bytes in Hex: <pre>70736274ff01009d0100000002710ea76ab45c5cb6438e607e59cc037626981805ae9e0dfd9089012abb0be5350100000000ffffffff190994d6a8b3c8c82ccbcfb2fba4106aa06639b872a8d447465c0d42588d6d670000000000ffffffff0200e1f505000000001976a914b6bc2c0ee5655a843d79afedd0ccc3f7dd64340988ac605af405000000001600141188ef8e4ce0449eaac8fb141cbf5a1176e6a088000000004f010488b21e039e530cac800000003dbc8a5c9769f031b17e77fea1518603221a18fd18f2b9a54c6c8c1ac75cbc3502f230584b155d1c7f1cd45120a653c48d650b431b67c5b2c13f27d7142037c1691027569c503100008000000080000000800001011f00e1f5050000000016001433b982f91b28f160c920b4ab95e58ce50dda3a4a220203309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c47304402202d704ced830c56a909344bd742b6852dccd103e963bae92d38e75254d2bb424502202d86c437195df46c0ceda084f2a291c3da2d64070f76bf9b90b195e7ef28f77201220603309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c1827569c5031000080000000800000008000000000010000000001011f00e1f50500000000160014388fb944307eb77ef45197d0b0b245e079f011de220202c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b11047304402204cb1fb5f869c942e0e26100576125439179ae88dca8a9dc3ba08f7953988faa60220521f49ca791c27d70e273c9b14616985909361e25be274ea200d7e08827e514d01220602c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b1101827569c5031000080000000800000008000000000000000000000220202d20ca502ee289686d21815bd43a80637b0698e1fbcdbe4caed445f6c1a0a90ef1827569c50310000800000008000000080000000000400000000</pre> ** Base64 String: <pre>cHNidP8BAJ0BAAAAAnEOp2q0XFy2Q45gflnMA3YmmBgFrp4N/ZCJASq7C+U1AQAAAAD/////GQmU1qizyMgsy8+y+6QQaqBmObhyqNRHRlwNQliNbWcAAAAAAP////8CAOH1BQAAAAAZdqkUtrwsDuVlWoQ9ea/t0MzD991kNAmIrGBa9AUAAAAAFgAUEYjvjkzgRJ6qyPsUHL9aEXbmoIgAAAAATwEEiLIeA55TDKyAAAAAPbyKXJdp8DGxfnf+oVGGAyIaGP0Y8rmlTGyMGsdcvDUC8jBYSxVdHH8c1FEgplPEjWULQxtnxbLBPyfXFCA3wWkQJ1acUDEAAIAAAACAAAAAgAABAR8A4fUFAAAAABYAFDO5gvkbKPFgySC0q5XljOUN2jpKIgIDMJaA8zx9446mpHzU7NZvH1pJdHxv+4gI7QkDkkPjrVxHMEQCIC1wTO2DDFapCTRL10K2hS3M0QPpY7rpLTjnUlTSu0JFAiAthsQ3GV30bAztoITyopHD2i1kBw92v5uQsZXn7yj3cgEiBgMwloDzPH3jjqakfNTs1m8fWkl0fG/7iAjtCQOSQ+OtXBgnVpxQMQAAgAAAAIAAAACAAAAAAAEAAAAAAQEfAOH1BQAAAAAWABQ4j7lEMH63fvRRl9CwskXgefAR3iICAsd3Fh9z0LfHK57nveZQKT0T8JW8dlatH1Jdpf0uELEQRzBEAiBMsftfhpyULg4mEAV2ElQ5F5rojcqKncO6CPeVOYj6pgIgUh9JynkcJ9cOJzybFGFphZCTYeJb4nTqIA1+CIJ+UU0BIgYCx3cWH3PQt8crnue95lApPRPwlbx2Vq0fUl2l/S4QsRAYJ1acUDEAAIAAAACAAAAAgAAAAAAAAAAAAAAiAgLSDKUC7iiWhtIYFb1DqAY3sGmOH7zb5MrtRF9sGgqQ7xgnVpxQMQAAgAAAAIAAAACAAAAAAAQAAAAA</pre> +* Case: PSBT with global unsigned tx that has 0 inputs and 0 outputs +** Bytes in Hex: <pre>70736274ff01000a0000000000000000000000</pre> +** Base64 String: <pre>cHNidP8BAAoAAAAAAAAAAAAAAA==</pre> + +* Case: PSBT with 0 inputs +** Bytes in Hex: <pre>70736274ff01004c020000000002d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000000</pre> +** Base64 String: <pre>cHNidP8BAEwCAAAAAALT3/UFAAAAABl2qRTQxZkDxbrChodg6Q/VIaRmWqdlIIisAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4ezLhMAAAAA</pre> + Fails Signer checks * Case: A Witness UTXO is provided for a non-witness input @@ -817,16 +970,16 @@ Given the above PSBT, a transaction extractor must create this Bitcoin transacti * Bytes in Hex: <pre>0200000000010258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd7500000000da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752aeffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d01000000232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f000400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00000000</pre> Given these two PSBTs with unknown key-value pairs: -* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f00</pre> -** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwA=</pre> +* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f00</pre> +** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwA=</pre> -* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f00</pre> -** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre> +* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708100f0102030405060708090a0b0c0d0e0f00</pre> +** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre> A combiner which orders keys lexicographically must produce the following PSBT: -* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f00</pre> -* Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8KDwECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PCg8BAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwoPAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre> +* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f00</pre> +* Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8K8AECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PCvABAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwrwAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre> ==Rationale== diff --git a/bip-0325.mediawiki b/bip-0325.mediawiki index 5a9f3f1..be4ad02 100644 --- a/bip-0325.mediawiki +++ b/bip-0325.mediawiki @@ -110,10 +110,6 @@ Other software need not add block signature validation code that they will not u Pull request at https://github.com/bitcoin/bitcoin/pull/18267 -== Acknowledgements == - -TODO - == References == # Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki index 1de7faa..b5a47d3 100644 --- a/bip-0340.mediawiki +++ b/bip-0340.mediawiki @@ -56,9 +56,7 @@ encodings and operations. '''Schnorr signature variant''' Elliptic Curve Schnorr signatures for message ''m'' and public key ''P'' generally involve a point ''R'', integers ''e'' and ''s'' picked by the signer, and the base point ''G'' which satisfy ''e = hash(R || m)'' and ''s⋅G = R + e⋅P''. Two formulations exist, depending on whether the signer reveals ''e'' or ''R'': # Signatures are pairs ''(e, s)'' that satisfy ''e = hash(s⋅G - e⋅P || m)''. This variant avoids minor complexity introduced by the encoding of the point ''R'' in the signature (see paragraphs "Encoding R and public key point P" and "Implicit Y coordinates" further below in this subsection). Moreover, revealing ''e'' instead of ''R'' allows for potentially shorter signatures: Whereas an encoding of ''R'' inherently needs about 32 bytes, the hash ''e'' can be tuned to be shorter than 32 bytes, and [http://www.neven.org/papers/schnorr.pdf a short hash of only 16 bytes suffices to provide SUF-CMA security at the target security level of 128 bits]. However, a major drawback of this optimization is that finding collisions in a short hash function is easy. This complicates the implementation of secure signing protocols in scenarios in which a group of mutually distrusting signers work together to produce a single joint signature (see Applications below). In these scenarios, which are not captured by the SUF-CMA model due its assumption of a single honest signer, a promising attack strategy for malicious co-signers is to find a collision in the hash function in order to obtain a valid signature on a message that an honest co-signer did not intend to sign. -# Signatures are pairs ''(R, s)'' that satisfy ''s⋅G = R + hash(R || m)⋅P''. This supports batch verification, as there are no elliptic curve operations inside the hashes. Batch verification enables significant speedups. - -[[File:bip-0340/speedup-batch.png|center|frame|This graph shows the ratio between the time it takes to verify ''n'' signatures individually and to verify a batch of ''n'' signatures. This ratio goes up logarithmically with the number of signatures, or in other words: the total time to verify ''n'' signatures grows with ''O(n / log n)''.]] +# Signatures are pairs ''(R, s)'' that satisfy ''s⋅G = R + hash(R || m)⋅P''. This supports batch verification, as there are no elliptic curve operations inside the hashes. Batch verification enables significant speedups.<ref>The speedup that results from batch verification can be demonstrated with the cryptography library [https://github.com/jonasnick/secp256k1/blob/schnorrsig-batch-verify/doc/speedup-batch.md libsecp256k1].</ref> Since we would like to avoid the fragility that comes with short hashes, the ''e'' variant does not provide significant advantages. We choose the ''R''-option, which supports batch verification. diff --git a/bip-0340/speedup-batch.png b/bip-0340/speedup-batch.png Binary files differdeleted file mode 100644 index fe672d4..0000000 --- a/bip-0340/speedup-batch.png +++ /dev/null diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 0f8d32a..586bb39 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -284,9 +284,7 @@ The reason for this is to increase leaf entropy and prevent an observer from lea == Test vectors == -Examples with creation transaction and spending transaction pairs, valid and invalid. - -Examples of preimage for sighashing for each of the sighash modes. +The test vectors used in the [https://github.com/bitcoin/bitcoin/blob/3820090bd619ac85ab35eff376c03136fe4a9f04/src/test/script_tests.cpp#L1718 Bitcoin Core unit test framework] can be found [https://github.com/bitcoin-core/qa-assets/blob/main/unit_test_data/script_assets_test.json?raw=true here]. == Rationale == @@ -294,7 +292,43 @@ Examples of preimage for sighashing for each of the sighash modes. == Deployment == -TODO +This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]]. + +For Bitcoin signet, these BIPs are always active. + +For Bitcoin mainnet and testnet3, these BIPs will be deployed by "version bits" with the name "taproot" and bit 2, using [[bip-0009.mediawiki|BIP9]] modified to use a lower threshold, with an additional ''min_activation_height'' parameter and replacing the state transition logic for the DEFINED, STARTED and LOCKED_IN states as follows: + + case DEFINED: + if (GetMedianTimePast(block.parent) >= starttime) { + return STARTED; + } + return DEFINED; + + case STARTED: + int count = 0; + walk = block; + for (i = 0; i < 2016; i++) { + walk = walk.parent; + if ((walk.nVersion & 0xE0000000) == 0x20000000 && ((walk.nVersion >> bit) & 1) == 1) { + count++; + } + } + if (count >= threshold) { + return LOCKED_IN; + } else if (GetMedianTimePast(block.parent) >= timeout) { + return FAILED; + } + return STARTED; + + case LOCKED_IN: + if (block.nHeight < min_activation_height) { + return LOCKED_IN; + } + return ACTIVE; + +For Bitcoin mainnet, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632 (expected approximately 12 November 2021). + +For Bitcoin testnet3, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1512 blocks (75%), and the min_activation_height is block 0. == Backwards compatibility == As a soft fork, older software will continue to operate without modification. diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki index 7e00a2e..87e07ae 100644 --- a/bip-0342.mediawiki +++ b/bip-0342.mediawiki @@ -133,8 +133,14 @@ In addition to changing the semantics of a number of opcodes, there are also som <references /> +==Deployment== + +This proposal is deployed identically to Taproot ([[bip-0341.mediawiki|BIP341]]). + ==Examples== +The Taproot ([[bip-0341.mediawiki|BIP341]]) test vectors also contain examples for Tapscript execution. + ==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://github.com/ajtowns/taproot-review structured reviews]. 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. + diff --git a/bip-0370.mediawiki b/bip-0370.mediawiki new file mode 100644 index 0000000..8dd557a --- /dev/null +++ b/bip-0370.mediawiki @@ -0,0 +1,305 @@ +<pre> + BIP: 370 + Layer: Applications + Title: PSBT Version 2 + Author: Andrew Chow <achow101@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0370 + Status: Draft + Type: Standards Track + Created: 2021-01-14 + License: BSD-2-Clause +</pre> + +==Introduction== + +===Abstract=== + +This document proposes a second version of the Partially Signed Bitcoin Transaction format +described in BIP 174 which allows for inputs and outputs to be added to the PSBT after creation. + +===Copyright=== + +This BIP is licensed under the 2-clause BSD license. + +===Motivation=== + +Partially Signed Bitcoin Transaction Version 0 as described in BIP 174 is unable to have new +inputs and outputs be added to the transaction. The fixed global unsigned transaction +cannot be changed which prevents any additional inputs or outputs to be added. +PSBT Version 2 is intended to rectify this problem. + +An additional benficial side effect is that all information for a given input or output will be +provided by its <tt><input-map></tt> or <tt><output-map></tt>. With Version 0, to retrieve +all of the information for an input or output, data would need to be found in two locations: +the <tt><input-map></tt>/<tt><output-map></tt> and the global unsigned transaction. PSBT +Version 2 now moves all related information to one place. + +==Specification== + +PSBT Version 2 (PSBTv2) only specifies new fields and field inclusion/exclusion requirements. + +<tt>PSBT_GLOBAL_UNSIGNED_TX</tt> must be excluded in PSBTv2. +<tt>PSBT_GLOBAL_VERSION</tt> must be included in PSBTv2 and set to version number 2<ref>'''What happened to version number 1?''' +Version number 1 is skipped because PSBT Version 0 has been colloquially referred to as version 1. Originally this BIP was to be +version 1, but because it has been colloquially referred to as version 2 during its design phrase, it was decided to change the +version number to 2 so that there would not be any confusion</ref>. + +The new global types for PSBT Version 2 are as follows: + +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><keydata></tt> Description +! <tt><valuedata></tt> +! <tt><valuedata></tt> Description +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +|- +| Transaction Version +| <tt>PSBT_GLOBAL_TX_VERSION = 0x02</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| The 32-bit little endian signed integer representing the version number of the transaction being created. Note that this is not the same as the PSBT version number specified by the PSBT_GLOBAL_VERSION field. +| 2 +| 0 +| 2 +|- +| Fallback Locktime +| <tt>PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime. +| +| 0 +| 2 +|- +| Input Count +| <tt>PSBT_GLOBAL_INPUT_COUNT = 0x04</tt> +| None +| No key data +| <tt><compact size uint></tt> +| Compact size unsigned integer representing the number of inputs in this PSBT. +| 2 +| 0 +| 2 +|- +| Output Count +| <tt>PSBT_GLOBAL_OUTPUT_COUNT = 0x05</tt> +| None +| No key data +| <tt><compact size uint></tt> +| Compact size unsigned integer representing the number of outputs in this PSBT. +| 2 +| 0 +| 2 +|- +| Transaction Modifiable Flags +| <tt>PSBT_GLOBAL_TX_MODIFIABLE = 0x06</tt> +| None +| No key data +| <tt><8-bit uint></tt> +| An 8 bit little endian unsigned integer as a bitfield for various transaction modification flags. Bit 0 is the Inputs Modifiable Flag and indicates whether inputs can be modified. Bit 1 is the Outputs Modifiable Flag and indicates whether outputs can be modified. Bit 2 is the Has SIGHASH_SINGLE flag and indicates whether the transaction has a SIGHASH_SINGLE signature who's input and output pairing must be preserved. Bit 2 essentially indicates that the Constructor must iterate the inputs to determine whether and how to add an input. +| +| 0 +| 2 +|} + +The new per-input types for PSBT Version 2 are defined as follows: + +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><keydata></tt> Description +! <tt><valuedata></tt> +! <tt><valuedata></tt> Description +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +|- +| Previous TXID +| <tt>PSBT_IN_PREVIOUS_TXID = 0x0e</tt> +| None +| No key data +| <tt><txid></tt> +| 32 byte txid of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent. +| 2 +| 0 +| 2 +|- +| Spent Output Index +| <tt>PSBT_IN_OUTPUT_INDEX = 0x0f</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| 32 bit little endian integer representing the index of the output being spent in the transaction with the txid of PSBT_IN_PREVIOUS_TXID. +| 2 +| 0 +| 2 +|- +| Sequence Number +| <tt>PSBT_IN_SEQUENCE = 0x10</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| The 32 bit unsigned little endian integer for the sequence number of this input. If omitted, the sequence number is assumed to be the final sequence number (0xffffffff). +| +| 0 +| 2 +|- +| Required Time-based Locktime +| <tt>PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| 32 bit unsigned little endian integer greater than or equal to 500000000 representing the minimum Unix timestamp that this input requires to be set as the transaction's lock time. +| +| 0 +| 2 +|- +| Required Height-based Locktime +| <tt>PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12</tt> +| None +| No key data +| <tt><32-bit uiht></tt> +| 32 bit unsigned little endian integer less than 500000000 representing the minimum block height that this input requires to be set as the transaction's lock time. +| +| 0 +| 2 +|} + +The new per-output types for PSBT Version 2 are defined as follows: + +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><keydata></tt> Description +! <tt><valuedata></tt> +! <tt><valuedata></tt> Description +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +|- +| Output Amount +| <tt>PSBT_OUT_AMOUNT = 0x03</tt> +| None +| No key data +| <tt><64-bit int></tt> +| 64 bit signed little endian integer representing the output's amount in satoshis. +| 2 +| 0 +| 2 +|- +| Output Script +| <tt>PSBT_OUT_SCRIPT = 0x03</tt> +| None +| No key data +| <tt><script></tt> +| The script for this output, also known as the scriptPubKey. Must be omitted in PSBTv0. Must be provided in PSBTv2. +| 2 +| 0 +| 2 +|} + +===Determining Lock Time=== + +The nLockTime field of a transaction is determined by inspecting the PSBT_GLOBAL_PREFERRED_LOCKTIME and each input's PSBT_IN_REQUIRED_TIME_LOCKTIME and PSBT_IN_REQUIRED_HEIGHT_LOCKTIME fields. +If none of the inputs have a PSBT_IN_REQUIRED_TIME_LOCKTIME and PSBT_IN_REQUIRED_HEIGHT_LOCKTIME, then PSBT_GLOBAL_PREFERRED_LOCKTIME must be used. +If PSBT_GLOBAL_PREFERRED_LOCKTIME is not provided, then it is assumed to be 0. + +If one or more inuts have a PSBT_IN_REQUIRED_TIME_LOCKTIME or PSBT_IN_REQUIRED_HEIGHT_LOCKTIME, then the field chosen is the one which is supported by all of the inputs. +This can be determined by looking at all of the inputs which specify a locktime in either of those fields, and choosing the field which is present in all of those inputs. +Inputs not specifying a lock time field can take both types of lock times, as can those that specify both. +The lock time chosen is then the maximum value of the chosen type of lock time. + +===Unique Identification=== + +PSBTv2s can be uniquely identified by constructing an unsigned transaction given the information provided in the PSBT and computing the transaction ID of that transaction. +Since PSBT_IN_SEQUENCE can be changed by Updaters and Combiners, the sequence number in this unsigned transaction must be set to 0 (not final, nor the sequence in PSBT_IN_SEQUENCE). +The lock time in this unsigned transaction must be computed as described previously. + +==Roles== + +PSBTv2 introduces new roles and modifies some existing roles. + +===Creator=== + +In PSBTv2, the Creator initializes the PSBT with 0 inputs and 0 outputs. +The PSBT version number is set to 2. The transaction version number must be set to at least 2. <ref>'''Why does the transaction version number need to be at least 2?''' The transaction version number is part of the validation rules for some features such as OP_CHECKSEQUENCEVERIFY. Since it is backwards compatible, and there are other ways to disable those features (e.g. through sequence numbers), it is easier to require transactions be able to support these features than to try to negotiate the transaction version number.</ref> +The Creator should also set PSBT_GLOBAL_PREFERRED_LOCKTIME. +If the Creator is not also a Constructor and will be giving the PSBT to others to add inputs and outputs, the PSBT_GLOBAL_TX_MODIFIABLE field must be present and and the Inputs Modifiable and Outputs Modifiable flags set appropriately. +If the Creator is a Constructor and no inputs and outputs will be added by other entities, PSBT_GLOBAL_TX_MODIFIABLE may be omitted. + +===Constructor=== + +This Constructor is only present for PSBTv2. +Once a Creator initializes the PSBT, a constructor will add inputs and outputs. +Before any input or output may be added, the constructor must check the PSBT_GLOBAL_TX_MODIFIABLE field. +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 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. +If the input has a required time based timelock, then PSBT_IN_REQUIRED_TIME_TIMELOCK must be set +If the input has a required height based timelock, then PSBT_IN_REQUIRED_HEIGHT_TIMELOCK must be set. +If an input has both types of timelocks, then both may be set. +In some cases, an input that can allow both types, but a particular branch supporting only one type of timelock will be taken, then the type of timelock that will be used can be the only one set. + +If an input being added specifies a required time lock, then the Constructor must iterate through all of the existing inputs and ensure that the time lock types are compatible. +Additionally, if during this iteration, it finds that any inputs have signatures, it must ensure that the newly added input does not change the transaction's locktime. +If the newly added input has an incompatible time lock, then it must not be added. +If it changes the transaction's locktime when there are existing signatures, it must not be added. + +If the Has SIGHASH_SINGLE flag is True, then the Constructor must iterate through the inputs and find the inputs which have signatures that use SIGHASH_SINGLE. +The same number of inputs and outputs must be added before those inputs and their corresponding outputs. + +A Constructor may choose to declare that no further inputs and outputs can be added to the transaction by setting the booleans in PSBT_GLOBAL_TX_MODIFIABLE to False or by removing this field entirely. + +A single entity is likely to be both a Creator and Constructor. + +===Updater=== + +For PSBTv2, an Updater can set the sequence number. + +===Signer=== + +For PSBTv2s, a signer must update the PSBT_GLOBAL_TX_MODIFIABLE field after signing inputs so that it accurately reflects the state of the PSBT. +If the Signer added a signature that does not use SIGHASH_ANYONECANPAY, the Input Modifiable flag must be set to False. +If the Signer added a signature that does not use SIGHASH_NONE, the Outputs Modifiable flag must be set to False. +If the Signer added a signature that uses SIGHASH_SINGLE, the Has SIGHASH_SINGLE flag must be set to True. + +===Transaction Extractor=== + +For PSBTv2s, the transaction is constructed using the PSBTv2 fields. +The lock time for this transaction is determined as described in the Determining Lock Time section. +The Extractor should produce a fully valid, network serialized transaction if all inputs are complete. + +==Backwards Compatibility== + +PSBTv2 shares the same gemeric format as PSBTv0 as defined in BIP 174. Parsers for PSBTv0 should +be able to deserialize PSBTv2 with only changes to support the new fields. + +However PSBTv2 is incompatible with PSBTv0, and vice versa due to the use of the PSBT_GLOBAL_VERSION. +This incompatibility is intentional so that PSBT_GLOBAL_UNSIGNED_TX could be removed in PSBTv2. +However it is possible to convert a PSBTv2 to a PSBTv0 by creating an unsigned +transaction from the PSBTv2 fields. + +==Test Vectors== + +TBD + +==Rationale== + +<references/> + +==Reference implementation== + +The reference implementation of the PSBT format is available at https://github.com/achow101/bitcoin/tree/psbt2. |
