Spaces on Bitcoin https://spacesprotocol.org/
Spaces empowers users with a sovereign Bitcoin identity, anchored securely on the Bitcoin blockchain. Imagine a social handle that is truly yours, censorship-resistant and accessible across various protocols like Nostr, wallet naming, peer-to-peer applications, and beyond.
Spaces are nice & memorable sovereign handles anchored in Bitcoin with minimal on-chain footprint. They are easier to share compared to an npub, and can be used to sign things just like a regular public key!
What makes spaces special?
Spaces are anchored in Bitcoin, the most secure Proof-of-Work blockchain, and have the following properties:
Primary spaces are community identifiers, capped at ~3600 per year, acquired through permissionless auctions on the Bitcoin blockchain.
Each primary Space is a community that may issue sovereign handles off-chain known as subspaces.
Spaces AND subspaces (once allocated) are permissionless and as secure as Bitcoin itself! No bridges, slashing, or any kind of optimistic security.
The spaces protocol is designed with zk-light clients in mind making these identities verifiable on resource constrained devices.
Subspaces do not need to trust the community operator once allocated, and they can do 100% of their transactions on-chain if they wish.
Minimal on-chain footprint.
Spaces vs. ENS
For full verification, you can sync the entire spaces protocol with a pruned Bitcoin full node on an old Raspberry PI. Bitcoin is the most secure Proof-of-Work blockchain today, and it's relatively lightweight compared to running an Ethereum node. The majority of ENS integrations trust centralized third-parties defeating the whole purpose of decentralized identities.
Quick start
Setup spaces on mainnet
Install Bitcoin Core or Knots
Install Bitcoin Core from bitcoin.org/en/download.
Edit bitcoin.conf in ~/Library/Application Support/Bitcoin/ (macOS) or ~/.bitcoin/ (Linux).
Add these lines to bitcoin.confto configure RPC auth:
rpcuser=<your-username>
rpcpassword=<your-password>
Install Spaces
spaced is a tiny layer that connects to Bitcoin Core over RPC and scans transactions relevant to the protocol.
Install the latest version:
curl --proto '=https' --tlsv1.2 -sSf https://install.spacesprotocol.org | sh
Verify installation
spaced --version
space-cli --version
Run Spaces
Ensure Bitcoin Core is fully synced
Start Spaces daemon
spaced --bitcoin-rpc-user <your-rpc-user> --bitcoin-rpc-password <your-rpc-password>
Create a wallet
Create the default wallet and get an address to receive coins
space-cli createwallet
space-cli getnewaddress
Send some BTC to the address you get and check your balance
space-cli balance
Auction process
In short, top level spaces are community identifiers limited to ~3600 spaces a year. Every day, the top 10 highest-bid spaces advance from pre-auctions to auctions learn more.
Opening an auction
You can check the explorer for currently open auctions . For example to open an auction for the space @bitcion
space-cli open bitcoin
Placing a bid
Find one of the spaces currently in auction and place a bid (amount is in sats)
space-cli bid nostr 1500
Check status of your Spaces
space-cli listspaces
This will list all spaces you own and spaces currently in auction.
Claiming a space
If you're currently winning and the space entered the claim period, you can register it!
space-cli register bitcoin
You may also watch the status of auctions on the explorer
Publish records
Once you register a space, you can publish records over the Fabric DHT without adding any on-chain bloat!
Fabric DHT
Fabric enables you to sign Nostr events, and DNS records with a Bitcoin sovereign handle (a space), or a public key (an npub), and publish them to the Fabric peer-to-peer network without adding any bloat to the Bitcoin blockchain!
Who can use it?
Own a Space? Publish forward records tied to your handle e.g., @example. To grab one, see quick start or buy one from a secondary marketplace.
No Space? No Problem! Use your npub to publish Nostr events (like NIP-65 relay lists) instead.
npm install -g @spacesprotocol/fabric
and verify installation
fabric --version
beam --version
By default, the beam tool will try to load trust anchors from http://127.0.0.1:7225/root-anchors.json to verify space handles. If you don't have a spaces spaces client, you can load the file from an external source that you trust e.g.
export FABRIC_REMOTE_ANCHORS=https://bitpki.com/root-anchors.json
Don't trust, verify! Run your own Bitcoin full node and spaces client.\
DNS Records
beam <space> <record-type>
For example:
beam @buffrr TXT
Nostr events
beam <space-or-pubkey> <event-kind> <optional-d-tag>
Publishing records by handle
If you own a space, you can publish forward records resolvable by your handle e.g. @example
Publish DNS records
Spaces use the DNS class code 2 (CLASS2) to further distinguish them from regular domains in the IN class.
Create a zone file:
Add your records to a file and save it e.g. myexample.zone
@example. 3600 CLASS2 TXT "Hello Fabric"
@example. 3600 CLASS2 A 127.0.0.1
Remember to replace @examplewith your space name, and remember to put the .at the end. It's not a typo in DNS zone files!
Sign the file
space-cli signzone @example myexample.zone > signed.event.json
The wallet will turn it into a signed Nostr event and bundles proof information to make it ready for publishing to Fabric.
Publish it with beam
beam publish signed.event.json
Publish Nostr Events
To sign a forward event (lookup by a space handle), you could do the following:
Note: there's no standard yet for using kind 0 for forward lookups yet but it's here as an example.
{
"kind": 0,
"created_at": 1679673265,
"content": "{"name": "Alice", "about": "A Nostr enthusiast", "picture": "https://example.com/avatar.jpg\"}",
"tags": []
}
space-cli signevent @example event.json --anchor > event.signed.json
For lookups by handle, you should use the --anchoroption to include trust path information and append the spacetag to the event.
beam publish event.signed.json
Publishing records by pubkey
If you have an npub, you could publish events on Fabric. This is still experimental and no Nostr client supports lookups through Fabric yet. Here's an example publishing a NIP-65 relay list:
{
"kind": 10002,
"created_at": 1679673265,
"pubkey": "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322",
"tags": [
["r", "wss://alicerelay.example.com"],
["r", "wss://brando-relay.com"],
["r", "wss://expensive-relay.example2.com", "write"],
["r", "wss://nostr-relay.example.com", "read"]
],
"content": "",
"sig": "<signature>"
}
Then publish it
beam publish event.signed.json
Auctions
Spaces enable auctions with arbitrary bids implemented directly on the Bitcoin blockchain. Auctions are designed as a fair competition for naming rights. Instead of distributing spaces on a first-come, first-served basis, the protocol employs a bidding system. This approach helps ensure that valuable names don't all end up concentrated in the hands of a few quick actors.
Spaces are restricted to 10 a day to prevent market flooding and to ensure each name receives adequate attention during auctions.
Space lifecycle
Pre-auctions
Users propose spaces they're interested in by placing bids
Each proposed name accumulates interest based on the value of the bids it receives
Names advance to the auction phase when they become one of the top 10 highest-bid spaces on a given day
The protocol releases up to 10 spaces per day which is about 3600 per year
Auctions
Once a name receives sufficient interest by being one of the top 10 highest-bid spaces on a given day, it enters the auctions phase.
Auctions last for 10 days.
Anyone can bid just as they normally did in pre-auctions.
To prevent sniping, any last-minute bids extend the auction by one day.
Claim Period
Once the 10-day auction concludes, the winning bidder may claim their space.
It's crucial for the winner to claim immediately because:
The auction remains open indefinitely until the space is claimed.
Someone can still outbid you during this period.
Where do proceeds from auctions go?
All proceeds from the auctions are burned. This means that the BTC used for bids is permanently removed from circulation. This approach ensures that no single entity profits from the auctions. Names aren't anyone's property to begin with! The Spaces protocol is built on cypherpunk principles, emphasizing decentralization, privacy, and individual empowerment that means:
No Premine: There was no initial allocation of names to the developers or any centralized entity.
No token: BTC is the currency!
Open and Permissionless: Anyone can participate in the auctions and use the protocol without seeking permission from a central authority.
Transparent: All auctions happen directly on the Bitcoin blockchain.
Name resolution
The Spaces protocol functions primarily as a Bitcoin certificate authority, minimizing on-chain footprint. Its trustless nature makes it an ideal foundation for Peer-to-Peer (P2P) protocols that leverage spaces as trust anchors, enabling off-chain record storage and other use cases.
Fabric
Fabric is a trustless, distributed DNS resolver for spaces that enables Bitcoin-signed zone file publication on a permissionless DHT without on-chain storage. You can run a Fabric node to host records or pay others to "pin" your signed zone file.
Bitcoin Wallet Naming
The Spaces protocol currently offers experimental support for resolving spaces to payment addresses. You can experiment with this feature using the spaces wallet:
Upcoming changes
We're in the process of formalizing the format for space records checkout SIP-02. You will be able to resolve spaces to silent payment addresses, Nostr, onion services and more.
Join us on Telegram to contribute or discuss ideas and stay up to date! https://t.me/spacesprotocol
Subspaces
Subspaces are individual identities within a community Space. Examples of this hierarchical structure:
alice@nostr
bob@bitcoin
mike@x
Here, Alice, Bob, and Mike are subspaces or unique identities within their respective community spaces @nostr, @bitcoin, and @x.
The Spaces protocol is being built in two stages. Initially, launch of the base layer on the Bitcoin mainnet, which includes on-chain auctions for the top-level spaces.
Work on subspaces will begin after the mainnet launch and will be implemented as a soft fork.
Subspaces are key to scalability as they enable the creation of millions of individual identities within each community space. They have a much lower on-chain footprint, making them more accessible and affordable for everyone!
Key Benefits
Subspaces, unlike traditional domains, are sovereign and permissionless identities.
Once issued, they cannot be taken down by their respective community.
They can do 100% of their transactions on-chain if they wish treated the same as a parent space.
They are cost effective to maintain.
More details on this protocol: https://docs.spacesprotocol.org/deep-dive/spec
Marketplace: https://spaces.market/
Explorer: https://explorer.spacesprotocol.org/
Wallet: https://akron.io/