From b2b23467bb5f188464b28cd5708b165af3bc95d4 Mon Sep 17 00:00:00 2001 From: Stefano Della Valle Date: Tue, 13 Sep 2022 18:48:16 +0200 Subject: [PATCH 1/5] Create Generic Signed Payload As quickly discussed, I'm happy to submit this very simple TIP that will allow to build a standard Selective Permanode INX plug-in --- Generic Signed Payload | 62 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Generic Signed Payload diff --git a/Generic Signed Payload b/Generic Signed Payload new file mode 100644 index 000000000..f6c447542 --- /dev/null +++ b/Generic Signed Payload @@ -0,0 +1,62 @@ +--- +tip: +title: +description: +author: +discussions-to: +status: Draft +type: +layer (*only required for Standards Track): +created: <2022-9-13> +requires (*optional): +replaces (*optional): +superseded-by (*optional): +--- + +## Abstract +Many applications that generate and publish data can benefit from the IOTA network as a transport layer. The STREAM protocol/library is designed to fulfill this purpose, ensuring that the sender is identified and thus that messages containing false data cannot be created. +However, for many low-cost applications STREAM can be too expensive and complex while writing data into the generic payload of a Tange Message (TIP-6) is very simple. + +In addition the pruning of the tangle performed by the nodes make the message reception unreliable. + +The solution is to create a simple INX plug-in for the node that can filter messages received by the node based on their tag and store them in a local database and then provide them to the user on demand. + +Obviously, the user will have to worry about deleting superfluous messages from this database and providing the node with sufficient storage space. +To confirm that the messages that are stored are correct and real, the node also calculates and stores a Proof of Inclusion for each message. + +This approach can also be used for other purposes, however, it is subject to a simple attack: the tag, the only element that can be used to distinguish messages without getting into the paylod, can be arbirally compiled, so a malicious publisher can create fake messages that the receiver cannot recognize. + + +## Motivation + +To support low-cost applications we need to create a selective permanode inx plug-in, and to make it reliable we need a standard method for identifying fake messages. + +This TIP is intended to define a message format that can be recognized as true or false by a standard method. + + +## Specification + +Detailed design + +The following describes the standard method for creating a generic message containing data whose validity can be verified by the receiver. + +The structure of the message is described here: https://github.com/iotaledger/tips/blob/main/tips/TIP-0006/tip-0006.md#indexation-payload + +The date field must contain: +- Public key +- Signature field of the following data field +- Data field (type: ByteArray) + + +## Rationale +This is a very simple soltution to allow to build selective permanodes and basic application that share data over the tangle with enough reliability. + +## Backwards Compatibility +Not relevant + +## Test Cases +The test case is the implementation of the INX Selective Permanode + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 75dd17d300bbe83925ac9d0014412e4542b90c9e Mon Sep 17 00:00:00 2001 From: Stefano Della Valle Date: Thu, 15 Sep 2022 09:24:58 +0200 Subject: [PATCH 2/5] Update Generic Signed Payload --- Generic Signed Payload | 58 ++++++++++++++++++++++++++++++------------ 1 file changed, 42 insertions(+), 16 deletions(-) diff --git a/Generic Signed Payload b/Generic Signed Payload index f6c447542..604b9aa3b 100644 --- a/Generic Signed Payload +++ b/Generic Signed Payload @@ -14,38 +14,64 @@ superseded-by (*optional): --- ## Abstract -Many applications that generate and publish data can benefit from the IOTA network as a transport layer. The STREAM protocol/library is designed to fulfill this purpose, ensuring that the sender is identified and thus that messages containing false data cannot be created. -However, for many low-cost applications STREAM can be too expensive and complex while writing data into the generic payload of a Tange Message (TIP-6) is very simple. +Many applications that generate and publish data can benefit from the IOTA network as a transport layer. The STREAM protocol/library is designed to fulfill this purpose, ensuring that the sender is identified and thus that blocks containing false data cannot be created. +However, for many low-cost applications STREAM can be too expensive and complex while writing data into the generic Tagged Data Payload (TIP-23) is very simple. -In addition the pruning of the tangle performed by the nodes make the message reception unreliable. +In addition the pruning of the tangle performed by the nodes make the blocks reception unreliable. -The solution is to create a simple INX plug-in for the node that can filter messages received by the node based on their tag and store them in a local database and then provide them to the user on demand. +The solution is to create a simple INX plug-in for the node that can filter blocks received by the node based on their tag and store them in a local database and then provide them to the user on demand. -Obviously, the user will have to worry about deleting superfluous messages from this database and providing the node with sufficient storage space. -To confirm that the messages that are stored are correct and real, the node also calculates and stores a Proof of Inclusion for each message. +Obviously, the user will have to worry about deleting superfluous blocks from this database and providing the node with sufficient storage space. +To confirm that the blocks that are stored are correct and real, the node also calculates and stores a Proof of Inclusion for each blocks. -This approach can also be used for other purposes, however, it is subject to a simple attack: the tag, the only element that can be used to distinguish messages without getting into the paylod, can be arbirally compiled, so a malicious publisher can create fake messages that the receiver cannot recognize. +This approach can also be used for other purposes, however, it is subject to a simple attack: the tag, the only element that can be used to distinguish blocks without getting into the paylod, can be arbirally compiled, so a malicious publisher can create fake messages that the receiver cannot recognize. ## Motivation -To support low-cost applications we need to create a selective permanode inx plug-in, and to make it reliable we need a standard method for identifying fake messages. +To support low-cost applications we need to create a selective permanode inx plug-in, and to make it reliable we need a standard method for identifying fake blocks. -This TIP is intended to define a message format that can be recognized as true or false by a standard method. +This TIP is intended to define a block payload format that can be recognized as true or false by a standard method. ## Specification Detailed design -The following describes the standard method for creating a generic message containing data whose validity can be verified by the receiver. -The structure of the message is described here: https://github.com/iotaledger/tips/blob/main/tips/TIP-0006/tip-0006.md#indexation-payload - -The date field must contain: -- Public key -- Signature field of the following data field -- Data field (type: ByteArray) +Serialized Layout + +The following describes the standard method for creating a generic bloack containing data whose validity can be verified by the receiver. + +The following table describes the serialization of Data field of a Tagged Data Payload described here: https://github.com/iotaledger/tips/blob/main/tips/TIP-0023/tip-0023.md + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameTypeDescription
Public Keyuint32ED25519 Public key
ED25519 Signature(uint8)ByteArrayED25519 Signature of the Data.
Data(uint32)ByteArrayBinary data. A leading uint32 denotes its length.
## Rationale From b16399c620c392f23e703f4b7ec7cef1f770c583 Mon Sep 17 00:00:00 2001 From: Stefano Della Valle Date: Thu, 15 Sep 2022 09:26:06 +0200 Subject: [PATCH 3/5] Update Generic Signed Payload --- Generic Signed Payload | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Generic Signed Payload b/Generic Signed Payload index 604b9aa3b..6ce286c6d 100644 --- a/Generic Signed Payload +++ b/Generic Signed Payload @@ -45,6 +45,13 @@ The following describes the standard method for creating a generic bloack contai The following table describes the serialization of Data field of a Tagged Data Payload described here: https://github.com/iotaledger/tips/blob/main/tips/TIP-0023/tip-0023.md +| Name | Type | Description | +|--------------|-------------------|----------------------------------------------------------| +| Payload Type | uint32 | Set to *value 5* to denote an _Tagged Data Payload_. | +| Tag | (uint8)ByteArray | The tag of the data. A leading uint8 denotes its length. | +| Data | (uint32)ByteArray | Binary data. A leading uint32 denotes its length. | + + From 785ee231783130ac817366e45b1f0e7b4953fc40 Mon Sep 17 00:00:00 2001 From: Stefano Della Valle Date: Thu, 15 Sep 2022 09:46:03 +0200 Subject: [PATCH 4/5] Update Generic Signed Payload Updated. Changed the previous approach to propose the creation of a new payload type. --- Generic Signed Payload | 60 +++++++----------------------------------- 1 file changed, 10 insertions(+), 50 deletions(-) diff --git a/Generic Signed Payload b/Generic Signed Payload index 6ce286c6d..454e7d096 100644 --- a/Generic Signed Payload +++ b/Generic Signed Payload @@ -14,18 +14,8 @@ superseded-by (*optional): --- ## Abstract -Many applications that generate and publish data can benefit from the IOTA network as a transport layer. The STREAM protocol/library is designed to fulfill this purpose, ensuring that the sender is identified and thus that blocks containing false data cannot be created. -However, for many low-cost applications STREAM can be too expensive and complex while writing data into the generic Tagged Data Payload (TIP-23) is very simple. - -In addition the pruning of the tangle performed by the nodes make the blocks reception unreliable. - -The solution is to create a simple INX plug-in for the node that can filter blocks received by the node based on their tag and store them in a local database and then provide them to the user on demand. - -Obviously, the user will have to worry about deleting superfluous blocks from this database and providing the node with sufficient storage space. -To confirm that the blocks that are stored are correct and real, the node also calculates and stores a Proof of Inclusion for each blocks. - -This approach can also be used for other purposes, however, it is subject to a simple attack: the tag, the only element that can be used to distinguish blocks without getting into the paylod, can be arbirally compiled, so a malicious publisher can create fake messages that the receiver cannot recognize. +The payload concept offers a very flexible way to combine and encapsulate information in the IOTA protocol. This document proposes a basic singed payload type that allows the addition of arbitrary signed data. ## Motivation @@ -38,48 +28,18 @@ This TIP is intended to define a block payload format that can be recognized as Detailed design - Serialized Layout -The following describes the standard method for creating a generic bloack containing data whose validity can be verified by the receiver. - -The following table describes the serialization of Data field of a Tagged Data Payload described here: https://github.com/iotaledger/tips/blob/main/tips/TIP-0023/tip-0023.md - -| Name | Type | Description | -|--------------|-------------------|----------------------------------------------------------| -| Payload Type | uint32 | Set to *value 5* to denote an _Tagged Data Payload_. | -| Tag | (uint8)ByteArray | The tag of the data. A leading uint8 denotes its length. | -| Data | (uint32)ByteArray | Binary data. A leading uint32 denotes its length. | - - - -
- - - - - - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
Public Keyuint32ED25519 Public key
ED25519 Signature(uint8)ByteArrayED25519 Signature of the Data.
Data(uint32)ByteArrayBinary data. A leading uint32 denotes its length.
+The following table describes the serialization of Data field of a _Singed Data Payload_ following the notation from [TIP-21](../TIP-0021/tip-0021.md): + +| Name | Type | Description | +|--------------|-------------------|-------------------------------------------------------------------------------------------| +| Payload Type | uint32 | Set to *value 6* to denote an _Signed Data Payload_. | +| Public key | ByteArray[32] | The public key of the Ed25519 keypair which is used to verify the correspondig signature. | +| Singature | ByteArray[64] | Ed25519 signature signing the BLAKE2b-256 hash of the Data | +| Data | (uint32)ByteArray | Binary data. A leading uint32 denotes its length. | +It is important to note that `Public key` and `Signature` are not considered by the protocol, they just serves as a marker for second layer applications. ## Rationale This is a very simple soltution to allow to build selective permanodes and basic application that share data over the tangle with enough reliability. From f5148efc85546d23f220d155aec2a86cc63e9aec Mon Sep 17 00:00:00 2001 From: Stefano Della Valle Date: Thu, 15 Sep 2022 09:55:39 +0200 Subject: [PATCH 5/5] Add the Tag Added the tag field to allow the data producer to specify different data Tags for different application meaning. --- Generic Signed Payload | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/Generic Signed Payload b/Generic Signed Payload index 454e7d096..6932ec861 100644 --- a/Generic Signed Payload +++ b/Generic Signed Payload @@ -1,6 +1,6 @@ --- tip: -title: +title: description: author: discussions-to: @@ -30,16 +30,23 @@ Detailed design Serialized Layout -The following table describes the serialization of Data field of a _Singed Data Payload_ following the notation from [TIP-21](../TIP-0021/tip-0021.md): +The following table describes the serialization of Data field of a _Singed Tagged Data Payload_ following the notation from [TIP-21](../TIP-0021/tip-0021.md): | Name | Type | Description | |--------------|-------------------|-------------------------------------------------------------------------------------------| | Payload Type | uint32 | Set to *value 6* to denote an _Signed Data Payload_. | +| Tag | (uint8)ByteArray | The tag of the data. A leading uint8 denotes its length. | | Public key | ByteArray[32] | The public key of the Ed25519 keypair which is used to verify the correspondig signature. | | Singature | ByteArray[64] | Ed25519 signature signing the BLAKE2b-256 hash of the Data | | Data | (uint32)ByteArray | Binary data. A leading uint32 denotes its length. | -It is important to note that `Public key` and `Signature` are not considered by the protocol, they just serves as a marker for second layer applications. +It is important to note that `Tag`, `Public key` and `Signature` are not considered by the protocol, they just serves as a marker for second layer applications. + +## Syntactic Validation + +- `length(Tag)` must not be larger than [`Max Tag Length`](../TIP-0022/tip-0022.md). +- Given the type and length information, the _Singed Tagged Data Payload_ must consume the entire byte array of the `Payload` field of the encapsulating object. + ## Rationale This is a very simple soltution to allow to build selective permanodes and basic application that share data over the tangle with enough reliability.