Replying to Avatar Brunswick

### 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

Reply to this note

Please Login to reply.

Discussion

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.

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?

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.

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.

Ecash is much simpler than you imagine

If it's ecash and not on chain then yeah I agree that's a much lower barrier to entry