However su is the first of its kind. If Bitcom commands have been all about admin purposes, su is the first Bitcom command designed for powering actual application transactions themselves by acting as an authentication extension to all apps.
The following command concatenates and signs the push data items at <sign_position> with <pubkey>'s private key pair and attaches the result <signature> to the transaction, which then can be verified later:
why
Because most bitcoin wallets generate a new address for every new transaction, it is impossible to identify a user by simply looking at a sender address for a transaction.
We need ways to separately attach user identity and its proof (signature) to transactions.
There are other existing authentication protocols such as AIP and HAIP which focus on flexibility, but sometimes you may just want a simple opinionated protocol that "just works".
design
here are the design principles of su:
Umbrella protocol:su is a native Bitcom command, using the $ su prompt to indicate the authentication protocol. Thanks to its simplicity, it can easily plug into any bitcoin script protocol to attach signature.
Focus on Simplicity: the protocol spec is as minimal as it can get. No redundant metadata. Less data, lower cost. The su syntax consists of only three attributes:
<PUBKEY>
<SIGN_POSITION>
<SIGNATURE>
Convention over Configuration: To achieve simplicity, su makes certain assumptions about how the signing should be carried out. There is no "configuration". su assumes the following convention:
Hex: Uses hex encoding.
SHA256: The hex data is always SHA256-hashed before being signed.
ECDSA: Uses ECDSA to sign the data.
Base64 Signature: The final signature is represented as a Base64 string.
Easy to Filter:su always shows up at the beginning of an output script sequence (Instead of showing up anywhere within a Bitcom pipeline). This deliberate constraint makes it easy to detect, index, and filter transactions that contain signed data, through systems like Planaria.
syntax
Just like the Metanet protocol, we can think of su as an "umbrella protocol" for authenticating ANYTHING. Because of this nature, the su protocol appears at the beginning of an output script sequence.
OP_FALSE OP_RETURN $ su <PUBKEY> <SIGN_POSITION> <SIGNATURE>
Where <SIGN_POSITION> is used to select one or more pushdata within a script, and takes the following form:
Sign it with PUBKEY 03836714653ab7b17569be03eaf6593d59116700a226a3c812cc1f3b3c8f1cbd6c's private key pair (line 4)
The result should match the SIGNATURE 1b3ffcb62a3bce00c9b4d2d66196d123803e31fa88d0a276c125f3d2524858f4d16bf05479fb1f988b852fe407f39e680a1d6d954afa0051cc34b9d444ee6cb0af (line 4)
Spec website
Check out the website:
https://su.planaria.network
This is version 0.0.1. The spec is not 100% set in stone yet, so feel free to provide feedback and discuss.
Below is a copy/paste of the su specification.
what
su
is a simple protocol for authenticating bitcoin applications.su
is a Bitcom command, inspired by the Unix "su" command.However
su
is the first of its kind. If Bitcom commands have been all about admin purposes,su
is the first Bitcom command designed for powering actual application transactions themselves by acting as an authentication extension to all apps.The following command concatenates and signs the push data items at
<sign_position>
with<pubkey>
's private key pair and attaches the result<signature>
to the transaction, which then can be verified later:why
Because most bitcoin wallets generate a new address for every new transaction, it is impossible to identify a user by simply looking at a sender address for a transaction.
We need ways to separately attach user identity and its proof (signature) to transactions.
There are other existing authentication protocols such as AIP and HAIP which focus on flexibility, but sometimes you may just want a simple opinionated protocol that "just works".
design
here are the design principles of
su
:su
is a native Bitcom command, using the$ su
prompt to indicate the authentication protocol. Thanks to its simplicity, it can easily plug into any bitcoin script protocol to attach signature.<PUBKEY>
<SIGN_POSITION>
<SIGNATURE>
su
always shows up at the beginning of an output script sequence (Instead of showing up anywhere within a Bitcom pipeline). This deliberate constraint makes it easy to detect, index, and filter transactions that contain signed data, through systems like Planaria.syntax
Just like the Metanet protocol, we can think of su as an "umbrella protocol" for authenticating ANYTHING. Because of this nature, the su protocol appears at the beginning of an output script sequence.
Where
<SIGN_POSITION>
is used to select one or more pushdata within a script, and takes the following form:Here are some
<SIGN_POSITION>
examples:0
: Select the pushdata at index 00,1,2
: Select and concatenate pushdata at index 0,1,20-4
: Select and concatenate pushdata at index 0,1,2,3,40-4,7
: Select and concatenate pushdata at index 0,1,2,3,4,70-4,7-9
: Select and concatenate pushdata at index 0,1,2,3,4,7,8,9example
Note that su always appears at the beginning of an output script sequence.
1. basic
A su command implementation which signs a B protocol upload (Bitcom:
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
)Let's take a look at the relevant parts:
$
su
03836714653ab7b17569be03eaf6593d59116700a226a3c812cc1f3b3c8f1cbd6c
9
HyOG2TVUR/Hdru7G8ZMl/MNkIEcjWFNgNDNF76FbOrHletOkb8He0in6G+g4uuDq5ee/YOiBV9OOfmYZYXjdqX4=
How it works:
<html><body>hello</body></html>
3c68746d6c3e3c626f64793e68656c6c6f3c2f626f64793e3c2f68746d6c3e
f97a8935f1bb9b75c4ee5d9968e76aae46debaacde6a8126ce9298698693704d
03836714653ab7b17569be03eaf6593d59116700a226a3c812cc1f3b3c8f1cbd6c
's private key pair.HyOG2TVUR/Hdru7G8ZMl/MNkIEcjWFNgNDNF76FbOrHletOkb8He0in6G+g4uuDq5ee/YOiBV9OOfmYZYXjdqX4=
We can easily filter the transactions on Neon Genesis using:
Or on BOB using:
2. multi-field signature
The same data, but signing multiple pushdata.
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
<html><body>hello</body></html>
text/html
utf-8
index.html
31394878696756345179427633744870515663554551797131707a5a56646f417574
3c68746d6c3e3c626f64793e68656c6c6f3c2f626f64793e3c2f68746d6c3e
746578742f68746d6c
7574662d38
696e6465782e68746d6c
3aae6932baf004abc7e0355eeed704bb486f74d95bcd49232992df5aa88cb121
03836714653ab7b17569be03eaf6593d59116700a226a3c812cc1f3b3c8f1cbd6c
's private key pair (line 4)1b3ffcb62a3bce00c9b4d2d66196d123803e31fa88d0a276c125f3d2524858f4d16bf05479fb1f988b852fe407f39e680a1d6d954afa0051cc34b9d444ee6cb0af
(line 4)