-
Notifications
You must be signed in to change notification settings - Fork 54
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: Milestone Payload #19
RFC: Milestone Payload #19
Conversation
* Multiple signature RFC extension * We are going for multisignature; we are going for Ed25519 * Fix typos, explain signature provider role better * Validation also needs to be numbered list * Reccomended key rotation frequency * Quorum rephrasing * Use <> for composite types
Co-authored-by: Thibault Martinez <thibault.martinez.30@gmail.com>
|
||
# Unresolved questions | ||
|
||
- Forcing matching `Parent1`, `Parent2` in the _Milestone Payload_ and its _Message_ makes it impossible to reattach the same payload at different positions in the Tangle. While this does not prevent reattachments in general (a different, valid `Nonce`, for example would lead to a new Message ID), this still simplifies milestone processing. However, it violates a clean separation of payload and message. As such, it might still be desirable to slightly complicate the milestone processing in order to allow any reattachments of _Milestone Payloads_ by not validating the parents. |
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.
"in order to allow"?
we must not allow reattachments
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.
It seems to be practically infeasible/impossible to completely prevent reattachments. As such, it is much easier and cleaner to consider the Milestone as a "virtual marker" located at the corresponding position than an actual message location. I've adapted the RFC to clarify this aspect.
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 minor edits for clarity within the content; please let me know if you have any questions / concerns about the suggestions!
@capossele since I am not sure how much of your original proposal is left, I've just requested a quick review from you 😅 |
Co-authored-by: Thibault Martinez <thibault.martinez.30@gmail.com>
add validation rules
Rendered Version
Author: @capossele