RFC: Message PoW #24
RFC: Message PoW #24
Conversation
| The PoW score is defined as the average number of iterations required to find the number of trailing zero trits in the hash divided by the message size. | ||
|
|
||
| The PoW validation is performed in the following way: | ||
| - Compute the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash of the serialized message (as described in [Draft RFC-17](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md)) *excluding* the 8-byte `Nonce` field and convert the hash into its 192-trit `b1t6` encoding. (See [RFC-15](https://iotaledger.github.io/protocol-rfcs/0015-binary-to-ternary-encoding/0015-binary-to-ternary-encoding.html) for a description of the encoding.) |
There was a problem hiding this comment.
The RFC-17 link should be changed once #17 has been merged.
| The PoW validation is performed in the following way: | ||
| - Compute the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash of the serialized message (as described in [Draft RFC-17](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md)) *excluding* the 8-byte `Nonce` field and convert the hash into its 192-trit `b1t6` encoding. (See [RFC-15](https://iotaledger.github.io/protocol-rfcs/0015-binary-to-ternary-encoding/0015-binary-to-ternary-encoding.html) for a description of the encoding.) | ||
| - Take the 8-byte `Nonce` in little-endian representation, convert it into its 48-trit `b1t6` encoding and append it to the hash trits. | ||
| - Add a padding of three zero trits to create a 243-trit string. |
There was a problem hiding this comment.
Why not 1,0,0 like you wanted originally?
There was a problem hiding this comment.
The 10* padding (where the 1 trit is always added) was necessary in a setting where the input has arbitrary length. Here, it'll always be exactly one block, so we don't need to worry about the preimage attack vector that a 0* padding introduces in the general case.
Because of this, a 0,0,0 padding just feels more natural but 1,0,0 would certainly work, too!
| # Unresolved questions | ||
|
|
||
| - What PoW score threshold should be used to secure the network? The direct equivalent of a minimum weight magnitude (MWM) of 14 together with the current message size per transaction is a PoW score ≥ 4000. However, this parameter depends on many factors, but it can also be modified at a later stage without protocol changes. | ||
| - The PoW score formula 3<sup>#zeros</sup> / size(message) could be replaced with an alternative function to better match the network usage, e.g. in order to penalize longer message more than linearly. |
There was a problem hiding this comment.
I agree that longer messages should be penalized, but we need to make sure that they are still cheaper than just doing lots of short messages. This is because each message will have overhead in terms of space and I think replacing long messages with many short ones is something we do not want to incentivize.
So I would actually opt to have a sublinear penalization :-)
There was a problem hiding this comment.
I am not so sure about that...
Smaller message help the Tangle more, if everyone only bundles huge transactions the MPS will be very low which makes it harder for tip selection or confidence computation for example.
I think it might make most sense to deploy an initial version first and then fine-tune this in a complete node with some reasonable network traffic and use cases. After all, the score computation can be a configurable parameter that can be changed without the need to update the node software.
There was a problem hiding this comment.
I just find it odd that we are not doing much to relieve space problems besides pruning
Co-authored-by: charlesthompson3 <74603461+charlesthompson3@users.noreply.github.com>
* add RFC document * reference in each serialization RFC * Migrate to TIP-21 * Update tip-0021.md * Add length type defs to ByteArray (#24) * Add length type defs to ByteArray * Add clarification to atMostOneOfEach subschema Co-authored-by: Levente Pap <levente.pap@iota.org>
Rendered Version
Example Go implementation in wollac/iota-crypto-demo: