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

inconsistent representation of commitment ATX and node ID #163

Open
poszu opened this issue Jul 3, 2023 · 5 comments · May be fixed by #211
Open

inconsistent representation of commitment ATX and node ID #163

poszu opened this issue Jul 3, 2023 · 5 comments · May be fixed by #211
Assignees

Comments

@poszu
Copy link
Collaborator

poszu commented Jul 3, 2023

Problem statement

Node ID and commitment ATX ID are formatted in base64 both in postdata_metadata.json and in post-rs CLI initializer. However, postcli accepts them in hex. They are also formatted in hex when logged in go-spacemesh. It is inconsistent and causes extra work to convert.

DoD

We should format ATXes in the same way everywhere (either hex or base64 - this is to decide).

@poszu poszu self-assigned this Jul 3, 2023
@poszu poszu changed the title inconsistent represantation of commitment ATX and node ID in postcli inconsistent represantation of commitment ATX and node ID Jul 3, 2023
@lrettig lrettig changed the title inconsistent represantation of commitment ATX and node ID inconsistent representation of commitment ATX and node ID Jul 27, 2023
@lrettig
Copy link
Member

lrettig commented Jul 27, 2023

The node ID is stored in hex in key.bin and base64 in postdata_metadata.json. This is really confusing and frustrating.

@fasmat
Copy link
Member

fasmat commented Jul 28, 2023

The node ID is stored in hex in key.bin and base64 in postdata_metadata.json. This is really confusing and frustrating.

key.bin contains the private key hex-encoded. postdata_metadata.json contains the NodeID (public key) in base64.

@lrettig
Copy link
Member

lrettig commented Jul 28, 2023

Right. IMHO they should both be in hex :) (The private key includes the public key so at least this way you can do pattern-matching.)

@fasmat fasmat self-assigned this Jul 28, 2023
@fasmat
Copy link
Member

fasmat commented Jul 28, 2023

I also responded in this comment: #203 (comment)

Updating this is more involved than it initially appears. We need a migration plan such that existing PoSTs are updated from the current schema to the new one. This is btw. true for any file layout we want to change and is probably worth documenting a general approach for as a cross cutting concern 🙂

@fasmat
Copy link
Member

fasmat commented Jul 28, 2023

We already had that issue come up in that some PoSTs have a NonceValue in their metadata and some not: #202

Thankfully there was an easy migration path that allowed to just add the value if not already present.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋 Backlog
Development

Successfully merging a pull request may close this issue.

3 participants