b's Introduction

B://

Bitcoin Data Protocol

b://6c784b78cff5ee4f469f783adc0e957265f467d3a0dae2b2b1ecbc84a1bd1fb6

Store and reference data on the Bitcoin blockchain.

Intro

B is an OP_RETURN protocol to store and reference arbitrary data on Bitcoin.

The design goal:

The simplest protocol to upload arbitrary media to the blockchain
A protocol to reference previously uploaded media from another on-chain media.

Protocol

The prefix for B is 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut, generated using Bitcom

Here's an example of what POST transactions look like:

OP_RETURN
  19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
  [Data]
  [Media Type]
  [Encoding]
  [Filename]

The order is deliberately data, media type, and encoding, filename, in the order of significance (With future extensibility through adding additional push data).

Data: data to store
Media Type: As listed at https://www.iana.org/assignments/media-types/media-types.xhtml
Encoding: As listed at https://www.iana.org/assignments/character-sets/character-sets.xhtml (The default is binary)
Filename: a filename to store the blob as (the default has no filename and just stored as a blob, identified simply by the txid)

Example: HTML

OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut  <html><body>hello world</body></html>  text/html  UTF-8  hello.html

Note

B:// is NOT a protocol for handling authenticated and encrypted media (That would be a much more complex problem). The main design goal of B is:

Public: Public assets
Simple: Simple to implement
Versatile: Easily pluggable to any application in any context
Extensible: Future extensibility with additional push data support

Demo

Try it here: https://b.bitdb.network

Usage

1. Uploading Large Media

Let's upload an image.

You can try it here (up to 100KB)

When you select a file, it directly writes the binary (ArrayBuffer) into Bitcoin pushdata (instead of base64 string). The resulting OP_RETURN would look something like this:

OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [ArrayBuffer from the file]  image/png  binary  duck.png

By default, the encoding is binary, so you could just do (if you don't care about file names):

OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [ArrayBuffer from the file]  image/png

Another example:

OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [ArrayBuffer from the file]  text/html  UTF-8  index.html

2. Referencing Media

Once uploaded, this media can be referenced from ANY other transactions using a transaction hash. For example, let's say the media hash for an image uploaded this way was 46e1ca555622e73708a065f92df0af2cc0fe00ed1dd352d5fb8510365050347c.

You can reference it in another HTML file like this:

<html>
<body>
<img src="b://46e1ca555622e73708a065f92df0af2cc0fe00ed1dd352d5fb8510365050347c">
</body>
</html>

Of course, to upload this HTML file itself, you would do this:

OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
<html><body><img src="b://46e1ca555622e73708a065f92df0af2cc0fe00ed1dd352d5fb8510365050347c"></body></html>
text/html
UTF-8 
example.html

Once this HTML file is uploaded to Bitcoin, and the tx hash is e2be88f33d98074f778ddd94c13fe500cb1f5a4dfb3ed958391c95f431c20549, you can link it from another HTML, like this:

<html>
<body>
Check out <a href="b://e2be88f33d98074f778ddd94c13fe500cb1f5a4dfb3ed958391c95f431c20549">my website!</a>
</body>
</html>

You can use it in a markdown too:

[Here](b://e2be88f33d98074f778ddd94c13fe500cb1f5a4dfb3ed958391c95f431c20549) is a website, which contains the following image:

![image](b://46e1ca555622e73708a065f92df0af2cc0fe00ed1dd352d5fb8510365050347c)

Of course, you will upload it like this:

OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
[Here](b://e2be88f33d98074f778ddd94c13fe500cb1f5a4dfb3ed958391c95f431c20549) is a website, which contains the following image:\n![image](b://46e1ca555622e73708a065f92df0af2cc0fe00ed1dd352d5fb8510365050347c)
text/markdown
UTF-8 
README.md

b's People

Contributors

Stargazers

Watchers

b's Issues

File split across multiple tx

Having separate blob with tx list might cover large files?

problem with default rpc endpoint

If I set pay.rpc: "https://bitcoinsv.si" datapay lib returns error NodeError.

I'm a node noob, how can I debug || what must I setup on my end so I can replace default rpc on https://bchsvexplorer.com ?

Support for both 'content-encoding' and 'character-encoding'

The 'encoding' field for specifying the character encoding is being overloaded in the wild to support content-encoding since no field exists for this specific purpose.

Here is an example tx which uses gzip compression on an html:

The encoding field is being used to specify the content-encoding gzip. This information is required to decode and render the content. While many content types are specific enough to include the compression information, many common content types are not such as text/html.

This issue is avoided in practice by overloading 'encoding' to define both types since knowing the content-encoding (gzip) can help you assume a binary character encoding, but this may not be safe in all cases in the future. You can imagine scenarios where some data might be compressed but with a resulting character encoding other than binary / converted to some other character encoding afterwards for some reason. This would be impossible to express in B's current form.

In my case, I am writing a TXO parser that relies on the value in the 'encoding' field to dictate which pushdata should be used for this content (out.b(x) vs out.s(x)). If the value is 'gzip' or similar, the "correct" thing to do according to the spec would be to produce an error as this is not a valid character-encoding. I cannot make a reliable determination without assuming the character encoding.

According to the docs, one design goal of B was to be both:
Simple: Simple to implement
Extensible: Future extensibility with additional push data support

With this in mind, I propose adding an additional optional field for 'content-encoding'. This would be added after filename as to be backward compatible. If omitted, it should be assumed to have a value of 'identity', i.e. no additional compression or modification. If there is no compression, no changes are required for application developers writing B content to the chain. If there is compression, you must specify the content encoding as well as the character encoding.

The results would look like this:

OP_RETURN
  19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
  [Data]
  [Media Type]
  [Character Encoding]
  [Filename]
  [Content Encoding]

Another example:
OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [ArrayBuffer from the file] text/html binary index.html gzip

The only alternative I can think of other than defining a new protocol is:

If the character encoding is not a valid type, assume it is binary and use the value instead to define content-encoding.

My problem with this is, it has a potential to break in the future and is not really "simple" since you would need to know this and its not immediately obvious.

Recommend Projects

unwriter / b Goto Github PK