NIP-XX: Decentralized Social Verification for Sybil Resistance aka Orange Check

[melvincarvalho]

Motivation

Nostr currently lacks robust mechanisms for Sybil resistance. Creating multiple anonymous accounts (sock-puppets) to influence discussions or promote specific agendas is trivially inexpensive. Without preventative measures, such Sybil attacks could become increasingly problematic as the platform scales.

This NIP proposes a simple, decentralized social verification method, analogous to historical concepts like GPG key signing parties, without centralized verification authorities. By leveraging a web of trust, the community itself ensures authenticity and integrity, fostering trust and cooperation among genuine users.

Proposal

Concept

Social Verification allows users to confirm each other’s real-world identities and legitimacy, building a decentralized "web of trust." Each verification strengthens community resilience by creating an interconnected network of trusted individuals, collectively resisting Sybil attacks.

Implementation

The verification process utilizes Bitcoin Taproot addresses, linking Nostr identities (npub) to on-chain attestations:

1. Identify a real person’s public key (npub) on Nostr.
2. Create and broadcast a Bitcoin transaction sending an amount of sats to the corresponding Taproot address derived from their Nostr public key.
3. Include an OP_RETURN output in this transaction containing the message VERIFIED.

Example:

• Receiver npub (Taproot address): <taproot-derived-address>
• OP_RETURN message: VERIFIED

This process can easily begin using Bitcoin's Testnet4, allowing experimentation without economic cost, thus encouraging widespread participation and adoption. Sats sent to one verified user can then be used to verify another user.

Verification Instructions

Users should only verify others when they:

• Personally know the individual being verified.
• Can confirm that the person is indeed a real human and accurately represents their claimed identity.

Anonymous or pseudonymous accounts are not part of this system and should not receive verifications. Users are encouraged to maintain honesty and careful judgment to uphold the web of trust's integrity.

A simple Nostr-compatible application (yet to be developed) will allow users to easily log in with their Nostr identities and manage their verifications. Verified accounts may be visually represented with a distinct symbol such as an "Orange Check."

Verification Interpretation

Each Nostr client can query the Bitcoin blockchain to check for verification transactions linked to any given Nostr public key. Users with one or multiple VERIFIED attestations gain a decentralized "verified" status, which others can evaluate when determining credibility or filtering interactions.

An indexer could be built to easily visualize this web of trust, displaying multiple decentralized verifications and highlighting community-established trust relationships.

Additional Benefits

An added side effect of using identical npub and Taproot addresses is "proof of publication"—a user’s on-chain transaction inherently provides timestamped proof of their involvement, enabling verifiable claims such as being an "OG from 2024."

Considerations

• Verification strength may depend on the number of distinct users who have verified a given account, naturally evolving into a robust web of trust.
• Clients may visually represent verification status based on the quality or quantity of attestations.
• This method maintains decentralization, avoiding centralized "blue-check" systems.

Security and Privacy

• Only public keys and minimal Bitcoin transactions are involved.
• No additional identity or sensitive personal information is explicitly required.

Benefits

• Effective Sybil resistance via economic "skin in the game."
• Decentralized and permissionless approach.
• Easy-to-implement and transparent verification system.
• Encourages a trustworthy community culture by rewarding authentic participation.

[mikedilger]

Asking users to do something that is esoteric with no immediate benefit to them... means it won't often be done. So it can't be relied upon to stitch a whole network together.

Also, the sybil attack network is distinguishable from the real one since the real one has very few links into the sybil one. There is a network partition. Detecting that network partition can help real people avoid the sybils, even if there are many more sybils than real people. I admit I'm not sure what the graph algorithm is that does this, but I've always though of it as the right solution requiring no setup.

[mikedilger]

Thinking more about this in the last few days, I just wrote this: #1861
This is more of a simple and casual vouching for other accounts, just made distinct from following.