{ "id": "eb0fb835940fd2c45a58c01fa3eb80817a54ba041d290d494c931f6b1b68751d", "pubkey": "c1e9ab3a56a2ab6ca4bebf44ea64b2fda40ac6311e886ba86b4652169cb56b43", "created_at": 1725656297, "kind": 42, "tags": [ [ "e", "86fe96e43f0de7269396f2df903984742cd9326b6c1fdc250c3c2079a323bdfe", "", "root" ], [ "e", "86fe96e43f0de7269396f2df903984742cd9326b6c1fdc250c3c2079a323bdfe" ], [ "p", "c1e9ab3a56a2ab6ca4bebf44ea64b2fda40ac6311e886ba86b4652169cb56b43" ], [ "p", "bb3555be5f416a17ac20d0b07d8f14b1137139d33a4c1d6eb4939b3287698522" ], [ "alt", "Public chat message" ] ], "content": "### Nostr Improvement Possibility (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/6/2024 blockheight 860194\n**Status**: Draft r2\n**Discussion**: \"Proof of Bitcoin\" nostr:nevent1qqsgdl5kuslsmeexjwt09hus8xz8gtxexf4kc87uy5xrcgre5v3mmlszyzan24d7taqk59avyrgtqlv0zjc3xufe6vayc8twkjfekv58dxzjyqcyqqqqq2q9jp7vl\n\n---\n\n#### **Abstract**\n\nThis NIP introduces a mechanism to connect a NOSTR Public Key (NPUB) with a Bitcoin address to establish credibility and prevent spam. The system offers three key functions: establishing, updating, and revoking NPUB identities through Bitcoin addresses. This proposal addresses immediate identity and credibility needs for NOSTR users, providing an economic and feasible way to enter the network without reliance on third-party services or KYC procedures. While concerns about scalability exist due to Bitcoin's limitations, this NIP is designed as a short-term, practical solution, not a long-term fix.\n\n---\n\n#### **Motivation**\n\nThe NOSTR ecosystem currently lacks a robust method for new users to establish identity credibility without relying on third-party services or domain-based verification (e.g., NIP-05). This gap creates a barrier to entry for serious individuals who wish to participate in NOSTR while maintaining privacy. Bots, spam accounts, and low-quality actors pose additional risks without a verifiable means of anchoring identities.\n\nThis NIP proposes connecting an NPUB to a Bitcoin address, leveraging Bitcoin’s cryptographic proofs to create a decentralized and verifiable identity system. The immediate objective is to give users a way to build credibility without linking their NPUB to personal information, social networks, or centralized services.\n\n---\n\n#### **Scalability Concerns and Responses**\n\nTwo primary concerns have been raised regarding scalability:\n1. **Bitcoin’s UXTO Limitation**: \n - A calculation found that distributing Bitcoin UTXOs to 10 billion users would take approximately 19 years, assuming 10,000 UTXOs per block. This suggests the current Bitcoin blockchain could struggle to support such a vast system. \n - However, this NIP does not intend to scale to 10 billion people in the immediate future. The proposal serves as a **short-term solution** to establish identity for early adopters on NOSTR, where large-scale UTXO consumption is not yet a concern.\n\n2. **Limited Supply of Bitcoin**:\n - Requiring each user to hold 100,000 satoshis (SATs) would constrain Bitcoin's supply. Critics argue this would limit the system's long-term scalability.\n - The 100,000 SAT threshold is based on current economic realities, where most Bitcoiners recommend this as the minimum UTXO size to avoid future transaction fees becoming disproportionate to the balance. This threshold is designed to balance practicality and spam deterrence, not to serve as a permanent requirement.\n\nIt is important to note that this NIP is not aimed at solving identity anchoring for **eternity**. Bitcoin’s protocol and scalability will likely evolve in the coming years, and potential solutions like e-cash or sidechains may offer alternatives. In the short term, however, anchoring NPUBs to Bitcoin is feasible and economical, especially given the current scale of NOSTR.\n\n---\n\n#### **Use Cases and Functions**\n\nThe system offers three key functions for managing identity:\n\n1. **Establishing the NPUB-Bitcoin Address Connection**:\n - Users can anchor their NPUB to a Bitcoin address by publishing a message that includes the NPUB, the Bitcoin address, the current block height, and a signature. \n - The signature proves control of both the NPUB and the Bitcoin address and should be verified by NOSTR clients to confirm the user's credibility.\n - A non-trivial amount of Bitcoin should be held in the address to prevent spam, with 100,000 SATs being the recommended threshold.\n\n2. **Changing the Bitcoin Address**:\n - Users can update their Bitcoin address while maintaining the same NPUB by signing a message with both the old and new Bitcoin addresses.\n - This process includes signatures from both addresses to verify ownership transfer and should be treated as an irrevocable identity update.\n - The old address is effectively retired, and the new one becomes the primary address for the NPUB.\n\n3. **Revoking and Reassigning NPUB Identity**:\n - Users can revoke their NPUB and assign a new one without losing their Bitcoin identity. The revocation message includes the old NPUB, the new NPUB, the block height, and a signature from the Bitcoin address.\n - Any messages signed by the old NPUB after the revocation block height are considered invalid.\n - This ensures that users can maintain credibility and identity continuity even after NPUB changes.\n\n---\n\n#### **Specification**\n\n1. **Message Format**:\n - Each message contains:\n - NPUB (or NPUBs in the case of revocation)\n - Bitcoin address\n - Block height\n - A signature generated using the Bitcoin private key.\n - For changes in Bitcoin address, the message is signed by both the old and new addresses.\n\n2. **Relay and Client Support**:\n - Relays should treat these messages as irrevocable, enabling verifiable identity across the network.\n - Clients must support signature verification using standard Bitcoin cryptographic methods.\n\n3. **Economic Constraints**:\n - Users must hold a non-trivial amount of Bitcoin in the associated address (e.g., 100,000 SATs) to prevent abuse and spam.\n - This requirement ensures that only users with a stake in maintaining credibility will participate in the system.\n\n---\n\n#### **Rationale**\n\nThis NIP provides a practical method for establishing short-term credibility in NOSTR, allowing users to build a reputation without tying their NPUB to personal information or social networks. The proposal is designed to bridge the gap for newcomers entering NOSTR without going through KYC processes, enhancing privacy while discouraging spam.\n\nWhile Bitcoin scalability concerns are valid for the long term, this NIP addresses **immediate needs**. By the time NOSTR reaches a global scale, alternate identity mechanisms or blockchain improvements will likely emerge. In the meantime, Bitcoin provides a **feasible, decentralized method** for early adopters to anchor their identities.\n\n---\n\n#### **Backwards Compatibility**\n\nThis NIP is fully compatible with existing identity standards such as NIP-05. It offers an additional identity verification method, not a replacement, and can coexist with domain-based or social network-based methods.\n\n---\n\n#### **Security Considerations**\n\n- **Private Key Management**: Users must protect their Bitcoin private keys to prevent identity theft. Compromised keys would result in lost credibility and the inability to manage their NPUB identity.\n- **Spam Mitigation**: The requirement of holding a non-trivial amount of Bitcoin reduces the likelihood of spam accounts, but the threshold must be carefully monitored to prevent abuse.\n- **Scalability**: This NIP focuses on immediate scalability. Future developments in Bitcoin or identity systems may alleviate long-term concerns.\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": "b825f3a1486ed1f91ec15ed96e01487aab6f1a10b2a75d97c9a53a7057394cc7e614516352f4c9022ea61fadc83f7a0e10a0b0f2ca57eef7a68d31c6c858f3d2" }