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

General clarifications and improvements #4

Open
ts5746 opened this issue Apr 15, 2019 · 0 comments
Open

General clarifications and improvements #4

ts5746 opened this issue Apr 15, 2019 · 0 comments
Labels
documentation Additional information or clarification required
Milestone

Comments

@ts5746
Copy link
Contributor

ts5746 commented Apr 15, 2019

Original internal issue to consider the following improvements and clarifications for the following paragraphs in the specification:
2.1 The design principles are not numbered which makes it harder to refer to.
2.6.4 At this stage of reading the protocol it is very unclear what this paragraph says. It seems as if it talks about a different layer of the system not directly relevant of the Whiteflag protocol. Makes the document confusing.
2.7 This paragraph feels as it is intended to help, but it only confuses because at this stage only the message characters are introduced, and the given examples are not understandable. Please add a human readable text what for example E01 or D10(5)X means.
4.1.3 The term ‘compression’ is not correct. I think it is clearer if the definition of the messages and the mapping to the underlying blockchain is separated. I assume that with ‘compression’ the mapping to a given blockchain is meant. Also, it assumes that the mapping for any blockchain is always the same.
4.2.1 Why is there a separate column with ‘compressed encoding’. Is the encoding different per field or just as described in 4.1.3?
4.3.1.1 n means ?
4.3.1.1 _ means +/- ?
5.1.1 This seems to imply that multisig / deterministic addresses can’t be used. However, no requirements on the used addresses are mentioned.
5.1.1 The sequence A(0), message X, A(1) means that message X in fact should be ignored because A(1) recalls the original A(0) as if it never happens?

@ts5746 ts5746 added this to the v1-draft.7 milestone Apr 15, 2019
@ts5746 ts5746 added the documentation Additional information or clarification required label Apr 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Additional information or clarification required
Projects
None yet
Development

No branches or pull requests

1 participant