unwriter / bitcom Goto Github PK
View Code? Open in Web Editor NEWBitcoin Computer
Bitcoin Computer
I have an existing BitCom prefix which is created before. Now I'm using another computer and I'd like to login.
Is there any way to login? I only have BitCom prefix address.
Example: "Upload a video, store its filename and frame rate, and then set admin rights, all in a single transaction, but using 3 separate protocols."
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] video/mp4 |
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60 |
1M16gTfEL8f6SkXnTzBepF56KDNG9Qka7Y SET ADMIN
Following the Unix Pipe (|
) system design, we can:
This spec proposal is inspired by
This pipeline idea DOES NOT require mandatory usage of the Bitcom convention (Usage of Bitcoin address as "prefix" instead of using a centralized registry), any protocol can adopt this today.
But the Bicom CLI intends to implement this, and will be much more synergistic if the protocols that adopt this pipeline scheme adopt the Bitcom convention since the pipeline proposal assumes a world where there are infinite number of protocols, which isn't possible if all protocols are managed in a central repository, in a human curated fashion.
The pipeline can potentially solve the immediate problem of:
filename
or fps
(frames per second), resolution
, etc.The key insight of Bicom pipeline:
You can pipe two protocols together like unix programs.
Let's think of the B:// protocol for example.
Instead of packing every possible metadata into the single protocol, we could:
Without a pipeline feature, whenever we want to add a new feature or an attribute, we will have to extend the base protocol itself, and the protocol will become larger and larger as time goes on, collecting technical debt, and become a nightmare to maintain:
OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] image/png binary flower.png ...
But what if we can make each protocol as minimal as possible, and then pipe them into one another?
With a piping feature, we could create a combination of two or more protocols that pipe linearly from one to the next:
B://
We can write a file using the same simple B://
protocol:
OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] video/mp4
Now, the protocol ONLY has 2 arguments: DATA and Media Type.
The rest can be determined by passing the B://
output to another protocol and let them take care of it. For example let's say we want to create a video storage system:
Let's think of a hypothetical protocol that lets you:
It would be like JavaScript's Object.assign()
For example, the following command is executed independently,
OP_RETURN 1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60
It would return an object with the video.mp4
and 60
as attributes.
However if we pass in the File object from the b://
protocol, like this:
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] video/mp4 |
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60
It would return an aggregate object containing all of the [DATA]
, video/mp4
, video.mp4
, and 60
attributes.
This command is saying,
b://
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy
which happens to be a video metadata protocol, which attaches additional metadataWith this we can ensure that this blob is atomically associated with this set of metadata.
Important: Note that the ordering is important. In this scenario, the metadata protocol can accept any random object, but the
b://
protocol is a sole data producer protocol and cannot accept an input from another protocol. This will be explained below in FAQ.
Also, if you simply want to store a blob with media type and nothing else, you can do so as well, you just need to end with B://
.
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] image/png
You have a choice.
By following the unix pipeline system, we can create a sequence of as many OP_RETURN protocols as we want.
You can pipe as many protocols as you want.
For example, there can be 3 protocols in the pipeline:
B://
for writing a data blobThe important part here is that each protocol can be a standalone module that:
But in this particular case we can write an OP_RETURN program that pipes one into another:
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] image/png |
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60 |
1M16gTfEL8f6SkXnTzBepF56KDNG9Qka7Y SET ADMIN
Lastly, if you decide to adopt the Bitcom OS protocol into your application protocol, you can use the $ echo A > B
command to define the schema directly in a standardized manner, so other apps can look it up in order to make sense of what the inputs and outputs from the protocol represent within the context of the Bitcom pipeline.
The great part about this approach is that you DO NOT have to decide how your protocol will interact with the outside world from the beginning.
At first you can just define a self contained protocol that doesn't interact with the outside world but does one thing.
And as you become more comfortable with opening up access, you can define a schema that describes:
For example, I can create a blob upload protocol like b://
WITHOUT any pipeline schema.
Then people may want to either fork the protocol to build their own protocol, or ask me for certain features they want to use from the b://
protocol. Then based on this feedback I can come up with an "Open API" of the b://
protocol which is essentially a schema definition of inputs and outputs within the pipeline system.
And once defined, other protocol developers can easily reference the schema and build their own application protocols by mashing up with my protocol.
And the best part: this schema itself can be stored on-chain using the Bitcom $ echo
command.
&
than a |
?There's a subtle but important difference.
&
implies that there is no order between commands, whereas |
assumes a single linear order of execution. Without a fixed order, various apps may use these protocols in various orders, which will make it hard to query for them.
For example, let's say we're using &
instead of |
to describe a file upload + naming + admin rights assignment. It can be expressed in 6 different ways:
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] video/mp4 &
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60 &
1M16gTfEL8f6SkXnTzBepF56KDNG9Qka7Y SET ADMIN
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] video/mp4 &
1M16gTfEL8f6SkXnTzBepF56KDNG9Qka7Y SET ADMIN &
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60
OP_RETURN
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60 &
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] video/mp4 &
1M16gTfEL8f6SkXnTzBepF56KDNG9Qka7Y SET ADMIN
OP_RETURN
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60 &
1M16gTfEL8f6SkXnTzBepF56KDNG9Qka7Y SET ADMIN &
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] video/mp4
OP_RETURN
1M16gTfEL8f6SkXnTzBepF56KDNG9Qka7Y SET ADMIN &
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60 &
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] video/mp4
OP_RETURN
1M16gTfEL8f6SkXnTzBepF56KDNG9Qka7Y SET ADMIN &
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] video/mp4 &
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60 &
This will make it very difficult to query the pattern from the blockchain through indexing services such as bitdb or realtime push subscription services such as bitsocket
However with a fixed sequence of what each protocol expects via pipeline (|
), we only have one sequence:
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] video/mp4 |
1EKrfyTD6UoXR85vpfxZ7e8h2h8C5XEroy video.mp4 60 |
1M16gTfEL8f6SkXnTzBepF56KDNG9Qka7Y SET ADMIN
which means we only need one query to deal with this specific template.
Of course, the &
feature also has a great potential use case and will be supported in the future, but at this stage, if we were to introduce one more feature to solve as many problems as possible, it makes more sense to use the |
.
The main value proposition of pipeline system is:
Hi command:
bit echo "Hi, this is a protocol for pageshot app. PageShot automatically generates images from provided URL" to README
produced
"data": [
"$",
"echo",
"hi, this is a protocol for pageshot app. pageshot automatically generates images from provided url",
"to",
"readme"],
all strings were lowecased unexpectedly :)
Currently a base58 encoded bitcoin address is used as a protocol identifier.
For example WeatherSV uses "1LtyME6b5AnMopQrBPLk4FGN8UBuhxKqrn", a 34 byte string. In its raw form, this data requires 25 20 bytes.
Base58 Pro's - inbuilt checksum, human readable (kind of)
Base58 Con's - it's big
Is it worth switching to the raw form for efficiencies sake?
Bitcom OP_RETURNs should include OP_FALSE as the first character. Bitcom is still using and old version of the datapay library which has not been updated to include OP_FALSE.
Trying to initialize an admin address for Open Directory using bit init
I'm getting the following error:
bit init
events.js:167
throw er; // Unhandled 'error' event
^Error: EISDIR: illegal operation on a directory, open 'C:\Users\Aristophanes\opendirectory-admin.bit'
Emitted 'error' event at:
at fs.open (internal/fs/streams.js:288:12)
at FSReqCallback.oncomplete (fs.js:148:20)
Proposed by @torusJKL
Original Proposal on Bitcoin: https://viewer.bitdb.network/#e52864d04efa56d94b1a3cf6347a752ed4114349caf191ed6ea08f865643e085
Further explanation: https://twitter.com/_unwriter/status/1089517509437464578
Instead of thinking of Bitcom as a "global computer that all application protocols register to",
think of Bitcom as "an OS (operating system) that gets installed into protocols".
Let's say your OP_RETURN protocol for a game controller looked like this:
1. Up
OP_RETURN 1Frooui3mqRQa1nAv8VRUDaRLxSXRFyNXA Up
2. Down
OP_RETURN 1Frooui3mqRQa1nAv8VRUDaRLxSXRFyNXA Down
3. Left
OP_RETURN 1Frooui3mqRQa1nAv8VRUDaRLxSXRFyNXA Left
4. Right
OP_RETURN 1Frooui3mqRQa1nAv8VRUDaRLxSXRFyNXA Right
5. A Key
OP_RETURN 1Frooui3mqRQa1nAv8VRUDaRLxSXRFyNXA A
6. B Key
OP_RETURN 1Frooui3mqRQa1nAv8VRUDaRLxSXRFyNXA B
To "install Bitcom OS" to your protocol, you can "activate" the Bitcom OS by starting your
OP_RETURN with "$" to indicate the "Admin mode":
OP_RETURN 1Frooui3mqRQa1nAv8VRUDaRLxSXRFyNXA $ echo "Torus Game Controller" to description
Basically,
After running bit init
command, I get following error.
/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-explorers/lib/insight.js:138
throw e;
^
Invalid Argument
Error
at new NodeError (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-lib/lib/errors/index.js:20:41)
at Object.checkArgument (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-lib/lib/util/preconditions.js:14:13)
at new AddressInfo (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-explorers/lib/models/addressinfo.js:20:5)
at Function.AddressInfo.fromInsight (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-explorers/lib/models/addressinfo.js:33:10)
at Request._callback (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-explorers/lib/insight.js:133:26)
at Request.self.callback (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/request/request.js:185:22)
at Request.emit (events.js:321:20)
at Request.<anonymous> (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/request/request.js:1154:10)
at Request.emit (events.js:321:20)
at IncomingMessage.<anonymous> (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/request/request.js:1076:12) {
message: 'Invalid Argument',
stack: 'Invalid Argument\n' +
'Error\n' +
' at new NodeError (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-lib/lib/errors/index.js:20:41)\n' +
' at Object.checkArgument (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-lib/lib/util/preconditions.js:14:13)\n' +
' at new AddressInfo (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-explorers/lib/models/addressinfo.js:20:5)\n' +
' at Function.AddressInfo.fromInsight (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-explorers/lib/models/addressinfo.js:33:10)\n' +
' at Request._callback (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/bitcore-explorers/lib/insight.js:133:26)\n' +
' at Request.self.callback (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/request/request.js:185:22)\n' +
' at Request.emit (events.js:321:20)\n' +
' at Request.<anonymous> (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/request/request.js:1154:10)\n' +
' at Request.emit (events.js:321:20)\n' +
' at IncomingMessage.<anonymous> (/Users/oscar/.nvm/versions/node/v13.7.0/lib/node_modules/bitcom/node_modules/request/request.js:1076:12)'
}
Check out the website:
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.
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:
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".
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.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_POSITION> ::= <digit>
| <digit>-<digit>
| <SIGN_POSITION>,<SIGN_POSITION>
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,9Note that su always appears at the beginning of an output script sequence.
A su command implementation which signs a B protocol upload (Bitcom: 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
)
0 OP_FALSE
1 OP_RETURN
2 $
3 su
4 03836714653ab7b17569be03eaf6593d59116700a226a3c812cc1f3b3c8f1cbd6c
5 9
6 HyOG2TVUR/Hdru7G8ZMl/MNkIEcjWFNgNDNF76FbOrHletOkb8He0in6G+g4uuDq5ee/YOiBV9OOfmYZYXjdqX4=
7 |
8 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
9 <html><body>hello</body></html>
10 text/html
11 utf-8
12 index.html
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:
{
"v": 3,
"q": {
"find": {
"out.s4": "03836714653ab7b17569be03eaf6593d59116700a226a3c812cc1f3b3c8f1cbd6c"
}
}
}
Or on BOB using:
{
"v": 3,
"q": {
"find": {
"out.tape.cell.s": "03836714653ab7b17569be03eaf6593d59116700a226a3c812cc1f3b3c8f1cbd6c"
}
}
}
The same data, but signing multiple pushdata.
0 OP_FALSE
1 OP_RETURN
2 $
3 su
4 03836714653ab7b17569be03eaf6593d59116700a226a3c812cc1f3b3c8f1cbd6c
5 8,9,10,11,12
6 1b3ffcb62a3bce00c9b4d2d66196d123803e31fa88d0a276c125f3d2524858f4d16bf05479fb1f988b852fe407f39e680a1d6d954afa0051cc34b9d444ee6cb0af
7 |
8 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
9 <html><body>hello</body></html>
10 text/html
11 utf-8
12 index.html
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)A Schema for Bitcoin Script, Stored on Bitcoin.
Define, Publish, and Consume Bitcoin Script Schema, over Bitcoin.
In the past when someone wanted to create an "overlay protocol" on top of Bitcoin script, they didn't have many options but to do it the old way of storing the protocol specification:
But this is far from ideal because:
This proposal solves above problems with a Bitcoin script schema that is:
In this section we will walk through a workflow of how this schema can be used:
There are two things to note about Bitcoin scripts:
For a schema to work, we should be able to express what each push data means while taking above factors into account.
And in this proposal, I suggest a schema scheme that's inspired by the BitDB transaction serialization format, because BitDB has already solved all these problems for its own use case. (However anyone can come up with their own schema scheme and replace with their scheme as well, because the idea itself is applicable to any type of schema).
here's an example schema for the B:// protocol:
{
"v": 1,
"s": {
"out.s2": "{{blob}}",
"out.s3": "{{mediatype}}"
}
}
v
: The schema scheme version numbers
: Schema descriptionInside the s
, we specify key/value pairs of Bitcoin script push data & its values. If a value is wrapped inside a {{ }}
pair, that means it's a schema attribute.
In above case, the schema is saying:
out.s2
is used to represent blob
.out.s3
is used to represent mediatype
.So now that we've decided on the schema, how do we publish it to the blockchain itself?
You can do this using the Bitcom scheme. More specifically you can use the $ echo
command to write a file to the protocol's root folder. (Note that this syntax is based on the upcoming "Bitcom as OS" update), and therefore the $ echo
command is embedded into the 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
application protocol (instead of Bitcom being a standalone protocol)
Here's an example of writing the schema to B://
protocol's root folder, using the Bitcom scheme:
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
$
echo
{"v":1,"s":{"out.s2":"{{blob}}","out.s3":"{{mediatype}}"}}
to
schema.json
Now that the schema has been published, you have opened up an "official" API endpoint for your protocol.
This means now others can look up the schema to understand what each push data means in your protocol transactions.
Here's a Bitquery to find the schema transaction:
{
"v": 3,
"q": {
"find": {
"out.s1": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut",
"out.s2": "$",
"out.s3": "echo",
"out.s5": "to",
"out.s6": "schema.json"
}
},
"r": {
"f": "[{schema: .out[0].s4}]
}
}
The example above is a simple one because there's only a single pattern. But sometimes you may want to have a single protocol with multiple patterns. You may want this type of protocol management if you want a single Bitcoin address to control multiple "API points" for a single protocol via the Bitcom scheme.
Let's think of a hypothetical Memo.cash clone that uses this scheme. This app will have two APIs:
OP_RETURN 17yyXL4raLZFU95ixkRESa2ZBPSSYxSsS5 0x01 Johndoe
OP_RETURN 17yyXL4raLZFU95ixkRESa2ZBPSSYxSsS5 0x02 Hello
Let's describe a schema. This time we have two APIs to describe instead of one, so we will put it inside an array:
{
"v": 1,
"s": [
{"out.h2":"01", "out.s3":"{{username}}"},
{"out.h2":"02", "out.s3":"{{message}}"}
]
}
The difference here is that h2
attributes are not variables wrapped in {{ }}
pairs. They are static values, so they are used to pattern match in the following manner:
out.h2
is 01
, then out.s3
matches to "{{username}}"
out.h2
is 02
, then out.s3
matches to "{{message}}"
We can publish this schema like this, using the bitcom scheme:
OP_RETURN
17yyXL4raLZFU95ixkRESa2ZBPSSYxSsS5
$
echo
{"v":1,"s":[{"out.h2":"01","out.s3":"{{username}}"},{"out.h2":"02","out.s3":"{{message}}"}]}
to
schema.json
Let's take a look at how this can be applied in a real world scenario. We will use a real world example protocol: B://
.
First we define a B://
schema for uploading blobs to the blockchain.
Since we are discussing a new way of doing things, let's assume for a moment that we are using a different version of B://
spec where it ONLY has a single attribute: {{blob}}
.
In this hypothetical version, B://
acts purely as a "blob upload scheme". It only has one attribute: blob
.
{
"v": 1,
"s": {
"out.s2": "{{blob}}"
}
}
We publish this schema to Bitcoin with an OP_RETURN:
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
$
echo
{"v":1,"s":{"out.s2":"{{blob}}"}}
to
schema.json
Next, we want to attach more header metadata to the blob by utilizing the Unix Pipeline concept, instead of packing all the extra attributes into the B://
protocol.
This way B://
can stay minimal, as a purely raw blob upload protocol, and developers can build extension protocols on top of the blob protocol simply by piping B://
into their header metadata protocols.
Let's define a simple metadata protocol schema as an example:
{
"v": 1,
"s": {
"out.s2": "{{mediatype}}",
"out.s3": "{{filename}}"
}
}
We also publish this schema to Bitcoin using an OP_RETURN:
OP_RETURN
18SuCAXiTgcq5Wj7J91JSkKhrqQ16qPQxW
$
echo
{"v":1,"s":{"out.s2":"{{mediatype}}","out.s3":"{{filename}}"}}
to
schema.json
Now that we've defined two protocols:
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
18SuCAXiTgcq5Wj7J91JSkKhrqQ16qPQxW
let's pipe them.
Here's an actual usage of the two protocols being pipelined to:
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [File_Buffer_Data] |
18SuCAXiTgcq5Wj7J91JSkKhrqQ16qPQxW image/png logo.png
Now, blob viewer services can interpret above OP_RETURN transaction by:
To read the schema for 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
, we can query BitDB using:
{
"v": 3,
"q": {
"find": {
"in.e.a": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut",
"out.s1": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut",
"out.s2": "$",
"out.s3": "echo",
"out.s5": "to",
"out.s6": "schema.json"
}
}
}
Next, to read the schema for 18SuCAXiTgcq5Wj7J91JSkKhrqQ16qPQxW
, we can query BitDB using:
{
"v": 3,
"q": {
"find": {
"in.e.a": "18SuCAXiTgcq5Wj7J91JSkKhrqQ16qPQxW",
"out.s1": "18SuCAXiTgcq5Wj7J91JSkKhrqQ16qPQxW",
"out.s2": "$",
"out.s3": "echo",
"out.s5": "to",
"out.s6": "schema.json"
}
}
}
Above queries will return the schema files for both protocols:
{
"v": 1,
"s": {
"out.s2": "{{blob}}"
}
}
and
{
"v": 1,
"s": {
"out.s2": "{{mediatype}}",
"out.s3": "{{filename}}"
}
}
Now we can finally go back to the original OP_RETURN and interpret what each push data means:
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [...] |
18SuCAXiTgcq5Wj7J91JSkKhrqQ16qPQxW image/png logo.png
And the interpretations are:
[...]
is a {{blob}}
!!image/png
is a {{mediatype}}
, and logo.png
is a {{filename}}
!!This schema scheme is based on how Bitcoin scripts natively work: It's based on Bitcoin push data sequencing and encoding.
This means this can be further extended in the future to describe:
The Bitcoin Script Schema is just one proposal to declaratively describe a Bitcoin script template, which makes it easy to:
There can be other indexing and schema description schemes, but the best ones will probably be very closely integrated with how Bitcoin script natively works.
The current proposal is one such attempt, and one that can be used Today.
The great thing about this approach is that we can easily switch out the schema to a new scheme if the community comes up with a better scheme.
I was wondering if you had any thoughts on using the bitcom protocol address as an actual output of transactions, as a norm, or in any way at all.
Doing this would make it much easier to filter on the transactions in existing wallets. For example, SPV wallets do not have access to the whole blockchain, but they do have access to all transactions for a given address. Using the protocol address as an output would open a path for SPV clients to enumerate content in a peer-to-peer way.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.