nskelsey / protocol

ahimsa protocol specification

Definitions of

###Storage Format The storage format is slightly complicated. We encode bulletins in the 20 byte slices used for bitcoin addresses in Pay2PubKeyHash transactions. The Tx indicates that it is a public bulletin by making the first 8 bytes of that first 20 byte slice equal to 0x 425245544852454e. The actual bulletin itself is then encoded in a protocol buffer for effeciency!?

###Database Schema As of version 0.0.0, the database consists of two tables. Blocks and bulletins are the only objects whose existence we track.

Prior Work

There are quite a few projects from which we have taken ideas, concepts and source code. The big ones are:

• btcd
  • The developers at Conformal have developed some awesome bitcoin libraries. We have used them extensively.
• twister
  • The intended use case of this project and ours is excatly the same. We just elected to use bitcoin's infrastructure, not set up our own.
• bitmessage
  • A similar messaging tool that encrypts messages preflight.
• bitchirp
  • The original distributed version of twitter.
• Proof of Existence
  • The first tool we were aware of that uses the blockchain for its distrbuted timestamp and data storage.
• CounterParty
  • Our bitcoin daemon and database schema was modeled after the one created by PhantomPhreak.

protocol's Issues

Align protobuf spec with the SQL schema

Data types should align so that an optional field like board is optional in the protobuf and nullable in the sql. Similarly, a required field for a bulletin is both 'NOT NULL' and 'required.'

New spec will look something like this:

The protobuf

message WireBulletin {
    required uint32 version = 1;
    optional string board = 2;
    required string message = 3;
    optional uint32 createdat = 4;
}

The SQL

CREATE TABLE bulletins (
    author  TEXT NOT NULL,
    txid    TEXT NOT NULL, 
    board   TEXT,
    message TEXT NOT NULL,
    block   TEXT,
    version INT  NOT NULL,
    createdat INT,
    -- Table constraints
    PRIMARY KEY(txid), 
    FOREIGN KEY(block) REFERENCES blocks (hash)
);

Add self reported time to bulletin spec

This lets the user report the time they created their message.

My reasoning is that if you trust what they are saying then you might as well trust the time that their machine indicates.

I think it should be an optional field.

Handle topic to board migration.