From 6351cf10ce8cc63a90ec6862ad37c83a9cb49c78 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Tue, 28 Jul 2020 14:43:01 +0200 Subject: [PATCH 01/35] adds signed transaction payload RFC --- .../0000-signed-transaction-payload.md | 862 ++++++++++++++++++ 1 file changed, 862 insertions(+) create mode 100644 text/0000-signed-transaction-payload/0000-signed-transaction-payload.md diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md new file mode 100644 index 000000000..9bd667e5e --- /dev/null +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -0,0 +1,862 @@ +--- +tags: RFC, draft +--- +# Draft RFC: Signed Transaction Payload + ++ Feature name: signed_transaction_payload ++ Start date: 2020-07-10 ++ RFC PR: [iotaledger/protocol-rfcs#18](https://github.com/iotaledger/protocol-rfcs/pull/18) + +# Summary + +This RFC defines a new transaction structure for Chrysalis Phase 2, which replaces the current notion of bundles. Specifically, this RFC describes the transaction payload to be embedded into a [message](https://github.com/iotaledger/protocol-rfcs/pull/17). + +# Motivation + +The current IOTA protocol uses so-called **transactions** (which are vertices in the Tangle), where each transaction defines either an input or output. A grouping of those input/output transaction vertices make up a so-called **bundle** which transfers the given values as an atomic unit (the entire bundle is applied or none of it). The input transactions define the funds to consume to create the deposits onto the output transactions target addresses. Additionally, to accommodate the rather big WOTS signatures, additional transaction vertices might be part of the bundle in order to carry parts of the signature which don't fit into one transaction vertex. + +The bundle concept has proven to be tedious, spawning a plethora of problems: +* Since the data making up the bundle is split across multiple vertices, it complicates the validation of the entire transfer. Instead of being able to immediately tell whether a bundle is valid or not, a node implementation must first collect all parts of the bundle before any actual validation can happen. This increases the complexity of the node implementation immensely. +* Reattaching the tail transaction of a bundle causes the entire transfer to be reapplied. +* Due to the split across multiple transaction vertices and having to do PoW for each of them, a created bundle might already be lazy in terms of where it attaches, reducing its chances to get confirmed. + +To fix the problems mentioned above and creating a more flexible transaction structure, we want to achieve a self-contained transaction structure defining the data of the entire transfer as a payload to be embedded into a message. + +The new transaction structure should fulfill following criteria: +* Support for Ed25519 (and thus reusable addresses) and WOTS signatures. +* Support for adding new types of signature schemes, addresses, inputs and outputs as part of protocol upgrades. +* Self-contained as in being able to validate the transaction immediately after receiving it. +* Enable unspent transaction outputs (UTXO) as inputs instead of an account based model. (UTXO enables easier double-spend detection) + +# Detailed design + +## UTXO + +The *unspent transaction output* (UTXO) model defines a ledger state where balances are not directly associated to addresses but to the outputs of transactions. In this model, transactions specify the outputs of previous transactions as inputs, which are consumed in order to create new outputs. A transaction must consume the entirety of the specified inputs. + +Using an UTXO based model provides several benefits: +* Parallel validation of transactions. +* Easier double-spend detection, since conflicting transactions would reference the same UTXO. +* Replay-protection which is especially important when having reusable addresses. Replaying the same transaction would manifest itself as already being applied or existent and thus not have any impact. +* Technically seen, balances are no longer associated to addresses which raises the level of abstraction and thus enables other types of outputs. Consider for example a type of output which specifies the balance to be unlocked by a transaction using this output which must fulfill a very hard Proof-of-Work difficulty or supply some other unlock criteria etc. + +Within a transaction using UTXOs, inputs and outputs make up the to be signed data of the transaction. The section unlocking the inputs is called *unlock block*. An unlock block may contain a signature proving ownership of a given input's address and/or other unlock criteria. + +The following image depicts the flow of funds using UTXO: + +![UTXO flow](https://i.imgur.com/h3uxf6N.png) + +The way UTXOs are referenced is further described in the Structure section of this RFC. + +## Structure + +### Serialized Layout + +A Signed Transaction payload is made up of two parts: +1. The Unsigned Transaction part which contains the inputs, outputs and an optional embedded payload. +2. The Unlock Blocks which unlock the Unsigned Transaction's inputs. In case the unlock block contains a signature, it signs the entire Unsigned Transaction part. + +All values are serialized in little-endian encoding. The serialized form of the transaction is deterministic, meaning the same logical transaction always results in the same serialized byte sequence. + +Following table structure describes the entirety of a Signed Transaction payload's serialized form: +
+ Data Types + + + + + + + + + + + + + + + + + + + + + + + + + + +
NotationSizeDescription
byte1 byteAn unsigned 8-bit integer.
varintvariable + A numerical value using N amount of bytes needed to represent its value. See docs on the Protocol Buffers site. +
ByteArray1 varint (length) + L * bytesA variable sized array of bytes where the leading varint L denotes the size of the array.
ByteArray[N]N * bytesA fixed sized array of bytes (without a leading varint N denoting the size of the array).
i.e. ByteArray[32]: A byte array with 32 bytes.
+
+ +
+ Subschema Notation + + + + + + + + + + + + + + + + + +
NameDescription
oneOfOne of the listed subschemas.
optOneOfOptionally one of the listed subschemas.
anyOfAny (one or more) of the listed subschemas.
+
+ +

+ + + + + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Payload Typevarint + Set to value 0 to denote a Signed Transaction payload. +
Transaction oneOf +
+ Unsigned Transaction +
+ Describes the essence data making up a transaction by defining its inputs and outputs and an optional payload. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Transaction Typebyte/varint + Set to value 0 to denote an Unsigned Transaction. +
Inputs Countbyte/varintThe amount of inputs proceeding.
Inputs anyOf +
+ UTXO Input +
+ Describes an input which references an unspent transaction output to consume. +
+ + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Input Typebyte/varint + Set to value 0 to denote an UTXO Input. +
Transaction IDByteArray[32]The BLAKE2b-256 hash of the transaction from which the UTXO comes from.
Transaction Output Indexbyte/varintThe index of the output on the referenced transaction to consume.
+
+
Outputs Countbyte/varintThe amount of outputs proceeding.
Outputs anyOf +
+ SigLockedSingleDeposit +
+ Describes a deposit to a single address which is unlocked via a signature. +
+ + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Output Typebyte/varint + Set to value 0 to denote a SigLockedSingleDeposit. +
Address oneOf +
+ Ed25519 Address + + + + + + + + + + + + + + + + +
NameTypeDescription
Address Typebyte/varint + Set to value 0 to denote an Ed25519 Address. +
AddressByteArray[32]The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key.
+
+
+ WOTS Address + + + + + + + + + + + + + + + + +
NameTypeDescription
Address Typebyte/varint + Set to value 1 to denote a WOTS Address. +
AddressByteArray[49]The T5B1 encoded WOTS address.
+
+
Amountuint64The amount of tokens to deposit with this SigLockedSingleDeposit output.
+
+
Payload Lengthbyte/varintThe length in bytes of the optional payload.
Payload optOneOf +
+ Unsigned Data Payload +
+ Describes a payload containing data without any specification what the data means. +
+ + + + + + + + + + + + + + + + +
NameTypeDescription
Payload Typebyte/varint + Set to value 2 to denote an Unsigned Data payload. +
DataByteArrayThe data of the Unsigned Data payload.
+
+
+ Signed Data Payload +
+ Describes a payload containing signed data (and its corresponding Ed25519 public key and signature) without + any specification what the data means. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Payload Typebyte/varint + Set to value 3 to denote an Signed Data payload. +
DataByteArrayThe data of the Signed Data payload.
Public KeyByteArray[32]The Ed25519 public key used to verify the signature.
SignatureByteArray[64]The signature signing the data.
+
+
+ Indexation Payload +
+ Describes a payload which is used to instruct the node to index the Message + of which it is part of. +
+ + + + + + + + + + + + + + + + +
NameTypeDescription
Payload Typebyte/varint + Set to value 4 to denote an Indexation payload. +
TagByteArray[16]The tag which is used to index the Signed Transaction's hash.
+
+
+
+
Unlock Blocks Countbyte/varintThe count of unlock blocks proceeding. Must match count of inputs specified.
Unlock Blocks anyOf +
+ Signature Unlock Block +
+ Defines an unlock block containing signature(s) unlocking input(s). +
+ + + + + + + + + + + + + + + +
NameTypeDescription
Unlock Typebyte/varint + Set to value 0 to denote a Signature Unlock Block. +
Signature oneOf +
+ Ed25519 Signature + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Signature Typebyte/varint + Set to value 0 to denote an Ed25519 Signature. +
Public keyByteArray[32]The public key of the Ed25519 keypair which is used to verify the signature.
SignatureByteArray[64]The signature signing the serialized Unsigned Transaction.
+
+
+ WOTS Signature + + + + + + + + + + + + + + + + +
NameTypeDescription
Signature Typebyte/varint + Set to value 1 to denote a WOTS Signature. +
SignatureByteArrayThe signature signing the serialized Unsigned Transaction.
+
+
+
+
+ Reference Unlock Block +
+ References a previous unlock block in order to substitute the duplication of the same unlock block data for inputs which unlock through the same data. +
+ + + + + + + + + + + + + + + + +
NameTypeDescription
Unlock Typebyte/varint + Set to value 1 to denote a Reference Unlock Block. +
ReferencevarintRepresents the index of a previous unlock block.
+
+
+ +### Transaction Parts + +In general, all parts of a Signed Transaction begin with a byte describing the type of the given part in order to keep the flexibility to introduce new types/versions of the given part in the future. + +#### Unsigned Transaction / Essence Data + +As described, the Unsigned Transaction of a Signed Transaction carries the inputs, outputs and an optional payload. The Unsigned Transaction is an explicit type of transaction and therefore starts with its own Transaction Type byte which is of value 0. + +An Unsigned Transaction must contain at least one input and output. + +##### Inputs + +The Inputs part holds the inputs to consume, respectively to fund the outputs of the Unsigned Transaction. There is only one type of input as of now, the UTXO Input. In the future, more types of inputs may be specified as part of protocol upgrades. + +Each defined input must be accompanied by a corresponding Unlock Block at the same index in the Unlock Blocks part of the Signed Transaction. If multiple inputs can be unlocked through the same Unlock Block, then the given Unlock Block only needs to be specified at the index of the first input which gets unlocked by it. Subsequent inputs which are unlocked through the same data must have a Reference Unlock Block pointing to the previous Unlock Block. This ensures that no duplicate data needs to occur in the same transaction. + +###### UTXO Input + +
+ Format + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Input Typebyte/varint + Set to value 0 to denote a UTXO Input. +
Transaction IDByteArray[64]The transaction reference from which the UTXO comes from.
Transaction Output Indexbyte/varintThe index of the output on the referenced transaction to consume.
+
+

+ +An UTXO Input is an input which references an output of a previous transaction by using the given transaction's BLAKE2b-256 hash + the index of the output on that transaction. An UTXO Input must be accompanied by an Unlock Block for the corresponding type of output the UTXO Input is referencing. + +Example: If the output the input references outputs to an Ed25519 address, then the corresponding unlock block must be of type Signature Unlock Block holding an Ed25519 signature. + +##### Outputs + +The Outputs part holds the outputs to create with this Unsigned Transaction. There is only one type of output as of now, the SigLockedSingleDeposit. + +###### SigLockedSingleDeposit + +
+ Format + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Output Typebyte/varint + Set to value 0 to denote a SigLockedSingleDeposit. +
Address (oneOf) +
+ Ed25519 Address + + + + + + + + + + + + + + + + +
NameTypeDescription
Address Typebyte/varint + Set to value 0 to denote an Ed25519 Address. +
AddressByteArray[32]The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key.
+
+
+ WOTS Address + + + + + + + + + + + + + + + + +
NameTypeDescription
Address Typebyte/varint + Set to value 1 to denote a WOTS Address. +
AddressByteArray[49]The T5B1 encoded WOTS address.
+
+
Amountuint64The amount of tokens to deposit with this SigLockedSingleDeposit output.
+
+ +

+ +The SigLockedSingleDeposit defines an output (with a certain amount) to a single target address which is unlocked via a signature proving ownership over the given address. Such output can hold addresses of different types. + +##### Payload + +The payload part of an Unsigned Transaction can hold an optional payload. This payload does not affect the validity of the Unsigned Transaction. If the transaction is not valid, then the payload must also be discarded. + +Supported payload types to be embedded into an Unsigned Transaction: + +| Name | Type Value | +| --------------------- | ---------- | +| Unsigned Data Payload | 2 | +| Signed Data Payload | 3 | +| Indexation Payload | 4 | + +#### Unlock Blocks + +The Unlock Blocks part holds the unlock blocks unlocking inputs within an Unsigned Transaction. + +There are different types of Unlock Blocks: + + + + + + + + + + + + + + + + +
NameValueDescription
Signature Unlock Block0An unlock block holding one or more signatures unlocking one or more inputs.
Reference Unlock Block1An unlock block which must reference a previous unlock block which unlocks also the input at the same index as this Reference Unlock Block.
+ +##### Signature Unlock Block + +
+ Format + + + + + + + + + + + + + + + +
NameTypeDescription
Unlock Typebyte/varint + Set to value 0 to denote a Signature Unlock Block. +
Signature oneOf +
+ Ed25519 Signature + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Signature Typebyte/varint + Set to value 0 to denote an Ed25519 Signature. +
Public keyByteArray[32]The public key of the Ed25519 keypair which is used to verify the signature.
SignatureByteArray[64]The signature signing the serialized Unsigned Transaction.
+
+
+ WOTS Signature + + + + + + + + + + + + + + + + +
NameTypeDescription
Signature Typebyte/varint + Set to value 1 to denote a WOTS Signature. +
SignatureByteArrayThe signature signing the serialized Unsigned Transaction.
+
+
+
+ +A Signature Unlock Block defines an Unlock Block which holds one or more signatures unlocking one or more inputs. Such block signs the entire Unsigned Transaction part of a Signed Transaction including the optional payload. + +##### Reference Unlock block + +
+ Format + + + + + + + + + + + + + + + + +
NameTypeDescription
Unlock Typebyte/varint + Set to value 1 to denote a Reference Unlock Block. +
ReferencevarintRepresents the index of a previous unlock block.
+
+ +A Reference Unlock Block defines an Unlock Block which references a previous Unlock Block (which must not be another Reference Unlock Block). It must be used if multiple inputs can be unlocked through the same origin Unlock Block. + +Example: +Consider an Unsigned Transaction containing UTXO Inputs A, B and C, where A and C are both spending the UTXOs originating from the same Ed25519 address. The Unlock Block part must thereby have following structure: + +| Index | Must Contain | +| ----- | ---------------------------------------------------------------------------------------------------------------- | +| 0 | A Signature Unlock Block holding the corresponding Ed25519 signature to unlock A and C. | +| 1 | A Signature Unlock Block which unlocks B. | +| 2 | A Reference Unlock Block which references index 0, since C also gets unlocked by the same signature as A. | + +## Validation + +A Signed Transaction payload has different validation stages, since some validation steps can only be executed if certain information becomes present, respectively should have become present. We therefore distinguish between syntactical- and semantic validation. + +### Syntactical Validation + +This validation can commence as soon as the transaction data has been received in its entirety. It validates the structure but not the signatures of the transaction. If the transaction does not pass this stage, it must not be further broadcasted and can be discarded right away. + +Following criteria defines whether the transaction passes the syntactical validation: +* `Transaction Type` value must be 0, denoting an `Unsigned Transaction`. +* Inputs: + * `Inputs Count` must be 0 < x < 127. + * At least one input must be specified. + * `Input Type` value must be 0, denoting an `UTXO Input`. + * `UTXO Input`: + * `Transaction Output Index` must be 0 ≤ x < 127. + * Every combination of `Transaction ID` + `Transaction Output Index` must be unique in the inputs set. + * Inputs must be in lexicographical order of their serialized form.1 +* Outputs: + * `Outputs Count` must be 0 < x < 127. + * At least one output must be specified. + * `Output Type` must be 0, denoting a `SigLockedSingleDeposit`. + * `SigLockedSingleDeposit`: + * `Address Type` must either be 0 or 1, denoting an `Ed25519`- or `WOTS address`. + * If `Address` is of type `WOTS address`, its bytes must be valid `T5B1` bytes. + * The `Address` must be unique in the set of `SigLockedSingleDeposits`. + * `Amount` must be > 0. + * Outputs must be in lexicographical order by their serialized form.1 + * Accumulated output balance must not exceed the total supply of tokens `2'779'530'283'277'761`. +* `Payload Length` must be 0 (to indicate that there's no payload) or be valid for the specified payload type. +* `Payload Type` must be one of the supported payload types if `Payload Length` is not 0. +* `Unlock Blocks Count` must match the amount of inputs. Must be 0 < x ≤ 127. +* `Unlock Block Type` must either be 0 or 1, denoting a `Signature Unlock Block` or `Reference Unlock block`. +* `Signature Unlock Blocks` must define either an `Ed25519`- or `WOTS Signature` and be unique. +* `Reference Unlock Blocks` must specify a previous `Unlock Block` which is not of type `Reference Unlock Block`. The reference index must therefore be < the index of the `Reference Unlock Block`. +* Given the type and length information, the Signed Transaction must consume the entire byte array the `Payload Length` field in the Message defines. + +1 ensures that serialization of the transaction becomes deterministic, meaning that libraries always produce the same bytes given the logical transaction. + +### Semantic Validation + +Semantic validation starts when a message which is part of a confirmation cone of a milestone, is processed in the [White-Flag ordering](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0005-white-flag/0005-white-flag.md#deterministically-ordering-the-tangle). Semantics are only validated during White-Flag confirmations to enforce an ordering which can be understood by all the nodes (i.e. milestone cones), no matter in which order transactions are received. Otherwise, if semantic validation would occur as soon as a transaction would be received, it could potentially lead to nodes having different views of the UTXOs available to spend. + + +Processing transactions in the White-Flag ordering enables users to spend UTXOs which are in the same milestone confirmation cone, if their transaction comes after the funding transaction in the mentioned White-Flag ordering. It is recommended that users spending unconfirmed UTXOs attach their message directly onto the message containing the source transaction. + +Following criteria defines whether the transaction passes the semantic validation: +1. The UTXOs the transaction references must be known (booked) and unspent. +1. The transaction is spending the entirety of the funds of the referenced UTXOs to the ouputs. +1. The address type of the referenced UTXO must match the signature type contained in the corresponding Signature Unlock Block. +1. The Signature Unlock Blocks are valid, i.e. the signatures prove ownership over the addresses of the referenced UTXOs. +1. Signature Unlock Blocks unlocking multiple inputs must only appear once (be unique) at same index of the first input it unlocks. All other inputs unlocked by the same Signature Unlock Block must have a companion Reference Unlock Block at the same index as the corresponding input which points to the origin Signature Unlock Block. + +If a transaction passes the semantic validation, its referenced UTXOs must be marked as spent and the corresponding new outputs must be booked/specified in the ledger. The booked transaction then also becomes part of the White-Flag Merkle tree inclusion set. + +Transactions which do not pass semantic validation are ignored. Their UTXOs are not marked as spent and neither are their outputs booked into the ledger. + +## Miscellaneous + +### Absent transaction timestamp + +A transaction timestamp whether signed or not, does not actually tell when the transaction was issued. Therefore the timestamp has been left out from the transaction structure. The correct way to determine the issuance time is to use a combination of the solidification and confirmation timestamps of the message embedding the transaction. + +### How to compute the balance + +Since the ledger no longer is account based, meaning that balances are directly mapped to addresses, computing the balance involves iterating over all UTXOs of which their destination address is the address in question and then accumulating their amounts. + +### Reusing the same address with Ed25519 + +While creating multiple signatures with Ed25519 does not reduce security, reusing the same address over and over again not only drastically reduces the privacy of yourself but also all other people in the UTXO chain of the moved funds. Applications and services are therefore instructed to create new addresses per deposit, in order to circumvent the privacy issues stemming from address reuse. In essence, Ed25519 support allows for smaller transaction sizes and to safely spend funds which were sent to an already used deposit address. Ed25519 addresses are not meant to be used like an e-mail address. See this [Bitcoin wiki entry](https://en.bitcoin.it/wiki/Address_reuse#:~:text=The%20most%20private%20and%20secure,a%20brand%20new%20bitcoin%20address.) for further information on how address reuse reduces privacy and this [article](https://en.bitcoin.it/wiki/Receiving_donations_with_bitcoin) why the same should be applied to donation addresses. + +# Drawbacks + +The new transaction format is the core data type within the IOTA ecosystem. Changing it means that all projects need to accommodate for it including client libraries, blueprints, PoC and applications using IOTA in general. There is no way to keep the changes backwards compatible. Additionally, these changes are breaking, meaning that all nodes must upgrade in order to further participate in the network. + +Local snapshots can also no longer be simply represented by a list of addresses and their balances, since the ledger is now made up of the UTXOs on which the actual funds reside on. Therefore local snapshot file schemes have to be adjusted to incorporate the transaction hashes, output indices and then the destination addresses plus the balances. + +# Rationale and alternatives + +Introducing this new transaction structure allows for further extensions in the future, in order to accommodate new requirements. With the support for Ed25519 addresses/signatures, transaction size is drastically reduced and allows for safe re-signing in case funds appear to be deposited onto a previous generated address. Due to the switch to a complete binary transaction, size is further reduced, saving network bandwidth and processing time. The new structure is backwards compatible with "Kerl" WOTS addresses and therefore allows both current methods of signing transactions to co-exist. + +Other transaction structures have been considered but they would have misused existing transaction fields to accommodate for new features, instead of putting them into a proper descriptive structure. Additionally, those ideas would have not been safe against replay attacks, deeming reusing the old transaction structure for example for Ed25519 addresses/signatures as infeasible. + +Not switching to the new transaction structure described in this RFC leads to people being open to loss of funds because of WOTS address re-use and not being able to properly extend the protocol further down the line. + +# Unresolved questions + +- What parts of the design do you expect to resolve through the RFC process + before this gets merged? +- What parts of the design do you expect to resolve through the implementation + of this feature before stabilization? +- What related issues do you consider out of scope for this RFC that could be + addressed in the future independently of the solution that comes out of this + RFC? \ No newline at end of file From 846bf74558f10e385b1a78877dacd14028a39d42 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Tue, 28 Jul 2020 14:45:12 +0200 Subject: [PATCH 02/35] removes hackmd headers --- .../0000-signed-transaction-payload.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index 9bd667e5e..952043015 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -1,8 +1,3 @@ ---- -tags: RFC, draft ---- -# Draft RFC: Signed Transaction Payload - + Feature name: signed_transaction_payload + Start date: 2020-07-10 + RFC PR: [iotaledger/protocol-rfcs#18](https://github.com/iotaledger/protocol-rfcs/pull/18) From 4584870ae658db3a3b5aa34f1863ca86ff9aef77 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Tue, 28 Jul 2020 20:16:16 +0200 Subject: [PATCH 03/35] normalizes RFC --- .../0000-signed-transaction-payload.md | 152 +++++++----------- 1 file changed, 60 insertions(+), 92 deletions(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index 952043015..6eed6e61a 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -33,7 +33,7 @@ Using an UTXO based model provides several benefits: * Parallel validation of transactions. * Easier double-spend detection, since conflicting transactions would reference the same UTXO. * Replay-protection which is especially important when having reusable addresses. Replaying the same transaction would manifest itself as already being applied or existent and thus not have any impact. -* Technically seen, balances are no longer associated to addresses which raises the level of abstraction and thus enables other types of outputs. Consider for example a type of output which specifies the balance to be unlocked by a transaction using this output which must fulfill a very hard Proof-of-Work difficulty or supply some other unlock criteria etc. +* Technically seen, balances may no longer be associated to addresses which raises the level of abstraction and thus enables other types of outputs. Consider for example a type of output which specifies the balance to be unlocked by a transaction which must fulfill a very hard Proof-of-Work difficulty or supply some other unlock criteria etc. Within a transaction using UTXOs, inputs and outputs make up the to be signed data of the transaction. The section unlocking the inputs is called *unlock block*. An unlock block may contain a signature proving ownership of a given input's address and/or other unlock criteria. @@ -54,40 +54,8 @@ A Signed Transaction payload is made up of two parts: All values are serialized in little-endian encoding. The serialized form of the transaction is deterministic, meaning the same logical transaction always results in the same serialized byte sequence. Following table structure describes the entirety of a Signed Transaction payload's serialized form: -
- Data Types - - - - - - - - - - - - - - - - - - - - - - - - - - -
NotationSizeDescription
byte1 byteAn unsigned 8-bit integer.
varintvariable - A numerical value using N amount of bytes needed to represent its value. See docs on the Protocol Buffers site. -
ByteArray1 varint (length) + L * bytesA variable sized array of bytes where the leading varint L denotes the size of the array.
ByteArray[N]N * bytesA fixed sized array of bytes (without a leading varint N denoting the size of the array).
i.e. ByteArray[32]: A byte array with 32 bytes.
-
- -
+* [Data Type Notation](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md#data-types) +*
Subschema Notation @@ -114,7 +82,7 @@ Following table structure describes the entirety of a Signed Transaction
- + @@ -134,7 +102,7 @@ Following table structure describes the entirety of a Signed Transaction
NameTypeType Description
- + @@ -160,7 +128,7 @@ Following table structure describes the entirety of a Signed Transaction
NameName Type Description
- + @@ -200,7 +168,7 @@ Following table structure describes the entirety of a Signed Transaction
NameName Type Description
- + @@ -215,10 +183,10 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -534,7 +534,7 @@ The Outputs part holds the outputs to create with this Unsigned Transa - + @@ -556,7 +556,7 @@ The Outputs part holds the outputs to create with this Unsigned Transa - + @@ -629,7 +629,7 @@ There are different types of Unlock Blocks: - + @@ -647,7 +647,7 @@ There are different types of Unlock Blocks: - + @@ -669,7 +669,7 @@ There are different types of Unlock Blocks: - + @@ -705,7 +705,7 @@ A Signature Unlock Block defines an Unlock Block which holds one o - + From c4597ac5238ad9fbc6432f46104b9626e17248c8 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Thu, 30 Jul 2020 19:19:33 +0200 Subject: [PATCH 05/35] fixes address type ordering --- .../0000-signed-transaction-payload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index 0d03d338e..6a6e756e6 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -752,7 +752,7 @@ Following criteria defines whether the transaction passes the syntactical valida * At least one output must be specified. * `Output Type` must be 0, denoting a `SigLockedSingleDeposit`. * `SigLockedSingleDeposit`: - * `Address Type` must either be 0 or 1, denoting an `Ed25519`- or `WOTS address`. + * `Address Type` must either be 0 or 1, denoting a `WOTS`- or `Ed25519` address . * If `Address` is of type `WOTS address`, its bytes must be valid `T5B1` bytes. * The `Address` must be unique in the set of `SigLockedSingleDeposits`. * `Amount` must be > 0. From 15739aa0938ea668522608ac4e0180a823298007 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Fri, 31 Jul 2020 12:10:31 +0200 Subject: [PATCH 06/35] replaces sentence with bad grammer with Charlie's suggestion --- .../0000-signed-transaction-payload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index 6a6e756e6..3a6b56e14 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -731,7 +731,7 @@ Consider an Unsigned Transaction containing UTXO Inputs A, B and C ## Validation -A Signed Transaction payload has different validation stages, since some validation steps can only be executed if certain information becomes present, respectively should have become present. We therefore distinguish between syntactical- and semantic validation. +A Signed Transaction payload has different validation stages, since some validation steps can only be executed at the point when certain information has (or has not) been received. We therefore distinguish between syntactical- and semantic validation. ### Syntactical Validation From 2ee7b0fe36f263a4317886194081a701efd3f697 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Mon, 17 Aug 2020 08:09:52 +0200 Subject: [PATCH 07/35] fixes wrong denotation value --- .../0000-signed-transaction-payload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index 3a6b56e14..4922aba68 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -216,7 +216,7 @@ Following table structure describes the entirety of a Signed Transaction From 3d4e7cebd650fe47cbce50f0b61cb29a2b4868b5 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Fri, 4 Sep 2020 15:56:45 +0200 Subject: [PATCH 08/35] use fixed size integers --- .../0000-signed-transaction-payload.md | 75 ++++++++++--------- 1 file changed, 39 insertions(+), 36 deletions(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index 4922aba68..4d5c3276a 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -87,7 +87,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -108,14 +108,14 @@ Following table structure describes the entirety of a Signed Transaction - + - + @@ -134,7 +134,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -146,7 +146,7 @@ Following table structure describes the entirety of a Signed Transaction - +
NameName Type Description
Address oneOf
- Ed25519 Address + WOTS Address - + @@ -226,21 +194,21 @@ Following table structure describes the entirety of a Signed Transaction - - + +
NameName Type Description
Address Type byte/varint - Set to value 0 to denote an Ed25519 Address. + Set to value 0 to denote a WOTS Address.
AddressByteArray[32]The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key.ByteArray[49]The T5B1 encoded WOTS address.
- WOTS Address + Ed25519 Address - + @@ -248,13 +216,13 @@ Following table structure describes the entirety of a Signed Transaction - - + +
NameName Type Description
Address Type byte/varint - Set to value 1 to denote a WOTS Address. + Set to value 0 to denote an Ed25519 Address.
AddressByteArray[49]The T5B1 encoded WOTS address.ByteArray[32]The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key.
@@ -399,8 +367,8 @@ Following table structure describes the entirety of a Signed Transaction
Signature oneOf -
- Ed25519 Signature +
+ WOTS Signature @@ -411,23 +379,18 @@ Following table structure describes the entirety of a Signed Transaction - - - - - - +
Name Signature Type byte/varint - Set to value 0 to denote an Ed25519 Signature. + Set to value 0 to denote a WOTS Signature.
Public keyByteArray[32]The public key of the Ed25519 keypair which is used to verify the signature.
SignatureByteArray[64]ByteArray The signature signing the serialized Unsigned Transaction.
-
- WOTS Signature +
+ Ed25519 Signature @@ -438,12 +401,17 @@ Following table structure describes the entirety of a Signed Transaction + + + + + - +
Name Signature Type byte/varint - Set to value 1 to denote a WOTS Signature. + Set to value 1 to denote an Ed25519 Signature.
Public keyByteArray[32]The public key of the Ed25519 keypair which is used to verify the signature.
SignatureByteArrayByteArray[64] The signature signing the serialized Unsigned Transaction.
@@ -503,7 +471,7 @@ Each defined input must be accompanied by a corresponding Unlock Block at Format - + @@ -542,7 +510,7 @@ The Outputs part holds the outputs to create with this Unsigned Transa Format
NameName Type Description
- + @@ -557,10 +525,10 @@ The Outputs part holds the outputs to create with this Unsigned Transa - + @@ -174,7 +174,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -192,7 +192,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -214,7 +214,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -239,7 +239,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -258,7 +258,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -284,7 +284,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -320,7 +320,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -340,7 +340,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -359,7 +359,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -377,7 +377,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -399,7 +399,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -433,7 +433,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -477,7 +477,7 @@ Each defined input must be accompanied by a corresponding Unlock Block at - + @@ -489,7 +489,7 @@ Each defined input must be accompanied by a corresponding Unlock Block at - +
NameName Type Description
Address (oneOf)
- Ed25519 Address + WOTS Address - + @@ -568,21 +536,21 @@ The Outputs part holds the outputs to create with this Unsigned Transa - - + +
NameName Type Description
Address Type byte/varint - Set to value 0 to denote an Ed25519 Address. + Set to value 0 to denote a WOTS Address.
AddressByteArray[32]The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key.ByteArray[49]The T5B1 encoded WOTS address.
- WOTS Address + Ed25519 Address - + @@ -590,13 +558,13 @@ The Outputs part holds the outputs to create with this Unsigned Transa - - + +
NameName Type Description
Address Type byte/varint - Set to value 1 to denote a WOTS Address. + Set to value 1 to denote an Ed25519 Address.
AddressByteArray[49]The T5B1 encoded WOTS address.ByteArray[32]The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key.
@@ -633,7 +601,7 @@ The Unlock Blocks part holds the unlock blocks unlocking inputs within an There are different types of Unlock Blocks: - + @@ -669,8 +637,8 @@ There are different types of Unlock Blocks: - + - + @@ -134,7 +134,7 @@ Following table structure describes the entirety of a Signed Transaction - + @@ -146,7 +146,7 @@ Following table structure describes the entirety of a Signed Transaction - +
NameName Value Description
Signature oneOf -
- Ed25519 Signature +
+ WOTS Signature @@ -681,23 +649,18 @@ There are different types of Unlock Blocks: - - - - - - +
NameSignature Type byte/varint - Set to value 0 to denote an Ed25519 Signature. + Set to value 0 to denote a WOTS Signature.
Public keyByteArray[32]The public key of the Ed25519 keypair which is used to verify the signature.
SignatureByteArray[64]ByteArray The signature signing the serialized Unsigned Transaction.
-
- WOTS Signature +
+ Ed25519 Signature @@ -708,12 +671,17 @@ There are different types of Unlock Blocks: + + + + + - +
NameSignature Type byte/varint - Set to value 1 to denote a WOTS Signature. + Set to value 1 to denote an Ed25519 Signature.
Public keyByteArray[32]The public key of the Ed25519 keypair which is used to verify the signature.
SignatureByteArrayByteArray[64] The signature signing the serialized Unsigned Transaction.
@@ -792,9 +760,10 @@ Following criteria defines whether the transaction passes the syntactical valida * Accumulated output balance must not exceed the total supply of tokens `2'779'530'283'277'761`. * `Payload Length` must be 0 (to indicate that there's no payload) or be valid for the specified payload type. * `Payload Type` must be one of the supported payload types if `Payload Length` is not 0. -* `Unlock Blocks Count` must match the amount of inputs. Must be 0 < x ≤ 127. +* `Unlock Blocks Count` must match the amount of inputs. Must be 0 < x < 127. * `Unlock Block Type` must either be 0 or 1, denoting a `Signature Unlock Block` or `Reference Unlock block`. -* `Signature Unlock Blocks` must define either an `Ed25519`- or `WOTS Signature` and be unique. +* `Signature Unlock Blocks` must define either an `Ed25519`- or `WOTS Signature`. +* A `Signature Unlock Block` unlocking multiple inputs must only appear once (be unique) and be positioned at same index of the first input it unlocks. All other inputs unlocked by the same `Signature Unlock Block` must have a companion `Reference Unlock Block` at the same index as the corresponding input which points to the origin `Signature Unlock Block`. * `Reference Unlock Blocks` must specify a previous `Unlock Block` which is not of type `Reference Unlock Block`. The reference index must therefore be < the index of the `Reference Unlock Block`. * Given the type and length information, the Signed Transaction must consume the entire byte array the `Payload Length` field in the Message defines. @@ -809,10 +778,9 @@ Processing transactions in the White-Flag ordering enables users to spend UTXOs Following criteria defines whether the transaction passes the semantic validation: 1. The UTXOs the transaction references must be known (booked) and unspent. -1. The transaction is spending the entirety of the funds of the referenced UTXOs to the ouputs. +1. The transaction is spending the entirety of the funds of the referenced UTXOs to the outputs. 1. The address type of the referenced UTXO must match the signature type contained in the corresponding Signature Unlock Block. 1. The Signature Unlock Blocks are valid, i.e. the signatures prove ownership over the addresses of the referenced UTXOs. -1. Signature Unlock Blocks unlocking multiple inputs must only appear once (be unique) at same index of the first input it unlocks. All other inputs unlocked by the same Signature Unlock Block must have a companion Reference Unlock Block at the same index as the corresponding input which points to the origin Signature Unlock Block. If a transaction passes the semantic validation, its referenced UTXOs must be marked as spent and the corresponding new outputs must be booked/specified in the ledger. The booked transaction then also becomes part of the White-Flag Merkle tree inclusion set. From ad14f75f6de7ef3680fed01645875852f5786147 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Tue, 28 Jul 2020 20:23:00 +0200 Subject: [PATCH 04/35] normalize to varint --- .../0000-signed-transaction-payload.md | 52 +++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index 6eed6e61a..0d03d338e 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -108,14 +108,14 @@ Following table structure describes the entirety of a Signed Transaction
Transaction Typebyte/varintvarint Set to value 0 to denote an Unsigned Transaction.
Inputs Countbyte/varintvarint The amount of inputs proceeding.
Input Typebyte/varintvarint Set to value 0 to denote an UTXO Input.
Transaction Output Indexbyte/varintvarint The index of the output on the referenced transaction to consume.
@@ -155,7 +155,7 @@ Following table structure describes the entirety of a Signed Transaction
Outputs Countbyte/varintvarint The amount of outputs proceeding.
Output Typebyte/varintvarint Set to value 0 to denote a SigLockedSingleDeposit.
Address Typebyte/varintvarint Set to value 0 to denote a WOTS Address.
Address Typebyte/varintvarint Set to value 0 to denote an Ed25519 Address.
Payload Lengthbyte/varintvarint The length in bytes of the optional payload.
Payload Typebyte/varintvarint Set to value 2 to denote an Unsigned Data payload.
Payload Typebyte/varintvarint Set to value 3 to denote an Signed Data payload.
Payload Typebyte/varintvarint Set to value 4 to denote an Indexation payload.
Unlock Blocks Countbyte/varintvarint The count of unlock blocks proceeding. Must match count of inputs specified.
Unlock Typebyte/varintvarint Set to value 0 to denote a Signature Unlock Block.
Signature Typebyte/varintvarint Set to value 0 to denote a WOTS Signature.
Signature Typebyte/varintvarint Set to value 1 to denote an Ed25519 Signature.
Unlock Typebyte/varintvarint Set to value 1 to denote a Reference Unlock Block.
Input Typebyte/varintvarint Set to value 0 to denote a UTXO Input.
Transaction Output Indexbyte/varintvarint The index of the output on the referenced transaction to consume.
@@ -516,7 +516,7 @@ The Outputs part holds the outputs to create with this Unsigned Transa
Output Typebyte/varintvarint Set to value 0 to denote a SigLockedSingleDeposit.
Address Typebyte/varintvarint Set to value 0 to denote a WOTS Address.
Address Typebyte/varintvarint Set to value 1 to denote an Ed25519 Address.
Unlock Typebyte/varintvarint Set to value 0 to denote a Signature Unlock Block.
Signature Typebyte/varintvarint Set to value 0 to denote a WOTS Signature.
Signature Typebyte/varintvarint Set to value 1 to denote an Ed25519 Signature.
Unlock Typebyte/varintvarint Set to value 1 to denote a Reference Unlock Block. Address Type varint - Set to value 0 to denote an Ed25519 Address. + Set to value 1 to denote an Ed25519 Address.
Payload Typevarintuint16 Set to value 0 to denote a Signed Transaction payload.
Transaction Typevarintuint8 Set to value 0 to denote an Unsigned Transaction.
Inputs Countvarintuint16 The amount of inputs proceeding.
Input Typevarintuint8 Set to value 0 to denote an UTXO Input.
Transaction Output Indexvarintuint16 The index of the output on the referenced transaction to consume.
@@ -155,7 +155,7 @@ Following table structure describes the entirety of a Signed Transaction Outputs Count - varint + uint16 The amount of outputs proceeding. @@ -174,7 +174,7 @@ Following table structure describes the entirety of a Signed Transaction Output Type - varint + uint8 Set to value 0 to denote a SigLockedSingleDeposit. @@ -192,7 +192,7 @@ Following table structure describes the entirety of a Signed Transaction Address Type - varint + uint8 Set to value 0 to denote a WOTS Address. @@ -214,7 +214,7 @@ Following table structure describes the entirety of a Signed Transaction Address Type - varint + uint8 Set to value 1 to denote an Ed25519 Address. @@ -239,7 +239,7 @@ Following table structure describes the entirety of a Signed Transaction Payload Length - varint + uint32 The length in bytes of the optional payload. @@ -258,7 +258,7 @@ Following table structure describes the entirety of a Signed Transaction Payload Type - varint + uint16 Set to value 2 to denote an Unsigned Data payload. @@ -284,7 +284,7 @@ Following table structure describes the entirety of a Signed Transaction Payload Type - varint + uint16 Set to value 3 to denote an Signed Data payload. @@ -320,7 +320,7 @@ Following table structure describes the entirety of a Signed Transaction Payload Type - varint + uint16 Set to value 4 to denote an Indexation payload. @@ -340,7 +340,7 @@ Following table structure describes the entirety of a Signed Transaction Unlock Blocks Count - varint + uint16 The count of unlock blocks proceeding. Must match count of inputs specified. @@ -359,7 +359,7 @@ Following table structure describes the entirety of a Signed Transaction Unlock Type - varint + uint8 Set to value 0 to denote a Signature Unlock Block. @@ -377,7 +377,7 @@ Following table structure describes the entirety of a Signed Transaction Signature Type - varint + uint8 Set to value 0 to denote a WOTS Signature. @@ -399,7 +399,7 @@ Following table structure describes the entirety of a Signed Transaction Signature Type - varint + uint8 Set to value 1 to denote an Ed25519 Signature. @@ -433,14 +433,14 @@ Following table structure describes the entirety of a Signed Transaction Unlock Type - varint + uint8 Set to value 1 to denote a Reference Unlock Block. Reference - varint + uint16 Represents the index of a previous unlock block. @@ -468,7 +468,7 @@ Each defined input must be accompanied by a corresponding Unlock Block at ###### UTXO Input
- Format + UTXO Input @@ -477,19 +477,19 @@ Each defined input must be accompanied by a corresponding Unlock Block at - + - - + + - +
Name
Input Typevarintuint8 - Set to value 0 to denote a UTXO Input. + Set to value 0 to denote an UTXO Input.
Transaction IDByteArray[64]The transaction reference from which the UTXO comes from.ByteArray[32]The BLAKE2b-256 hash of the transaction from which the UTXO comes from.
Transaction Output Indexvarintuint16 The index of the output on the referenced transaction to consume.
@@ -506,8 +506,11 @@ The Outputs part holds the outputs to create with this Unsigned Transa ###### SigLockedSingleDeposit -
- Format +
+ SigLockedSingleDeposit +
+ Describes a deposit to a single address which is unlocked via a signature. +
@@ -516,13 +519,13 @@ The Outputs part holds the outputs to create with this Unsigned Transa - + - + - + @@ -556,7 +559,7 @@ The Outputs part holds the outputs to create with this Unsigned Transa - + @@ -629,7 +632,7 @@ There are different types of Unlock Blocks: - + @@ -647,7 +650,7 @@ There are different types of Unlock Blocks: - + @@ -669,7 +672,7 @@ There are different types of Unlock Blocks: - + @@ -705,14 +708,14 @@ A Signature Unlock Block defines an Unlock Block which holds one o - + - +
Name
Output Typevarintuint8 Set to value 0 to denote a SigLockedSingleDeposit.
Address (oneOf)Address oneOf
WOTS Address @@ -534,7 +537,7 @@ The Outputs part holds the outputs to create with this Unsigned Transa
Address Typevarintuint8 Set to value 0 to denote a WOTS Address.
Address Typevarintuint8 Set to value 1 to denote an Ed25519 Address.
Unlock Typevarintuint8 Set to value 0 to denote a Signature Unlock Block.
Signature Typevarintuint8 Set to value 0 to denote a WOTS Signature.
Signature Typevarintuint8 Set to value 1 to denote an Ed25519 Signature.
Unlock Typevarintuint8 Set to value 1 to denote a Reference Unlock Block.
Referencevarintuint16 Represents the index of a previous unlock block.
From b84920b839b06486cd58460c0b3fba1e2ff6a574 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Mon, 7 Sep 2020 11:20:48 +0200 Subject: [PATCH 09/35] remove non-existing payload types --- .../0000-signed-transaction-payload.md | 76 +++---------------- 1 file changed, 9 insertions(+), 67 deletions(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index 4d5c3276a..0edd49d8e 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -87,7 +87,7 @@ Following table structure describes the entirety of a Signed Transaction Payload Type - uint16 + uint32 Set to value 0 to denote a Signed Transaction payload. @@ -245,67 +245,6 @@ Following table structure describes the entirety of a Signed Transaction Payload optOneOf -
- Unsigned Data Payload -
- Describes a payload containing data without any specification what the data means. -
- - - - - - - - - - - - - - - - -
NameTypeDescription
Payload Typeuint16 - Set to value 2 to denote an Unsigned Data payload. -
DataByteArrayThe data of the Unsigned Data payload.
-
-
- Signed Data Payload -
- Describes a payload containing signed data (and its corresponding Ed25519 public key and signature) without - any specification what the data means. -
- - - - - - - - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
Payload Typeuint16 - Set to value 3 to denote an Signed Data payload. -
DataByteArrayThe data of the Signed Data payload.
Public KeyByteArray[32]The Ed25519 public key used to verify the signature.
SignatureByteArray[64]The signature signing the data.
-
Indexation Payload
@@ -320,11 +259,16 @@ Following table structure describes the entirety of a Signed Transaction Payload Type - uint16 + uint32 - Set to value 4 to denote an Indexation payload. + Set to value 2 to denote an Indexation payload. + + Index + ByteArray[uint16] + The tag which is used to index the message containing this transaction. + Tag ByteArray[16] @@ -593,9 +537,7 @@ Supported payload types to be embedded into an Unsigned Transaction: | Name | Type Value | | --------------------- | ---------- | -| Unsigned Data Payload | 2 | -| Signed Data Payload | 3 | -| Indexation Payload | 4 | +| Indexation Payload | 2 | #### Unlock Blocks From 30d5d5a446a0ee6e52a9a52a0b18176deccc8f01 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Mon, 7 Sep 2020 11:53:45 +0200 Subject: [PATCH 10/35] reduce embedded payload table --- .../0000-signed-transaction-payload.md | 28 ------------------- 1 file changed, 28 deletions(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index 0edd49d8e..dbdff0291 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -247,34 +247,6 @@ Following table structure describes the entirety of a Signed Transaction
Indexation Payload -
- Describes a payload which is used to instruct the node to index the Message - of which it is part of. -
- - - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
Payload Typeuint32 - Set to value 2 to denote an Indexation payload. -
IndexByteArray[uint16]The tag which is used to index the message containing this transaction.
TagByteArray[16]The tag which is used to index the Signed Transaction's hash.
From e33bc0aac0c1371611b657b369081b38c4af18db Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Wed, 7 Oct 2020 09:29:59 +0200 Subject: [PATCH 11/35] normalize array types, renames signed transaction payload to transaction payload and unsigned transaction to transaction essence --- .../0000-signed-transaction-payload.md | 88 ++++++++++--------- 1 file changed, 47 insertions(+), 41 deletions(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index dbdff0291..580db27ce 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -1,4 +1,4 @@ -+ Feature name: signed_transaction_payload ++ Feature name: transaction_payload + Start date: 2020-07-10 + RFC PR: [iotaledger/protocol-rfcs#18](https://github.com/iotaledger/protocol-rfcs/pull/18) @@ -47,13 +47,13 @@ The way UTXOs are referenced is further described in the Structure sectio ### Serialized Layout -A Signed Transaction payload is made up of two parts: -1. The Unsigned Transaction part which contains the inputs, outputs and an optional embedded payload. -2. The Unlock Blocks which unlock the Unsigned Transaction's inputs. In case the unlock block contains a signature, it signs the entire Unsigned Transaction part. +A Transaction Payload payload is made up of two parts: +1. The The Transaction Essence part which contains the inputs, outputs and an optional embedded payload. +2. The Unlock Blocks which unlock the Transaction Essence's inputs. In case the unlock block contains a signature, it signs the entire Transaction Essence part. All values are serialized in little-endian encoding. The serialized form of the transaction is deterministic, meaning the same logical transaction always results in the same serialized byte sequence. -Following table structure describes the entirety of a Signed Transaction payload's serialized form: +Following table structure describes the entirety of a Transaction Payload's serialized form: * [Data Type Notation](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md#data-types) *
Subschema Notation @@ -89,14 +89,14 @@ Following table structure describes the entirety of a Signed Transaction Payload Type uint32 - Set to value 0 to denote a Signed Transaction payload. + Set to value 0 to denote a Transaction Payload. Transaction oneOf
- Unsigned Transaction + Transaction Essence
Describes the essence data making up a transaction by defining its inputs and outputs and an optional payload.
@@ -110,7 +110,7 @@ Following table structure describes the entirety of a Signed Transaction Transaction Type uint8 - Set to value 0 to denote an Unsigned Transaction. + Set to value 0 to denote a Transaction Essence. @@ -141,7 +141,7 @@ Following table structure describes the entirety of a Signed Transaction Transaction ID - ByteArray[32] + Array<byte>[32] The BLAKE2b-256 hash of the transaction from which the UTXO comes from. @@ -199,7 +199,7 @@ Following table structure describes the entirety of a Signed Transaction Address - ByteArray[49] + Array<byte>[49] The T5B1 encoded WOTS address. @@ -221,7 +221,7 @@ Following table structure describes the entirety of a Signed Transaction Address - ByteArray[32] + Array<byte>[32] The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key. @@ -300,8 +300,8 @@ Following table structure describes the entirety of a Signed Transaction Signature - ByteArray - The signature signing the serialized Unsigned Transaction. + Array<byte> + The signature signing the serialized Transaction Essence.
@@ -322,13 +322,13 @@ Following table structure describes the entirety of a Signed Transaction Public key - ByteArray[32] + Array<byte>[32] The public key of the Ed25519 keypair which is used to verify the signature. Signature - ByteArray[64] - The signature signing the serialized Unsigned Transaction. + Array<byte>[64] + The signature signing the serialized Transaction Essence.
@@ -367,19 +367,22 @@ Following table structure describes the entirety of a Signed Transaction ### Transaction Parts -In general, all parts of a Signed Transaction begin with a byte describing the type of the given part in order to keep the flexibility to introduce new types/versions of the given part in the future. +In general, all parts of a Transaction Payload begin with a byte describing the type of the given part in order to keep the flexibility to introduce new types/versions of the given part in the future. -#### Unsigned Transaction / Essence Data +#### Transaction Essence Data -As described, the Unsigned Transaction of a Signed Transaction carries the inputs, outputs and an optional payload. The Unsigned Transaction is an explicit type of transaction and therefore starts with its own Transaction Type byte which is of value 0. +As described, the Transaction Essence of a Transaction Payload carries the inputs, outputs and an optional payload. The Transaction Essence is an explicit type and therefore starts with its own Transaction Essence Type byte which is of value 0. -An Unsigned Transaction must contain at least one input and output. +A Transaction Essence must contain at least one input and output. ##### Inputs -The Inputs part holds the inputs to consume, respectively to fund the outputs of the Unsigned Transaction. There is only one type of input as of now, the UTXO Input. In the future, more types of inputs may be specified as part of protocol upgrades. +The Inputs part holds the inputs to consume, respectively to fund the outputs of the Transaction Essence. There is only one type of input as of now, the UTXO Input. In the future, more types of inputs may be specified as part of protocol upgrades. -Each defined input must be accompanied by a corresponding Unlock Block at the same index in the Unlock Blocks part of the Signed Transaction. If multiple inputs can be unlocked through the same Unlock Block, then the given Unlock Block only needs to be specified at the index of the first input which gets unlocked by it. Subsequent inputs which are unlocked through the same data must have a Reference Unlock Block pointing to the previous Unlock Block. This ensures that no duplicate data needs to occur in the same transaction. +Each defined input must be accompanied by a corresponding Unlock Block at the same index in the Unlock Blocks part of the Transaction Payload. +If multiple inputs can be unlocked through the same Unlock Block, then the given Unlock Block only needs to be specified at the index of the first input which gets unlocked by it. +Subsequent inputs which are unlocked through the same data must have a Reference Unlock Block pointing to the previous Unlock Block. +This ensures that no duplicate data needs to occur in the same transaction. ###### UTXO Input @@ -400,7 +403,7 @@ Each defined input must be accompanied by a corresponding Unlock Block at Transaction ID - ByteArray[32] + Array<byte>[32] The BLAKE2b-256 hash of the transaction from which the UTXO comes from. @@ -418,7 +421,7 @@ Example: If the output the input references outputs to an Ed25519 address, then ##### Outputs -The Outputs part holds the outputs to create with this Unsigned Transaction. There is only one type of output as of now, the SigLockedSingleDeposit. +The Outputs part holds the outputs to create with this Transaction Payload. There is only one type of output as of now, the SigLockedSingleDeposit. ###### SigLockedSingleDeposit @@ -460,7 +463,7 @@ The Outputs part holds the outputs to create with this Unsigned Transa Address - ByteArray[49] + Array<byte>[49] The T5B1 encoded WOTS address. @@ -482,7 +485,7 @@ The Outputs part holds the outputs to create with this Unsigned Transa Address - ByteArray[32] + Array<byte>[32] The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key. @@ -503,9 +506,9 @@ The SigLockedSingleDeposit defines an output (with a certain amount) to a ##### Payload -The payload part of an Unsigned Transaction can hold an optional payload. This payload does not affect the validity of the Unsigned Transaction. If the transaction is not valid, then the payload must also be discarded. +The payload part of a Transaction Essence can hold an optional payload. This payload does not affect the validity of the Transaction Essence. If the transaction is not valid, then the payload must also be discarded. -Supported payload types to be embedded into an Unsigned Transaction: +Supported payload types to be embedded into a Transaction Essence: | Name | Type Value | | --------------------- | ---------- | @@ -513,7 +516,7 @@ Supported payload types to be embedded into an Unsigned Transaction: #### Unlock Blocks -The Unlock Blocks part holds the unlock blocks unlocking inputs within an Unsigned Transaction. +The Unlock Blocks part holds the unlock blocks unlocking inputs within an Transaction Essence. There are different types of Unlock Blocks: @@ -571,8 +574,8 @@ There are different types of Unlock Blocks: - - + +
SignatureByteArrayThe signature signing the serialized Unsigned Transaction.Array<byte>The signature signing the serialized Transaction Essence.
@@ -593,13 +596,13 @@ There are different types of Unlock Blocks: Public key - ByteArray[32] + Array<byte>[32] The public key of the Ed25519 keypair which is used to verify the signature. Signature - ByteArray[64] - The signature signing the serialized Unsigned Transaction. + Array<byte>[64] + The signature signing the serialized Transaction Essence.
@@ -608,7 +611,8 @@ There are different types of Unlock Blocks:
-A Signature Unlock Block defines an Unlock Block which holds one or more signatures unlocking one or more inputs. Such block signs the entire Unsigned Transaction part of a Signed Transaction including the optional payload. +A Signature Unlock Block defines an Unlock Block which holds one or more signatures unlocking one or more inputs. +Such block signs the entire Transaction Essence part of a Transaction Payload including the optional payload. ##### Reference Unlock block @@ -638,7 +642,7 @@ A Signature Unlock Block defines an Unlock Block which holds one o A Reference Unlock Block defines an Unlock Block which references a previous Unlock Block (which must not be another Reference Unlock Block). It must be used if multiple inputs can be unlocked through the same origin Unlock Block. Example: -Consider an Unsigned Transaction containing UTXO Inputs A, B and C, where A and C are both spending the UTXOs originating from the same Ed25519 address. The Unlock Block part must thereby have following structure: +Consider an Transaction Essence containing UTXO Inputs A, B and C, where A and C are both spending the UTXOs originating from the same Ed25519 address. The Unlock Block part must thereby have following structure: | Index | Must Contain | | ----- | ---------------------------------------------------------------------------------------------------------------- | @@ -648,14 +652,14 @@ Consider an Unsigned Transaction containing UTXO Inputs A, B and C ## Validation -A Signed Transaction payload has different validation stages, since some validation steps can only be executed at the point when certain information has (or has not) been received. We therefore distinguish between syntactical- and semantic validation. +A Transaction Payload payload has different validation stages, since some validation steps can only be executed at the point when certain information has (or has not) been received. We therefore distinguish between syntactical- and semantic validation. ### Syntactical Validation This validation can commence as soon as the transaction data has been received in its entirety. It validates the structure but not the signatures of the transaction. If the transaction does not pass this stage, it must not be further broadcasted and can be discarded right away. Following criteria defines whether the transaction passes the syntactical validation: -* `Transaction Type` value must be 0, denoting an `Unsigned Transaction`. +* `Transaction Essence Type` value must be 0, denoting an `Transaction Essence`. * Inputs: * `Inputs Count` must be 0 < x < 127. * At least one input must be specified. @@ -682,7 +686,7 @@ Following criteria defines whether the transaction passes the syntactical valida * `Signature Unlock Blocks` must define either an `Ed25519`- or `WOTS Signature`. * A `Signature Unlock Block` unlocking multiple inputs must only appear once (be unique) and be positioned at same index of the first input it unlocks. All other inputs unlocked by the same `Signature Unlock Block` must have a companion `Reference Unlock Block` at the same index as the corresponding input which points to the origin `Signature Unlock Block`. * `Reference Unlock Blocks` must specify a previous `Unlock Block` which is not of type `Reference Unlock Block`. The reference index must therefore be < the index of the `Reference Unlock Block`. -* Given the type and length information, the Signed Transaction must consume the entire byte array the `Payload Length` field in the Message defines. +* Given the type and length information, the Transaction Payload must consume the entire byte array the `Payload Length` field in the Message defines. 1 ensures that serialization of the transaction becomes deterministic, meaning that libraries always produce the same bytes given the logical transaction. @@ -715,11 +719,13 @@ Since the ledger no longer is account based, meaning that balances are directly ### Reusing the same address with Ed25519 -While creating multiple signatures with Ed25519 does not reduce security, reusing the same address over and over again not only drastically reduces the privacy of yourself but also all other people in the UTXO chain of the moved funds. Applications and services are therefore instructed to create new addresses per deposit, in order to circumvent the privacy issues stemming from address reuse. In essence, Ed25519 support allows for smaller transaction sizes and to safely spend funds which were sent to an already used deposit address. Ed25519 addresses are not meant to be used like an e-mail address. See this [Bitcoin wiki entry](https://en.bitcoin.it/wiki/Address_reuse#:~:text=The%20most%20private%20and%20secure,a%20brand%20new%20bitcoin%20address.) for further information on how address reuse reduces privacy and this [article](https://en.bitcoin.it/wiki/Receiving_donations_with_bitcoin) why the same should be applied to donation addresses. +While creating multiple signatures with Ed25519 does not reduce security, reusing the same address over and over again not only drastically reduces the privacy of yourself but also all other people in the UTXO chain of the moved funds. Applications and services are therefore instructed to create new addresses per deposit, in order to circumvent the privacy issues stemming from address reuse. +In essence, Ed25519 support allows for smaller transaction sizes and to safely spend funds which were sent to an already used deposit address. +Ed25519 addresses are not meant to be used like an e-mail address. See this [Bitcoin wiki entry](https://en.bitcoin.it/wiki/Address_reuse#:~:text=The%20most%20private%20and%20secure,a%20brand%20new%20bitcoin%20address.) for further information on how address reuse reduces privacy and this [article](https://en.bitcoin.it/wiki/Receiving_donations_with_bitcoin) why the same should be applied to donation addresses. # Drawbacks -The new transaction format is the core data type within the IOTA ecosystem. Changing it means that all projects need to accommodate for it including client libraries, blueprints, PoC and applications using IOTA in general. There is no way to keep the changes backwards compatible. Additionally, these changes are breaking, meaning that all nodes must upgrade in order to further participate in the network. +The new transaction format is the core data type within the IOTA ecosystem. Changing it means that all projects need to accommodate for it, including client libraries, blueprints, PoC and applications using IOTA in general. There is no way to keep the changes backwards compatible. Additionally, these changes are breaking, meaning that all nodes must upgrade in order to further participate in the network. Local snapshots can also no longer be simply represented by a list of addresses and their balances, since the ledger is now made up of the UTXOs on which the actual funds reside on. Therefore local snapshot file schemes have to be adjusted to incorporate the transaction hashes, output indices and then the destination addresses plus the balances. From 28c0cdca9cd150e40c68624bb91dc643bef7c786 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Wed, 7 Oct 2020 09:32:44 +0200 Subject: [PATCH 12/35] renames SigLockedSingleDeposit to SigLockedSingleOutput --- .../0000-signed-transaction-payload.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md index 580db27ce..756ca020f 100644 --- a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md +++ b/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md @@ -162,7 +162,7 @@ Following table structure describes the entirety of a Transaction Payload Outputs anyOf
- SigLockedSingleDeposit + SigLockedSingleOutput
Describes a deposit to a single address which is unlocked via a signature.
@@ -176,7 +176,7 @@ Following table structure describes the entirety of a Transaction Payload Output Type uint8 - Set to value 0 to denote a SigLockedSingleDeposit. + Set to value 0 to denote a SigLockedSingleOutput. @@ -231,7 +231,7 @@ Following table structure describes the entirety of a Transaction Payload Amount uint64 - The amount of tokens to deposit with this SigLockedSingleDeposit output. + The amount of tokens to deposit with this SigLockedSingleOutput output.
@@ -421,12 +421,12 @@ Example: If the output the input references outputs to an Ed25519 address, then ##### Outputs -The Outputs part holds the outputs to create with this Transaction Payload. There is only one type of output as of now, the SigLockedSingleDeposit. +The Outputs part holds the outputs to create with this Transaction Payload. There is only one type of output as of now, the SigLockedSingleOutput. -###### SigLockedSingleDeposit +###### SigLockedSingleOutput
- SigLockedSingleDeposit + SigLockedSingleOutput
Describes a deposit to a single address which is unlocked via a signature.
@@ -440,7 +440,7 @@ The Outputs part holds the outputs to create with this Transaction Pay Output Type uint8 - Set to value 0 to denote a SigLockedSingleDeposit. + Set to value 0 to denote a SigLockedSingleOutput. @@ -495,14 +495,14 @@ The Outputs part holds the outputs to create with this Transaction Pay Amount uint64 - The amount of tokens to deposit with this SigLockedSingleDeposit output. + The amount of tokens to deposit with this SigLockedSingleOutput output.

-The SigLockedSingleDeposit defines an output (with a certain amount) to a single target address which is unlocked via a signature proving ownership over the given address. Such output can hold addresses of different types. +The SigLockedSingleOutput defines an output (with a certain amount) to a single target address which is unlocked via a signature proving ownership over the given address. Such output can hold addresses of different types. ##### Payload @@ -671,11 +671,11 @@ Following criteria defines whether the transaction passes the syntactical valida * Outputs: * `Outputs Count` must be 0 < x < 127. * At least one output must be specified. - * `Output Type` must be 0, denoting a `SigLockedSingleDeposit`. - * `SigLockedSingleDeposit`: + * `Output Type` must be 0, denoting a `SigLockedSingleOutput`. + * `SigLockedSingleOutput`: * `Address Type` must either be 0 or 1, denoting a `WOTS`- or `Ed25519` address . * If `Address` is of type `WOTS address`, its bytes must be valid `T5B1` bytes. - * The `Address` must be unique in the set of `SigLockedSingleDeposits`. + * The `Address` must be unique in the set of `SigLockedSingleOutputs`. * `Amount` must be > 0. * Outputs must be in lexicographical order by their serialized form.1 * Accumulated output balance must not exceed the total supply of tokens `2'779'530'283'277'761`. From 0631dfe3f42432a7338624dbd8445eac927c7cb4 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Wed, 7 Oct 2020 09:33:23 +0200 Subject: [PATCH 13/35] renames folder and file --- .../0000-transaction-payload.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename text/{0000-signed-transaction-payload/0000-signed-transaction-payload.md => 0000-transaction-payload/0000-transaction-payload.md} (100%) diff --git a/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md similarity index 100% rename from text/0000-signed-transaction-payload/0000-signed-transaction-payload.md rename to text/0000-transaction-payload/0000-transaction-payload.md From faa8857719264f7b028bcf6712c021f5fb0fc6c7 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Wed, 7 Oct 2020 10:45:54 +0200 Subject: [PATCH 14/35] renames the Transaction field to Essence --- text/0000-transaction-payload/0000-transaction-payload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md index 756ca020f..386a8fe05 100644 --- a/text/0000-transaction-payload/0000-transaction-payload.md +++ b/text/0000-transaction-payload/0000-transaction-payload.md @@ -93,7 +93,7 @@ Following table structure describes the entirety of a Transaction Payload - Transaction oneOf + Essence oneOf
Transaction Essence From 32b0781a04648f4282ffb0ddd23aa73a08441f49 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Thu, 19 Nov 2020 10:48:37 +0100 Subject: [PATCH 15/35] apply suggestions from technical writer Co-authored-by: charlesthompson3 <74603461+charlesthompson3@users.noreply.github.com> --- .../0000-transaction-payload.md | 68 +++++++++---------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md index 386a8fe05..8bab115b4 100644 --- a/text/0000-transaction-payload/0000-transaction-payload.md +++ b/text/0000-transaction-payload/0000-transaction-payload.md @@ -8,34 +8,34 @@ This RFC defines a new transaction structure for Chrysalis Phase 2, which replac # Motivation -The current IOTA protocol uses so-called **transactions** (which are vertices in the Tangle), where each transaction defines either an input or output. A grouping of those input/output transaction vertices make up a so-called **bundle** which transfers the given values as an atomic unit (the entire bundle is applied or none of it). The input transactions define the funds to consume to create the deposits onto the output transactions target addresses. Additionally, to accommodate the rather big WOTS signatures, additional transaction vertices might be part of the bundle in order to carry parts of the signature which don't fit into one transaction vertex. +The current IOTA protocol uses **transactions** (which are vertices in the Tangle), where each transaction defines either an input or output. A grouping of those input/output transaction vertices make up a **bundle** which transfers the given values as an atomic unit (the entire bundle is applied or none of it). The input transactions define the funds to consume and create the deposits onto the output transactions target addresses. Additionally, to accommodate the larger WOTS signatures, additional transaction vertices might be part of the bundle to carry parts of the signature which do not fit into one transaction vertex. -The bundle concept has proven to be tedious, spawning a plethora of problems: -* Since the data making up the bundle is split across multiple vertices, it complicates the validation of the entire transfer. Instead of being able to immediately tell whether a bundle is valid or not, a node implementation must first collect all parts of the bundle before any actual validation can happen. This increases the complexity of the node implementation immensely. +The bundle concept has proven to be time consuming, with several issues as well: +* Since the data making up the bundle is split across multiple vertices, it complicates the validation of the entire transfer. Instead of being able to immediately tell whether a bundle is valid or not, a node implementation must first collect all parts of the bundle before any actual validation can happen. This increases the complexity of the node implementation. * Reattaching the tail transaction of a bundle causes the entire transfer to be reapplied. -* Due to the split across multiple transaction vertices and having to do PoW for each of them, a created bundle might already be lazy in terms of where it attaches, reducing its chances to get confirmed. +* Due to the split across multiple transaction vertices and having to do PoW for each of them, a bundle might already be lazy in terms of where it attaches, reducing its chances to be confirmed. -To fix the problems mentioned above and creating a more flexible transaction structure, we want to achieve a self-contained transaction structure defining the data of the entire transfer as a payload to be embedded into a message. +To fix the problems mentioned above and to create a more flexible transaction structure, the goal is to achieve a self-contained transaction structure defining the data of the entire transfer as a payload to be embedded into a message. -The new transaction structure should fulfill following criteria: +The new transaction structure should fulfil the following criteria: * Support for Ed25519 (and thus reusable addresses) and WOTS signatures. -* Support for adding new types of signature schemes, addresses, inputs and outputs as part of protocol upgrades. -* Self-contained as in being able to validate the transaction immediately after receiving it. -* Enable unspent transaction outputs (UTXO) as inputs instead of an account based model. (UTXO enables easier double-spend detection) +* Support for adding new types of signature schemes, addresses, inputs, and outputs as part of protocol upgrades. +* Self-contained, as in being able to validate the transaction immediately after receiving it. +* Enable unspent transaction outputs (UTXO) as inputs instead of an account based model (UTXO enables easier double-spend detection). # Detailed design ## UTXO -The *unspent transaction output* (UTXO) model defines a ledger state where balances are not directly associated to addresses but to the outputs of transactions. In this model, transactions specify the outputs of previous transactions as inputs, which are consumed in order to create new outputs. A transaction must consume the entirety of the specified inputs. +The *unspent transaction output* (UTXO) model defines a ledger state where balances are not directly associated to addresses but to the outputs of transactions. In this model, transactions specify the outputs of previous transactions as inputs, which are consumed to create new outputs. A transaction must consume the entirety of the specified inputs. Using an UTXO based model provides several benefits: * Parallel validation of transactions. * Easier double-spend detection, since conflicting transactions would reference the same UTXO. -* Replay-protection which is especially important when having reusable addresses. Replaying the same transaction would manifest itself as already being applied or existent and thus not have any impact. -* Technically seen, balances may no longer be associated to addresses which raises the level of abstraction and thus enables other types of outputs. Consider for example a type of output which specifies the balance to be unlocked by a transaction which must fulfill a very hard Proof-of-Work difficulty or supply some other unlock criteria etc. +* Replay-protection which is important when having reusable addresses. Replaying the same transaction would manifest itself as already being applied or existent and thus not have any impact. +* Technically seen, balances may no longer be associated to addresses which raises the level of abstraction and thus enables other types of outputs. Consider, for example, a type of output which specifies the balance to be unlocked by a transaction which must fulfil a Proof-of-Work difficulty or supply some other unlock criteria, etc. -Within a transaction using UTXOs, inputs and outputs make up the to be signed data of the transaction. The section unlocking the inputs is called *unlock block*. An unlock block may contain a signature proving ownership of a given input's address and/or other unlock criteria. +Within a transaction using UTXOs, inputs and outputs make up the to-be-signed data of the transaction. The section unlocking the inputs is called *unlock block*. An unlock block may contain a signature proving ownership of a given input's address and/or other unlock criteria. The following image depicts the flow of funds using UTXO: @@ -367,17 +367,17 @@ Following table structure describes the entirety of a Transaction Payload ### Transaction Parts -In general, all parts of a Transaction Payload begin with a byte describing the type of the given part in order to keep the flexibility to introduce new types/versions of the given part in the future. +In general, all parts of a Transaction Payload begin with a byte describing the type of the given part to keep the flexibility to introduce new types/versions of the given part in the future. #### Transaction Essence Data -As described, the Transaction Essence of a Transaction Payload carries the inputs, outputs and an optional payload. The Transaction Essence is an explicit type and therefore starts with its own Transaction Essence Type byte which is of value 0. +As described, the Transaction Essence of a Transaction Payload carries the inputs, outputs, and an optional payload. The Transaction Essence is an explicit type and therefore starts with its own Transaction Essence Type byte which is of value 0. A Transaction Essence must contain at least one input and output. ##### Inputs -The Inputs part holds the inputs to consume, respectively to fund the outputs of the Transaction Essence. There is only one type of input as of now, the UTXO Input. In the future, more types of inputs may be specified as part of protocol upgrades. +The Inputs part holds the inputs to consume, respectively, to fund the outputs of the Transaction Essence. There is only one type of input as of now, the UTXO Input. In the future, more types of inputs may be specified as part of protocol upgrades. Each defined input must be accompanied by a corresponding Unlock Block at the same index in the Unlock Blocks part of the Transaction Payload. If multiple inputs can be unlocked through the same Unlock Block, then the given Unlock Block only needs to be specified at the index of the first input which gets unlocked by it. @@ -502,7 +502,7 @@ The Outputs part holds the outputs to create with this Transaction Pay

-The SigLockedSingleOutput defines an output (with a certain amount) to a single target address which is unlocked via a signature proving ownership over the given address. Such output can hold addresses of different types. +The SigLockedSingleOutput defines an output (with a certain amount) to a single target address which is unlocked via a signature proving ownership over the given address. This output can hold addresses of different types. ##### Payload @@ -612,7 +612,7 @@ There are different types of Unlock Blocks:
A Signature Unlock Block defines an Unlock Block which holds one or more signatures unlocking one or more inputs. -Such block signs the entire Transaction Essence part of a Transaction Payload including the optional payload. +This block signs the entire Transaction Essence part of a Transaction Payload including the optional payload. ##### Reference Unlock block @@ -656,9 +656,9 @@ A Transaction Payload payload has different validation stages, since some ### Syntactical Validation -This validation can commence as soon as the transaction data has been received in its entirety. It validates the structure but not the signatures of the transaction. If the transaction does not pass this stage, it must not be further broadcasted and can be discarded right away. +This validation can commence as soon as the transaction data has been received in its entirety. It validates the structure but not the signatures of the transaction. If the transaction does not pass this stage, it must not be broadcasted further and can be discarded right away. -Following criteria defines whether the transaction passes the syntactical validation: +The following criteria defines whether the transaction passes the syntactical validation: * `Transaction Essence Type` value must be 0, denoting an `Transaction Essence`. * Inputs: * `Inputs Count` must be 0 < x < 127. @@ -673,7 +673,7 @@ Following criteria defines whether the transaction passes the syntactical valida * At least one output must be specified. * `Output Type` must be 0, denoting a `SigLockedSingleOutput`. * `SigLockedSingleOutput`: - * `Address Type` must either be 0 or 1, denoting a `WOTS`- or `Ed25519` address . + * `Address Type` must either be 0 or 1, denoting a `WOTS`- or `Ed25519` address. * If `Address` is of type `WOTS address`, its bytes must be valid `T5B1` bytes. * The `Address` must be unique in the set of `SigLockedSingleOutputs`. * `Amount` must be > 0. @@ -684,20 +684,20 @@ Following criteria defines whether the transaction passes the syntactical valida * `Unlock Blocks Count` must match the amount of inputs. Must be 0 < x < 127. * `Unlock Block Type` must either be 0 or 1, denoting a `Signature Unlock Block` or `Reference Unlock block`. * `Signature Unlock Blocks` must define either an `Ed25519`- or `WOTS Signature`. -* A `Signature Unlock Block` unlocking multiple inputs must only appear once (be unique) and be positioned at same index of the first input it unlocks. All other inputs unlocked by the same `Signature Unlock Block` must have a companion `Reference Unlock Block` at the same index as the corresponding input which points to the origin `Signature Unlock Block`. +* A `Signature Unlock Block` unlocking multiple inputs must only appear once (be unique) and be positioned at the same index of the first input it unlocks. All other inputs unlocked by the same `Signature Unlock Block` must have a companion `Reference Unlock Block` at the same index as the corresponding input which points to the origin `Signature Unlock Block`. * `Reference Unlock Blocks` must specify a previous `Unlock Block` which is not of type `Reference Unlock Block`. The reference index must therefore be < the index of the `Reference Unlock Block`. -* Given the type and length information, the Transaction Payload must consume the entire byte array the `Payload Length` field in the Message defines. +* Given the type and length of the information, the Transaction Payload must consume the entire byte array for the `Payload Length` field in the Message it defines. 1 ensures that serialization of the transaction becomes deterministic, meaning that libraries always produce the same bytes given the logical transaction. ### Semantic Validation -Semantic validation starts when a message which is part of a confirmation cone of a milestone, is processed in the [White-Flag ordering](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0005-white-flag/0005-white-flag.md#deterministically-ordering-the-tangle). Semantics are only validated during White-Flag confirmations to enforce an ordering which can be understood by all the nodes (i.e. milestone cones), no matter in which order transactions are received. Otherwise, if semantic validation would occur as soon as a transaction would be received, it could potentially lead to nodes having different views of the UTXOs available to spend. +Semantic validation starts when a message that is part of a confirmation cone of a milestone is processed in the [White-Flag ordering](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0005-white-flag/0005-white-flag.md#deterministically-ordering-the-tangle). Semantics are only validated during White-Flag confirmations to enforce an ordering that can be understood by all the nodes (i.e. milestone cones), no matter the order the transactions are received. Otherwise, if semantic validation would occur as soon as a transaction would be received, it could potentially lead to nodes having different views of the UTXOs available to spend. Processing transactions in the White-Flag ordering enables users to spend UTXOs which are in the same milestone confirmation cone, if their transaction comes after the funding transaction in the mentioned White-Flag ordering. It is recommended that users spending unconfirmed UTXOs attach their message directly onto the message containing the source transaction. -Following criteria defines whether the transaction passes the semantic validation: +The following criteria defines whether the transaction passes the semantic validation: 1. The UTXOs the transaction references must be known (booked) and unspent. 1. The transaction is spending the entirety of the funds of the referenced UTXOs to the outputs. 1. The address type of the referenced UTXO must match the signature type contained in the corresponding Signature Unlock Block. @@ -711,29 +711,29 @@ Transactions which do not pass semantic validation are ignored. Their UTXOs are ### Absent transaction timestamp -A transaction timestamp whether signed or not, does not actually tell when the transaction was issued. Therefore the timestamp has been left out from the transaction structure. The correct way to determine the issuance time is to use a combination of the solidification and confirmation timestamps of the message embedding the transaction. +A transaction timestamp whether signed or not, does not actually tell when the transaction was issued. Therefore, the timestamp has been left out from the transaction structure. The correct way to determine the issuance time is to use a combination of the solidification and confirmation timestamps of the message embedding the transaction. ### How to compute the balance -Since the ledger no longer is account based, meaning that balances are directly mapped to addresses, computing the balance involves iterating over all UTXOs of which their destination address is the address in question and then accumulating their amounts. +Since the ledger is no longer account based, meaning that balances are directly mapped to addresses, computing the balance involves iterating over all UTXOs where their destination address is the address in question and then accumulating their amounts. ### Reusing the same address with Ed25519 -While creating multiple signatures with Ed25519 does not reduce security, reusing the same address over and over again not only drastically reduces the privacy of yourself but also all other people in the UTXO chain of the moved funds. Applications and services are therefore instructed to create new addresses per deposit, in order to circumvent the privacy issues stemming from address reuse. +While creating multiple signatures with Ed25519 does not reduce security, repeatedly reusing the same address not only drastically reduces the privacy of users but also all other people in the UTXO chain of the moved funds. Applications and services are then instructed to create new addresses per deposit, to circumvent the privacy issues stemming from address reuse. In essence, Ed25519 support allows for smaller transaction sizes and to safely spend funds which were sent to an already used deposit address. -Ed25519 addresses are not meant to be used like an e-mail address. See this [Bitcoin wiki entry](https://en.bitcoin.it/wiki/Address_reuse#:~:text=The%20most%20private%20and%20secure,a%20brand%20new%20bitcoin%20address.) for further information on how address reuse reduces privacy and this [article](https://en.bitcoin.it/wiki/Receiving_donations_with_bitcoin) why the same should be applied to donation addresses. +Ed25519 addresses are not meant to be used like an e-mail address. See this [Bitcoin wiki entry](https://en.bitcoin.it/wiki/Address_reuse#:~:text=The%20most%20private%20and%20secure,a%20brand%20new%20bitcoin%20address.) for further information on how address reuse reduces privacy and this [article](https://en.bitcoin.it/wiki/Receiving_donations_with_bitcoin) on why the same should be applied to donation addresses. # Drawbacks -The new transaction format is the core data type within the IOTA ecosystem. Changing it means that all projects need to accommodate for it, including client libraries, blueprints, PoC and applications using IOTA in general. There is no way to keep the changes backwards compatible. Additionally, these changes are breaking, meaning that all nodes must upgrade in order to further participate in the network. +The new transaction format is the core data type within the IOTA ecosystem. Changing it means that all projects need to accommodate for it, including client libraries, blueprints, PoC, and applications using IOTA in general. There is no way to keep the changes backwards compatible. Additionally, these changes are breaking, meaning that all nodes must upgrade to further participate in the network. -Local snapshots can also no longer be simply represented by a list of addresses and their balances, since the ledger is now made up of the UTXOs on which the actual funds reside on. Therefore local snapshot file schemes have to be adjusted to incorporate the transaction hashes, output indices and then the destination addresses plus the balances. +Additionally, local snapshots can no longer be represented by a list of addresses and their balances, since the ledger is now made up of the UTXOs on which the actual funds reside on. Therefore, local snapshot file schemes have to be adjusted to incorporate the transaction hashes, output indices, and then the destination addresses including the balances. # Rationale and alternatives -Introducing this new transaction structure allows for further extensions in the future, in order to accommodate new requirements. With the support for Ed25519 addresses/signatures, transaction size is drastically reduced and allows for safe re-signing in case funds appear to be deposited onto a previous generated address. Due to the switch to a complete binary transaction, size is further reduced, saving network bandwidth and processing time. The new structure is backwards compatible with "Kerl" WOTS addresses and therefore allows both current methods of signing transactions to co-exist. +Introducing this new transaction structure allows for further extensions in the future, to accommodate new requirements. With the support for Ed25519 addresses/signatures, transaction size is drastically reduced and allows for safe re-signing in case funds appear to be deposited onto a previous generated address. Due to the switch to a complete binary transaction, size is further reduced, saving network bandwidth and processing time. The new structure is backwards compatible with "Kerl" WOTS addresses and so allows both current methods of signing transactions to co-exist. -Other transaction structures have been considered but they would have misused existing transaction fields to accommodate for new features, instead of putting them into a proper descriptive structure. Additionally, those ideas would have not been safe against replay attacks, deeming reusing the old transaction structure for example for Ed25519 addresses/signatures as infeasible. +Other transaction structures have been considered but they would have misused existing transaction fields to accommodate for new features, instead of putting them into a proper descriptive structure. Additionally, those ideas would not have been safe against replay attacks, which deems reusing the old transaction structure, for example for Ed25519 addresses/signatures, as infeasible. Not switching to the new transaction structure described in this RFC leads to people being open to loss of funds because of WOTS address re-use and not being able to properly extend the protocol further down the line. @@ -745,4 +745,4 @@ Not switching to the new transaction structure described in this RFC leads to pe of this feature before stabilization? - What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this - RFC? \ No newline at end of file + RFC? From e0bb10822e60efb90e35ddd73afb7d3841f1be6b Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Mon, 11 Jan 2021 20:48:48 +0100 Subject: [PATCH 16/35] Apply suggestions from code review Co-authored-by: Andrea V --- text/0000-transaction-payload/0000-transaction-payload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md index 8bab115b4..6cf95d8b2 100644 --- a/text/0000-transaction-payload/0000-transaction-payload.md +++ b/text/0000-transaction-payload/0000-transaction-payload.md @@ -381,7 +381,7 @@ The Inputs part holds the inputs to consume, respectively, to fund the ou Each defined input must be accompanied by a corresponding Unlock Block at the same index in the Unlock Blocks part of the Transaction Payload. If multiple inputs can be unlocked through the same Unlock Block, then the given Unlock Block only needs to be specified at the index of the first input which gets unlocked by it. -Subsequent inputs which are unlocked through the same data must have a Reference Unlock Block pointing to the previous Unlock Block. +Subsequent inputs which are unlocked through the same data must have a Reference Unlock Block pointing to the index of a previous Unlock Block. This ensures that no duplicate data needs to occur in the same transaction. ###### UTXO Input From c1b96bb4d74789867cb55a4ae78f14dc8565b418 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Mon, 11 Jan 2021 20:58:22 +0100 Subject: [PATCH 17/35] fixes inputs/outputs/unlock blocks bounds --- text/0000-transaction-payload/0000-transaction-payload.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md index 6cf95d8b2..097d3a702 100644 --- a/text/0000-transaction-payload/0000-transaction-payload.md +++ b/text/0000-transaction-payload/0000-transaction-payload.md @@ -661,7 +661,7 @@ This validation can commence as soon as the transaction data has been received i The following criteria defines whether the transaction passes the syntactical validation: * `Transaction Essence Type` value must be 0, denoting an `Transaction Essence`. * Inputs: - * `Inputs Count` must be 0 < x < 127. + * `Inputs Count` must be 0 < x ≤ 127. * At least one input must be specified. * `Input Type` value must be 0, denoting an `UTXO Input`. * `UTXO Input`: @@ -669,7 +669,7 @@ The following criteria defines whether the transaction passes the syntactical va * Every combination of `Transaction ID` + `Transaction Output Index` must be unique in the inputs set. * Inputs must be in lexicographical order of their serialized form.1 * Outputs: - * `Outputs Count` must be 0 < x < 127. + * `Outputs Count` must be 0 < x ≤ 127. * At least one output must be specified. * `Output Type` must be 0, denoting a `SigLockedSingleOutput`. * `SigLockedSingleOutput`: @@ -681,7 +681,7 @@ The following criteria defines whether the transaction passes the syntactical va * Accumulated output balance must not exceed the total supply of tokens `2'779'530'283'277'761`. * `Payload Length` must be 0 (to indicate that there's no payload) or be valid for the specified payload type. * `Payload Type` must be one of the supported payload types if `Payload Length` is not 0. -* `Unlock Blocks Count` must match the amount of inputs. Must be 0 < x < 127. +* `Unlock Blocks Count` must match the amount of inputs. Must be 0 < x ≤ 127. * `Unlock Block Type` must either be 0 or 1, denoting a `Signature Unlock Block` or `Reference Unlock block`. * `Signature Unlock Blocks` must define either an `Ed25519`- or `WOTS Signature`. * A `Signature Unlock Block` unlocking multiple inputs must only appear once (be unique) and be positioned at the same index of the first input it unlocks. All other inputs unlocked by the same `Signature Unlock Block` must have a companion `Reference Unlock Block` at the same index as the corresponding input which points to the origin `Signature Unlock Block`. From ecb287b8892f8fa8a8f30ea058243cf784dc650e Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Tue, 12 Jan 2021 13:52:06 +0100 Subject: [PATCH 18/35] clarify from which data a tx ID is built from --- text/0000-transaction-payload/0000-transaction-payload.md | 1 + 1 file changed, 1 insertion(+) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md index 097d3a702..ef202feb6 100644 --- a/text/0000-transaction-payload/0000-transaction-payload.md +++ b/text/0000-transaction-payload/0000-transaction-payload.md @@ -52,6 +52,7 @@ A Transaction Payload payload is made up of two parts: 2. The Unlock Blocks which unlock the Transaction Essence's inputs. In case the unlock block contains a signature, it signs the entire Transaction Essence part. All values are serialized in little-endian encoding. The serialized form of the transaction is deterministic, meaning the same logical transaction always results in the same serialized byte sequence. +A `Blake2b-256` hash of the entire serialized data makes up Transaction Payload's ID. Following table structure describes the entirety of a Transaction Payload's serialized form: * [Data Type Notation](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md#data-types) From e2faf6940b4f3b40b72f234350bbd5ba69899177 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Fri, 29 Jan 2021 15:44:36 +0100 Subject: [PATCH 19/35] make it clear that the opt. payload within a tx is persisted as long as the tx is syntactically valid --- text/0000-transaction-payload/0000-transaction-payload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md index ef202feb6..5a6ffa928 100644 --- a/text/0000-transaction-payload/0000-transaction-payload.md +++ b/text/0000-transaction-payload/0000-transaction-payload.md @@ -507,7 +507,7 @@ The SigLockedSingleOutput defines an output (with a certain amount) to a ##### Payload -The payload part of a Transaction Essence can hold an optional payload. This payload does not affect the validity of the Transaction Essence. If the transaction is not valid, then the payload must also be discarded. +The payload part of a Transaction Essence can hold an optional payload. This payload does not affect the validity of the Transaction Essence. If the transaction is not syntactically valid, then the payload must also be discarded. Supported payload types to be embedded into a Transaction Essence: From 5553079b5f6c195f77a460ee3a8c21e4d94c3cc3 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Thu, 18 Feb 2021 15:33:08 +0100 Subject: [PATCH 20/35] remove WOTS --- .../0000-transaction-payload.md | 105 ++---------------- 1 file changed, 8 insertions(+), 97 deletions(-) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md index 5a6ffa928..5aab0795f 100644 --- a/text/0000-transaction-payload/0000-transaction-payload.md +++ b/text/0000-transaction-payload/0000-transaction-payload.md @@ -18,7 +18,7 @@ The bundle concept has proven to be time consuming, with several issues as well: To fix the problems mentioned above and to create a more flexible transaction structure, the goal is to achieve a self-contained transaction structure defining the data of the entire transfer as a payload to be embedded into a message. The new transaction structure should fulfil the following criteria: -* Support for Ed25519 (and thus reusable addresses) and WOTS signatures. +* Support for Ed25519 (and thus reusable addresses). * Support for adding new types of signature schemes, addresses, inputs, and outputs as part of protocol upgrades. * Self-contained, as in being able to validate the transaction immediately after receiving it. * Enable unspent transaction outputs (UTXO) as inputs instead of an account based model (UTXO enables easier double-spend detection). @@ -183,28 +183,6 @@ Following table structure describes the entirety of a Transaction Payload Address oneOf -
- WOTS Address - - - - - - - - - - - - - - - - -
NameTypeDescription
Address Typeuint8 - Set to value 0 to denote a WOTS Address. -
AddressArray<byte>[49]The T5B1 encoded WOTS address.
-
Ed25519 Address @@ -217,7 +195,7 @@ Following table structure describes the entirety of a Transaction Payload @@ -284,28 +262,6 @@ Following table structure describes the entirety of a Transaction Payload
Address Type uint8 - Set to value 1 to denote an Ed25519 Address. + Set to value 0 to denote an Ed25519 Address.
Signature oneOf -
- WOTS Signature - - - - - - - - - - - - - - - - -
NameTypeDescription
Signature Typeuint8 - Set to value 0 to denote a WOTS Signature. -
SignatureArray<byte>The signature signing the serialized Transaction Essence.
-
Ed25519 Signature @@ -318,7 +274,7 @@ Following table structure describes the entirety of a Transaction Payload @@ -447,28 +403,6 @@ The Outputs part holds the outputs to create with this Transaction Pay @@ -100,7 +100,7 @@ Following table structure describes the entirety of a Transaction Payload
Transaction Essence
- Describes the essence data making up a transaction by defining its inputs and outputs and an optional payload. + Describes the essence data making up a transaction by defining its inputs and outputs and an optional payload.
Signature Type uint8 - Set to value 1 to denote an Ed25519 Signature. + Set to value 0 to denote an Ed25519 Signature.
Address oneOf -
- WOTS Address - - - - - - - - - - - - - - - - -
NameTypeDescription
Address Typeuint8 - Set to value 0 to denote a WOTS Address. -
AddressArray<byte>[49]The T5B1 encoded WOTS address.
-
Ed25519 Address @@ -481,7 +415,7 @@ The Outputs part holds the outputs to create with this Transaction Pay @@ -558,28 +492,6 @@ There are different types of Unlock Blocks: - +
Address Type uint8 - Set to value 1 to denote an Ed25519 Address. + Set to value 0 to denote an Ed25519 Address.
Signature oneOf -
- WOTS Signature - - - - - - - - - - - - - - - - -
NameTypeDescription
Signature Typeuint8 - Set to value 0 to denote a WOTS Signature. -
SignatureArray<byte>The signature signing the serialized Transaction Essence.
-
Ed25519 Signature @@ -592,7 +504,7 @@ There are different types of Unlock Blocks: @@ -674,8 +586,7 @@ The following criteria defines whether the transaction passes the syntactical va * At least one output must be specified. * `Output Type` must be 0, denoting a `SigLockedSingleOutput`. * `SigLockedSingleOutput`: - * `Address Type` must either be 0 or 1, denoting a `WOTS`- or `Ed25519` address. - * If `Address` is of type `WOTS address`, its bytes must be valid `T5B1` bytes. + * `Address Type` must be 0, denoting an `Ed25519` address. * The `Address` must be unique in the set of `SigLockedSingleOutputs`. * `Amount` must be > 0. * Outputs must be in lexicographical order by their serialized form.1 @@ -684,7 +595,7 @@ The following criteria defines whether the transaction passes the syntactical va * `Payload Type` must be one of the supported payload types if `Payload Length` is not 0. * `Unlock Blocks Count` must match the amount of inputs. Must be 0 < x ≤ 127. * `Unlock Block Type` must either be 0 or 1, denoting a `Signature Unlock Block` or `Reference Unlock block`. -* `Signature Unlock Blocks` must define either an `Ed25519`- or `WOTS Signature`. +* `Signature Unlock Blocks` must define either a `Ed25519 Signature`. * A `Signature Unlock Block` unlocking multiple inputs must only appear once (be unique) and be positioned at the same index of the first input it unlocks. All other inputs unlocked by the same `Signature Unlock Block` must have a companion `Reference Unlock Block` at the same index as the corresponding input which points to the origin `Signature Unlock Block`. * `Reference Unlock Blocks` must specify a previous `Unlock Block` which is not of type `Reference Unlock Block`. The reference index must therefore be < the index of the `Reference Unlock Block`. * Given the type and length of the information, the Transaction Payload must consume the entire byte array for the `Payload Length` field in the Message it defines. @@ -732,7 +643,7 @@ Additionally, local snapshots can no longer be represented by a list of addresse # Rationale and alternatives -Introducing this new transaction structure allows for further extensions in the future, to accommodate new requirements. With the support for Ed25519 addresses/signatures, transaction size is drastically reduced and allows for safe re-signing in case funds appear to be deposited onto a previous generated address. Due to the switch to a complete binary transaction, size is further reduced, saving network bandwidth and processing time. The new structure is backwards compatible with "Kerl" WOTS addresses and so allows both current methods of signing transactions to co-exist. +Introducing this new transaction structure allows for further extensions in the future, to accommodate new requirements. With the support for Ed25519 addresses/signatures, transaction size is drastically reduced and allows for safe re-signing in case funds appear to be deposited onto a previous generated address. Due to the switch to a complete binary transaction, size is further reduced, saving network bandwidth and processing time. Other transaction structures have been considered but they would have misused existing transaction fields to accommodate for new features, instead of putting them into a proper descriptive structure. Additionally, those ideas would not have been safe against replay attacks, which deems reusing the old transaction structure, for example for Ed25519 addresses/signatures, as infeasible. From 27da30c54b3013fa02ee774a4590698cddd9d499 Mon Sep 17 00:00:00 2001 From: Luca Moser Date: Tue, 23 Feb 2021 12:05:37 +0100 Subject: [PATCH 21/35] adds dust allowance output and clarifies signing of blake-hash instead of raw essence bytes --- .../0000-transaction-payload.md | 274 ++++++------------ 1 file changed, 88 insertions(+), 186 deletions(-) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md index 5aab0795f..ec7e967c3 100644 --- a/text/0000-transaction-payload/0000-transaction-payload.md +++ b/text/0000-transaction-payload/0000-transaction-payload.md @@ -52,6 +52,7 @@ A Transaction Payload payload is made up of two parts: 2. The Unlock Blocks which unlock the Transaction Essence's inputs. In case the unlock block contains a signature, it signs the entire Transaction Essence part. All values are serialized in little-endian encoding. The serialized form of the transaction is deterministic, meaning the same logical transaction always results in the same serialized byte sequence. + A `Blake2b-256` hash of the entire serialized data makes up Transaction Payload's ID. Following table structure describes the entirety of a Transaction Payload's serialized form: @@ -210,7 +211,59 @@ Following table structure describes the entirety of a Transaction Payload - + + +
Signature Type uint8 - Set to value 1 to denote an Ed25519 Signature. + Set to value 0 to denote an Ed25519 Signature.
Amount uint64The amount of tokens to deposit with this SigLockedSingleOutput output.The amount of tokens to deposit.
+
+
+ SigLockedDustAllowanceOutput +
+ Describes a deposit which as a special property also alters the dust allowance of the target address. +
+ + + + + + + + + + + + + + + + + + +
NameTypeDescription
Output Typeuint8 + Set to value 1 to denote a SigLockedDustAllowanceOutput. +
Address oneOf +
+ Ed25519 Address + + + + + + + + + + + + + + + + +
NameTypeDescription
Address Typeuint8 + Set to value 0 to denote an Ed25519 Address. +
AddressArray<byte>[32]The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key.
+
+
Amountuint64The amount of tokens to deposit.
@@ -285,7 +338,7 @@ Following table structure describes the entirety of a Transaction Payload
Signature Array<byte>[64]The signature signing the serialized Transaction Essence.The signature signing the Blake2b-256 hash of the serialized Transaction Essence.
@@ -336,112 +389,35 @@ A Transaction Essence must contain at least one input and output. The Inputs part holds the inputs to consume, respectively, to fund the outputs of the Transaction Essence. There is only one type of input as of now, the UTXO Input. In the future, more types of inputs may be specified as part of protocol upgrades. -Each defined input must be accompanied by a corresponding Unlock Block at the same index in the Unlock Blocks part of the Transaction Payload. -If multiple inputs can be unlocked through the same Unlock Block, then the given Unlock Block only needs to be specified at the index of the first input which gets unlocked by it. -Subsequent inputs which are unlocked through the same data must have a Reference Unlock Block pointing to the index of a previous Unlock Block. +Each defined input must be accompanied by a corresponding Unlock Block at the same index in the Unlock Blocks part of the Transaction Payload. + +If multiple inputs can be unlocked through the same Unlock Block, then the given Unlock Block only needs to be specified at the index of the first input which gets unlocked by it. + +Subsequent inputs which are unlocked through the same data must have a Reference Unlock Block pointing to the index of a previous Unlock Block. This ensures that no duplicate data needs to occur in the same transaction. ###### UTXO Input -
- UTXO Input - - - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
Input Typeuint8 - Set to value 0 to denote an UTXO Input. -
Transaction IDArray<byte>[32]The BLAKE2b-256 hash of the transaction from which the UTXO comes from.
Transaction Output Indexuint16The index of the output on the referenced transaction to consume.
-
-

- An UTXO Input is an input which references an output of a previous transaction by using the given transaction's BLAKE2b-256 hash + the index of the output on that transaction. An UTXO Input must be accompanied by an Unlock Block for the corresponding type of output the UTXO Input is referencing. Example: If the output the input references outputs to an Ed25519 address, then the corresponding unlock block must be of type Signature Unlock Block holding an Ed25519 signature. ##### Outputs -The Outputs part holds the outputs to create with this Transaction Payload. There is only one type of output as of now, the SigLockedSingleOutput. +The Outputs part holds the outputs to create with this Transaction Payload. ###### SigLockedSingleOutput -
- SigLockedSingleOutput -
- Describes a deposit to a single address which is unlocked via a signature. -
- - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
Output Typeuint8 - Set to value 0 to denote a SigLockedSingleOutput. -
Address oneOf -
- Ed25519 Address - - - - - - - - - - - - - - - - -
NameTypeDescription
Address Typeuint8 - Set to value 0 to denote an Ed25519 Address. -
AddressArray<byte>[32]The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key.
-
-
Amountuint64The amount of tokens to deposit with this SigLockedSingleOutput output.
-
+The SigLockedSingleOutput defines an output (with a certain amount) to a single target address which is unlocked via a signature proving ownership over the given address. This output can hold addresses of different types. -

+###### SigLockedDustAllowanceOutput + +The SigLockedDustAllowanceOutput works the same as a SigLockedSingleOutput but additionally controls the dust allowance on the target address. See [Dust Protection RFC](https://github.com/iotaledger/protocol-rfcs/pull/32) for further information. -The SigLockedSingleOutput defines an output (with a certain amount) to a single target address which is unlocked via a signature proving ownership over the given address. This output can hold addresses of different types. ##### Payload -The payload part of a Transaction Essence can hold an optional payload. This payload does not affect the validity of the Transaction Essence. If the transaction is not syntactically valid, then the payload must also be discarded. +The payload part of a Transaction Essence can hold an optional payload. This payload does not affect the validity of the Transaction Essence. If the transaction is not syntactically valid, then the payload must also be discarded. Supported payload types to be embedded into a Transaction Essence: @@ -474,84 +450,10 @@ There are different types of Unlock Blocks: ##### Signature Unlock Block -
- Format - - - - - - - - - - - - - - - -
NameTypeDescription
Unlock Typeuint8 - Set to value 0 to denote a Signature Unlock Block. -
Signature oneOf -
- Ed25519 Signature - - - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
Signature Typeuint8 - Set to value 0 to denote an Ed25519 Signature. -
Public keyArray<byte>[32]The public key of the Ed25519 keypair which is used to verify the signature.
SignatureArray<byte>[64]The signature signing the serialized Transaction Essence.
-
-
-
- -A Signature Unlock Block defines an Unlock Block which holds one or more signatures unlocking one or more inputs. -This block signs the entire Transaction Essence part of a Transaction Payload including the optional payload. +A Signature Unlock Block defines an Unlock Block which holds one or more signatures signing the Blake2b-256 hash of the Transaction Essence (including the optional payload). ##### Reference Unlock block -
- Format - - - - - - - - - - - - - - - - -
NameTypeDescription
Unlock Typeuint8 - Set to value 1 to denote a Reference Unlock Block. -
Referenceuint16Represents the index of a previous unlock block.
-
- A Reference Unlock Block defines an Unlock Block which references a previous Unlock Block (which must not be another Reference Unlock Block). It must be used if multiple inputs can be unlocked through the same origin Unlock Block. Example: @@ -574,28 +476,28 @@ This validation can commence as soon as the transaction data has been received i The following criteria defines whether the transaction passes the syntactical validation: * `Transaction Essence Type` value must be 0, denoting an `Transaction Essence`. * Inputs: - * `Inputs Count` must be 0 < x ≤ 127. - * At least one input must be specified. - * `Input Type` value must be 0, denoting an `UTXO Input`. - * `UTXO Input`: - * `Transaction Output Index` must be 0 ≤ x < 127. - * Every combination of `Transaction ID` + `Transaction Output Index` must be unique in the inputs set. - * Inputs must be in lexicographical order of their serialized form.1 + * `Inputs Count` must be 0 < x ≤ 127. + * At least one input must be specified. + * `Input Type` value must be 0, denoting an `UTXO Input`. + * `UTXO Input`: + * `Transaction Output Index` must be 0 ≤ x < 127. + * Every combination of `Transaction ID` + `Transaction Output Index` must be unique in the inputs set. + * Inputs must be in lexicographical order of their serialized form.1 * Outputs: - * `Outputs Count` must be 0 < x ≤ 127. - * At least one output must be specified. - * `Output Type` must be 0, denoting a `SigLockedSingleOutput`. - * `SigLockedSingleOutput`: - * `Address Type` must be 0, denoting an `Ed25519` address. - * The `Address` must be unique in the set of `SigLockedSingleOutputs`. - * `Amount` must be > 0. - * Outputs must be in lexicographical order by their serialized form.1 - * Accumulated output balance must not exceed the total supply of tokens `2'779'530'283'277'761`. + * `Outputs Count` must be 0 < x ≤ 127. + * At least one output must be specified. + * `Output Type` must denote a `SigLockedSingleOutput` or `SigLockedDustAllowanceOutput`. + * `SigLockedSingleOutput`/`SigLockedDustAllowanceOutput`: + * `Address Type` must be 0, denoting an `Ed25519` address. + * The `Address` must be unique in the set of `SigLockedSingleOutputs`/`SigLockedDustAllowanceOutputs` (two separate sets). + * `Amount` must be > 0. + * Outputs must be in lexicographical order by their serialized form.1 + * Accumulated output balance must not exceed the total supply of tokens `2'779'530'283'277'761`. * `Payload Length` must be 0 (to indicate that there's no payload) or be valid for the specified payload type. * `Payload Type` must be one of the supported payload types if `Payload Length` is not 0. * `Unlock Blocks Count` must match the amount of inputs. Must be 0 < x ≤ 127. * `Unlock Block Type` must either be 0 or 1, denoting a `Signature Unlock Block` or `Reference Unlock block`. -* `Signature Unlock Blocks` must define either a `Ed25519 Signature`. +* `Signature Unlock Blocks` must define a `Ed25519 Signature`. * A `Signature Unlock Block` unlocking multiple inputs must only appear once (be unique) and be positioned at the same index of the first input it unlocks. All other inputs unlocked by the same `Signature Unlock Block` must have a companion `Reference Unlock Block` at the same index as the corresponding input which points to the origin `Signature Unlock Block`. * `Reference Unlock Blocks` must specify a previous `Unlock Block` which is not of type `Reference Unlock Block`. The reference index must therefore be < the index of the `Reference Unlock Block`. * Given the type and length of the information, the Transaction Payload must consume the entire byte array for the `Payload Length` field in the Message it defines. @@ -604,7 +506,7 @@ The following criteria defines whether the transaction passes the syntactical va ### Semantic Validation -Semantic validation starts when a message that is part of a confirmation cone of a milestone is processed in the [White-Flag ordering](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0005-white-flag/0005-white-flag.md#deterministically-ordering-the-tangle). Semantics are only validated during White-Flag confirmations to enforce an ordering that can be understood by all the nodes (i.e. milestone cones), no matter the order the transactions are received. Otherwise, if semantic validation would occur as soon as a transaction would be received, it could potentially lead to nodes having different views of the UTXOs available to spend. +Semantic validation starts when a message that is part of a confirmation cone of a milestone is processed in the [White-Flag ordering](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0005-white-flag/0005-white-flag.md#deterministically-ordering-the-tangle). Semantics are only validated during White-Flag confirmations to enforce an ordering that can be understood by all the nodes (i.e. milestone cones), no matter the order the transactions are received. Otherwise, if semantic validation would occur as soon as a transaction would be received, it could potentially lead to nodes having different views of the UTXOs available to spend. Processing transactions in the White-Flag ordering enables users to spend UTXOs which are in the same milestone confirmation cone, if their transaction comes after the funding transaction in the mentioned White-Flag ordering. It is recommended that users spending unconfirmed UTXOs attach their message directly onto the message containing the source transaction. @@ -631,15 +533,15 @@ Since the ledger is no longer account based, meaning that balances are directly ### Reusing the same address with Ed25519 -While creating multiple signatures with Ed25519 does not reduce security, repeatedly reusing the same address not only drastically reduces the privacy of users but also all other people in the UTXO chain of the moved funds. Applications and services are then instructed to create new addresses per deposit, to circumvent the privacy issues stemming from address reuse. -In essence, Ed25519 support allows for smaller transaction sizes and to safely spend funds which were sent to an already used deposit address. +While creating multiple signatures with Ed25519 does not reduce security, repeatedly reusing the same address not only drastically reduces the privacy of users but also all other people in the UTXO chain of the moved funds. Applications and services are then instructed to create new addresses per deposit, to circumvent the privacy issues stemming from address reuse. +In essence, Ed25519 support allows for smaller transaction sizes and to safely spend funds which were sent to an already used deposit address. Ed25519 addresses are not meant to be used like an e-mail address. See this [Bitcoin wiki entry](https://en.bitcoin.it/wiki/Address_reuse#:~:text=The%20most%20private%20and%20secure,a%20brand%20new%20bitcoin%20address.) for further information on how address reuse reduces privacy and this [article](https://en.bitcoin.it/wiki/Receiving_donations_with_bitcoin) on why the same should be applied to donation addresses. # Drawbacks The new transaction format is the core data type within the IOTA ecosystem. Changing it means that all projects need to accommodate for it, including client libraries, blueprints, PoC, and applications using IOTA in general. There is no way to keep the changes backwards compatible. Additionally, these changes are breaking, meaning that all nodes must upgrade to further participate in the network. -Additionally, local snapshots can no longer be represented by a list of addresses and their balances, since the ledger is now made up of the UTXOs on which the actual funds reside on. Therefore, local snapshot file schemes have to be adjusted to incorporate the transaction hashes, output indices, and then the destination addresses including the balances. +Additionally, local snapshots can no longer be represented by a list of addresses and their balances, since the ledger is now made up of the UTXOs on which the actual funds reside on. Therefore, local snapshot file schemes have to be adjusted to incorporate the transaction hashes, output indices, and then the destination addresses including the balances. # Rationale and alternatives From b886adedf62d8a4cc12a4e61e5fde3d2c683c399 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Wed, 3 Nov 2021 11:35:53 +0100 Subject: [PATCH 22/35] make payload validation consistent with other RFCs --- .../0000-transaction-payload.md | 154 ++++++++++-------- 1 file changed, 88 insertions(+), 66 deletions(-) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md index ec7e967c3..7fcda7bb9 100644 --- a/text/0000-transaction-payload/0000-transaction-payload.md +++ b/text/0000-transaction-payload/0000-transaction-payload.md @@ -91,7 +91,7 @@ Following table structure describes the entirety of a Transaction Payload 		Payload Type uint32 - Set to value 0 to denote a Transaction Payload. + Set to value 0 to denote a Transaction Payload.
@@ -112,21 +112,21 @@ Following table structure describes the entirety of a Transaction Payload - + - +
Transaction Type uint8 - Set to value 0 to denote a Transaction Essence. + Set to value 0 to denote a Transaction Essence.
Inputs Count uint16 The amount of inputs proceeding.
Inputs anyOf
UTXO Input
- Describes an input which references an unspent transaction output to consume. + Describes an input which references an unspent transaction output to consume.
@@ -155,18 +155,18 @@ Following table structure describes the entirety of a Transaction Payload - + - + @@ -297,7 +318,7 @@ Following table structure describes the entirety of a Transaction Payload
Signature Unlock Block
- Defines an unlock block containing signature(s) unlocking input(s). + Defines an unlock block containing signature(s) unlocking input(s).
Outputs Count uint16 The amount of outputs proceeding.
Outputs anyOf
SigLockedSingleOutput
- Describes a deposit to a single address which is unlocked via a signature. + Describes a deposit to a single address which is unlocked via a signature.
@@ -218,7 +218,7 @@ Following table structure describes the entirety of a Transaction Payload
SigLockedDustAllowanceOutput
- Describes a deposit which as a special property also alters the dust allowance of the target address. + Describes a deposit which as a special property also alters the dust allowance of the target address.
@@ -274,14 +274,35 @@ Following table structure describes the entirety of a Transaction Payload - + - +
uint32 The length in bytes of the optional payload.
Payload optOneOf
- Indexation Payload + Generic Payload +
+ An outline of a generic payload +
+ + + + + + + + + + + + + + + + +
NameTypeDescription
Payload Typeuint32 + The type of the payload. It will instruct the node how to parse the fields that follow. +
Data FieldsANYA sequence of fields, where the structure depends on Payload Type.
-
@@ -315,7 +336,7 @@ Following table structure describes the entirety of a Transaction Payload
Signature oneOf -
+
Ed25519 Signature @@ -349,7 +370,7 @@ Following table structure describes the entirety of a Transaction Payload
Reference Unlock Block
- References a previous unlock block in order to substitute the duplication of the same unlock block data for inputs which unlock through the same data. + References a previous unlock block in order to substitute the duplication of the same unlock block data for inputs which unlock through the same data.
@@ -417,36 +438,25 @@ The SigLockedDustAllowanceOutput works the same as a SigLockedSingleOu ##### Payload -The payload part of a Transaction Essence can hold an optional payload. This payload does not affect the validity of the Transaction Essence. If the transaction is not syntactically valid, then the payload must also be discarded. +The _Transaction Essence_ itself can contain another payload as described in general in [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html). This payload does not affect the semantic validity of the Transaction Essence. If the transaction is not syntactically valid, then the payload must also be discarded. -Supported payload types to be embedded into a Transaction Essence: +The following table lists all the payloads types that can be nested inside a _Transaction Essence_ as well as links to the corresponding specification: -| Name | Type Value | -| --------------------- | ---------- | -| Indexation Payload | 2 | +| Name | Type Value | RFC | +| ---------- | ---------- | ---------------------------------------------------------------------------------------------------------------------- | +| Indexation | 2 | [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html#indexation-payload) | #### Unlock Blocks The Unlock Blocks part holds the unlock blocks unlocking inputs within an Transaction Essence. There are different types of Unlock Blocks: -
- - - - - - - - - - - - - - - -
NameValueDescription
Signature Unlock Block0An unlock block holding one or more signatures unlocking one or more inputs.
Reference Unlock Block1An unlock block which must reference a previous unlock block which unlocks also the input at the same index as this Reference Unlock Block.
+ +| Name | Value | Description | +| ---------------------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------- | +| Signature Unlock Block | 0 | An unlock block holding one or more signatures unlocking one or more inputs. | +| Reference Unlock Block | 1 | An unlock block which must reference a previous unlock block which unlocks also the input at the same index as this Reference Unlock Block. | + ##### Signature Unlock Block @@ -474,33 +484,37 @@ A Transaction Payload payload has different validation stages, since some This validation can commence as soon as the transaction data has been received in its entirety. It validates the structure but not the signatures of the transaction. If the transaction does not pass this stage, it must not be broadcasted further and can be discarded right away. The following criteria defines whether the transaction passes the syntactical validation: -* `Transaction Essence Type` value must be 0, denoting an `Transaction Essence`. -* Inputs: - * `Inputs Count` must be 0 < x ≤ 127. - * At least one input must be specified. - * `Input Type` value must be 0, denoting an `UTXO Input`. - * `UTXO Input`: - * `Transaction Output Index` must be 0 ≤ x < 127. - * Every combination of `Transaction ID` + `Transaction Output Index` must be unique in the inputs set. - * Inputs must be in lexicographical order of their serialized form.1 -* Outputs: - * `Outputs Count` must be 0 < x ≤ 127. - * At least one output must be specified. - * `Output Type` must denote a `SigLockedSingleOutput` or `SigLockedDustAllowanceOutput`. - * `SigLockedSingleOutput`/`SigLockedDustAllowanceOutput`: - * `Address Type` must be 0, denoting an `Ed25519` address. - * The `Address` must be unique in the set of `SigLockedSingleOutputs`/`SigLockedDustAllowanceOutputs` (two separate sets). - * `Amount` must be > 0. - * Outputs must be in lexicographical order by their serialized form.1 - * Accumulated output balance must not exceed the total supply of tokens `2'779'530'283'277'761`. -* `Payload Length` must be 0 (to indicate that there's no payload) or be valid for the specified payload type. -* `Payload Type` must be one of the supported payload types if `Payload Length` is not 0. -* `Unlock Blocks Count` must match the amount of inputs. Must be 0 < x ≤ 127. -* `Unlock Block Type` must either be 0 or 1, denoting a `Signature Unlock Block` or `Reference Unlock block`. -* `Signature Unlock Blocks` must define a `Ed25519 Signature`. -* A `Signature Unlock Block` unlocking multiple inputs must only appear once (be unique) and be positioned at the same index of the first input it unlocks. All other inputs unlocked by the same `Signature Unlock Block` must have a companion `Reference Unlock Block` at the same index as the corresponding input which points to the origin `Signature Unlock Block`. -* `Reference Unlock Blocks` must specify a previous `Unlock Block` which is not of type `Reference Unlock Block`. The reference index must therefore be < the index of the `Reference Unlock Block`. -* Given the type and length of the information, the Transaction Payload must consume the entire byte array for the `Payload Length` field in the Message it defines. +* Essence: + * `Transaction Type` value must be 0, denoting an `Transaction Essence`. + * Inputs: + * `Inputs Count` must be 0 < x ≤ 127. + * At least one input must be specified. + * `Input Type` value must be 0, denoting an `UTXO Input`. + * `UTXO Input`: + * `Transaction Output Index` must be 0 ≤ x < 127. + * Every combination of `Transaction ID` + `Transaction Output Index` must be unique in the inputs set. + * Inputs must be sorted in lexicographical order of their serialized form.1 + * Outputs: + * `Outputs Count` must be 0 < x ≤ 127. + * At least one output must be specified. + * `Output Type` must denote a `SigLockedSingleOutput` or `SigLockedDustAllowanceOutput`. + * `SigLockedSingleOutput`/`SigLockedDustAllowanceOutput`: + * `Address Type` must be 0, denoting an `Ed25519` address. + * The `Address` must be unique in the set of `SigLockedSingleOutputs`/`SigLockedDustAllowanceOutputs` (two separate sets). + * `Amount` must be larger than zero. + * Outputs must be sorted in lexicographical order by their serialized form.1 + * Accumulated output balance must not exceed the total supply of tokens `2'779'530'283'277'761`. + * Payload (if present): + * `Payload Type` must match one of the values described under [Payload](#payload). + * `Data fields` must be correctly parsable in the context of the `Payload Type`. + * The payload itself must pass syntactic validation. +* Unlock Blocks: + * `Unlock Blocks Count` must match `Inputs Count` of the _Transaction Essence_. + * `Unlock Type` must either be 0 or 1, denoting a `Signature Unlock Block` or `Reference Unlock block`. + * `Signature Unlock Blocks` must define a `Ed25519 Signature`. + * A `Signature Unlock Block` unlocking multiple inputs must only appear once (be unique) and be positioned at the same index of the first input it unlocks. All other inputs unlocked by the same `Signature Unlock Block` must have a companion `Reference Unlock Block` at the same index as the corresponding input which points to the origin `Signature Unlock Block`. + * `Reference Unlock Blocks` must specify a previous `Unlock Block` which is not of type `Reference Unlock Block`. The reference index must therefore be < the index of the `Reference Unlock Block`. +* Given the type and length information, the _Transaction Payload_ must consume the entire byte array of the `Payload` field of the encapsulating object. 1 ensures that serialization of the transaction becomes deterministic, meaning that libraries always produce the same bytes given the logical transaction. @@ -521,6 +535,14 @@ If a transaction passes the semantic validation, its referenced UTXOs must be ma Transactions which do not pass semantic validation are ignored. Their UTXOs are not marked as spent and neither are their outputs booked into the ledger. +### Payloads + +The _Transaction Payload_ itself can contain another payload as described in general in [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html). The following table lists all the payloads types that can be nested inside a _Transaction Payload_ as well as links to the corresponding specification: + +| Payload Name | Type Value | RFC | +| ------------ | ---------- | ---------------------------------------------------------------------------------------------------------------------- | +| Indexation | 2 | [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html#indexation-payload) | + ## Miscellaneous ### Absent transaction timestamp From 9d85237d0b4545a5ef610953bf65dd2c4ae15a77 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Wed, 3 Nov 2021 12:01:26 +0100 Subject: [PATCH 23/35] Update links --- text/0000-transaction-payload/0000-transaction-payload.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0000-transaction-payload/0000-transaction-payload.md index 7fcda7bb9..c6f4bc902 100644 --- a/text/0000-transaction-payload/0000-transaction-payload.md +++ b/text/0000-transaction-payload/0000-transaction-payload.md @@ -4,7 +4,7 @@ # Summary -This RFC defines a new transaction structure for Chrysalis Phase 2, which replaces the current notion of bundles. Specifically, this RFC describes the transaction payload to be embedded into a [message](https://github.com/iotaledger/protocol-rfcs/pull/17). +This RFC defines a new transaction structure for Chrysalis Phase 2, which replaces the current notion of bundles. Specifically, this RFC proposes a transaction payload for the messages described in the IOTA protocol [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html). # Motivation @@ -433,8 +433,7 @@ The SigLockedSingleOutput defines an output (with a certain amount) to a ###### SigLockedDustAllowanceOutput -The SigLockedDustAllowanceOutput works the same as a SigLockedSingleOutput but additionally controls the dust allowance on the target address. See [Dust Protection RFC](https://github.com/iotaledger/protocol-rfcs/pull/32) for further information. - +The SigLockedDustAllowanceOutput works the same as a SigLockedSingleOutput but additionally controls the dust allowance on the target address. See [Dust Protection RFC-0032 (draft)](https://github.com/iotaledger/protocol-rfcs/pull/32) for further information. ##### Payload From b0469494f976761035c6a7fbbcbaf5bdd0fac859 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Wed, 3 Nov 2021 12:08:18 +0100 Subject: [PATCH 24/35] fix filename --- .../0018-transaction-payload.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename text/{0000-transaction-payload/0000-transaction-payload.md => 0018-transaction-payload/0018-transaction-payload.md} (100%) diff --git a/text/0000-transaction-payload/0000-transaction-payload.md b/text/0018-transaction-payload/0018-transaction-payload.md similarity index 100% rename from text/0000-transaction-payload/0000-transaction-payload.md rename to text/0018-transaction-payload/0018-transaction-payload.md From 2a15eb999a42758d909f6ba937908ea273023917 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Wed, 3 Nov 2021 12:10:41 +0100 Subject: [PATCH 25/35] add image to git --- text/0018-transaction-payload/img/utxo.png | Bin 0 -> 52729 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 text/0018-transaction-payload/img/utxo.png diff --git a/text/0018-transaction-payload/img/utxo.png b/text/0018-transaction-payload/img/utxo.png new file mode 100644 index 0000000000000000000000000000000000000000..b6f9f198869b3485acf8c67b7a98331a41a9f18a GIT binary patch literal 52729 zcmbTe1yoes`!7zZlqjW?LkUvSDMJf`q;!|0q%=dL5>f*=bn4J4-C+?!OGzUzfTRrF z|HJ!&-|t=j-@WUu>zd^{OV2rb?`J>p`8?0F&%5U;klXlF_!t-%x1Y&BRmZ@oO4G}DJ^hv!xz+*xGZ(XPaxPjHu z`7(5$=U^t;b!JC&x#9>V_We$id?1c*bX!}nffN31+(XyBfvh^a;P1WR;o*z~1mRyJ z6vN;65rrgDt#2)7(o!sDQqC=B8b21EvrsYqHEK6j+Fa{9Osnd{`cPXD>!IY;j|lHD z_6}Z5;MQG=7Sj{q3)2fJ%=2?KA)#=5#~<9hpY&hReUW~xCdQ8|6@=M>{k8k?V-^l+ z4@XQFG}`%b>)pKm-23P7v;-4%^*C)^%{sTifsCCd8it}rm?U)n{(^XMSYR}FAI@Rp zggl-WFZ}e$OJ&TX7oEZ%mJcEaEn$}kT9I;DF3s)M?-r+@1mNM}645lWe3-;CuX(HX z9s@7tpI=fG25Qh=47nc@7}B<))o6Yi9xf#4M5dSL6S_2leR|f_L5G7M5x%|G@?P&z zfO4ZQ4cXz(re)C!)0hED=Bu~F1U|!i4pN>dx4(x+Xp(YxFkl-*kl9dcv@sAvhsDE! znLOHXUb$7ac>f+#kLpTIdseUM&%e@Qrjvy7OFgQyjYl87zlfz9Xg=a_ zB|dy{uw5LH=z34-#Gs>K$(GVU=6Z)raj@VJ#$6Kghe0kR6y>LDt<$CeSg8mFzBub+ROC!DIdL zh8_`qjzHvQjrTq_(k?~3c5&G$cXa*H?|RF#`8y+d1poJm~R$Qu7A>;L%w=iT{)m`HQW{B25-0m`7a!3G4kB*>}fx?E`-x)xfTJYO8W zPK@=~#+qn9_p`aSo~m=FIBi!<51d%vm=JnnNm0NpRH{MGpiF#Ugj zN(zB!n;+4ZmA;{EE99b&rpNc&@iz2l<_3>G?k{fVY|ALzP{VQf{v|o7);Eg5o*~%f z9U-#++3be8_FlMj?IWSy)TO_ic0?TsGWU=&Qc1+=h4s{|3wf#cw zo}j<`pW)NbMyU-p!sQhI+2K!$f#}Z9Qdl>cxxHo*mA^>8xg$2)7-8Kz$g4c;-HXs( zc{*?J@Cl(JqgD9^w!5j}o!NX8DT8WIx$7f ztF=#pwft$MW93i*RgH>7sAgplgY!f|&Z?cm(qMA7p7q0OJ!MZTQ2O^A%MAzU>6TDO z<()HMvt4wob8C(gH1^s9#ssDUZ=S|U_#PMd2shF=qiz$H?s%kFNxkOvv4PiJQxjxq z^l@E@%5`}U`EFsYZ)7 zwsYelpb-Se@B`Hgv;_9{o=zs~mxHpgrO7lP--pF9YNaevsMj?Jt zTS2E|kz8B{-+fN=p)m+ikK)Qi-@=5otPAA6Pi$jAu2{ropbtYl!I)DDckVLWRS52BB#LG5i#=jgwB zj=^)p5_I~Sp?K!g$wZu)Grf3tU@!A^i28FE7%x<^l8WTjt)RCz3=~6le=kLU)XNRR z<!zMc#nrYhily~Fv}=rM)v zW`P?p3o#=smIedU+hd;n>j&Bb0pq&4&L5(L#fFJw?7-rK(P01GtPBQ8=q}mIQ5h^p zAY8d&YhvH)>Oo+NM$uo1DG>8=^q(&YlW~%uixdMSSzs6Nzd;uG+v_zDXG!6DxA5xT zVer8mvFtv*V1?aW;|{ro4L6y9C}`8cV^4AySbQ}0|NG)Ehkp)CM&#aK4+oY4R1FVV z{03+0DIgZ1AOYQSIOL5x#n)@$zX9e;Rkc7Nh{wIt$)pYt3ku|ea&-20v={;L=ChxCW6Wv@u5Pv{-f+SFDD7Hz$xzM%Iu_xdj#@q7 zhRXZ8f`7da5Ft9tB>@LGrv#GFZ=|`s3i+Uz$Qc$LE%-{&k8gK)SaW@%nxNqR(6&wH zXEfcXd+eU_BZn#ZB(GM@-`{du}+8%ZlsI)7sa&xkll%!df%RUxrD zY-h^HX$5j0F(M4Pj!l5;wV5cj{OTJN$OxUPJz*cl=ae)wOykPpcBig&n2hc|!d&@@ zg25pg2mI8KD~NN+j*{XYD`?*>mck~6C84@##U%=sgDFI3x?vop{d9xCXqicwub{`e zE|Wohz=gjry6X|rkDi|Xd2qQ#o(jbiw|umHrnp~ex411|Msjj8g^(l7O+t#m{f)^r z7q90a_wmPs;aA(?8x1Jaazol}K~l`hu7!iyfHDgV*_EfbkCc+KgGR&AAnz4=*?S{nJUl#($>M9_+j3C18?p&f*SPe#78bmt zkYsV^;hZd1&EmH2s$QC~KaT8J#a+-%qph04UJPWv%e%vuH&o*xB~u0c0`@;YeL>r# zzsv@EJ7ZMZ{tekOmj+qbNWp;zryrR6uxyp-FgZYbYd;_~6ZSw3`TIRCE-uDtAU$LI zuRae4LMGVil1R;>S}z%XP+=z{AMEtre*&Z=3eW@gjwsdGKoIUJ83m1ttC|0dd-+qj zkmN(Pzk4kQ>=(a2jK`Q{;O@$w zycVXDR&VOhpGRU66N`LFsP2X65g0?BZcydML0+a7zfn?F4)*9>DAucl3q)3E6x#a^ zl^Tg!uCjX?pmc(-T}vR2Az&aY`WYNiIA8_IQSglV0=WH70FlVJp2GCtZKrQz&+oc`glW+$k~zM<4s=kDY!->Jt59{FdWW(nzXPou@)|#Hp?4QXkCU z_LxH(V$p!WyZO|;01kQed?WDuv~m*aec&1%;jKU5z!Q>t_R63idDL;L>5^rRwewM) z;g>%~d8f!mlzY?FH_xI`TuEVKunvL#hl5}f2xg$tjZehfb5Vg`3&>uDVJu>Y| ziiA>ut@acjQz;(e!AX8%&D{+oMn`-1nM+Aw_GOB`p{AbI^!_ie6@5skV!FRB;x*TG zp081ci5i^q>-uvYMLPixEVn7vzNv`gjd`e95rrYHLtTnQh~1?vF^CS?Tg!4??gRYh zK9g~-P0>0>qtAh3nrHwXZ2y6Mt#S`IZ)D^zkgW<+44_Ft7+Gp=~~$o7Y|Gov9!YO)K|UCe4|# zlremn^AtLNlhsfyDS>)%-Z+%2UV;Rozho5y!$^t`uusHW&fh}#B*Th_H#4Zru@0L|@-24cwWSVM^1YkX6bwS%=wH94?&&)`lmEY~_JdDow`Ou4PDl z>9oDyZXc2aSz~Z~vY>v?HuUO}uqAI%A`wT&@WwJ>{QHF|UDj!e;ttKct*I*|tBK6a|79e(s2&pp`x8FZ*3=R&K z7N=N310`*3**rETf`=o1dsX$DA`!QeD*ux@IJv|L4<61LV{K!cn~#%OhZYsNJcPZx z-)FYdSj6LhDy*Z^jRq_Im!1dprX)jmUxj|UX7qp50M(-1@DiM4#L>nM!y1@0suqds z@M~<9E}6sn_WgT(k$1uxJ=SE6LkH>zwmh%z34nPs+>=07-rn;UC)P;uz`tXP-Fi&-VU>_arq4#a_5f~`Cq?UbNLcp z`L=4D5NxlR3RabHyNH$+ek7t1Zw=v#M2H^;sa@|z8EF>y_!!sp#ORr1^qeq`>05RJ zcg=)Blrst$Z!?@v4DucDkSk%M5ptM#3x|^t(g+VY^5m(ce+egN=QjI-^ENb8C+A76 zxFXbz-T0o$-@v5;1TL4?^9~Q^0t0&p&W7V0PN&{yv%vOWioS;scMKvRjBIR|q5K2b z+hwkT^I8O$GMCV;Vv?dN8kYlWfTZngCaepH=6ap~|7c#;a?GY*>ln4SHpZSA^*~g+ zOM7#+l{V8C{m#WiULIG|Y<;+ZG=%6uA$T%RHFK>3hMoe#2e-`to$vAQydJQ(`JW1v zzaxLW43VYX6rWUZ`ODL$>qy#OIDNMegr1(CY{he!T3O{XyyZ>T%vM|6?n&m$$?VM# zqh9EMLFD8@l%eo~!aiQu59_p=)son5?K9)(veKJ7BWtf4dP*Q#XXOZJcdbo*?L`phT_zVIO= z+rhwCcx){M+OwMapOApj4vR!L(|lrLVjk{-%pEaJHW+{^a_ksKmZ=2o<)JujuAt_l z#}?C9dNL=9!^Qy%m005wY~yUR z_VGQC=Hr79=AUi%VZlo7TR(i!6L|qx(GP z#1&M+2Lmu=FSzgpYZ-7ovCfoNvT6b6CH$)gLw8@X!6f{S4k+M<4#mV!*YxAwbKU8F zi8lTyAs?CW2mGLl{ZrHvWhHIY)eyD^EJyKoDbJp zT`$0&98NfM#VUF`UW!pW6cVQ*ix$?bwGg2uVv|SdUrI|-fqA&E zjec)%UxN#B8aLJTkZD6(l~V=7qM~FyJZczV6^O$1I$OJ1t$22!9%sQXha%Si1Ox9> zrL7cvzB}SdD*a^@)>PiR5Q}3)gvA;vn0Mx9#P4(xPN~JVpaXZ&x*554V-kgSpzfWth=sOYHu#WS8fWu*cof>RS}e4DhKGHbEMtG8bVPxETW%A{9NtevAn+&>ubY)~iyJ@>GZ-s_B?`@0If%Y(d zAH;CVsSHY)*amQm*yQ_R(ViEdtr(M_{EoA{E>{}KO%lY5_OcktbRro=P z#%~lY=?7%btEQsgy~6x4i^Gd}&S|ei0zqGvoiD<5q z(66Pry*4Jb+?P)L;6cg45)Z!tj)nF3bff3O)RCfB)s|^v43N$^{5!=zI6>-A@cxmB z+%P~VhgVX!ics&u*$q1S#AXp|&HZK_%NHE+f>5XSsQ|ML32Qnw-lhuKlPT9_|KnX` zd;}!7YPH(2ykFqF_GSlm%(OLton$%)|3#N;6zN^&QvTxmo2N7#L`;{sBs#Toz@9i? zgNv$UqCHDyy%`suC>QLK^jBNF;w1|J$91Y{*4+rfSvjJC2uzNZDEjRBtscxGN-6_a z*R-7MHRlRHvQl=xtkgkxlu&&-SK8G0uIUf@V-LR92MQV(h~eFuJ;>t>&khL=fp>xX zyil1*yskOwv%BxGd7$gA#v4D;n#P8jf#yE0TPnR3W+K3~yF3Qoqd9$j2AcCEw0Q*Z2n3GB}Yw z?>kOql1B@B6-M9Tb1`NzBoyvCoO-d7cy4jMcYyaZN1fl2Q#CeZgR#*$)aygxN;$Em zO~pI%;)k0B2?s6X!}88LyxQ)G>Ut7MhF!ei?WF7;E)0s5VqPSIPr7AW1T`phoLuto z%66Pc|A?Z04+$OJ3ZbzdWR*Iwe)0qfR=8I_t}FycBG}+;ro`RRJSFijiwb@9yBGNS zRXK-fSII`I6q9qPck_qzP;wg~B5|>rnTZWmL$=M+U45$(E!NKjOHnoUM}K^*)28j_ z`k5xZbfm0tcyCHI)6zOag1ey? zd#gD&ROt=4#uR`21qmrH%F$#OnS}T{v&z}ZKb8E{_SU=TSDzlmay== zcIeuA~2Cby)0YEYp|x=^%^%3;E`4@GwBz4!+E@zxp4 zk*Ju1m6g?bFK~BfhuyWbps2g-DU@N2fMdKpTLFCMf5WK$h*qGIU3(`kRNY?5zXdIr zD}m@@GE<{XS}ywQwGWy{2Czrsi|}b70~Ja4gZtG%y+euic-L9P zyDtnJN>Xt+vwL+aQ+Afo_q^38q5J$Uw+ozyjGF$osPKJ^bAxu zn_kE*JWW_}&`LtoV4Vg#4$h5%kUGK@En!)OR%^n;2X<#VHo13@QD`H2tU{nGMcak9@HzCpZ z<3y%$?4fCV0LpK6$S1xR+5VXNqt)9@)dgoJDh;^103&r*M<0Wz5UnSe7y{*&Evq2D z8r;+npnD7Z>57bFso=sP?Gj5h<3|r4nod-`v>C5pdI};XCFObf<6$I7?6~2;x;G^l zkCd5Z$heu`K>*Yiz>zw?{_15OCXrB2mqH_u{FQ%d==`M?;tMG2Ih92QGg^-4o=)4)lu zKduT4)R`0fk3^FUOD+y#Fr?uw=ulm4sgXvBVeGkl*OlL4Z?R7Xx3fzwA}M#1Fv!v; zuub(u^#eCQVegAcb&yzFs@C6l_Y+7gFLrXn!3v+q$GIOdGq(@ffkLl{XJhDn)Zp~n zJvDKZ8tqvd%eDU=11PGWACB&X6TAoUwrD!o{do5`l38SbW(>6VD@XulfI)-B{YB#| zG7Md}SRI_yYG3*~U%9(RS1^DnMW}h4wc?J%c;F)3f)FZo+T@ZrJYA<|4&EQw<9nxi zismDcBl`BsJd~T)Oeub~z|d_!(}fxKez_%RkKlOBd4#j2GW9hyzV+5i@kFj2 zx9&CT;^;~>2~mtWR*VjeDjaTQt5>O68=x4^x(-jT*=yRKDvLSYvC8|f%);<4~OEv4an}3ixbSvZsyP4whR|;xnUYE2SU+} zN$47P>zj$(()#A|2&29=m1Yv3?q*_*b$AfO1jseF8o`eMsZiSmR*T3TAspv3QD?iX$M6as%?I{n39 z<17Nn7e@{sQ`e575-4AdB3~h<4*l+$$jAUDnOOhGR=j;jBFLma*K|eq*>lVY6FqG? zLfIGhOOjx}Nv+u|<(p?WPnH^Viw3l`yodEcS}(!ghqnOwL0=^&>{7|=?y6GszCHYK z8iNi`(yyoov9DIYl`YFqEn)Yaw^wCp@ChU9iwRZ6%+}jDb1yL_lyax?Hp4mi@SdVw zFgU8diQ=|Bz^KwwE3j)u`R!50>a%uhi^b7vuMHqwClC}F@-ORt>hg>7{@iOK+}7cX7&G?zavl;1TrlPWTm7~xRHVcHaBS? zjq8UoJB+~Xgi30dH=jITCqjubo!6Bi~K8CSZF>eg~fnvINDrHMS!PQ!iq02Q zG{_A5XlTp43m+lVcWAGSAF-a;R|m0+*c?*)6O{rz0mE+YHW8{`lLUog#@Hi@X_ZEA zC#_+}a(ugifxUMZ!PSlMz_-^z4YDM6e90$K0-a$+KR8!QE@jiv)ph@t!nMPqtT85n zq_wqb6yC{KG3%{HV%g?p6{6Y7ZTK>QX{bnPT|9f9_gNw2hp`wOB6f<6r1;lF*^~m& zx@HzjzHQxTmhpDR1dcbxn4Yy3vZ%zCJG&&=v5V!rcA)AZwUWFNKok>79|U*ur*S*f zmIiI?KzGh!-u@;HO;E`GJPIx}p|!?hvb#A#_@P)pb4)_psu!^rBD$Zgax$X5keZjw z%$^K!U{>daO;l9%+l}ezD;8GPtf4X~+OMlOmO#>8gpLf$IIiP_Lz;P9Zrnz?EKvy& zzo$l$cS@3<3V00NjA?CItVgY2DUlXNUIz7X%xd$KMtF530DK&EcVa6Pi}q4Fh6$G8 zy^a>xAU*1W=KfK&2XfO6TJfFO&t@qdYPF7t^a$X4YqNcGM-ClYK0w97im`k3B5e-R#cQqdl-;+kzvL^&?)gWh73zbT+fz1eB(tajXh9+a`;$fmx>nQe+F2Oadz3gAX6*jaYd}f-Dn%L|`l?5i}b=;LscVkbuD4rLul$7`?~?opr{svi|UL zQm(=27PgzxT%rssOR+I_lxWo_C{TW*k-Cchl2{o)yTLAwCHC+yIq13-F|W~vx-CNS zA>(l!6T5d8hEeX@6?stQ56*>-J0!&SXS-N>&C)z@?I#a!JNh(H+YT2fLl;^8!=I@x zqr|{k(F>t2#JV~gnq^4Sy;`v#q=iP3(~i3qJ1M)&*clYX2!-d}X==Sa^7Zv#ovh4o zWd3H8quV(#LV1{iEx3Q?`W1r@$i`6 z9*OD%>0aHR7Z_?sZ~5sEW+iTVFvDbT1PeDW?u-y z>KRbe@%&*q{#S(mv~#?cZj(jZyalL?eOEt56XBdY!czh@xFWWaa>xoR{ne>{wT3_( z8X!yV^0rPI*g$pS3bQA(IhsVc0W&Th<`t9;05%RWF7~EofoWNHlKg!p4S42>^&+XK zCjCzSruqbdWJ(g!DSjqL9do7HjzGOT2%93 zC8s~pUv7kl5BuA82_l)ra~l9*uJ$Pig`jm`y7^vLiR81e04b9PS}qx|v%pq4a~Q1N zJy~L)KB&Ta)f#PHtZoDEVEe__`xOoua$}+m}l*f3nkLNh#B z9bR;WD-=h7A%i;tY9O(GLzsX%XzwR`BN3u&DQ07R%W4{0_xD876K z{5dkv+E_VzDGvJ$hys|Lemo7orw00 ze{VKvB+7=&_7R-0fn|->)qEZ{G)wdS$h@ml zr628m!4nuxoDb5&9(+uVaL&`l#l^2W;YO9eFoX(Sr#OK!w{Uz1Y%H6BCHo##t$kPu z@d&#PK_;3isEBf0Ufko}4XDl^`PP;2&IP{&_cw74!@Yp)VWOU!Psd7)6erQ622LNG zW?Smqe#fC_fgTIfwm?kXy65}dm?3v)qy5j0yZFQtubD^BR@qofkXDiI*}2v7(n9p3 zc|fDScIEvoB^1iHeE{d0G=(Uyab`h$m)W$xb~G!Sp0ta3eNq*BI$C1IM+QJC-Na&N zGUwqDCUo5u?|J`7m6LQbl9F$rSdZ^pM@J&QxxKypZ?P6Z2LbjCUjI`%V(0C2w~;svZ<_*{3d^Pb@sM3rNP0+aB>G|qv zs&2ih3P?#xZI8-ks{973+y(cD>{|SR1h_!byLpn6e#b?*D(vOz>q6bPLU^ZD7i6|0 z4X;HPKH7(D|M-TPRO6OuAHq1K<=&|HQeR*H-4g*VDwkQm1J;i$I?~cuKod$x!eaxr zEhc8>7o){`N!(_yRaFec>UZv9xl|mT?JeE!mv!$xsJ*5)M&IDy|I!=HG$0*3-$Qux zmJu4cB}yd~oVUH1_h_$)`O}-?&p-komXBGHON-=@a>`qvsHFiCuxEjVoEApovdTWfa!2PQbSO1_|7&Qby`+l*Z%EVgqbQl2&Gsm& zh4N5u6P?+2CjN3?I)j9L*YCNn9l)5a107yF(0QN}-LgP_I#Ivw zVT~4sZc^*EX0@K0q2jvP+)bn^bfFD7UdhZ{JN+Yd23Wdx=7=yfFnTcV;!BR2m0^Aw z@-wS%vUu6epG;;J%V#Gi8BJrS3i!JfA&D;@xL@`?ix75ztt*MGHPP zPxjF?YiiWs@ILU-tT(B6jn+pNsv(%Qo6E7pUMzg_+H`sP79yPreID>DD&P?B)LZa| zOb3!S)_IyMk)b?7yQgFK9bY_e_KeekpQ}-E=}Hw6{sCz|G>HYbH$VL<#$yIQEj^md zk%30mT2NVZ=p5ZpuP=tJJ|6>z%iF?Mlf?ZR7~u8w^>9dfvEJy;few2OZ{K<^XMT@o zKY71yH-aq+a_1s2ZJp!oC@#cNJJ;BnNLZSVmlcb39MY9$%jb?Z7Q$G-?5T-`R`tn; z`*K#o>D?9d5-|xs;m|Fg$S+$rVPNTep~#HoT{}mT&a-qCaVEweSZd6!D`5uaI}@8dyR?x zegb}hj<=3R!6_Qb2BmH9&CIr-7OhHrFYMpy#tf^NEIMU?PEVP}b|5Qus}WCj6QIMu znniPW!4B1bY1ll`f6*{Ckd_p@8i(f|^nIo)X8wz#I}xV(ss`@NFy6C0t%z^$vS#Qy zTCidylmsd*gk^=Tv0@6gOEA_kvXI$=?1g7~^ZG<{tlf3xI;!R>1|{pQqrU$(Tu7GT zDAB`sE!~hk?XvT6Y~k^lKsflG zT)ZiI<^HSnKQN@5R{fVRg^Z(K$q;w*w9hHZud3!z;XMG6D|R2BQ1%&S%^y7g)J;ih z#5nH5lwG`0HhA^m;DOw~p?ePN(la27lYgi{sxyG5HLxvT@C5KUBMl@Of+&VodG;X^ zQEC-Y5Dv;)_X+K0S-;39L&O3Cq8MPSBCt?@`7gWgWE7cxm|n6sai)cQ<5B7!O}Acz z;CoifCvlK!m5nFQlG(~iTY-F1$~$=QW}G`5UA3)1Im)8}@>|X{`L}1@H!kqQVmY`` z0LhjA-XtT7W|o+exL`eSqWsJVsV`?>2NEhik{{0*@$NNW4R%FZ2~}Xiilc^StnK)2 z11!N-Y@+!g44vpp3;_UHE=d#6t0Di7`x#tRi_-a*l3CVjtrZmN@9ujTOxrBy6S?;; zP)1C>vq#Dat?EDZK?^IWRFoG7S5+^m^*)_2*vaorK~`z`?7f<>y>TJ7u<@_!IerAV z9!=*bqK{P03_YH2fF?;rM8?Cxg{h1AjU_Ed`%aA$0Zm6TyM7fWK=)c9uH$U|ZS0H( zZ;OkIVgORfD=T@~zh-bm4UnvjKfABNNFv#acC~M@I!t&J&p> zjN(@sgt)1;cz$eCPJhr9RDA%$pj#Gr*VARGy1Ix<=l)2uURBg#uXdv3#s{*_`A@Bh^mYYAO#6xJJsRB?k9D7B0vjlts6ON@UgBQ%fBo! z`4Upl?px3?Rtl!nI9TKgo>&<8i@;xp{pqf2c75Bs??bo4vX;PUOSHb<<^ReZ@u15b z-Lin&(>H%GHZsusJi|ADplD2Tf#|XQXkQQF{*z#>>u&QqB(GRtzweis4K)y~5YLX^ z8cZtcniSgn{KjvUzQR#JwHuK(nOpkuxXnAa$O37^yH0x5CjouJ@Is=0$=lJHJCCO-d7ghj*b~w zec$o%wRGByE6y@3k52TgRt5#743*sLq{^SIAWm_!jS9??L?WCUqGPY+#R?1r(Wps@ zYKRUb;Dhz+_F25QHz!eROa!{J-JCW!jJSZB<*=eE_jNxWw-CUW>Q8E?N?c>X$Rh_P zjN|ym7c;s{K(o>Rk>Ic)&2M33Vp3R%_)fY8op>n&eOj~_2}>Fv5u(4~_NpiTWgPLy>&kRO|WM3Y_}q&$)y??{L$|FLpNcMVV_Z(O#)Vs!V^YDOxthL+8vbHJ+KzCAIN&+^d3O{pz-m*iMY zOt$D$YXR^s$SWF5?x|q2a+dqVub5#>-^b=W&l%wsn^J0yg%P%vJQ)mk?^4~q2l%*3w6G>MajTQ zOD=5D8xcSa(b%&1YAm3DLxkcvn-{Rx_rw&N7p1NZjx?nIso^D zW5ozWGekGJDFJ=+35)0W7aFe4uA$cMQ&=I|AS{V3AMEc!Q9&jvQG!l+K<$;`Km8N= zY?z^FFH_H(ynJ?u-z8Cn`gbx9c!Nxca_JaOc^$V%%=kzmfNZn{r6puU)|e=HB=HSk ztQ_JOtgASgQp2|&bgPj#4e|vkTJJNIWYM3li2;<|6~ZHU-5MeS3{dAe$z)+%`tBZ& zvU2q2)83Pp7p%jD?l(N!WykH;6-jTIPWcX_D>M@j0 zZq&#bu)A| zUgcSP%zd_2=lrX(P0R*iAdXswPuk73`Tv>S0PTf5o}TxYRiK8A=Nb<;XJEmV5ITPT zr!SE?yGjouQzBk2oFGt-g~lCbfX)x|UeVNUuz~Tt`g$mZxIgBx*crwP(OTETq;H2k zJMR^@V#}uv3QoEWM%)j2f!+!mkD=QNloOfkMp+S{Y;Xha!-&5bvV0N%&YBw=bLO`4 zk`L}t!SUy=Xju}^%X?4Sr%-o89xbYoPkt}saAir-TCG+9+dqbp=9L9@E?841GH`I< zsPsXLpGNt9BgOI61If~i70*UiU!(=)cfOLfKM@zAJj?LT`hivO$ZR;87C6(?q6{3& zx%S7D!0-z**-qu#7c(93axVIZ538yiCJyd^&dYnm3b|*dS?@KUh!ukQc+ChGtKnJ* zIptz+^BdmZ+Re77P+_<*j`t#(!2;*M9{pJxCnJ22ngus|9I9U)-=A*zDBV4>NJ0ly z{@Vdlp@!%DS4I-|>Vc6kkN{)eOhz}c!lIlawRztP@#lxK^69YM&JcH|V}|(=0S*4K zynCRv^{oBM2bmY7Jf2l-@1gLDo3ONqy$jJIr5cTl_lm0;Tx<3(Wmm=Aj}2em(|7@f zt}4B}r`{V<>TQltkN?K1r}oZaeAP4lUT)a|HqO|UI~O97B|k(47gf#`ThNSbTDbT+#2Qw!uo8`mx;WJc_oggUUn}-p3mI>pf4T}$za0Z z!|;+JkilTcs;s?;>(2LX*NYq_gZS>5T^-`u(gX2O%>H)ZI9?HX*P@9=`e>v53`Mcm znP2LVwybo2TBB)YI>{StZ`oYPZRpYy%yZk58QzZuvBa{_V%*0w*Jr*S&T(Sp#&ksX zxG5!z5P!WHRU8B6)T{r*KgojCVDsHqDN~r#ZpOco-_?fszo^AK^h#-2l27-@8?eXP z594I!LZdqc@f}db88&j>4j zL7L0O#pqmUdfWRP&oXL$k>`S?k|&zY`bU<&fZg2StwzylVTeOhbyDGw(n!Cheo3=; z_3MIZ?z}NEqtXbCcnSYj>FZtqrC5lAm1gQQtua%_qbYqxiio-XMzqWGf`Ca|jsmks0CaG~3Y25NR}B>W^m;#--!$)R`-KbvqmtwF zGkm6oGd&{QJ^C0?gF|BTDaUdgXU9`R%@dH&u~Wa>pY&aTO4ev}0dKWiXA)GG*OLs% z2;)t!t^myA#}l<*NKNgvbp-CxuwKzNtW{jy>OnSDC0j|2hrN4Ms+}d!YO<&{`BiJ& zPaEm{5SFatvfY<(wtTPYXY&U;Ida9nPKXY35(hYxgBo|xdiV<6O$uKSWng3=-(LH9 z&T07=Q6d1N9`)5^3w|wcw3FohE3JYDX5YqW$5?$JGD#SU?kr2q!;LhoSqKentZgYV zYn~X>($j)!3i+yyJyN(aQ5}HR_sI@vepwU^2t}w_?YrCN?)~kFRzWyu#LVfI=2}la zTX4nF^U>$F68&Ah?3JWNCEl`Ov(tyO_+?O_z7#h-40_1`=%E0tHKYIA(gR3qrcj-o zk7|@Ca76MtxTjt&!uGz1=(5^>lNz$Wq^32VL1N~V{#bmx%TArVgg$xVZ+JY^fY7afg`(2C!;)i@I&tj`8WTG;O+7F7HdBBB+zhJrvID}o0OzTX#@nVutiD%dpC zOVvt@;(K@X4jRUz6c&MWlxNnPKR}X*#%HWV+1PQc&@5}eCT_~) zSAZ?2lm7_UEp<^M(H@@><=mFYk=f^@C2E6nMuQ1NQqnN#op4fwuD?jXRA__W$QeWV!DF@7HL zT$X*|>~GL{IQKSC1Iod|BB%a>S%s$W3rZ1+W6O;c(Dv7@t+UlxZGqiEnCHKPFfkvY(fBp@$QGKJzBVxVu;6GTu(4E7YPWcJaqe86 zXTqpREuyG=(a|M-=NtcR0z3~_WsaFioC=rHU+Mj=5%BA4!F!j7Km$eb2#u=z z>`k*~=P&{;I#a2~3Py#WFmOKpczw8M@XiToLF|XIC%8*q>e{ zvzz5qMC5U6cHP6rt#z+{$9)j1fBWT@93g7(){}a$@;`lwEn86Mt}zE&ZGzJ!C)kXZ z%xo-gLm`RR0%EJ8%!<67gLZtwORIZ+=W-{qAXr}$9BH+5b-{UdjaK!_RBy+^DkjKO zU_2+bN-vYg=dT93Q8tXIa+(;zSKTWp(TjUV zdF@|9eX4E?N!AgTli-L?c>F;h?XJItzIicQ_-(=WpPH4MvgvN&G>^aRcj{E3@ZzCn znVnV4^ZmrBl?Hlo3PUqBo|YL;-nGTDm-i#yV9}-?_%74>-hJ~sRSC-PcR#T#2;PBq z=KW%{ptC{gDbt)ny0!5mj#8e{P4~u&sfrWb{rakIu3qo+O&#_>6i)w?Hf4Y>#PDx# zeHg*IFYXSccs|feg@h$b8LLX>)|6hXpRgYV%i`^jHk8max&q!KrAUH(nhI&2Gx!_* zdArCXDx#QN5IvYt>k^@5wEz73o8v!4v|N^kUFm#2bJKdwBtuW{rhmvP$5Cd58C zKHZDGS6{Re{v>I zGzswaw|D(EY`fdBnj)V`3U=tVqE3pSWB8dS;NlK%^P1QHd{8FP4~y&Uq*273q43ev zQ2mYmw|wK0NB_%LSeWfn`UOMLE0snjHNW5xSE9F41hut91o($pzoUrvygiyk7`S5^ ze^BP+p=dfBX3x@`SM9x5tG~=c5(zi9->bc_PPyvy-0&&qJxb{(H=>I5OfAnHNganSI`$wAH$!ayp6d z94%E4@zuV-nK}G3*{$P3&`?Y1CX-+#cj&tnDaX;ZpWXU&^fO9b7TdU*x@UNp|+4ubSF+ z`1h~#_q;i&M*le*lJSV!8#@2a8nphiCp~px5w-MUbU4;)S)!=SZf+=G1BS=d3z4_U zU#51-Ykx06`}GHOh{tl2#3DN{{+x!G67_>ZV&)T(PwV)v@_p;&CG+XLlK^k`=k^4N zf^UPNY1bZa-ZD-2|0C?JqpIw-xNSgCKmh@1*obr^C9!E?Q-XAt(p}OmT^o?@?vU;f zflWzwyXo$(@AjPMdCocSc;E3c_=f@9d)=$%nsZ+Bw>4ICe2#8=nsvo{EW}}>%4t)f-r?s z8e@m?htu-G9FBvWFFXvAQBzZHnNsz|LeUw|V96q-jhfqAV| zA}F?dlNM~eWYb%0CF_^D>o<$q+9&a^^R?Js{{A2i;j5?1AdmuE$x2sI6G zvOBDk>21-*W&V`h)MgyNrGO-~FBG6zTfQ>HGylAt9tzsWRQ(%R5R}qCYGFNh9|1xPudD?a0F=v4?!HKV= zMYSNMe?na=Nyz=gl-Ygm_C097JCDo|M`p8JKxXw^VnYG0alTZ(XTkfx+|aX}_=xVWnc16j&XNnb@+L9HY0(qL zT#HGrj`#_NWDtylg3^Ks-K813i!hr=6LMZVuZb#b0ktL0Vvhf% z7qamo&7@uE&hSZ$Qq0@6fZuTvj9=baPY^-{CYoi5TwNOzANrL`J)I*?yq0Ni4fdc+_Y4FJzx6C7V}AI!ru`ZVQMz}*+_EG!O~4#;JLXwskG~w zLQ2-R|9`Qbpz!q259H;}4erGZrAP&Dn#+i#K*QP%;UDzKdD&RAEcl^VNUG{af6`~I zQp=xKA6vb3B;;=&e*6@QZ-n6WH1l_7JGVpd^eJ(Bgmq;!xXdTIir=YbLM%z~hjk)@ zk0ed2!-`RRgzk{N1XBF6KI6u+#hri+ zmNIY$LDl?(H{!Hgs*N5SQCOX9)I(s`!3k)D(xCkhL~(noHM8H|THU=cG|Zikg(MXN z3BFKUAj^yMr{gYXzd`ye=fZw8k=L%fHbUcefKc}qO3&ZYcx@l_d$X-v@7>oLv&2@LU&?M*Kr zY~ktz1S}r@uipO{^UnVT7IjN4E+#XcvH;P_>G^i)+{Q5(s;i^YL2s@V+5c9AV`Buu zyc+IxpZ2rCs^JOg2i&pX;+532(?Ty6{z50{en@Jnr8xTJ2m6Ud)n$*{W$9>gn}_d% zjp62XcDF-TghzX?4UKdH_UeEw4g2G)-K1N+ij}N+svF<#A5`NFG$ug1+Ko>Wav+}a zY-xSLLBNxr==oom0$uGRmtBmY8*EDKmW*I=l2VEy-ky( zeK~wqUnmfG2gItP{)kQf_1!@Y@0XCs-Ziv6XJXw#@s=0nhvJc@2+ZWi1tEfbdj3zcRgCva#i#-OvY6K?LNg{%Cap zO9Jp7>JPPv8v$6oNmC=ga;VC(aCPiPSPmQuIka^aFZ&B~#*2lR*%cZQs7Av=XoNdx{$aivl7P

`=; z+hu{J$rR#$ISL}MRoh3O(*N_s>OYx1l9{3@`&e0?9-23MuiAlFXdevoE3AcPo~4H(d&i4?UsQ|`5!eod_*84|DWRMQ&pGJX>nxZ;qj-wV;VnCr(K2QLhbrzFO;NL(p6Rkx*)+DTo8o_{i9RU}tC7WA>7=R!V=qZoeUw+$U1!LDH3Tme7t4 z>RzuSy0M;YiakDI`0Ju|<3GrwAus$qfdr^r=udyfHp?Dy9(;I?q$T?|Ap7BemA#e& z4gIEUW~)%t%28Gh(y@Rv_DIGY4Is=qm35Jv1FXp-s)$yUj$H)&8&oguZ+~|>0xkRe6J%^xGX#w?Dc;e^*`lPY7Cy5zm@(s4_A2=XJo`4{x291@{5>jpqF{Qa^drt5>SHn zg7Ff!CHn6%>99o}q=Lqv4fgf@I9P19d$@C5a2OT{UFf4u`Y~0e^%*Gd>^A|bE>)`H zZZ8jEv>6`R3j{bgNGgQ445WCeL0{}-hU2bb-fdP7S zf4^L0ez;tU0MU5Qu&{(g)4zmG08|ULpf{JnSFujpK10AYb}&DO@I5F93ltDAuxT)p z8Qrg}3GnPag?C}}r<{gyciZR!eJTHd%P&MaEKjcPFP9mKgt7UsJO7kHjsXSS8-qz> z!@vTII9`QOQd0iR2lp$hxF-P&DLAhs2;?RiEq?w*RyJHKf4J$>YXy*wh(d-Dp)QDn z9SCD=yceHgcmw@YjP;AVIO!))clPPmyiI($1#svZpoE^>U65%V@3+~+zS!RJuBd60 z7$XrA39s0cUb_5!}jS-!3RqwA#{=_B9@zO`VFB%cc^Bz|aGvQkMwjLlfb zIUYw(XMk!pDrH#Ad^ZSK2TG_UT}u~cR+Y*rR;o`5(~x$hU0-0JsZ1I7D^Kez@8yD3 z^;3b$D1@;3zi}5tw89gY16lNoy@kLsJUhw28mKbz~ALBoYYtrvj#6d}} zoGZfb?0N$M+OZU<(f$jZlb-#fXR1(@3}_VeMEU-V!*EUgpatYbEaP+HomVj;Z2veZ z`$Ibs$A*A(n4Fwk-_h@%apEiXA2I~VzR?a;Ms?)LB#hMC==E}n~%^5rLHn99HqnQtnQW*RLXbgC)i9`0CnaGzLs9 zeys*_k;h4AIR-avygl#aHJU5>D`7RuUn~aHUjbfM5hPUIrhK(5@|_>J?R-j$npQqt z*LMHzYiSC4mmLDogNlR$ZjlKnk1 zb1*2a`J$`i$Ip)(4I`YuVIlTQR8djUNV#h&mqmP4pn{WhT!hVBtwn*X=el*tT@RtJ zkHMNk!1jNYJgu{8z6sc&;oY$=v1z-v$?Ju_^A2v4zhGSKR{6#KUjSbJE9E|Ls84@n z2>=03_UCBI-BHT3ovIJn_yMkg3ZeV?P9AEmWFG1&@PQODynrH6%Ad02&?J~W`=-@j z`_hUO5^KwixRl`%RQ;@98Tsi`xV`aH^GQrtjCb4fR~yOFpxvpmlGFjZX?S;-jI)Hw zu!ZG#e#D9UhkvWL;FkPby@mcO094!ORFX%e=?<`oZYTgra#vYN z$&MPc@sEJ8(^v+eELGI|`O~L2G#`?4@5JQ~M%!4uN53r&@mQ%;Xm7=BRYX3e*nrdj;zr2?RUFeq3fX$E8Xc4^S)xVz)PtjV(0xp`ya^`;uhAjpMdvbfBG+MN)y1QIR9W%G!|{wDGvWCU?0wY zeTfd*Ca|ji;noY5%Mffe?2n~4`sA@&Rv-Jpt_JdDhQCwHQ;&Z?4)P_@JG}ZYQQ{_= zk*6JA2=xe(s>7}|1jmrw_#A_KzO98uj_jQM$EECD{99Yws_MNzCh6dg8a(IxT?c0n zOza%>e?o*N3-LFmYyX`ud+n_=kaKQbQoh9wB$-p-E3SInMXJn4!&zCAaP;S)$prX# z5d2s8lPoMOm1)UN;wIn2*^%$=@5@n8o@!&hIFiSDfvVx2jQuwYz!ROI_PsWf@Q|5k ziaDt;T*POY^6(P39kO)zgcci&u8;3ix8wPL3I?iNV%&LO3_WQIHQ!x*JPVCN@<+&W zcGVYtDT>D6hlhek-h1mIi02Y~aWlhn2*mxJ!S{#{+jNnIIPDY256ViN8llGo zn&fu?%Xx4#d{?PQ7Lu1A$5cH$nz6S)jZMH?9bC%I=Em}d+x)t>U;GJIV5#!1P5EvK zGqkaRD(I%CXZ_0Qyw83k+H&vNicPo@ChVq@!gM67u`%zml@UHXI8o{fa?+vdK z$~R)uWd@k0;&$1?24vKzsL!MfmHVkW>~cxlZAs~21QJX{SUwj8g7gnb)W?Ne*p+se zlpXL<1G==OC|IA>u%4CM@T2(E4GC*5+%c>{tN@perMKrW=+V9QOFQ&U+EQbo7(Vo5 zlpM$_`j3sB1PJhPGn*<`sM@MCFZr>MTbVJNEcJ@rOs38^W8Q;S)^`P5HMEDR$28Xp z$i#hCdljhGZGu)My?XH7T%HND_@D(|R=PMg+PpGA2!n_>{9vI3%Xz-rs}Hn#Rtr?S z`08LBiS5uvIdfpB$yxC(R2>Fg7J75uV1IO7u|f1e=qMvt!c{vAxu9cQo+vdib*Yg1 z<<|oKV52h?e8|NSK2~MF2ezfS>?BX}j=yygO1e7nY&SEuWgtO?Mfa1^uqUkcQn%eA zc9qtG)DIxmd{#2)f8eIYl51Fkd%8=%Igi4qV4@Oc;v0j0sXI zv4#blC!ep2678JlPz_Y1-`8FBWWaiA_aFPDr7-AEe+MyCMM06SB$8&h^V!w|lz2lWKRhwS=5P@!cT7#y3S2 zMnWxk9YhG9W3BQXcbBd%E1v%p^Ml_kO~-uJ#5csdVccvEy3q+{-J8AaEgIk!WGre#gw z+qv*Uo3HNor`@23`L6P(6Xze1e1JNbN?qlI?I{g@>-8Z5;)(LwHQ=Qik>bDfDmzba z#D4bH9cbgS?(5YhFB)=*BOJ8L#eqn%eOr}8YAJ>)icjhyY{ikP>ZH2Xpnu!2`E*>U zOR(F$x^49{f5Q3|2Q5`qb-i0qXZ*a_>szRvbT!K(xYlSHy0Bi0P{vSK$-?<1aTydT z?LuSS7kS}~a-HACwz8Bg{XNJk3fhtUt9_wG<>Q#uQ%pl!b6Un?=Hi#=}cZdG2&75rA!sY{10ZZ?W`^Fcy( zu+ws7i53>00?VBIg=X4vS%Js9oV1jF4bp<|nFyzP0IhV5A9IQb+bYo>MIpi;P1)XPic=I@Sh!p#%1KtbD1TEc znbV{PZO@yuc^`{@+agGIx&01|qD)zJOYRmo3+Q^wW8j%kX20oy$F-W}=X;_K&RV}< zt)^DTi4{UtlQ!6BqJDNaIrCGF$Ck**w5A=7=w+*WBwUGmF{o;)M&|8_y+fr1?DA$W zjmJSsNUO~>{vpXDJpj+c_^q@WDRFYg8(M2UpT6f|LVe9M+yaYNunP-Ib#WX17Mnv#8FwQFx{-RHRyrz%xE3l0dl zs6oq##CnbAgKXb~v!hsWzMdU^ZGR{oW*>=HoI|>~@#FWtTRyqwYdy-9={*{4?@k(G zeOC^9@N7Q2#Cx@-rs1eKk3quKy-3DKv{=V*P@!{cdat_BgdJ_XkMq8`vXR2Fm4w&H zEids)4=JC^j{T3e&k4GE#M8UXCT9iff;^Ghijur6NYy^~^G$C6}e_s4PcB3!%j71JjQL&E*y zOXB;wyr*Aum&(rGX)ZkqnlQ-TuCybxAS@`bqqj*=Kg`gvbzEKzd~M=Y<5ji9$1>iMHtvW(~U_QqHF1Nhe;hfsoIBqUyQBmLD!J9==!{KVWo0F5GIQQ zjjiQ0PN*yr<~Gu9hF5(OIrM6yWvy>$nB-ptHI%Lt6`PLpL>|0qwl^XjMYij{urc^l z{;;>%lI<}Z-}lYk^x6}4(M563#Y~RS8uODPf%n+O;L^@zeKX65^HE@s;=9gF@2nVs z0`be>{I@`;>j!)^U?_T~R^iwMBHYH=&B|u!@zZJ8UuN$sxf-hP*=mL{-i8UY<#ori zgA+|m`n4iU8a$kxXZr22fomR4gJb)j=jwvB3FjM=#u+z~`@!h5!Z>#Dvb@e|_+Soo zv~gneD-*8uL9k|(Ov?yfU334oiG$VS_e0sGV~1(la#C`4TBH7iU%+N~V2SJOxG|c{ z!|oVgQgyX_$p6jx#G}W5&Cb)Z9Atj#uQdE*`N@o_yts;knBj3@I@;@QMSQ5@7X7Wp zH+b}*;Pw6ph3?WrNwVV|fC?jH3=T($gi?@WuZ_IFk*ckRbB44`f8H*sswwtDyVI+f310|VO$4E1%P zCCOvF;v(Ru$jAVxIVK*q#F#K%oEr2BKNCynI9$gBRHkv(WFBq7gEdrO0x!@TDs#6` zhHl33KqmEZVbK=wUR#)N$q?o^={ip_PLcAPQ&OJc+*`y*%IPlb>khVf zZEP{aXD|h$_aDV4ml2}atD1q+<1(8$4m2PDCGmb^HyF@|S4>3nvl_BE9p!Bbo7Ky= z4~3~jKpm{_{*g}?jINrxaB(?GH%&cd zwopR#-8kpT~7u_l283q2ZapnA84eoq8$u3GpG+(B5#E7x@ z4+G|(EuKhVQ>~JE8#Zw3RorKG`Lq5F`f7E})UX)1c5K|M9sBBG!^I)K!%ajT2@Tin z;yNsEQQUA=7|vDdgF5Dl5sceH&*FGM5nYdH;@9wW(9Z4AdL;6dz?ZRBz&%OJn$ue0 zK~ho9OE?*2<7bpu`#Z;$$PygqYbM_jJRu&KtZ%(ig1 zu8j4hjFuvpd_e(I5Pw*Fsv%VjHL#p7raqR0mq7wv=hhWnEixeV;q8yct5e`M6=gs6 z;4M=gLk@YuDqdDly^-pTvGQZf->-|M;F`i(v@qM7beY?)8Gm%o_evs2_X#qoDM*lq zY&k|Zom8=a`KzW&Jj{JK;+l z@@>&oklple(Mhsd92oYauOu$h&&nG$|76ep+PYQBWl z7&&gVY!hkulCz+0C2=NX5G`eR^p)FN6UslB{#7KYGt-TB{w(0t? z8q83v$o!099rK2G{w9R93QyN_8DHn;|VYHYG%;!^%V(LfNVtjQ@rs|RKr`54i>-Tq!T&S^TY%5+_fcr^28~~GSB`)QsC!-k zqrNPZ0}7YT;yI;b@&C+nT3E*cg?aM_&yM3Vi06t9fzg#F6MeD|qgU9O0x1n|=$@Dj zCqaJt@#nu!;|WK;^|z`PJqFp)#IQr*bzQ?@!y3e)%0R;&);_IHN@v=LzfFT7c&rYJ z9A!@@)x^ywq%gaY9iT>122rXQeYJiCsR`Jp^TEf{T1?$xo$9-=_n z2Qz7YzgZ*STOU|`tX08Dq7p8G7aP>7m_vRYx_VfRKD%=4v(0PURB(aj@JMtWy49Qu zKs$GZO-bm}OmdO9H@b2@_6F)wh$j55Q(-6;J50(A3*Gr4zthqHGJ(-cTsq zVbH5pNw~}ZEtlluhWfFa@n%<1$mC8ufuMCKiO^nihbByS_N6^(U!bZAMzaX%=%=_P z4JLQsAQY*VBo5#R!t>XK-DyiC1Y^J?x_kK1~RQOREGeMUL zRMN&VmNyht>3|Qd>M%N{d#-97i$)iOpi)utY(=V37I1jA4JRkddk9*q_<=__bro+3 z|Fl~>112u1HOtZ%W~#5VE=zKaMPVrKPl;rjquXQ0*rzCz#kluCAUp53%lKW*%3#ih z&fpWrx4wu7f<=WrO+QELfC)JIesUJ%jVg0W0*mJK(sb4QYPVJuT6_`uU#`n!e~taT zU9RO^(1rZ@ds~+e_)y{$6ebWCK=VYtLAz2@{=E1^znGGF4e-p(itCv%SlrTfUPMwB zz*Q|xh{GroRF!Mhz+(;&L3xpnf1E^#YzfJzPn*w4j8i-IQ^C1ujeZL)pBz1Crl@El zx>K}1Ji~`tuUmsk!_Z`lTr?Q*#v2b%wOmGbQA2lZz6$y0T}Q1-5(|}q%d&XvUBy-C z;gzMiuM#fO-}fXrt{E-67J>D4C|0abS0NmwEK8S+#7%Nq;06J`MWLDP&J7wOSBYz=Z<|Ei7aZ2b&uS9`g+1 zj!3pN=A~$WoATyeN6=p%Q6P{bh~>_7hUwCu)toZ@=}GFpdh&@~ZenOL6Q~vk?<7L( z$uSK%X+S;T1O3MQbjtZ*8h@zp3hdE zBPg$HjS|38vKLo5SCv6Fa;v#rk?LTEQAW#e{Me{vbor-32o9EHJl?4D(y}R+e_G!D zSIbq1A-V`dh%P9ApCWb)JOr+@_UefWv5lNT&Y2wWkVP@ejOLe#7%LBxV1kMSia4`T#&z?+^jaq1ZbL%aADdyVO5Job=ZaXY*u-7S|{R==Nnbg{^-0!t$+K zAFn%wX;sZ32Z*ol3DoHfAU~k!t9Elwt>!=NC-2luN1B302>F+p812dZWh15Grqn)f z5LN-T%+(KN=?anKb64E~!oNmoza9HIWux#}-ZV@a~-WmcGxU48HFXyi0mTU75>0MpjB$Ltt^Cbm|6f$;2e{Y7- zg{`72@Laz^^Iv8>9{xd17a1DPJhC_wR)zGipy=j7G`ETO5^*@{_M@%|0vLRMyVyFLZT^#ad-y2!+_A=NdO`}rWVF>hpU zrOMbiL--$y!Y>cRXpzr5bWEEREGl{!Mr#O0Y}1-j;N zP#*~4E?2G}$mnx!OU(5U*BjmjTu}(vZC^ULeOkY2Cl&P zqNhkqy|VKWr7@^3QzTs(TINo< z*z+onGLoMkR(`V~rl2k?dit=yS;+XD+OR?#3bIrs3GtcS$+6DdQ@e9MP{nyxR}-}M z=l^!uRR{B>7vX3DpI7O^Dfk@NA>Q(l+TeykU>qvaVN9SnI9lCTv>6c}L4U1@-i}!R zgpW}fB{sfQ(4wGmWeU);>n0he<;+W{pgB0l_*qOpr0wCxBDbL6b5}67L`qiMbcG%i zxQYZ`R=*?)+=Y_oNV{7-q0#;yTdg z)LAd`fgkTqZ@e#er{y2NsH+oJRaLP$Zhed@`x%4<0|d{{FHwgtw?@Uzce#1HSDP@F zUw;{zYNL3G~88MPB30 zgztEx(MQpzbRnloylxtHXre62_z8m%1fX2scs)V-%J%M<%s*fu@5-vAT=OjEJJ{vu zHH}3nBWy}_2ke6o0*b9r_w8W@PWnfw5E4RG>BcB4?IEooB5J>ZvrvIW!z z-Hu&u&ddgrxt{m+^|}4vF&QG&Zu8J!eFcb+kJgwe0T(xYPhQDga+xo7-H;}L8ZOUa zXjLBE^P)a4%Oj{0(@XX>_)1=>CCnhj7TO9V8=q%H_P{#e3e9cn(PkMPt~Pp)`FY&| zlM=)@#DRH?(}mLDn5eoDzgQ6F zZ-CnxTi!f8#4^a52PEdHsHnCw$k+`fYxi>0YnB@9o+#zZjy}dcrn?^~td$xZ(^Y8I zP=R?%lqyIV|ztsG7)=`x1TA^E23pexGCuHE{ZPSFN+$ z3f;miD=`EWl_{(e82t3!Q0sFVb8uAf?ldy3X1>>Lajazzlj7EGaA{hWde_zS5;8D48$a;J6S| zs4`BrgV6VgR#)R}a}lG(c5Q`~$NdI*j5R$7lh4J)<&DAJtA+W>vh3#@!Q!O%w*a_v z^WrrcAC5l&!;ObY;6Tq3Tz{K9$7kx8C{l|4_U*GWcuZAAiRfErr>LhpRNx{}mkC`D z0)Y%vc}`&~P0xnuLS{;1xaSbmmD;ZbE(IU~bIDaT zwb=bZS->E!YdjUvZ&i}gwxF9tk$dm8y4foJA& zopeIceg)Nn8~6+-u$^aQ>q5Qq-ppIOdd9{cPF3o52!!}mrTlf<+!nWZ`kq#9QNI#RYD-dq-a8w9k^XN>I-OL>%F~_Dcv~+`O)1u^Uo$z1igH}Nr#?b6A~h0$;-bY zAfR~t`sMk~yRHc$2bF{$n>_4-1#xtsfW0?pGB`<0pga|=T2=7Ho)gq7rSJ-zs}822 z@l>YoHRVPl5)<>K9^|ALfDrZW7u||vN7m&LH^1QU^NY%Lr)OlCp*fS;Bzh(|3R_E( z{%iumI3&2qts{9?9K;(YSh&E)7;K>Qx%v{goc0k6 zOLTd~9)K(s>asRS`7D;gm*rk}ByIkYtE&2;^bXtVtMx<;b^cId4j-^z=3*Yx8Il$W zW9kGFNtan`Md-yVUiD{Md$kGbPLisy9IKE`g+j8vN4!1e@!p`5O=+zP4aP;D>P^U) z%1}ssyRD~!zKRMDf9j|fq5s0ACZW5Nw{ry}py>NAfx|2kI4pN3lHw{{8;f2Zbz3VdpE%Ftcp5G`B$YFUoU7zW$tuGa+?~%U@ zz98c>SlrkzUZ^vd1KX4G9(opS)Ro29wmd%EmZbTiNQrQ^2YAza(DZ~@%uQ3 zD8FBRrd+C(liFNr?(ER~uACVP#o}Q_{*A8H2rZN=!}+Wd8HvkK$6fi?ahU1dInrb> zV-CbOD{}DY9+}P86*|pNkCPyLSno{;ixe5~+O}sZbHtB(Ro*P}d6}}#D&akjBIdE) zV5U8s<$cw%-B^2jb^GjflZ^A-=D3xcq&fK1^v@eM>Vg%0Q$Yf5%4nj$Ye|(kWnENY zd$ZN&-40z9HzS=%u;adFFZUL;l#A#u=6u>~CTuDED0 z=i^9_WwgWmPUD$u?q2)Rakg4BmYt!8t=13)0KM?0HWJXhevVih2C>K_OjoGcASzp2 z-4i7z{ykkT$|i`G87aw@PZ)WqSN(2xYKSa+<{7!jN%C;!I=j#2gH}TIa`^<0`u~&Tvn;C5qJANrG7Lo_L<%vejFi!#qvG4zvAUa^QgAcu%s?IXl zjHa|Etv?^rO;Y!}F3s9?!ABboR}=CiuCG_RfRq>tkc5`=;F-g5fZLsKx}&3?$fT4f zPi!XV+^%1&(E?W9t7qW}Zd8O1kgn1nc3N213I~wN*_+M4G%aWa;k!A5 zu^VM7=eQr*l}zIunD zSE#56#p^xd*Lsd)6T4P`$s9`LD5E@Gg&vrSu!i}t)V4V&ce%N3guJZnw4wNN9D)4y zbcoJ6mOQWCyz4>M7VlWdes_AKVtIe2Bb&z8t+HX)j``-h{tr>`$sQwWg%Y%za)llz zO!>;VUXpF@T+K3)^4SOFfOo68JlS6+c@ZcP7mAv?)VPpvW0Yu}8=FTLBFiXSyM-q3 z?huE=!bV!g!(>0KBM*_Oe?95>wt_v9*)MsKA<4SnzBZPdTUp7dEcm{jD+90=P3h0d zQIIz9TRGd9ch%lhS@Rq;9|{8Alc_32koK?MPM@qC*~mouk-|%&?vMrnkR-tfX)AbK`MOZ*=87p3za<}$Zi&N*h*o?Pz=K3#9E{}gwV)dwI z{4-yuJr7dQB&qbxMzs{R!|$8he{Qcni*{Ws&kcY7{MwElxpVh@=9gwu$52;P!M3&o z8c+awk@69ZCKcf$LjVIx`IZLIf4<759CD$QZuUWn|D0BTF zvLS5;5E#TR$$r95&{|HK(jdA+9j))!m+iOO8>b|~>p71NQC2u-L})>g_amV#U$_^2 z?{YK-bFVL<&LZ+s{()SVOWGVAo%W8;&TtTd&i(B}bquij8AXn*WQ9YJT}DgZSMV&; z@Z+~iM8qDqI-Y4zzG}&Od}OK>EvBUZ`yD7EO$EnG^b14r)Re#Y3>1_v@#lG^5d-&$ zO@(qqVXhSA(zMMx@Lft9AM9PTI+s1X(V-^luT%fv)15O}cqKuT2}Ww!Qc0KBHi*Uu z)2-g1R?r#Q_4S~$^7)^11e8RO`GDvbi)KTHaB;B zBFVxgOVoA`(}3I2jRzC69-UQH@qz1FL#^iP46crTt2a5)BOxJ$du1FHI0a&m1Of)| zW34hyRA?(te23PFlRABU;vaO^c_AYb8~T_dvFL`?JeHUx=vy0QULpSX)CBa zn6cS!M{@fLrt5K6{Ul^Cni4{M|KN{? z+m!_A_8zh&Eppo7pRnbydyl6wfCyx=uk3Mr{f+on9qHuvF6w*oFeuHRPNJ3l&P{J5 z(LyscT$FH=7}{@b&vSPderNE<=+xEyxGV|sfeTGcevM%^LK^xrt2a5+K0)n+A^qT< z?rsA>HysrVtK!bNM78V;{+5diucGyW81PgJ+aY)N*QcAGfm^RS>s0>LB6>Sj{$(0m zyE6=*ipK2X(|d|D!gfPBwu09`<NZ6 zN+)40f*mR?{bh5!x@zb#di@Yln|?H|LK~YrWesf6K&yuR@h+&Tq{FsdRu}`BiP>#H zTH4NRncgr}PE6OSoH($HI}{Z;;3;Lc%B$?Ay1)czy%cvOKA>QUqEeS18j#B$3W=or z5|ro9!}shpCJ_Dn%1VG6?CzjOadgz6sG85Otf=aQU^G)@u9#tA{lxcKKZ=73CL1Cb?sqB>mUq10im=}M+R*nA zQLnkMCYi0;|BX6DseKFwSSLPlFfqFLjxx{VR{6XtZ{!4-mlF`&Q_ORYx~bj_iykjpEUFR0v$+#{sRl?j+;Ki;eeh8II|fW z8!riY-Z&1Xyu&guFi^Rv%F~x~bgVHR0*;Y=90fX~#c_Y8N`iy9ikeICts&B%Zd3;s z|B$hy#AOrdNOh5&_kOzM+GuL;EVfZ#k38YYUQjC&Rwx1kl9;~hcxb>df_ zV^1_Pl^$RL*br&-{r^n5SqtE&L>hhTQTM-58An`+LVF|=ES>je!mpEiYB>0C7`s0c zQ2bO^;5~Vckb-!}z-g{-HHkel@lcEzNeLN5GO96PiQJGS|4M06zEVH&p@l^;uz3cZ zrUUtvw2!wG!^B%leBAGWz~*W}SM&%%gC8SC>)(m>vLW$Ug`hZRzooP1n>`XqOKHZVXmZolSxvolfh%Gggo<#f)&F*08#E}xaR`}0tQ zC6z33z!mmqJLmZeH~wbF9dl*Frcd!nxX{MN`nP61DObN&18Pv>hSI8WsEl(4RggOi9BU$dfFsVq}mmSa}7#>`@;iGk~9nKtxG%M-A^l2(scAX%m$jlc% zeE8a~KmI5P8|<^`SQg40djdZs=eMir7x2^HTjF~9H4tM&NK8ZICV37Wv)p&mLN&`- zmMNZ9GbBng>m{ot$`8Jy>%B_1B1_UWZLO>cM1u3Od zP*{Y3NQ08nCDIK_Ni9IS73uB{=|;M1A)QMa1ira+ySMxOz27O zU>oUu42FM z*aS*gPn%l}^EGJW4+|E)TweQn9L_jczj{$OEC1;o;8p$LY@>j!HFX(G)Hu@4X&tMS zYk&lsJ~ey^tYZ}#2!*W{jVM2>Vw&g;%4*FT^(TaK(soRP)E-Pek^jXx+&^lS6bM&s zVS^mQSx?|6DbTBTsYWzw=X*#$wv%1?4PZ^FD||H{${qdr&fu#_C#$`1N#k2V5cKPW zyludg7y-X?@)R z&foa-;Y_R%C#K-!&3J?3=D7C&s#uCTQnpr}F~!WPZQPrb;pq-Bk;-a7Ff7q-dRy8vI!IQ<*<#1l81L!w zSl^wqt)lMkthcx`#e!%pI^>uxQD`b!^x@Jdksvfx)k=5ZI!K0u^gEpTwb`_SNJ_Ec z1Qs2KMDUdeOvluBMreBu)v(NTggi`*JQ-3zjzv?Qs_Mbe?PXac@+`rrnzN8AAYh87$ICqZ7- z66~|~-}Y~#qMhB%F{Cr|LFE*P!mC1DVGq^964Zi22U_FH00Cf#yaxdT4yCN{J+JYf z5CJPb@&qhMd|g|`1LSKc(M0uz^yyV)$8-<+Khv@c#++scBk0i^6=ngFFQ=P&IzSfg z>E#k%1ZJLi{4(G309v|uPG)$Aq=(1c04nN9TXb|JHw!DvE!KOixfgtuOAF>Y4{N>?Fse z{Kk~&rwP9>!#=P)3JmwBIVY#54I*PQjZOBmUN>e1;97g?SfgG)x%+jV7`ScSTrb|K z0%9{wW6_;cv^J*uY;Ebe{OPMh4}$EMYkFbdhX|!H-SN5kEGQ$8!4rk(W4!_~_dcn$ z_1mVd1GM-$aGVh^G9g;0%R194N+(`HJF1R|~+H5R@+BC7gl(f*eu4EvIlLxn3d zbM|Y;NbEYhT|F=tHpQHLix@i;uw5R0BZ~Fv0lR11aE)-3liek~8o>O2HGD%s{zX0G zR9c>!QmNm^#d-m5?C;+Xl>PK9d?irQ4VNdJ7sPjbMIT(YzEoO;VmCmP0@%gQEiU$jFd;e-VMFGXV?wj+R{1=T4@~GmV=acZC53O12cZ^#j1`=_nKMh5rIs0WVd|aDMt-}a{BTZI*4Z9WH6E~e zyN_;Zb)fd*7nQAzMiGCZHNdvxJ^GZlKsu~Uf?Vi@;p8{t|6SnP!s5E|kPBE^+q`r> zW|n(x>F$|fHUc-DC##19mNJv%shPO$;N^e99WCdsbE^ZnyB*{uicpQ@2L<*Y0>(k= z;0K#=+>>UD9dm=dsTo6gyr)OOviB(|XzsM}bWT=q8(iqkPipb#$AvJlD|a`uhjnovW)S%9mUd1w2q;z4R9rr=K*=jPV)z znzL*Q*RSNZuP)xtMZE@c3v>bd_k*5tN5Lc_pG)$?4Kno3PSg(Kz9hR-Hm_k8F0~v- z9B4@4N5Cp>obwpQOt2jMh#nZPzCW!A)O(J+JNINr2{x^#Ef#B|5Oy`9?n?y+G8ty9 z*1-nWrPpekgvs2x1ewT{m$$LE4Gn1q4^tv_KjKh;3w@PC*9i#bVaJH zN&c--=7(=Xp3uCcyS_e;?s=hc^>FIBO!Mv`nq!2?Tc$Km#`?qS$&}v}E{^|DQNZ$3 zsi{gc+YAnT;?C|fmCqI_D$UG({4fZdhs&vQ=$Lg|J{g|r7@OEI>nD_+&d+#PnL7e4KluSTsqzgeOA)QbW5SYmk@*jAo5J#v z`O+BY`em4Wwlm7ORXfE4(K7GBV{6>CqR!in!<|0orE}KyR%_m8NaCkg^*plGR%|ft z`PL;|z*nlX)5D3dpnkNK&8RQL!5YXG3DzqCnde<&I1{^0dRaeAktF#}soi;O1?yen zb_Xk?8m!o-89;^*IDi~j86A=J5GW7uP5nruZB&)O`%>s@gJ}qZ^y0$EERW9Jjlat$ z55$HE6$}XWZ^fLyxdH4@=wfF+2XYKxqsGoO@F%M{BXQig%8f3D4DO#lz>vgB-6OrT*x%wX5?JDA8jpK*o zF)>w;Gt0Z$cRW~TSf~Hmv$@g z?&UJ(RT|&>3oQyl2IFxMS>Wa?ZFF~+t`0wh53{e1)pO@`?BgVB&mQ{OxN9f)jAR&Ujk@%YAFiJ;>jg8H5 z-Zze?n5mtPBy@Go-x@;Y&0p9DSzTi@(&K+Dgw^bDn$Ts0mQkmjKPM0bF(%-hn?L#X zvQc<0SMI!1pdFjI%QT%Eruc*HNsiOm@fDeOlBjzwu^Uxg{lwbQvyWaOdu-AG^Kinx zuVNXJaw5<$SNFx@P+6=9A6+XaAIKs`k{4Ym+oE)qzgbNjEpPI|5Bonr@RwX-uds_B zhQJ!~7y$NSrtC&b@Qe~!E%0CHeNqx*X(qHOxQqP@$G+63r&S#sf=ri_1-o+)JO442 z2hfqREO=1SqUe6^E5UXCnk>=92ffi#L%VIVYAmI(uao>_#(I1Lf;jfvSvG7%0S1r`=o#QN4Z!n=3 zH}h5PBFB1bzp$jR1Z7#5iY3pqZh1x?=*xOB^W0&`nJYv@~l}G)D(m=WN)EOPW z$|e^n#X``|zH3c89LFL$;SD}GCGseJvmD6$7))Y9LskD97(RT0He3=VtaU68Z5Nhb zjTu|JcI~1}hqm70-pI?L&E zeh#dc7E>Po!&{8c73-hQTQ36IXbpMtCnL=IgezQSrU-y%3%4B^{)gh<(W5B$Mv$4d zY1dUbuH{CrAw0|Ks`wD_%>n1fxYG4t`bpa=O&g4pb3IK)OmYYRfuA3W?CbQf<+K~$ zjz%u16(Q5lLjc$ zf#4c{o2xZLHE2q!zfaVUm+|%^2Vq4VmT0DBdBzzb_EVcLi9oriQmTX-2Qmh6iZ%=? zeDA8a{e{<#bt`4OO$W-j87WWMtB!E<&w>SmAaEjeM_g!}uPQ%MR%L1{xiv z^qF-}a_+Bm*U;l`3+(%phS&2VRshGMRZ+6{n@+^WA%#{ys_xEKfbzeAblniA&)a!N zMwHT#e*U9F)`r}@A`wk)?w7SE9!kQKOEbbnM)|;b}wn#@6~>PX6stxlUjF|6(|H|06fP)Rb_n<`hiAi<9va!>5*GXf9CFkir=dO$a+?j4t8*(J zevbU&LJwRGaS^zACIUBqStnwpA-)^cU8L%+nx!Zt@U|qIwJ6j?>%FB^Ud7al$Z)Rs zs8?{4q;U-)%?{~JN03`B^hcBva0Kl?`cX2%BubU&i+E(1sL1saw06{fi{{oTI(9Re9>mv??K|!~_N-ei*K`d|5>81K@+x4q!8+zWEOn z{qf*GC^|D0O@il66KN!GGAh*Tx{5BjkaP7xjKR86Oz=*4XXF;6uDsBS(Ol~w`*S?O zqTCCLy$^xZf25}=&)ens0LS;7l-;0Pv|fu|0MU_HM&l=hy^kZFU4j# z-AkP8Za}PjF{>h**3$3M7m7^JPEYrg22xP2uF~*zQqka1ED+z>c}`YsJB@jJ*%;Pd zPFoeFhQXDfo$ehm^dRrjLcwNeV!~|orR8o{eM(VT$WG_#Jq)Y^3FRKC5sd7L$20Yd z*}4anw%@}XR##i(Br#P&N=)nzs#1LftT`8W zY=*cJ+)Q^45Q7 zzbvuWIdNk)#GQ$yDq{h!$g~~93GGQ!nyT8`h6v`ZfgDnJhr98*Ab+#FK#JFhlWjxWOxh#Fa-%V%;-P#{-LB#I7QV*dec3=tf_JOs zw)f1ByKdiS7x#lCTfb_sG|=HMwBa{$_Y}x_| z?+Ck;rCa7c8DyPf>4Im3dxi7e$c8f%yL!Ap0Y)2t0iO2sku<6#x<()m?mxH+x!6j&pR6-H76ba(bUM*qWoN+awKyFvXd?oKi%S zy|~-LwA^!LkSD^lpr8q*PI3CvCI%D(wXHj_)uqynY7YwY>(^i7Q6wzfTQgz~E!CS| zoc5JSXJ@Axc76Bu>2UD9y4cZR7W$h{HuT4UC48Nj(=GF+PC7m#-dWwO&h)wu7J4&G z(O2H!L!4JRsLnn+$ndpeGl=1)_{PEdj8H2$mQ#>Z5n_VWW4??ZE^Mo?s4a7e^yO<2 z_%12-#nSQH$;74c_W5$xhCB6D;TqDRya^fUM%H6eb*5vYE7#j$gRHat?;Lnh;5|x` zph$YLYezf%Pkb9^aVbnD>DqXyZMXyL>d_o+jGM5qa67x~TK)6v3bQsg?OwCC4@2!A z2ix*sh#4MQ$yQAsGpRFe6E^AqB7D}F-gmE195LwbPxFuUVAC#o*T`-96LOp560Pj6 zF5!LK#h#kl*ldZDHtvf8Y(`L6iMBEo18{I^_SZEu8g=@QhS%*#3=NlaqoMC#Zrs=xw}B}hN^q>hL?Zlx{i%i zRqXby1w5q4q|cjVgPtXQ1hQ~dz!thD>Iqfqz@gq3=t!^#4a;8qS+c5uK)`+zn@VT+ zkZ6Wu?$zC$A4Z@cQ40TYCu%Gbz%Q`w>Y8!}?e9OM{Ypi12q;To*mqbu?N#HRN2a__ z%=H&*%LG}u1h@7+;!^n@8O^{-)=kw<+Or&Xn`1Ze@bFYmW38X#cmq23;%bU#d%0*S zr*0=xDDQGryIwSic<;zq1t9QZfGjH7Yup`I61_vg=`p7Hd_EM7m}A;fI{ajNlT4#SfFMf8@N==4 zvd!UaonktkMpN_fsM_rN-z*7v^p95Lb={<&Jlqi!xv2}9cmz5Q<|*uh*FWM6<={ky z*VFRUVR02?8uWO3dAtF{r9)1#-7+{jMJmLzsi^K}BAR`He=9*!Y8GVsPyw6LPfJ33 zZ7#DW#q`CG4$?!H7~l}PcSHkB6FkN18X`l0^n{S>3rvxSaWXNAoXf>`XY-iRpnEfj z|@)V2w?|J1nu(7Z>9X9Z9xbEP!&WsOk8N6EBXCKI_TTMG&(OuL1h?H3_ zd}%+Q$U6@iZa+M<47jp%l?`5Kgk9AlpydpAk*smbvSVDF37;|j8coI(B$b9;u!V2 zLPS4J4nuU?zs2arI@2jK%oxN{+`h6Hcig3|dA!LC*vRH1CxF$Ka;j32bU^-cB;_@U zk*wwVF)TedO5yt%C>N<)ffpzox8QTeTz3+Ug$Xk zho~r(>(Q2&q~!IpqwQQ`M>|EMBEWtERZrht8Ut0zm@&&O3IU(OhBFz@l*UF;9}5GZ zJ_!#COZ9Z<45Jw>fx?1UL&$hJ47+dNpb{ZJp0R~KPWqPB4)TbBphyK!LI|Z4N&Gr+ z3r|pFaG_i;rlwr>IO zgnqEV4bsLRCV-_BGI)7T6*mTcEjNru_yf^y$43+ozA zE2y}AAukR{^Q01SQ%^yr6N9{c4Mt`r48i^j>&#cBHhF7Od*Q$l>MWsdtE0hgl^dz6*M%b|%N}x^qc&rO8H8GyW3MrXx z0rdSsJY~dTN%D}xco02G%NUK*!p!1G9vh^uB5c=eg)dOvIua3n+aSxgQIm^|iAk%< z!U##IXgbi?S7D?yC8zt*ilTrE)wf{`=>J0*@pzSv*N7JQW;`fM(*OY11vs%5Dl8`b zcEf|Lgp@+4TDfAbTTb1X6uzDq()TIx(y;% zFMn)ODJb)!-xq-aUT$PHKLIp)l%_}>0d_K1> z$U;FC{j_!at##8f^!)b_nti7J+oT|CqC8}1HJzjGHdHMwvd=V+x*W|4;Cz!fy!kJ` zOb96hhlumIHT2kQSfoT=&OZq9aUtlnNVouQ%0*gXTj2;tISB6KAU1F#X zI5e1SqGoesu~ktxQp5epW4N(ZLe*F+ZFNY$n0BqhP1r-|{_4PZir#0LY~_;-pur<* zqgB%yeTJLm#su)>oku(=zijSjynkgTaESk}<|Rx^-=|antKMp`Jym|VYxvpx^!svD zl%nr3H@F~)I5{~xdwPb0AUUlvglZuwTIoC|!q8|V;;R`F1fKEk!SP=c8%U4a=mrt5 z&9I-}vbDAqeN3C4?5w<%I{THwc3RbQ#b8|fIH(s)uooCQ;eb+XQ{o>v! zMScF=~;%vP(R=_@xEMjmhjQAhN3&^RX&4F`bfU^t) zs6TxccT`DsxqHrslRI;O(V;@R$0vI0i`XT``!%G-rq}1BtC=q(Q<+2wcnc`LVNb)yth@eE|GpPlX^*+SH+ArIj|st>-K%Adf8ce5dvn@GPhNK7JWgG@KN6 zJz6l6B)Wcs!tjkxqO)@0{_h+RFl%0zd|{881CtDa31Ym;$%Xpo~+n|=uj^1 z&#JG5>_L!n{;ya-x~7Tz-uf@E>zJCubhH5bG39#zAy~T%E>Y5ziFSh^+v4Q1vzpi6 zakVs5-ma1!zV<|^iiH>-2pq8&Ww+wn(w=zz;6qquFH95vrnS#WmgXnUyRLeVVsy8I z10njsP4TRa-)8$+gS7b@R!JDX34yFhQio=jFvx?IIQCAr|ISJOH1F3@2-J2wXzmI* ztuNJ2k4AiSwt9~I9~540D zzR*{Z?C-a5*;jy+zOf>_|AOO_>!*k3%MF)zn_%I_*AOJgIcFeY`ITG$IS!-$64l1p z^o-Rt@by=;RAL9o=xB>%9ABRlfcdfF15=9^t~G;b!pi8caQi1cbpaKHHfG0!U~TD8 z;=^?s`!hQ$O4#=HvX6E(HUyXH9_!=o!qqoy+FcE*%9`_Tp&*Ol3eF-?7W9EW7Qkzid--ypUt+2}aoQF7;``wN zpiJNYcr24Zx{zQ9D)B1vl;xPkwx#9FsI(#G{bw%zXYj>F9adzqs?N?H?1R3+lTW2O zk|(Af+n54{gf+68nCBMWGG<6xj{ZN2S*xfv5m}PZ4`aKCny0rAMLKsU-XKmX62WU4 zZ#-F#yxsJDm*yUVL2y%i0)UicFG)hTqH5JHkC0UkuKkCkKH@Q+)K=mKzI=c;0M_$=QTA<8tFO3DxuY>i| zNR`R_n;4ysGjG{$zo;(I{q`;1Xf=HhB*YmM32rCvZu#p>|Fmq+F=Gj!#12&cY95rD zlDvvJrxr0$sQr{R0YhGoxI#=jV1qJ7X4N5WX_`W94iA2s!(X1(GPtO6X1rD7f#WXo zjJXbc1uLnY;a8OR>nkCDGLWmLe>0FjtPsKfC|MVD9AD%87jR9cydAyYnDTh$1dq?= zjIX^zE@A{adp+LiYlKr`vB^!I`_A;_kD}AgD?Zk%BJm)tA?b1>y-^lx+lQs}p>m)< zLPB!67|=wjwOs2MtsGJ}LJqJ+wI+fVI4~Xq#`@20Ax;i24FGi1)z!Twts6oE1P+;f zUgM<(rRN5;}c<=tCBqU3?bq_0*b3@EnVxAUJBTAGe3CAS^o5W2La@k-ccDU zxyT82caMw?>YlaQ1UmJNrW!0oDe>2mz7%x$ZK8teGEB`Y=6SGPrL5w0)$+}hvxl+VJ?xu(Sh?BPu9E+&Q`8bu599sCQ$zB6MW?Td{|0M zkk^7HQ)m5RHysgX4jmF4N&ea$tW;x(BhGGWCB`2X%wA}c51@b)fuGVvXc>mhwCPCD zw1?$+kk$DDYXEcJvq3zy9qG>X1tPEaNEIp*5Dm>1W1k9CZ_DD#k}`wik=NO?rbv3ty@gHjG?sMkMse84>MxNuY3z!mes zB$2RLQN*=w=21P1_qZ$!ydtwglm#?3-_jzy8#<@ z>Hz6tOFxGKRF10V`HVBp+bt0p{wzrhU9UZ2e_a^AHqE1#r~q&^?OE#uZzwhT=9GXC zYQKNzZ!UUS^!-H|A3_C7YD5~vOqt@=K!%0=J@@I*0;wa-F%SLdi#Liydm(|zZ5l#i zS%c744JmU={6Y})0{G6AT4^_m#n!iqW+|%d}8HbO{>0W5g|u+h2getcRVmDC`Gf!PG!@ z{D$+J6;mZnkp~HZR7QU;(rbRiBDn$rb!8f!G*#g_>+TN@0O}eZMzR>b(eik4N=a2f;s=1-IN%fAAdrzel(V1w~yxpXN1YxebDpya>U*X2_=)OVreKSoDKRYMFZ zv!!lg^3?dq(^JUKR+iv|~!vM?N2WS`4kUEE4DScCv&_=a6-NRB+fL2&Moc!a|hCkK3 zGfP{H7O%ltX$vz;8kYF$e*ugUopi{+$G@4I|6I__V_?ZVNTexK*01(V7#f+B*34x` zk&Wv*d+psa64Fg41Q$SDa$xLOC~%hw-D_@1TtAde=@Z*CWz47@0&A^$B_m>|{soH2 z4Cb=<9wDrYXRhKr!#gLdZ}}b4me7C2z<(V!3z}3(xJl2+(^+#f>^#~jReiFIxqYUI z_%ac~uBEdg9L^mfB`qz&MKg!^yE9Fazn226%cFB(+g06-KdTA@{#1mqhLB8i$G>OA zKO@4{{3kLq%1bF3OfE(u@-d|1* zXL0c;=6@9DqW)E!>(2`=5^=%NB|zPh-=-q8OTh^3QaaAN?FV8D4)T;k{V&9mk@A~> z5(*se4trIt?!UM`|NK7I>o!VsYg%N*sm38LaB*GS3{CF+2D<+oA;_ad)xLTd-Iiuy zVrUJVqOE}HYyUdK2-k2G`M5T$HLl2khw4G~9pj(- zks%ce1^mS~;T3PhLud(YbpAC^+wJ4B-@mq4E7&IA-Kc-|;nsia1DNiSKdHL$IqmK3 zDB8$)dpD|gucm9q7npJdLzk{*XRb+6)A;y^SE*!cvN7{`z0lnB4gKmJ%8^BJT@3H3 zxX<O(T=(K9D3ijAg`c ze*Un5`KvlWSv_bJzewPd99I?M%v-msXh$*{mKW=XCO>jIDAr&UI-Br$K>oX%j|x#j z{5oK>L&8~4TnOy$ahGuQtBJYiDi4@uuTFr+!H zAMrwbOmno8@DIk{mXgjBcMiuYYicB)6BS0OWypmoHr|<9v&?CaF=n@{GU|w4{ysFa zTED%Kycu0M$$YW2v}MV6=~zl;kxqsQ%}32{F~WcfB;J-0|2gsC!%eX%r6mn3lxlVB zgF*#cOy>^Xk?#3WUi$a$5zIcEFc&PK>0ntLB);0cuzBhOnNQM^^!sZLG1g>KXnZHm&r)U&((9OL;^*wC3JI%~|?k!i> z={|GjsJwm3S=MD4bkodK>5R2bd8Q~Z+pJDqeWVC0JKxW0s-a^pDn}_lFlVZS$J6X; zy8k8mtIjl0%dGwLecuQ6?Sc_k+x(f0ysOA}g?J!+caCu>LpT+b-~aC39qmWA78Pl7 z^7H4vrC4G(8!i*xoK`({^T^WkeRlB@EhmI3W2z+v%a!?aHd0pem}@R?4?0VPp~Mu= zd4R$>YB4_$eWWpAdHQw!Y;OeLZlEjLq9&XwC#s~_NVhB-lZ zm1|sA2M=BH6-FK0=CwY8@UG+`zn6S8QxqG(rk77iIhz!lQxVOOo*`>AB@Sl*s0E)h zP>!6ye1>t-lLZ{{-I<4fTcXsLXhg3l&X2JTu8WeA&6bb0q&X}E9eI4(XoAm*9$I&# zjO>+JmKQrxQrxN^d}}&Y^5oQHddDwiW6usHXR|wt2y0Z(e}h7%V>dU)JW*cXe!LK? zHD%|tq-$5G1{-Q-KMZG-Q+Be*b)+neR_$ysFdq0kKqj2`l1fCtoDjL$AeUnZ=S7Zr%!&&7MEy+uqsxv{9oz2>B!bym5w$W_4Nl-!(l79ypPnOq~-HgZ@t+U}t> zbm&M~KCI1sqr-!uao^4*XG~j3UhA;zdlto7nwe>jWiFapHy!UTOlN5B4*!M60QUT* zg4bSFBmc*{zYSdzBU;1*97fTZ#?^SZ!i^g?6uPqW&Ii&Q?{IR8EpyQok{Vr){D&fg zPnSw=3J5i_CG4$@4-YKh{W9lB-bVydnx16}Qekeqt}^0`%?9Vym5vG_z8!M4^2%yz zqlW|X6yW*xgE~EE7*JN;&uG6NjfBjOMr1@$&vm+TLjt_ zt%fdyRf>^}SGgeswg>z2^wH7t(e?h9T6>ELY3S?a4jX1Ky!JW?-u^ZL)L*SouuDVP zNa0fRgpa8LZ`y5*sJg54`kFr2D~{V%#il3^dGuv`x{Wl2IiqM!p5mLkWBSUg%k+`n zNE@=L3}a18bFeB}*ux@!uZq`)N3fciDPC=Ik~?>F9nNakn`PE#?kU%_-3SlcV;Z@^ zpqtJ7Auz(N+CEeARTF;Z25Y%}iQzzYeDAm7<4gIVFYW6C%lMQR&PODIzgzu^jM7CG z`uWDrv_Ts?djdfBl@%iz=k1r28(v z=K#C<{+ZOAJ=aMc0p(2*??~wHNxP#+&AHz>P~(G|9M5U`#F%zWp>Gb`;%Y0!(MoOX z)_m1Mw(Z<}Ta?RfYM~7q)hx{4m)YJmZ&3>&5n6_v{TkwS5%NX!7VyS0kLdH1z#%e6 z{NdHmsl^y15gwD~G^iX?i`ef=D44FuX}GI$=~L}}XNE;FRq7Bf8|@L7h1TP!@owgr z{P>G+=-My(>96C0yHq!V3GeR*8hW=ST*4iW(VK~%l3rmz^3FP+>|Sh4e^02)nb#3E zepLg#@m?rM93w=OIs~#J?RWygm8xWlIa+lgt*z&v9rIw>l<0R~$mp ztsL5a6!Z64_)Xg}KXMvbZ+%Aed!-hvQEbO4D9I^r?~QxZ*GfP=-E=FPnvgtcIkue4 zH#g{yb%M>H4>8KA<}6JMTHL6DniZ=wHg!^^7xHR8b=f;KZ5Dt@kpBSy}b zf`@DEn_)Ha)c*Pf^I4HS^t{$7y^XgmcoK;66ew#I3(KFY{g2b)&4VkY?MX*Z{b(gn z+T{ouRCZ&Hf`o(=|JBBA()(uS=C5&CK3F#GRCLvrA3j%cS7Xj))z8i^eOdKf`||N% z2yQ~3s-}*0Uw^Eq)l1h=aZw7!M^0OOt}c>)&(@x}ZvWIf8{`VF_sB*hly~lMC|gua z2;_1PnU(uG*$Bpzz4e;3C_#6Z0JgF6GS! lijjX`%s;&_yU$Hm$oImi4*R}p Date: Wed, 3 Nov 2021 12:14:24 +0100 Subject: [PATCH 26/35] Use image from local folder --- text/0018-transaction-payload/0018-transaction-payload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0018-transaction-payload/0018-transaction-payload.md b/text/0018-transaction-payload/0018-transaction-payload.md index c6f4bc902..33e8e55af 100644 --- a/text/0018-transaction-payload/0018-transaction-payload.md +++ b/text/0018-transaction-payload/0018-transaction-payload.md @@ -39,7 +39,7 @@ Within a transaction using UTXOs, inputs and outputs make up the to-be-signed da The following image depicts the flow of funds using UTXO: -![UTXO flow](https://i.imgur.com/h3uxf6N.png) +![UTXO flow](img/utxo.png) The way UTXOs are referenced is further described in the Structure section of this RFC. From 9ec69b5b6d720374dd54e6c2ac72f3ecb83f8c22 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Wed, 3 Nov 2021 12:14:54 +0100 Subject: [PATCH 27/35] Remove unresolved questions --- .../0018-transaction-payload.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/text/0018-transaction-payload/0018-transaction-payload.md b/text/0018-transaction-payload/0018-transaction-payload.md index 33e8e55af..d342b5e64 100644 --- a/text/0018-transaction-payload/0018-transaction-payload.md +++ b/text/0018-transaction-payload/0018-transaction-payload.md @@ -571,13 +571,3 @@ Introducing this new transaction structure allows for further extensions in the Other transaction structures have been considered but they would have misused existing transaction fields to accommodate for new features, instead of putting them into a proper descriptive structure. Additionally, those ideas would not have been safe against replay attacks, which deems reusing the old transaction structure, for example for Ed25519 addresses/signatures, as infeasible. Not switching to the new transaction structure described in this RFC leads to people being open to loss of funds because of WOTS address re-use and not being able to properly extend the protocol further down the line. - -# Unresolved questions - -- What parts of the design do you expect to resolve through the RFC process - before this gets merged? -- What parts of the design do you expect to resolve through the implementation - of this feature before stabilization? -- What related issues do you consider out of scope for this RFC that could be - addressed in the future independently of the solution that comes out of this - RFC? From 10ba8b33c5277608734fb55febe2bf88526dd601 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Wed, 3 Nov 2021 12:19:26 +0100 Subject: [PATCH 28/35] Always use the mdbook links --- text/0018-transaction-payload/0018-transaction-payload.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0018-transaction-payload/0018-transaction-payload.md b/text/0018-transaction-payload/0018-transaction-payload.md index d342b5e64..3d2c7df0d 100644 --- a/text/0018-transaction-payload/0018-transaction-payload.md +++ b/text/0018-transaction-payload/0018-transaction-payload.md @@ -56,7 +56,7 @@ All values are serialized in little-endian encoding. The serialized form of the A `Blake2b-256` hash of the entire serialized data makes up Transaction Payload's ID. Following table structure describes the entirety of a Transaction Payload's serialized form: -* [Data Type Notation](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md#data-types) +* Data Type Notation, see [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html#data-types) *

Subschema Notation @@ -519,7 +519,7 @@ The following criteria defines whether the transaction passes the syntactical va ### Semantic Validation -Semantic validation starts when a message that is part of a confirmation cone of a milestone is processed in the [White-Flag ordering](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0005-white-flag/0005-white-flag.md#deterministically-ordering-the-tangle). Semantics are only validated during White-Flag confirmations to enforce an ordering that can be understood by all the nodes (i.e. milestone cones), no matter the order the transactions are received. Otherwise, if semantic validation would occur as soon as a transaction would be received, it could potentially lead to nodes having different views of the UTXOs available to spend. +Semantic validation starts when a message that is part of a confirmation cone of a milestone is processed in the [White-Flag ordering](https://iotaledger.github.io/protocol-rfcs/0005-white-flag/0005-white-flag.html#deterministically-ordering-the-tangle). Semantics are only validated during White-Flag confirmations to enforce an ordering that can be understood by all the nodes (i.e. milestone cones), no matter the order the transactions are received. Otherwise, if semantic validation would occur as soon as a transaction would be received, it could potentially lead to nodes having different views of the UTXOs available to spend. Processing transactions in the White-Flag ordering enables users to spend UTXOs which are in the same milestone confirmation cone, if their transaction comes after the funding transaction in the mentioned White-Flag ordering. It is recommended that users spending unconfirmed UTXOs attach their message directly onto the message containing the source transaction. From 55fb8bef574d05c49eddaabf5a071a0294859ac6 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Wed, 3 Nov 2021 12:23:53 +0100 Subject: [PATCH 29/35] Remove duplicate payload section --- text/0018-transaction-payload/0018-transaction-payload.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/text/0018-transaction-payload/0018-transaction-payload.md b/text/0018-transaction-payload/0018-transaction-payload.md index 3d2c7df0d..c295c29d7 100644 --- a/text/0018-transaction-payload/0018-transaction-payload.md +++ b/text/0018-transaction-payload/0018-transaction-payload.md @@ -534,14 +534,6 @@ If a transaction passes the semantic validation, its referenced UTXOs must be ma Transactions which do not pass semantic validation are ignored. Their UTXOs are not marked as spent and neither are their outputs booked into the ledger. -### Payloads - -The _Transaction Payload_ itself can contain another payload as described in general in [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html). The following table lists all the payloads types that can be nested inside a _Transaction Payload_ as well as links to the corresponding specification: - -| Payload Name | Type Value | RFC | -| ------------ | ---------- | ---------------------------------------------------------------------------------------------------------------------- | -| Indexation | 2 | [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html#indexation-payload) | - ## Miscellaneous ### Absent transaction timestamp From 50ff0f76f00f1b72543ec2ac31464138db3fd735 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Wed, 3 Nov 2021 13:28:33 +0100 Subject: [PATCH 30/35] update links in other RFCs --- text/0017-tangle-message/0017-tangle-message.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/text/0017-tangle-message/0017-tangle-message.md b/text/0017-tangle-message/0017-tangle-message.md index 6a048792f..44dfd8b74 100644 --- a/text/0017-tangle-message/0017-tangle-message.md +++ b/text/0017-tangle-message/0017-tangle-message.md @@ -141,11 +141,11 @@ The following criteria defines whether the message passes the syntactical valida While messages without a payload, i.e. `Payload Length` set to zero, are valid, such messages do not contain any information. As such, messages usually contain a payload. The detailed specification of each payload type is out of scope of this RFC. The following table lists all currently specified payloads that can be part of a message and links to their specification. The _indexation payload_ will be specified here as an example: -| Payload Name | Type Value | RFC | -| ------------ | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Transaction | 0 | [RFC-0018 (draft)](https://github.com/luca-moser/protocol-rfcs/blob/signed-tx-payload/text/0000-signed-transaction-payload/0000-signed-transaction-payload.md) | -| Milestone | 1 | [RFC-0019](https://iotaledger.github.io/protocol-rfcs/0019-milestone-payload/0019-milestone-payload.html) | -| Indexation | 2 | [RFC-0017](#indexation-payload) | +| Payload Name | Type Value | RFC | +| ------------ | ---------- | ------------------------------------------------------------------------------------------------------------- | +| Transaction | 0 | [RFC-0018](https://iotaledger.github.io/protocol-rfcs/0018-transaction-payload/0018-transaction-payload.html) | +| Milestone | 1 | [RFC-0019](https://iotaledger.github.io/protocol-rfcs/0019-milestone-payload/0019-milestone-payload.html) | +| Indexation | 2 | [RFC-0017](#indexation-payload) | ### Indexation payload From 39eaf11da1215b409c4136fbfcb8307779cc208c Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Wed, 3 Nov 2021 13:33:27 +0100 Subject: [PATCH 31/35] Beautify markdown table --- .../0018-transaction-payload.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/text/0018-transaction-payload/0018-transaction-payload.md b/text/0018-transaction-payload/0018-transaction-payload.md index c295c29d7..dd766d144 100644 --- a/text/0018-transaction-payload/0018-transaction-payload.md +++ b/text/0018-transaction-payload/0018-transaction-payload.md @@ -468,11 +468,11 @@ A Reference Unlock Block defines an Unlock Block which references Example: Consider an Transaction Essence containing UTXO Inputs A, B and C, where A and C are both spending the UTXOs originating from the same Ed25519 address. The Unlock Block part must thereby have following structure: -| Index | Must Contain | -| ----- | ---------------------------------------------------------------------------------------------------------------- | -| 0 | A Signature Unlock Block holding the corresponding Ed25519 signature to unlock A and C. | -| 1 | A Signature Unlock Block which unlocks B. | -| 2 | A Reference Unlock Block which references index 0, since C also gets unlocked by the same signature as A. | +| Index | Must Contain | +| ----- | ----------------------------------------------------------------------------------------------------------- | +| 0 | A _Signature Unlock Block_ holding the corresponding Ed25519 signature to unlock A and C. | +| 1 | A _Signature Unlock Block_ which unlocks B. | +| 2 | A _Reference Unlock Block_ which references index 0, since C also gets unlocked by the same signature as A. | ## Validation From 4198e02bec3e2484117a530c8dcb7199a9d1bb66 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Wed, 3 Nov 2021 13:37:32 +0100 Subject: [PATCH 32/35] Reference BLAKE RFC --- text/0018-transaction-payload/0018-transaction-payload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0018-transaction-payload/0018-transaction-payload.md b/text/0018-transaction-payload/0018-transaction-payload.md index dd766d144..19a40ccee 100644 --- a/text/0018-transaction-payload/0018-transaction-payload.md +++ b/text/0018-transaction-payload/0018-transaction-payload.md @@ -53,7 +53,7 @@ A Transaction Payload payload is made up of two parts: All values are serialized in little-endian encoding. The serialized form of the transaction is deterministic, meaning the same logical transaction always results in the same serialized byte sequence. -A `Blake2b-256` hash of the entire serialized data makes up Transaction Payload's ID. +The *Transaction Payload ID* is the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash of the entire serialized payload data. Following table structure describes the entirety of a Transaction Payload's serialized form: * Data Type Notation, see [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html#data-types) From f86d8dbc33bfa2734297dcce577c8424982e53c1 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Thu, 4 Nov 2021 12:35:22 +0100 Subject: [PATCH 33/35] Several minor cleanups --- .../0018-transaction-payload.md | 784 +++++++++--------- 1 file changed, 381 insertions(+), 403 deletions(-) diff --git a/text/0018-transaction-payload/0018-transaction-payload.md b/text/0018-transaction-payload/0018-transaction-payload.md index 19a40ccee..ca238bf5d 100644 --- a/text/0018-transaction-payload/0018-transaction-payload.md +++ b/text/0018-transaction-payload/0018-transaction-payload.md @@ -1,16 +1,16 @@ -+ Feature name: transaction_payload ++ Feature name: `transaction-payload` + Start date: 2020-07-10 + RFC PR: [iotaledger/protocol-rfcs#18](https://github.com/iotaledger/protocol-rfcs/pull/18) # Summary -This RFC defines a new transaction structure for Chrysalis Phase 2, which replaces the current notion of bundles. Specifically, this RFC proposes a transaction payload for the messages described in the IOTA protocol [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html). +In the current IOTA protocol, transactions are grouped into so-called bundles to assure that they can only be confirmed as one unit. This RFC proposes a new UTXO-based transaction structure containing all the inputs and outputs of a transfer. Specifically, this RFC defines a transaction payload for the _messages_ described in the IOTA protocol [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html). # Motivation -The current IOTA protocol uses **transactions** (which are vertices in the Tangle), where each transaction defines either an input or output. A grouping of those input/output transaction vertices make up a **bundle** which transfers the given values as an atomic unit (the entire bundle is applied or none of it). The input transactions define the funds to consume and create the deposits onto the output transactions target addresses. Additionally, to accommodate the larger WOTS signatures, additional transaction vertices might be part of the bundle to carry parts of the signature which do not fit into one transaction vertex. +Currently, the vertices of the Tangle are represented by transactions, where each transaction defines either an input or output. A grouping of those input/output transaction vertices makes up a bundle which transfers the given values as an atomic unit (the entire bundle is applied or none of it). An applied bundle consumes the input transactions' funds and creates the corresponding deposits into the output transactions' target addresses. Furthermore, additional meta transactions can be part of the bundle to carry parts of the signature which do not fit into a single input transaction. -The bundle concept has proven to be time consuming, with several issues as well: +The bundle concept has proven to be very challenging in practice because of the following issues: * Since the data making up the bundle is split across multiple vertices, it complicates the validation of the entire transfer. Instead of being able to immediately tell whether a bundle is valid or not, a node implementation must first collect all parts of the bundle before any actual validation can happen. This increases the complexity of the node implementation. * Reattaching the tail transaction of a bundle causes the entire transfer to be reapplied. * Due to the split across multiple transaction vertices and having to do PoW for each of them, a bundle might already be lazy in terms of where it attaches, reducing its chances to be confirmed. @@ -21,41 +21,39 @@ The new transaction structure should fulfil the following criteria: * Support for Ed25519 (and thus reusable addresses). * Support for adding new types of signature schemes, addresses, inputs, and outputs as part of protocol upgrades. * Self-contained, as in being able to validate the transaction immediately after receiving it. -* Enable unspent transaction outputs (UTXO) as inputs instead of an account based model (UTXO enables easier double-spend detection). +* Enable unspent transaction outputs (UTXO) as inputs instead of an account based model. # Detailed design ## UTXO -The *unspent transaction output* (UTXO) model defines a ledger state where balances are not directly associated to addresses but to the outputs of transactions. In this model, transactions specify the outputs of previous transactions as inputs, which are consumed to create new outputs. A transaction must consume the entirety of the specified inputs. +The *unspent transaction output* (UTXO) model defines a ledger state where balances are not directly associated to addresses but to the outputs of transactions. In this model, transactions reference outputs of previous transactions as inputs, which are consumed (removed) to create new outputs. A transaction must consume all the funds of the referenced inputs. -Using an UTXO based model provides several benefits: +Using a UTXO based model provides several benefits: * Parallel validation of transactions. * Easier double-spend detection, since conflicting transactions would reference the same UTXO. * Replay-protection which is important when having reusable addresses. Replaying the same transaction would manifest itself as already being applied or existent and thus not have any impact. -* Technically seen, balances may no longer be associated to addresses which raises the level of abstraction and thus enables other types of outputs. Consider, for example, a type of output which specifies the balance to be unlocked by a transaction which must fulfil a Proof-of-Work difficulty or supply some other unlock criteria, etc. +* Technically seen, balances are no longer associated to addresses which raises the level of abstraction and thus enables other types of outputs with particular unlock criteria. -Within a transaction using UTXOs, inputs and outputs make up the to-be-signed data of the transaction. The section unlocking the inputs is called *unlock block*. An unlock block may contain a signature proving ownership of a given input's address and/or other unlock criteria. +Within a transaction using UTXOs, inputs and outputs make up the to-be-signed data of the transaction. The section unlocking the inputs is called the *unlock block*. An unlock block may contain a signature proving ownership of a given input's address and/or other unlock criteria. The following image depicts the flow of funds using UTXO: ![UTXO flow](img/utxo.png) -The way UTXOs are referenced is further described in the Structure section of this RFC. - ## Structure -### Serialized Layout +### Serialized layout -A Transaction Payload payload is made up of two parts: -1. The The Transaction Essence part which contains the inputs, outputs and an optional embedded payload. -2. The Unlock Blocks which unlock the Transaction Essence's inputs. In case the unlock block contains a signature, it signs the entire Transaction Essence part. +A _Transaction Payload_ is made up of two parts: +1. The _Transaction Essence_ part which contains the inputs, outputs and an optional embedded payload. +2. The _Unlock Blocks_ which unlock the inputs of the _Transaction Essence_. When an unlock block contains a signature, it signs the entire _Transaction Essence_ part. All values are serialized in little-endian encoding. The serialized form of the transaction is deterministic, meaning the same logical transaction always results in the same serialized byte sequence. -The *Transaction Payload ID* is the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash of the entire serialized payload data. +The *Transaction ID* is the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash of the entire serialized payload data including signatures. -Following table structure describes the entirety of a Transaction Payload's serialized form: +The following table structure describes the entirety of a _Transaction Payload_ in its serialized form: * Data Type Notation, see [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html#data-types) *
Subschema Notation @@ -82,364 +80,358 @@ Following table structure describes the entirety of a Transaction Payload

- - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Payload Typeuint32 - Set to value 0 to denote a Transaction Payload. -
Essence oneOf -
- Transaction Essence +
NameTypeDescription
Payload Typeuint32 + Set to value 0 to denote a Transaction Payload. +
Essence oneOf +
+ Transaction Essence +
+ Describes the essence data making up a transaction by defining its inputs, outputs and an optional payload. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - + + + + + + + + + +
NameTypeDescription
Transaction Typeuint8 + Set to value 0 to denote a Transaction Essence. +
Inputs Countuint16The number of input entries.
Inputs anyOf +
+ UTXO Input +
+ Describes an input which references an unspent transaction output to consume. +
+ + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Input Typeuint8 + Set to value 0 to denote an UTXO Input. +
Transaction IDByteArray[32]The BLAKE2b-256 hash of the transaction payload containing the referenced output.
Transaction Output Indexuint16The output index of the referenced output.
+
+
Outputs Countuint16The number of output entries.
Outputs anyOf +
+ SigLockedSingleOutput
- Describes the essence data making up a transaction by defining its inputs and outputs and an optional payload. + Describes a deposit to a single address which is unlocked via a signature.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Transaction Typeuint8 - Set to value 0 to denote a Transaction Essence. -
Inputs Countuint16The amount of inputs proceeding.
Inputs anyOf -
- UTXO Input -
- Describes an input which references an unspent transaction output to consume. -
- - - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
Input Typeuint8 - Set to value 0 to denote an UTXO Input. -
Transaction IDArray<byte>[32]The BLAKE2b-256 hash of the transaction from which the UTXO comes from.
Transaction Output Indexuint16The index of the output on the referenced transaction to consume.
-
-
Outputs Countuint16The amount of outputs proceeding.
Outputs anyOf -
- SigLockedSingleOutput -
- Describes a deposit to a single address which is unlocked via a signature. -
- - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
Output Typeuint8 - Set to value 0 to denote a SigLockedSingleOutput. -
Address oneOf -
- Ed25519 Address - - - - - - - - - - - - - - - - -
NameTypeDescription
Address Typeuint8 - Set to value 0 to denote an Ed25519 Address. -
AddressArray<byte>[32]The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key.
-
-
Amountuint64The amount of tokens to deposit.
-
-
- SigLockedDustAllowanceOutput -
- Describes a deposit which as a special property also alters the dust allowance of the target address. -
- - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
Output Typeuint8 - Set to value 1 to denote a SigLockedDustAllowanceOutput. -
Address oneOf -
- Ed25519 Address - - - - - - - - - - - - - - - - -
NameTypeDescription
Address Typeuint8 - Set to value 0 to denote an Ed25519 Address. -
AddressArray<byte>[32]The raw bytes of the Ed25519 address which is a BLAKE2b-256 hash of the Ed25519 public key.
-
-
Amountuint64The amount of tokens to deposit.
-
-
Payload Lengthuint32The length in bytes of the optional payload.
Payload optOneOf -
- Generic Payload -
- An outline of a generic payload -
- - - - - - - - - - - - - - - - -
NameTypeDescription
Payload Typeuint32 - The type of the payload. It will instruct the node how to parse the fields that follow. -
Data FieldsANYA sequence of fields, where the structure depends on Payload Type.
-
-
NameTypeDescription
Output Typeuint8 + Set to value 0 to denote a SigLockedSingleOutput. +
Address oneOf +
+ Ed25519 Address + + + + + + + + + + + + + + + + +
NameTypeDescription
Address Typeuint8 + Set to value 0 to denote an Ed25519 Address. +
AddressByteArray[32]The raw bytes of the Ed25519 address which is the BLAKE2b-256 hash of the public key.
+
+
Amountuint64The amount of tokens to deposit.
-
-
Unlock Blocks Countuint16The count of unlock blocks proceeding. Must match count of inputs specified.
Unlock Blocks anyOf -
- Signature Unlock Block +
+
+ SigLockedDustAllowanceOutput
- Defines an unlock block containing signature(s) unlocking input(s). + Describes a deposit which as a special property also alters the dust allowance of the target address.
- - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Unlock Typeuint8 - Set to value 0 to denote a Signature Unlock Block. -
Signature oneOf -
- Ed25519 Signature - - - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
Signature Typeuint8 - Set to value 0 to denote an Ed25519 Signature. -
Public keyArray<byte>[32]The public key of the Ed25519 keypair which is used to verify the signature.
SignatureArray<byte>[64]The signature signing the Blake2b-256 hash of the serialized Transaction Essence.
-
-
NameTypeDescription
Output Typeuint8 + Set to value 1 to denote a SigLockedDustAllowanceOutput. +
Address oneOf +
+ Ed25519 Address + + + + + + + + + + + + + + + + +
NameTypeDescription
Address Typeuint8 + Set to value 0 to denote an Ed25519 Address. +
AddressByteArray[32]The raw bytes of the Ed25519 address which is the BLAKE2b-256 hash of the public key.
+
+
Amountuint64The amount of tokens to deposit.
-
-
- Reference Unlock Block +
+
Payload Lengthuint32The length in bytes of the optional payload.
Payload optOneOf +
+ Generic Payload
- References a previous unlock block in order to substitute the duplication of the same unlock block data for inputs which unlock through the same data. + An outline of a generic payload.
- - - - - - - - - - - - - - - + + + + + + + + + + + + + + + +
NameTypeDescription
Unlock Typeuint8 - Set to value 1 to denote a Reference Unlock Block. -
Referenceuint16Represents the index of a previous unlock block.
NameTypeDescription
Payload Typeuint32 + The type of the payload. It will instruct the node how to parse the fields that follow. +
Data FieldsANYA sequence of fields, where the structure depends on Payload Type.
+
+
+
+
Unlock Blocks Countuint16The number of unlock block entries. It must match the field Inputs Count.
Unlock Blocks anyOf +
+ Signature Unlock Block +
+ Defines an unlock block containing a signature. +
+ + + + + + + + + + + + + + - + + + +
NameTypeDescription
Unlock Typeuint8 + Set to value 0 to denote a Signature Unlock Block. +
Signature oneOf +
+ Ed25519 Signature + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Signature Typeuint8 + Set to value 0 to denote an Ed25519 Signature. +
Public keyByteArray[32]The Ed25519 public key of the signature.
SignatureByteArray[64]The Ed25519 signature signing the Blake2b-256 hash of the serialized Transaction Essence.
-
-
+
+
+ Reference Unlock Block +
+ References a previous unlock block, where the same unlock block can be used for multiple inputs. +
+ + + + + + + + + + + + + + + + +
NameTypeDescription
Unlock Typeuint8 + Set to value 1 to denote a Reference Unlock Block. +
Referenceuint16Represents the index of a previous unlock block.
+
+
-### Transaction Parts - -In general, all parts of a Transaction Payload begin with a byte describing the type of the given part to keep the flexibility to introduce new types/versions of the given part in the future. +### Transaction parts -#### Transaction Essence Data +In general, all parts of a Transaction Payload begin with a byte describing the type of the given part. This improves the flexibility to introduce new types/versions of the given part in the future. -As described, the Transaction Essence of a Transaction Payload carries the inputs, outputs, and an optional payload. The Transaction Essence is an explicit type and therefore starts with its own Transaction Essence Type byte which is of value 0. +#### Transaction Essence data -A Transaction Essence must contain at least one input and output. +The Transaction Essence of a Transaction Payload carries the inputs, outputs, and an optional payload. The Transaction Essence is an explicit type and therefore starts with its own Transaction Essence Type byte which is of value 0. ##### Inputs -The Inputs part holds the inputs to consume, respectively, to fund the outputs of the Transaction Essence. There is only one type of input as of now, the UTXO Input. In the future, more types of inputs may be specified as part of protocol upgrades. +The Inputs part holds the inputs to consume in order to fund the outputs of the Transaction Payload. Currently, there is only one type of input, the UTXO Input. In the future, more types of inputs may be specified as part of protocol upgrades. -Each defined input must be accompanied by a corresponding Unlock Block at the same index in the Unlock Blocks part of the Transaction Payload. - -If multiple inputs can be unlocked through the same Unlock Block, then the given Unlock Block only needs to be specified at the index of the first input which gets unlocked by it. - -Subsequent inputs which are unlocked through the same data must have a Reference Unlock Block pointing to the index of a previous Unlock Block. -This ensures that no duplicate data needs to occur in the same transaction. +Each input must be accompanied by a corresponding Unlock Block at the same index in the Unlock Blocks part of the Transaction Payload. ###### UTXO Input -An UTXO Input is an input which references an output of a previous transaction by using the given transaction's BLAKE2b-256 hash + the index of the output on that transaction. An UTXO Input must be accompanied by an Unlock Block for the corresponding type of output the UTXO Input is referencing. +A UTXO Input is an input which references an unspent output of a previous transaction. This UTXO is uniquely defined by the _Transaction ID_ of that transaction together with corresponding output index. Each UTXO Input must be accompanied by an Unlock Block that is allowed to unlock the output the UTXO Input is referencing. -Example: If the output the input references outputs to an Ed25519 address, then the corresponding unlock block must be of type Signature Unlock Block holding an Ed25519 signature. +Example: +If the input references an output to an Ed25519 address, then the corresponding unlock block must be of type Signature Unlock Block holding an Ed25519 signature. ##### Outputs -The Outputs part holds the outputs to create with this Transaction Payload. +The Outputs part holds the outputs that are created by this Transaction Payload. The following output types are supported: ###### SigLockedSingleOutput -The SigLockedSingleOutput defines an output (with a certain amount) to a single target address which is unlocked via a signature proving ownership over the given address. This output can hold addresses of different types. +The SigLockedSingleOutput defines an output (with a certain amount) to a single target address which is unlocked via a signature proving ownership over the given address. This output supports addresses of different types. ###### SigLockedDustAllowanceOutput -The SigLockedDustAllowanceOutput works the same as a SigLockedSingleOutput but additionally controls the dust allowance on the target address. See [Dust Protection RFC-0032 (draft)](https://github.com/iotaledger/protocol-rfcs/pull/32) for further information. +The SigLockedDustAllowanceOutput works in the same way as a SigLockedSingleOutput but additionally controls the dust allowance on the target address. See [Dust Protection RFC-0032 (draft)](https://github.com/iotaledger/protocol-rfcs/pull/32) for further information. ##### Payload -The _Transaction Essence_ itself can contain another payload as described in general in [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html). This payload does not affect the semantic validity of the Transaction Essence. If the transaction is not syntactically valid, then the payload must also be discarded. +The _Transaction Essence_ itself can contain another payload as described in general in [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html). If the transaction is not [semantically valid](#semantic-validation), then the payload must also be discarded. -The following table lists all the payloads types that can be nested inside a _Transaction Essence_ as well as links to the corresponding specification: +The following table lists all the payload types that can be nested inside a _Transaction Essence_ as well as links to the corresponding specification: | Name | Type Value | RFC | | ---------- | ---------- | ---------------------------------------------------------------------------------------------------------------------- | @@ -447,119 +439,105 @@ The following table lists all the payloads types that can be nested inside a _Tr #### Unlock Blocks -The Unlock Blocks part holds the unlock blocks unlocking inputs within an Transaction Essence. - -There are different types of Unlock Blocks: - -| Name | Value | Description | -| ---------------------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------- | -| Signature Unlock Block | 0 | An unlock block holding one or more signatures unlocking one or more inputs. | -| Reference Unlock Block | 1 | An unlock block which must reference a previous unlock block which unlocks also the input at the same index as this Reference Unlock Block. | - +The Unlock Blocks part holds the unlock blocks unlocking inputs within a Transaction Essence. The following types of unlock blocks are supported: ##### Signature Unlock Block -A Signature Unlock Block defines an Unlock Block which holds one or more signatures signing the Blake2b-256 hash of the Transaction Essence (including the optional payload). +A Signature Unlock Block defines an Unlock Block which holds a signature signing the BLAKE2b-256 hash of the Transaction Essence (including the optional payload). ##### Reference Unlock block -A Reference Unlock Block defines an Unlock Block which references a previous Unlock Block (which must not be another Reference Unlock Block). It must be used if multiple inputs can be unlocked through the same origin Unlock Block. +A Reference Unlock Block defines an Unlock Block which references a previous Unlock Block (which must not be another Reference Unlock Block). It **must** be used if multiple inputs can be unlocked via the same Unlock Block. Example: -Consider an Transaction Essence containing UTXO Inputs A, B and C, where A and C are both spending the UTXOs originating from the same Ed25519 address. The Unlock Block part must thereby have following structure: +Consider a Transaction Essence containing the UTXO Inputs 0, 1 and 2, where 0 and 2 are both spending outputs belonging to the same Ed25519 address A and 1 is spending from a different address B. This results in the following structure of the Unlock Blocks part: -| Index | Must Contain | -| ----- | ----------------------------------------------------------------------------------------------------------- | -| 0 | A _Signature Unlock Block_ holding the corresponding Ed25519 signature to unlock A and C. | -| 1 | A _Signature Unlock Block_ which unlocks B. | -| 2 | A _Reference Unlock Block_ which references index 0, since C also gets unlocked by the same signature as A. | +| Index | Unlock Block | +| ----- | ---------------------------------------------------------------------------------------- | +| 0 | A _Signature Unlock Block_ holding the Ed25519 signature for address A. | +| 1 | A _Signature Unlock Block_ holding the Ed25519 signature for address B. | +| 2 | A _Reference Unlock Block_ which references 0, as both require the same signature for A. | ## Validation -A Transaction Payload payload has different validation stages, since some validation steps can only be executed at the point when certain information has (or has not) been received. We therefore distinguish between syntactical- and semantic validation. +A Transaction Payload has different validation stages, since some validation steps can only be executed when certain information has (or has not) been received. We therefore distinguish between syntactic and semantic validation: -### Syntactical Validation +### Syntactic validation -This validation can commence as soon as the transaction data has been received in its entirety. It validates the structure but not the signatures of the transaction. If the transaction does not pass this stage, it must not be broadcasted further and can be discarded right away. +Syntactic validation is checked as soon as the transaction data has been received in its entirety. It validates the structure but not the signatures of the transaction. If the transaction does not pass this stage, it must not be broadcasted further and can be discarded right away. -The following criteria defines whether the transaction passes the syntactical validation: +The following criteria defines whether a payload passes the syntactical validation: * Essence: - * `Transaction Type` value must be 0, denoting an `Transaction Essence`. + * `Transaction Type` value must denote a _Transaction Essence_. * Inputs: * `Inputs Count` must be 0 < x ≤ 127. - * At least one input must be specified. - * `Input Type` value must be 0, denoting an `UTXO Input`. - * `UTXO Input`: + * For each input the following must be true: + * `Input Type` must denote a _UTXO Input_. * `Transaction Output Index` must be 0 ≤ x < 127. - * Every combination of `Transaction ID` + `Transaction Output Index` must be unique in the inputs set. - * Inputs must be sorted in lexicographical order of their serialized form.1 + * `Inputs` must be sorted in lexicographical order of their serialized form.1 + * Each pair of `Transaction ID` and `Transaction Output Index` must be unique in the inputs set. * Outputs: * `Outputs Count` must be 0 < x ≤ 127. - * At least one output must be specified. - * `Output Type` must denote a `SigLockedSingleOutput` or `SigLockedDustAllowanceOutput`. - * `SigLockedSingleOutput`/`SigLockedDustAllowanceOutput`: - * `Address Type` must be 0, denoting an `Ed25519` address. - * The `Address` must be unique in the set of `SigLockedSingleOutputs`/`SigLockedDustAllowanceOutputs` (two separate sets). + * For each input the following must be true: + * `Output Type` must denote a _SigLockedSingleOutput_ or a _SigLockedDustAllowanceOutput_. + * `Address Type` must denote an _Ed25519 Address_. * `Amount` must be larger than zero. - * Outputs must be sorted in lexicographical order by their serialized form.1 - * Accumulated output balance must not exceed the total supply of tokens `2'779'530'283'277'761`. + * `Outputs` must be sorted in lexicographical order of their serialized form.1 + * Each `Address` must be unique per output type. For example, a _SigLockedSingleOutput_ and a _SigLockedDustAllowanceOutput_ can have the same address, but not two _SigLockedSingleOutputs_. + * The sum of all `Amount` fields must not exceed the total IOTA supply of 2,779,530,283,277,761. * Payload (if present): * `Payload Type` must match one of the values described under [Payload](#payload). * `Data fields` must be correctly parsable in the context of the `Payload Type`. * The payload itself must pass syntactic validation. * Unlock Blocks: * `Unlock Blocks Count` must match `Inputs Count` of the _Transaction Essence_. - * `Unlock Type` must either be 0 or 1, denoting a `Signature Unlock Block` or `Reference Unlock block`. - * `Signature Unlock Blocks` must define a `Ed25519 Signature`. - * A `Signature Unlock Block` unlocking multiple inputs must only appear once (be unique) and be positioned at the same index of the first input it unlocks. All other inputs unlocked by the same `Signature Unlock Block` must have a companion `Reference Unlock Block` at the same index as the corresponding input which points to the origin `Signature Unlock Block`. - * `Reference Unlock Blocks` must specify a previous `Unlock Block` which is not of type `Reference Unlock Block`. The reference index must therefore be < the index of the `Reference Unlock Block`. + * Each `Unlock Type` must denote a _Signature Unlock Block_ or a _Reference Unlock Block_. + * Each _Signature Unlock Block_ must contain an _Ed25519 Signature_. + * Each _Signature Unlock Block_ must be unique. + * A _Reference Unlock Block_ at index i must have `Reference` < i and the unlock block at index `Reference` must be a _Signature Unlock Block_. * Given the type and length information, the _Transaction Payload_ must consume the entire byte array of the `Payload` field of the encapsulating object. 1 ensures that serialization of the transaction becomes deterministic, meaning that libraries always produce the same bytes given the logical transaction. -### Semantic Validation +### Semantic validation -Semantic validation starts when a message that is part of a confirmation cone of a milestone is processed in the [White-Flag ordering](https://iotaledger.github.io/protocol-rfcs/0005-white-flag/0005-white-flag.html#deterministically-ordering-the-tangle). Semantics are only validated during White-Flag confirmations to enforce an ordering that can be understood by all the nodes (i.e. milestone cones), no matter the order the transactions are received. Otherwise, if semantic validation would occur as soon as a transaction would be received, it could potentially lead to nodes having different views of the UTXOs available to spend. +The Semantic validation of a _Transaction Payload_ is performed when its encapsulating message is confirmed by a milestone. The semantic validity of transactions depends on the order in which they are processed. Thus, it is necessary that all the nodes in the network perform the checks in the same order, no matter the order in which the transactions are received. This is assured by using the White-Flag ordering as described in [RFC-005](https://iotaledger.github.io/protocol-rfcs/0005-white-flag/0005-white-flag.html#deterministically-ordering-the-tangle). +Processing transactions according to the White-Flag ordering enables users to spend UTXOs which are created in the same milestone confirmation cone, as long as the spending transaction comes after the funding transaction in the aforementioned White-Flag order. In this case, it is recommended that users include the _Message ID_ of the funding transaction as a parent of the message containing the spending transaction. -Processing transactions in the White-Flag ordering enables users to spend UTXOs which are in the same milestone confirmation cone, if their transaction comes after the funding transaction in the mentioned White-Flag ordering. It is recommended that users spending unconfirmed UTXOs attach their message directly onto the message containing the source transaction. +The following criteria defines whether a payload passes the semantic validation: +* Each input must reference a valid UTXO, i.e. the output referenced by the input's `Transaction ID` and `Transaction Output Index` is known (booked) and unspent. +* The transaction must spend the entire balance, i.e. the sum of the `Amount` fields of all the UTXOs referenced by inputs must match the sum of the `Amount` fields of all outputs. +* Each unlock block must be valid with respect to the UTXO referenced by the input of the same index: + * If it is a _Signature Unlock Block_: + * The `Signature Type` must match the `Address Type` of the UTXO, + * the BLAKE2b-256 hash of `Public Key` must match the `Address` of the UTXO and + * the `Signature` field must contain a valid signature for `Public Key`. + * If it is a _Reference Unlock Block_, the referenced _Signature Unlock Block_ must be valid with respect to the UTXO. -The following criteria defines whether the transaction passes the semantic validation: -1. The UTXOs the transaction references must be known (booked) and unspent. -1. The transaction is spending the entirety of the funds of the referenced UTXOs to the outputs. -1. The address type of the referenced UTXO must match the signature type contained in the corresponding Signature Unlock Block. -1. The Signature Unlock Blocks are valid, i.e. the signatures prove ownership over the addresses of the referenced UTXOs. +If a _Transaction Payload_ passes the semantic validation, its referenced UTXOs must be marked as spent and its new outputs must be created/booked in the ledger. The _Message ID_ of the message encapsulating the processed payload then also becomes part of the input for the White-Flag Merkle tree hash of the confirming milestone ([RFC-0012](https://iotaledger.github.io/protocol-rfcs/0012-milestone-merkle-validation/0012-milestone-merkle-validation.html)). -If a transaction passes the semantic validation, its referenced UTXOs must be marked as spent and the corresponding new outputs must be booked/specified in the ledger. The booked transaction then also becomes part of the White-Flag Merkle tree inclusion set. - -Transactions which do not pass semantic validation are ignored. Their UTXOs are not marked as spent and neither are their outputs booked into the ledger. +Transactions that do not pass semantic validation are ignored. Their UTXOs are not marked as spent and their outputs are not booked in the ledger. ## Miscellaneous -### Absent transaction timestamp - -A transaction timestamp whether signed or not, does not actually tell when the transaction was issued. Therefore, the timestamp has been left out from the transaction structure. The correct way to determine the issuance time is to use a combination of the solidification and confirmation timestamps of the message embedding the transaction. +### Transaction timestamps -### How to compute the balance +Since transaction timestamps -- whether they are signed or not -- do not provide any guarantee of correctness, they have been left out of the _Transaction Payload_. Applications relying on some notion of time for transactions can use the local solidification time or the global timestamp of the confirming milestone ([RFC-0019](https://iotaledger.github.io/protocol-rfcs/0019-milestone-payload/0019-milestone-payload.html)). -Since the ledger is no longer account based, meaning that balances are directly mapped to addresses, computing the balance involves iterating over all UTXOs where their destination address is the address in question and then accumulating their amounts. +### Address reuse -### Reusing the same address with Ed25519 +While, in contrast to Winternitz one-time signatures (W-OTS), producing multiple Ed25519 signatures for the same private key and address does not decrease its security, it still drastically reduces the privacy of users. It is thus considered best practice that applications and services create a new address per deposit to circumvent these privacy issues. -While creating multiple signatures with Ed25519 does not reduce security, repeatedly reusing the same address not only drastically reduces the privacy of users but also all other people in the UTXO chain of the moved funds. Applications and services are then instructed to create new addresses per deposit, to circumvent the privacy issues stemming from address reuse. -In essence, Ed25519 support allows for smaller transaction sizes and to safely spend funds which were sent to an already used deposit address. -Ed25519 addresses are not meant to be used like an e-mail address. See this [Bitcoin wiki entry](https://en.bitcoin.it/wiki/Address_reuse#:~:text=The%20most%20private%20and%20secure,a%20brand%20new%20bitcoin%20address.) for further information on how address reuse reduces privacy and this [article](https://en.bitcoin.it/wiki/Receiving_donations_with_bitcoin) on why the same should be applied to donation addresses. +In essence, Ed25519 support allows for smaller transaction sizes and to safely spend funds which were sent to an already used deposit address. Ed25519 addresses are not meant to be used like email addresses. See this [Bitcoin wiki article](https://en.bitcoin.it/wiki/Address_reuse) for further information. # Drawbacks -The new transaction format is the core data type within the IOTA ecosystem. Changing it means that all projects need to accommodate for it, including client libraries, blueprints, PoC, and applications using IOTA in general. There is no way to keep the changes backwards compatible. Additionally, these changes are breaking, meaning that all nodes must upgrade to further participate in the network. - -Additionally, local snapshots can no longer be represented by a list of addresses and their balances, since the ledger is now made up of the UTXOs on which the actual funds reside on. Therefore, local snapshot file schemes have to be adjusted to incorporate the transaction hashes, output indices, and then the destination addresses including the balances. +* The new transaction format is the core data type within the IOTA ecosystem. Changing it means that all projects need to accommodate it, including wallets, web services, client libraries and applications using IOTA in general. It is not possible to keep these changes backwards compatible, meaning that all nodes must upgrade to further participate in the network. +* Additionally, local snapshots can no longer be represented by a list of addresses and their balances, since the ledger is now made up of the UTXOs on which the actual funds reside. Therefore, local snapshot file schemes have to be adjusted to incorporate the transaction hashes, output indices, and then the destination addresses including the balances. # Rationale and alternatives -Introducing this new transaction structure allows for further extensions in the future, to accommodate new requirements. With the support for Ed25519 addresses/signatures, transaction size is drastically reduced and allows for safe re-signing in case funds appear to be deposited onto a previous generated address. Due to the switch to a complete binary transaction, size is further reduced, saving network bandwidth and processing time. - -Other transaction structures have been considered but they would have misused existing transaction fields to accommodate for new features, instead of putting them into a proper descriptive structure. Additionally, those ideas would not have been safe against replay attacks, which deems reusing the old transaction structure, for example for Ed25519 addresses/signatures, as infeasible. - -Not switching to the new transaction structure described in this RFC leads to people being open to loss of funds because of WOTS address re-use and not being able to properly extend the protocol further down the line. +* Introducing this new transaction structure allows for extensions in the future, to accommodate new requirements. With the support for Ed25519 addresses/signatures, transaction size is drastically reduced and allows for safe re-signing in case of address reuse. Due to the switch to a complete binary transaction, the transaction size is reduced even further, saving network bandwidth and processing time. +* Other transaction structures have been considered but they would have misused existing transaction fields to accommodate for new features, instead of putting them into a proper descriptive structure. Additionally, those ideas would not have been safe against replay attacks, which deems reusing the old transaction structure, for example for Ed25519 addresses/signatures, as infeasible. +* Not switching to the new transaction structure described in this RFC would have led to more people losing funds because of W-OTS address reuse and it would prevent extending the IOTA protocol further down the line. From 63bdac0c8f955bbfdb351c284a4d70270ba06afc Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Thu, 4 Nov 2021 14:05:08 +0100 Subject: [PATCH 34/35] Fix en-dash --- text/0018-transaction-payload/0018-transaction-payload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0018-transaction-payload/0018-transaction-payload.md b/text/0018-transaction-payload/0018-transaction-payload.md index ca238bf5d..35bb5bf02 100644 --- a/text/0018-transaction-payload/0018-transaction-payload.md +++ b/text/0018-transaction-payload/0018-transaction-payload.md @@ -523,7 +523,7 @@ Transactions that do not pass semantic validation are ignored. Their UTXOs are n ### Transaction timestamps -Since transaction timestamps -- whether they are signed or not -- do not provide any guarantee of correctness, they have been left out of the _Transaction Payload_. Applications relying on some notion of time for transactions can use the local solidification time or the global timestamp of the confirming milestone ([RFC-0019](https://iotaledger.github.io/protocol-rfcs/0019-milestone-payload/0019-milestone-payload.html)). +Since transaction timestamps – whether they are signed or not – do not provide any guarantee of correctness, they have been left out of the _Transaction Payload_. Applications relying on some notion of time for transactions can use the local solidification time or the global timestamp of the confirming milestone ([RFC-0019](https://iotaledger.github.io/protocol-rfcs/0019-milestone-payload/0019-milestone-payload.html)). ### Address reuse From 03725311c98b9f04fa355fb5e08ebf07b2a79f11 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Thu, 4 Nov 2021 14:34:36 +0100 Subject: [PATCH 35/35] Clarify semantic validity of the payload --- text/0018-transaction-payload/0018-transaction-payload.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0018-transaction-payload/0018-transaction-payload.md b/text/0018-transaction-payload/0018-transaction-payload.md index 35bb5bf02..f3d2d19c4 100644 --- a/text/0018-transaction-payload/0018-transaction-payload.md +++ b/text/0018-transaction-payload/0018-transaction-payload.md @@ -429,7 +429,7 @@ The SigLockedDustAllowanceOutput works in the same way as a SigLockedS ##### Payload -The _Transaction Essence_ itself can contain another payload as described in general in [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html). If the transaction is not [semantically valid](#semantic-validation), then the payload must also be discarded. +The _Transaction Essence_ itself can contain another payload as described in general in [RFC-0017](https://iotaledger.github.io/protocol-rfcs/0017-tangle-message/0017-tangle-message.html). The [semantic validity](#semantic-validation) of the encapsulating _Transaction Payload_ does not have any impact on the payload. The following table lists all the payload types that can be nested inside a _Transaction Essence_ as well as links to the corresponding specification: