-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not 1,0,0 like you wanted originally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just find it odd that we are not doing much to relieve space problems besides pruning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are some very minor edits to the content; otherwise, it reads all good! Let me know if you have any questions about the suggestions.
-Charles
Co-authored-by: charlesthompson3 <74603461+charlesthompson3@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still need to come to an agreement if we should raise PoW difficulty more than linearly according to the message length; for the other unresolved question we decided not to withhold approval on just parameters. Besides these, it looks good!
* 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: