Official Snapshot BrightID Registry Research

Research
#1

Here’s a list of things about the v5 registry I wanna check with @castall, I’ve added my opinion in each one of them.

  1. Currently the v5 registry is deployed at https://explorer.idchain.one/address/0x375ADBa519376Bda93ebCC8a1Abbd47736E91C00/contracts
    with the following designs not finalized

  2. Should verifierToken or app be immutable?
    (1a) verifierToken should be mutable, in the event of a node becomes untrustworthy, we can issue a new verifier token and redistribute them.
    (1b) Another interesting solution would be using a verifier token with its standard modified, where the admin would have the permission to transfer tokens from another wallet without approval, thus giving the admin the ability to essentially strip the verifier token out of a faulty node’s wallet. Of course in this case the admin wallet would be a community vault, e.g. an Aragon Vault.
    (2)app on the other hand, should be immutable.

  3. What’s the use case for the map variable history?
    (1) From my understanding after studying the contract code, the variable history is essentially a list of pointers, where a user’s new eth address would point to the old one.
    (2) This variable is modified in the method verify, where when a user submit verification data for his/her eth address, they would also include their used eth address (associated with their BrightID). But if said user is dishonest and do not submit their used eth address, the old addresses will still be verified since its isVerified struct variable is still set to true.
    This is proven to be wrong after some research done on how the verification data is signed: Since the signature is generated for ALL contextIDs used by that user, if a user is dishonest about their address history, the signature would be invalid.
    I realised this right after linking another eth address to Noble to run a test, oh well, now I know what history is for.

  4. Is the current expiration implementation enough?
    (1) Right now instead of expiration, a more correct term would be “re-registeration”, since after a period is over (currently set to a month), an already verified address would stay verified until a new address is registered for the same BrightID. Meaning users don’t have to “re-register” every month, instead they are able to change their address after one month.
    (2) I’m okay with the current implementation, it suits our needs.

  5. How long should the expiration period be?
    (1) It’s currently set to one month, technically if what I wrote in 4 is correct, this period could be much shorter, since when a user changes their address, the old ones should all become unverified.

#2

Either solution you mentioned could work.

Yes

It gives apps flexibility in handling the case when users link multiple appids (contextids). In API v5, linking again creates an inescapable list of all the past ids a user has used. An app could do several things like: disqualify the user, recognize only the newest one, recognize only the first one.

In API v6, there will be no history (because of blind signatures), and a user can only link one appid until the expiration period ends, so I recommend we follow this approach.

This is how that approach looks in API v5 BrightID-SmartContract/BrightIDFaucetVerifier.sol at master · BrightID/BrightID-SmartContract · GitHub . The history is kept, but only the most recent address is used. This is how it looks in API v6. BrightID-SmartContract/BrightID.sol at master · BrightID/BrightID-SmartContract · GitHub There is no array of addresses, only one address.

Yes. That is an advantage of v5. Existing users don’t have to reregister, but they can. In v6, the advantages are: we don’t have the complexity of using a history, and we get blind signatures which prevents any leakage of BrightID <> eth address if a BrightID node is compromised. In v6, existing users must reregister

Correct. The template uses one day, which is what rarecoin wanted and it’s working fine for them.

1 Like
#3

Right, thanks for the answers :pray:. I’ll be working on a verifier token with the solution (1b) then, just so we don’t have to redistribute everytime a node is compromised.

#4

The work-in-progress version of the IDChain registration site is up at React App . At this point I’ve done what I can without input from others.

1 Gas Token Distribution

I need to discuss the gas token distribution with the BrightID people. I determined they use this contract
(https://explorer.idchain.one/address/0x6E39d7540c2ad4C18Eb29501183AFA79156e79aa/transactions) in their faucet but I’m not clear on whether or not this is something we can use or if we need to deploy our own version of this contract and fund it ourselves. For now just manually send the idchain gas tokens (EIDI) to your wallet to get past this step. I’ll reach out to them.

If you need tokens I have some that I can send you.

2 Check if Wallet Address is Sponsored

Is there an API or Smart Contract function to determine if a wallet address is already sponsored?

3 Noble BrightID QR Code url

Does anyone have the Noble brightID QR Code url? I have the one from the IDChain faucet in place right now, but I know this needs changed. Here is what I have now.

brightid://link-verification/http:%2f%2fnode.brightid.org/idchain/

4 verify() execution issues

I’m having an issue getting the ‘verify()’ smart contract function to execute successfully. Here is an example transaction I sent through.

https://explorer.idchain.one/tx/0x2b33408e938d4d6b07018de734c97a36ea209973e79fceb09ec2618db07143ad/internal-transactions

I assume I’m not calling this correctly. I’ll explain what I’m doing and hopefully I can be pointed in the right direction.

a. I query this url to get the parameters for the function.

https://app.brightid.org/node/v5/verifications/Noble/0xBCD17bC16d53D690Ba29d567E79d41d4a7049451?signed=eth&timestamp=seconds

it returns:

{"data":{"unique":true,"app":"Noble","context":"Noble","contextIds":["0xbcd17bc16d53d690ba29d567e79d41d4a7049451"],"sig":{"r":"eb44f9c7438d2bfee443363cff09795e5eadb7aacde1dedb0e9fe6f300a927e9","s":"5f47f7f8874ab0b3ced1c9b100c9af9d19260fa1db3051fbed0063e3948e9318","v":27},"timestamp":1642893795,"publicKey":"02d2e244cb1a3f0692127486bd00115717b59fcd5edac2f57dd1ca53fcebc71373"}}

b. I call verify() with the data returned from that API. In this instance the parameters were:

addrs: [
  0xbcd17bc16d53d690ba29d567e79d41d4a7049451
]

timestamp: 1642893795

v: 27

r: 0xeb44f9c7438d2bfee443363cff09795e5eadb7aacde1dedb0e9fe6f300a927e9

s: 0x5f47f7f8874ab0b3ced1c9b100c9af9d19260fa1db3051fbed0063e3948e9318
#5

I DON’T UNDERSTAND ANY OF THIS. But wow that flow looks great and difficult - which I LIKE. There needs to be this barrier to entry.

1 Like
#6
  1. Reach out to @castall or in the IDChain keybase.
  2. I think this API does it, a BrightID node won’t sign verification of a user unless they’re sponsored and verified, as stated in this doc:
    A user must be "sponsored" before your app can query their verification status.
    So as long as this query doesn’t return a correct signature, the user is not sponsored.
  3. You can generate a QR Code url using the BrightID Test App, using context Noble
  4. Your steps are correct, but the contract you used is outdated, and it’s using the snapshot context.
    I’ve deployed the final version (for now) of the snapshot registry here
    You can connect your BrightID to the snapshot context using the BrightID Test App I provided above, then query the verification using the snapshot context instead of Noble, it should work.
#7

We got your back sir!

#8

Alright, I’ve updated the app so #2, 3 and 4 are good. I was able to test the full process from start to finish (aside from claiming gas) and it looks good.

I linked a second wallet to my brightID, and tried to put a verification through for it. This was rejected, which, if I understand correctly, is the expected outcome. I believe this is what prevents people from registering multiple wallets with only one brightID account, but please correct me if I’m mistaken.

I’ll follow up with the brightID people about the gas claiming question tomorrow.

#9

Also forgot to add, the app code is in github at, https://github.com/SongADAO/songaday-idchain-registration

I’ve also uploaded the node server docker container files to, https://github.com/SongADAO/songaday-idchain-archive-node-server

#10

I did some research on linking multiple wallets to one BrightID, you should be able to register it to the contract if you provided all the addresses in an array (aka the contextIds array from the API response), and update the signature parameters (they’re changed when you link new addresses). And if you do register multiple addresses this way, only the first address will be verified. The reason that your transaction failed is because there’s a internal cooldown period, which is set to one day. I’ll deploy another testing contract (without cooldowns) for you in a bit, I’ll provide the link here with edits.

Edit: Test Contract deployed, identical code to the official contract except the cooldown period is set to 0.

#11

Ahh, ok that makes sense. I do send the contextId array that is returned so I think the code is good. It would be that cooldown period though. If you deploy the test contract I can try it out to make sure, but I believe it’s good. I’ll add an error message that explains the cooldown to the user so they understand what is happening.

Edit: just saw you posted the test contract. I’ll verify my code is good and add the error message about the cooldown tomorrow.

#12

You should be able to pull a revert message from the failed transactions, it should cover most of the failed reasons.

#13

reposting from discord:

Ran into a problem with the testing contract. The problem was that REGISTRATION_PERIOD is actually used in two places. There is the place where we want it to be set to 0 so that it can be run over and over, but there is also a place (second line of verify()) in which it is used to make sure that the timestamp parameter being passed isn’t too old. with REGISTRATION_PERIOD being set to 0 there it made it so that it was impossible for timestamp to ever be valid. I just edited the line and filled in a hardcode time or 24 hours for that line and deployed a new version of the test contract with that change.

new test contract is here, https://explorer.idchain.one/address/0x62b008b2593a175BB33FFFbe8a11a92939B5A67C/transactions

2 Likes