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

Define the builder signing API in to include a signing domain and fork version etc. #29

Closed
metachris opened this issue May 12, 2022 · 1 comment · Fixed by #33
Closed

Define the builder signing API in to include a signing domain and fork version etc. #29

metachris opened this issue May 12, 2022 · 1 comment · Fixed by #33

Comments

@metachris
Copy link
Contributor

from @protolambda:

Define the signing API in a way where you are forced to include a signing domain and fork version etc.

Signatures should be constructed in a way where they are unique for the purpose of the work and version of the protocol. See compute_signing_root and get_domain in the phase0 beacon spec.

You essentially want to compute a "domain" (32 bytes) from a fork digest (constructed from genesis + fork info) and a type-domain (e.g. proposals and attestations have different domains to be sure they never have the same signature for two different intents). Or you can implement your own non-standard domain method. But definitely don't just create a BLS signature over data that might have a different meaning later on in the protocol. cc @lightclient

Originally posted by @protolambda in #28 (comment)

See also ethereum/consensus-specs#2884 for the DomainType
@metachris metachris changed the title It would be much better to define the signing API in a way where you are forced to include a signing domain and fork version etc. Signatures should be constructed in a way where they are unique for the purpose of the work and version of the protocol. See compute_signing_root and get_domain in the phase0 beacon spec. You essentially want to compute a "domain" (32 bytes) from a fork digest (constructed from genesis + fork info) and a type-domain (e.g. proposals and attestations have different domains to be sure they never have the same signature for two different intents). Or you can implement your own non-standard domain method. But definitely don't just create a BLS signature over data that might have a different meaning later on in the protocol. cc @lightclient Define the signing API in to include a signing domain and fork version etc. May 12, 2022
@metachris metachris changed the title Define the signing API in to include a signing domain and fork version etc. Define the builder signing API in to include a signing domain and fork version etc. May 12, 2022
@metachris metachris mentioned this issue May 12, 2022
Merged
@metachris
Copy link
Contributor Author

Related code in Prysm: https://github.com/prysmaticlabs/prysm/tree/develop/beacon-chain/core/signing

@lightclient lightclient mentioned this issue May 16, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Adds "domain" to signing logic lightclient/mergemock
1 participant
@metachris