unwriter’s tools explained, use cases reviewed: Part 3

Getting your Trinity Audio player ready...

This article reviews more application related tools that developer unwriter has released over the second half of 2019.

The first two pieces can be reviewed here and here.

Bitbus

Bitbus creates a filtered subledger of Bitcoin transactions in your file system based on a Bitquery you define. Bitbus eliminates the need to run a ‘non-mining node’.

Bitbus is a more intimate Bitsocket—instead of listening to someone else’s node you can monitor your file system and trigger events from there. Bitsocket would only fire off once, with Bitbus you have a local audit trail of all events that occur.

Use case

Building any application that require different types and subsets of Bitcoin transactions—if you need to filter for WeatherSV transactions and certain B:\\ files, you can run two instances of Bitbus that place files in separate sub-directories, then query those from one application. This is more sensical than running a node to get the entire blockchain or making constant API calls elsewhere to fetch the data.

Eventchain

Eventchain derives from Bitbus in that it appends transactions to a file, much like an event log. You define the query and format in which the transaction will be added as a new line, then can use external application to interact with a simple file. This is useful for interacting with Bitcoin via other programming languages as all of them can deal with file reading/writing.

Use case

We can replace FTP by using Eventchain over Bitcoin—for example we can filter for only certain B:\\ protocol files, then create them in a sub-directory. We now have FTP over the Bitcoin blockchain. There is no need to archive since the blockchain is the archive. If we add encryption, we can have the same functionality as SFTP without the headache of setting up accounts.

Su – Simple authentication protocol

Su is a Bitcom protocol that can be leveraged for authenticating user actions on Bitcoin. Three fields are required:

– Public key
– Sign position of data to check
– Signature

Assumptions are made about how the data is signed, so those are not implemented for the sake of keeping the protocol lean and simple (less is more).

To interpret transactions, check the push data in the OP_RETURN at the sign position, and validate that the signature matches the public key. If this data is associated with some user we can validate that they broadcasted and signed it, therefore we can display it in app.

Use case

Leverage Su as a filter mechanism and prevent identity spoofing in your application. In fall of 2019, Jack the CEO of Twitter was hacked. With using something like Su, we do not need the user to log in to an application for them to post content. Users can write to the blockchain with any method then our application can determine whether it is valid to display, leveraging the cryptographic features of Bitcoin.

(Honestly, the fact that the CEO of Twitter was hacked and tweeted out hate speech is a joke, and this is due to the mesh network topology of the Internet)

Bitkey

Bitkey is a user database on Bitcoin. Each record establishes a link between a paymail and public key. We can simply query the blockchain with a paymail and derive a user’s public key for payment. Given that the write mechanism to the database in this format leverages signatures, we can have reasonable confidence that the paymail owner is tied to its user.

One problem I have noticed is that wallet providers did not implement the same API route in HTTP to query paymails for public keys. This is non-sensical in my opinion as it makes development more complicated because they must keep track of different URLs and paths in their application if they want to support paymail from different wallet providers.

Use case

Encrypt files to different users’ public keys by querying against the Bitkey database. Instead of calling out to many different servers as alluded to above, I can consistently query one centralized location thus reducing code, complexity and risk in my application.

Overpool

Overpool is an off-chain Bitcoin transaction ledger. This software allows acceptance of signed or unsigned transactions (similar to Bitpipe). Data in a Bitcoin transaction format can be passed around different parties before they are broadcast. Intermittent local subledgers can be maintained, then applications can broadcast transactions in batch as opposed to real-time.

The main benefit is providing streamlined functionality for applications to send malleable yet ready to broadcast Bitcoin transactions between each other.

Use case

Honestly when this was first released I had a hard time coming up with a legitimate use case. After going back and understanding the latest tools unwriter has put out there I now have some ideas on how to use this.

In a multiplayer game you could record all actions by the different players in a local subledger—then once one player is left standing (thus winning) the winner can broadcast the result along with any potential summation calculations done on the subledger (to record stats and details about the match) as opposed to recording every action on-chain.

Summary

I hope these pieces have helped those looking to understand what unwriter has been up to this year and potentially how they can play a role in their application development. Also I hope this serves to help non-technical people grasp at a high-level what is going on instead of blindly celebrating each time he announces a ‘mystical’ tool.

Let me know what you think in the comments or on Twetch!

What do you want to see explained further?

What could be clarified?

Any feedback is appreciated!