Re: NOSTR Censorship Improvement Proposal

čt 27. 3. 2025 v 16:56 odesílatel Bitcoin_Fan_1 <
Bitcoin_Fan_1@protonmail.com> napsal:

> Hi Melvin et al,
>
> Thank you for your reply! Yes you certainly captured the core concept—it’s
> essentially a personal blockchain where each message’s cryptographic link
> exposes censorship.
>
> Since submitting the original proposal, I’ve further refined the design
> based on deeper analysis, and wanted to highlight two critical improvements
> over the initial version:
>
> 1. Hash Calculation Upgrade
> Each message now incorporates three verifiable elements:
>
> The message content itself
>
> A cleartext message_number (strictly increasing: 1, 2, 3…)
>
> The prev_hash of the prior message
>
> This means:
> current_hash = SHA256(content + str(message_number) + prev_hash)
> Why this matters:
>
> Tampering with any component (content, order, or history) breaks the chain
>
> Clients can validate full history integrity from any message subset
>
> 2. Instant Censorship Proofs
> The cleartext message_number enables:
>
> O(1) gap detection: Missing numbers = undeniable suppression (e.g., #4 →
> #6)
>
> Resource efficiency: Mobile clients skip expensive hashing unless gaps
> exist
>
> Backward compatibility: Legacy clients ignore numbers but still validate
> hashes
>
> Trade-Offs
> +2% storage overhead (for numbering metadata)
>
> No new privacy risks (Nostr is public-by-design; numbers reveal no more
> than timestamps)
>
> I'll try to get a revised NIP draft together a bit later. Feel free to let
> me know your thoughts.
>

Sounds good.

First question is that there might be a classic race condition.

What if the user has two messages with the name number?  This is similar to
the double spend problem.

Or let's say one message is not broadcast, for some reason.  How do i know
which line in the tree is correct?  Or maybe that's the responsibility of
the user.

This reminds me a bit of Peter Todd's single-use seals idea, for tamper
proof chains of transactions:

https://petertodd.org/2016/commitments-and-single-use-seals


> Best regards,
>
> Bitcoin_Fan_1
>
>
> -------- Original Message --------
> On 3/27/25 10:24 AM, Melvin Carvalho wrote:
>
>
>
> út 18. 3. 2025 v 9:00 odesílatel Bitcoin_Fan_1 <
> Bitcoin_Fan_1@protonmail.com> napsal:
>
>> Hello everyone, I just wanted to pass along a draft of a proposal that I
>> created this evening to try to eliminate or greatly reduce censorship on
>> NOSTR. Please review it when you can and feel free to share any feedback
>> that you have. Thank you.
>>
>> ---
>>
>> # **NIP-21mm: Hash-Linked Messages and Lightweight Client Relays for
>> Censorship Resistance**
>>
>> **Date**: March 17, 2025
>> **Author**:Bitcoin_Fan_1@protonmail.com
>> **Status**: Draft
>> **Category**: Protocol Improvement
>>
>> ---
>>
>> ## **Abstract**
>>
>> This proposal introduces a method to enhance censorship resistance in the
>> Nostr protocol by implementing hash-linked message structures and
>> lightweight client relay functionality. The goal is to ensure that users
>> can verify the integrity and authenticity of their messages while
>> minimizing reliance on external relays. This approach creates a
>> cryptographically verifiable chain of messages for each user and allows
>> users to act as the first relay for their own messages.
>>
>> ---
>>
>> ## **Motivation**
>>
>> Currently, Nostr relies on relays to distribute user-signed messages
>> across the network. However, there is no way for users to ensure that
>> relays are not censoring or tampering with their messages. This lack of
>> transparency undermines the protocol's censorship resistance.
>>
>> The proposed solution addresses this issue by:
>> 1. Structuring messages in a hash-linked format, enabling verifiable
>> integrity across a user's entire message history.
>> 2. Introducing lightweight relay functionality within client software,
>> allowing users to act as the first relay for their own messages.
>> 3. Providing mechanisms for other clients to verify message authenticity
>> against the user's original relay.
>>
>> ---
>>
>> ## **Specification**
>>
>> ### **1. Message Structure**
>> Each message sent by a user will include additional fields to create a
>> cryptographically verifiable chain of messages. The structure is as follows:
>>
>> #### **First Message (Message 0)**
>> The first message sent by a user includes:
>> - The standard Nostr message data (e.g., `content`, `pubkey`,
>> `created_at`, etc.).
>> - A SHA256 hash of:
>>   - The message content.
>>   - The Unix timestamp (`created_at`) in seconds when the message was
>> created.
>>   - A sequential message number (`msg_number`), starting at `0`.
>> - A digital signature of the above hash using the user's private key.
>>
>> #### **Subsequent Messages**
>> Each subsequent message includes:
>> - The standard Nostr message data.
>> - A SHA256 hash of:
>>   - The current message content.
>>   - The Unix timestamp (`created_at`).
>>   - The sequential message number (`msg_number`).
>>   - The hash of the previous message in the sequence.
>> - A digital signature of the above hash using the user's private key.
>>
>> This creates a hash-linked chain of messages, similar to a blockchain but
>> specific to each user.
>>
>> ### **2. Lightweight Client Relay**
>> Each Nostr client will include optional lightweight relay functionality
>> to act as the first point of transmission for its user's messages. This
>> relay will:
>> - Store all messages sent by the user locally.
>> - Broadcast these messages to one or more external relays for wider
>> distribution.
>> - Publicly display the hash of each transmitted message for verification
>> purposes.
>>
>> ### **3. Verification by Receiving Clients**
>> Receiving clients can verify the authenticity and integrity of a user's
>> messages by:
>> 1. Querying the user's personal relay (if available) to retrieve the
>> original message and its hash.
>> 2. Comparing the retrieved hash with hashes stored on other relays.
>> 3. Validating that each message's hash matches its signature and that the
>> chain of hashes is intact.
>>
>> ---
>>
>> ## **Rationale**
>>
>> The proposed changes enhance censorship resistance by:
>> 1. Ensuring that any attempt to censor or tamper with messages is
>> detectable through cryptographic verification.
>> 2. Reducing reliance on external relays by allowing users to act as their
>> own initial relay.
>> 3. Preserving compatibility with existing Nostr infrastructure while
>> introducing optional enhancements.
>>
>> By linking messages in a cryptographically verifiable chain, users gain
>> greater control over their data without requiring significant changes to
>> existing protocols.
>>
>> ---
>>
>> ## **Backward Compatibility**
>>
>> This proposal is backward-compatible with existing Nostr clients and
>> relays, as it does not alter the core protocol's requirements. Clients and
>> relays that do not implement these changes can still process standard Nostr
>> messages but will not benefit from enhanced verification features.
>>
>> ---
>>
>> ## **Security Considerations**
>>
>> 1. **Hash Collision Resistance**: The use of SHA256 ensures that it is
>> computationally infeasible to generate two different inputs with the same
>> hash, preserving message integrity.
>> 2. **Private Key Security**: As with existing Nostr functionality, users
>> must safeguard their private keys to prevent unauthorized signing of
>> messages..
>> 3. **Relay Availability**: If a user's personal relay is offline,
>> verification may be delayed until it becomes available again. External
>> relays can serve as backups in such cases.
>>
>> ---
>>
>> ## **Implementation Plan**
>>
>> 1. Add support for hash-linked message structures in Nostr clients.
>> 2. Develop lightweight relay functionality as an optional feature in
>> client software.
>> 3. Update receiving clients to verify hashes against personal relays when
>> available.
>>
>> ---
>>
>> ## **Future Work**
>>
>> 1. Explore incentives for external relays to store and distribute
>> verifiable hash-linked messages.
>> 2. Investigate additional cryptographic techniques (e.g., Merkle trees)
>> to optimize storage and verification processes.
>>
>> ---
>>
>> ## **Conclusion**
>>
>> This proposal enhances Nostr's censorship resistance by introducing
>> cryptographically verifiable message chains and empowering users with
>> lightweight client relay functionality. By enabling transparent
>> verification of message authenticity and integrity, it strengthens trust in
>> the protocol while preserving its decentralized nature.
>>
>
> Hi, this looks great!
>
> So it's like a personal blockchain that links each of your messages
> together, making it easy to detect if anything’s been censored or tampered
> with?
>
>
>>
>> ---
>>
>>
>>