bitbind.io: system and API for tagging and tracking objects with the blockchain

[garethjenkins]

Hi!

So, for the last year or so I've been working on a couple of bitcoin projects. The first of those is https://bitbind.io -- a design, architecture and API for attaching digital assets to the blockchain without either polluting it with extra data or relying on non-standard features. The second is a set of digital collectible & trading card games, for which bitbind.io was built to support. I'll post more on that as I get it online, but there's some draft content already available at https://www.deckbound.com.

The first version of https://bitbind.io is online now, with some examples and further description on the site. I've copied the design diagrams below as they explain the principles pretty well.

I'd love to get some feedback on the design and expand the use cases and description of the service as result. Deckbound's architecture utilises bitbind.io to track digital cards (like those in Hearthstone or Magic: The Gathering), facilitate 3rd party trade (cards are effectively just bitcoin transactions), provide unique attribute sets (generated from transaction IDs) and allow for levelling and other attribution... but I can see that the idea of tagging addresses (and consequentially the addresses and transaction that result from them) could provide a good lightweight alternative to the various "2.0" initiatives and other related projects.

So -- bitbind.io tags:

https://bitbind.io/img/bitbind-tags.png

Tags and objects are pushed to bitbind.io by a public REST call, using a private API key. That API key denotes the namespace ("foo" of "foo:bar") for the tag.

At the moment, the tags are hosted by bitbind.io, but we're looking to move that to a distributed hash table or validated transaction hash in the future. I'm also interested in exploring options for signed namespaces... effectively a root tag address for each namespace that allows for the "tagging" of other address (I'm doing this with deckbound -- each card class tag is child to a set of genesis addresses and tags).

bitbind.io objects:

https://bitbind.io/img/bitbind-objects.png

Objects represent a trackable item. An object is created from a genesis transaction, the first output of that transaction being the object initial "forward address". The object then tracks that forward address. A transaction that uses it as an input will relocate the current forward address to the first output of the transfer transaction.

An object's address is the transaction ID of its genesis transaction.

...and, most usefully, tagged objects:

https://bitbind.io/img/bitbind-objects-and-tags.png

A full history of forward addresses is kept as the "address history" of the object. If any of those addresses are used as the output of a transaction from a tagged address, they are implicitly tags for that object. Any tags present on the inputs to the genesis transaction are also considered tags for that object.

The API -- https://bitbind.io/#api -- allows RESTful queries and posts for tags, tagchain, object, createtag and createobject

Testing, use, API Keys and examples

As well as feedback on the design, I'd love to get some other people using the service. If you want an API Key let me know your preferred namespace and I'll set it up. Once I've extended the tags queries for recursive lookups and established some performance boundaries, I'll set up a signup system -- but for now I'm happy to manage them either through this thread or PM/email.

If you've got a interesting use case or example let me know and I'll add it to the site.

Look forward to feedback and discussion -- I'll post more about deckbound separately over the coming days and weeks.

[RagnarDanneskjold]

This sounds pretty interesting. Any plans to place on github so I can see it?
There are a number of similar efforts you might appreciate like this one:
https://github.com/TSavo/Link

[garethjenkins]

Ragnar -- thanks, and yea, that's the plan. At the moment the data store is a local repository, but I'd like to move to a distributed hash and implement a basic peer system before opening up the code (else different instances of the service would have different datasets). Also keen on putting in an efficient solution for tracking long-distance tag queries (at the moment it'll recurse through transaction chains which isn't very quick). It internally uses an instance of bitpay's Insight explorer, and it's likely that I'll look to extend that to monitor transactions as they happen to keep a local database of object and tag chains.

Thanks for the, er, Link link -- was discussing something similar with someone at the SF bitcoin meetup earlier in the year. Might've been the same thing. Regardless, going to have more of a poke at it myself as it potentially lines up with some other stuff I'm doing.

G.

[dexX7]

Hey garethjenkins,

can you quickly explain what the purpose of this is? According to some place else you don't store any data on-chain, so I'm wondering: what is this?

[garethjenkins]

Hey garethjenkins,

can you quickly explain what the purpose of this is? According to some place else you don't store any data on-chain, so I'm wondering: what is this?

Hi -- sure. We needed to be able to do hierarchical tagging for Deckbound, using multiple address sets at each part of the hierarchy. There wasn't anything that allowed us to do that and maintain compatibility with existing bitcoin tech (particularly regular wallets), so we built bitbind.io. Much of what the service itself does is maintain the flattened tag list for each address, but it's totally feasible to rebuild that from the raw tag data and the blockchain itself.

G.