Skip to content
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

Merged
merged 33 commits into from
Oct 27, 2021

Conversation

jakubcech
Copy link
Contributor

@jakubcech jakubcech commented Jul 28, 2020

karimodm and others added 9 commits October 19, 2020 09:41
* 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>
text/0019-milestone-payload/0019-milestone-payload.md Outdated Show resolved Hide resolved
text/0019-milestone-payload/0019-milestone-payload.md Outdated Show resolved Hide resolved

# 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.
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor

@charlesthompson3 charlesthompson3 left a 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!

text/0019-milestone-payload/0019-milestone-payload.md Outdated Show resolved Hide resolved
text/0019-milestone-payload/0019-milestone-payload.md Outdated Show resolved Hide resolved
text/0019-milestone-payload/0019-milestone-payload.md Outdated Show resolved Hide resolved
@Wollac Wollac requested a review from capossele January 6, 2021 13:52
@Wollac
Copy link
Contributor

Wollac commented Jan 6, 2021

@capossele since I am not sure how much of your original proposal is left, I've just requested a quick review from you 😅

@Wollac Wollac merged commit 2a579e0 into iotaledger:master Oct 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants