• Introduction to the Concept of Proof of Work
• Proof of Work in Nostr: NIP-13
  • How It Works Technically
  • Example of a Mined Event
• Why PoW in Nostr is “Invisible”?
  • How to Verify that PoW is Working
• The Role of PoW in Relay Policies and Moderation
• Limitations and Criticisms of PoW in Nostr
• Practical Configuration and Considerations for Users
• Conclusions

§Introduction to the Concept of Proof of Work

Proof of Work (PoW) is a cryptographic mechanism that requires a participant to perform a certain amount of computational work, demonstrable and verifiable by others, to perform an action within a distributed system. The original idea, proposed by Cynthia Dwork and Moni Naor in 1993 as an anti-spam tool, was made famous by Satoshi Nakamoto who adopted it as a consensus algorithm for the Bitcoin network. In Bitcoin, PoW is the competitive “mining” process by which nodes validate blocks of transactions and add them to the blockchain, ensuring security and immutability.

The fundamental principle is simple: make the creation of new data expensive (in terms of energy and computation time), while the verification of that work’s correctness must be cheap and instantaneous. This asymmetry creates an economic barrier against spam or denial-of-service attacks, as it becomes prohibitively expensive for a malicious actor to generate large volumes of false or unwanted content.

§Proof of Work in Nostr: NIP-13

Nostr (Notes and Other Stuff Transmitted by Relays) is a simple, open publishing protocol designed to be censorship-resistant and decentralized. Unlike Bitcoin, Nostr does not have a blockchain or a global consensus mechanism. Its purpose is to transmit events (notes, messages, metadata) through a network of independent relays. In this context, Proof of Work is not used to achieve consensus, but to deter spam and network inflation attacks.

The NIP-13 (Nostr Improvement Proposal 13) specification defines the standard way to generate and interpret Proof of Work for Nostr events. According to NIP-13, the PoW “difficulty” is defined as the number of leading zero bits in the event’s ID, calculated according to the rules of NIP-01. An event’s ID is the SHA-256 hash of its serialized JSON representation, digitally signed. To “mine” an event, the client must find a nonce (a number used once) that, when included in the event’s tags, causes the resulting hash to have the desired number of leading zeros.

§How It Works Technically

1. Event Construction: The user creates an event (e.g., a kind:1 post) with content, timestamp (created_at), and other metadata.
2. Adding the nonce Tag: The client adds a special tag of the form ["nonce", "<value>", "<target_difficulty>"]. The first value is a counter that will be incremented during mining; the third value is the desired target difficulty (e.g., "20" for 20 zero bits).
3. Mining: The client starts varying the nonce value (or, alternatively, also the created_at field) and recalculates the event ID (the SHA-256 hash) for each attempt. The process continues until an ID is found that satisfies the target difficulty, i.e., has at least the required number of leading zero bits.
4. Publication: Once a valid nonce is found, the complete event (with the nonce tag and the “mined” ID) is signed with the user’s private key and sent to relays.
5. Verification: Anyone receiving the event can instantly verify the PoW by recalculating the ID from the event data and counting the leading zero bits. If the count is equal to or greater than the target difficulty declared in the nonce tag, the PoW is valid.

§Example of a Mined Event

Here is a real example of a mined event from NIP-13:

{
"id": "000006d8c378af1779d2feebc7603a125d99eca0ccf1085959b307f64e5dd358",
"pubkey": "a48380f4cfcc1ad5378294fcac36439770f9c878dd880ffa94bb74ea54a6f243",
"created_at": 1651794653,
"kind": 1,
"tags": [["nonce", "776797", "20"]],
"content": "It's just me mining my own business",
"sig": "284622fc0a3f4f1303455d5175f7ba962a3300d136085b9566801bc2e0699de0c7e31e44c81fb40ad9049173742e904713c3594a1da0fc5d2382a25c11aba977"
}

The ID begins with six hexadecimal zeros (000006...), which corresponds to 24 leading zero bits, thus exceeding the target difficulty of 20. Note: in hexadecimal, each digit represents 4 bits. To calculate the zero bits, examine the digits from left to right:

• 0 (hex digit) = 0000 in binary → 4 zero bits.
• Six consecutive 0 digits give 6 * 4 = 24 zero bits.

NIP-13 also provides reference functions in C and JavaScript to count zero bits.

§Why PoW in Nostr is “Invisible”?

A user who enables PoW in their client often expects to see an immediate increase in visibility, likes, replies, or “zaps”. However, PoW is not a promotion algorithm. Its effect is predominantly passive and preventive:

• Spam deterrent: Creating thousands of spam events with high PoW (e.g., 20+ bits) becomes computationally expensive and slow, discouraging bots.
• No engagement guarantee: PoW does not make your posts appear higher in feeds, does not guarantee interactions, and does not affect content selection algorithms (which in Nostr are determined by clients and relays, not a central entity).
• Technical, not social, effect: The impact manifests at the network level, making it harder to flood the network with unwanted events, but it does not activate social reward mechanisms.

In summary, the absence of a measurable increase in likes or views does not mean that PoW is not working. It means it is performing its basic role silently, as a passive quality filter.

§How to Verify that PoW is Working

Although the social effect is nil, it is possible to technically verify that PoW is active and functioning:

1. Check the event ID: After publication, examine the event ID (a 64-character hexadecimal string). Use an online tool or a library to count the “leading zero bits”. More leading zeros mean higher difficulty of the work performed.
2. Observe relays: Some relays enforce moderation policies that require a minimum PoW to accept events. These policies can be declared in the relay’s information document (NIP-11) via the min_pow_difficulty field. If your event is accepted by relays with such requirements, it is an indicator that your PoW meets the criteria.
3. Measure sending time: With high difficulty (e.g., >25), the mining process can take seconds or even minutes on consumer hardware. This delay is the only immediate “visible effect” for the user.

§The Role of PoW in Relay Policies and Moderation

Nostr relays are autonomous servers that decide which events to accept, store, and retransmit. Many relays implement moderation policies to combat spam and harmful content. PoW is one of the tools at their disposal.

For example, the @nostrify/policies moderation framework includes a PowPolicy that rejects events that do not meet the difficulty criteria defined by NIP-13. A relay can configure a policy pipeline that combines PoW checks with filters for keywords, duplicates, banned pubkeys, etc.

NIP-11 (Relay Information Document) allows a relay to publicly declare its min_pow_difficulty. This informs clients that, to publish to that relay, they will need to generate events with a difficulty equal to or greater than the indicated value. It is a transparent way to set an entry barrier against spam.

However, it is crucial to note that the adoption of PoW by relays is voluntary and heterogeneous. Not all relays require PoW, and those that do can set different thresholds. Therefore, the effectiveness of PoW as a global deterrent depends on its widespread adoption across the relay network.

§Limitations and Criticisms of PoW in Nostr

The PoW mechanism in Nostr is not without limitations and criticisms:

• Energy consumption: Although the work required for a single event is negligible compared to Bitcoin mining, massive adoption by many users could still represent energy waste, especially if PoW is not strictly necessary.
• Hardware inequality: Users with powerful devices (PCs, servers) can generate high PoW easily, while users with mobile or old computers may be disadvantaged. This could create a disparity in the ability to participate in the network.
• Delegated PoW and centralization: NIP-13 mentions the possibility of “Delegated Proof of Work”, where energy-constrained clients can outsource the computation to external service providers (perhaps for a fee). Although useful for accessibility, this could centralize PoW generation in a few hands, partially defeating the decentralized purpose.
• Limited effect on sophisticated spam: A determined attacker with sufficient computational resources (e.g., botnets or cheap servers) could still generate spam with moderate PoW. PoW raises the cost but does not make it impossible.

These criticisms have led to alternative or complementary proposals, such as “pay-to-relay” systems, reputation systems based on social graphs, or decentralized captcha mechanisms.

§Practical Configuration and Considerations for Users

In Nostr clients (like Damus, Amethyst, Nostr Console, etc.), PoW is usually an optional setting. The user can specify a target difficulty (e.g., 20, 24, 30). Common values for ordinary anti-spam use range from 18 to 24. Difficulties above 30 require significant computation time even on powerful hardware and are rarely needed.

Example configuration in a hypothetical client:

Settings > Proof of Work (NIP-13) > Target difficulty: 20

Recommendations:

• For a normal user who wants to contribute to spam reduction without performance impacts, 20-22 bits is a good compromise.
• If using a mobile device, it is advisable to set a lower difficulty (16-18) or disable PoW to preserve battery and responsiveness.
• To participate in threads or communities that explicitly require high PoW (such as some “hellthreads” or relays with high min_pow_difficulty), you will need to adjust the configuration accordingly.

Remember: PoW is just one of many factors influencing the visibility of your content. Factors such as content quality, the size and engagement of your social graph, the choice of active and relevant relays, and the appropriate use of tags (hashtags) are far more decisive for obtaining interactions.

§Conclusions

Proof of Work in Nostr, standardized by NIP-13, is a tool of passive defense against spam and network inflation attacks. Its design makes it a computational quality signal that relays can use to filter events, but it plays no direct role in content promotion or feed algorithms.

Its “invisibility” in the user experience is therefore an intrinsic characteristic, not a bug. Those who enable PoW should not expect an increase in likes or views, but rather the satisfaction of contributing to a more resilient and less spam-prone network. The collective effectiveness of the mechanism depends on voluntary adoption by users and relays, balancing anti-spam benefits with computational costs and accessibility considerations.

In a decentralized ecosystem like Nostr, PoW represents an example of how simple cryptographic tools can be employed to solve practical moderation problems, without the need for central authorities. Its future evolution, possibly integrated with other mechanisms like micropayments, will help define the balance between openness, quality, and sustainability of the network.

#Nostr #ProofOfWork #PoW #NIP13 #Decentralization #SpamPrevention #Cryptography #RelayPolicy #Moderation #Bitcoin #OpenProtocol #CensorshipResistance