From d85fd9b443a5d6aa85a4f107ee0695a3c4523d18 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Fri, 25 Mar 2022 17:31:10 +0100 Subject: [PATCH 01/20] add TIP-30 --- tips/TIP-0030/tip-0030.md | 236 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 236 insertions(+) create mode 100644 tips/TIP-0030/tip-0030.md diff --git a/tips/TIP-0030/tip-0030.md b/tips/TIP-0030/tip-0030.md new file mode 100644 index 000000000..1dcbb6ef5 --- /dev/null +++ b/tips/TIP-0030/tip-0030.md @@ -0,0 +1,236 @@ +--- +tip: 30 +title: Milestone Payload +description: Coordinator issued milestone payload with Ed25519 authentication +author: Angelo Capossele (@capossele) , Wolfgang Welz (@Wollac) +discussions-to: https://github.com/iotaledger/tips/pull/69 +status: Draft +type: Standards +layer: Core +created: 2022-03-25 +requires: TIP-8 +--- + +# Summary + +In IOTA, nodes use the milestones issued by the Coordinator to reach a consensus on which transactions are confirmed. This TIP proposes a milestone payload for the messages described in the IOTA protocol [TIP-6](../TIP-0006/tip-0006.md). It uses Edwards-curve Digital Signature Algorithm (EdDSA) to authenticate the milestones. + +# Motivation + +In order to integrate the concept of milestones consistently into Tangle messages, this TIP describes a dedicated payload type for milestones. It contains the same essential data fields that were part of a milestone bundle in the legacy IOTA protocol. Additionally, this document also describes how Ed25519 signatures are used to assure authenticity of the issued milestones. In order to make the management and security of the used private keys easier, simple multisignature features with support for key rotation have been added. + +# Detailed design + +The [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash of the _Milestone Essence_, consisting of the actual milestone information (like its index number or position in the tangle), is signed using the Ed25519 signature scheme as described in the IRTF [RFC 8032](https://tools.ietf.org/html/rfc8032). + +To increase the security of the design, a milestone can (optionally) be independently signed by multiple keys at once. These keys should be operated by detached signature provider services running on independent infrastructure elements. This assists in mitigating the risk of an attacker having access to all the key material necessary for forging milestones. While the Coordinator takes responsibility for forming Milestone Payload Messages, it delegates signing in to these providers through an ad-hoc RPC connector. Mutual authentication should be enforced between the Coordinator and the signature providers: a [client-authenticated TLS handshake](https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake) scheme is advisable. To increase the flexibility of the mechanism, nodes can be configured to require a quorum of valid signatures to consider a milestone as genuine. + +In addition, a key rotation policy can also be enforced by limiting key validity to certain milestone intervals. Accordingly, nodes need to know which public keys are applicable for which milestone index. This can be provided by configuring a list of entries consisting of the following fields: +- _Index Range_ providing the interval of milestone indices for which this entry is valid. The interval must not overlap with any other entry. +- _Applicable Public Keys_ defining the set of valid public keys. +- _Signature Threshold_ specifying the minimum number of valid signatures. Must be at least one and not greater than the number of _Applicable Public Keys_. + +## Structure + +All values are serialized in little-endian encoding. The serialized form of the milestone is deterministic, meaning the same logical milestone always results in the same serialized byte sequence. + +The following table structure describes the entirety of a _Milestone Payload_ in its serialized form ([TIP-6 Data Types](../TIP-0006/tip-0006.md#data-types)): + + + + + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Payload Typeuint32Set to value 1 to denote a Milestone Payload.
Essence oneOf +
+ Milestone Essence +
Describes the signed part of a Milestone Payload.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Index Numberuint32The index number of the milestone.
Timestampuint64The Unix time (seconds since Unix epoch) at which the milestone was issued.
Parents Countuint8The number of messages that are directly approved.
Parents anyOf +
+ Parent +
+ References another directly approved message. +
+ + + + + + + + + + + +
NameTypeDescription
Message IDByteArray[32]The Message ID of the parent.
+
+
Inclusion Merkle RootByteArray[32]The Merkle tree hash (BLAKE2b-256) of the message IDs of all the not-ignored state-mutating transaction payloads referenced by the milestone (TIP-0004).
Next PoW Scoreuint32The new PoW score all messages should adhere to. If 0 then the PoW score should not change.
Next PoW Score Milestone Indexuint32The index of the first milestone that will require a new minimal pow score for applying transactions. This field comes into effect only if the Next PoW Score field is not 0.
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.
+
+
+
+
Signatures Countuint8Number of signature entries. The number must match the field Keys Count.
Signatures anyOf +
+ 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 Milestone Essence.
+
+
+ +## Generation + +- Generate a new _Milestone Essence_ corresponding to the Coordinator milestone. +- Transmit the serialized _Milestone Essence_ to the corresponding number of signature service providers. + - The signature provider service will sign the received serialized bytes as-is. + - The signature provider will serialize the signature bytes and return them to the Coordinator. +- Fill the `Signatures` field of the milestone payload with the received signature bytes. +- Generate a *Message* as defined in [TIP-6](../TIP-0006/tip-0006.md) using the same `Parents` as in the created _Milestone Payload_. + +## Syntactic validation + +- `Parents` of the payload must match `Parents` of the encapsulating _Message_. +- PoW score: + - If `Next Pow Score` is zero, `Next PoW Score Milestone Index` must also be zero. + - Otherwise `Next PoW Score Milestone Index` must be larger than `Index Number`. +- Payload (if present): + - `Payload Type` must match one of the values described under [Payloads](#payloads). + - `Data fields` must be correctly parsable in the context of the `Payload Type`. + - The payload itself must pass syntactic validation. +- Signatures: + - `Signatures Count` must be at least the _Signature Threshold_ and at most the number of _Applicable Public Keys_ for the current milestone index. + - For each signature block the following must be true: + - `Signature Type` value must denote an `Ed25519 Signature`. + - `Public Key` must be contained in _Applicable Public Keys_ for the current milestone index. + - The signature blocks must be sorted with respect to their `Public Key` in lexicographical order. + - Each `Public Key` must be unique. +- Given the type and length information, the _Milestone Payload_ must consume the entire byte array of the `Payload` field of the _Message_. + +### Payloads + +The _Milestone Payload_ itself can contain another payload as described in general in [TIP-6](../TIP-0006/tip-0006.md). The following table lists all the payloads types that can be nested inside a _Milestone Payload_ as well as links to the corresponding specification: + +| Payload Name | Type Value | TIP | +| ------------ | ---------- | ------------------------------------------ | +| Receipts | 4 | [TIP-15](../TIP-0015/tip-0015.md#receipts) | + +# Rationale and alternatives + +- Instead of using EdDSA we could have chosen ECDSA. Both algorithms are well supported and widespread. However, signing with ECDSA requires fresh randomness while EdDSA does not. Especially in the case of milestones where essences are signed many times using the same key, this is a crucial property. +- Due to the layered design of messages and payloads, it is practically not possible to prevent reattachments of _Milestone Payloads_. Hence, this payload has been designed in a way to be independent from the message it is contained in. A milestone should be considered as a virtual marker (referencing `Parents`) rather than an actual message in the Tangle. This concept is compatible with reattachments and supports a cleaner separation of the message layers. +- Forcing matching `Parents` in the _Milestone Payload_ and its _Message_ makes it impossible to reattach the same payload at different positions in the Tangle. This does not prevent reattachments in general (a different, valid `Nonce`, for example would lead to a new Message ID) and it violates a strict separation of payload and message. However, it simplifies milestone processing as the position of the Message will be the same as the position encoded in the Milestone Payload. Having these clear structural properties seems to be more desirable than a strict separation of layers. + +# Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From c09bd705d2a5a0a16bdf2dd85921ec1f9dd2707f Mon Sep 17 00:00:00 2001 From: Levente Pap Date: Fri, 25 Mar 2022 19:15:28 +0100 Subject: [PATCH 02/20] Swap TIP number --- tips/{TIP-0030/tip-0030.md => TIP-0029/tip-0029.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename tips/{TIP-0030/tip-0030.md => TIP-0029/tip-0029.md} (99%) diff --git a/tips/TIP-0030/tip-0030.md b/tips/TIP-0029/tip-0029.md similarity index 99% rename from tips/TIP-0030/tip-0030.md rename to tips/TIP-0029/tip-0029.md index 1dcbb6ef5..664d02ef1 100644 --- a/tips/TIP-0030/tip-0030.md +++ b/tips/TIP-0029/tip-0029.md @@ -1,5 +1,5 @@ --- -tip: 30 +tip: 29 title: Milestone Payload description: Coordinator issued milestone payload with Ed25519 authentication author: Angelo Capossele (@capossele) , Wolfgang Welz (@Wollac) @@ -8,7 +8,7 @@ status: Draft type: Standards layer: Core created: 2022-03-25 -requires: TIP-8 +replaces: 8 --- # Summary From 612d96330dde7d460a8766b635af496c0b73c6f3 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Sat, 26 Mar 2022 13:06:30 +0100 Subject: [PATCH 03/20] Introduce new payload type value --- tips/TIP-0029/tip-0029.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 664d02ef1..c4bb1aaf8 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -45,7 +45,7 @@ The following table structure describes the entirety of a _Milestone Payload_ in Payload Type uint32 - Set to value 1 to denote a Milestone Payload. + Set to value 7 to denote a Milestone Payload. Essence oneOf @@ -200,14 +200,15 @@ The following table structure describes the entirety of a _Milestone Payload_ in ## Syntactic validation -- `Parents` of the payload must match `Parents` of the encapsulating _Message_. -- PoW score: - - If `Next Pow Score` is zero, `Next PoW Score Milestone Index` must also be zero. - - Otherwise `Next PoW Score Milestone Index` must be larger than `Index Number`. -- Payload (if present): - - `Payload Type` must match one of the values described under [Payloads](#payloads). - - `Data fields` must be correctly parsable in the context of the `Payload Type`. - - The payload itself must pass syntactic validation. +- Essence: + - `Parents` of the payload must match `Parents` of the encapsulating _Message_. + - PoW score: + - If `Next Pow Score` is zero, `Next PoW Score Milestone Index` must also be zero. + - Otherwise `Next PoW Score Milestone Index` must be larger than `Index Number`. + - Payload (if present): + - `Payload Type` must match one of the values described under [Payloads](#payloads). + - `Data fields` must be correctly parsable in the context of the `Payload Type`. + - The payload itself must pass syntactic validation. - Signatures: - `Signatures Count` must be at least the _Signature Threshold_ and at most the number of _Applicable Public Keys_ for the current milestone index. - For each signature block the following must be true: From a4f3cbb9c07b084d24a957d40f97d8182d800cd5 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Fri, 1 Apr 2022 16:12:37 +0200 Subject: [PATCH 04/20] Add metadata --- tips/TIP-0029/tip-0029.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index c4bb1aaf8..5092d501f 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -112,6 +112,11 @@ The following table structure describes the entirety of a _Milestone Payload_ in uint32 The index of the first milestone that will require a new minimal pow score for applying transactions. This field comes into effect only if the Next PoW Score field is not 0. + + Metadata + (uint16)ByteArray + Binary data only relevant to milestone issuer, e.g. internal state. A leading uint16 denotes its length. + Payload Length uint32 From 8e4642b235d02d7c58b039524d1b55c73612e2c8 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Thu, 21 Apr 2022 13:20:53 +0100 Subject: [PATCH 05/20] Update with milestone options --- tips/TIP-0029/tip-0029.md | 156 ++++++++++++++++++++------------------ 1 file changed, 84 insertions(+), 72 deletions(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 5092d501f..24443c79a 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -11,7 +11,7 @@ created: 2022-03-25 replaces: 8 --- -# Summary +# Abstract In IOTA, nodes use the milestones issued by the Coordinator to reach a consensus on which transactions are confirmed. This TIP proposes a milestone payload for the messages described in the IOTA protocol [TIP-6](../TIP-0006/tip-0006.md). It uses Edwards-curve Digital Signature Algorithm (EdDSA) to authenticate the milestones. @@ -19,7 +19,7 @@ In IOTA, nodes use the milestones issued by the Coordinator to reach a consensus In order to integrate the concept of milestones consistently into Tangle messages, this TIP describes a dedicated payload type for milestones. It contains the same essential data fields that were part of a milestone bundle in the legacy IOTA protocol. Additionally, this document also describes how Ed25519 signatures are used to assure authenticity of the issued milestones. In order to make the management and security of the used private keys easier, simple multisignature features with support for key rotation have been added. -# Detailed design +# Specification The [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash of the _Milestone Essence_, consisting of the actual milestone information (like its index number or position in the tangle), is signed using the Ed25519 signature scheme as described in the IRTF [RFC 8032](https://tools.ietf.org/html/rfc8032). @@ -30,11 +30,18 @@ In addition, a key rotation policy can also be enforced by limiting key validity - _Applicable Public Keys_ defining the set of valid public keys. - _Signature Threshold_ specifying the minimum number of valid signatures. Must be at least one and not greater than the number of _Applicable Public Keys_. +## Milestone ID + +The _Milestone ID_ is the BLAKE2b-256 hash of the serialized _Milestone Essence_. +It is important to note that the signatures do not impact the _Milestone ID_. + ## Structure +### Serialized Layout + All values are serialized in little-endian encoding. The serialized form of the milestone is deterministic, meaning the same logical milestone always results in the same serialized byte sequence. -The following table structure describes the entirety of a _Milestone Payload_ in its serialized form ([TIP-6 Data Types](../TIP-0006/tip-0006.md#data-types)): +The following table describes the entirety of a _Milestone Payload_ in its serialized form following the notation from [TIP-21](../TIP-0021/tip-0021.md): @@ -66,22 +73,25 @@ The following table structure describes the entirety of a _Milestone Payload_ in - + + + + + + - + @@ -158,7 +146,7 @@ The following table structure describes the entirety of a _Milestone Payload_ in - + @@ -194,48 +182,72 @@ The following table structure describes the entirety of a _Milestone Payload_ in
Timestampuint64uint32 The Unix time (seconds since Unix epoch) at which the milestone was issued.
Last Milestone IDByteArray[32]The Milestone ID of the milestone with Index Number - 1.
Parents Count uint8The number of messages that are directly approved.The number of parents referenced by this milestone.
Parents anyOf
Parent -
- References another directly approved message. -
+
A message that is directly referenced by this milestone.
@@ -98,59 +108,37 @@ The following table structure describes the entirety of a _Milestone Payload_ in - + - - - - - - - + - - - + + + - + - - - + + + - + +
+ Receipts Milestone Option +
Defines UTXOs for newly migrated funds.
+
+ +
Name
Inclusion Merkle RootConfirmed Merkle Root ByteArray[32]The Merkle tree hash (BLAKE2b-256) of the message IDs of all the not-ignored state-mutating transaction payloads referenced by the milestone (TIP-0004).
Next PoW Scoreuint32The new PoW score all messages should adhere to. If 0 then the PoW score should not change.
The Merkle tree hash (BLAKE2b-256) of the Message IDs of all messages confirmed by this milestone.
Next PoW Score Milestone Indexuint32The index of the first milestone that will require a new minimal pow score for applying transactions. This field comes into effect only if the Next PoW Score field is not 0.Applied Merkle RootByteArray[32]The Merkle tree hash (BLAKE2b-256) of the Message IDs of all messages applied by this milestone that contain a state-mutating transaction (see TIP-4).
Metadata (uint16)ByteArrayBinary data only relevant to milestone issuer, e.g. internal state. A leading uint16 denotes its length.Binary data only relevant to the milestone issuer, e.g. internal state. A leading uint16 denotes its length.
Payload Lengthuint32The length in bytes of the optional payload.Options Countuint8The number of milestone options following.
Payload optOneOfOptions atMostOneOfEach
- 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.
+ PoW Milestone Option +
Defines dynamic changes to the PoW parameters.
-
Signatures Count uint8Number of signature entries. The number must match the field Keys Count.The number of signature entries following.
Signatures anyOf
-## Generation +### Milestone options + +The `Options` field holds additional data authenticated by the milestone. + +The following table lists all the `Milestone Option Type` that are currently supported as well as links to the corresponding specification: -- Generate a new _Milestone Essence_ corresponding to the Coordinator milestone. -- Transmit the serialized _Milestone Essence_ to the corresponding number of signature service providers. - - The signature provider service will sign the received serialized bytes as-is. - - The signature provider will serialize the signature bytes and return them to the Coordinator. -- Fill the `Signatures` field of the milestone payload with the received signature bytes. -- Generate a *Message* as defined in [TIP-6](../TIP-0006/tip-0006.md) using the same `Parents` as in the created _Milestone Payload_. +| Payload Name | Type Value | TIP | +| ------------ | ---------- | ------------------------------------------ | +| Receipt | 0 | [TIP-17](../TIP-0017/tip-0017.md#receipts) | +| PoW | 1 | [TIP-29](#pow-milestone-option) | + +#### PoW Milestone Option + +The _PoW Milestone Option_ allows to change the PoW protocol parameters. + +| Name | Type | Description | +| ------------------------------ | ------ | ----------------------------------------------------------------------------------------------------- | +| Milestone Option Type | uint8 | Set to **value 1** to denote a *PoW Milestone Option*. | +| Next PoW Score | uint32 | The new PoW score all messages should adhere to. | +| Next PoW Score Milestone Index | uint32 | The index of the first milestone that will require a new minimal pow score for applying transactions. | + +## Validation -## Syntactic validation +Similar to transaction validation, milestone validation has been separated into two classes. For a milestone to be valid, both of them need to be true. + +### Syntactic validation + +Syntactic validation can be checked from the _Milestone Essence_ plus the messages in the past cone referenced by it. - Essence: + - `Index Number` must not be smaller than `First Milestone Index`. + - If `Index Number` equals `First Milestone Index`, the following fields must be zeroed out: + - `Last Milestone ID` + - `Confirmed Merkle Root` + - `Applied Merkle Root` + - If `Index Number` is greater than `First Milestone Index`, the milestone must reference (i.e. one of the `Parents` must contain or reference) another syntactically valid milestone whose _Milestone ID_ matches `Last Milestone ID`. With respect to that referenced milestone, the following must hold: + - `Index Number` must increment by `1`. + - `Timestamp` must be strictly larger (i.e. at least one second later). + - `Confirmed Merkle Root` must match the Merkle tree hash of the IDs of all messages in _White Flag Ordering_ (as described in TIP-2) that are newly referenced. (This always includes at least one valid milestone message with `Last Milestone ID`.) + - `Applied Merkle Root` must match the Merkle tree hash of the not-ignored state-mutating transactions that are newly referenced (see TIP-2). - `Parents` of the payload must match `Parents` of the encapsulating _Message_. - - PoW score: - - If `Next Pow Score` is zero, `Next PoW Score Milestone Index` must also be zero. - - Otherwise `Next PoW Score Milestone Index` must be larger than `Index Number`. - - Payload (if present): - - `Payload Type` must match one of the values described under [Payloads](#payloads). - - `Data fields` must be correctly parsable in the context of the `Payload Type`. - - The payload itself must pass syntactic validation. + - Options: + - `Milestone Option Type` must match one of the values described under [Milestone Options](#milestone-options). + - The option itself must pass syntactic validation. + - The options must be sorted in ascending order based on their `Milestone Option Type`. - Signatures: - `Signatures Count` must be at least the _Signature Threshold_ and at most the number of _Applicable Public Keys_ for the current milestone index. - For each signature block the following must be true: - `Signature Type` value must denote an `Ed25519 Signature`. - `Public Key` must be contained in _Applicable Public Keys_ for the current milestone index. + - `Signature` must contain a valid signature for `Public Key`. - The signature blocks must be sorted with respect to their `Public Key` in lexicographical order. - Each `Public Key` must be unique. - Given the type and length information, the _Milestone Payload_ must consume the entire byte array of the `Payload` field of the _Message_. + +### Semantic validation -### Payloads - -The _Milestone Payload_ itself can contain another payload as described in general in [TIP-6](../TIP-0006/tip-0006.md). The following table lists all the payloads types that can be nested inside a _Milestone Payload_ as well as links to the corresponding specification: +Semantic validation is defined in the context of all available messages. -| Payload Name | Type Value | TIP | -| ------------ | ---------- | ------------------------------------------ | -| Receipts | 4 | [TIP-15](../TIP-0015/tip-0015.md#receipts) | +- The milestone chain must not fork, i.e. there must not be two different, syntactically valid milestones with the same `Index Number`. In case of a fork, the correct state of the ledger cannot be derived from the milestones alone and usually the node implementation should alert the user and halt. -# Rationale and alternatives +# Rationale -- Instead of using EdDSA we could have chosen ECDSA. Both algorithms are well supported and widespread. However, signing with ECDSA requires fresh randomness while EdDSA does not. Especially in the case of milestones where essences are signed many times using the same key, this is a crucial property. - Due to the layered design of messages and payloads, it is practically not possible to prevent reattachments of _Milestone Payloads_. Hence, this payload has been designed in a way to be independent from the message it is contained in. A milestone should be considered as a virtual marker (referencing `Parents`) rather than an actual message in the Tangle. This concept is compatible with reattachments and supports a cleaner separation of the message layers. - Forcing matching `Parents` in the _Milestone Payload_ and its _Message_ makes it impossible to reattach the same payload at different positions in the Tangle. This does not prevent reattachments in general (a different, valid `Nonce`, for example would lead to a new Message ID) and it violates a strict separation of payload and message. However, it simplifies milestone processing as the position of the Message will be the same as the position encoded in the Milestone Payload. Having these clear structural properties seems to be more desirable than a strict separation of layers. +- While it is always possible to cryptographically prove that a message was confirmed by a given milestone by supplying all the messages of a path from the milestone to the message, such a proof can become rather large (depending on the messages). To simplify such proof-of-inclusions, the `Confirmed Merkle Root` of all the confirmed messages has been added. # Copyright From 900a7701a3db222489c4e9cf6b7b32c5d4b094a6 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Thu, 21 Apr 2022 13:32:39 +0100 Subject: [PATCH 06/20] update receipt TIP --- tips/TIP-0029/tip-0029.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 24443c79a..d5ede16c9 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -188,10 +188,10 @@ The `Options` field holds additional data authenticated by the milestone. The following table lists all the `Milestone Option Type` that are currently supported as well as links to the corresponding specification: -| Payload Name | Type Value | TIP | -| ------------ | ---------- | ------------------------------------------ | -| Receipt | 0 | [TIP-17](../TIP-0017/tip-0017.md#receipts) | -| PoW | 1 | [TIP-29](#pow-milestone-option) | +| Payload Name | Type Value | TIP | +| ------------ | ---------- | ---------------------------------------------------------- | +| Receipt | 0 | [TIP-34](../TIP-0034/tip-0034.md#receipt-milestone-option) | +| PoW | 1 | [TIP-29](#pow-milestone-option) | #### PoW Milestone Option From c1f88e41cc95d14bac374066df1e0aaf25442ee0 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Thu, 21 Apr 2022 14:04:25 +0100 Subject: [PATCH 07/20] Clarify encapsulating message --- tips/TIP-0029/tip-0029.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index d5ede16c9..000a750b2 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -222,7 +222,7 @@ Syntactic validation can be checked from the _Milestone Essence_ plus the messag - `Timestamp` must be strictly larger (i.e. at least one second later). - `Confirmed Merkle Root` must match the Merkle tree hash of the IDs of all messages in _White Flag Ordering_ (as described in TIP-2) that are newly referenced. (This always includes at least one valid milestone message with `Last Milestone ID`.) - `Applied Merkle Root` must match the Merkle tree hash of the not-ignored state-mutating transactions that are newly referenced (see TIP-2). - - `Parents` of the payload must match `Parents` of the encapsulating _Message_. + - `Parents` must match the `Parents` field of the encapsulating _Message_, i.e. the _Message_ that contains the _Milestone Payload_. - Options: - `Milestone Option Type` must match one of the values described under [Milestone Options](#milestone-options). - The option itself must pass syntactic validation. From c3ab001a6fae14cf2b522535c4f54404d3aa7de9 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Mon, 25 Apr 2022 10:32:47 +0100 Subject: [PATCH 08/20] Remove PoW Milestone Option The PoW option will be part of the upcoming Dynamic PoW TIP --- tips/TIP-0029/tip-0029.md | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 000a750b2..11591e280 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -191,17 +191,6 @@ The following table lists all the `Milestone Option Type` that are currently sup | Payload Name | Type Value | TIP | | ------------ | ---------- | ---------------------------------------------------------- | | Receipt | 0 | [TIP-34](../TIP-0034/tip-0034.md#receipt-milestone-option) | -| PoW | 1 | [TIP-29](#pow-milestone-option) | - -#### PoW Milestone Option - -The _PoW Milestone Option_ allows to change the PoW protocol parameters. - -| Name | Type | Description | -| ------------------------------ | ------ | ----------------------------------------------------------------------------------------------------- | -| Milestone Option Type | uint8 | Set to **value 1** to denote a *PoW Milestone Option*. | -| Next PoW Score | uint32 | The new PoW score all messages should adhere to. | -| Next PoW Score Milestone Index | uint32 | The index of the first milestone that will require a new minimal pow score for applying transactions. | ## Validation From ff9d8a430a77aa943dc5ccb2010736c229963ab5 Mon Sep 17 00:00:00 2001 From: Levente Pap Date: Tue, 26 Apr 2022 14:08:14 +0200 Subject: [PATCH 09/20] Changes "Last Milestone ID" to "Previous Milestone ID" --- tips/TIP-0029/tip-0029.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 11591e280..876c8b7ce 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -77,7 +77,7 @@ The following table describes the entirety of a _Milestone Payload_ in its seria The Unix time (seconds since Unix epoch) at which the milestone was issued. - Last Milestone ID + Previous Milestone ID ByteArray[32] The Milestone ID of the milestone with Index Number - 1. @@ -203,13 +203,13 @@ Syntactic validation can be checked from the _Milestone Essence_ plus the messag - Essence: - `Index Number` must not be smaller than `First Milestone Index`. - If `Index Number` equals `First Milestone Index`, the following fields must be zeroed out: - - `Last Milestone ID` + - `Previous Milestone ID` - `Confirmed Merkle Root` - `Applied Merkle Root` - - If `Index Number` is greater than `First Milestone Index`, the milestone must reference (i.e. one of the `Parents` must contain or reference) another syntactically valid milestone whose _Milestone ID_ matches `Last Milestone ID`. With respect to that referenced milestone, the following must hold: + - If `Index Number` is greater than `First Milestone Index`, the milestone must reference (i.e. one of the `Parents` must contain or reference) another syntactically valid milestone whose _Milestone ID_ matches `Previous Milestone ID`. With respect to that referenced milestone, the following must hold: - `Index Number` must increment by `1`. - `Timestamp` must be strictly larger (i.e. at least one second later). - - `Confirmed Merkle Root` must match the Merkle tree hash of the IDs of all messages in _White Flag Ordering_ (as described in TIP-2) that are newly referenced. (This always includes at least one valid milestone message with `Last Milestone ID`.) + - `Confirmed Merkle Root` must match the Merkle tree hash of the IDs of all messages in _White Flag Ordering_ (as described in TIP-2) that are newly referenced. (This always includes at least one valid milestone message with `Previous Milestone ID`.) - `Applied Merkle Root` must match the Merkle tree hash of the not-ignored state-mutating transactions that are newly referenced (see TIP-2). - `Parents` must match the `Parents` field of the encapsulating _Message_, i.e. the _Message_ that contains the _Milestone Payload_. - Options: From a60274bb7bc40948dd441efd18bf0fae8e6af985 Mon Sep 17 00:00:00 2001 From: Levente Pap Date: Thu, 19 May 2022 15:07:45 +0200 Subject: [PATCH 10/20] Rename "messages" to "blocks" --- tips/TIP-0029/tip-0029.md | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 876c8b7ce..d9cfe87ba 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -13,17 +13,17 @@ replaces: 8 # Abstract -In IOTA, nodes use the milestones issued by the Coordinator to reach a consensus on which transactions are confirmed. This TIP proposes a milestone payload for the messages described in the IOTA protocol [TIP-6](../TIP-0006/tip-0006.md). It uses Edwards-curve Digital Signature Algorithm (EdDSA) to authenticate the milestones. +In IOTA, nodes use the milestones issued by the Coordinator to reach a consensus on which transactions are confirmed. This TIP proposes a milestone payload for the blocks described in the IOTA protocol [TIP-24](../TIP-0024/tip-0024.md). It uses Edwards-curve Digital Signature Algorithm (EdDSA) to authenticate the milestones. # Motivation -In order to integrate the concept of milestones consistently into Tangle messages, this TIP describes a dedicated payload type for milestones. It contains the same essential data fields that were part of a milestone bundle in the legacy IOTA protocol. Additionally, this document also describes how Ed25519 signatures are used to assure authenticity of the issued milestones. In order to make the management and security of the used private keys easier, simple multisignature features with support for key rotation have been added. +In order to integrate the concept of milestones consistently into Tangle blocks, this TIP describes a dedicated payload type for milestones. It contains the same essential data fields that were part of a milestone bundle in the legacy IOTA protocol. Additionally, this document also describes how Ed25519 signatures are used to assure authenticity of the issued milestones. In order to make the management and security of the used private keys easier, simple multisignature features with support for key rotation have been added. # Specification The [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash of the _Milestone Essence_, consisting of the actual milestone information (like its index number or position in the tangle), is signed using the Ed25519 signature scheme as described in the IRTF [RFC 8032](https://tools.ietf.org/html/rfc8032). -To increase the security of the design, a milestone can (optionally) be independently signed by multiple keys at once. These keys should be operated by detached signature provider services running on independent infrastructure elements. This assists in mitigating the risk of an attacker having access to all the key material necessary for forging milestones. While the Coordinator takes responsibility for forming Milestone Payload Messages, it delegates signing in to these providers through an ad-hoc RPC connector. Mutual authentication should be enforced between the Coordinator and the signature providers: a [client-authenticated TLS handshake](https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake) scheme is advisable. To increase the flexibility of the mechanism, nodes can be configured to require a quorum of valid signatures to consider a milestone as genuine. +To increase the security of the design, a milestone can (optionally) be independently signed by multiple keys at once. These keys should be operated by detached signature provider services running on independent infrastructure elements. This assists in mitigating the risk of an attacker having access to all the key material necessary for forging milestones. While the Coordinator takes responsibility for forming Milestone Payload Blocks, it delegates signing in to these providers through an ad-hoc RPC connector. Mutual authentication should be enforced between the Coordinator and the signature providers: a [client-authenticated TLS handshake](https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake) scheme is advisable. To increase the flexibility of the mechanism, nodes can be configured to require a quorum of valid signatures to consider a milestone as genuine. In addition, a key rotation policy can also be enforced by limiting key validity to certain milestone intervals. Accordingly, nodes need to know which public keys are applicable for which milestone index. This can be provided by configuring a list of entries consisting of the following fields: - _Index Range_ providing the interval of milestone indices for which this entry is valid. The interval must not overlap with any other entry. @@ -91,7 +91,7 @@ The following table describes the entirety of a _Milestone Payload_ in its seria
Parent -
A message that is directly referenced by this milestone.
+
A block that is directly referenced by this milestone.
@@ -99,22 +99,22 @@ The following table describes the entirety of a _Milestone Payload_ in its seria - + - +
NameDescription
Message IDBlock ID ByteArray[32]The Message ID of the parent.The Block ID of the parent.
- Confirmed Merkle Root + Inclusion Merkle Root ByteArray[32] - The Merkle tree hash (BLAKE2b-256) of the Message IDs of all messages confirmed by this milestone. + The Merkle tree hash (BLAKE2b-256) of the Block IDs of all blocks included by this milestone. Applied Merkle Root ByteArray[32] - The Merkle tree hash (BLAKE2b-256) of the Message IDs of all messages applied by this milestone that contain a state-mutating transaction (see TIP-4). + The Merkle tree hash (BLAKE2b-256) of the Block IDs of all blocks applied by this milestone that contain a state-mutating transaction (see TIP-4). Metadata @@ -198,20 +198,20 @@ Similar to transaction validation, milestone validation has been separated into ### Syntactic validation -Syntactic validation can be checked from the _Milestone Essence_ plus the messages in the past cone referenced by it. +Syntactic validation can be checked from the _Milestone Essence_ plus the blocks in the past cone referenced by it. - Essence: - `Index Number` must not be smaller than `First Milestone Index`. - If `Index Number` equals `First Milestone Index`, the following fields must be zeroed out: - `Previous Milestone ID` - - `Confirmed Merkle Root` + - `Inlcusion Merkle Root` - `Applied Merkle Root` - If `Index Number` is greater than `First Milestone Index`, the milestone must reference (i.e. one of the `Parents` must contain or reference) another syntactically valid milestone whose _Milestone ID_ matches `Previous Milestone ID`. With respect to that referenced milestone, the following must hold: - `Index Number` must increment by `1`. - `Timestamp` must be strictly larger (i.e. at least one second later). - - `Confirmed Merkle Root` must match the Merkle tree hash of the IDs of all messages in _White Flag Ordering_ (as described in TIP-2) that are newly referenced. (This always includes at least one valid milestone message with `Previous Milestone ID`.) + - `Inlcusion Merkle Root` must match the Merkle tree hash of the IDs of all blocks in _White Flag Ordering_ (as described in TIP-2) that are newly referenced. (This always includes at least one valid milestone block with `Previous Milestone ID`.) - `Applied Merkle Root` must match the Merkle tree hash of the not-ignored state-mutating transactions that are newly referenced (see TIP-2). - - `Parents` must match the `Parents` field of the encapsulating _Message_, i.e. the _Message_ that contains the _Milestone Payload_. + - `Parents` must match the `Parents` field of the encapsulating _Block_, i.e. the _Block_ that contains the _Milestone Payload_. - Options: - `Milestone Option Type` must match one of the values described under [Milestone Options](#milestone-options). - The option itself must pass syntactic validation. @@ -224,19 +224,19 @@ Syntactic validation can be checked from the _Milestone Essence_ plus the messag - `Signature` must contain a valid signature for `Public Key`. - The signature blocks must be sorted with respect to their `Public Key` in lexicographical order. - Each `Public Key` must be unique. -- Given the type and length information, the _Milestone Payload_ must consume the entire byte array of the `Payload` field of the _Message_. +- Given the type and length information, the _Milestone Payload_ must consume the entire byte array of the `Payload` field of the _Block_. ### Semantic validation -Semantic validation is defined in the context of all available messages. +Semantic validation is defined in the context of all available blocks. - The milestone chain must not fork, i.e. there must not be two different, syntactically valid milestones with the same `Index Number`. In case of a fork, the correct state of the ledger cannot be derived from the milestones alone and usually the node implementation should alert the user and halt. # Rationale -- Due to the layered design of messages and payloads, it is practically not possible to prevent reattachments of _Milestone Payloads_. Hence, this payload has been designed in a way to be independent from the message it is contained in. A milestone should be considered as a virtual marker (referencing `Parents`) rather than an actual message in the Tangle. This concept is compatible with reattachments and supports a cleaner separation of the message layers. -- Forcing matching `Parents` in the _Milestone Payload_ and its _Message_ makes it impossible to reattach the same payload at different positions in the Tangle. This does not prevent reattachments in general (a different, valid `Nonce`, for example would lead to a new Message ID) and it violates a strict separation of payload and message. However, it simplifies milestone processing as the position of the Message will be the same as the position encoded in the Milestone Payload. Having these clear structural properties seems to be more desirable than a strict separation of layers. -- While it is always possible to cryptographically prove that a message was confirmed by a given milestone by supplying all the messages of a path from the milestone to the message, such a proof can become rather large (depending on the messages). To simplify such proof-of-inclusions, the `Confirmed Merkle Root` of all the confirmed messages has been added. +- Due to the layered design of blocks and payloads, it is practically not possible to prevent reattachments of _Milestone Payloads_. Hence, this payload has been designed in a way to be independent from the block it is contained in. A milestone should be considered as a virtual marker (referencing `Parents`) rather than an actual block in the Tangle. This concept is compatible with reattachments and supports a cleaner separation of the block layers. +- Forcing matching `Parents` in the _Milestone Payload_ and its _Block_ makes it impossible to reattach the same payload at different positions in the Tangle. This alone does not prevent reattachments in general (a different, valid `Nonce`, for example would lead to a new Block ID) and it violates a strict separation of payload and block. However, it simplifies milestone processing as the position of the Block will be the same as the position encoded in the Milestone Payload. Having these clear structural properties seems to be more desirable than a strict separation of layers. +- While it is always possible to cryptographically prove that a block was confirmed by a given milestone by supplying all the blocks of a path from the milestone to the block, such a proof can become rather large (depending on the blocks). To simplify such proof-of-inclusions, the `Inlcusion Merkle Root` of all the included blocks has been added. # Copyright From a577cb9ba9087c5427a542578b2b4b1228bad1e5 Mon Sep 17 00:00:00 2001 From: Levente Pap Date: Thu, 19 May 2022 15:28:07 +0200 Subject: [PATCH 11/20] Add WIP Protocol Parameteres Milestone Option --- tips/TIP-0029/tip-0029.md | 55 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 51 insertions(+), 4 deletions(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index d9cfe87ba..64e0571f8 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -188,11 +188,58 @@ The `Options` field holds additional data authenticated by the milestone. The following table lists all the `Milestone Option Type` that are currently supported as well as links to the corresponding specification: -| Payload Name | Type Value | TIP | -| ------------ | ---------- | ---------------------------------------------------------- | -| Receipt | 0 | [TIP-34](../TIP-0034/tip-0034.md#receipt-milestone-option) | +| Payload Name | Type Value | TIP | +|---------------------|------------|-------------------------------------------------------------| +| Receipt | 0 | [TIP-34](../TIP-0034/tip-0034.md#receipt-milestone-option) | +| Protocol Parameters | 1 | [TIP-29](#protocol-parameters-milestone-option) | -## Validation +#### Protocol Parameters Milestone Option + +This `Milestone Option` is used to signal to nodes the commencing of new protocol parameters, including new protocol +version or PoW difficulty. + +
+Protocol Parameters Milestone Option +
+ Defines changing protocol parameters. +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Milestone Option Typeuint8Set to value 1 to denote a Protocol Parameters Milestone Option.
Target Milestone Indexuint32The milestone index at which these protocol parameters become active.
Protocol Versionuint8The to be applied protocol version.
Parameters(uint16)ByteArrayThe protocol parameters in binary, serialized form.
+ +##### Syntactic Validation + - `length(Parameters)` must not exceed `Max Metadata Length` (defined in [TIP-22](../TIP-0022/tip-0022.md)). + +##### Semantic Validation + - TBW + +## Milestone Validation Similar to transaction validation, milestone validation has been separated into two classes. For a milestone to be valid, both of them need to be true. From 6505585b01bc72dd562b0aead04e97c0c63d4df1 Mon Sep 17 00:00:00 2001 From: Levente Pap Date: Fri, 20 May 2022 14:15:29 +0200 Subject: [PATCH 12/20] Add Protocol Version to Milestone Essence --- tips/TIP-0029/tip-0029.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 64e0571f8..b2431a34a 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -76,6 +76,11 @@ The following table describes the entirety of a _Milestone Payload_ in its seria uint32 The Unix time (seconds since Unix epoch) at which the milestone was issued. + + Protocol Version + uint8 + The protocol version of the Milestone Payload and its block. + Previous Milestone ID ByteArray[32] From 75cc4bcf9fbb9274009d6c23bfd6b6d5c50a1db9 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Thu, 7 Jul 2022 14:04:24 +0200 Subject: [PATCH 13/20] describe Protocol Parameters Milestone Option validation --- tips/TIP-0029/tip-0029.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index b2431a34a..1737c49b2 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -239,10 +239,9 @@ version or PoW difficulty. ##### Syntactic Validation - - `length(Parameters)` must not exceed `Max Metadata Length` (defined in [TIP-22](../TIP-0022/tip-0022.md)). - -##### Semantic Validation - - TBW + - `Target Milestone Index` must be greater than or euqal to `Index Number` of the milestone it is contained in. + - `Target Milestone Index` must be less than or equal to `Index Number` + 30. (This value is fixed and technically not a protocol parameter as defined in [TIP-22](../TIP-0022/tip-0022.md), as it should not be subject to protocol parameter changes induced by this option.) + - `length(Parameters)` must not exceed `Max Metadata Length`. ## Milestone Validation From 68c26e27741366b2e31cf4399fee0d78ebf43780 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Thu, 7 Jul 2022 14:05:30 +0200 Subject: [PATCH 14/20] add Metadata limit --- tips/TIP-0029/tip-0029.md | 1 + 1 file changed, 1 insertion(+) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 1737c49b2..c42d5d752 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -263,6 +263,7 @@ Syntactic validation can be checked from the _Milestone Essence_ plus the blocks - `Inlcusion Merkle Root` must match the Merkle tree hash of the IDs of all blocks in _White Flag Ordering_ (as described in TIP-2) that are newly referenced. (This always includes at least one valid milestone block with `Previous Milestone ID`.) - `Applied Merkle Root` must match the Merkle tree hash of the not-ignored state-mutating transactions that are newly referenced (see TIP-2). - `Parents` must match the `Parents` field of the encapsulating _Block_, i.e. the _Block_ that contains the _Milestone Payload_. + - `length(Metadata)` must not exceed `Max Metadata Length`. - Options: - `Milestone Option Type` must match one of the values described under [Milestone Options](#milestone-options). - The option itself must pass syntactic validation. From 13d84da29f576ddac5dae5af6b1d16622a7f1d6e Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Thu, 7 Jul 2022 14:52:08 +0200 Subject: [PATCH 15/20] Fix typo --- tips/TIP-0029/tip-0029.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index c42d5d752..ca94d7df7 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -239,7 +239,7 @@ version or PoW difficulty. ##### Syntactic Validation - - `Target Milestone Index` must be greater than or euqal to `Index Number` of the milestone it is contained in. + - `Target Milestone Index` must be greater than `Index Number` of the milestone it is contained in. - `Target Milestone Index` must be less than or equal to `Index Number` + 30. (This value is fixed and technically not a protocol parameter as defined in [TIP-22](../TIP-0022/tip-0022.md), as it should not be subject to protocol parameter changes induced by this option.) - `length(Parameters)` must not exceed `Max Metadata Length`. From f2a84e28c24a186ab809a2f9a49ed10f6cc6d61d Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Tue, 19 Jul 2022 10:27:55 +0200 Subject: [PATCH 16/20] Remove PoW option comment --- tips/TIP-0029/tip-0029.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index ca94d7df7..0c8ed2fc4 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -134,13 +134,13 @@ The following table describes the entirety of a _Milestone Payload_ in its seria Options atMostOneOfEach -
- PoW Milestone Option -
Defines dynamic changes to the PoW parameters.
-
Receipts Milestone Option
Defines UTXOs for newly migrated funds.
+
+
+ Protocol Parameters Milestone Option +
Defines dynamic changes to the protocol parameters.
From 051a20c3a0881d178ca308d12a985231901d0834 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Tue, 19 Jul 2022 19:14:18 +0200 Subject: [PATCH 17/20] remove nonce reference --- tips/TIP-0029/tip-0029.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 0c8ed2fc4..39494d49a 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -287,7 +287,7 @@ Semantic validation is defined in the context of all available blocks. # Rationale - Due to the layered design of blocks and payloads, it is practically not possible to prevent reattachments of _Milestone Payloads_. Hence, this payload has been designed in a way to be independent from the block it is contained in. A milestone should be considered as a virtual marker (referencing `Parents`) rather than an actual block in the Tangle. This concept is compatible with reattachments and supports a cleaner separation of the block layers. -- Forcing matching `Parents` in the _Milestone Payload_ and its _Block_ makes it impossible to reattach the same payload at different positions in the Tangle. This alone does not prevent reattachments in general (a different, valid `Nonce`, for example would lead to a new Block ID) and it violates a strict separation of payload and block. However, it simplifies milestone processing as the position of the Block will be the same as the position encoded in the Milestone Payload. Having these clear structural properties seems to be more desirable than a strict separation of layers. +- Forcing matching `Parents` in the _Milestone Payload_ and its block makes it impossible to reattach the same payload at different positions in the Tangle. Strictly speaking, this violates the separation of payload and block. However, it simplifies milestone processing as the position of the block will be the same as the position encoded in the Milestone Payload. Having these clear structural properties seems to be more desirable than a strict separation of layers. - While it is always possible to cryptographically prove that a block was confirmed by a given milestone by supplying all the blocks of a path from the milestone to the block, such a proof can become rather large (depending on the blocks). To simplify such proof-of-inclusions, the `Inlcusion Merkle Root` of all the included blocks has been added. # Copyright From ff05c487dc03fa4f0b4c1c4bd916d15d16668695 Mon Sep 17 00:00:00 2001 From: Levente Pap Date: Thu, 21 Jul 2022 17:36:21 +0200 Subject: [PATCH 18/20] Update tips/TIP-0029/tip-0029.md Co-authored-by: muXxer --- tips/TIP-0029/tip-0029.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 39494d49a..75688bbcd 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -255,7 +255,7 @@ Syntactic validation can be checked from the _Milestone Essence_ plus the blocks - `Index Number` must not be smaller than `First Milestone Index`. - If `Index Number` equals `First Milestone Index`, the following fields must be zeroed out: - `Previous Milestone ID` - - `Inlcusion Merkle Root` + - `Inclusion Merkle Root` - `Applied Merkle Root` - If `Index Number` is greater than `First Milestone Index`, the milestone must reference (i.e. one of the `Parents` must contain or reference) another syntactically valid milestone whose _Milestone ID_ matches `Previous Milestone ID`. With respect to that referenced milestone, the following must hold: - `Index Number` must increment by `1`. From 38355323e6f98e5247046391b98fd4d8fd471fb4 Mon Sep 17 00:00:00 2001 From: Levente Pap Date: Thu, 21 Jul 2022 17:36:28 +0200 Subject: [PATCH 19/20] Update tips/TIP-0029/tip-0029.md Co-authored-by: muXxer --- tips/TIP-0029/tip-0029.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 75688bbcd..4c1d965b6 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -288,7 +288,7 @@ Semantic validation is defined in the context of all available blocks. - Due to the layered design of blocks and payloads, it is practically not possible to prevent reattachments of _Milestone Payloads_. Hence, this payload has been designed in a way to be independent from the block it is contained in. A milestone should be considered as a virtual marker (referencing `Parents`) rather than an actual block in the Tangle. This concept is compatible with reattachments and supports a cleaner separation of the block layers. - Forcing matching `Parents` in the _Milestone Payload_ and its block makes it impossible to reattach the same payload at different positions in the Tangle. Strictly speaking, this violates the separation of payload and block. However, it simplifies milestone processing as the position of the block will be the same as the position encoded in the Milestone Payload. Having these clear structural properties seems to be more desirable than a strict separation of layers. -- While it is always possible to cryptographically prove that a block was confirmed by a given milestone by supplying all the blocks of a path from the milestone to the block, such a proof can become rather large (depending on the blocks). To simplify such proof-of-inclusions, the `Inlcusion Merkle Root` of all the included blocks has been added. +- While it is always possible to cryptographically prove that a block was confirmed by a given milestone by supplying all the blocks of a path from the milestone to the block, such a proof can become rather large (depending on the blocks). To simplify such proof-of-inclusions, the `Inclusion Merkle Root` of all the included blocks has been added. # Copyright From d2ee43984e86ab7337329081cae718baf3e306d0 Mon Sep 17 00:00:00 2001 From: Wolfgang Welz Date: Tue, 2 Aug 2022 09:47:11 +0200 Subject: [PATCH 20/20] remove leagacy IOTA reference --- tips/TIP-0029/tip-0029.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tips/TIP-0029/tip-0029.md b/tips/TIP-0029/tip-0029.md index 4c1d965b6..ca217323c 100644 --- a/tips/TIP-0029/tip-0029.md +++ b/tips/TIP-0029/tip-0029.md @@ -17,7 +17,7 @@ In IOTA, nodes use the milestones issued by the Coordinator to reach a consensus # Motivation -In order to integrate the concept of milestones consistently into Tangle blocks, this TIP describes a dedicated payload type for milestones. It contains the same essential data fields that were part of a milestone bundle in the legacy IOTA protocol. Additionally, this document also describes how Ed25519 signatures are used to assure authenticity of the issued milestones. In order to make the management and security of the used private keys easier, simple multisignature features with support for key rotation have been added. +In order to integrate the concept of milestones consistently into Tangle blocks, this TIP describes a dedicated payload type for milestones. In this context, the document also describes how Ed25519 signatures are used to assure authenticity of the issued milestones. In order to make the management and security of the used private keys easier, simple multisignature features with support for key rotation have been added. # Specification