Getting the proof of account ownership server extension added to existing BOINC projects

[grctest]

Back in 2019 I managed to create a BOINC web server extension which introduces public proof of BOINC account ownership:

BOINC/boinc#2965

https://github.com/BOINC/boinc/wiki/ProofOfOwnership

We've not reached out to project admins to implement this server extension yet, nor have we implemented it within the Gridcoin Research client.

If we could get whitelisted projects to add this feature then we could speed up beacon registrations and also enable airdropping other tokens.

Even if we only got a couple projects to add this feature it would be beneficial in the long run.

[jamescowens]

@grctest I believe we canvassed the projects several years ago on this and received little interest. I am certainly willing to try again. We should approach them via the BOINC Discord server. We should talk to Vitalli about this first.

Reviewing the technical details of this, I think the easiest way to implement this is for the Gridcoin client to provide the verification code as the message to be signed on the BOINC side, and modify the beacon code to immediately activate beacons with a signed verification code. There is a little squishiness involving the correlation between user account, email, and cpid and you and I should discuss live.

The advantage of this approach is that it will interoperate well with the current method of changing the nickname field and allowing the scrapers to pick that up to activate the beacon.

[grctest]

Yeah, I'm not proposing we completely replace the existing system, especially if only a subset of projects end up supporting the feature; It'd probably work best as an alternative beacon wizard method for individual projects which support the server extension.

I'd imagine the steps would be as follows:

• Launch beacon wizard, select public key proof method
• Select a whitelisted project from a dropdown menu to proceed with validation (selecting the correct public key to use)
• User inputs their account id (eg pastes their profile's URL https://setiathome.berkeley.edu/show_user.php?userid=12345 -> 12345)
• User is provided a message: (multiple ideas)
  • {user id} {project_id} {Beacon_Address}
  • {user id} {project_id} {Beacon_Address} {CPID}
  • {user id} {project_id} {Beacon_Address} {side-staking address}
  • {user id} {Beacon_Address} {project_id} {hash of project public key}
• User is instructed to sign it using the server extension
• User pastes the resulting XML data back into the Gridcoin client

   <account_ownership_verification>
    <master_url>http://domain.tld/project_name/</master_url>
    <msg>`{project provided user id} {client provided user id} {project_id} {Beacon_Address} {etc...}`</msg>
    <signature>BASE64_SIGNED_MSG</signature>
  </account_ownership_verification>
  

  • Note: The user id is prepended to the input message in the server extension
• XML result is validated against the project's pubkey (validating the claim before broadcast)
  • If invalid: disable buttons to broadcast, else enable broadcast button
• Second beacon operation type is broadcast with: signed message & plaintext contents
• Beacon is accepted or rejected

From the XML result we can quickly verify:

• That the gridcoin address owns the claimed user id
• The xml result was generated by the owner of the broadcasting/beacon address
• Multiple individual account id ownerships associated with one beacon address, establishing greater proof of CPID ownership
• The message was signed by the project's private key

You're right though, it's a proof of user id ownership, so there's additional considerations:

• CPID can change over time, where as their user id is permanent (unless edited via SQL)
• By design projects are able to change their signing key pair - when this happens all previously signed user id ownership proofs for this project become invalid.
  • Whilst an indefinite proof of ownership, it can be voided unexpectedly not on a scheduled basis, the user would need to be prompted to renew their proof of account ownership.
  • If say 2000 user's beacons for WCG for example were to be invalidated at the same time due to a loss of keypair private keys due to hardware failure, then this shouldn't trigger reorgs or invalidation of past beacon operations, they should silently fail as the new public key is fetched from the project's /get_project_config.php server endpoint.
  • If 2k beacons for one project could invalidate at once, how frequently should we be checking for this scenario? Who is doing the fetching of public keys? Is each client fetching the keys, or are the oracles?
  • Should the invalidation of past beacons for a project only trigger (or be detected) once a beacon is broadcast which has a new signing key? E.g. Using this message: {user id} {Beacon_Address} {project_id} {project_public_key_hash} if there are 2k existing beacons with an old project_id and project_public_key_hash pair, then once a new pair is validated all old beacons are invalidated whilst this one new beacon validates? So that as soon as a new key is used the invalidation order is given, instead of many users querying the PHP API endpoint for a change in public key values?
• If the user has multiple projects should a single proof of id ownership grant full ownership of their CPID? Or should each project require an individual proof of id ownership?
• If an user only crunches one project, is a 'cross-project id' ownership proof pertinent? They may prefer establishing proof of a single project's ownership at a time, especially if the validation is instant (with a delay till the next superblock for inclusion).
  • If we took CPID out of the message, treating ownership proof like folding@home, then there wouldn't be any CPID 'squishiness' to worry about, and staking validators wouldn't need to worry about validating CPID ownerships, just checking strings match and that a public key handshake validates.

I don't think we'd need to involve email with this method though, they can provide the URL, we fetch the data, if they can't sign the message then that's proof they don't own the account, versus trying to craft their CPID from the email perhaps?

I suppose the question we should be asking is what message would be best signed by projects for gridcoin beacon registration? It doesn't necessarily need to involve CPIDs.

[Dave247]

Surely in all the years Gridcoin has existed it has to have earned some goodwill with at least one of the project admins?

Actually... I remember seeing the proof on ownership button in one of the accounts when I logged in just the other week to update my username when I needed to renew my beacon. Unless I'm misunderstanding something maybe some of the projects have already implemented it?

[Dave247]

Actually... I remember seeing the proof on ownership button in one of the accounts when I logged in just the other week to update my username when I needed to renew my beacon. Unless I'm misunderstanding something maybe some of the projects have already implemented it?

Forgot about this for a while, and then struggled to remember where it was that I saw it but I did find it again.

This screenshot is from Minecraft@Home, which looks to me exactly like what is described in the proof of ownership repo. Though perhaps this was already known when the project was first added to the whitelist? Either way it's a start and gives a justification to adding the functionality into the Gridcoin client.

[grctest]

Cool!

<account_ownership_verification>
<master_url>https://minecraftathome.com/minecrafthome/</master_url>
<msg>19100117 test</msg>
<signature>ih9PhdjTFHtUDlKHqCOzdjDAQi/V3Ashx6K/z8YN0PpNlRQxwGoCDetuDNQ6DggPOwKNrsdA+6x9q9olNU17ei5skE934GzKy5d1z2BXn7XfLzj/MPPmX+kmnClFQNN7oHjoh22ddg88/169go+h0Ls+RKM+zqdqMxkQGRARETKqMhAOYiQx51YmNhOiGEUD/t6HRI00Gbd3GiD5SZBBR7HSQagR9LQ/LUugrO4KgCiDJBqrpzTFCRaYMOohIRk4UBiD5I9nCe9O0Y1gl+6cbNeKox+s3UpSzAhA+07i3nagFW77QgXhiG5pQ/r+MEN+iLa4cnAN3LDhYewt7CSFWcs/HFxULOUhQjEUkBh7umsCwKSNRdikkYgQ999f053P4dWKlsHrZ/FU2BPiSu3pNpQfh620gH8tWkYP5j/7HTXlQpesaXDKmYCUUbMKnrI3a869P1WkroZGytNYTpC/2X9rg7VgUoZCGlOXrtcd0HH2RD8OLbRvqiW8qZ/roE0yUYZjTAF/LeBCD3PwNEvVJS4VEv7mbgMKgAcNadmAd4/hqyqzQn1gddFJgY7h3CC+dGRdxvy7FTJsxweiig58qfHoHi7ibsR0lwiBKgGLgaUpZcERAiHyhN4ICxc5Zo9UIWjg1NNLOW5Fx7hB9Yh63aqAUKf9Q/GTZ33vKWU/PMA=</signature>
</account_ownership_verification>

https://minecraftathome.com/minecrafthome/get_project_config.php

<account_ownership_public_key>LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlJQ0lqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FnOEFNSUlDQ2dLQ0FnRUE2Zy9BSGRvVHlvYTBuN1IxU2JKZQpNZHNEazdIOGg3TnkzRG13MTVUNjV6TGhyQ01KMlpFenBpQ2x4QXVWVUlYeXhSdjhoeVl5bW5vTTh4aUp6UDBkCi9jdlJWUm1odldodThCYmtyNWcxMWNwb04yWE9kenlsbnBSK1UrNC8yb1B5QnByZW1BbE9La3J4RXBrYUJZZWoKeWtSRExJbFFNZTZHY1ZxNkdDOUFRWURKSlo2bkxjQnBja0I3SWdIYk1JRjh6c0RvYWkxTmZ6NVhqTzBXU0I4bgp1TjBwTUZYNEtvdkxjWmVDNS9rUXlBMFpLdFB2WG1oRjN6anlXN3kwVXJXQUNld3BsNEpLZHBNekJPQW5lWitNCkZiZCt5dzVQOHNFaW5wa0M5WjR1endHclRKUkFzUVpSS041NmRKT3VxR3E0RGlxeFNocEkrZWxBb0FXQ2FGQmkKUURuUzJvbXV4Y2hHOXI0M09pWjNmK1F4eTFGaWM3ZVN5dlJ2UC8rY1U4WTJHNEp3Q3ZGNXgxZmhITEdJZ2hmdgpOMkFzOFdadmRyeHRKcWw3NHE2QkMrQzA5b2xYQUhEUWJLOEd4MVdJcEM5TVN4NFlkRnNsQnFORUdHRzlaQ0lICmM3UEsvN3BDZW9tdGw5ZlZrWW92ejN3NUxmVTFqS1Brbjl1L1A1b3lMM1h2c1dibWxpL3Bac2pTOWtYU0FLTWYKQ2NMTExUblBZdkI3WXgwOGhmZkJkRVU0VUZxWlkySWdmN1J1bGxRVU5uSllqSkljTWFJWWpPZzlMaE90eTNtSApya1F2RE9FVEJDT1NlSVBKWnJuTnNQZGN6OTVxTFMzU0lvYXJ2ZEtPYTdZTWdRSFNwUFNSSzhZdWh6eEIrbjV0CktoOEtWdCtlNkpTcXdOWFNSZ3o4NzVFQ0F3RUFBUT09Ci0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQo=</account_ownership_public_key>

Check out this webapp to test it out: https://g.co/gemini/share/61344de212cd