Skip to content

HTLCs

Jump to bottom
Melvin Carvalho edited this page Mar 27, 2025 · 1 revision

NIP-XYZ: Trustless Digital Commerce on Nostr using Bitcoin

Summary

This NIP proposes a method for creating, publishing, and trustlessly trading digital goods on Nostr using the Bitcoin blockchain. It leverages OP_RETURN for anchoring asset metadata and uses Hashed Time-Locked Contracts (HTLCs) for secure, trust-minimized transfers.

Motivation

To enable decentralized digital commerce, artists and creators need a way to register, advertise, and exchange digital assets securely and transparently, without centralized platforms. This NIP outlines a trustless protocol that ties together Nostr and Bitcoin.

Definitions

  • Digital Good: A unique digital item (e.g., artwork, document, music file) that can be owned and transferred.
  • OP_RETURN: A Bitcoin script opcode used to embed metadata in transactions.
  • HTLC (Hashed Time-Locked Contract): A Bitcoin smart contract that allows conditional payments based on time and cryptographic hash preimages.
  • Relay: A Nostr server that propagates and stores events.

Protocol

Step 1: Create Digital Goods

  • Assign a unique name/ID to each digital item.
  • Prepare a JSON metadata object with fields like:
    • name
    • description
    • creator_pubkey
    • timestamp
    • hash (of the content or preview)

Step 2: Anchor Goods on Bitcoin

  • Broadcast a Bitcoin transaction with an OP_RETURN output containing a compact representation (e.g., hash or CID) of the digital good's metadata.
  • The OP_RETURN record serves as an immutable on-chain anchor.
  • Specific encoding formats and usage of OP_RETURN will be covered in a separate NIP.

Step 3: Advertise on Nostr

  • Post a Nostr event with kind XYZ (TBD) referencing the asset, including:
    • A d tag with the unique name or identifier
    • A description field
    • A price
    • A reference to the Bitcoin OP_RETURN transaction ID
    • Optional contact/public key for negotiation or HTLC coordination

Step 4: Trade via HTLC

  • Buyer and seller negotiate terms via Nostr DM or out-of-band.
  • Buyer creates an HTLC on Bitcoin with the agreed price and time lock.
  • Seller reveals the preimage (e.g., a key to unlock the asset or proof of ownership) to claim the funds.
  • Buyer then uses the preimage to finalize ownership.

Step 5: Update Ownership

  • A new Nostr event is published by the buyer or seller indicating the transfer of ownership.
  • Relays can update listings to reflect the new owner, timestamp, and optionally append to a chain of custody/history.

Storage Considerations

In the case of digital art or similar assets, the actual content can be stored in decentralized or cloud-based storage systems. For example:

  • Blossom: A privacy-respecting storage system compatible with Nostr principles.
  • Other cloud storage solutions: Such as IPFS, Arweave, or encrypted S3 buckets, depending on user preference.

The metadata should include references (e.g., URLs, CIDs) to where the content is stored.

Security Considerations

  • HTLC usage must be carefully implemented to avoid loss of funds.
  • Relays must filter/verify ownership claims based on on-chain data.
  • Metadata and asset claims should be cryptographically signed.

Future Work

  • Standardize metadata schema for digital goods.
  • Define a canonical Nostr kind for these commerce events.

References

Clone this wiki locally