Developers shouldn’t be working for the wallet; the wallet should be working for the developer.
– Jack Liu at Coingeek London 2020.
BSVABI is a specification proposal from Dean Little of Bitping that any existing or future wallet could implement in order to streamline access to Bitcoin applications.
Identity
A simple structure is proposed for IDs—simply broadcast a transaction with an OP_RETURN output containing a JSON object of two public keys that act as owner and active keys.
Inb4 ‘Keys are not identity!’—this transaction only serves to establish an identity; since the ID is embedded in a Bitcoin transaction, it can be validated on-chain via an SPV proof.
An interesting concept is the ability to apply Proof of Work to your identity. The transaction ID of possible owner/active key permutations can be hashed repeatedly to achieve a certain number of leading zeroes, or a magic number prefix such as ‘21e8’.
Imagine a service provider who only allows users to access if they have at least six leading zeroes in their identity. This barrier to entry can be effective against fake accounts that infect most popular platforms we use today.
If you’re using something other than SPV proofs as a store of signing keys for identity, you’re gonna get rekt.
— Dean ✪ 利迪恩 (@deanmlittle) February 25, 2020
The active key’s purpose is to link to wallets such that they can perform the following six standard functions on a user’s behalf:
– Sign
– Login
– Encrypt
– Decrypt
– Verify
– Send (money)
Almost all existing Bitcoin SV applications require implementations of these functions today.
The segregation of owner and active keys intends to remove the need to trust a wallet or platform with ownership of their identity yet can prove they own the ID by signing with the owner key at any time.
Bitcoin service providers can easily extend this open protocol to account for subsequent actions and supplemental information of Metalink IDs to further build reputation.
As the Bitcoin whitepaper states, today’s services must harass users for lots of sensitive information, partially due to the lack of a single source of truth representing their identity.
With this solution where services begin to attest for users over time, a chain of digital trust can be formed and publicly verified.
ABI implications for wallets
The ABI spec is fairly technical and can be deeply explored here, but its goal is to streamline communication between applications and wallets by establishing a schema on-chain.
The schema can then be imported by referencing its Transaction ID, allowing the wallet to perform any additional functions specified such as ‘Like’ or ‘Post’ in addition to the six standard functions referenced above can be leveraged.
Currently, the existing wallets like Money Button, RelayX and DotWallet rely on legacy Internet protocols such as HTTPS, DNS and OAuth to validate user access to other Bitcoin platforms.
Source: Twetch
With this proposal, wallets would leverage the superior security model of Bitcoin, rather than these duct-taped, band-aid solutions created to address the poor security model of the Internet.
In the timestamped link below, Andrew Desantis describes the fate for future platforms not on par with Bitcoin’s security model:
An added benefit of wallets adhering to something like Metalink is streamlined application development.
If developers building apps can have these common, standard functions abstracted away for them, they can focus their time on the unique features of their platform, giving builders on Bitcoin SV a huge advantage in bringing a product to market.
Discussion and recommendations to the proposal are encouraged, so please check out the proposal at BSVABI.org and submit feedback via a pull request on its GitHub.
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.
