Merge branch 'master' into cip-0001-rework

CIP-0010/registry.json

@@ -7,6 +7,10 @@
     "transaction_metadatum_label": 88,
     "description": "milkomeda.com - the destination address in the sidechain"
   },
+  {
+    "transaction_metadatum_label": 123,
+    "description": "shareslake.com - Bridge routing information"
+  },
   {
     "transaction_metadatum_label": 309,
     "description": "Proof of Existence record"

CIP-0031/README.md

@@ -3,8 +3,8 @@ CIP: 31
 Title: Reference inputs
 Authors: Michael Peyton Jones <[email protected]>
 Comments-Summary: No comments
-Comments-URI: 
-Status: Draft
+Comments-URI:
+Status: Active
 Type: Standards Track
 Created: 2021-11-29
 License: CC-BY-4.0
@@ -53,17 +53,17 @@ A reference input is a transaction input, which is linked to a particular transa
 
 - A referenced output must exist in the UTXO set.
 - Any value on a referenced output is _not_ considered when balancing the transaction.
-- The spending conditions on referenced outputs are _not_ checked, nor are the witnesses required to be present. 
+- The spending conditions on referenced outputs are _not_ checked, nor are the witnesses required to be present.
     - i.e. validators are not required to pass (nor are the scripts themselves or redeemers required to be present at all), and signatures are not required for pubkey outputs.
 - Referenced outputs are _not_ removed from the UTXO set if the transaction validates.
 - Reference inputs _are_ visible to scripts.
 
 For clarity, the following two behaviours which are present today are unchanged by this proposal:
 
-1. Transactions must _spend_ at least one output.[^1] 
+1. Transactions must _spend_ at least one output.[^1]
 2. Spending an output _does_ require the spending conditions to be checked.[^2]
 
-[^1]: This restriction already exists, and is important. It seems unnecessary, since transactions must always pay fees and fees must come from somewhere, but fees could in principle be paid via reward withdrawals, so the requirement to spend a UTXO is relevant. 
+[^1]: This restriction already exists, and is important. It seems unnecessary, since transactions must always pay fees and fees must come from somewhere, but fees could in principle be paid via reward withdrawals, so the requirement to spend a UTXO is relevant.
 [^2]: That is, this proposal does not change outputs or the spending of outputs, it instead adds a new way of _referring_ to outputs.
 
 ### Script context
@@ -74,7 +74,7 @@ The script context therefore needs to be augmented to contain information about
 Changing the script context will require a new Plutus language version in the ledger to support the new interface.
 The change in the new interface is: a _new_ field is added to the structure which contains the list of reference inputs.
 
-The interface for old versions of the language will not be changed. 
+The interface for old versions of the language will not be changed.
 Scripts with old versions cannot be spent in transactions that include reference inputs, attempting to do so will be a phase 1 transaction validation failure.
 
 ### Extra datums
@@ -93,35 +93,35 @@ The CDDL for transaction bodies will change to the following to reflect the new
 ```
 transaction_body =
  { 0 : set<transaction_input>    ; inputs
- ...      
+ ...
  , ? 16 : set<transaction_input> ; reference inputs
  }
 ```
 
 ## Rationale
 
-The key idea of this proposal is to use UTXOs to carry information. 
-But UTXOs are currently a bad fit for distributing information. 
-Because of locality, we have to include outputs that we use in the transaction, and the only way we have of doing that is to _spend_ them - and a spent output cannot then be referenced by anything else. 
+The key idea of this proposal is to use UTXOs to carry information.
+But UTXOs are currently a bad fit for distributing information.
+Because of locality, we have to include outputs that we use in the transaction, and the only way we have of doing that is to _spend_ them - and a spent output cannot then be referenced by anything else.
 To put it another way: outputs are resource-like, but information is not resource-like.
 
-The solution is to add a way to _inspect_ ("reference") outputs without spending them. 
-This allows outputs to play double duty as resource containers (for the value they carry) and information containers (for the data they carry). 
+The solution is to add a way to _inspect_ ("reference") outputs without spending them.
+This allows outputs to play double duty as resource containers (for the value they carry) and information containers (for the data they carry).
 
 ### Requirements
 
 We have a number of requirements that we need to fulfil.
 - Determinism
     - It must be possible to predict the execution of scripts precisely, given the transaction.
-- Locality 
+- Locality
     - All data involved in transaction validation should be included in the transaction or the outputs which it spends (or references).
 - Non-interference
     - As far as possible, transactions should not interfere with others. The key exception is when transactions consume resources that other transactions want (usually by consuming UTXO entries).
 - Replay protection
     - The system should not be attackable (e.g. allow unexpected data reads) by replaying old traffic.
-- Storage control and garbage-collection incentives 
+- Storage control and garbage-collection incentives
     - The amount of storage required by the system should have controls that prevent it from overloading nodes, and ideally should have incentives to shrink the amount of storage that is used over time.
-- Optimized storage 
+- Optimized storage
     - The system should be amenable to optimized storage solutions.
 - Data transfer into scripts
     - Scripts must have a way to observe the data.
@@ -193,7 +193,7 @@ This is actually a very important feature.
 Since anyone can lock an output with any address, addresses are not that useful for identifying _particular_ outputs on chain, and instead we usually rely on looking for particular tokens in the value locked by the output.
 Hence, if a script is interested in referring to the data attached to a _particular_ output, it will likely want to look at the value that is locked in the output.
 
-For example, an oracle provider would need to distinguish the outputs that they create (with good data) from outputs created by adversaries (with bad data). 
+For example, an oracle provider would need to distinguish the outputs that they create (with good data) from outputs created by adversaries (with bad data).
 They can do this with a token, so long as scripts can then see the token!
 
 ### Hydra

CIP-0032/README.md

@@ -3,8 +3,8 @@ CIP: 32
 Title: Inline datums
 Authors: Michael Peyton Jones <[email protected]>
 Comments-Summary: No comments
-Comments-URI: 
-Status: Draft
+Comments-URI:
+Status: Active
 Type: Standards Track
 Created: 2021-11-29
 License: CC-BY-4.0
@@ -19,10 +19,10 @@ This will allow much simpler communication of datum values between users.
 
 ## Motivation
 
-Conceptually, datums are pieces of data that are attached to outputs. 
+Conceptually, datums are pieces of data that are attached to outputs.
 However, in practice datums are implemented by attaching _hashes_ of datums to outputs, and requiring that the spending transaction provides the actual datum.
 
-This is quite inconvenient for users. 
+This is quite inconvenient for users.
 Datums tend to represent the result of computation done by the party who creates the output, and as such there is almost no chance that the spending party will know the datum without communicating with the creating party.
 That means that either the datum must be communicated between parties off-chain, or communicated on-chain by including it in the witness map of the transaction that creates the output ("extra datums").
 This is also inconvenient for the spending party, who must watch the whole chain to spot it.
@@ -39,7 +39,7 @@ Transaction outputs are changed so that the datum field can contain either a has
 
 The min UTXO value for an output with an inline datum depends on the size of the datum, following the `coinsPerUTxOWord` protocol parameter.
 
-When an output with an inline datum is spent, the spending transaction does not need to provide the datum itself. 
+When an output with an inline datum is spent, the spending transaction does not need to provide the datum itself.
 
 ### Script context
 
@@ -52,7 +52,7 @@ There are two changes in the new version of the interface:
 - The datum field on transaction outputs can either be a hash or the actual datum.
 - The datum field on transaction inputs can either be a hash or the actual datum.
 
-The interface for old versions of the language will not be changed. 
+The interface for old versions of the language will not be changed.
 Scripts with old versions cannot be spent in transactions that include inline datums, attempting to do so will be a phase 1 transaction validation failure.
 
 ### CDDL
@@ -78,10 +78,10 @@ Since inline datums change very little about the model apart from where data is
 
 ### UTXO set size
 
-This proposal gives users a way to put much larger amounts of data into the UTXO set. 
+This proposal gives users a way to put much larger amounts of data into the UTXO set.
 Won’t this lead to much worse UTXO set bloat?
 
-The answer is that we already have a mechanism to discourage this, namely the minimum UTXO value. 
+The answer is that we already have a mechanism to discourage this, namely the minimum UTXO value.
 If inline datums turns out to drive significantly increased space usage, then we may need to increase `coinsPerUTxOWord` in order to keep the UTXO size down.
 That will be costly and inconvenient for users, but will still allow them to use inline datums where they are most useful and the cost is bearable.
 Furthermore, we hope that we will in fact be able to _reduce_ `coinsPerUTxOWord` when the upcoming work on moving the UTXO mostly to on-disk storage is complete.
@@ -165,4 +165,4 @@ Hence we choose both option 1s and do _not_ provide backwards compatibility for
 
 ## References
 
-[1]: Chakravarty, Manuel MT, et al. "The extended UTXO model." 
+[1]: Chakravarty, Manuel MT, et al. "The extended UTXO model."

CIP-0033/README.md

@@ -3,8 +3,8 @@ CIP: 33
 Title: Reference scripts
 Authors: Michael Peyton Jones <[email protected]>
 Comments-Summary: No comments
-Comments-URI: 
-Status: Draft
+Comments-URI:
+Status: Active
 Type: Standards
 Created: 2021-11-29
 License: CC-BY-4.0
@@ -26,7 +26,7 @@ Script sizes pose a significant problem. This manifests itself in two ways:
 
 We would like to alleviate these problems.
 
-The key idea is to use reference inputs and modified outputs which carry actual scripts ("reference scripts"), and allow such reference scripts to satisfy the script witnessing requirement for a transaction. 
+The key idea is to use reference inputs and modified outputs which carry actual scripts ("reference scripts"), and allow such reference scripts to satisfy the script witnessing requirement for a transaction.
 This means that the transaction which _uses_ the script will not need to provide it at all, so long as it referenced an output which contained the script.
 
 ## Specification
@@ -46,10 +46,10 @@ Changing the script context will require a new Plutus language version in the le
 The change is: a new optional field is added to outputs and inputs to represent reference scripts.
 Reference scripts are represented by their hash in the script context.
 
-The interface for old versions of the language will not be changed. 
+The interface for old versions of the language will not be changed.
 Scripts with old versions cannot be spent in transactions that include reference scripts, attempting to do so will be a phase 1 transaction validation failure.
 
-### CDDL 
+### CDDL
 
 The CDDL for transaction outputs will change as follows to reflect the new field.
 ```
@@ -60,7 +60,7 @@ transaction_output =
   , ? ref_script : plutus_script
   ]
 ```
-TODO: can we use a more generic type that allows _any_ script in a forwards-compatible way? 
+TODO: can we use a more generic type that allows _any_ script in a forwards-compatible way?
 
 ## Rationale
 
@@ -89,11 +89,11 @@ This is clearly not what you want: the reference script could be anything, perha
 
 With inline datums, we could put reference scripts in the datum field of outputs.
 
-This approach has two problems. 
+This approach has two problems.
 First, there is a representation confusion: we would need some way to know that a particular datum contained a reference script.
 We could do this implicitly, but it would be better to have an explicit marker.
 
-Secondly, this prevents having an output which is locked by a script that needs a datum _and_ has a reference script in it. 
+Secondly, this prevents having an output which is locked by a script that needs a datum _and_ has a reference script in it.
 While this is a more unusual situation, it's not out of the question.
 For example, a group of users might want to use a Plutus-based multisig script to control the UTXO with a reference script in it.
 

CIP-0036/test-vector.md

@@ -32,22 +32,22 @@ Data to sign (human readable format)
 
 Legacy version (full delegation to one key only):
 ```javascript
-'61284': {
-  '1': '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',
-  '2': '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e',
-  '3': '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
-  '4': 1234,
+61284: {
+  1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',
+  2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e',
+  3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
+  4: 1234,
 },
 ```
 
 New version:
 ```javascript
-'61284': {
-  '1': [['0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663', 1], ['0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee', 3]],
-  '2': '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e',
-  '3': '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
-  '4': 1234,
-  '5': 0
+61284: {
+  1: [['0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663', 1], ['0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee', 3]],
+  2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e',
+  3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
+  4: 1234,
+  5: 0
 },
 ```
 
@@ -81,30 +81,30 @@ New:
 Legacy:
 ```javascript
 {
-  '61284': {
-    '1': '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',
-    '2': '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef',
-    '3': '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
-    '4': 1234,
+  61284: {
+    1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',
+    2: '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef',
+    3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
+    4: 1234,
   },
-  '61285': {
-    '1': '0xcf8e34db193edc930faf64626a0a759dd9ce654874d4b6f255dc2aa8f52313b6dbb9aa1b162b43ed8946668edca920dd34f5a51a14130814fdc86adb6218b501'
+  61285: {
+    1: '0xcf8e34db193edc930faf64626a0a759dd9ce654874d4b6f255dc2aa8f52313b6dbb9aa1b162b43ed8946668edca920dd34f5a51a14130814fdc86adb6218b501'
   }
 }
 ```
 
 New:
 ```javascript
 {
-  '61284': {
-    '1': [['0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663', 1], ['0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee', 3]],
-    '2': '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef',
-    '3': '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
-    '4': 1234,
-    '5': 0
+  61284: {
+    1: [['0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663', 1], ['0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee', 3]],
+    2: '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef',
+    3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
+    4: 1234,
+    5: 0
   },
-  '61285': {
-    '1': '0x3aaa2e6b43c0a96e880a7d70df84dffb2a1a17b19d7a99a6ed27b91d499b32027c43acfbf6dff097af7634b2ee38c8039af259b0b6a64316f02b4ffee28a0608'
+  61285: {
+    1: '0x3aaa2e6b43c0a96e880a7d70df84dffb2a1a17b19d7a99a6ed27b91d499b32027c43acfbf6dff097af7634b2ee38c8039af259b0b6a64316f02b4ffee28a0608'
   }
 }
 ```

CIP-0040/README.md

@@ -2,7 +2,7 @@
 CIP: 40
 Title: Explicit Collateral Output
 Authors: Sebastien Guillemot <[email protected]>, Jared Corduan <[email protected]>, Andre Knispel <[email protected]>
-Status: Proposed
+Status: Active
 Type: Standards
 Created: 2022-02-10
 License: CC-BY-4.0
@@ -28,7 +28,7 @@ Additionally, there cannot be more than *maxColInputs* (protocol parameter) inpu
 
 However,
 
-- Restriction #1 is problematic because hardcore dApp users rarely have UTXO entries that do not contain any tokens. To combat this, wallets have created a special wallet-dependent "collateral" UTXO to reserve for usage of collateral for dApps which is not a great UX. 
+- Restriction #1 is problematic because hardcore dApp users rarely have UTXO entries that do not contain any tokens. To combat this, wallets have created a special wallet-dependent "collateral" UTXO to reserve for usage of collateral for dApps which is not a great UX.
 - Restriction #6 is problematic because wallets want to protect users from signing transactions with large collateral as they cannot verify whether or not the transaction will fail when submitted (especially true for hardware wallets)
 
 # Specification