Oddbean

### NOSTR Improvement Possibility (NIP): NPUB to Bitcoin Address Anchoring with Web of Trust Integration **NIP Number**: TBD **NIP Title**: NPUB to Bitcoin Address Anchoring for Immediate Identity Establishment and Web of Trust Support **Author**: Brunswick nostr:nprofile1qqsvr6dt8ft292mv5jlt7382vje0mfq2ccc3azrt4p45v5sknj6kkscpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszyrhwden5te0dehhxarj9ekk7mf03umfwq **Date**: 9/6/2024 blockheight 860202 **Status**: Draft r3 **Discussion**: "Proof of Bitcoin" nostr:nevent1qqsgdl5kuslsmeexjwt09hus8xz8gtxexf4kc87uy5xrcgre5v3mmlszyzan24d7taqk59avyrgtqlv0zjc3xufe6vayc8twkjfekv58dxzjyqcyqqqqq2q9jp7vl #### **Abstract** This NIP introduces a mechanism to connect a NOSTR Public Key (NPUB) with a Bitcoin address to establish credibility and prevent spam, supplementing a Web of Trust system. The system offers three key functions: establishing, updating, and revoking NPUB identities through Bitcoin addresses. The primary goal is to provide new users with a temporary credibility mechanism while they build their Web of Trust. Additionally, the system supports key rotation for established users. --- #### **Motivation** NOSTR 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. The Web of Trust is a more reliable long-term solution, but new users without established connections need a way to demonstrate credibility. This NIP proposes connecting an NPUB to a Bitcoin address, leveraging Bitcoin’s cryptographic proofs to create a decentralized and verifiable identity system. The Bitcoin anchoring system supplements the Web of Trust and provides an onboarding mechanism for new users while discouraging spam and bot accounts. Once users establish their Web of Trust, the Bitcoin anchor can serve other purposes, such as key rotation. --- #### **Scalability Concerns and Responses** Two primary concerns have been raised regarding scalability: 1. **Bitcoin’s UXTO Limitation**: - 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. - 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. 2. **Limited Supply of Bitcoin**: - 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. - 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. It 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. --- #### **Integration with Web of Trust** This system serves as a supplementary mechanism to the Web of Trust (WoT), which is the **preferable** and **more reliable** method for prioritizing credible content on NOSTR. The Web of Trust scores posts based on the credibility of individuals within your network. However, new users often lack established WoT connections, making it difficult for their posts to be prioritized or seen. The Bitcoin anchoring system offers a temporary credibility mechanism: - **Bitcoin Anchoring Score**: Based on the **age of the Bitcoin wallet balance**. The score is the number of blocks since the wallet has maintained a balance above the set threshold (e.g., 100,000 SATs). This score resets to zero if the balance dips below the threshold. - Clients and relays can **deprioritize posts** from users with low WoT scores or no network connections but allow posts from those with a **non-trivial Bitcoin anchoring score**. For example, a post could be considered if the wallet has maintained a balance above the threshold for at least 500 blocks. The anchoring system allows new users to demonstrate credibility until their Web of Trust score improves. Once users have established strong connections in their Web of Trust, they no longer need to rely on the Bitcoin anchor unless they wish to use it for **key rotation**. --- #### **Use Cases and Functions** The system offers three key functions for managing identity: 1. **Establishing the NPUB-Bitcoin Address Connection**: - 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. - 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. - A non-trivial amount of Bitcoin should be held in the address to prevent spam, with 100,000 SATs being the recommended threshold. 2. **Changing the Bitcoin Address**: - Users can update their Bitcoin address while maintaining the same NPUB by signing a message with both the old and new Bitcoin addresses. - This process includes signatures from both addresses to verify ownership transfer and should be treated as an irrevocable identity update. - The old address is effectively retired, and the new one becomes the primary address for the NPUB. 3. **Revoking and Reassigning NPUB Identity**: - 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. - Any messages signed by the old NPUB after the revocation block height are considered invalid. - This ensures that users can maintain credibility and identity continuity even after NPUB changes. --- #### **Specification** 1. **Message Format**: - Each message contains: - NPUB (or NPUBs in the case of revocation) - Bitcoin address - Block height - A signature generated using the Bitcoin private key. - For changes in Bitcoin address, the message is signed by both the old and new addresses. 2. **Relay and Client Support**: - Relays should treat these messages as irrevocable, enabling verifiable identity across the network. - Clients must support signature verification using standard Bitcoin cryptographic methods. - **Clients and relays** can also filter or prioritize content based on the Bitcoin anchoring score, particularly when WoT scores are low or absent. 3. **Economic Constraints**: - Users must hold a non-trivial amount of Bitcoin in the associated address (e.g., 100,000 SATs) to prevent abuse and spam. - This requirement ensures that only users with a stake in maintaining credibility will participate in the system. --- #### **Rationale** This NIP provides a **temporary credibility mechanism** for new users in NOSTR who have not yet established a strong Web of Trust. The Bitcoin anchoring score offers a proportional measure of credibility based on the age of the Bitcoin wallet, allowing new users to demonstrate their seriousness and intent. While the Web of Trust is the **long-term solution** for prioritizing content, this NIP helps onboard users who may otherwise struggle to gain credibility in the early stages. The Bitcoin anchor system can also be used for **key rotation**, offering flexibility for maintaining identity over time. --- #### **Backwards Compatibility** This 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. --- #### **Security Considerations** - **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. - **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. - **Scalability**: This NIP focuses on immediate scalability. Future developments in Bitcoin or identity systems may alleviate long-term concerns. - **Web of Trust Integration**: The Bitcoin anchoring score supplements but does not replace the Web of Trust. Once a user has established a high WoT score, the Bitcoin anchor may become unnecessary. --- #### **References** - [NIP-05](https://github.com/nostr-protocol/nips/blob/master/05.md): Mapping Nostr Public Keys to DNS-based Identities - Bitcoin Signed Messages: [BIP-137 Specification](https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki) --- #### **Acknowledgments** Thanks to the Nostr and Bitcoin communities for feedback and technical insights that helped shape this proposal.

nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0ss9zgs RFC nostr:nevent1qqsz6jwq3pmgj53r5hcfsszczmkz0zgnvx7lelwzuck4ujtp2cf37ucpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyrq7n2e62632km9yh6l5f6nykt76gzkxxy0gs6agddr9y95uk445xqcyqqqqq2s9zqn43

I think the bootstrapping should be more open-ended, and I'm skeptical of stuff that tries to put things on bitcoin. OTS is a neat idea, but it's centralized in practice, and isn't long-term economical. This seems similar. That said, it could be one good way to do it, although my ideal would be to use the web of trust to validate bootstrapped-trust providers, who would vouch for new pubkeys (using a badge or something). How the new pubkey gets that badge would be completely open-ended — it could be a captcha, payment, proof of work, KYC check, whatever. The badge would then expire after a short period of time, during which the new user would want to gain followers to get into the web.

What I think is different here is there is no on-chain interaction, only that someone hold some bitcoin and HODL it in a wallet. The longer it is held, the more credible the associatrd npub. Any linking is only done through message signing and nostr relays.

Slight improvement over OTS, but it still depends on validators to run a bitcoin node (which is not a huge deal, but definitely an additional piece of infrastructure). Much worse is that this requires users to know how to sign a message with their bitcoin key, which is a non-starter in terms of UX imo.

The idea of a badge issued by a trusted agent is also a good one. However, what credibility does an issuer have if there is no consequence to not policing their badge holders? How do you avoid recreating the "certificate authority" debacle around ssl centralization?

Yeah, that's a super good point. It could end up going that direction. I would hope that issuers would be kept accountable by the people trusting them, and get bad reviews if they didn't do their job, like anything else. That would allow for a decentralized system without a deep and brittle hierarchy like with CAs. One problem with root CAs is probably that they're baked in to the OS/Browser at a low level, and need to be trustworthy for every request, rather than being a bootstrapping mechanism. The moment a root CA gets compromised everyone using a certificate downstream is in trouble. The same would be true of a WoT bootstrapping service, but the duration the certificate needs to be valid would be days or weeks, not years (taking renewals into account).

### NOSTR Improvement Possibility (NIP): NPUB to Chaumian Ecash Token Anchoring for Identity Establishment **NIP Number**: TBD **NIP Title**: NPUB to Chaumian Ecash Token Anchoring for Identity and Web of Trust Support **Author**: Brunswick nostr:nprofile1qqsvr6dt8ft292mv5jlt7382vje0mfq2ccc3azrt4p45v5sknj6kkscpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszyrhwden5te0dehhxarj9ekk7mf03umfwq **Date**: 9/6/2024 blockheight 860202 **Status**: Draft r3 **Discussion**: "Proof of Bitcoin" nostr:nevent1qqsgdl5kuslsmeexjwt09hus8xz8gtxexf4kc87uy5xrcgre5v3mmlszyzan24d7taqk59avyrgtqlv0zjc3xufe6vayc8twkjfekv58dxzjyqcyqqqqq2q9jp7vl --- #### **Abstract** This NIP introduces a method to anchor a NOSTR Public Key (NPUB) to a Chaumian ecash Cashu token that is P2PK-locked to the NPUB, offering a decentralized and anonymous way to establish credibility on the NOSTR network. This method supplements the Web of Trust system, providing new users with an immediate credibility mechanism while they build their network. The proposal removes the need for additional message types, simplifying the process by allowing users to post or reference the token on their profile or through NOSTR notes. --- #### **Motivation** NOSTR currently lacks a clear and decentralized method for new users to establish credibility without relying on centralized services or domain-based verification. This creates a barrier for new users who do not have connections within a Web of Trust. While the Web of Trust remains a reliable long-term solution, new users need a bootstrap mechanism for credibility. By using a Chaumian ecash Cashu token that is P2PK-locked to the NPUB, users can establish verifiable credibility without relying on a Bitcoin on-chain transaction. This proposal also simplifies the validation process, as the age and validity of the token can be checked against the Cashu mint. --- #### **Use of Chaumian Ecash Cashu Tokens** In this updated system: - **Chaumian ecash Cashu tokens** are used to anchor NPUBs. - Each token is **P2PK-locked** (Pay-to-Public-Key) to the user's NPUB. - The token serves as proof of credibility, with its **age** verifiable through the Cashu mint. - Users can post the token directly in their profile or reference a NOSTR note (kind 1) containing the token. No additional message types are required, as the token itself carries all necessary information for validation. --- #### **Integration with Web of Trust** This token-based system serves as a **supplement** to the Web of Trust. While long-term credibility will be determined by the Web of Trust score, the token provides new users with an immediate credibility anchor until their Web of Trust connections are established. - **Token Age as Credibility**: The credibility of the token is tied to its age, which can be validated against the Cashu mint. - **Temporary Use**: Once users have established themselves within the Web of Trust, they may no longer need to rely on the token. - **Flexible Trust System**: Clients and relays can prioritize posts based on Web of Trust scores or token credibility, reducing spam and bot interactions. --- #### **Specification** 1. **Token Format**: - A Chaumian ecash Cashu token that is P2PK-locked to the NPUB of the user. - The token must be **posted** directly in the user’s profile or referenced in a NOSTR note (kind 1). 2. **Relay and Client Support**: - Relays should handle tokens like other NOSTR metadata, enabling verification of the token's validity and age. - Clients must support the ability to validate the token against the Cashu mint and factor it into the trust mechanism. 3. **Validation**: - The token’s **age** can be verified by checking the Cashu mint for the duration it has been held above a set threshold (such as 100,000 SATs, or equivalent). - Tokens that fall below the threshold or are revoked will reset the credibility score. --- #### **Rationale** This NIP provides a **lightweight, decentralized** method for new users to gain credibility on NOSTR without requiring on-chain Bitcoin transactions. The use of Chaumian ecash Cashu tokens is economical and maintains the privacy of users. It allows for easy validation and a straightforward process for establishing temporary credibility until Web of Trust connections are built. This change eliminates the scalability concerns raised with the original proposal that relied on Bitcoin's on-chain UTXO limits, and it simplifies the process for clients and relays to implement. --- #### **Backwards Compatibility** This NIP remains fully compatible with existing standards such as NIP-05 and the Web of Trust. It acts as a **supplementary** method to provide a temporary credibility anchor and does not interfere with other identity systems. --- #### **Security Considerations** - **Token Security**: Users must ensure the security of their Chaumian ecash tokens. A compromised token could allow unauthorized individuals to claim credibility. - **Mint Validation**: The Cashu mint should be trusted to provide reliable data for token age and validation, and its decentralization will impact the security model. - **Spam Mitigation**: The use of tokens helps mitigate spam, but their value threshold must be set high enough to prevent abuse while remaining economical for users. --- #### **References** - [NIP-05](https://github.com/nostr-protocol/nips/blob/master/05.md): Mapping Nostr Public Keys to DNS-based Identities - Chaumian Ecash: [Cashu Project Documentation](https://github.com/cashubtc) --- #### **Acknowledgments** Thanks to the Nostr and Bitcoin communities for feedback and technical insights that helped shape this proposal.

Proof-of-bitcoin identity anchoring: nostr:nevent1qqswq6v7exjd907zns3mlukkrez9w9e8lhured35y90896fsfqyh9fqpz3mhxw309akx7cmpd35x7um58g6rsd3e9upzps0f4va9dg4tdjjta06yafjt9ldyptrrz85gdw5xk3jjz6wt266rqvzqqqqqqypu8gry

nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpzemhxue69uhhyetvv9ujuvrcvd5xzapwvdhk6qgdwaehxw309aukzcn49ekk2qghwaehxw309aex2mrp0yh8x6tpd4ehgu3wvdhk60v82wz nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug RFC nostr:nevent1qqs8wraj30wgeyehxaxhmmlzrfx4sxrh970yhtyl7cyvd364dp6s50gpz3mhxw309akx7cmpd35x7um58g6rsd3e9upzps0f4va9dg4tdjjta06yafjt9ldyptrrz85gdw5xk3jjz6wt266rqvzqqqqqqy5eymtd

Its a demonstration that a web-of-trust, a trust-anchor, or some other means of authenticating valid npubs should be converged on by the community before the network becomes crippled by simple flood attacks. nostr:nevent1qqswq6v7exjd907zns3mlukkrez9w9e8lhured35y90896fsfqyh9fqpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyrq7n2e62632km9yh6l5f6nykt76gzkxxy0gs6agddr9y95uk445xqcyqqqqqqglqgnac

I like NIP-05 because it bootstraps trust from the legacy world (DNS URIs). I also like the badge nip because it enables npubs to vouch for each other. Agree it needs to be as open-ended as possible.

Totally get where you're coming from! I love the idea of using a web of trust for validation. It opens up so many possibilities for new users while keeping things decentralized! Exciting stuff! 🌟

I'm not sure a mechanism that relies on making BTC transactions is great because the UX would be very bad (and near unusable for normies). I feel like there are probably some other heuristics you could apply to npubs (looking at follows is just one) to determine their credibility without requiring any user action. Stuff like "age of oldest event" or "count of times blocked by credible npubs" could do a lot.