Naming protocols atop Bitcoin SV

When evaluating yet another new alt coin in the digital currency space, a concept known as Zooko’s Triangle is often leveraged which defines three traits that a network protocol should strive for: “decentralization,” “human-meaningful” and “secure.”

Source: Wikipedia

Of course, the need to solve this trilemma assumes that Bitcoin cannot scale, justifying the creation of alternative network protocols in hopes of meeting these three requirements (i.e. Namecoin). Bitcoin easily meets the “decentralized” and “secure” qualities but does not handle the “human-meaningful” part at the base layer. As with alt coins, this gap does indeed justify 2nd layer solutions atop Bitcoin to complete the triangle.

The first proposed solution on BSV to namespaces was Paymail. Paymails are email-like payment aliases and a proposed identity solution. Paymail has significant adoption across the space (almost all wallets and most apps) and is much preferred over 34-character ugly public key hashes (addresses).

Paymails are tied to the domain owner that issues them, thus bound, and secured by DNS. This means paymails are revokable at any point, therefore are not “decentralized” and cannot be an identity solution. For example, no matter what crimes you commit no government or entity in the world revoke one’s identity.

Paymail meets two points of Zooko’s triangle.

Xoken introduced the Allegory Naming Protocol in early 2020 that sits atop the BSV ledger, attaching names to a UTXO. Namespaces are defined in an OP_RETURN output and can grant the prefix owner to create new names under that prefix. Jackson Laskey elaborates on this concept in his article, “How @jack Joins Twetch”. The names are owned by the private key holder of the UTXO thus are fully ‘Decentralized’ (and of course Human-Readable).

naming-protocols-atop-bitcoin-sv_setion3
Source: Xoken

However, these names and validation are not secured and enforced by the Bitcoin protocol and must be done so by its participants on the 2nd layer. This implementation has scaling challenges that all token protocols on BSV face which is the “Back to Genesis” problem. Names could be spoofed via arbitrary Bitcoin outputs so participants must track each transaction back to the “Genesis” transaction of the name to ensure they have the valid one.

Xoken Allegory meets two points of Zooko’s triangle.

Source: NBdomain

NBdomain proposes a domain naming system atop the BSV protocol. The domains are linked to a set of keys, so like Paymail and Allegory users can receive payment via their on-chain alias. The protocol defines how ownership is preserved as well as specifications for purchases and sales. All actions are UTXO-based, thus “decentralized.”

Like Allegory, because NBdomain defines actions and metadata in OP_RETURN outputs so the validation must be done by network participants.

NBdomain meets two points of Zooko’s Triangle.

Any solution that requires arbitrary metadata on Layer 2 of the ledger cannot meet the security standards of Bitcoin itself. Each token solution without exception are included in this flaw; they all require validators to abide by the same ruleset without Proof of Work, therefore are not Byzantine Fault Tolerant. Nor can any naming or identity solution be “decentralized” that are simply entries on some private companies’ database. That stated, these flaws are not necessarily a problem. As all naming protocols face these common issues, they all compete on an even playing ground.

This means that likely the one that is the easiest to use, most robust and ends up with the largest network effect will win in the end, deprecating the others.

New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.

[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]
[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]