{ "id": "c9ee73e4480e665861e426b1c0b57bc128b666258d35217432d47f5b004a88f5", "pubkey": "c1e9ab3a56a2ab6ca4bebf44ea64b2fda40ac6311e886ba86b4652169cb56b43", "created_at": 1725592818, "kind": 42, "tags": [ [ "e", "86fe96e43f0de7269396f2df903984742cd9326b6c1fdc250c3c2079a323bdfe", "", "root" ], [ "e", "86fe96e43f0de7269396f2df903984742cd9326b6c1fdc250c3c2079a323bdfe" ], [ "p", "c1e9ab3a56a2ab6ca4bebf44ea64b2fda40ac6311e886ba86b4652169cb56b43" ], [ "p", "bb3555be5f416a17ac20d0b07d8f14b1137139d33a4c1d6eb4939b3287698522" ], [ "alt", "Public chat message" ] ], "content": "### Nostr Improvement Proposal (NIP): NPUB to Bitcoin Address Anchoring with Identity Functions\n\n**NIP Number**: TBD \n**NIP Title**: NPUB to Bitcoin Address Anchoring for Enhanced Identity and Spam Prevention \n**Author**: Brunswick nostr:nprofile1qqsvr6dt8ft292mv5jlt7382vje0mfq2ccc3azrt4p45v5sknj6kkscpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszyrhwden5te0dehhxarj9ekk7mf03umfwq\n**Date**: 9/5/2024 blockheight 860073\n**Status**: Draft \n**Discussion**: \"Proof of Bitcoin\" nostr:nevent1qqsgdl5kuslsmeexjwt09hus8xz8gtxexf4kc87uy5xrcgre5v3mmlszyzan24d7taqk59avyrgtqlv0zjc3xufe6vayc8twkjfekv58dxzjyqcyqqqqq2q9jp7vl\n\n---\n\n#### **Abstract**\n\nThis NIP proposes a method to anchor a Nosr Public Key (NPUB) to a Bitcoin address, offering a mechanism to establish and maintain identity credibility while minimizing spam and fraudulent activity. The system allows for three key functions: establishing an NPUB-Bitcoin address connection, changing the associated Bitcoin address, and revoking and reassigning NPUB identities. These functions are rooted in the Bitcoin blockchain but do not require on-chain Bitcoin transactions, reducing costs while leveraging the credibility of Bitcoin.\n\n---\n\n#### **Motivation**\n\nNostr's reliance on social networks or external systems for identity verification (such as NIP-05) introduces potential issues of centralization and a lack of meaningful identity verification. NIP-05, which ties NPUBs to email-style usernames at fully qualified domain names, often fails to establish a true connection between the identity and the individual, as the domain owner can freely assign usernames without meaningful validation.\n\nThis proposal addresses these issues by anchoring identity to a decentralized asset (Bitcoin), creating a verifiable system where NPUBs can be linked to Bitcoin addresses. By using signed messages, users can establish a chain of credibility, while introducing a system that acts as a deterrent to spam and bot accounts.\n\n---\n\n#### **Use Cases and Functions**\n\nThis system is designed to fulfill three primary identity-related functions:\n\n1. **Establishing the Initial Connection**:\n - A user establishes a connection between their NPUB and a Bitcoin address.\n - The Bitcoin address should contain a non-trivial amount of Bitcoin to demonstrate commitment without exposing significant holdings.\n - A message containing the NPUB, Bitcoin address, block height (timestamp), and a signed message is published to Nostr. The message signature is made using the Bitcoin private key, proving ownership of both the NPUB and Bitcoin address.\n - The relay should treat this message as irrevocable, ensuring future verification.\n\n2. **Changing the Bitcoin Address**:\n - If a user wishes to update the Bitcoin address associated with their NPUB, they must sign a message with both the old and new Bitcoin addresses.\n - The message should include the NPUB, the old Bitcoin address, the new Bitcoin address, and a signature from both the old and new addresses.\n - This ensures that the NPUB remains unchanged but allows the user to transition to a new Bitcoin address.\n - The relay and clients should accept this as the new root of identity, verifying both signatures.\n\n3. **Revoking and Reassigning NPUB Identity**:\n - In case of a compromised NPUB or voluntary identity change, the user can revoke the old NPUB and assign a new NPUB while maintaining the same Bitcoin address.\n - The revocation message includes the old NPUB, the new NPUB, the block height (timestamp) of revocation, and is signed by the Bitcoin address.\n - Any Nostr message signed by the old NPUB after the revocation block height is considered invalid. Clients should treat the new NPUB as the valid identity.\n\n---\n\n#### **Specification**\n\n1. **Relay Handling**:\n - Relays must support these three functions (initial establishment, address change, and NPUB reassignment) by handling messages containing the Bitcoin address, block height, and NPUB signature.\n - Messages should be treated as irrevocable and permanent, ensuring that identity changes are preserved and verifiable across relays.\n\n2. **Message Format**:\n - Each message includes:\n - NPUB\n - Bitcoin address (with a minimal balance to avoid dust)\n - Block height at the time of the event\n - A signature generated using the Bitcoin private key that corresponds to the address.\n - For Bitcoin address changes, messages must be signed by both the old and new addresses.\n - For NPUB revocation, the message contains both the old and new NPUBs and is signed by the Bitcoin address.\n\n3. **Signature Verification**:\n - Clients must verify signatures using the standard Bitcoin cryptographic methods.\n - Clients should also verify the balance of the associated Bitcoin address to ensure it contains a non-trivial amount, discouraging spam by making it expensive to generate credible identities.\n \n---\n\n#### **Rationale**\n\nAnchoring NPUBs to Bitcoin addresses offers several benefits:\n- **Decentralized Identity**: Bitcoin addresses are globally recognized, decentralized, and verifiable without reliance on central authorities.\n- **Spam Prevention**: By requiring a minimal amount of Bitcoin to be associated with an NPUB, spam accounts and bots face a financial cost, making it harder to flood the network with low-quality content.\n- **Credibility Without Social Networks**: Users can establish credibility based on their Bitcoin history, even if they have no prior connections in the Nostr network.\n\nThe minimal Bitcoin balance ensures users are serious while avoiding significant exposure of funds. This approach leverages the age and stability of Bitcoin wallets rather than large balances, further discouraging trivial spam accounts.\n\n---\n\n#### **Backwards Compatibility**\n\nThis NIP is designed to complement existing identity standards such as NIP-05. It does not interfere with current practices and can operate alongside domain-based identity verification, offering an alternative for users who prefer decentralized identity mechanisms.\n\n---\n\n#### **Security Considerations**\n\n- **Private Key Protection**: Users must safeguard their private keys to prevent identity theft. Loss of the private key controlling a Bitcoin address may result in the inability to verify or revoke identity.\n- **Spam Mitigation**: While a minimal balance requirement deters spam, setting the right threshold is critical to prevent trivial balances (such as 1 satoshi) from being used to flood the network.\n- **Identity Theft**: The proposed mechanism reduces the risk of impersonation but does not eliminate it entirely, as users still need to protect their Bitcoin private keys.\n\n---\n\n#### **References**\n\n- [NIP-05](https://github.com/nostr-protocol/nips/blob/master/05.md): Mapping Nostr Public Keys to DNS-based Identities\n- Bitcoin Signed Messages: [BIP-137 Specification](https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki)\n\n---\n\n#### **Acknowledgments**\n\nThanks to the Nostr and Bitcoin communities for feedback and technical insights that helped shape this proposal.", "sig": "b1c4ae88c2a730b616abb9c41081a1c5f47d9dfb5dd242a3ccb8246fb59d3fb9d903b7fd3789d68ea3462d53b71316585bb2ac2a5267fc5e187793652d26b9f6" }