Threadlocks: One-Time Commitments with Bitcoin and Nostr

[Lomanu4]

What if you could make a promise, cryptographically bind it to Bitcoin, and close it forever with one action — all while broadcasting its intent through Nostr?

Welcome to Threadlocks — a new pattern for time-boxed commitments that live at the intersection of Bitcoin and decentralized social protocols.

The Problem with Open-Ended State


Distributed systems struggle with consensus over time and state. You want to make a claim — or a promise — and prove it happened. But you don’t want to bloat a blockchain. And you don’t want to trust a centralized party. You just want a one-time, cryptographically verifiable commitment, and a public record that it occurred.

? Introducing Threadlocks


Threadlocks are a minimal, composable mechanism for one-time commitments. Inspired by the idea of single-use seals, Threadlocks build on native Bitcoin primitives (like Taproot key tweaking) and pair beautifully with Nostr, the decentralized event-based protocol.

? What’s a Threadlock?


A Threadlock is:

• Time-boxed: It exists only until it’s used.
• Single-use: Once closed, it can never be reopened.
• Cryptographically anchored: It's tied to a Bitcoin UTXO or Taproot tweak.
• Narratively threaded: Nostr events document, declare, and extend Threadlocks in social or application logic.

It’s like a fuse you can light once — but visible forever in the chain.

? How Threadlocks Work (In Plain Terms)

1. Lock the Thread


You create a commitment point:

• Usually a Bitcoin UTXO.
• Or better yet, a tweaked Taproot pubkey derived from a base key and a secret (your claim hash, a nonce, or logic payload).

This UTXO becomes your Threadlock.

2. Declare the Thread


You post a Nostr event with a special t tag or threadlock tag:


{
"kind": 3xxxx,
"content": "I claim access to channel #xyz",
"tags": [
["c", "txo:chain:txid:vout"]
]
}

This announces your intent and binds it to a specific Bitcoin output.

3. Resolve the Lock


Later, you spend that UTXO in a Bitcoin transaction, embedding the commitment proof in witness data, an OP_RETURN, or via script logic.

Once spent, that output is forever closed — your Threadlock is done.

? Why Not Just Use Smart Contracts?


Because:

• You don’t need a VM or gas fees.
• You don’t need global consensus on execution.
• You don’t want to publish logic on-chain.
• You just want a provable state transition: once, verifiably.

Threadlocks are the "less is more" of crypto commitments.

? What Nostr Brings to the Table


Nostr gives Threadlocks:

• Event sequencing (via created_at)
• Threaded logic (e tags / reply chains)
• Lightweight announcements
• Social context for commitments

Threadlocks can be:

• Referenced by future events
• Forked into multiple branches
• Validated by others watching for specific closure conditions

? Use Cases


Threadlocks enable:

• One-time claims ("I minted this", "I voted")
• ? Access control (only those with unspent Threadlocks can act)
• ?️ DAO governance (commit → vote → finalize)
• ? Game state progression (quests, puzzles, unlocks)
• ? Credential issuance (proof of training, rights, NFTs)

All without smart contracts. Just Bitcoin + Nostr.

?️ Future: Libraries, NIPs, Agents


We're working on:

• A lightweight JavaScript library for managing Threadlocks
• A NIP proposal for a standardized threadlock tag
• Autonomous agents that monitor and act on Threadlock resolution

Пожалуйста Авторизируйтесь или Зарегистрируйтесь для просмотра скрытого текста.