diff options
| -rw-r--r-- | README.mediawiki | 26 | ||||
| -rw-r--r-- | bip-0008.mediawiki | 74 | ||||
| -rw-r--r-- | bip-0008/states.dot | 34 | ||||
| -rw-r--r-- | bip-0008/states.png | bin | 25677 -> 46310 bytes | |||
| -rw-r--r-- | bip-0008/states.svg | 173 | ||||
| -rw-r--r-- | bip-0009.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0039.mediawiki | 23 | ||||
| -rw-r--r-- | bip-0039/bip-0039-wordlists.md | 21 | ||||
| -rw-r--r-- | bip-0039/portuguese.txt | 2048 | ||||
| -rw-r--r-- | bip-0049.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0079.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0085.mediawiki | 61 | ||||
| -rw-r--r-- | bip-0114.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0119.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0124.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0135.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0141.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0155.mediawiki | 47 | ||||
| -rw-r--r-- | bip-0174.mediawiki | 688 | ||||
| -rw-r--r-- | bip-0322.mediawiki | 196 | ||||
| -rw-r--r-- | bip-0325.mediawiki | 27 | ||||
| -rw-r--r-- | bip-0340.mediawiki | 8 | ||||
| -rw-r--r-- | bip-0340/reference.py | 5 | ||||
| -rw-r--r-- | bip-0340/test-vectors.py | 2 | ||||
| -rw-r--r-- | bip-0341.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0342.mediawiki | 2 |
26 files changed, 2809 insertions, 646 deletions
diff --git a/README.mediawiki b/README.mediawiki index ca28339..b8f971b 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1,4 +1,4 @@ -People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list. After discussion, please open a PR. After copy-editing and acceptance, it will be published here. +People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (do <em>not</em> assign a number - read <a href="bip-0002.mediawiki">BIP 2</a> for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here. We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. @@ -398,7 +398,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Bustapay :: a practical coinjoin protocol | Ryan Havar | Informational -| Proposed +| Replaced |- | [[bip-0080.mediawiki|80]] | @@ -546,13 +546,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Thomas Kerin, Mark Friedenbach | Standard | Final -|- +|- style="background-color: #ffcfcf" | [[bip-0114.mediawiki|114]] | Consensus (soft fork) | Merkelized Abstract Syntax Tree | Johnson Lau | Standard -| Draft +| Rejected |- style="background-color: #ffcfcf" | [[bip-0115.mediawiki|115]] | Consensus (soft fork) @@ -616,13 +616,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Eric Lombrozo | Process | Active -|- +|- style="background-color: #ffcfcf" | [[bip-0124.mediawiki|124]] | Applications | Hierarchical Deterministic Script Templates | Eric Lombrozo, William Swanson | Informational -| Draft +| Rejected |- style="background-color: #ffffcf" | [[bip-0125.mediawiki|125]] | Applications @@ -679,13 +679,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Tom Zander | Standard | Rejected -|- +|- style="background-color: #ffcfcf" | [[bip-0135.mediawiki|135]] | | Generalized version bits voting | Sancho Panza | Informational -| Draft +| Rejected |- | [[bip-0136.mediawiki|136]] | Applications @@ -847,13 +847,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Pieter Wuille, Greg Maxwell | Informational | Final -|- style="background-color: #ffffcf" +|- style="background-color: #cfffcf" | [[bip-0174.mediawiki|174]] | Applications | Partially Signed Bitcoin Transaction Format | Andrew Chow | Standard -| Proposed +| Final |- | [[bip-0175.mediawiki|175]] | Applications @@ -938,13 +938,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Karl-Johan Alm | Standard | Draft -|- +|- style="background-color: #ffffcf" | [[bip-0325.mediawiki|325]] | Applications | Signet -| Karl-Johan Alm +| Karl-Johan Alm, Anthony Towns | Standard -| Draft +| Proposed |- | [[bip-0330.mediawiki|330]] | Peer Services diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 6fa8cea..d5cb191 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -37,8 +37,8 @@ Each soft fork deployment is specified by the following per-chain parameters (fu # The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number. # The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}. # The '''startheight''' specifies 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 either considered failed on all descendants of the block (but see the exception during '''FAILING''' state), or, if '''lockinontimeout'' is true, transitions to the '''LOCKED_IN''' state. -# The '''lockinontimeout''' boolean if set to true, will transition state to '''LOCKED_IN''' at timeoutheight if not already '''LOCKED_IN''' or '''ACTIVE'''. +# 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 '''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=== @@ -53,16 +53,18 @@ The following guidelines are suggested for selecting these parameters for a soft 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'''. + ===States=== With each block and soft fork, we associate a deployment state. The possible states are: # '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment. # '''STARTED''' for blocks at or beyond the startheight. -# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion, or for one retarget period after the timeout when '''lockinontimeout''' is true. +# '''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. -# '''FAILING''' for one retarget period after the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is false. -# '''FAILED''' for all blocks after the FAILING retarget period. +# '''FAILED''' for all blocks after the timeoutheight if LOCKED_IN is not reached. ===Bit flags=== @@ -77,19 +79,19 @@ for the purposes of this proposal, and support two future upgrades for different When a block nVersion does not have top bits 001, it is treated as if all bits are 0 for the purposes of deployments. -Miners must continue setting the bit in LOCKED_IN phase so uptake is visible and acknowledged. -Blocks without the applicable bit set are invalid during this period. -For flexibility, this rule does NOT require the top 3 bits to be set any particular way. +Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on consensus rules. ===New consensus rules=== The new consensus rules for each soft fork are enforced for each block that has ACTIVE state. +During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget period have already failed to signal, any further blocks that fail to signal are invalid. + ===State transitions=== <img src="bip-0008/states.png" align="middle"></img> -During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeoutheight''' is reached. +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'''. The genesis block has state DEFINED for each deployment, by definition. @@ -121,7 +123,8 @@ We remain in the initial state until we reach the start block height. After a period in the STARTED state, we tally the bits set, and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016). -If the threshold hasn't been met, and we reach the timeout, then we either transition to LOCKED_IN state anyway (if lockinontimeout is true), or we transition to FAILING. +If the threshold hasn't been met, lockinontimeout is true, and we are at the last period before the timeout, then we transition to MUST_SIGNAL. +If the threshold hasn't been met and we reach the timeout, we transition directly to FAILED. Note that a block's state never depends on its own nVersion; only on that of its ancestors. @@ -131,28 +134,22 @@ Note that a block's state never depends on its own nVersion; only on that of its for (i = 0; i < 2016; i++) { walk = walk.parent; if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) { - count++; + ++count; } } if (count >= threshold) { return LOCKED_IN; + } else if (lockinontimeout && block.height + 2016 >= timeoutheight) { + return MUST_SIGNAL; } else if (block.height >= timeoutheight) { - return (lockinontimeout == true) ? LOCKED_IN : FAILING; + return FAILED; } return STARTED; -If the deployment is not LOCKED_IN by the timeout (or '''lockinontimeout'''), it has a single retarget period during which it may still become active, only by unanimous signalling in every block. -This state exists such that if '''lockinontimeout''' is set to true later, it remains compatible with the original deployment. +If we have finished a period of MUST_SIGNAL, we transition directly to LOCKED_IN. - case FAILING: - walk = block; - for (i = 0; i < 2016; i++) { - walk = walk.parent; - if (walk.nVersion & 0xE0000000 == 0x20000000 && ((walk.nVersion >> bit) & 1) != 1) { - return FAILED; - } - } - return ACTIVE; + case MUST_SIGNAL: + return LOCKED_IN; After a retarget period of LOCKED_IN, we automatically transition to ACTIVE. @@ -178,6 +175,32 @@ current retarget period (i.e. up to and including its ancestor with height block it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016 block, indexed by its parent. +===Mandatory signalling=== + +Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal as required. For example: + + if (GetStateForBlock(block) == MUST_SIGNAL) { + int nonsignal = 0; + int count = 1 + (block.nHeight % 2016); + walk = block; + while (count > 0) { + --count; + if ((walk.nVersion & 0xE0000000) != 0x20000000 || ((walk.nVersion >> bit) & 1) != 1) { + ++nonsignal; + if (nonsignal + threshold > 2016) { + return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal"); + } + } else if (nonsignal == 0) { + break; + } + walk = walk.parent; + } + } + +Implementations should be careful not to ban peers that send blocks that are invalid due to not signalling (or blocks that build on those blocks), as that would allow an incompatible chain that is only briefly longer than the compliant chain to cause a split of the p2p network. If that occurred, nodes that have not set ''lockinontimeout'' may not see new blocks in the compliant chain, and thus not reorg to it at the point when it has more work, and would thus not be following the valid chain with the most work. + +Implementations with ''lockinontimeout'' set to true may potentially follow a lower work chain than nodes with ''lockinontimeout'' set to false for an extended period. In order for this not to result in a net split nodes with ''lockinontimeout'' set to true, those nodes may need to preferentially connect to each other. Deployments proposing that implementations set ''lockinontimeout'' to true should either use parameters that do not risk there being a higher work alternative chain, or specify a mechanism for implementations that support the deployment to preferentially peer with each other. + ===Warning mechanism=== To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state). @@ -211,7 +234,7 @@ The template Object is also extended: The "version" key of the template is retained, and used to indicate the server's preference of deployments. If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF]. Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". -Servers MUST set bits in "vbrequired" for deployments in LOCKED_IN state, to ensure blocks produced are valid. +Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL state, to ensure blocks produced are valid. 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. @@ -225,9 +248,8 @@ https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip8 ==Contrasted with BIP 9== -* The '''lockinontimeout''' flag is added. BIP 9 would only transition to the FAILED state when timeout was reached. +* The '''lockinontimeout''' flag is added, providing a way to guarantee transition to LOCKED_IN. * Block heights are used for the deployment monotonic clock, rather than median-time-past. -* The last-ditch effort during a new FAILING state is added to allow '''lockinontimeout''' to be safely set after the initial deployment. ==Backwards compatibility== diff --git a/bip-0008/states.dot b/bip-0008/states.dot new file mode 100644 index 0000000..aa919ff --- /dev/null +++ b/bip-0008/states.dot @@ -0,0 +1,34 @@ +digraph { + rankdir=TD; + + node [style="rounded,filled,bold", shape=box, fixedsize=true, width=1.5, fontname="Arial"]; + + edge [weight = 100]; + "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"]; + "MUST_SIGNAL" -> "LOCKED_IN" [label="always"]; + + edge [weight = 1]; + "STARTED" -> "LOCKED_IN" [label="height < timeoutheight\nAND\nthreshold reached"]; + + "FAILED" -> "LOCKED_IN" [style=invis]; + + "DEFINED":sw -> "DEFINED":nw; + "STARTED":sw -> "STARTED":nw; + "ACTIVE":sw -> "ACTIVE":nw; + "FAILED":sw -> "FAILED":nw; + + "STARTED" [fillcolor="#a0a0ff"]; + "MUST_SIGNAL" [fillcolor="#a0a0ff"]; + "LOCKED_IN" [fillcolor="#ffffa0"]; + "ACTIVE" [fillcolor="#a0ffa0"]; + "FAILED" [fillcolor="#ffa0a0"]; + + { rank=same; "STARTED" "MUST_SIGNAL" } + { rank=same; "FAILED" "LOCKED_IN" } + { rank=sink; "ACTIVE" } +} + + diff --git a/bip-0008/states.png b/bip-0008/states.png Binary files differindex 76f6cb7..6477ed3 100644 --- a/bip-0008/states.png +++ b/bip-0008/states.png diff --git a/bip-0008/states.svg b/bip-0008/states.svg index f2e4b34..3503c34 100644 --- a/bip-0008/states.svg +++ b/bip-0008/states.svg @@ -1,55 +1,120 @@ -<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 848 464" width="905" height="495"> - <defs> - <style type="text/css"><![CDATA[ - rect { - fill: white; - stroke: black; - stroke-width: 1; - } - text { - fill: black; - } - svg>path { - stroke: black; - stroke-width: 2; - fill: none; - marker-end: url(#arrow); - } - ]]></style> - <marker id="arrow" markerWidth="13" markerHeight="13" refX="8" refY="6" orient="auto"> - <path d="M0,2 L0,11 L8,6 L0,2" style="fill: black;" /> - </marker> - </defs> - - <rect x="112" y="48" width="128" height="32"/> - <text x="176" y="72" font-size="20" text-anchor="middle">DEFINED</text> - <path d="M 128 80 a 24 32 0 1 1 0 -32"/><!-- loop --> - <path d="M 176 80 l 0 96"/> - <text x="182" y="128" font-size="12" text-anchor="start">startheight <= height</text> - <rect x="112" y="176" width="128" height="32"/> - <text x="176" y="200" font-size="20" text-anchor="middle">STARTED</text> - <path d="M 128 208 a 24 32 0 1 1 0 -32"/><!-- loop --> - <path d="M 176 208 l 0 96"/> - <text x="182" y="232" font-size="12" text-anchor="start">(lockinontimeout == false) AND (height < timeoutheight) AND (threshold reached)</text> - <text x="304" y="256" font-size="12" text-anchor="start">OR</text> - <text x="182" y="280" font-size="12" text-anchor="start">(lockinontimeout == true) AND ((height >= timeoutheight) OR (threshold reached))</text> - <rect x="112" y="304" width="128" height="32"/> - <text x="176" y="328" font-size="20" text-anchor="middle">LOCKED_IN</text> - <path d="M 176 336 l 0 48"/> - <text x="182" y="360" font-size="12" text-anchor="start">Always</text> - <rect x="112" y="384" width="128" height="32"/> - <text x="176" y="408" font-size="20" text-anchor="middle">ACTIVE</text> - <path d="M 128 416 a 24 32 0 1 1 0 -32"/><!-- loop --> - - <rect x="640" y="176" width="128" height="32"/> - <text x="704" y="200" font-size="20" text-anchor="middle">FAILING</text> - <path d="M 240 192 l 400 0"/> - <text x="408" y="184" font-size="12" text-anchor="middle">(lockinontimeout == false) AND (timeoutheight <= height)</text> - <path d="M 704 208 l 0 176"/> - <text x="720" y="296" font-size="12" text-anchor="start">NOT all blocks signal</text> - <path d="M 656 208 c 0 196 -416 176 -416 176"/> - <text x="544" y="352" font-size="12" text-anchor="start">all blocks signal</text> - <rect x="640" y="384" width="128" height="32"/> - <text x="704" y="408" font-size="20" text-anchor="middle">FAILED</text> - <path d="M 756 416 a 24 32 0 1 0 0 -32"/><!-- loop --> +<?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) + --> +<!-- 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"> +<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"/> +<!-- DEFINED --> +<g id="node1" class="node"> +<title>DEFINED</title> +<path fill="lightgrey" stroke="black" stroke-width="2" d="M114,-333.75C114,-333.75 30,-333.75 30,-333.75 24,-333.75 18,-327.75 18,-321.75 18,-321.75 18,-309.75 18,-309.75 18,-303.75 24,-297.75 30,-297.75 30,-297.75 114,-297.75 114,-297.75 120,-297.75 126,-303.75 126,-309.75 126,-309.75 126,-321.75 126,-321.75 126,-327.75 120,-333.75 114,-333.75"/> +<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"> +<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"/> +</g> +<!-- STARTED --> +<g id="node2" class="node"> +<title>STARTED</title> +<path fill="#a0a0ff" stroke="black" stroke-width="2" d="M114,-246.75C114,-246.75 30,-246.75 30,-246.75 24,-246.75 18,-240.75 18,-234.75 18,-234.75 18,-222.75 18,-222.75 18,-216.75 24,-210.75 30,-210.75 30,-210.75 114,-210.75 114,-210.75 120,-210.75 126,-216.75 126,-222.75 126,-222.75 126,-234.75 126,-234.75 126,-240.75 120,-246.75 114,-246.75"/> +<text text-anchor="middle" x="72" y="-225.05" font-family="Arial" font-size="14.00">STARTED</text> +</g> +<!-- DEFINED->STARTED --> +<g id="edge1" class="edge"> +<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> +</g> +<!-- STARTED->STARTED --> +<g id="edge9" 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"/> +</g> +<!-- 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> +</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> +</g> +<!-- FAILED --> +<g id="node4" class="node"> +<title>FAILED</title> +<path fill="#ffa0a0" stroke="black" stroke-width="2" d="M114,-129.75C114,-129.75 30,-129.75 30,-129.75 24,-129.75 18,-123.75 18,-117.75 18,-117.75 18,-105.75 18,-105.75 18,-99.75 24,-93.75 30,-93.75 30,-93.75 114,-93.75 114,-93.75 120,-93.75 126,-99.75 126,-105.75 126,-105.75 126,-117.75 126,-117.75 126,-123.75 120,-129.75 114,-129.75"/> +<text text-anchor="middle" x="72" y="-108.05" font-family="Arial" font-size="14.00">FAILED</text> +</g> +<!-- STARTED->FAILED --> +<g id="edge3" class="edge"> +<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> +</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> +</g> +<!-- STARTED->LOCKED_IN --> +<g id="edge6" 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> +</g> +<!-- MUST_SIGNAL->LOCKED_IN --> +<g id="edge5" 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> +</g> +<!-- FAILED->FAILED --> +<g id="edge11" 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 --> +<!-- 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> +</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> +</g> +<!-- ACTIVE->ACTIVE --> +<g id="edge10" 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"/> +</g> +</g> </svg> diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index a68bb80..f90919a 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -217,7 +217,7 @@ Soft forks right now are typically treated as booleans: they go from an inactive The failure timeout allows eventual reuse of bits even if a soft fork was never activated, so it's clear that the new use of the bit refers to a -new BIP. It's deliberately very course grained, to take into account +new BIP. It's deliberately very coarse-grained, to take into account reasonable development and deployment delays. There are unlikely to be enough failed proposals to cause a bit shortage. diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 2b95c51..08985ac 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -18,7 +18,7 @@ This BIP describes the implementation of a mnemonic code or mnemonic sentence -- a group of easy to remember words -- for the generation of deterministic wallets. -It consists of two parts: generating the mnemonic, and converting it into a +It consists of two parts: generating the mnemonic and converting it into a binary seed. This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods. @@ -29,7 +29,7 @@ handling of raw binary or hexadecimal representations of a wallet seed. The sentence could be written on paper or spoken over the telephone. This guide is meant to be a way to transport computer-generated randomness with -a human readable transcription. It's not a way to process user-created +a human-readable transcription. It's not a way to process user-created sentences (also known as brainwallets) into a wallet seed. ==Generating the mnemonic== @@ -46,7 +46,7 @@ as an index into a wordlist. Finally, we convert these numbers into words and use the joined words as a mnemonic sentence. The following table describes the relation between the initial entropy -length (ENT), the checksum length (CS) and the length of the generated mnemonic +length (ENT), the checksum length (CS), and the length of the generated mnemonic sentence (MS) in words. <pre> @@ -67,12 +67,12 @@ MS = (ENT + CS) / 11 An ideal wordlist has the following characteristics: a) smart selection of words - - the wordlist is created in such way that it's enough to type the first four + - the wordlist is created in such a way that it's enough to type the first four letters to unambiguously identify the word b) similar words avoided - word pairs like "build" and "built", "woman" and "women", or "quick" and "quickly" - not only make remembering the sentence difficult, but are also more error + not only make remembering the sentence difficult but are also more error prone and more difficult to guess c) sorted wordlists @@ -97,7 +97,7 @@ This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods. The conversion of the mnemonic sentence to a binary seed is completely independent -from generating the sentence. This results in rather simple code; there are no +from generating the sentence. This results in a rather simple code; there are no constraints on sentence structure and clients are free to implement their own wordlists or even whole sentence generators, allowing for flexibility in wordlists for typo detection or other purposes. @@ -113,7 +113,14 @@ will make the desired wallet available. ==Wordlists== -* [[bip-0039/bip-0039-wordlists.md|Moved to separate document]] +Since the vast majority of BIP39 wallets supports only the English wordlist, +it is '''strongly discouraged''' to use non-English wordlists for generating +the mnemonic sentences. + +If you still feel your application really needs to use a localized wordlist, +use one of the following instead of inventing your own. + +* [[bip-0039/bip-0039-wordlists.md|Wordlists]] ==Test vectors== @@ -168,7 +175,9 @@ Rust: Swift: * https://github.com/CikeQiu/CKMnemonic * https://github.com/yuzushioh/WalletKit +* https://github.com/pengpengliu/BIP39 * https://github.com/matter-labs/web3swift/blob/develop/Sources/web3swift/KeystoreManager/BIP39.swift +* https://github.com/zcash-hackworks/MnemonicSwift C++: * https://github.com/libbitcoin/libbitcoin-system/blob/master/include/bitcoin/system/wallet/mnemonic.hpp diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index 0940f35..f2c173c 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/bip-0039/bip-0039-wordlists.md @@ -9,6 +9,7 @@ * [French](french.txt) * [Italian](italian.txt) * [Czech](czech.txt) +* [Portuguese](portuguese.txt) ## Wordlists (Special Considerations) @@ -93,8 +94,24 @@ Words chosen using the following rules: 1. Words are 4-8 letters long. 2. Words can be uniquely determined typing the first 4 letters. 3. Only words containing all letters without diacritical marks. (It was the hardest task, because in one third of all Czech letters has diacritical marks.) -4. Only nouns, werbs and adverbs, no other word types. All words are in basic form. -5. No personal names or geografical names. +4. Only nouns, verbs and adverbs, no other word types. All words are in basic form. +5. No personal names or geographical names. 6. No very similar words with 1 letter of difference. 7. Words are sorting according English alphabet (Czech sorting has difference in "ch"). 8. No words already used in other language mnemonic sets (english, italian, french, spanish). Letters with diacritical marks from these sets are counted as analogous letters without diacritical marks. + +### Portuguese + +Credits: @alegotardo @bitmover-studio @brenorb @kuthullu @ninjastic @sabotag3x @Trimegistus + +1. Words can be uniquely determined typing the first 4 characters. +2. No accents or special characters. +3. No complex verb forms. +4. No plural words, unless there's no singular form. +5. No words with double spelling. +6. No words with the exact sound of another word with different spelling. +7. No offensive words. +8. No words already used in other language mnemonic sets. +9. The words which have not the same spelling in Brazil and in Portugal are excluded. +10. No words that remind negative/sad/bad things. +11. No very similar words with 1 letter of difference. diff --git a/bip-0039/portuguese.txt b/bip-0039/portuguese.txt new file mode 100644 index 0000000..4a89105 --- /dev/null +++ b/bip-0039/portuguese.txt @@ -0,0 +1,2048 @@ +abacate +abaixo +abalar +abater +abduzir +abelha +aberto +abismo +abotoar +abranger +abreviar +abrigar +abrupto +absinto +absoluto +absurdo +abutre +acabado +acalmar +acampar +acanhar +acaso +aceitar +acelerar +acenar +acervo +acessar +acetona +achatar +acidez +acima +acionado +acirrar +aclamar +aclive +acolhida +acomodar +acoplar +acordar +acumular +acusador +adaptar +adega +adentro +adepto +adequar +aderente +adesivo +adeus +adiante +aditivo +adjetivo +adjunto +admirar +adorar +adquirir +adubo +adverso +advogado +aeronave +afastar +aferir +afetivo +afinador +afivelar +aflito +afluente +afrontar +agachar +agarrar +agasalho +agenciar +agilizar +agiota +agitado +agora +agradar +agreste +agrupar +aguardar +agulha +ajoelhar +ajudar +ajustar +alameda +alarme +alastrar +alavanca +albergue +albino +alcatra +aldeia +alecrim +alegria +alertar +alface +alfinete +algum +alheio +aliar +alicate +alienar +alinhar +aliviar +almofada +alocar +alpiste +alterar +altitude +alucinar +alugar +aluno +alusivo +alvo +amaciar +amador +amarelo +amassar +ambas +ambiente +ameixa +amenizar +amido +amistoso +amizade +amolador +amontoar +amoroso +amostra +amparar +ampliar +ampola +anagrama +analisar +anarquia +anatomia +andaime +anel +anexo +angular +animar +anjo +anomalia +anotado +ansioso +anterior +anuidade +anunciar +anzol +apagador +apalpar +apanhado +apego +apelido +apertada +apesar +apetite +apito +aplauso +aplicada +apoio +apontar +aposta +aprendiz +aprovar +aquecer +arame +aranha +arara +arcada +ardente +areia +arejar +arenito +aresta +argiloso +argola +arma +arquivo +arraial +arrebate +arriscar +arroba +arrumar +arsenal +arterial +artigo +arvoredo +asfaltar +asilado +aspirar +assador +assinar +assoalho +assunto +astral +atacado +atadura +atalho +atarefar +atear +atender +aterro +ateu +atingir +atirador +ativo +atoleiro +atracar +atrevido +atriz +atual +atum +auditor +aumentar +aura +aurora +autismo +autoria +autuar +avaliar +avante +avaria +avental +avesso +aviador +avisar +avulso +axila +azarar +azedo +azeite +azulejo +babar +babosa +bacalhau +bacharel +bacia +bagagem +baiano +bailar +baioneta +bairro +baixista +bajular +baleia +baliza +balsa +banal +bandeira +banho +banir +banquete +barato +barbado +baronesa +barraca +barulho +baseado +bastante +batata +batedor +batida +batom +batucar +baunilha +beber +beijo +beirada +beisebol +beldade +beleza +belga +beliscar +bendito +bengala +benzer +berimbau +berlinda +berro +besouro +bexiga +bezerro +bico +bicudo +bienal +bifocal +bifurcar +bigorna +bilhete +bimestre +bimotor +biologia +biombo +biosfera +bipolar +birrento +biscoito +bisneto +bispo +bissexto +bitola +bizarro +blindado +bloco +bloquear +boato +bobagem +bocado +bocejo +bochecha +boicotar +bolada +boletim +bolha +bolo +bombeiro +bonde +boneco +bonita +borbulha +borda +boreal +borracha +bovino +boxeador +branco +brasa +braveza +breu +briga +brilho +brincar +broa +brochura +bronzear +broto +bruxo +bucha +budismo +bufar +bule +buraco +busca +busto +buzina +cabana +cabelo +cabide +cabo +cabrito +cacau +cacetada +cachorro +cacique +cadastro +cadeado +cafezal +caiaque +caipira +caixote +cajado +caju +calafrio +calcular +caldeira +calibrar +calmante +calota +camada +cambista +camisa +camomila +campanha +camuflar +canavial +cancelar +caneta +canguru +canhoto +canivete +canoa +cansado +cantar +canudo +capacho +capela +capinar +capotar +capricho +captador +capuz +caracol +carbono +cardeal +careca +carimbar +carneiro +carpete +carreira +cartaz +carvalho +casaco +casca +casebre +castelo +casulo +catarata +cativar +caule +causador +cautelar +cavalo +caverna +cebola +cedilha +cegonha +celebrar +celular +cenoura +censo +centeio +cercar +cerrado +certeiro +cerveja +cetim +cevada +chacota +chaleira +chamado +chapada +charme +chatice +chave +chefe +chegada +cheiro +cheque +chicote +chifre +chinelo +chocalho +chover +chumbo +chutar +chuva +cicatriz +ciclone +cidade +cidreira +ciente +cigana +cimento +cinto +cinza +ciranda +circuito +cirurgia +citar +clareza +clero +clicar +clone +clube +coado +coagir +cobaia +cobertor +cobrar +cocada +coelho +coentro +coeso +cogumelo +coibir +coifa +coiote +colar +coleira +colher +colidir +colmeia +colono +coluna +comando +combinar +comentar +comitiva +comover +complexo +comum +concha +condor +conectar +confuso +congelar +conhecer +conjugar +consumir +contrato +convite +cooperar +copeiro +copiador +copo +coquetel +coragem +cordial +corneta +coronha +corporal +correio +cortejo +coruja +corvo +cosseno +costela +cotonete +couro +couve +covil +cozinha +cratera +cravo +creche +credor +creme +crer +crespo +criada +criminal +crioulo +crise +criticar +crosta +crua +cruzeiro +cubano +cueca +cuidado +cujo +culatra +culminar +culpar +cultura +cumprir +cunhado +cupido +curativo +curral +cursar +curto +cuspir +custear +cutelo +damasco +datar +debater +debitar +deboche +debulhar +decalque +decimal +declive +decote +decretar +dedal +dedicado +deduzir +defesa +defumar +degelo +degrau +degustar +deitado +deixar +delator +delegado +delinear +delonga +demanda +demitir +demolido +dentista +depenado +depilar +depois +depressa +depurar +deriva +derramar +desafio +desbotar +descanso +desenho +desfiado +desgaste +desigual +deslize +desmamar +desova +despesa +destaque +desviar +detalhar +detentor +detonar +detrito +deusa +dever +devido +devotado +dezena +diagrama +dialeto +didata +difuso +digitar +dilatado +diluente +diminuir +dinastia +dinheiro +diocese +direto +discreta +disfarce +disparo +disquete +dissipar +distante +ditador +diurno +diverso +divisor +divulgar +dizer +dobrador +dolorido +domador +dominado +donativo +donzela +dormente +dorsal +dosagem +dourado +doutor +drenagem +drible +drogaria +duelar +duende +dueto +duplo +duquesa +durante +duvidoso +eclodir +ecoar +ecologia +edificar +edital +educado +efeito +efetivar +ejetar +elaborar +eleger +eleitor +elenco +elevador +eliminar +elogiar +embargo +embolado +embrulho +embutido +emenda +emergir +emissor +empatia +empenho +empinado +empolgar +emprego +empurrar +emulador +encaixe +encenado +enchente +encontro +endeusar +endossar +enfaixar +enfeite +enfim +engajado +engenho +englobar +engomado +engraxar +enguia +enjoar +enlatar +enquanto +enraizar +enrolado +enrugar +ensaio +enseada +ensino +ensopado +entanto +enteado +entidade +entortar +entrada +entulho +envergar +enviado +envolver +enxame +enxerto +enxofre +enxuto +epiderme +equipar +ereto +erguido +errata +erva +ervilha +esbanjar +esbelto +escama +escola +escrita +escuta +esfinge +esfolar +esfregar +esfumado +esgrima +esmalte +espanto +espelho +espiga +esponja +espreita +espumar +esquerda +estaca +esteira +esticar +estofado +estrela +estudo +esvaziar +etanol +etiqueta +euforia +europeu +evacuar +evaporar +evasivo +eventual +evidente +evoluir +exagero +exalar +examinar +exato +exausto +excesso +excitar +exclamar +executar +exemplo +exibir +exigente +exonerar +expandir +expelir +expirar +explanar +exposto +expresso +expulsar +externo +extinto +extrato +fabricar +fabuloso +faceta +facial +fada +fadiga +faixa +falar +falta +familiar +fandango +fanfarra +fantoche +fardado +farelo +farinha +farofa +farpa +fartura +fatia +fator +favorita +faxina +fazenda +fechado +feijoada +feirante +felino +feminino +fenda +feno +fera +feriado +ferrugem +ferver +festejar +fetal +feudal +fiapo +fibrose +ficar +ficheiro +figurado +fileira +filho +filme +filtrar +firmeza +fisgada +fissura +fita +fivela +fixador +fixo +flacidez +flamingo +flanela +flechada +flora +flutuar +fluxo +focal +focinho +fofocar +fogo +foguete +foice +folgado +folheto +forjar +formiga +forno +forte +fosco +fossa +fragata +fralda +frango +frasco +fraterno +freira +frente +fretar +frieza +friso +fritura +fronha +frustrar +fruteira +fugir +fulano +fuligem +fundar +fungo +funil +furador +furioso +futebol +gabarito +gabinete +gado +gaiato +gaiola +gaivota +galega +galho +galinha +galocha +ganhar +garagem +garfo +gargalo +garimpo +garoupa +garrafa +gasoduto +gasto +gata +gatilho +gaveta +gazela +gelado +geleia +gelo +gemada +gemer +gemido +generoso +gengiva +genial +genoma +genro +geologia +gerador +germinar +gesso +gestor +ginasta +gincana +gingado +girafa +girino +glacial +glicose +global +glorioso +goela +goiaba +golfe +golpear +gordura +gorjeta +gorro +gostoso +goteira +governar +gracejo +gradual +grafite +gralha +grampo +granada +gratuito +graveto +graxa +grego +grelhar +greve +grilo +grisalho +gritaria +grosso +grotesco +grudado +grunhido +gruta +guache +guarani +guaxinim +guerrear +guiar +guincho +guisado +gula +guloso +guru +habitar +harmonia +haste +haver +hectare +herdar +heresia +hesitar +hiato +hibernar +hidratar +hiena +hino +hipismo +hipnose +hipoteca +hoje +holofote +homem +honesto +honrado +hormonal +hospedar +humorado +iate +ideia +idoso +ignorado +igreja +iguana +ileso +ilha +iludido +iluminar +ilustrar +imagem +imediato +imenso +imersivo +iminente +imitador +imortal +impacto +impedir +implante +impor +imprensa +impune +imunizar +inalador +inapto +inativo +incenso +inchar +incidir +incluir +incolor +indeciso +indireto +indutor +ineficaz +inerente +infantil +infestar +infinito +inflamar +informal +infrator +ingerir +inibido +inicial +inimigo +injetar +inocente +inodoro +inovador +inox +inquieto +inscrito +inseto +insistir +inspetor +instalar +insulto +intacto +integral +intimar +intocado +intriga +invasor +inverno +invicto +invocar +iogurte +iraniano +ironizar +irreal +irritado +isca +isento +isolado +isqueiro +italiano +janeiro +jangada +janta +jararaca +jardim +jarro +jasmim +jato +javali +jazida +jejum +joaninha +joelhada +jogador +joia +jornal +jorrar +jovem +juba +judeu +judoca +juiz +julgador +julho +jurado +jurista +juro +justa +labareda +laboral +lacre +lactante +ladrilho +lagarta +lagoa +laje +lamber +lamentar +laminar +lampejo +lanche +lapidar +lapso +laranja +lareira +largura +lasanha +lastro +lateral +latido +lavanda +lavoura +lavrador +laxante +lazer +lealdade +lebre +legado +legendar +legista +leigo +leiloar +leitura +lembrete +leme +lenhador +lentilha +leoa +lesma +leste +letivo +letreiro +levar +leveza +levitar +liberal +libido +liderar +ligar +ligeiro +limitar +limoeiro +limpador +linda +linear +linhagem +liquidez +listagem +lisura +litoral +livro +lixa +lixeira +locador +locutor +lojista +lombo +lona +longe +lontra +lorde +lotado +loteria +loucura +lousa +louvar +luar +lucidez +lucro +luneta +lustre +lutador +luva +macaco +macete +machado +macio +madeira +madrinha +magnata +magreza +maior +mais +malandro +malha +malote +maluco +mamilo +mamoeiro +mamute +manada +mancha +mandato +manequim +manhoso +manivela +manobrar +mansa +manter +manusear +mapeado +maquinar +marcador +maresia +marfim +margem +marinho +marmita +maroto +marquise +marreco +martelo +marujo +mascote +masmorra +massagem +mastigar +matagal +materno +matinal +matutar +maxilar +medalha +medida +medusa +megafone +meiga +melancia +melhor +membro +memorial +menino +menos +mensagem +mental +merecer +mergulho +mesada +mesclar +mesmo +mesquita +mestre +metade +meteoro +metragem +mexer +mexicano +micro +migalha +migrar +milagre +milenar +milhar +mimado +minerar +minhoca +ministro +minoria +miolo +mirante +mirtilo +misturar +mocidade +moderno +modular +moeda +moer +moinho +moita +moldura +moleza +molho +molinete +molusco +montanha +moqueca +morango +morcego +mordomo +morena +mosaico +mosquete +mostarda +motel +motim +moto +motriz +muda +muito +mulata +mulher +multar +mundial +munido +muralha +murcho +muscular +museu +musical +nacional +nadador +naja +namoro +narina +narrado +nascer +nativa +natureza +navalha +navegar +navio +neblina +nebuloso +negativa +negociar +negrito +nervoso +neta +neural +nevasca +nevoeiro +ninar +ninho +nitidez +nivelar +nobreza +noite +noiva +nomear +nominal +nordeste +nortear +notar +noticiar +noturno +novelo +novilho +novo +nublado +nudez +numeral +nupcial +nutrir +nuvem +obcecado +obedecer +objetivo +obrigado +obscuro +obstetra +obter +obturar +ocidente +ocioso +ocorrer +oculista +ocupado +ofegante +ofensiva +oferenda +oficina +ofuscado +ogiva +olaria +oleoso +olhar +oliveira +ombro +omelete +omisso +omitir +ondulado +oneroso +ontem +opcional +operador +oponente +oportuno +oposto +orar +orbitar +ordem +ordinal +orfanato +orgasmo +orgulho +oriental +origem +oriundo +orla +ortodoxo +orvalho +oscilar +ossada +osso +ostentar +otimismo +ousadia +outono +outubro +ouvido +ovelha +ovular +oxidar +oxigenar +pacato +paciente +pacote +pactuar +padaria +padrinho +pagar +pagode +painel +pairar +paisagem +palavra +palestra +palheta +palito +palmada +palpitar +pancada +panela +panfleto +panqueca +pantanal +papagaio +papelada +papiro +parafina +parcial +pardal +parede +partida +pasmo +passado +pastel +patamar +patente +patinar +patrono +paulada +pausar +peculiar +pedalar +pedestre +pediatra +pedra +pegada +peitoral +peixe +pele +pelicano +penca +pendurar +peneira +penhasco +pensador +pente +perceber +perfeito +pergunta +perito +permitir +perna +perplexo +persiana +pertence +peruca +pescado +pesquisa +pessoa +petiscar +piada +picado +piedade +pigmento +pilastra +pilhado +pilotar +pimenta +pincel +pinguim +pinha +pinote +pintar +pioneiro +pipoca +piquete +piranha +pires +pirueta +piscar +pistola +pitanga +pivete +planta +plaqueta +platina +plebeu +plumagem +pluvial +pneu +poda +poeira +poetisa +polegada +policiar +poluente +polvilho +pomar +pomba +ponderar +pontaria +populoso +porta +possuir +postal +pote +poupar +pouso +povoar +praia +prancha +prato +praxe +prece +predador +prefeito +premiar +prensar +preparar +presilha +pretexto +prevenir +prezar +primata +princesa +prisma +privado +processo +produto +profeta +proibido +projeto +prometer +propagar +prosa +protetor +provador +publicar +pudim +pular +pulmonar +pulseira +punhal +punir +pupilo +pureza +puxador +quadra +quantia +quarto +quase +quebrar +queda +queijo +quente +querido +quimono +quina +quiosque +rabanada +rabisco +rachar +racionar +radial +raiar +rainha +raio +raiva +rajada +ralado +ramal +ranger +ranhura +rapadura +rapel +rapidez +raposa +raquete +raridade +rasante +rascunho +rasgar +raspador +rasteira +rasurar +ratazana +ratoeira +realeza +reanimar +reaver +rebaixar +rebelde +rebolar +recado +recente +recheio +recibo +recordar +recrutar +recuar +rede +redimir +redonda +reduzida +reenvio +refinar +refletir +refogar +refresco +refugiar +regalia +regime +regra +reinado +reitor +rejeitar +relativo +remador +remendo +remorso +renovado +reparo +repelir +repleto +repolho +represa +repudiar +requerer +resenha +resfriar +resgatar +residir +resolver +respeito +ressaca +restante +resumir +retalho +reter +retirar +retomada +retratar +revelar +revisor +revolta +riacho +rica +rigidez +rigoroso +rimar +ringue +risada +risco +risonho +robalo +rochedo +rodada +rodeio +rodovia +roedor +roleta +romano +roncar +rosado +roseira +rosto +rota +roteiro +rotina +rotular +rouco +roupa +roxo +rubro +rugido +rugoso +ruivo +rumo +rupestre +russo +sabor +saciar +sacola +sacudir +sadio +safira +saga +sagrada +saibro +salada +saleiro +salgado +saliva +salpicar +salsicha +saltar +salvador +sambar +samurai +sanar +sanfona +sangue +sanidade +sapato +sarda +sargento +sarjeta +saturar +saudade +saxofone +sazonal +secar +secular +seda +sedento +sediado +sedoso +sedutor +segmento +segredo +segundo +seiva +seleto +selvagem +semanal +semente +senador +senhor +sensual +sentado +separado +sereia +seringa +serra +servo +setembro +setor +sigilo +silhueta +silicone +simetria +simpatia +simular +sinal +sincero +singular +sinopse +sintonia +sirene +siri +situado +soberano +sobra +socorro +sogro +soja +solda +soletrar +solteiro +sombrio +sonata +sondar +sonegar +sonhador +sono +soprano +soquete +sorrir +sorteio +sossego +sotaque +soterrar +sovado +sozinho +suavizar +subida +submerso +subsolo +subtrair +sucata +sucesso +suco +sudeste +sufixo +sugador +sugerir +sujeito +sulfato +sumir +suor +superior +suplicar +suposto +suprimir +surdina +surfista +surpresa +surreal +surtir +suspiro +sustento +tabela +tablete +tabuada +tacho +tagarela +talher +talo +talvez +tamanho +tamborim +tampa +tangente +tanto +tapar +tapioca +tardio +tarefa +tarja +tarraxa +tatuagem +taurino +taxativo +taxista +teatral +tecer +tecido +teclado +tedioso +teia +teimar +telefone +telhado +tempero +tenente +tensor +tentar +termal +terno +terreno +tese +tesoura +testado +teto +textura +texugo +tiara +tigela +tijolo +timbrar +timidez +tingido +tinteiro +tiragem +titular +toalha +tocha +tolerar +tolice +tomada +tomilho +tonel +tontura +topete +tora +torcido +torneio +torque +torrada +torto +tostar +touca +toupeira +toxina +trabalho +tracejar +tradutor +trafegar +trajeto +trama +trancar +trapo +traseiro +tratador +travar +treino +tremer +trepidar +trevo +triagem +tribo +triciclo +tridente +trilogia +trindade +triplo +triturar +triunfal +trocar +trombeta +trova +trunfo +truque +tubular +tucano +tudo +tulipa +tupi +turbo +turma +turquesa +tutelar +tutorial +uivar +umbigo +unha +unidade +uniforme +urologia +urso +urtiga +urubu +usado +usina +usufruir +vacina +vadiar +vagaroso +vaidoso +vala +valente +validade +valores +vantagem +vaqueiro +varanda +vareta +varrer +vascular +vasilha +vassoura +vazar +vazio +veado +vedar +vegetar +veicular +veleiro +velhice +veludo +vencedor +vendaval +venerar +ventre +verbal +verdade +vereador +vergonha +vermelho +verniz +versar +vertente +vespa +vestido +vetorial +viaduto +viagem +viajar +viatura +vibrador +videira +vidraria +viela +viga +vigente +vigiar +vigorar +vilarejo +vinco +vinheta +vinil +violeta +virada +virtude +visitar +visto +vitral +viveiro +vizinho +voador +voar +vogal +volante +voleibol +voltagem +volumoso +vontade +vulto +vuvuzela +xadrez +xarope +xeque +xeretar +xerife +xingar +zangado +zarpar +zebu +zelador +zombar +zoologia +zumbido diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki index 0029003..7d8d2c7 100644 --- a/bip-0049.mediawiki +++ b/bip-0049.mediawiki @@ -26,7 +26,7 @@ will detect the accounts and handle them appropriately. ===Considerations=== Two generally different approaches are possible for current BIP44 capable wallets: -1) Allow the user to use the same account(s) that they already uses, but add segregated witness encoded addresses to it. +1) Allow the user to use the same account(s) that they already use, but add segregated witness encoded addresses to it. 1.1) Use the same public keys as defined in BIP44, but in addition to the normal P2PKH address also derive the P2SH address from it. diff --git a/bip-0079.mediawiki b/bip-0079.mediawiki index c8f2104..797c8f1 100644 --- a/bip-0079.mediawiki +++ b/bip-0079.mediawiki @@ -68,7 +68,7 @@ The template transaction should be sent to the receiver via an HTTP POST to the The receiver is then responsible for validating the template transaction. If there is a problem with the transaction, or the receiver is generally unhappy with the transaction (e.g. fees are too small) the HTTP response code of 422 should be used and a human-readable string containing information on why which can be directly given to the user. -Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefor assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid. +Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefore assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid. === Contributed Input Choice === @@ -118,7 +118,7 @@ For anyone wanting to implement bustapay payments, here are some notes for recei == Backwards Compatibility == -Bustapay is an optional payment protocol and therefor has no backwards compatibility concerns. It in fact can only be supported in addition to normal transaction processing, as falling back to a normal bitcoin transaction is a required behavior. +Bustapay is an optional payment protocol and therefore has no backwards compatibility concerns. It in fact can only be supported in addition to normal transaction processing, as falling back to a normal bitcoin transaction is a required behavior. == Credits == diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 7c4cbca..cbd3a2a 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -25,6 +25,8 @@ As HD keychains are essentially derived from initial entropy, this proposal prov ==Definitions== +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + The terminology related to keychains used in the wild varies widely, for example `seed` has various different meanings. In this document we define the terms # '''BIP32 root key''' is the root extended private key that is represented as the top root of the keychain in BIP32. @@ -69,19 +71,42 @@ OUTPUT * DERIVED KEY=503776919131758bb7de7beb6c0ae24894f4ec042c26032890c29359216e21ba * DERIVED ENTROPY=70c6e3e8ebee8dc4c0dbba66076819bb8c09672527c4277ca8729532ad711872218f826919f6b67218adde99018a6df9095ab2b58d803b5b93ec9802085a690e +==BIP85-DRNG== + +BIP85-DRNG-SHAKE256 is a deterministic random number generator for cryptographic functions that require deterministic outputs, but where the input to that function requires more than the 64 bytes provided by BIP85's HMAC output. BIP85-DRNG-SHAKE256 uses BIP85 to seed a SHAKE256 stream (from the SHA-3 standard). The input must be exactly 64 bytes long (from the BIP85 HMAC output). + +RSA key generation is an example of a function that requires orders of magnitude more than 64 bytes of random input. Further, it is not possible to precalculate the amount of random input required until the function has completed. + + drng_reader = BIP85DRNG.new(bip85_entropy) + rsa_key = RSA.generate_key(4096, drng_reader.read()) + +===Test Vectors=== +INPUT: +xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb +* MASTER BIP32 ROOT KEY: m/83696968'/0'/0' + +OUTPUT +* DERIVED KEY=cca20ccb0e9a90feb0912870c3323b24874b0ca3d8018c4b96d0b97c0e82ded0 +* DERIVED ENTROPY=6bea85e51a05e6dbaf2ccee05097758213807997ba936589cef01c8f19c0079f395a0cd045efa3438677f3ef9ad34c9a68506626c5a17e51ed5e177852ee7fdc + +* DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111 + ==Reference Implementation== -Python library implementation: [https://github.com/ethankosakovsky/bipentropy python-bipentropy] +* Python library implementation: [https://github.com/ethankosakovsky/bip85] +* JavaScript library implementation: [https://github.com/hoganri/bip85-js] ===Other Implementations=== -Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] +* JavaScript library implementation: [https://github.com/hoganri/bip85-js] + +* Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] ==Applications== Application number define 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}'' path for the application, and ''{index}'' in the index. ===BIP39=== Application number: 39' @@ -231,6 +256,36 @@ INPUT: OUTPUT * DERIVED ENTROPY=492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c +===RSA=== + +Application number: 828365' + +The derivation path format is: <code>m/83696968'/828365'/{key_bits}'/{key_index}'</code> + +The RSA key generator should use BIP85-DRNG as the input RNG function. + +===RSA GPG=== + +Keys allocated for RSA-GPG purposes use the following scheme: + + - Main key <code>m/83696968'/828365'/{key_bits}'/{key_index}'</code> + - Sub keys: <code>m/83696968'/828365'/{key_bits}'/{key_index}'/{sub_key}'</code> + + - key_index is the parent key for CERTIFY capability + - sub_key <code>0'</code> is used as the ENCRYPTION key + - sub_key <code>1'</code> is used as the AUTHENTICATION key + - sub_key <code>2'</code> is usually used as SIGNATURE key + +Note on timestamps: + +The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to unix Epoch timestamp 1231006505 (the Bitcoin genesis block time <code>'2009-01-03 18:05:05'</code> UTC) because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of <code>faketime</code>). + +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. + ==Backwards Compatibility== This specification is not backwards compatible with any other existing specification. diff --git a/bip-0114.mediawiki b/bip-0114.mediawiki index 21d0b6c..410e84c 100644 --- a/bip-0114.mediawiki +++ b/bip-0114.mediawiki @@ -5,7 +5,7 @@ Author: Johnson Lau <jl2012@xbt.hk> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0114 - Status: Draft + Status: Rejected Type: Standards Track Created: 2016-04-02 License: PD diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 7a87b24..730ffb9 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -266,7 +266,7 @@ segwit transaction in which case it must be only the exact redeemscript. P2SH is (unless the P2SH hash is broken) with CHECKTEMPLATEVERIFY because the template hash must commit to the ScriptSig, which must contain the redeemscript, which is a hash cycle. -To prevent succeptibility to malleability when not using a segwit input, we also commit to the +To prevent malleability when not using a segwit input, we also commit to the scriptsig. This makes it possible to use a 2 input CHECKTEMPLATEVERIFY with a legacy pre-signed spend, as long as the exact scriptsig for the legacy output is committed. This is more robust than simply disallowing any scriptSig to be set with CHECKTEMPLATEVERIFY. diff --git a/bip-0124.mediawiki b/bip-0124.mediawiki index a5929ac..69cb134 100644 --- a/bip-0124.mediawiki +++ b/bip-0124.mediawiki @@ -6,7 +6,7 @@ William Swanson <swansontec@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0124 - Status: Draft + Status: Rejected Type: Informational Created: 2015-11-20 License: PD diff --git a/bip-0135.mediawiki b/bip-0135.mediawiki index 89d3077..1324746 100644 --- a/bip-0135.mediawiki +++ b/bip-0135.mediawiki @@ -5,7 +5,7 @@ Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0135 https://bitco.in/forum/threads/bip9-generalized-version-bits-voting-bip-genvbvoting.1968/ - Status: Draft + Status: Rejected Type: Informational Created: 2017-03-29 License: CC0-1.0 diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 82f6abd..8528729 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -127,7 +127,7 @@ Sigops per block is currently limited to 20,000. We change this restriction as f Sigops in the current pubkey script, signature script, and P2SH check script are counted at 4 times their previous value. The sigop limit is likewise quadrupled to ≤ 80,000. -Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH <code>witnessScript</code> are counted identically as previously within the P2SH <code>redeemScript</code>. That is, CHECKSIG is counted as only 1 sigop, and CHECKMULTISIG is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program. +Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH <code>witnessScript</code> are counted identically as previously within the P2SH <code>redeemScript</code>. That is, CHECKSIG is counted as only 1 sigop. When preceded by OP_1 to OP_16 CHECKMULTISIG is counted as 1 to 16 sigops respectively, otherwise it is counted as 20 sigops. This rule applies to both native witness program and P2SH witness program. === Additional definitions === diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki index 5914241..ab3c0fc 100644 --- a/bip-0155.mediawiki +++ b/bip-0155.mediawiki @@ -46,7 +46,7 @@ The <code>addrv2</code> message is defined as a message where <code>pchCommand = It is serialized in the standard encoding for P2P messages. Its format is similar to the current <code>addr</code> message format <ref>[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]</ref>, with the difference that the -fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the time and services format has been changed to VARINT. +fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize]. This means that the message contains a serialized <code>std::vector</code> of the following structure: @@ -55,13 +55,13 @@ This means that the message contains a serialized <code>std::vector</code> of th !Name !Description |- -| <code>VARINT</code> (unsigned) +| <code>uint32_t</code> | <code>time</code> -| Time that this node was last seen as connected to the network. A time in Unix epoch time format, up to 64 bits wide. +| Time that this node was last seen as connected to the network. A time in Unix epoch time format. |- -| <code>VARINT</code> (unsigned) +| <code>CompactSize</code> | <code>services</code> -| Service bits. A 64-wide bit field. +| Service bits. A bit field that is 64 bits wide, encoded in [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize]. |- | <code>uint8_t</code> | <code>networkID</code> @@ -78,8 +78,8 @@ This means that the message contains a serialized <code>std::vector</code> of th One message can contain up to 1,000 addresses. Clients SHOULD reject messages with more addresses. -Field <code>addr</code> has a variable length, with a maximum of 32 bytes (256 bits). Clients SHOULD reject -longer addresses. +Field <code>addr</code> has a variable length, with a maximum of 512 bytes (4096 bits). +Clients SHOULD reject messages with longer addresses, irrespective of the network ID. The list of reserved network IDs is as follows: @@ -120,21 +120,23 @@ The list of reserved network IDs is as follows: | Cjdns overlay network address |} -To allow for future extensibility, clients MUST ignore address types that they do not know about. -Client MAY store and gossip address formats that they do not know about. Further network ID numbers MUST be reserved in a new BIP document. +Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to. -Clients SHOULD reject addresses that have a different length than specified in this table for a specific address ID, as these are meaningless. +Clients SHOULD NOT gossip addresses from unknown networks because they have no means to validate those addresses and so can be tricked to gossip invalid addresses. + +Further network ID numbers MUST be reserved in a new BIP document. + +Clients SHOULD reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless. See the appendices for the address encodings to be used for the various networks. -==Compatibility== +==Signaling support and compatibility== + +Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2". -Send <code>addrv2</code> messages only, and exclusively, when the peer has a certain protocol version (or higher): -<source lang="c++"> -//! gossiping using `addrv2` messages starts with this version -static const int GOSSIP_ADDRV2_VERSION = 70016; -</source> -For older peers keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types. +The <code>sendaddrv2</code> message MUST only be sent in response to the <code>version</code> message from a peer and prior to sending the <code>verack</code> message. + +For older peers, that did not emit <code>sendaddrv2</code>, keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types. ==Reference implementation== @@ -142,15 +144,13 @@ The reference implementation is available at (to be done) ==Acknowledgements== -- Jonas Schnelli: change <code>services</code> field to VARINT, to make the message more compact in the likely case instead of always using 8 bytes. - -- Luke-Jr: change <code>time</code> field to VARINT, for post-2038 compatibility. +- Jonas Schnelli: change <code>services</code> field to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize], to make the message more compact in the likely case instead of always using 8 bytes. - Gregory Maxwell: various suggestions regarding extensibility ==Appendix A: Tor v2 address encoding== -The new message introduces a separate network ID for <code>TORV2</code>. +The new message introduces a separate network ID for <code>TORV2</code>. Clients MUST send Tor hidden service addresses with this network ID, with the 80-bit hidden service ID in the address field. This is the same as the representation in the legacy <code>addr</code> message, minus the 6 byte prefix of the OnionCat wrapping. @@ -164,10 +164,11 @@ onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion" CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2] where: - - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service. - - VERSION is an one byte version field (default value '\x03') + - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service + - VERSION is a one byte version field (default value '\x03') - ".onion checksum" is a constant string - CHECKSUM is truncated to two bytes before inserting it in onion_address + - H() is the SHA3-256 cryptographic hash function </pre> Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte PUBKEY part in the address field. As VERSION will always be '\x03' in the case of v3 addresses, this is enough to reconstruct the onion address. diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 80c7284..c034f05 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -5,7 +5,7 @@ Author: Andrew Chow <achow101@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174 - Status: Proposed + Status: Final Type: Standards Track Created: 2017-07-12 License: BSD-2-Clause @@ -21,6 +21,9 @@ signatures for an input while the input does not have a complete set of signatur The signer can be offline as all necessary information will be provided in the transaction. +The generic format is described here in addition to the specification for version 0 +of this format. + ===Copyright=== This BIP is licensed under the 2-clause BSD license. @@ -48,272 +51,337 @@ is the separator here <tt>0x00</tt> instead of <tt>0xff</tt>?''' The separator here is used to distinguish between each chunk of data. A separator of 0x00 would mean that the unserializer can read it as a key length of 0, which would never occur with actual keys. It can thus be used as a separator and allow for easier unserializer implementation.</ref>. -Each key-value pair must have a unique key within its scope; duplicates are not allowed. The format -of a record is as follows: -Note: <tt><..></tt> indicates that the data is prefixed by a compact size unsigned integer representing -the length of that data. <tt>{..}</tt> indicates the raw data itself. -<pre> -<key>|<value> -</pre> + <psbt> := <magic> <global-map> <input-map>* <output-map>* + <magic> := 0x70 0x73 0x62 0x74 0xFF + <global-map> := <keypair>* 0x00 + <input-map> := <keypair>* 0x00 + <output-map> := <keypair>* 0x00 + <keypair> := <key> <value> + <key> := <keylen> <keytype> <keydata> + <value> := <valuelen> <valuedata> + +Where: + +;<tt><keytype></tt> +: A compact size unsigned integer representing the type. This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. This must be unique within a specific <tt><map></tt>. +;<tt><keylen></tt> +: The compact size unsigned integer containing the combined length of <tt><keytype></tt> and <tt><keydata></tt> +;<tt><valuelen></tt> +: The compact size unsigned integer containing the length of <tt><valuedata></tt>. +;<tt><magic></tt> +: Magic bytes which are ASCII for psbt <ref>'''Why use 4 bytes for psbt?''' The +transaction format needed to start with a 5 byte header which uniquely identifies +it. The first bytes were chosen to be the ASCII for psbt because that stands for +Partially Signed Bitcoin Transaction. </ref> 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. + +The currently defined global types are as follows: -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Name -!Type -!Description +{| +! 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 +! Parent BIP |- -| Key Length -| Compact Size Unsigned Integer -| Specify how long the key is +| Unsigned Transaction +| <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt> +| None +| No key data +| <tt><transaction></tt> +| The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses). +| 0 +| +| 0 +| 174 |- -| Key -| byte[] -| The Key itself +| Extended Public Key +| <tt>PSBT_GLOBAL_XPUB = 0x01</tt> +| <tt><xpub></tt> +| The 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived. +| <tt><32-bit uint> <32-bit uint>*</tt> +| 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 +| 174 |- -| Value Length -| Compact Size Unsigned Integer -| Specify how long the value is +| PSBT Version Number +| <tt>PSBT_GLOBAL_VERSION = 0xFB</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0. +| +| +| 0 +| 174 |- -| Value -| byte[] -| The Value itself +| Proprietary Use Type +| <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt> +| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> +| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>. +| <tt><data></tt> +| Any value data as defined by the proprietary type user. +| +| +| 0 +| 174 |} -The format of each key-value map is as follows: - -<pre> -{key-value pair}|{key-value pair}|...|{0x00} -</pre> +The currently defined per-input types are defined as follows: -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Field Size -!Name -!Type -!Value -!Description +{| +! 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 +! Parent BIP +|- +| Non-Witness UTXO +| <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> +| None +| No key data +| <tt><transaction></tt> +| 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 +| 174 +|- +| Witness UTXO +| <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt> +| None +| No key data +| <tt><64-bit uint> <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 +| 174 +|- +| Partial Signature +| <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt> +| <tt><pubkey></tt> +| The public key which corresponds to this signature. +| <tt><signature></tt> +| The signature as would be pushed to the stack from a scriptSig or witness. +| +| +| 0 +| 174 +|- +| Sighash Type +| <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| 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 +| 174 +|- +| Redeem Script +| <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt> +| None +| No key data +| <tt><redeemScript></tt> +| The redeemScript for this input if it has one. +| +| +| 0 +| 174 +|- +| Witness Script +| <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt> +| None +| No key data +| <tt><witnessScript></tt> +| The witnessScript for this input if it has one. +| +| +| 0 +| 174 +|- +| BIP 32 Derivation Path +| <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt> +| <tt><pubkey></tt> +| The public key +| <tt><32-bit uint> <32-bit uint>*</tt> +| 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 +| 174 |- -| 1+ -| Key-value pairs -| Array of key-value pairs -| varies -| The key-value pairs. +| Finalized scriptSig +| <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt> +| None +| No key data +| <tt><scriptSig></tt> +| The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. +| +| +| 0 +| 174 +|- +| Finalized scriptWitness +| <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt> +| None +| No key data +| <tt><scriptWitness></tt> +| The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. +| +| +| 0 +| 174 +|- +| Proof-of-reserves commitment +| <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt> +| None +| No key data +| <tt><porCommitment></tt> +| The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. +| +| +| 0 +| [[bip-0127.mediawiki|127]] +|- +| RIPEMD160 preimage +| <tt>PSBT_IN_RIPEMD160 = 0x0a</tt> +| <tt><20-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>RIPEMD160</tt> algorithm +| +| +| 0 +| 174 |- -| 1 -| separator -| char -| <tt>0x00</tt> -| Must be <tt>0x00</tt> at the end of the map. +| SHA256 preimage +| <tt>PSBT_IN_SHA256 = 0x0b</tt> +| <tt><32-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm +| +| +| 0 +| 174 +|- +| HASH160 preimage +| <tt>PSBT_IN_HASH160 = 0x0c</tt> +| <tt><20-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| 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 +| 174 +|- +| HASH256 preimage +| <tt>PSBT_IN_HASH256 = 0x0d</tt> +| <tt><32-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm twice +| +| +| 0 +| 174 +|- +| Proprietary Use Type +| <tt>PSBT_IN_PROPRIETARY = 0xFC</tt> +| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> +| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>. +| <tt><data></tt> +| Any value data as defined by the proprietary type user. +| +| +| 0 +| 174 |} -At the beginning of each key is a compact size unsigned integer representing the type. -This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. -For convenience, this BIP will specify types using their full serialization, so a multi-byte type will have it's full prefix and zero padding as necessary. -There are global types, per-input types, and per-output types. - -The currently defined global types are as follows: - -* Type: Unsigned Transaction <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x00}</tt> -** Value: The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses). A PSBT must have a transaction, otherwise it is invalid. -*** <tt>{transaction}</tt> -** Note: Every PSBT must have a field with this type. - -* Type: Extended Public Key <tt>PSBT_GLOBAL_XPUB = 0x01</tt> -** Key: The type followed by the 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived. -*** <tt>{0x01}|{xpub}</tt> -** Value: The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit 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. -*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> - -* Type: Version Number <tt>PSBT_GLOBAL_VERSION = 0xFB</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0xFB}</tt> -** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0. -*** <tt>{32-bit uint}</tt> - -* Type: Proprietary Use Type <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt> -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> -** Value: Any value data as defined by the proprietary type user. -*** <tt><data></tt> - -The currently defined per-input types are defined as follows: - -* Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> -** Key: None. The key must only contain the 1 byte type. -***<tt>{0x00}</tt> -** Value: The transaction in network serialization format the current input spends from. This should 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> -*** <tt>{transaction}</tt> - -* Type: Witness UTXO <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x01}</tt> -** Value: The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt> -*** <tt>{serialized transaction output({output value}|<scriptPubKey>)}</tt> - -* Type: Partial Signature <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt> -** Key: The public key which corresponds to this signature. -*** <tt>{0x02}|{public key}</tt> -** Value: The signature as would be pushed to the stack from a scriptSig or witness. -*** <tt>{signature}</tt> - -* Type: Sighash Type <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x03}</tt> -** Value: The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature. -*** <tt>{sighash type}</tt> - -* Type: Redeem Script <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x04}</tt> -** Value: The redeemScript for this input if it has one. -*** <tt>{redeemScript}</tt> - -* Type: Witness Script <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x05}</tt> -** Value: The witnessScript for this input if it has one. -*** <tt>{witnessScript}</tt> - -* Type: BIP 32 Derivation Path <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt> -** Key: The public key -*** <tt>{0x06}|{public key}</tt> -** Value: The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input. -*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> - -* Type: Finalized scriptSig <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x07}</tt> -** Value: The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. -*** <tt>{scriptSig}</tt> - -* Type: Finalized scriptWitness <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x08}</tt> -** Value: The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. -*** <tt>{scriptWitness}</tt> - -* Type: Proof-of-reserves commitment <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x09}</tt> -** Value: The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. -*** <tt>{porCommitment}</tt> - -* Type: RIPEMD160 preimage <tt>PSBT_RIPEMD160 = 0x0a</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0a}|{20-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `RIPEMD160` algorithm -*** <tt>{preimage}</tt> - -* Type: SHA256 preimage <tt>PSBT_SHA256 = 0x0b</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0b}|{32-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm -*** <tt>{preimage}</tt> - -* Type: HASH160 preimage <tt>PSBT_HASH160 = 0x0c</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0c}|{20-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm followed by the `RIPEMD160` algorithm -*** <tt>{preimage}</tt> - -* Type: HASH256 preimage <tt>PSBT_HASH256 = 0x0d</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0d}|{32-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm twice -*** <tt>{preimage}</tt> - -* Type: Proprietary Use Type <tt>PSBT_IN_PROPRIETARY = 0xFC</tt> -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> -** Value: Any value data as defined by the proprietary type user. -*** <tt><data></tt> - The currently defined per-output <ref>'''Why do we need per-output data?''' Per-output data allows signers to verify that the outputs are going to the intended recipient. The output data can also be use by signers to determine which outputs are change outputs and verify that the change is returning to the correct place.</ref> types are defined as follows: -* Type: Redeem Script <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x00}</tt> -** Value: The redeemScript for this output if it has one. -*** <tt>{redeemScript}</tt> - -* Type: Witness Script <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x01}</tt> -** Value: The witnessScript for this output if it has one. -*** <tt>{witnessScript}</tt> - -* Type: BIP 32 Derivation Path <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt> -** Key: The public key -*** <tt>{0x02}|{public key}</tt> -** Value: The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output. -*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> - -* Type: Proprietary Use Type <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt> -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> -** Value: Any value data as defined by the proprietary type user. -*** <tt><data></tt> - -The transaction format is specified as follows: - - -<pre> - {0x70736274}|{0xff}|{global key-value map}|{input key-value map}|...|{input key-value map}|{output key-value map}|...|{output key-value map}| -</pre> - -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Field Size -!Name -!Type -!Value -!Description -|- -| 4 -| Magic Bytes -| int32_t -| <tt>0x70736274</tt> -| Magic bytes which are ASCII for psbt. <ref>'''Why use 4 bytes for psbt?''' The -transaction format needed to start with a 5 byte header which uniquely identifies -it. The first bytes were chosen to be the ASCII for psbt because that stands for -Partially Signed Bitcoin Transaction. </ref> This integer should be serialized -in most significant byte order. +{| +! 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 +! Parent BIP |- -| 1 -| separator -| char -| <tt>0xff</tt> -| Must be <tt>0xff</tt> <ref>'''Why Use a separator after the magic bytes?''' The separator -is part of the 5 byte header for PSBT. This byte is a separator of <tt>0xff</tt> because -this will cause any non-PSBT unserializer to fail to properly unserialize the PSBT -as a normal transaction. Likewise, since the 5 byte header is fixed, no transaction -in the non-PSBT format will be able to be unserialized by a PSBT unserializer.</ref> +| Redeem Script +| <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt> +| None +| No key data +| <tt><redeemScript></tt> +| The redeemScript for this output if it has one. +| +| +| 0 +| 174 |- -| 1+ -| Global data -| Key-value Map -| varies -| The key-value pairs for all global data. +| Witness Script +| <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt> +| None +| No key data +| <tt><witnessScript></tt> +| The witnessScript for this output if it has one. +| +| +| 0 +| 174 |- -| 1+ -| Inputs -| Array of key-value maps -| varies -| The key-value pairs for each input as described above. Every input in the unsigned transaction must have a corresponding input map. +| BIP 32 Derivation Path +| <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt> +| <tt><public key></tt> +| The public key +| <tt><{32-bit uint> <32-bit uint>*</tt> +| 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 +| 174 |- -| 1+ -| Outputs -| Array of key-value maps -| varies -| The key-value pairs for each output as described above. Every output in the unsigned transaction must have a corresponding output map. +| Proprietary Use Type +| <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt> +| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> +| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>. +| <tt><data></tt> +| Any value data as defined by the proprietary type user. +| +| +| 0 +| 174 |} -Each block of data between separators can be viewed as a scope, and all separators -are required<ref>'''Why are all separators required?''' The separators are required -so that the unserializer knows which input it is unserializing data for.</ref>. Types can be skipped when they are unnecessary. For example, if an input is a witness input, then it should not have a Non-Witness UTXO key-value pair. @@ -336,10 +404,10 @@ values are valid, then it does not matter which is chosen as either way the tran ===Proprietary Use Type=== For all global, per-input, and per-output maps, the types <tt>0xFC</tt> is reserved for proprietary use. -The proprietary use type requires keys that follow the type with a variable length string identifer, then a subtype. +The proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifer, followed by the string identifier, then a subtype, and finally any key data. The identifier can be any variable length string that software can use to identify whether the particular data in the proprietary type can be used by it. -It can also be the empty string and just be a single <tt>0x00</tt> byte although this is not recommended. +It can also be the empty string although this is not recommended. The subtype is defined by the proprietary type user and can mean whatever they want it to mean. The subtype must also be a compact size unsigned integer in the same form as the normal types. @@ -350,9 +418,15 @@ It is useful when there are additional data that they need attached to a PSBT bu The proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes. This type must be used for internal processes only. -==Responsibilities== +==Version 0== -Using the transaction format involves many different responsibilities. Multiple responsibilities can be handled by a single entity, but each responsibility is specialized in what it should be capable of doing. +Partially Signed Bitcoin Transactions version 0 is the first version of the PSBT format. +Version 0 PSBTs must either omit PSBT_GLOBAL_VERSION or include it and set it to 0. +Version 0 PSBTs must include PSBT_GLOBAL_UNSIGNED_TX, if omitted, the PSBT is invalid. + +==Roles== + +Using the transaction format involves many different roles. Multiple roles can be handled by a single entity, but each role is specialized in what it should be capable of doing. ===Creator=== @@ -373,7 +447,7 @@ The Signer must only accept a PSBT. The Signer must only use the UTXOs provided in the PSBT to produce signatures for inputs. Before signing a non-witness input, the Signer must verify that the TXID of the non-witness UTXO matches the TXID specified in the unsigned transaction. Before signing a witness input, the Signer must verify that the witnessScript (if provided) matches the hash specified in the UTXO or the redeemScript, and the redeemScript (if provided) matches the hash in the UTXO. -The Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. <ref>'''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 173 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in <tt>PSBT_IN_WITNESS_UTXO<tt> of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) be provided to ensure that the amounts of other inputs are not being tampered with.</ref> +The Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. <ref>'''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 173 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in <tt>PSBT_IN_WITNESS_UTXO</tt> of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) be provided to ensure that the amounts of other inputs are not being tampered with.</ref> The Signer should not need any additional data sources, as all necessary information is provided in the PSBT format. The Signer must only add data to a PSBT. Any signatures created by the Signer must be added as a "Partial Signature" key-value pair for the respective input it relates to. @@ -509,6 +583,18 @@ Updaters and combiners that need to add a version number to a PSBT should use th For example, if a combiner sees two PSBTs for the same transaction, one with version 0, and the other with version 1, then it should combine them and produce a PSBT with version 1. If an updater is updating a PSBT and needs to add a field that is only available in version 1, then it should set the PSBT version number to 1 unless a version higher than that is already specified. +===Procedure For New Fields=== + +New fields should first be proposed on the bitcoin-dev mailing list. +If a field requires significatn description as to its usage, it should be accompanied by a separate BIP. +The field must be added to the field listing tables in the Specification section. + +===Procedure For New Versions=== + +New PSBT versions must be described in a separate BIP. +The BIP may reference this BIP and any components of PSBT version 0 that are retained in the new version. +Any new fields described in the new version must be added to the field listing tables in the Specification section. + ==Compatibility== This transaction format is designed so that it is unable to be properly unserialized @@ -757,109 +843,3 @@ and for coming up with the name and abbreviation of PSBT. Thanks to Pieter Wuille, Gregory Maxwell, Jonathan Underwood, Daniel Cousens and those who commented on the bitcoin-dev mailing list for additional comments and suggestions for improving this proposal. - -==Appendix A: Data types and their specifications== - -Any data types, their associated scope and BIP number must be defined here - -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Scope -!Type values -!Name -!BIP Number -|- -| Global -| 0 -| PSBT_GLOBAL_UNSIGNED_TX -| BIP 174 -|- -| Global -| 1 -| PSBT_GLOBAL_XPUB -| BIP 174 -|- -| Global -| 251 -| PSBT_GLOBAL_VERSION -| BIP 174 -|- -| Global -| 252 -| PSBT_GLOBAL_PROPRIETARY -| BIP 174 -|- -| Input -| 0 -| PSBT_IN_NON_WITNESS_UTXO -| BIP 174 -|- -| Input -| 1 -| PSBT_IN_WITNESS_UTXO -| BIP 174 -|- -| Input -| 2 -| PSBT_IN_PARTIAL_SIG -| BIP 174 -|- -| Input -| 3 -| PSBT_IN_SIGHASH_TYPE -| BIP 174 -|- -| Input -| 4 -| PSBT_IN_REDEEM_SCRIPT -| BIP 174 -|- -| Input -| 5 -| PSBT_IN_WITNESS_SCRIPT -| BIP 174 -|- -| Input -| 6 -| PSBT_IN_BIP32_DERIVATION -| BIP 174 -|- -| Input -| 7 -| PSBT_IN_FINAL_SCRIPTSIG -| BIP 174 -|- -| Input -| 8 -| PSBT_IN_FINAL_SCRIPTWITNESS -| BIP 174 -|- -| Input -| 9 -| PSBT_IN_POR_COMMITMENT -| [[bip-0127.mediawiki|BIP 127]] -|- -| Input -| 252 -| PSBT_IN_PROPRIETARY -| BIP 174 -|- -| Output -| 0 -| PSBT_OUT_REDEEM_SCRIPT -| BIP 174 -|- -| Output -| 1 -| PSBT_OUT_WITNESS_SCRIPT -| BIP 174 -|- -| Output -| 2 -| PSBT_OUT_BIP32_DERIVATION -| BIP 174 -|- -| Output -| 252 -| PSBT_OUT_PROPRIETARY -| BIP 174 -|} diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index 95991e6..7aca5d1 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -13,119 +13,99 @@ == Abstract == -A standard for interoperable generic signed messages based on the Bitcoin Script format. - -== Background == - -* Assume two actors, a prover <code>P</code> and a verifier <code>V</code>. -* <code>P</code> wants to prove that they own the private key <code>k</code> associated with a given address <code>A</code> (which in turn is derived from the pubkey <code>kG</code>). -* Let <code>V</code> generate a message <code>M</code> and hand this to <code>P</code>. -* <code>P</code> generates a signature <code>S</code> by signing the message <code>M</code> using <code>k</code>. Given <code>S</code>, <code>V</code> can prove that <code>P</code> has the private key associated with <code>A</code>. - -The astute reader will notice that the above is missing a critical part, namely the pubkey <code>kG</code>, without which the verifier cannot actually verify the message. The current message signing standard solves this via a cryptographic trick, wherein the signature <code>S</code> above is a special "recoverable signature" type. Given the message <code>M</code> and the signature <code>S</code>, it is then possible to recover the pubkey <code>kG</code>. The system thus derives the address for the pubkey <code>kG</code>, and if it does not match <code>A</code>, the proof is deemed invalid. - -While this is a neat trick, it unnecessarily restricts and complicates the message signing mechanism; for instance, it is currently not possible to sign a message for a P2SH address, because there is no pubkey to recover from the resulting signature. +A standard for interoperable signed messages based on the Bitcoin Script format, either for proving fund availability, or committing to a message as the intended recipient of funds sent to the invoice address. == Motivation == -The current message signing standard only works for P2PKH (1...) addresses. By extending it to use a Bitcoin Script based approach, it could be made more generic without causing a too big burden on implementers, who most likely have access to Bitcoin Script interpreters already. - -== Specification == +The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This approach minimizes the burden for implementers as message signing can be expected to be part of a library or project that includes Bitcoin Script interpreters already. -A new structure <code>SignatureProof</code> is added, which is a simple serializable scriptSig & witness container. +Additionally, the current message signing only proves that the message has been committed to by the recipient of a given invoice address. +It does not prove anything about the invoice address itself, nor that the signer has access to the private keys used to implement this invoice. +More importantly, it does not prove ownership nor access to any funds, even if the same private key would be a valid signer for spending them - and this is a commonly desired use case. -=== SignatureProof container === +== Specification == -{|class="wikitable" style="text-align: center;" -|- -!Type -!Length -!Name -!Comment -|- -|VarInt||1-8||scriptsiglen||Number of bytes in scriptSig data -|- -|Uint8*||[scriptsiglen]||scriptsig||ScriptSig data -|- -|VarInt||1-8||witlen||Number of entries in witness stack -|- -|Uint8[]*||[witlen]||wit||Witness stack, as [witlen] uint8* vectors, each one prepended with a varint of its size -|} +This BIP follows the specification of BIP-325 challenges and solutions. -In some cases, the scriptsig or wit may be empty. If both are empty, the proof is incomplete. +Let there be two virtual transactions to_spend and to_sign. -=== Result Codes === +The "to_spend" transaction is: -A verification call will return a result code according to the table below. + nVersion = 0 + nLockTime = 0 + vin[0].prevout.hash = 0000...000 + vin[0].prevout.n = 0xFFFFFFFF + vin[0].nSequence = 0 + vin[0].scriptSig = OP_0 PUSH32[ message_hash ] + vin[0].scriptWitness = [] + vout[0].nValue = 0 + vout[0].scriptPubKey = message_challenge -{|class="wikitable" style="text-align: center;" -|- -!Code -!Description -|- -|INCOMPLETE||Empty proof. -|- -|INCONCLUSIVE||The given proof was consensus-valid but policy-invalid. -|- -|VALID||The proof was valid. -|- -|INVALID||The proof was invalid -|- -|ERROR||An error was encountered -|} +where message_hash is a BIP340-tagged hash of the message, i.e. sha256_tag(m), where tag = "BIP0322-signed-message", and message_challenge is the to be proven (public) key script. +For proving funds, message_challenge shall be simply OP_TRUE. -== Signing and Verifying == +The "to_sign" transaction is: -If the challenge consists of an address is in the P2PKH (legacy) format, sign using the legacy format (further information below). Otherwise continue as stated below. + nVersion = 0 or as appropriate (e.g. 2, for time locks) + nLockTime = 0 or as appropriate (for time locks) + vin[0].prevout.hash = to_spend.txid + vin[0].prevout.n = 0 + vin[0].nSequence = 0 or as appropriate (for time locks) + vin[0].scriptWitness = message_signature + vout[0].nValue = 0 + vout[0].scriptPubKey = OP_RETURN -For both cases, generate a sighash based on the given scriptPubKey and message as follows: +When a proof of funds is being created, additional inputs should be included for virtually spending transaction outputs of desired value. -# Define the message pre-image as the sequence "Bitcoin Signed Message:\n" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD) -# Let sighash = sha256(sha256(scriptPubKey || pre-image)) +* All signatures must use the SIGHASH_ALL flag. +* The proof is considered valid, inconclusive, or invalid based on whether the to_sign transaction is a valid spend of the to_spend transaction or not, according to the rules specified in the "Consensus and standard flags" section below. +* Proofs of funds may be encumbered with the in_future flag, according to the rules specified in the "Locktime and Sequence" section below, in which case we refer to the result in text form as "valid_in_future", "inconclusive_in_future", etc. -A private key may be used directly to sign a message. In this case, its P2WPKH bech32 address shall be derived, and used as the input. +Proofs of funds are the base64-encoding of the to_spend and to_sign transactions concatenated in standard network serialisation, and proofs without additional inputs or time locks (simple proofs) are the base64-encoding of the to_sign script witness. -=== Signing === +A validator must verify the proof is valid and meets the description of virtual transactions as specified above. See "Validation" below. -The signature is generated as follows: +=== Validation === -# Derive the private key privkey for the scriptPubKey; FAIL if not VALID -# Generate and return a signature sig with privkey=privkey, sighash=sighash - -=== Verifying === +To validate a simple proof, the following steps must be taken: -Verify a proof, given a standard flags value, a script sig, an optional witness, and a derived sighash as described above. +# construct the to_spend and to_sign transactions, based on the specification above +# check the signature using consensus rules, then upgradable rules -While omitted below, ERROR is returned if an unforeseen error occurs at any point in the process. A concrete example of this is if a legacy proof is given as input to a non-legacy address; the deserialization of the proof will fail in this case, and this should result in an ERROR result. +To validate a proof of funds, the following steps must be taken: -# Verify Script with flags=consensus flags (currently P2SH, DERSIG, NULLDUMMY, CLTV, CSV, WITNESS), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash -# Return INVALID if verification fails -# Verify Script with flags=standard flags (above plus STRICTENC, MINIMALDATA, etc.), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash -# Return VALID if verification succeeds, otherwise return INCONCLUSIVE +# deserialize the to_spend and to_sign transactions from the proof, and fail if the proof contains extraneous bytes +# verify that the to_sign transaction uses all inputs covered by the proof of funds, exactly once +# reconstruct the to_spend' and to_sign' transactions, based on the specification above, copying the version, lock time, and sequence values +# verify that to_spend = to_spend', that to_sign has at least 1 input, has exactly 1 output, and that to_sign.vin[0] = to_sign'.vin[0] +# set the "in_future" flag if the transaction's lock time is in the future according to consensus rules +# establish a "coins map", a mapping of outpoints (hash, vout) to coins (scriptPubKey, amount), initialized to coins_map(to_spend.txid, 0) = (to_spend.vout[0], 0) +# for each proof of fund input, set the corresponding values in the coins map; abort if the input cannot be found +# check the signature of each input using consensus rules, then upgradable rules == Legacy format == -The legacy format is restricted to the legacy P2PKH address format. +New proofs should use the new format for all invoice address formats, including P2PKH. -Any other input (i.e. non-P2PKH address format) must be signed using the new format described above. +The legacy format MAY be used, but must be restricted to the legacy P2PKH invoice address format. === Signing === -Given the P2PKH address <code>a</code> and the message <code>m</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>: +Given the P2PKH invoice address <code>a</code> and the message <code>m</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>: # let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the pubkey <code>P</code>, contained in <code>a</code> # let <code>x</code> be the private key associated with <code>P</code> so that <code>pkh(xG) = p</code> -# let <code>digest</code> be <code>SHA56d("Bitcoin Signed Message:\n"||m)</code> +# let <code>digest</code> be <code>SHA56d(0x18||"Bitcoin Signed Message:\n"||compactint(len(m))||m)</code> # create a compact signature <code>sig</code> (aka "recoverable ECDSA signature") using <code>x</code> on <code>digest</code> The resulting proof is <code>sig</code>, serialized using the base64 encoding. === Verifying === -Given the P2PKH address <code>a</code>, the message <code>m</code>, the compact signature <code>sig</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>: +Given the P2PKH invoice address <code>a</code>, the message <code>m</code>, the compact signature <code>sig</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>: # let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the pubkey <code>P</code>, contained in <code>a</code> -# let <code>digest</code> be <code>SHA56d("Bitcoin Signed Message:\n"||m)</code> +# let <code>digest</code> be <code>SHA56d(0x18||"Bitcoin Signed Message:\n"||compactint(len(m))||m)</code> # attempt pubkey recovery for <code>digest</code> using the signature <code>sig</code> and store the resulting pubkey into <code>Q</code> ## fail verification if pubkey recovery above fails # let <code>q</code> be the pubkey-hash <code>pkh(Q)</code> for the pubkey <code>Q</code> @@ -137,7 +117,7 @@ This specification is backwards compatible with the legacy signmessage/verifymes == Reference implementation == -# Pull request to Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/16440 +TODO == Acknowledgements == @@ -153,9 +133,9 @@ This document is licensed under the Creative Commons CC0 1.0 Universal license. == Consensus and standard flags == -Each flag is associated with some type of enforced rule (most often a soft fork). There are two sets of flags: consensus flags (which result in a block being rejected, if violated), and policy flags (which result in a transaction being accepted only if it is contained within an actual block, and rejected otherwise, if violated). The policy flags are a super-set of the consensus flags. +Each flag is associated with some type of enforced rule (most often a soft fork). There are two sets of flags: consensus flags (which result in a block being rejected, if violated), and upgradable flags (which are typically policy-rejected by nodes specifically for the purpose of future network upgrades). The upgradable flags are a super-set of the consensus flags. -BIP322 specifies that a proof that validates for both rulesets is valid, a proof that validates for consensus rules, but not for policy rules, is "inconclusive", and a proof that does not validate for consensus rules is "invalid" (regardless of policy rule validation). +This BIP specifies that a proof that validates for both rulesets is valid, a proof that validates for consensus rules, but not for upgradable rules, is "inconclusive", and a proof that does not validate for consensus rules is "invalid" (regardless of upgradable rule validation). The ruleset sometimes changes. This BIP does not intend to be complete, nor does it indicate enforcement of rules, it simply lists the rules as they stand at the point of writing. @@ -168,7 +148,7 @@ The ruleset sometimes changes. This BIP does not intend to be complete, nor does * CHECKSEQUENCEVERIFY: enable CHECKSEQUENCEVERIFY ([https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112]) * WITNESS: enable WITNESS ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) -=== Policy rules === +=== Upgradable rules === All of the above, plus (subject to change): @@ -185,62 +165,4 @@ All of the above, plus (subject to change): == Test vectors == -(TODO: update test vectors, which are based on previous iteration where signature proofs contained additional data) - -== Native segwit test vector == - -<pre> -address = bcrt1qe7nte4zk4ayly5tc53dtdjupgkz0lr8azx3rzz -scriptpubkey = 0014cfa6bcd456af49f25178a45ab6cb814584ff8cfd -message = hello -preimage = 0014cfa6bcd456af49f25178a45ab6cb814584ff8cfd426974636f696e205369 - 676e6564204d6573736167653a0a68656c6c6f - (scriptpubkey || "Bitcoin Signed Message:\nhello") -sighash = 790eef86c204f0bff969ff822121317aa34eff0215dbd30ccf031e7b2f3f0cc1 - (sha256d(preimage), displayed in big-endian) -</pre> - -The proof becomes: - -<pre> -HEX: 01000000010002473044022075b4fb40421d55c55462879cb352a85eeb3af2138d3f0290 - 2c9143f12870f5f70220119c2995c1661138142f3899c1fd6d1af7e790e0e081be72db9c - e7bf5b5b932901210290beccd02b73eca57467b2b6f1e47161a9b76a5e67586e7c1dee9e - a6e2dcd869 - -Base64: AQAAAAEAAkcwRAIgdbT7QEIdVcVUYoecs1KoXus68hONPwKQLJFD8Shw9fcCIBGcKZXBZhE4 - FC84mcH9bRr355Dg4IG+ctuc579bW5MpASECkL7M0Ctz7KV0Z7K28eRxYam3al5nWG58He6e - puLc2Gk= -</pre> - -Split into components: - -{|class="wikitable" style="text-align: center;" -|- -!Type -!Length -!Name -!Value -!Comment -|- -|Uint32||4||flags||<code>01000000</code>||proof format version -|- -|Uint8||1||entries||<code>01</code>||1 entry -|- -|VarInt||1-8||scriptsiglen||<code>00</code>||0 byte scriptsig -|- -|VarInt||1-8||wit entries||<code>02</code>||2 witness stack entries -|- -|VarInt||1-8||entry1len||<code>47</code>||71 byte entry -|- -|Uint8[71]||71||entry1||<code>3044022075b4fb40421d55c55462879cb352a85eeb3af213 -8d3f02902c9143f12870f5f70220119c2995c1661138142f -3899c1fd6d1af7e790e0e081be72db9ce7bf5b5b932901</code>||Witness stack item 1 -|- -|VarInt||1-8||entry2len||<code>21</code>||33 byte entry -|- -|Uint8[33]||33||entry2||<code>0290beccd02b73eca57467b2b6f1e47161a9b76a5e67586e -7c1dee9ea6e2dcd869</code>||Witness stack item 2 -|} - -The above test vector is for a bech32 P2WPKH (native segwit) address. (Once BIP solidifies, will add test vector for other types.) +TODO diff --git a/bip-0325.mediawiki b/bip-0325.mediawiki index 752570d..5a9f3f1 100644 --- a/bip-0325.mediawiki +++ b/bip-0325.mediawiki @@ -3,9 +3,10 @@ Layer: Applications Title: Signet Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> + Anthony Towns <aj@erisian.com.au> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0325 - Status: Draft + Status: Proposed Type: Standards Track Created: 2019-03-20 License: CC0-1.0 @@ -21,19 +22,20 @@ Testnet is a great place to try out new things without risking real money, but i A new type of test network would be more suitable for integration testing by organizations such as exchanges, or testing of next generation Layer-2 protocols like Eltoo or sidechain pegs. The goal is not to be perfectly reliable but rather to have a predictable amount of unreliability. You want a test network to behave like mainnet (i.e. no thousands of block reorgs) while also making it easier to trigger expected but rare events like a 6-block reorg. Regtest is not suitable for longer-term scenarios involving multiple independent parties because creating blocks costs nothing, so any party can completely control the test network. - == Specification == A new type of network ("signet"), which takes an additional consensus parameter called the challenge (scriptPubKey). The challenge can be a simple pubkey (P2PKH style), or a k-of-n multisig, or any other script you would want. -The witness commitment of the coinbase transaction is extended to include a secondary commitment (the signature/solution) of either: +Signet requires all blocks to have a BIP 141 commitment in the coinbase transaction. In order to provide a non-empty solution to the block challenge the block's BIP 141 commitment's optional data must include an additional commitment of the signature/solution for the block: - 1-4 bytes - Push the following (4 + x + y) bytes - 4 bytes - Signet scriptSig header (0xecc7daa2) + 1-5 bytes - Push the following (4 + x + y) bytes + 4 bytes - Signet header (0xecc7daa2) x bytes - scriptSig y bytes - scriptWitness -The scriptSig is serialized by first encoding its length as CompactSize. If the scriptWitness is empty, it is encoded as 0 bytes, otherwise it is encoded in the usual way (see BIP 141 "witness" encoding). +In the special case where an empty solution is valid (ie scriptSig and scriptWitness are both empty) this additional commitment can optionally be left out. This special case is to allow non-signet-aware block generation code to be used to test a custom signet chain where the challenge is trivially true. + +The scriptSig is serialized by first encoding its length as CompactSize. The scriptWitness stack is serialized as described in BIP 141. Any push operations that do not start with the 4 byte Signet header are ignored. Multiple push operations with the 4 byte Signet header are ignored except for the first instance of the header. @@ -60,8 +62,10 @@ The "to_sign" transaction is: vin[0].prevout.hash = to_spend.txid vin[0].prevout.n = 0 vin[0].nSequence = 0 + vin[0].sigScript = [ signet_solution sigScript (x bytes), if any ] + vin[0].scriptWitness = [ signet_solution scriptWitness (y bytes), if any ] vout[0].nValue = 0 - vout[0].scriptPubKey = signet_challenge + vout[0].scriptPubKey = OP_RETURN The scriptSig and/or scriptWitness for <code>vin[0]</code> are filled in from the Signet header push above. @@ -77,11 +81,12 @@ The genesis block is the same for all signet networks, whereas the message start === Genesis Block === -* Time stamp: 1534313275 -* Nonce: 100123 -* Difficulty: 1e2adc28 +* Time stamp: 1598918400 +* Nonce: 52613770 +* Difficulty: 0x1e0377ae +* Version: 1 -The resulting genesis block hash is 0000032d7f67af9ec7b7152aea0fe7c95b9804ff973265e252f245e0ae61799d, and the block hex is 0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a3bc3735b28dc2a1e1b8701000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000. +The resulting genesis block hash is 00000008819873e925422c1ff0f99f7cc9bbb232af63a077a480a3633bee1ef6, and the block hex is 0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a008f4d5fae77031e8ad222030101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000. === Message Start === diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki index 9502a69..1de7faa 100644 --- a/bip-0340.mediawiki +++ b/bip-0340.mediawiki @@ -110,7 +110,7 @@ The following conventions are used, with constants as defined for [https://www.s ** The function ''bytes(x)'', where ''x'' is an integer, returns the 32-byte encoding of ''x'', most significant byte first. ** The function ''bytes(P)'', where ''P'' is a point, returns ''bytes(x(P))''. ** The function ''int(x)'', where ''x'' is a 32-byte array, returns the 256-bit unsigned integer whose most significant byte first encoding is ''x''. -** The function ''has_even_y(P)'', where ''P'' is a point, returns ''y(P) mod 2 = 0''. +** The function ''has_even_y(P)'', where ''P'' is a point for which ''not is_infinite(P)'', returns ''y(P) mod 2 = 0''. ** The function ''lift_x(x)'', where ''x'' is an integer in range ''0..p-1'', returns the point ''P'' for which ''x(P) = x''<ref> Given a candidate X coordinate ''x'' in the range ''0..p-1'', there exist either exactly two or exactly zero valid Y coordinates. If no valid Y coordinate exists, then ''x'' is not a valid X coordinate either, i.e., no point ''P'' exists for which ''x(P) = x''. The valid Y coordinates for a given candidate ''x'' are the square roots of ''c = x<sup>3</sup> + 7 mod p'' and they can be computed as ''y = ±c<sup>(p+1)/4</sup> mod p'' (see [https://en.wikipedia.org/wiki/Quadratic_residue#Prime_or_prime_power_modulus Quadratic residue]) if they exist, which can be checked by squaring and comparing with ''c''.</ref> and ''has_even_y(P)'', or fails if no such point exists. The function ''lift_x(x)'' is equivalent to the following pseudocode: *** Let ''c = x<sup>3</sup> + 7 mod p''. @@ -184,7 +184,9 @@ The algorithm ''Verify(pk, m, sig)'' is defined as: * Let ''s = int(sig[32:64])''; fail if ''s ≥ n''. * Let ''e = int(hash<sub>BIP0340/challenge</sub>(bytes(r) || bytes(P) || m)) mod n''. * Let ''R = s⋅G - e⋅P''. -* Fail if ''not has_even_y(R)'' or ''x(R) ≠ r''. +* Fail if ''is_infinite(R)''. +* Fail if ''not has_even_y(R)''. +* Fail if ''x(R) ≠ r''. * Return success iff no failure occurred before reaching this point. For every valid secret key ''sk'' and message ''m'', ''Verify(PubKey(sk),m,Sign(sk,m))'' will succeed. @@ -225,7 +227,7 @@ Moreover, Schnorr signatures are compatible with [https://web.archive.org/web/20 === Adaptor Signatures === -[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce with a known point ''T = t⋅G'', but not offsetting his secret nonce. +[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce ''R'' with a known point ''T = t⋅G'', but not offsetting the signature's ''s'' value. A correct signature (or partial signature, as individual signers' contributions to a multisignature are called) on the same message with same nonce will then be equal to the adaptor signature offset by ''t'', meaning that learning ''t'' is equivalent to learning a correct signature. This can be used to enable atomic swaps or even [https://eprint.iacr.org/2018/472 general payment channels] in which the atomicity of disjoint transactions is ensured using the signatures themselves, rather than Bitcoin script support. The resulting transactions will appear to verifiers to be no different from ordinary single-signer transactions, except perhaps for the inclusion of locktime refund logic. diff --git a/bip-0340/reference.py b/bip-0340/reference.py index 5d17db5..5b38c0a 100644 --- a/bip-0340/reference.py +++ b/bip-0340/reference.py @@ -26,13 +26,15 @@ def tagged_hash(tag: str, msg: bytes) -> bytes: tag_hash = hashlib.sha256(tag.encode()).digest() return hashlib.sha256(tag_hash + tag_hash + msg).digest() -def is_infinity(P: Optional[Point]) -> bool: +def is_infinite(P: Optional[Point]) -> bool: return P is None def x(P: Point) -> int: + assert not is_infinite(P) return P[0] def y(P: Point) -> int: + assert not is_infinite(P) return P[1] def point_add(P1: Optional[Point], P2: Optional[Point]) -> Optional[Point]: @@ -83,6 +85,7 @@ def hash_sha256(b: bytes) -> bytes: return hashlib.sha256(b).digest() def has_even_y(P: Point) -> bool: + assert not is_infinite(P) return y(P) % 2 == 0 def pubkey_gen(seckey: bytes) -> bytes: diff --git a/bip-0340/test-vectors.py b/bip-0340/test-vectors.py index e5b8847..d1bf6b2 100644 --- a/bip-0340/test-vectors.py +++ b/bip-0340/test-vectors.py @@ -6,7 +6,7 @@ def is_square(x): def has_square_y(P): """Determine if P has a square Y coordinate. Used in an earlier draft of BIP340.""" - assert not is_infinity(P) + assert not is_infinite(P) return is_square(P[1]) def vector0(): diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 7ac5bf8..0f8d32a 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -193,7 +193,7 @@ def taproot_tweak_seckey(seckey0, h): </source> The following function, <code>taproot_output_script</code>, returns a byte array with the scriptPubKey (see [[bip-0141.mediawiki|BIP141]]). -<code>ser_script</code> refers to a function that prefixes its input with a CCompactSize-encoded length. +<code>ser_script</code> refers to a function that prefixes its input with a CompactSize-encoded length. <source lang="python"> def taproot_tree_helper(script_tree): diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki index 3cf87a3..7e00a2e 100644 --- a/bip-0342.mediawiki +++ b/bip-0342.mediawiki @@ -125,7 +125,7 @@ In summary, the semantics of signature validation is identical to BIP340, except In addition to changing the semantics of a number of opcodes, there are also some changes to the resource limitations: * '''Script size limit''' The maximum script size of 10000 bytes does not apply. Their size is only implicitly bounded by the block weight limit.<ref>'''Why is a limit on script size no longer needed?''' Since there is no <code>scriptCode</code> directly included in the signature hash (only indirectly through a precomputable tapleaf hash), the CPU time spent on a signature check is no longer proportional to the size of the script being executed.</ref> * '''Non-push opcodes limit''' The maximum non-push opcodes limit of 201 per script does not apply.<ref>'''Why is a limit on the number of opcodes no longer needed?''' An opcode limit only helps to the extent that it can prevent data structures from growing unboundedly during execution (both because of memory usage, and because of time that may grow in proportion to the size of those structures). The size of stack and altstack is already independently limited. By using O(1) logic for <code>OP_IF</code>, <code>OP_NOTIF</code>, <code>OP_ELSE</code>, and <code>OP_ENDIF</code> as suggested [https://bitslog.com/2017/04/17/new-quadratic-delays-in-bitcoin-scripts/ here] and implemented [https://github.com/bitcoin/bitcoin/pull/16902 here], the only other instance can be avoided as well.</ref> -* '''Sigops limit''' The sigops in tapscripts do not count towards the block-wide limit of 80000 (weighted). Instead, there is a per-script sigops ''budget''. The budget equals 50 + the total serialized size in bytes of the transaction input's witness (including the <code>CCompactSize</code> prefix). Executing a signature opcode (<code>OP_CHECKSIG</code>, <code>OP_CHECKSIGVERIFY</code>, or <code>OP_CHECKSIGADD</code>) with a non-empty signature decrements the budget by 50. If that brings the budget below zero, the script fails immediately. Signature opcodes with unknown public key type and non-empty signature are also counted.<ref>'''The tapscript sigop limit''' The signature opcode limit protects against scripts which are slow to verify due to excessively many signature operations. In tapscript the number of signature opcodes does not count towards the BIP141 or legacy sigop limit. The old sigop limit makes transaction selection in block construction unnecessarily difficult because it is a second constraint in addition to weight. Instead, the number of tapscript signature opcodes is limited by witness weight. Additionally, the limit applies to the transaction input instead of the block and only actually executed signature opcodes are counted. Tapscript execution allows one signature opcode per 50 witness weight units plus one free signature opcode.</ref><ref>'''Parameter choice of the sigop limit''' Regular witnesses are unaffected by the limit as their weight is composed of public key and (<code>SIGHASH_ALL</code>) signature pairs with ''33 + 65'' weight units each (which includes a 1 weight unit <code>CCompactSize</code> tag). This is also the case if public keys are reused in the script because a signature's weight alone is 65 or 66 weight units. However, the limit increases the fees of abnormal scripts with duplicate signatures (and public keys) by requiring additional weight. The weight per sigop factor 50 corresponds to the ratio of BIP141 block limits: 4 mega weight units divided by 80,000 sigops. The "free" signature opcode permitted by the limit exists to account for the weight of the non-witness parts of the transaction input.</ref><ref>'''Why are only signature opcodes counted toward the budget, and not for example hashing opcodes or other expensive operations?''' It turns out that the CPU cost per witness byte for verification of a script consisting of the maximum density of signature checking opcodes (taking the 50 WU/sigop limit into account) is already very close to that of scripts packed with other opcodes, including hashing opcodes (taking the 520 byte stack element limit into account) and <code>OP_ROLL</code> (taking the 1000 stack element limit into account). That said, the construction is very flexible, and allows adding new signature opcodes like <code>CHECKSIGFROMSTACK</code> to count towards the limit through a soft fork. Even if in the future new opcodes are introduced which change normal script cost there is no need to stuff the witness with meaningless data. Instead, the taproot annex can be used to add weight to the witness without increasing the actual witness size.</ref>. +* '''Sigops limit''' The sigops in tapscripts do not count towards the block-wide limit of 80000 (weighted). Instead, there is a per-script sigops ''budget''. The budget equals 50 + the total serialized size in bytes of the transaction input's witness (including the <code>CompactSize</code> prefix). Executing a signature opcode (<code>OP_CHECKSIG</code>, <code>OP_CHECKSIGVERIFY</code>, or <code>OP_CHECKSIGADD</code>) with a non-empty signature decrements the budget by 50. If that brings the budget below zero, the script fails immediately. Signature opcodes with unknown public key type and non-empty signature are also counted.<ref>'''The tapscript sigop limit''' The signature opcode limit protects against scripts which are slow to verify due to excessively many signature operations. In tapscript the number of signature opcodes does not count towards the BIP141 or legacy sigop limit. The old sigop limit makes transaction selection in block construction unnecessarily difficult because it is a second constraint in addition to weight. Instead, the number of tapscript signature opcodes is limited by witness weight. Additionally, the limit applies to the transaction input instead of the block and only actually executed signature opcodes are counted. Tapscript execution allows one signature opcode per 50 witness weight units plus one free signature opcode.</ref><ref>'''Parameter choice of the sigop limit''' Regular witnesses are unaffected by the limit as their weight is composed of public key and (<code>SIGHASH_ALL</code>) signature pairs with ''33 + 65'' weight units each (which includes a 1 weight unit <code>CompactSize</code> tag). This is also the case if public keys are reused in the script because a signature's weight alone is 65 or 66 weight units. However, the limit increases the fees of abnormal scripts with duplicate signatures (and public keys) by requiring additional weight. The weight per sigop factor 50 corresponds to the ratio of BIP141 block limits: 4 mega weight units divided by 80,000 sigops. The "free" signature opcode permitted by the limit exists to account for the weight of the non-witness parts of the transaction input.</ref><ref>'''Why are only signature opcodes counted toward the budget, and not for example hashing opcodes or other expensive operations?''' It turns out that the CPU cost per witness byte for verification of a script consisting of the maximum density of signature checking opcodes (taking the 50 WU/sigop limit into account) is already very close to that of scripts packed with other opcodes, including hashing opcodes (taking the 520 byte stack element limit into account) and <code>OP_ROLL</code> (taking the 1000 stack element limit into account). That said, the construction is very flexible, and allows adding new signature opcodes like <code>CHECKSIGFROMSTACK</code> to count towards the limit through a soft fork. Even if in the future new opcodes are introduced which change normal script cost there is no need to stuff the witness with meaningless data. Instead, the taproot annex can be used to add weight to the witness without increasing the actual witness size.</ref>. * '''Stack + altstack element count limit''' The existing limit of 1000 elements in the stack and altstack together after every executed opcode remains. It is extended to also apply to the size of initial stack. * '''Stack element size limit''' The existing limit of maximum 520 bytes per stack element remains, both in the initial stack and in push opcodes. |
