White Paper

lee preimesberger edited this page May 27, 2015 · 2 revisions

the Census Protocol Foundation

A blockchain distributed application for transferring digital goods

White Paper

  • James (Cemil) Ayvaz
  • Eric Ramirez
  • Lee Preimesberger


Census Protocol is a Type I DApp with a customized block chain that is dedicated to keeping, transferring, and expiring digital items. The main use case detailed in most documents currently is that of only holding ‘tickets’ for events and items, but the design and implementation is targeted to being extended to all digital items, such as in-game items, software keys, and other ephemeral artifacts that are produced by a community. Once submitted to the blockchain, those artifacts continue to exist with the creator’s restrictions, and can continue to exist far beyond the creators or the creating body’s existence.

The implementation allows the creation of multiple bazaars and exchanges on top of the blockchain itself. Each bazaar or exchange on the blockchain can transparently move property across borders and currencies.

Census is not built or intended as a Bitcoin replacement, but rather a complementary protocol.


  • Able to handle many different data types and items
  • Near instant local coin base exchanges on a single bazaar
  • Double signing - items signed by authors and also by venues or applications to ensure items are real and value
  • Built in protection from transaction malleability, dusting, and other DOS attacks
  • A pool-free protocol - reducing chances of a 51% attack
  • ‘Broken arrow’ protection - items can only be sent to a valid, existing address
  • No hard-fork protocol - the internal structure is not in a binary format, so obsolete nodes that suit their purpose (an appliance of some sort) can run eternally so long as its functionality is available

Intentions and Goals

Part of the manifesto for Census Protocol is to remove the middleman from most creative activities and fairly pay creators and those adding value, rather than those who happen to have a virtual monopoly. ‘Media’ means ‘things in the middle’ in Latin - and the purpose of Census Protocol is to remove the ‘middle’ from creative transactions. Everyone is paid fairly - but it is not possible to mark up tickets to 100% of the face price in fees if the creator does not allow this. Users can easily determine if an item is valid and can easily buy those items on the block chain with zero risk.

The goal of the project is to become the de facto system of record for ownership of digital items and tickets. The ownership of these items can be passed from user to user and resold an infinite number of times and still work correct for the current owner while revoking ownership for the old owners once ownership is passed.

Project Goals


  • To create a system for moving and monetizing digital items from creators to consumers
  • To create an open, and standard protocol that can be implemented and verified in multiple languages and systems
  • An attempt to address known gaps in the Bitcoin protocol - including transaction malleability, dusting, and the 51% attack
  • To allow venues to control and monetize on items
  • An open-source, publicly controlled protocol much like OpenStack and TCP/IP
  • A CPU-intensive protocol on the client side, making DOS attacks extremely expensive

Is Not:

  • Another Bitcoin
  • An Altcoin
  • A corporation attempting to monetize on another light variation of the original Satoshi papers and code
  • Another protocol that can be gamed with hardware - the proof of work is actual work. Nodes must do useful work to get paid with block rewards
  • A poolable protocol, and is therefore not susceptible to a 51% attack. Beyond the early stage, it is impossible for a single wallet to control any meaningful amount of network power.
  • Consensus Methods Census Protocol is not intended to be structured to promote a ‘gold rush’ mentality of mining and sales of the tokens. The block chain does not reward ‘dead’ blocks - so early adopters who spam the network with large farms will not receive large rewards and will not be able to corner the network. The blockchain has a very small time period in it’s processing cadence - so the most profitable mining would be found in brokers and creators that run nodes that process sales on their own creations. Since the network propagation time of the transactions becomes critical - the node closest to the action (the ticketing office, brokers, or app creator) has a profound self interest in supporting the network to retain the transaction fees on the product.

The system is profoundly unfair in the favor of product and item creators, and this is intended. Even on a large, established network - a popular band or other creator can capture most of their revenue using Census Protocol while still giving a fair share to resellers and venues by running a node.

Since the network is structured on the self-interest of the users, the algorithm is a simple block chain of signed transactions. If there is no activity - there is no excessive power or network usage and there is no token production. The blockchain rewards useful work only - and are simple enough to be able to run on cheap appliances (cash registers). There is a working concept of the protocol on Github, but it will not be available for public comment until nearer completion.

Since also the supply is very slowly growing - the price of tokens remains stable and will not undergo the wild speculation of currencies such as Bitcoin. The block reward is intended to nearly match that lost in accidents and neglect and create a stable supply. The max coin count of the network is virtually infinite, but the rewards should be under network loss and demand, resulting in a rising price.

Token Distribution

A percentage of blocks are premined, but they are owned by the Foundation and are at a locked exchange rate defined by the board. Regardless of demand, the price will not be allowed to spike and crash as was rampant in the early days of crypto. The board is composed of both developers and corporate sponsors, who have a self-interest in a stable currency. Tokens are locked with a major fiat currency - generally the US dollar and will be allowed to deflate at a rate good for the sake of the network and of early supporters.

During the pilot phase, tokens are distributed to investors on a Bitcoin or USD to token fixed ratio on a crowd sale to raise funds for completion of the product and the launch of the matching foundation. This will result in a fixed number of tokens being assigned. After the pilot phase, tokens will be awarded in response to contributions to the Foundation itself.

A moderate number of tokens are reserved to reward the development team for various milestones in development. This number is no greater than those created through funding.

After this phase, the remaining tokens in the pool will be distributed per useful block based on a level to be determined by the foundation. The goal of the algorithm would be to maintain stable value ratio to protect the investment of original founders but without driving the price to bubble levels.

Census Protocol Block Chain

Census Protocol is not trying to emulate the race to max computational and power efficiency of current cryptocurrency families. A goal of the network is reward creation and useful work - rather than deep pockets. Public and private keys are created using the familiar Elliptic Curve Encryption. Code is based entirely off tested and stable Bitcoin libraries.

  • creators create value by creating items that people want on the block chain and are rewarded richly for it
  • venues (either physical or virtual) can approve, sign, and monetize on items created for their venue
  • brokers connect creators to consumers on the public block chain and are rewarded with rewards based on the value they add to the exchange
  • ‘miner’ nodes are rewarded for processing the sales for a fixed transaction fee

The block chain reference implementation is implemented in Python and NodeJS and all protocols are entirely JSON-based. When synchronizing with the network the block chain appears in JSON inside a websocket stream, which is automatically compressed at the server level - and the target node regardless of language can extract this into a native format for the platform. The reference implementation keeps all state information of the network in memory. Each block is a simple JSON block containing the transactions, a sequence, and a checksum based on the contents and the checksum of the previous block.

The protocol is not friendly to mining pools as seen in Bitcoin. Each node on the network has a separate wallet address that receives genesis coins from the operations of the network. Every ownership transaction or creation of an item requires tokens - which are consumed and swept into the miner wallet along with a modest block reward. There is no race to create possible blocks - the only race is to create useful blocks. Because of network propagation, it is in the interest of large content creators and vendors to host nodes on the network.

Creation of Items

Each item created requires a small fee to be spent. This prevents users from spamming the network with junk transactions. The creation fees are non-refundable and are given to the miners signing the transactions. Creating ‘dust’ is expensive for the creator and profitable for the network - and is discouraged.

The item is created through a network transaction that creates a record containing all the needed user parameters and that transfers funds from the creator wallet to the miner tip jar. The record is available on the block chain and is available (depending on flags) for sale. If available for sale - any transaction satisfying the item parameters (max/min price, fees, etc.) can transfer ownership to another user.

Curated Items

The blockchain has the concept of curated or approved items. Once created, an additional authority can approve items for specific venues or applications. The use case for this would be a large concert venue, which would not want random users booking tickets for events at their site that weren’t paid for. Alternatively, this could be used by a MMORPG to approve new content for sale in the online game world or to ensure that nothing malicious is released. This appears on the blockchain as another self referencing transaction that consumes tokens.

Network Peculiarities and Differences from Bitcoin and Major Altcoins

This blockchain only rewards useful information. As part of this - it is ill suited to pooling with any current technology. Workers are performing useful work as fast as possible to ‘win’ the race to create the next block rather than doing useless work to solve a problem that amounts to a crapshoot. The Bitcoin method is perfect for its intended purpose - but Census Protocol seeks to perform useful work as fast as possible rather than ensure fairness on a grand scale.

Because of this - a successful miner should be creating/processing/curating content rather than just providing a service on the network. Network latency does matter in this system, so creating large systems with no supporting infrastructure to grow the network does not net value for the user. Nodes that produce useful content are tagged as higher reliability and become higher in the network rankings.

As part of the blockchain transfer - the network also tracks the reliability of nodes. If a node is producing junk transactions - it is is rapidly blacklisted and drops in reliability on the network. All nodes want to listen to the higher quality nodes. Newer or lower reliability nodes will find themselves delegated to lower quality peers and will receive less revenue.

Transfer of Items

The network will allow transfer of ownership for any item that has ‘saleable’ marked on it that has a transaction meeting the criteria after it on the block chain. Defined criteria are:

  • Sales price
  • Max Sales Price (for auction formats)
  • Time Period
  • Any restrictions made by the creator (max price, etc.) take priority

The first approved transaction meeting these will move the item to the new owner, and the funds will be swept into the appropriate wallets in a single transaction.

Potential Uses

The primary use case in this document event tickets - these can be created, sold, and validated easily using the blockchain. But the blockchain itself could be used for many other purposes.

  • Imagine that a user-created and funded MMORPG could be created on top of the block chain. The users themselves could create content, and the creators could be rewarded as players purchase key items to enter new zones or to activate new armor sets.
  • An album could be released entirely on the block chain - removing the 30% fee imposed by current distribution methods
  • ‘Limited edition’ digital items could be created, using multi-key decryption and factoring the current user credentials into them
  • A simple paid access service could be based on the block chain, where access to a site (or physical area) can be based on expiring tokens on the block chain

Protocol Entry Points

GET /api/v1/version

This returns information about the version of the protocol supported in the ‘version’ field. The other fields are free form and can give information about the node, the software implementation, and any other information that is relevant.

GET /api/v1/item

This returns items from the local working set in random order and with no filtering. This is not useful for most implementations, and can be restrained to any number of records. The suggested restriction value is 50 records.

POST /api/v1/wallet

Create a wallet in the blockchain. This is a special entry point and can be also done through the /api/v1/item POST entry point. A wallet must exist for any transactions to connect to them. This prevents what the protocol defines as ‘broken arrow’ transactions that go nowhere.

GET /api/v1/wallet/:id

Return the current wallet balance (actually, the entire JSON data for it ) of the given wallet.


Returns the current wallet for the given email address.

GET /api/v1/item/:id

Return the record matching the given txid number. This txid value is the universal tracking number and is portable.

GET /api/v1/item/verify/:id

Returns a valid HTTP response for an active item, false if not.

GET /geo/:lat/:lon/:dist

Returns a list, possibly capped at 50 or less items, of items :dist km from a given point on the earth. This is limited to 50 miles or 80 km.

POST /api/v1/item

Adds the given item to the database. There are multiple cryptographic signature checks depending on the data.


For creator, venue and creator signatures are replaced with “”, the JSON object is transformed into a predictable UTF-8 stream, and the signature value verified. If this passes, this check is satisfied.


For venue, creator signatures are replaced with “”, the JSON object is transformed into a predictable UTF-8 stream, and the signature value verified. If this passes, this check is satisfied.

If both of these checks are valid - the item is added. This does not mean that the item will be accepted by the network however. For the local coinbase, existence is proof enough - any subsequent calls (item/verify) will pass until the system rejects the transaction (should this happen).

POST /api/v1/buy

Used to buy an item. The item moves to the buying user. The source and target addresses define the ownership swap.

GET /api/v1/vend

Find all the items for sale. The return values can be arbitrarily capped depending on the implementation. In generation, clients should expect to get approximately 50 return values - although they should be able to handle anywhere from zero to the max packet size for the protocol level.

This is only useful during development - the return order is random so on a large system this is simply junk data.

GET /api/v1/vend/:id

Find the item matching the given GUID. If there is no match, it returns an empty set.

GET /api/v1/vend/venue/:id

Find all the items for sale within the given venue GUID. The return values can be arbitrarily capped depending on the implementation. In generation, clients should expect to get approximately 50 return values - although they should be able to handle anywhere from zero to the max packet size for the protocol level.

GET /api/v1/geo/:lat/:lon/:dist

Find all the items for sale within :dist kilometers of the given GPS coordinates. The return values can be arbitrarily capped depending on the implementation. In generation, clients should expect to get approximately 50 return values - although they should be able to handle anywhere from zero to the max packet size for the protocol level.

POST /api/v1/vend

List the given item for sale. Terms can be included depending on the support level.

The following entries are used for peer discovery.

POST /api/v1/peer

Request registration as a peer. This may be rejected if the host is too busy or the peer appears suspicious or is blacklisted.

GET /api/v1/peer

Returns a random number of random peers to connect to. The host should connect to at least three other peers. Connections are done over a websocket protocol which is the topic of a separate paper.

Appendix A - JSON Schema for input

Appendix B: Return Values

Possible values for “result” include:

{| style="border-spacing:0;" | style="border:1pt solid #000000;padding:0.0694in;"| Value for ‘result’ | style="border:1pt solid #000000;padding:0.0694in;"| Meaning

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-invalid-signature | style="border:1pt solid #000000;padding:0.0694in;"| Packet was invalid - possible additional information in “warnings”

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-flare | style="border:1pt solid #000000;padding:0.0694in;"| This IP address has been flagged as a possible DOS attack because of repeated bad or trivial connections. Further connections will be ignored and may be forcibly trapped at the OS layer

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-no-api-entry | style="border:1pt solid #000000;padding:0.0694in;"| Requested operation is not valid

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-missing-mandatory-fields | style="border:1pt solid #000000;padding:0.0694in;"| Packet is missing one or more fields that are needed - additional information may exist in “warning” but this is not mandatory.

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-dust-transaction | style="border:1pt solid #000000;padding:0.0694in;"| Packet has been identified as a ‘dust’ transaction - which is a possible DOS vector - and has been rejected by the node. The value of the transaction and its fees are trivial and appear to be network spam. These values are implementation specific.

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-invalid-to | style="border:1pt solid #000000;padding:0.0694in;"| Transaction is attempting to move an item to a non-existent or revoked address

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-invalid-from | style="border:1pt solid #000000;padding:0.0694in;"| Transaction is attempting to move items from a non-existent address

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-unknown-transaction | style="border:1pt solid #000000;padding:0.0694in;"| Transaction type is one that is not recognized by this node.

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-too-large | style="border:1pt solid #000000;padding:0.0694in;"| Packet exceeds the current network maximum

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-max-calls-exceeded | style="border:1pt solid #000000;padding:0.0694in;"| The number of queries for this node type has been exceeded. Try again later (this is to restrict calls from Internet nodes in favor of local ones for data processing)

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-malformed-address | style="border:1pt solid #000000;padding:0.0694in;"| wallet address does not match the correct format

|- | style="border:1pt solid #000000;padding:0.0694in;"| abend-unknown-transaction | style="border:1pt solid #000000;padding:0.0694in;"| item is not a known type


Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.