DRAFT — 2026-02-17 Author: SatoshiSan
NoSecond.Best (NSB) is a decentralized naming protocol anchored on the Bitcoin timechain, providing human-readable payment addresses that work today via DNS and evolve toward full decentralization.
| Phase | Format | Resolution | Trust Model |
|---|---|---|---|
| 1 — Gateway | ₿alice@nosecond.best |
DNS (BIP-353) + HTTPS gateway | Centralized (our server) |
| 2 — Federated | ₿alice@anydomain.com |
Any domain runs a resolver | Federated (domain operators) |
| 3 — Sovereign | ₿alice (no domain) |
On-chain + Nostr relays | Trustless (Bitcoin + cryptography) |
₿user@domain (display),
resolved via DNS TXT records at
user.user._bitcoin-payment.domainNSB builds on BIP-353 for Phase 1 compatibility, then extends beyond it by anchoring name ownership on-chain and enabling decentralized resolution.
₿<name>@<domain> # Phase 1 & 2 (BIP-353 compatible)
₿<name> # Phase 3 (domain-free, on-chain only)Name rules: - Lowercase alphanumeric + hyphens + underscores - 1-64 characters - No leading/trailing hyphens - Reserved names (see §7) controlled by NSB initially
Every name is bound to a secp256k1 keypair (compatible with both Bitcoin and Nostr).
Name registrations are batched and anchored to Bitcoin L1 using an OP_RETURN merkle commitment:
OP_RETURN <NSB_PROTOCOL_TAG> <merkle_root> <block_height> <batch_number>Where: - NSB_PROTOCOL_TAG = 0x4e534200
(“NSB\0”) - merkle_root = root of a merkle tree containing
all registrations in this batch - block_height = reference
block height - batch_number = sequential batch counter
Each leaf is the SHA256 hash of a registration record:
{
"name": "alice",
"domain": "nosecond.best",
"owner_pubkey": "02abc123...",
"registered_at": 880000,
"expires_at": 932000,
"nonce": "random_bytes_hex"
}Resolution data is NOT stored on-chain (it changes too often). Instead, it lives on Nostr relays and is served by the NSB gateway.
Name owners publish resolution data as signed Nostr events:
{
"kind": 38383,
"tags": [
["d", "alice@nosecond.best"],
["onchain", "bc1qxyz..."],
["lightning", "lno1qgsq..."],
["lnurl", "lnurl1dp68gurn8ghj7..."],
["bolt12", "lno1..."],
["nostr", "npub1abc..."],
["silent", "sp1q..."],
["updated", "1708200000"]
],
"content": "",
"pubkey": "<owner_pubkey_hex>",
"created_at": 1708200000,
"id": "...",
"sig": "..."
}Event kind 38383 (parameterized replaceable event):
- d tag = name identifier (ensures only one active record
per name) - Payment method tags = what this name resolves to - Signed by
the owner key = verifiable by anyone - Replaceable = owner publishes new
event to update
Supported resolution targets: | Tag | Description |
|—–|————-| | onchain | On-chain Bitcoin address (bc1…) | |
lightning | Lightning node pubkey or connection string | |
lnurl | LNURL pay endpoint | | bolt12 | BOLT12
offer | | silent | BIP-352 silent payment address | |
nostr | Nostr public key | | web | Website URL
|
The nosecond.best gateway reads Nostr events and serves them via standard protocols:
DNS (BIP-353 compatible):
alice.user._bitcoin-payment.nosecond.best. IN TXT "bitcoin:bc1qxyz...?lno=lno1..."HTTPS (Lightning Address / LNURL compatible):
GET https://nosecond.best/.well-known/lnurlp/alice
→ { "callback": "...", "tag": "payRequest", ... }API (for apps):
GET https://nosecond.best/api/v1/resolve/alice
→ {
"name": "alice",
"owner": "02abc123...",
"onchain": "bc1qxyz...",
"lightning": "...",
"verified": true,
"merkle_proof": "...",
"anchor_txid": "abc123..."
}Any wallet can resolve names without the gateway:
38383 events with
d tag matching alice@nosecond.bestWallet → Nostr Relay: REQ ["REQ", "sub1", {"kinds": [38383], "#d": ["alice@nosecond.best"]}]
Relay → Wallet: EVENT {...}
Wallet: verify event.pubkey == registered owner for "alice"
Wallet: extract payment info from tagsFull verification that ₿alice@nosecond.best is
legitimate:
1. Find on-chain anchor tx with NSB_PROTOCOL_TAG
2. Extract merkle_root from OP_RETURN
3. Verify alice's registration record against merkle_root (using merkle proof)
4. Extract owner_pubkey from registration record
5. Find latest kind:38383 Nostr event for "alice@nosecond.best"
6. Verify event is signed by owner_pubkey
7. Extract payment addresses from event tags
8. ✅ Verified: these addresses belong to the registered owner of "alice"User NSB Service Bitcoin L1
| | |
|-- 1. Check availability ---->| |
|<--- "alice" is available ----| |
| | |
|-- 2. Submit registration --->| |
| (name + owner pubkey) | |
| | |
|<-- 3. Lightning invoice -----| |
| | |
|-- 4. Pay invoice ----------->| |
| | |
|<-- 5. Confirmation + --------| |
| merkle proof (pending) | |
| |-- 6. Batch anchor tx ----->|
| | (OP_RETURN merkle root) |
| | |
|<-- 7. Final confirmation ----| |
| (with txid + proof) | |
| | |
|-- 8. Publish Nostr event --->| (relays) |
| (resolution data) | |
| | |
✅ ₿alice@nosecond.best is live |User Nostr Relays NSB Gateway
| | |
|-- Publish new kind:38383 --->| |
| (signed by owner key) | |
| |--- event propagation -->|
| | |-- update DNS/API
| | |
✅ Resolution updated (no on-chain tx needed)Current Owner NSB Service Bitcoin L1
| | |
|-- Request transfer --------->| |
| (name, new_owner_pubkey, | |
| signed by current owner) | |
| | |
|<-- Lightning invoice --------| |
| | |
|-- Pay ---------------------->| |
| |-- Batch anchor -------->|
| | (transfer record |
| | in merkle tree) |
| | |
✅ New owner publishes their Nostr resolution eventA domain owner (e.g., bitcoin.org) can offer
₿name@bitcoin.org by:
Register domain on-chain — Prove domain ownership via a DNS TXT record + on-chain anchor
_nsb-verify.bitcoin.org IN TXT "nsb:verify:<owner_pubkey>"Then anchor this claim on Bitcoin (batched with other operations)
Run an NSB resolver — Open-source software that:
Or delegate to nosecond.best — We host the resolver for them (SaaS model)
name@domain
identifier₿alice (no @ sign)When the protocol has enough adoption: - Names registered without a
domain resolve against a global on-chain registry - No
single entity controls the namespace - Resolution still via Nostr
events, but the d tag is just alice (no
domain) - First-come-first-served, anchored on Bitcoin
₿alice@nosecond.best →
₿alice migration path needed| Category | Examples | Price |
|---|---|---|
| Ultra-premium (1-3 chars) | ₿btc, ₿pay, ₿sat | Auction / offers |
| Premium (common words) | ₿alice, ₿wallet, ₿shop | 100,000+ sats |
| Standard (4+ chars) | ₿satoshisan, ₿mystore | 10,000 sats |
| Long (10+ chars) | ₿mylongusername | 1,000 sats |
Top 1000 common first names, top 500 common words, brand names (released on verified request), Bitcoin-related terms (btc, bitcoin, satoshi, lightning, etc.)
| Stream | Description |
|---|---|
| Name registration fees | Primary revenue — Lightning payments for registration |
| Premium name sales | Auction/fixed price for desirable names |
| Renewal fees | Recurring revenue from yearly renewals |
| Domain hosting (Phase 2) | SaaS for third-party domains |
| API access | Free tier + paid for high-volume commercial use |
| Component | Technology |
|---|---|
| Gateway server | Rust or TypeScript |
| Bitcoin interaction | Bitcoin Core RPC / Electrum |
| Lightning payments | LND / CLN / LDK |
| Nostr integration | nostr-tools / custom relay client |
| DNS serving | PowerDNS or custom authoritative server |
| Database | PostgreSQL (indexer state) |
| Frontend | Web app for registration + management |
This is a living document. Version 0.1 — expect significant changes as the protocol is refined.