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.

Sign up for GitHub

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

Jump to bottom

correct magic bytes values in readme #2

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

correct magic bytes values in readme #2

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7d7798c
correct magic bytes values in readme
nicolasochem Apr 5, 2023
96e4e00
Update README.md
nicolasochem Apr 14, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ Note that we have only tested it on [AWS CloudHSM](https://aws.amazon.com/cloudh

Please note that this software does not provide any authentication or authorization. You will need to take care of that yourself. It simply returns the signature for valid payloads, after performing some checks:
* Is the message a valid payload?
* Does the message begin with a 0x01 or 0x02? Indicating it is a baking or endorsement, rather than a 0x03 transfer.
* Does the message begin with a 0x11, 0x12 or 0x13? Indicating it is a baking or endorsement, rather than a 0x03 transfer.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0x03 could also be votes now and not just transfers. The signer checks for that:

tezos-kms-signer/src/sigreq.py

Lines 36 to 53 in 926601f

elif self.data[0] == 0x03: # Operation, for now, we only do ballots
self.chainid = None
self.type = "Unknown operation"
self.blockhash = self.data[1:32] # The block hash
if self.data[33] == 0x06: # 0x06 is a ballot
self.pkh_type = self.data[34] # Public Key Hash type
self.pkh = self.data[35:55] # Public Key Hash
self.period = self.data[55:59]
self.proposal = self.data[59:91]
if self.data[91] == 0x00:
self.type = "Ballot"
self.vote = "yay"
elif self.data[91] == 0x01:
self.type = "Ballot"
self.vote = "nay"
elif self.data[91] == 0x02:
self.type = "Ballot"
self.vote = "pass"

Also maybe add

Suggested change
* Does the message begin with a 0x11, 0x12 or 0x13? Indicating it is a baking or endorsement, rather than a 0x03 transfer.
* Does the message begin with a 0x11, 0x12 or 0x13? Indicating it is a baking, preendorsement, or endorsement, rather than a 0x03 transfer.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually we should forbid any 0x03 operation. With a consensus key baker, you vote with the baker key, not the consensus key.

Copy link

@harryttd harryttd Apr 16, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's assuming all users would use a consensus key. But i don't think we need to restrict them to that. As far as i can tell, there is no issue with allowing votes. If we keep the voting we should add in that voting ops are accepted.

* Is the message within a certain threshold of the head of the chain? Ensures you are signing valid blocks.
* For baking signatures, is the block height of the payload greater than the current block height? This prevents double baking.

Expand Down