Merge pull request #2 from bitcoin/master

Update local

9 files changed, 567 insertions, 98 deletions

diff --git a/README.mediawiki b/README.mediawiki
index 106c455..5ab7499 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -994,6 +994,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille
 | Standard
 | Draft
+|-
+| [[bip-0370.mediawiki|370]]
+| Applications
+| PSBT Version 2
+| Andrew Chow
+| Standard
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->
diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 3bf5aec..35d38c2 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -192,7 +192,7 @@ A BIP may only change status from Draft (or Rejected) to Proposed, when the auth
 
 BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.
 
-An Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
+A Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
 
 When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
 
@@ -326,7 +326,7 @@ For example, a preamble might include the following License header:
 
 In this case, the BIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement.
 
-It is also possible to license source code differently from the BIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
+It is also possible to license source code differently from the BIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
 
 For example, a preamble specifying the optional License-Code header might look like:
 
diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 7b61eaa..59bbb99 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -39,6 +39,7 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 # The '''startheight''' specifies the height of the first block at which the bit gains its meaning.
 # The '''timeoutheight''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is considered failed on all descendants of the block.
 # The '''threshold''' specifies the minimum number of block per retarget period which indicate lock-in of the soft fork during the subsequent period.
+# The '''minimum_activation_height''' specifies the height of the first block at which the soft fork is allowed to become active.
 # The '''lockinontimeout''' boolean if set to true, blocks are required to signal in the final period, ensuring the soft fork has locked in by timeoutheight.
 
 ===Selection guidelines===
@@ -47,15 +48,16 @@ The following guidelines are suggested for selecting these parameters for a soft
 
 # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
 # '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes.
-# '''startheight''' should be set to some block height in the future when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. It should be rounded up to the next height which begins a retarget period for simplicity.
+# '''startheight''' should be set to some block height in the future. It should be rounded up to the next height which begins a retarget period for simplicity. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after software with parameters is expected to be released. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state.
 # '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
 # '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet.
+# '''minimum_activation_height''' should be set to several retarget periods in the future if the '''startheight''' is to be very soon after software with parameters is expected to be released. '''minimum_activation_height''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. This allows more time to be spent in the LOCKED_IN state so that nodes can upgrade. This may be set to 0 to have the LOCKED_IN state be a single retarget period.
 # '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
 
 A later deployment using the same bit is possible as long as the startheight is after the previous one's
 timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
 
-'''startheight''' and '''timeoutheight''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4096 blocks (2 retarget intervals) after '''startheight'''.
+'''startheight''', '''timeoutheight''', and '''minimum_activation_height''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4096 blocks (2 retarget intervals) after '''startheight'''.
 
 ===States===
 
@@ -64,8 +66,8 @@ With each block and soft fork, we associate a deployment state. The possible sta
 # '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
 # '''STARTED''' for blocks at or beyond the startheight.
 # '''MUST_SIGNAL''' for one retarget period prior to the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is true.
-# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED (or MUST_SIGNAL) blocks of which at least threshold have the associated bit set in nVersion.
-# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
+# '''LOCKED_IN''' for at least one retarget period after the first retarget period with STARTED (or MUST_SIGNAL) blocks of which at least threshold have the associated bit set in nVersion. A soft fork remains in LOCKED_IN until at least '''minimum_activation_height''' is reached.
+# '''ACTIVE''' for all blocks after the LOCKED_IN state.
 # '''FAILED''' for all blocks after the timeoutheight if LOCKED_IN is not reached.
 
 ===Bit flags===
@@ -93,7 +95,8 @@ During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget
 
 <img src="bip-0008/states.png" align="middle"></img>
 
-Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight''', and ACTIVE will be reached no later than at a height of '''timeoutheight + 2016'''.
+Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight'''.
+Regardless of the value of '''lockinontimeout''', if LOCKED_IN is reached, ACTIVE will be reached either one retarget period later, or at '''minimum_activation_height''', whichever comes later.
 
 The genesis block has state DEFINED for each deployment, by definition.
 
@@ -153,10 +156,14 @@ If we have finished a period of MUST_SIGNAL, we transition directly to LOCKED_IN
         case MUST_SIGNAL:
             return LOCKED_IN;
 
-After a retarget period of LOCKED_IN, we automatically transition to ACTIVE.
+After at least one retarget period of LOCKED_IN, we automatically transition to ACTIVE if the minimum activation height is reached. Otherwise LOCKED_IN continues.
 
         case LOCKED_IN:
-            return ACTIVE;
+            if (block.height >= minimum_activation_height) {
+                return ACTIVE;
+            } else {
+                return LOCKED_IN;
+            }
 
 And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached.
 
diff --git a/bip-0008/states.dot b/bip-0008/states.dot
index aa919ff..8615978 100644
--- a/bip-0008/states.dot
+++ b/bip-0008/states.dot
@@ -7,7 +7,8 @@ digraph {
   "DEFINED" -> "STARTED" [label="height >= start_height"];
   "STARTED" -> "MUST_SIGNAL" [label="height + 2016 >= timeoutheight AND lockinontimeout"];
   "STARTED" -> "FAILED" [label="height >= timeoutheight\nAND\nNOT lockinontimeout"];
-  "LOCKED_IN" -> "ACTIVE" [label="always"];
+  "LOCKED_IN" -> "ACTIVE" [label="height >= minimum_activation_height"];
+  "LOCKED_IN":se -> "LOCKED_IN":ne [label="height < minimum_activation_height"];
   "MUST_SIGNAL" -> "LOCKED_IN" [label="always"];
 
   edge [weight = 1];
diff --git a/bip-0008/states.png b/bip-0008/states.png
index 6477ed3..f15efdb 100644
--- a/bip-0008/states.png
+++ b/bip-0008/states.png
diff --git a/bip-0008/states.svg b/bip-0008/states.svg
index 3503c34..63fe634 100644
--- a/bip-0008/states.svg
+++ b/bip-0008/states.svg
@@ -1,14 +1,13 @@
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by graphviz version 2.42.3 (20191010.1750)
+<!-- Generated by graphviz version 2.46.1 (0)
  -->
-<!-- Title: %3 Pages: 1 -->
-<svg width="563pt" height="348pt"
- viewBox="0.00 0.00 563.00 348.37" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<!-- Pages: 1 -->
+<svg width="937pt" height="348pt"
+ viewBox="0.00 0.00 937.00 348.37" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
 <g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 344.37)">
-<title>%3</title>
-<polygon fill="white" stroke="transparent" points="-4,4 -4,-344.37 559,-344.37 559,4 -4,4"/>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-344.37 933,-344.37 933,4 -4,4"/>
 <!-- DEFINED -->
 <g id="node1" class="node">
 <title>DEFINED</title>
@@ -16,7 +15,7 @@
 <text text-anchor="middle" x="72" y="-312.05" font-family="Arial" font-size="14.00">DEFINED</text>
 </g>
 <!-- DEFINED&#45;&gt;DEFINED -->
-<g id="edge8" class="edge">
+<g id="edge9" class="edge">
 <title>DEFINED:sw&#45;&gt;DEFINED:nw</title>
 <path fill="none" stroke="black" d="M18,-297.75C12,-287.25 0,-287.25 0,-315.75 0,-334.01 4.92,-340.57 10.04,-340.17"/>
 <polygon fill="black" stroke="black" points="12.41,-342.75 18,-333.75 8.02,-337.3 12.41,-342.75"/>
@@ -32,10 +31,10 @@
 <title>DEFINED&#45;&gt;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 &gt;= start_height</text>
+<text text-anchor="middle" x="155" y="-268.55" font-family="Times,serif" font-size="14.00">height &gt;= start_height</text>
 </g>
 <!-- STARTED&#45;&gt;STARTED -->
-<g id="edge9" class="edge">
+<g id="edge10" class="edge">
 <title>STARTED:sw&#45;&gt;STARTED:nw</title>
 <path fill="none" stroke="black" d="M18,-210.75C12,-200.25 0,-200.25 0,-228.75 0,-247.01 4.92,-253.57 10.04,-253.17"/>
 <polygon fill="black" stroke="black" points="12.41,-255.75 18,-246.75 8.02,-250.3 12.41,-255.75"/>
@@ -43,15 +42,15 @@
 <!-- MUST_SIGNAL -->
 <g id="node3" class="node">
 <title>MUST_SIGNAL</title>
-<path fill="#a0a0ff" stroke="black" stroke-width="2" d="M543,-246.75C543,-246.75 459,-246.75 459,-246.75 453,-246.75 447,-240.75 447,-234.75 447,-234.75 447,-222.75 447,-222.75 447,-216.75 453,-210.75 459,-210.75 459,-210.75 543,-210.75 543,-210.75 549,-210.75 555,-216.75 555,-222.75 555,-222.75 555,-234.75 555,-234.75 555,-240.75 549,-246.75 543,-246.75"/>
-<text text-anchor="middle" x="501" y="-225.05" font-family="Arial" font-size="14.00">MUST_SIGNAL</text>
+<path fill="#a0a0ff" stroke="black" stroke-width="2" d="M634,-246.75C634,-246.75 550,-246.75 550,-246.75 544,-246.75 538,-240.75 538,-234.75 538,-234.75 538,-222.75 538,-222.75 538,-216.75 544,-210.75 550,-210.75 550,-210.75 634,-210.75 634,-210.75 640,-210.75 646,-216.75 646,-222.75 646,-222.75 646,-234.75 646,-234.75 646,-240.75 640,-246.75 634,-246.75"/>
+<text text-anchor="middle" x="592" y="-225.05" font-family="Arial" font-size="14.00">MUST_SIGNAL</text>
 </g>
 <!-- STARTED&#45;&gt;MUST_SIGNAL -->
 <g id="edge2" class="edge">
 <title>STARTED&#45;&gt;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 &gt;= timeoutheight AND lockinontimeout</text>
+<path fill="none" stroke="black" d="M126.18,-228.75C222.75,-228.75 424.19,-228.75 527.64,-228.75"/>
+<polygon fill="black" stroke="black" points="527.94,-232.25 537.94,-228.75 527.94,-225.25 527.94,-232.25"/>
+<text text-anchor="middle" x="332" y="-235.55" font-family="Times,serif" font-size="14.00">height + 2016 &gt;= timeoutheight AND lockinontimeout</text>
 </g>
 <!-- FAILED -->
 <g id="node4" class="node">
@@ -64,57 +63,64 @@
 <title>STARTED&#45;&gt;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 &gt;= timeoutheight</text>
-<text text-anchor="middle" x="139" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text>
-<text text-anchor="middle" x="139" y="-151.55" font-family="Times,serif" font-size="14.00">NOT lockinontimeout</text>
+<text text-anchor="middle" x="162.5" y="-181.55" font-family="Times,serif" font-size="14.00">height &gt;= timeoutheight</text>
+<text text-anchor="middle" x="162.5" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text>
+<text text-anchor="middle" x="162.5" y="-151.55" font-family="Times,serif" font-size="14.00">NOT lockinontimeout</text>
 </g>
 <!-- LOCKED_IN -->
 <g id="node5" class="node">
 <title>LOCKED_IN</title>
-<path fill="#ffffa0" stroke="black" stroke-width="2" d="M543,-129.75C543,-129.75 459,-129.75 459,-129.75 453,-129.75 447,-123.75 447,-117.75 447,-117.75 447,-105.75 447,-105.75 447,-99.75 453,-93.75 459,-93.75 459,-93.75 543,-93.75 543,-93.75 549,-93.75 555,-99.75 555,-105.75 555,-105.75 555,-117.75 555,-117.75 555,-123.75 549,-129.75 543,-129.75"/>
-<text text-anchor="middle" x="501" y="-108.05" font-family="Arial" font-size="14.00">LOCKED_IN</text>
+<path fill="#ffffa0" stroke="black" stroke-width="2" d="M634,-129.75C634,-129.75 550,-129.75 550,-129.75 544,-129.75 538,-123.75 538,-117.75 538,-117.75 538,-105.75 538,-105.75 538,-99.75 544,-93.75 550,-93.75 550,-93.75 634,-93.75 634,-93.75 640,-93.75 646,-99.75 646,-105.75 646,-105.75 646,-117.75 646,-117.75 646,-123.75 640,-129.75 634,-129.75"/>
+<text text-anchor="middle" x="592" y="-108.05" font-family="Arial" font-size="14.00">LOCKED_IN</text>
 </g>
 <!-- STARTED&#45;&gt;LOCKED_IN -->
-<g id="edge6" class="edge">
+<g id="edge7" class="edge">
 <title>STARTED&#45;&gt;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 &lt; timeoutheight</text>
-<text text-anchor="middle" x="434" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text>
-<text text-anchor="middle" x="434" y="-151.55" font-family="Times,serif" font-size="14.00">threshold reached</text>
+<path fill="none" stroke="black" d="M126.08,-218.75C163.11,-212.29 213.23,-202.95 257,-192.75 329.78,-175.79 346.33,-165.17 419,-147.75 454.78,-139.17 495.06,-130.94 527.74,-124.62"/>
+<polygon fill="black" stroke="black" points="528.47,-128.04 537.63,-122.72 527.15,-121.17 528.47,-128.04"/>
+<text text-anchor="middle" x="503.5" y="-181.55" font-family="Times,serif" font-size="14.00">height &lt; timeoutheight</text>
+<text text-anchor="middle" x="503.5" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text>
+<text text-anchor="middle" x="503.5" y="-151.55" font-family="Times,serif" font-size="14.00">threshold reached</text>
 </g>
 <!-- MUST_SIGNAL&#45;&gt;LOCKED_IN -->
-<g id="edge5" class="edge">
+<g id="edge6" class="edge">
 <title>MUST_SIGNAL&#45;&gt;LOCKED_IN</title>
-<path fill="none" stroke="black" d="M501,-210.28C501,-191.69 501,-161.99 501,-140.25"/>
-<polygon fill="black" stroke="black" points="504.5,-140 501,-130 497.5,-140 504.5,-140"/>
-<text text-anchor="middle" x="520" y="-166.55" font-family="Times,serif" font-size="14.00">always</text>
+<path fill="none" stroke="black" d="M592,-210.28C592,-191.69 592,-161.99 592,-140.25"/>
+<polygon fill="black" stroke="black" points="595.5,-140 592,-130 588.5,-140 595.5,-140"/>
+<text text-anchor="middle" x="616.5" y="-166.55" font-family="Times,serif" font-size="14.00">always</text>
 </g>
 <!-- FAILED&#45;&gt;FAILED -->
-<g id="edge11" class="edge">
+<g id="edge12" class="edge">
 <title>FAILED:sw&#45;&gt;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&#45;&gt;LOCKED_IN -->
+<!-- LOCKED_IN&#45;&gt;LOCKED_IN -->
+<g id="edge5" class="edge">
+<title>LOCKED_IN:se&#45;&gt;LOCKED_IN:ne</title>
+<path fill="none" stroke="black" d="M646,-93.75C652,-83.25 664,-83.25 664,-111.75 664,-130.01 659.08,-136.57 653.96,-136.17"/>
+<polygon fill="black" stroke="black" points="655.98,-133.3 646,-129.75 651.59,-138.75 655.98,-133.3"/>
+<text text-anchor="middle" x="796.5" y="-108.05" font-family="Times,serif" font-size="14.00">height &lt; minimum_activation_height</text>
+</g>
 <!-- ACTIVE -->
 <g id="node6" class="node">
 <title>ACTIVE</title>
-<path fill="#a0ffa0" stroke="black" stroke-width="2" d="M543,-42.75C543,-42.75 459,-42.75 459,-42.75 453,-42.75 447,-36.75 447,-30.75 447,-30.75 447,-18.75 447,-18.75 447,-12.75 453,-6.75 459,-6.75 459,-6.75 543,-6.75 543,-6.75 549,-6.75 555,-12.75 555,-18.75 555,-18.75 555,-30.75 555,-30.75 555,-36.75 549,-42.75 543,-42.75"/>
-<text text-anchor="middle" x="501" y="-21.05" font-family="Arial" font-size="14.00">ACTIVE</text>
+<path fill="#a0ffa0" stroke="black" stroke-width="2" d="M634,-42.75C634,-42.75 550,-42.75 550,-42.75 544,-42.75 538,-36.75 538,-30.75 538,-30.75 538,-18.75 538,-18.75 538,-12.75 544,-6.75 550,-6.75 550,-6.75 634,-6.75 634,-6.75 640,-6.75 646,-12.75 646,-18.75 646,-18.75 646,-30.75 646,-30.75 646,-36.75 640,-42.75 634,-42.75"/>
+<text text-anchor="middle" x="592" y="-21.05" font-family="Arial" font-size="14.00">ACTIVE</text>
 </g>
 <!-- LOCKED_IN&#45;&gt;ACTIVE -->
 <g id="edge4" class="edge">
 <title>LOCKED_IN&#45;&gt;ACTIVE</title>
-<path fill="none" stroke="black" d="M501,-93.55C501,-81.91 501,-66.3 501,-52.99"/>
-<polygon fill="black" stroke="black" points="504.5,-52.93 501,-42.93 497.5,-52.93 504.5,-52.93"/>
-<text text-anchor="middle" x="520" y="-64.55" font-family="Times,serif" font-size="14.00">always</text>
+<path fill="none" stroke="black" d="M592,-93.55C592,-81.91 592,-66.3 592,-52.99"/>
+<polygon fill="black" stroke="black" points="595.5,-52.93 592,-42.93 588.5,-52.93 595.5,-52.93"/>
+<text text-anchor="middle" x="730.5" y="-64.55" font-family="Times,serif" font-size="14.00">height &gt;= minimum_activation_height</text>
 </g>
 <!-- ACTIVE&#45;&gt;ACTIVE -->
-<g id="edge10" class="edge">
+<g id="edge11" class="edge">
 <title>ACTIVE:sw&#45;&gt;ACTIVE:nw</title>
-<path fill="none" stroke="black" d="M447,-6.75C441,3.75 429,3.75 429,-24.75 429,-43.01 433.92,-49.57 439.04,-49.17"/>
-<polygon fill="black" stroke="black" points="441.41,-51.75 447,-42.75 437.02,-46.3 441.41,-51.75"/>
+<path fill="none" stroke="black" d="M538,-6.75C532,3.75 520,3.75 520,-24.75 520,-43.01 524.92,-49.57 530.04,-49.17"/>
+<polygon fill="black" stroke="black" points="532.41,-51.75 538,-42.75 528.02,-46.3 532.41,-51.75"/>
 </g>
 </g>
 </svg>
diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index cbd3a2a..182404f 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -35,19 +35,19 @@ The terminology related to keychains used in the wild varies widely, for example
 
 ==Motivation==
 
-Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human friendly serialization of the BIP32 root key (or BIP32 extended keys in general) which makes paper backups or manually restoring the key more error-prone. BIP39 was designed solve this problem but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
+Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human friendly serialization of the BIP32 root key (or BIP32 extended keys in general) which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
 
-Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support of BIP32 extended private keys so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenarios are particularly satisfactory for security reasons. For example, some wallets may be inherently less secure like hot wallets on smartphones, Join Market servers, Lightning Network nodes. Having multiple seeds is far from desirable especially for those who rely on split key or redundancy backups in different geological locations. Adding is necessarily difficult and may result in users being more lazy with subsequent keys, such that compromises security or leads to key loss.
+Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenarios are particularly satisfactory for security reasons. For example, some wallets may be inherently less secure like hot wallets on smartphones, Join Market servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
 
-There is added complication with wallets that implement other standards, or no standards at all. Bitcoin Core wallet uses a WIF as the ''hdseed'', and yet other wallets use different mnemonic schemes like Electrum to derive the BIP32 root key. Other cryptocurrencies like Monero also use a different mnemonic scheme entirely.
+There is added complication with wallets that implement other standards, or no standards at all. Bitcoin Core wallet uses a WIF as the ''hdseed'', and yet other wallets like Electrum use different mnemonic schemes to derive the BIP32 root key. Other cryptocurrencies like Monero also use an entirely different mnemonic scheme.
 
-Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" to derive a mnemonic/seed, and then process the mnemonic into a BIP32 key, or private key. We can use BIP32 itself to derive the "initial entropy" to then recreate the same mnemonic or seed according the specific application standard of the target wallet. We can use a BIP44 like categorization to ensure unitform derivation according to the target application type.
+Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" to derive a mnemonic/seed, and then process the mnemonic into a BIP32 key, or private key. We can use BIP32 itself to derive the "initial entropy" to then recreate the same mnemonic or seed according to the specific application standard of the target wallet. We can use a BIP44-like categorization to ensure uniform derivation according to the target application type.
 
 ==Specification==
 
 We assume a single BIP32 master root key. This specification is not concerned with how this was derived (e.g. directly or via a mnemonic scheme such as BIP39).
 
-For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation truncating the rest
+For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation truncating the rest.
 
 The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].
 
@@ -87,7 +87,7 @@ xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu
 
 OUTPUT
 * DERIVED KEY=cca20ccb0e9a90feb0912870c3323b24874b0ca3d8018c4b96d0b97c0e82ded0
-* DERIVED ENTROPY=6bea85e51a05e6dbaf2ccee05097758213807997ba936589cef01c8f19c0079f395a0cd045efa3438677f3ef9ad34c9a68506626c5a17e51ed5e177852ee7fdc
+* DERIVED ENTROPY=efecfbccffea313214232d29e71563d941229afb4338c21f9517c41aaa0d16f00b83d2a09ef747e7a64e8e2bd5a14869e693da66ce94ac2da570ab7ee48618f7
 
 * DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111
 
@@ -104,18 +104,18 @@ OUTPUT
 
 ==Applications==
 
-Application number define how entropy will be used post processing. Some basic examples follow:
+The Application number defines how entropy will be used post processing. Some basic examples follow:
 
-Derivation path uses the format <code>m/83696968'/{app_no}'/{index}'</code> where ''{app_no}'' path for the application, and ''{index}'' in the index.
+Derivation path uses the format <code>m/83696968'/{app_no}'/{index}'</code> where ''{app_no}'' is the path for the application, and ''{index}'' is the index.
 
 ===BIP39===
 Application number: 39'
 
-Truncate trailing (least significant) bytes of the entropy to the number of bits required to map to the relevant word length 128 bits for 12 words, 256 bits for 24 words.
+Truncate trailing (least significant) bytes of the entropy to the number of bits required to map to the relevant word length: 128 bits for 12 words, 256 bits for 24 words.
 
 The derivation path format is: <code>m/83696968'/39'/{language}'/{words}'/{index}'</code>
 
-Example a BIP39 mnemonic with 12 English words (first index) would have the path <code>m/83696968'/39'/0'/12'/0'</code> the next key would be <code>m/83696968'/39'/0'/12'/1'</code> etc.
+Example: a BIP39 mnemonic with 12 English words (first index) would have the path <code>m/83696968'/39'/0'/12'/0'</code>, the next key would be <code>m/83696968'/39'/0'/12'/1'</code> etc.
 
 Language Table
 
@@ -284,17 +284,17 @@ Note on GPG key capabilities on smartcard/hardware devices:
 
 GPG capable smart-cards SHOULD be be loaded as follows: The encryption slot SHOULD be loaded with the ENCRYPTION capable key; the authentication slot SHOULD be loaded with the AUTHENTICATION capable key. The signature capable slot SHOULD be loaded with the SIGNATURE capable key.
 
-However, depending on available slots on the smart-card, and preferred policy, the CERTIFY capable key MAY be flagged with CERTIFY and SIGNATURE capabilities and loaded into the SIGNATURE capable slot (for example where the smart-card has only three slots and the CERTIFY capability is required on the same card). In this case, the SIGNATURE capable sub-key would be disregarded because the CERTIFY capable key serves dual purpose.
+However, depending on available slots on the smart-card, and preferred policy, the CERTIFY capable key MAY be flagged with CERTIFY and SIGNATURE capabilities and loaded into the SIGNATURE capable slot (for example where the smart-card has only three slots and the CERTIFY capability is required on the same card). In this case, the SIGNATURE capable sub-key would be disregarded because the CERTIFY capable key serves a dual purpose.
 
 ==Backwards Compatibility==
 
 This specification is not backwards compatible with any other existing specification.
 
-This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived, as such this standard is allows it to derive wallets with initialization schemes like BIP39 or Electrum wallet style mnemonics.
+This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived. As such, this standard is able to derive wallets with initialization schemes like BIP39 or Electrum wallet style mnemonics.
 
 ==Discussion==
 
-The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (k) be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This acts in an abundance of caution to ward off unwanted side effects should k be used for a dual purpose, including as a nonce hash(k), where undesirable and unforeseen interactions could occur.
+The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur.
 
 ==Acknowledgements==
 
@@ -306,10 +306,10 @@ BIP32, BIP39
 
 ==Footnotes==
 
-[1] There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users should iterate to the next index).
+[1] There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users to iterate to the next index).
 
 From BIP32:
-> In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or ≥ n, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2<sup>127</sup>.)
+In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or ≥ n, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2<sup>127</sup>.)
 
 ==Copyright==
 
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 9f6ad41..75fea0e 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -115,9 +115,75 @@ The currently defined global types are as follows:
 | The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
+| Transaction Version
+| <tt>PSBT_GLOBAL_TX_VERSION = 0x02</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| The 32-bit little endian signed integer representing the version number of the transaction being created. Note that this is not the same as the PSBT version number specified by the PSBT_GLOBAL_VERSION field.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Fallback Locktime
+| <tt>PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime.
+|
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Input Count
+| <tt>PSBT_GLOBAL_INPUT_COUNT = 0x04</tt>
+| None
+| No key data
+| <tt><compact size uint></tt>
+| Compact size unsigned integer representing the number of inputs in this PSBT.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Output Count
+| <tt>PSBT_GLOBAL_OUTPUT_COUNT = 0x05</tt>
+| None
+| No key data
+| <tt><compact size uint></tt>
+| Compact size unsigned integer representing the number of outputs in this PSBT.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Transaction Modifiable Flags
+| <tt>PSBT_GLOBAL_TX_MODIFIABLE = 0x06</tt>
+| None
+| No key data
+| <tt><single byte boolean> <single byte boolean> <bitvector></tt>
+| A single byte boolean (0 for False, 1 for True) representing whether inputs can be modified, followed by a single byte boolean representing whether outputs can be modified.
+|
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| SIGHASH_SINGLE Inputs
+| <tt>PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS = 0x07</tt>
+| None
+| No key data
+| <tt><bit vector></tt>
+| A bit vector representing which input indexes use SIGHASH_SINGLE. If the bit for an index is set to 1, then the input and output pair at that index are tied together with SIGHASH_SINGLE and must be moved together.
+|
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
 | PSBT Version Number
 | <tt>PSBT_GLOBAL_VERSION = 0xFB</tt>
 | None
@@ -126,7 +192,7 @@ The currently defined global types are as follows:
 | The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Proprietary Use Type
@@ -137,7 +203,7 @@ The currently defined global types are as follows:
 | Any value data as defined by the proprietary type user.
 |
 |
-| 0
+| 0, 2
 | 174
 |}
 
@@ -163,18 +229,18 @@ The currently defined per-input types are defined as follows:
 | The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref>
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Witness UTXO
 | <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt>
 | None
 | No key data
-| <tt><64-bit uint> <scriptPubKeylen> <scriptPubKey></tt>
+| <tt><64-bit int> <scriptPubKeylen> <scriptPubKey></tt>
 | The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Partial Signature
@@ -185,7 +251,7 @@ The currently defined per-input types are defined as follows:
 | The signature as would be pushed to the stack from a scriptSig or witness.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Sighash Type
@@ -196,7 +262,7 @@ The currently defined per-input types are defined as follows:
 | The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Redeem Script
@@ -207,7 +273,7 @@ The currently defined per-input types are defined as follows:
 | The redeemScript for this input if it has one.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Witness Script
@@ -218,7 +284,7 @@ The currently defined per-input types are defined as follows:
 | The witnessScript for this input if it has one.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | BIP 32 Derivation Path
@@ -229,7 +295,7 @@ The currently defined per-input types are defined as follows:
 | The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Finalized scriptSig
@@ -240,7 +306,7 @@ The currently defined per-input types are defined as follows:
 | The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Finalized scriptWitness
@@ -251,7 +317,7 @@ The currently defined per-input types are defined as follows:
 | The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Proof-of-reserves commitment
@@ -262,7 +328,7 @@ The currently defined per-input types are defined as follows:
 | The UTF-8 encoded commitment message string for the proof-of-reserves.  See [[bip-0127.mediawiki|BIP 127]] for more information.
 |
 |
-| 0
+| 0, 2
 | [[bip-0127.mediawiki|127]]
 |-
 | RIPEMD160 preimage
@@ -273,7 +339,7 @@ The currently defined per-input types are defined as follows:
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>RIPEMD160</tt> algorithm
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | SHA256 preimage
@@ -284,7 +350,7 @@ The currently defined per-input types are defined as follows:
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | HASH160 preimage
@@ -295,7 +361,7 @@ The currently defined per-input types are defined as follows:
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm followed by the <tt>RIPEMD160</tt> algorithm
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | HASH256 preimage
@@ -306,9 +372,64 @@ The currently defined per-input types are defined as follows:
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm twice
 |
 |
-| 0
+| 0, 2
 | 174
 |-
+| Previous TXID
+| <tt>PSBT_IN_PREVIOUS_TXID = 0x0e</tt>
+| None
+| No key data
+| <tt><txid></tt>
+| 32 byte txid of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Spent Output Index
+| <tt>PSBT_IN_OUTPUT_INDEX = 0x0f</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 32 bit little endian integer representing the index of the output being spent in the transaction with the txid of PSBT_IN_PREVIOUS_TXID.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Sequence Number
+| <tt>PSBT_IN_SEQUENCE = 0x10</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| The 32 bit unsigned little endian integer for the sequence number of this input. If omitted, the sequence number is assumed to be the final sequence number (0xffffffff).
+|
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Required Time-based Locktime
+| <tt>PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 32 bit unsigned little endian integer greater than or equal to 500000000 representing the minimum Unix timestamp that this input requires to be set as the transaction's lock time.
+|
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Required Height-based Locktime
+| <tt>PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12</tt>
+| None
+| No key data
+| <tt><32-bit uiht></tt>
+| 32 bit unsigned little endian integer less than 500000000 representing the minimum block height that this input requires to be set as the transaction's lock time.
+|
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
 | Proprietary Use Type
 | <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
 | <tt><identifierlen> <identifier> <subtype> <subkeydata></tt>
@@ -317,7 +438,7 @@ The currently defined per-input types are defined as follows:
 | Any value data as defined by the proprietary type user.
 |
 |
-| 0
+| 0, 2
 | 174
 |}
 
@@ -345,7 +466,7 @@ determine which outputs are change outputs and verify that the change is returni
 | The redeemScript for this output if it has one.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Witness Script
@@ -356,7 +477,7 @@ determine which outputs are change outputs and verify that the change is returni
 | The witnessScript for this output if it has one.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | BIP 32 Derivation Path
@@ -367,9 +488,31 @@ determine which outputs are change outputs and verify that the change is returni
 | The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
+| Output Amount
+| <tt>PSBT_OUT_AMOUNT = 0x03</tt>
+| None
+| No key data
+| <tt><64-bit int></tt>
+| 64 bit signed little endian integer representing the output's amount in satoshis.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Output Script
+| <tt>PSBT_OUT_SCRIPT = 0x03</tt>
+| None
+| No key data
+| <tt><script></tt>
+| The script for this output, also known as the scriptPubKey. Must be omitted in PSBTv0. Must be provided in PSBTv2.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
 | Proprietary Use Type
 | <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
 | <tt><identifierlen> <identifier> <subtype> <subkeydata></tt>
@@ -378,7 +521,7 @@ determine which outputs are change outputs and verify that the change is returni
 | Any value data as defined by the proprietary type user.
 |
 |
-| 0
+| 0, 2
 | 174
 |}
 
@@ -494,9 +637,9 @@ for input,i in enumerate(psbt.inputs):
         assert(sha256d(non_witness_utxo) == psbt.tx.input[i].prevout.hash)
         if redeemScript.exists:
             assert(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey == P2SH(redeemScript))
-            sign_non_witness(redeemScript)
+            sign_non_witness(redeemScript, i)
         else:
-            sign_non_witness(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey)
+            sign_non_witness(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey, i)
     else if witness_utxo.exists:
         if redeemScript.exists:
             assert(witness_utxo.scriptPubKey == P2SH(redeemScript))
@@ -504,10 +647,10 @@ for input,i in enumerate(psbt.inputs):
         else:
             script = witness_utxo.scriptPubKey
         if IsP2WPKH(script):
-            sign_witness(P2PKH(script[2:22]))
+            sign_witness(P2PKH(script[2:22]), i)
         else if IsP2WSH(script):
             assert(script == P2WSH(witnessScript))
-            sign_witness(witnessScript)
+            sign_witness(witnessScript, i)
     else:
         assert False
 </pre>
@@ -714,8 +857,8 @@ The following are valid PSBTs:
 ** Base64 String: <pre>cHNidP8BAFICAAAAAZ38ZijCbFiZ/hvT3DOGZb/VXXraEPYiCXPfLTht7BJ2AQAAAAD/////AfA9zR0AAAAAFgAUezoAv9wU0neVwrdJAdCdpu8TNXkAAAAATwEENYfPAto/0AiAAAAAlwSLGtBEWx7IJ1UXcnyHtOTrwYogP/oPlMAVZr046QADUbdDiH7h1A3DKmBDck8tZFmztaTXPa7I+64EcvO8Q+IM2QxqT64AAIAAAACATwEENYfPAto/0AiAAAABuQRSQnE5zXjCz/JES+NTzVhgXj5RMoXlKLQH+uP2FzUD0wpel8itvFV9rCrZp+OcFyLrrGnmaLbyZnzB1nHIPKsM2QxqT64AAIABAACAAAEBKwBlzR0AAAAAIgAgLFSGEmxJeAeagU4TcV1l82RZ5NbMre0mbQUIZFuvpjIBBUdSIQKdoSzbWyNWkrkVNq/v5ckcOrlHPY5DtTODarRWKZyIcSEDNys0I07Xz5wf6l0F1EFVeSe+lUKxYusC4ass6AIkwAtSriIGAp2hLNtbI1aSuRU2r+/lyRw6uUc9jkO1M4NqtFYpnIhxENkMak+uAACAAAAAgAAAAAAiBgM3KzQjTtfPnB/qXQXUQVV5J76VQrFi6wLhqyzoAiTACxDZDGpPrgAAgAEAAIAAAAAAACICA57/H1R6HV+S36K6evaslxpL0DukpzSwMVaiVritOh75EO3kXMUAAACAAAAAgAEAAIAA</pre>
 
 * Case: PSBT with unknown types in the inputs.
-** Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0000</pre>
-** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAA=</pre>
+** Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f0000</pre>
+** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAA=</pre>
 
 * Case: PSBT with `PSBT_GLOBAL_XPUB`.
 ** Bytes in Hex: <pre>70736274ff01009d0100000002710ea76ab45c5cb6438e607e59cc037626981805ae9e0dfd9089012abb0be5350100000000ffffffff190994d6a8b3c8c82ccbcfb2fba4106aa06639b872a8d447465c0d42588d6d670000000000ffffffff0200e1f505000000001976a914b6bc2c0ee5655a843d79afedd0ccc3f7dd64340988ac605af405000000001600141188ef8e4ce0449eaac8fb141cbf5a1176e6a088000000004f010488b21e039e530cac800000003dbc8a5c9769f031b17e77fea1518603221a18fd18f2b9a54c6c8c1ac75cbc3502f230584b155d1c7f1cd45120a653c48d650b431b67c5b2c13f27d7142037c1691027569c503100008000000080000000800001011f00e1f5050000000016001433b982f91b28f160c920b4ab95e58ce50dda3a4a220203309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c47304402202d704ced830c56a909344bd742b6852dccd103e963bae92d38e75254d2bb424502202d86c437195df46c0ceda084f2a291c3da2d64070f76bf9b90b195e7ef28f77201220603309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c1827569c5031000080000000800000008000000000010000000001011f00e1f50500000000160014388fb944307eb77ef45197d0b0b245e079f011de220202c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b11047304402204cb1fb5f869c942e0e26100576125439179ae88dca8a9dc3ba08f7953988faa60220521f49ca791c27d70e273c9b14616985909361e25be274ea200d7e08827e514d01220602c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b1101827569c5031000080000000800000008000000000000000000000220202d20ca502ee289686d21815bd43a80637b0698e1fbcdbe4caed445f6c1a0a90ef1827569c50310000800000008000000080000000000400000000</pre>
@@ -817,16 +960,16 @@ Given the above PSBT, a transaction extractor must create this Bitcoin transacti
 * Bytes in Hex: <pre>0200000000010258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd7500000000da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752aeffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d01000000232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f000400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00000000</pre>
 
 Given these two PSBTs with unknown key-value pairs:
-* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f00</pre>
-** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwA=</pre>
+* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f00</pre>
+** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwA=</pre>
 
-* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f00</pre>
-** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre>
+* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708100f0102030405060708090a0b0c0d0e0f00</pre>
+** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre>
 
 A combiner which orders keys lexicographically must produce the following PSBT:
 
-* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f00</pre>
-* Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8KDwECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PCg8BAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwoPAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre>
+* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f00</pre>
+* Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8K8AECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PCvABAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwrwAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre>
 
 ==Rationale==
 
diff --git a/bip-0370.mediawiki b/bip-0370.mediawiki
new file mode 100644
index 0000000..8dd557a
--- /dev/null
+++ b/bip-0370.mediawiki
@@ -0,0 +1,305 @@
+<pre>
+  BIP: 370
+  Layer: Applications
+  Title: PSBT Version 2
+  Author: Andrew Chow <achow101@gmail.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0370
+  Status: Draft
+  Type: Standards Track
+  Created: 2021-01-14
+  License: BSD-2-Clause
+</pre>
+
+==Introduction==
+
+===Abstract===
+
+This document proposes a second version of the Partially Signed Bitcoin Transaction format
+described in BIP 174 which allows for inputs and outputs to be added to the PSBT after creation.
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+===Motivation===
+
+Partially Signed Bitcoin Transaction Version 0 as described in BIP 174 is unable to have new
+inputs and outputs be added to the transaction. The fixed global unsigned transaction
+cannot be changed which prevents any additional inputs or outputs to be added.
+PSBT Version 2 is intended to rectify this problem.
+
+An additional benficial side effect is that all information for a given input or output will be
+provided by its <tt><input-map></tt> or <tt><output-map></tt>. With Version 0, to retrieve
+all of the information for an input or output, data would need to be found in two locations:
+the <tt><input-map></tt>/<tt><output-map></tt> and the global unsigned transaction. PSBT
+Version 2 now moves all related information to one place.
+
+==Specification==
+
+PSBT Version 2 (PSBTv2) only specifies new fields and field inclusion/exclusion requirements.
+
+<tt>PSBT_GLOBAL_UNSIGNED_TX</tt> must be excluded in PSBTv2.
+<tt>PSBT_GLOBAL_VERSION</tt> must be included in PSBTv2 and set to version number 2<ref>'''What happened to version number 1?'''
+Version number 1 is skipped because PSBT Version 0 has been colloquially referred to as version 1. Originally this BIP was to be
+version 1, but because it has been colloquially referred to as version 2 during its design phrase, it was decided to change the
+version number to 2 so that there would not be any confusion</ref>.
+
+The new global types for PSBT Version 2 are as follows:
+
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+|-
+| Transaction Version
+| <tt>PSBT_GLOBAL_TX_VERSION = 0x02</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| The 32-bit little endian signed integer representing the version number of the transaction being created. Note that this is not the same as the PSBT version number specified by the PSBT_GLOBAL_VERSION field.
+| 2
+| 0
+| 2
+|-
+| Fallback Locktime
+| <tt>PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime.
+|
+| 0
+| 2
+|-
+| Input Count
+| <tt>PSBT_GLOBAL_INPUT_COUNT = 0x04</tt>
+| None
+| No key data
+| <tt><compact size uint></tt>
+| Compact size unsigned integer representing the number of inputs in this PSBT.
+| 2
+| 0
+| 2
+|-
+| Output Count
+| <tt>PSBT_GLOBAL_OUTPUT_COUNT = 0x05</tt>
+| None
+| No key data
+| <tt><compact size uint></tt>
+| Compact size unsigned integer representing the number of outputs in this PSBT.
+| 2
+| 0
+| 2
+|-
+| Transaction Modifiable Flags
+| <tt>PSBT_GLOBAL_TX_MODIFIABLE = 0x06</tt>
+| None
+| No key data
+| <tt><8-bit uint></tt>
+| An 8 bit little endian unsigned integer as a bitfield for various transaction modification flags. Bit 0 is the Inputs Modifiable Flag and indicates whether inputs can be modified. Bit 1 is the Outputs Modifiable Flag and indicates whether outputs can be modified. Bit 2 is the Has SIGHASH_SINGLE flag and indicates whether the transaction has a SIGHASH_SINGLE signature who's input and output pairing must be preserved. Bit 2 essentially indicates that the Constructor must iterate the inputs to determine whether and how to add an input.
+|
+| 0
+| 2
+|}
+
+The new per-input types for PSBT Version 2 are defined as follows:
+
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+|-
+| Previous TXID
+| <tt>PSBT_IN_PREVIOUS_TXID = 0x0e</tt>
+| None
+| No key data
+| <tt><txid></tt>
+| 32 byte txid of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent.
+| 2
+| 0
+| 2
+|-
+| Spent Output Index
+| <tt>PSBT_IN_OUTPUT_INDEX = 0x0f</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 32 bit little endian integer representing the index of the output being spent in the transaction with the txid of PSBT_IN_PREVIOUS_TXID.
+| 2
+| 0
+| 2
+|-
+| Sequence Number
+| <tt>PSBT_IN_SEQUENCE = 0x10</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| The 32 bit unsigned little endian integer for the sequence number of this input. If omitted, the sequence number is assumed to be the final sequence number (0xffffffff).
+|
+| 0
+| 2
+|-
+| Required Time-based Locktime
+| <tt>PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 32 bit unsigned little endian integer greater than or equal to 500000000 representing the minimum Unix timestamp that this input requires to be set as the transaction's lock time.
+|
+| 0
+| 2
+|-
+| Required Height-based Locktime
+| <tt>PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12</tt>
+| None
+| No key data
+| <tt><32-bit uiht></tt>
+| 32 bit unsigned little endian integer less than 500000000 representing the minimum block height that this input requires to be set as the transaction's lock time.
+|
+| 0
+| 2
+|}
+
+The new per-output types for PSBT Version 2 are defined as follows:
+
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+|-
+| Output Amount
+| <tt>PSBT_OUT_AMOUNT = 0x03</tt>
+| None
+| No key data
+| <tt><64-bit int></tt>
+| 64 bit signed little endian integer representing the output's amount in satoshis.
+| 2
+| 0
+| 2
+|-
+| Output Script
+| <tt>PSBT_OUT_SCRIPT = 0x03</tt>
+| None
+| No key data
+| <tt><script></tt>
+| The script for this output, also known as the scriptPubKey. Must be omitted in PSBTv0. Must be provided in PSBTv2.
+| 2
+| 0
+| 2
+|}
+
+===Determining Lock Time===
+
+The nLockTime field of a transaction is determined by inspecting the PSBT_GLOBAL_PREFERRED_LOCKTIME and each input's PSBT_IN_REQUIRED_TIME_LOCKTIME and PSBT_IN_REQUIRED_HEIGHT_LOCKTIME fields.
+If none of the inputs have a PSBT_IN_REQUIRED_TIME_LOCKTIME and PSBT_IN_REQUIRED_HEIGHT_LOCKTIME, then PSBT_GLOBAL_PREFERRED_LOCKTIME must be used.
+If PSBT_GLOBAL_PREFERRED_LOCKTIME is not provided, then it is assumed to be 0.
+
+If one or more inuts have a PSBT_IN_REQUIRED_TIME_LOCKTIME or PSBT_IN_REQUIRED_HEIGHT_LOCKTIME, then the field chosen is the one which is supported by all of the inputs.
+This can be determined by looking at all of the inputs which specify a locktime in either of those fields, and choosing the field which is present in all of those inputs.
+Inputs not specifying a lock time field can take both types of lock times, as can those that specify both.
+The lock time chosen is then the maximum value of the chosen type of lock time.
+
+===Unique Identification===
+
+PSBTv2s can be uniquely identified by constructing an unsigned transaction given the information provided in the PSBT and computing the transaction ID of that transaction.
+Since PSBT_IN_SEQUENCE can be changed by Updaters and Combiners, the sequence number in this unsigned transaction must be set to 0 (not final, nor the sequence in PSBT_IN_SEQUENCE).
+The lock time in this unsigned transaction must be computed as described previously.
+
+==Roles==
+
+PSBTv2 introduces new roles and modifies some existing roles.
+
+===Creator===
+
+In PSBTv2, the Creator initializes the PSBT with 0 inputs and 0 outputs.
+The PSBT version number is set to 2. The transaction version number must be set to at least 2. <ref>'''Why does the transaction version number need to be at least 2?''' The transaction version number is part of the validation rules for some features such as OP_CHECKSEQUENCEVERIFY. Since it is backwards compatible, and there are other ways to disable those features (e.g. through sequence numbers), it is easier to require transactions be able to support these features than to try to negotiate the transaction version number.</ref>
+The Creator should also set PSBT_GLOBAL_PREFERRED_LOCKTIME.
+If the Creator is not also a Constructor and will be giving the PSBT to others to add inputs and outputs, the PSBT_GLOBAL_TX_MODIFIABLE field must be present and and the Inputs Modifiable and Outputs Modifiable flags set appropriately.
+If the Creator is a Constructor and no inputs and outputs will be added by other entities, PSBT_GLOBAL_TX_MODIFIABLE may be omitted.
+
+===Constructor===
+
+This Constructor is only present for PSBTv2.
+Once a Creator initializes the PSBT, a constructor will add inputs and outputs.
+Before any input or output may be added, the constructor must check the PSBT_GLOBAL_TX_MODIFIABLE field.
+Inputs may only be added if the Inputs Modifiable flag is True.
+Outputs may only be added if the Outputs Modifiable flag is True.
+
+When an input or output is added, the corresponding PSBT_GLOBAL_INPUT_COUNT or PSBT_GLOBAL_OUTPUT_COUNT must be incremeted to reflect the number of inputs and outputs in the PSBT.
+When an input is added, it must have PSBT_IN_PREVIOUS_TXID and PSBT_IN_OUTPUT_INDEX set.
+When an output is added, it must have PSBT_OUT_VALUE and PSBT_OUT_OUTPUT_SCRIPT set.
+If the input has a required timelock, Constructors must set the requisite timelock field.
+If the input has a required time based timelock, then PSBT_IN_REQUIRED_TIME_TIMELOCK must be set
+If the input has a required height based timelock, then PSBT_IN_REQUIRED_HEIGHT_TIMELOCK must be set.
+If an input has both types of timelocks, then both may be set.
+In some cases, an input that can allow both types, but a particular branch supporting only one type of timelock will be taken, then the type of timelock that will be used can be the only one set.
+
+If an input being added specifies a required time lock, then the Constructor must iterate through all of the existing inputs and ensure that the time lock types are compatible.
+Additionally, if during this iteration, it finds that any inputs have signatures, it must ensure that the newly added input does not change the transaction's locktime.
+If the newly added input has an incompatible time lock, then it must not be added.
+If it changes the transaction's locktime when there are existing signatures, it must not be added.
+
+If the Has SIGHASH_SINGLE flag is True, then the Constructor must iterate through the inputs and find the inputs which have signatures that use SIGHASH_SINGLE.
+The same number of inputs and outputs must be added before those inputs and their corresponding outputs.
+
+A Constructor may choose to declare that no further inputs and outputs can be added to the transaction by setting the booleans in PSBT_GLOBAL_TX_MODIFIABLE to False or by removing this field entirely.
+
+A single entity is likely to be both a Creator and Constructor.
+
+===Updater===
+
+For PSBTv2, an Updater can set the sequence number.
+
+===Signer===
+
+For PSBTv2s, a signer must update the PSBT_GLOBAL_TX_MODIFIABLE field after signing inputs so that it accurately reflects the state of the PSBT.
+If the Signer added a signature that does not use SIGHASH_ANYONECANPAY, the Input Modifiable flag must be set to False.
+If the Signer added a signature that does not use SIGHASH_NONE, the Outputs Modifiable flag must be set to False.
+If the Signer added a signature that uses SIGHASH_SINGLE, the Has SIGHASH_SINGLE flag must be set to True.
+
+===Transaction Extractor===
+
+For PSBTv2s, the transaction is constructed using the PSBTv2 fields.
+The lock time for this transaction is determined as described in the Determining Lock Time section.
+The Extractor should produce a fully valid, network serialized transaction if all inputs are complete.
+
+==Backwards Compatibility==
+
+PSBTv2 shares the same gemeric format as PSBTv0 as defined in BIP 174. Parsers for PSBTv0 should
+be able to deserialize PSBTv2 with only changes to support the new fields.
+
+However PSBTv2 is incompatible with PSBTv0, and vice versa due to the use of the PSBT_GLOBAL_VERSION.
+This incompatibility is intentional so that PSBT_GLOBAL_UNSIGNED_TX could be removed in PSBTv2.
+However it is possible to convert a PSBTv2 to a PSBTv0 by creating an unsigned
+transaction from the PSBTv2 fields.
+
+==Test Vectors==
+
+TBD
+
+==Rationale==
+
+<references/>
+
+==Reference implementation==
+
+The reference implementation of the PSBT format is available at https://github.com/achow101/bitcoin/tree/psbt2.