HackMD
  • Prime
    Prime  Full-text search on all paid plans
    Search anywhere and reach everything in a Workspace with Prime plan.
    Got it
      • Create new note
      • Create a note from template
    • Prime  Full-text search on all paid plans
      Prime  Full-text search on all paid plans
      Search anywhere and reach everything in a Workspace with Prime plan.
      Got it
      • Options
      • Versions and GitHub Sync
      • Transfer ownership
      • Delete this note
      • Template
      • Save as template
      • Insert from template
      • Export
      • Dropbox
      • Google Drive
      • Gist
      • Import
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
      • Download
      • Markdown
      • HTML
      • Raw HTML
      • Sharing Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Note Permission
      • Read
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • Write
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • More (Comment, Invitee)
      • Publishing
        Everyone on the web can find and read all notes of this public team.
        After the note is published, everyone on the web can find and read this note.
        See all published notes on profile page.
      • Commenting Enable
        Disabled Forbidden Owners Signed-in users Everyone
      • Permission
        • Forbidden
        • Owners
        • Signed-in users
        • Everyone
      • Invitee
      • No invitee
    Menu Sharing Create Help
    Create Create new note Create a note from template
    Menu
    Options
    Versions and GitHub Sync Transfer ownership Delete this note
    Export
    Dropbox Google Drive Gist
    Import
    Dropbox Google Drive Gist Clipboard
    Download
    Markdown HTML Raw HTML
    Back
    Sharing
    Sharing Link copied
    /edit
    View mode
    • Edit mode
    • View mode
    • Book mode
    • Slide mode
    Edit mode View mode Book mode Slide mode
    Note Permission
    Read
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    Write
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    More (Comment, Invitee)
    Publishing
    Everyone on the web can find and read all notes of this public team.
    After the note is published, everyone on the web can find and read this note.
    See all published notes on profile page.
    More (Comment, Invitee)
    Commenting Enable
    Disabled Forbidden Owners Signed-in users Everyone
    Permission
    Owners
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Invitee
    No invitee
       owned this note    owned this note      
    Published Linked with GitHub
    Like BookmarkBookmarked
    Subscribed
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    Subscribe
    # A verifiable time constrained mechanism for Proof of Humanity renewals > NOTE 1: I am not an expert in blockchain technology, nor in cryptographic security. All the ideas described on this post are from what I have been learning from a Senior Programmer perspective. Feel free to double check and send any corrections that might need fixing. > > NOTE 2: I will refer by Human(s) as the submitter of the evidence (whether its in the registration or the renewal process) Proof of Humanity is slowly proving to be the solution for a sybil-resistant Identity protocol. I also believe that it solves the task that most governments fail of giving an Identity, which is a human right. One task that has been tabled for months as the project moved forward, is the mechanism for renewing profiles. There is yet not a well defined framework about how this process should be. On this post I intend to propose such mechanism to achieve this in a frictionless UX for Humans and Curators. The proposal includes definitions on what counts as a valid renewal submission for Curators and Jurors, and some UI changes to align with this guidelines. Before diving into the proposal, we need to better understand what we are trying to solve, and there are some ongoing discussions around several topics that need to be taken into consideration for a good mechanism; some are related to the Humans, some on the Curators/Challengers but in the end, *it's all about user experience on both ends*. ## What makes a good renewal process? After several discussions with the community, some of the topics that need to be taken into consideration for achieving consensus on this matter are the following: ### 1. The human on the renewal video should be the same as the one on the registration video It should be a no brainer that one of the most obvious things that the Curators should verify, is that the human on the renewal video is the same as the one on the registration submission. If this is not defined anywhere, it SHOULD be. ### 2. The phrase that should be said on the new renewal video Achieving consensus on a single phrase should be relatively easy to define and can be further discussed. Some suggested phrases can be seen on [this HIP-32](https://gov.proofofhumanity.id/t/phase-2-hip-32-define-text-to-be-read-for-profile-renewal/1157). Most of them make sense and its a matter for voting on a single one (or maybe even allow for multiple). > *As a side note, not related to this post: Besides the proposals in english, there is [this HIP](https://gov.proofofhumanity.id/t/phase-1-hip-xx-use-an-auxiliary-neutral-language-for-the-registration-statements/1159/12) related to using an alternate neutral language such as Esperanto* ### 3. Enforce a verifiable and auditable Evidence on the time that the video was recorded The video recording is currently the best evidence that a human uses to produce a valid registration and, their renewal. > *This is what this post is all about and will tries to solve for.* Failure on implementing the right solution for this problem could allow for bad actors to take advantage. > One possible attack could be a case where a bad-actor records multiple videos of the same person at the same time, and then renew the registration, by using a different video every time, *even if the human on the video has passed*. ### 4. Curators/Challengers should have an easy way of verifying a renewal The way Proof of Humanity deals with fake profiles is through "Curators" or "Challengers". Anyone can participate on the task of curating the registry. To do so, a Curator mines the entire registry looking for invalid profiles. Invalid meaning: The registration doesn't follow the rules established by the DAO to be considered a legitimate registration, or includes some issues to be considered an invalid one. For these Curators, the task is not easy, and the process of validating a profile should be as frictionless as possible. ### 5. Renewal process should be as similar as possible to the registration process (or easier if possible) We've all been there. We've all put our ETH deposit to register the first time on Proof of Humanity, scared of losing our deposit. To reduce friction,we should make the process of renewing a profile, as similar as possible to the registration, so that registrants know what to expect from the process, and how to act (since they've had a first experience with it). *It is not the objective of this post to expand on this, but I think some improvement can and should be done on this* ## The proposal This post is not meant to be taken as an HIP (*feel free to use as reference if it makes sense*), but rather as an explanation on a possible mechanism that could solves [3 of the 5 definitions stated above](https://hackmd.io/XVzQ5rFMRJWH4W1lIa1Z0Q?both#What-makes-a-good-renewal-process): - [3. Enforce a verifiable and auditable Evidence on the time the video was recorded](https://hackmd.io/XVzQ5rFMRJWH4W1lIa1Z0Q?both#3-Enforce-a-verifiable-and-auditable-Evidence-on-the-time-the-video-was-recorded) - [4. Curators/Challengers should have an easy way of verifying a renewal](https://hackmd.io/XVzQ5rFMRJWH4W1lIa1Z0Q?both#4-CuratorsChallengers-should-have-an-easy-way-of-verifying-a-renewal) - [5. Renewal process should be as similar as possible to the registration process](https://hackmd.io/XVzQ5rFMRJWH4W1lIa1Z0Q?both#5-Renewal-process-should-be-as-similar-as-possible-to-the-registration-process-or-easier-if-possible) ## Cryptographic security The underlying technology on which Proof of Humanity is built, a decentralized blockchain, has enough cryptographic mecanisms that can be securely used to generate auditable evidence. We can take advantage of those mechanisms to play in our favor (our: us, humans). ## The Validation Block To make things short, the easiest way to do time validations with blockchain technology is by making use of the blocks' timestamps. Each block on the blockchain is created at a specific point in time, and that time gets registered on the blockchain. This means that we can figure out at what time a specific block was created, just by fetching the block header (reading from the blockchain contract is gasless). > The block header contains specific structured information about each block INCLUDING the time it was created (See Block Header section on [this post](https://medium.com/coinmonks/ethereum-under-the-hood-part-7-blocks-c8a5f57cc356)). To refer to a block, we will use its ID which is a unique value representing the block on the blockchain. I will refer to this as the "**Validation Block**" or "**VB**" 🙂 ## Building a cryptographic evidence for a moment in time We need to make sure that a vide was recorder at most at a specific moment in time, but that "moment" needs to be correctly defined. We will call it **video expiration date**. **Video expiration date** is calculated from the moment that the validation block was generated, plus a time window. Consensus should be reach on what the right time window should be. This is a key item since [it could impact on the security of the registry](https://hackmd.io/XVzQ5rFMRJWH4W1lIa1Z0Q?both#3-Enforce-a-verifiable-and-auditable-Evidence-on-the-time-the-video-was-recorded). I will refer to this as "**Time Window**" or "**TW**" ⏳🪟 ### Renewal Video When recording a registration video, we are required to show a sign with our wallet's address (screen or paper). If we asked the humans to do the same video, but now, besides displaying the address, to write down and display the ID of the Validation Block, we would impact on the UX for the Human by adding an extra step. #### Display the signed hash Cryptography to the rescue once again! Using code on the FRONT END we can ask the user to sign the ID of the Validation Block. The signature, can later be used to [infer the address of the signer and the integrity of the Validation Block ID](https://medium.com/mycrypto/the-magic-of-digital-signatures-on-ethereum-98fe184dc9c7) without revealing their private key. We then [calculate the hash of the signature](https://en.wikipedia.org/wiki/Hash_function) and use that as the value to display on the sign of the recorded video (screen or paper). All of this can be easily done through code, so there is no extra interaction from the Human rather than writing/copying/printing a specific value.. The hash could have the same length as the address which would mantain the amount of effort required by the Human, as when they registered. ### Metadata The metadata for the renewal should be the same as the existing one for registration, but include 2 new fields called `validation_block_id` and `validation_block_id_signature`. On these we will store the Validation Block ID and the signature that we can use later for validation of the data and the account. ## Renewal Validation With the updated metadata, anyone (including Curators) should have enough information to rebuild the hash of the signature and compare it to the one on the video. ### Curators process With this new implementation, Curators experience will be exactly the same as it is with registrations but in this case, the compared value will be hash of `validation_block_signature`, not the user address. Curators shouldn't care about the meaning, they should just care that the value is the same *(as long as the UI is implemented to hold this mechanism)*. ### Automated validations *The remaining steps can AND SHOULD do the remaining validations by CODE on the FRONT END. Either to help curators or to warn submiters. * Once the curator has done its job, we can automate the process of validating the cryptographic evidence, and finally check that the expiration date is greater than the submission date. ***Since all the required data to make this validations are on the metadata, it can all be automated by code as follows:*** #### Validate the signature from the metadata We do this by infering the address of the signer using the `validation_block_id` and `validation_block_signature` fields. This is easily solvable by code since [and address can be inferred from a signature](https://medium.com/mycrypto/the-magic-of-digital-signatures-on-ethereum-98fe184dc9c7). If the resulting address is the same as the Human making the submission, we have crypotographic evidence that the wallet who signed the Validation Block is the same one making the submission on the video. Since the hash on the video is valid, we can infer that the Block ID is the one used at the moment of recording the video. *If the resulting address is not the same as the submitter, the FRONT END should display a warning for challengers/curators. Not implementing this would require Curators to run the cryptographic proof manually, thus **failing on the task of keeping UX the same*** #### Time validation Since all crypotographic evidence is validwe can now take care of looking to the time at which that block generated to make sure that the video was recorded within the expected time, from recording to submission. We just search the block by it's ID and make sure that the **Expiration Date** is greater than the Submission block date. This also requires UI changes, or UX for Humans and Curators will be greatly impacted. ## Implementation Most of the development details described are relativelly simple to implement thanks to libraries that implement all of cryptographic work (such as ethers.js). A Curator or anyone could easily build a prototype and run validations on their own. There is also some work to make some changes to the UI to display the values for Curators to compare and finally, some warnings that would automatically be shown if any or none of the automatic validations pass. ### Who should do the UI Changes? However easy it can be for a tech saavy to build a system that runs validations, the app.proofofhumanity.id webpage is the FRONT END application of the project as most humans and Curators use that. To make this mechanism viable while mantaining the UX for both Humans and Curators, it's recommended that a developer is paid to make the required changes. Humans should not expect that a developer will help putting together this solutions together out ot love. (It could happen though) ### What needs to be done on the UI? For the Human submission the user could use the same page of the Registration, with wording changes and a label that allows them to get the latest block ID, sign it, hash it and display the hash to the human to set up tyhe sign for the video. It is recommended that the UI includes a counter that displays for how long the hash will be valid (or the **Expiration Date**). ALso, some warning can easily be implemented to avoid Humans making mistakes. All the cryptographic evidence should be done at the moment of submission to help Humans [avoid making honest mistakes](https://t.me/proofhumanity/39027) ## Thats all but ### A possibility for using the same mechanism for registration As an extra idea, this could be very well used on registration too: Human farming is an issue that has been seen on the Proof of Humanity registry. Since being registered allows you to accrue $UBI (which at the time of this writing is worth about 0.2 USD), there is an economic incentive on having as much accounts as possible. Time-constrained registration videos could be a way to reduce this kind of issues. If a person wants to farm 100 people, it should take considerable time to use the video with the Validation Block not expiring. The **Time Window** parameter should be fine tuned so that its not a problem for honest registrants to submit their video with time, but at the same time make it hard for bad actors to take advantage of this time window. By having cryptographic evidence of when a video was recorded, we can build more constraints around the protocol. Bye Bye

    Import from clipboard

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lost their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template is not available.


    Upgrade

    All
    • All
    • Team
    No template found.

    Create custom template


    Upgrade

    Delete template

    Do you really want to delete this template?

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in via Google

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Tutorials

    Book Mode Tutorial

    Slide Mode Tutorial

    YAML Metadata

    Contacts

    Facebook

    Twitter

    Feedback

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions

    Versions and GitHub Sync

    Sign in to link this note to GitHub Learn more
    This note is not linked with GitHub Learn more
     
    Add badge Pull Push GitHub Link Settings
    Upgrade now

    Version named by    

    More Less
    • Edit
    • Delete

    Note content is identical to the latest version.
    Compare with
      Choose a version
      No search result
      Version not found

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub

        Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

         Sign in to GitHub

        HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Available push count

        Upgrade

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Upgrade

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully