The long awaited Double Signing spec #33
Conversation
| @@ -0,0 +1,126 @@ | |||
| # Contribution Signing | |||
|
|
|||
| In order to verify that contributions listed in the `transcript.json` are actually generated by the addresses listed in the transcript, the contributors MAY sign their contribution with their Ethereum address that they logged in with. And in turn, the secret contributed to the ceremony can be used as a BLS private key which can then sign the participant's Ethereum address or their GitHub name. | |||
There was a problem hiding this comment.
Ack, this MAY is important because it means that you do not need to do the double signing procedure. If you want to build your participant code just like how you would build it for a regular ceremony then it is still possible
There was a problem hiding this comment.
Yup, definitely an optional feature. Debated MAY vs SHOULD, is this OPTIONAL or RECOMMENDED?
|
|
||
| ### `message` | ||
|
|
||
| `message` contains the string-hex (including leading `0x`) encoded PoT-Pubkeys taken from [contribution.md](../contribution/contribution.md). These are `bls.G2Point`s corresponding to the setups for each of the numbers of powers. Thus, an example `message` corresponding with {`1`, `1`, `1`, `1`} (note this is just for demonstration purposes, these specs REQUIRE the secrets to be different) as secrets would be: |
There was a problem hiding this comment.
"these specs REQUIRE the secrets to be different"
Just to add some notes: The sequencer checks this when they receive a contribution. Note, that they do not check whether the secret is distinct amongst all contributions (which is fine)
This means that a user can contribute once with secret (a,b,c,d) since (a,b,c,d) are all distinct, it will be accepted.
The user can then contribute again with (a,b,c,d) and it will be accepted.
There was a problem hiding this comment.
Yes, this is permissible behavior as it is a specific case of the more general making-your-keys-algebraically-related subcategory which we cannot detect. This is a part of our honesty assumption.
The simple check we do do is to prevent faulty (but honest) contributions.
| def github_handle_to_identity(github_handle: str) -> str: | ||
| # Note that GitHub handles are limited to 39 alpha-numeric chars | ||
| # (Regex: /^[a-z\d](?:[a-z\d]|-(?=[a-z\d])){0,38}$/i) | ||
| assert github_handle[1] == '@' # GitHub handles must start with '@'. |
There was a problem hiding this comment.
Github handles are mutable, so we could use the github account ID instead or both?
You can see your own account ID by going to here for example: http://caius.github.io/github_id
Why this may be a problem:
- I use the github username :
kevaundraynow - Five years in the future, I change it to
kevaundray1 - Someone else changes their username to
kevaundray
There was a problem hiding this comment.
Yeah, I agree that this is a problem. We cannot rely on GitHub handles as they are not immutable. (I myself have changed from av80r to CarlBeek.)
I implemented IDs in b50deec
Now the identity string includes both so as to be both human-readable and tied to a user, not ID. Now the infamous kevaundray example looks like git|12530043|@kevaundray.
This PR adds the notion of "double signing" to contribution and the transcript (as discussed in #1). The idea is that we can add further verifiability to the ceremony by being able to cryptographically check who added which contribution.
This PR adds two signatures:
identity(which looks something likegit|@carlbeekoreth|0xd334741d0766b257b18f2d058e844e17e346a0c1. Note: this does not change the cryptographic assumptions of the setup as we still rely on precisely the same curve and paring assumptions.