Checkoin

Checkoin allows the hand to hand circulation of physical mediums that hold "something" (for example a secret information). Guaranteeing to the person receiving it that the medium is indeed the uniquely identified medium that it pretends to be, that it has not been counterfeited nor copied, and that what it holds hasn't been tampered with nor unveiled by anyone before. Checkoin was initially designed for the offline circulation of cryptocurrencies, but is not limited to it.

Physical cryptocoins (or cryptocash) are mediums of exchange holding sealed cold storage information for cashing cryptocurrencies (or more generally any redeemable asset). As Bitcoin addressed the digital currency's issue of double-spending, Checkoin aims to address the issues of the hand to hand circulation of physical cryptocoins (geolocation, counterfeiting, altering, copying, etc.), while protecting the freedom and anonymity of the users.

It allows to check the integrity of physical cryptocoins without having to break their sealing, with a high level of trust and ease, like checking a banknote under a UV blacklight. Thus, they can circulate safely, by hand from peer-to-peer, until they eventually get cashed by having their irreversible sealing opened, then trashed.

In other words, you don't need to “crack the nut” to know if it is “rotten”, you just perform a reliable “health evaluation” that helps you to decide if you accept it as a payment, if any doubt you simply reject it, return it, or crack it to be sure, and eat it!

Why physical mediums of exchange in the digital age? Because it's fun, easy, socially interacting and pedagogical for bringing the use of cryptocurrencies to the masses. Furthermore, as the digital age is also the time of mass surveillance (gaining ground on our privacy under the war on cash), and as the global fiat currency war has already started, having alternative means of exchange that rest most of their time off-the-grid in our pockets (and which worth more than the paper it's written on) is interesting way to stay away from these threats. Finally, Satoshi's motivation for Bitcoin wasn't the beauty or convenience of technology, but freedom, pursuing the dynamic to the physical world is more than ever bitcoinish.

In its current form Checkoin is a technical proposal for the standardization of such specifications, a pre-RFC-like work in progress. You are welcome to get in in order to manifest this open economical ecosystem of trust, freedom, fluidity and innovation into reality!

Then, the Blacklight retrieves information (via its server) from the Network about the Coin, and cryptographically authenticates it (using the Visible Scan Data's Passphrase which is never sent anywhere outside of the Blacklight). If the authentication successes the Blacklight's server performs data analysis about the Coin to be displayed on the Blacklight. Especially about the consistency of the geolocation and timing of the previous Scans' lineage. Indeed, if the Coin has been subjected to counterfeiting with its Visible Scan Data being copied, it means that there are multiple counterfeited “coins” that will be scanned at different locations and time, which will quickly become inconsistent with the frequency of exchanges and geographical distance between the Blacklights.

This verification imposes discouraging constraints to the wannabe counterfeiters. They would be able to counterfeit only a very very few copies of a Coin (not to say only one), while attempting to offload it quickly in a narrow geographical perimeter, in the hope of slipping through the net of the Scans' analysis by the Blacklights. As Checkoin allows anyone to become a Minter, the variety of Coins' shapes, colors, materials, holograms, etc. makes this counterfeiting very tedious (especially if the counterfeiter only captured the Visible Scan Data of the Coin but not the Coin itself, which pushes him/her to rush its handcrafted imitation, before the original moves to another location). That's also why Blacklights display pictures (and/or short videos) of the Coin provided by its Minter, so the user knows precisely how it is supposed to look like. The sophistication of the Models of Coins is recommended to be proportional to the value of the asset they hold, in order to make the difficulty to counterfeit proportionally dissuasive (from the simple cardboard up to the key signing microchip).

Here follows a non-exhaustive list of informations and services that the Blacklights should propose:

analysis about the coherence of the geolocation and timing of previous Scans,

Then, unless the user has requested an “silent scan”, a new Scan record of the current location and time gets stored on the Network (optionally encrypted), which brings the process to a close, until the next Scan. Thus, scanning a Coin enforces the safety of its circulation.

Notes

Even if the “user” is alluded to in this document for practical reasons, there is no such thing as a “user” in the definitions nor data model of these specifications, for obvious privacy reasons. The only identified endpoint of Checkoin for the “end user” is the well established Blacklight server manager's Account. Any Checkoin component is forbidden to require (coercively or not) any “end user” to identify with an Account under any circumstance.

The Sealed Cashing Data is not limited to cryptocurrencies, there is no reason for such limitation, and it facilitate the diversification of assets in peoples' pockets/portfolios which enforces economical security, other Asset Types could be:

a coupon for the local grocery store (then the Blacklight should display the value of the asset according to the location, it is likely to value 0 half way around the world)

a Goldmoney coupon (or the gold nugget itself, indeed if the asset is small enough, transportable and securely sealed it can replace the content of the Sealed Cashing Data),

organic seeds,

medicine,

etc.

If the Visible Scan Data of a Coin gets leaked on the Internet, or if a previous user kept note of it, there is the possibility of an attack on this Coin's integrity by making multiple forged scans with inconsistent time and location. This is unlikely to happen except for gratuitous malice or retaliation (e.g. an angry customer), but if the Coin integrity gets damaged, it still has the value of the asset it holds, so, the damage is limited. Such an attack would be like smashing a Philharmonic gold coin with a hammer, it loose some of its value, but it's still gold. Furthermore, such attacks could be intercepted by the Blacklights' servers with some pattern analysis (even if not detected immediately such an attack can be reverted later on by excluding Scans signed by corrupted BlacklightServer Managers, then wrongfully corrupted Coins recover their integrity). In the case of a Coin holding a key signing microchip, the user can ask the Coin to sign the location, thus dismissing the corrupted Scans.

The circulation of Coins passed from hand to hand can speed up the transaction process and relieve the traffic congestion on saturated cryptocurrencies like Bitcoin.

Checkoin is more resilient against Internet failure/censorship than cryptocurrencies. Indeed, it doesn't require worldwide write access to allow exchanges to take place, the only writing that happens during an exchange is the Scan, which is by design optional (“silent scan”) and can be replicated on the Network later on when Internet is restored (via the second Pool layer). In case of Internet failure/censorship any database backup of the CheckoinNetwork (including media ressources) can operate in a local standalone mode (or within a regional LAN), with a reasonable short/middle term reliability before slowly deteriorating. Indeed, it will eventually suffer a lack of remote Scan data at some point (especially if operating outside of a LAN) and ignore Coins newly minted after the connexion loss. But only few minutes of sporadic Internet connexion some days in the week for synchronizing could keep it alive in the long term.

There will always be counterfeiters, but Checkoin makes it quite dissuasive and unworthy. Also, one of the reasons why counterfeiting has been so tempting in history of mankind is the monopoly on money supply, and artificial scarcity typical to economies of perpetual crisis. But with Checkoin there is no such monopoly, it's an economy of abundance, anyone able to manufacture fake “coins” can more easily become a legit Minter, which might also reduce this temptation.

Vintage wine stock

Handcrafted

Physical gold micro-nuggets

Definitions

Network

The decentralized computer logistics that runs the software and data that are common to all Checkoin actors and accessible from the Internet. The Network is composed of two layers based on existing technologies, the lower layer called the Chain and the upper layer the Pool.

Chain

A set of applications and data running upon an existing blockchain technology able to execute smart contracts (likely to be Ethereum). It hosts the rigid, neutral, unstoppable, secure and minimal components of the Checkoin clockwork. Where interaction between untrusted Accounts must remain safe, and where eternal and indisputable data that worth paying transaction fees for gets stored.

checkoin_version: the version of the Checkoin specifications followed to create the Account,

account: the Account address,

name: the name of the Account.

Any other field can be freely added, please contribute to help improving and standardizing them.

Pool

A network layer for storing, retrieving and broadcasting public signed data that do not need or cannot be stored on the Chain. Typically because this data is frequent, large, do not require blockchain validation, or requires real time propagation.

In its first version this layer implementation follows the KISS principle, it is currently the most debatable technical part, you are welcome to contribute to propose improvements.

It simply consists in a collection of Seed Nodes registered on the Chain, that make their data available via asynchronous replication able technology (undetermined yet, might be something like CouchDB, Redis, etc.).

If the asynchronous replication menaces to saturate, a second version of Checkoin might relegate its role for the initial synchronization of Slave Nodes, then new incoming data being globally transported via another P2P broadcast mesh network. Or this whole layer could be moved to a better suited or tailor made technology.

This data is likely to be curated before being exploited, by selecting the Seed Nodes and the signed data they serve based on their reputation.

Seed Nodes should primarily be set up and managed by Blacklight fabricators for their own use, but not necessarily, it could also be collaborative or third party services.

Localized String

A dictionary object presenting multiple translations of the same string.

Auditor

Outside of the merciless Chain technology, we face again the classic trust issues of the physical world. While Checkoin core is designed not to suffer from it (when trust gets broken the way out is to reject, return or cash the Coin), having a reputation system on top of it can significantly enhance the level of trust, which will greatly extend the area of proper functioning of the service and smoothen its use.

To do so, any Account can become an Auditor by providing extra Audit information about the ecosystem. Whether they are ad-hoc or professional Auditors.

Audit

A record on the Network providing information about the reliability an of an entry:

audit_domain: a slug describing the domain in which domain the audit has been carried out (e.g. "privacy", "checkoin_specs_compliance", "data_protection", "ecology", "neutrality", "independence", "customer_service", etc.),

date: ISO 8601 timestamp of the date of the Audit,

signature: Auditor's signature of all the other fields (mandatory and free) alphabetically ordered and serialized in a non-indented JSON string, so it can be trusted outside of the Chain (e.g. if replicated on the Pool).

Any other field can be freely added (except for Audits on Scan records for privacy reasons), please contribute to help improving and standardizing them.

Checkoin does not provide nor recommends any method for analyzing this data, it's up to the Blacklight fabricators and Auditors to innovate on this domain. However, Checkoin might provide some toolkits and libraries in the future that may include some standard Audit analysis algorithms.

An Audit can be registered on the Chain or on the Pool, however an Audit registered on the Chain might have more weight, as well as an Audit that is more recent.

Asset Type

{//Mandatory"checkoin_version":"pre-rfc_rev27-1b21f03","uuid":"10101010-101010101-0101-010101010101","registered_by":"0x0707[…]07070","name":"Bitcoin","slug":"BTC","symbol":"Ƀ",//Optional"description":"World's most famous cryptocurrency.",//OraLocalizedString.//Free[…]}

cashing_method: a slug representing the method to be used to cash Coins of this Model (e.g. "armory", "pub_priv_keys", "goldmoney_coupon", etc.),

date: ISO 8601 timestamp of the date of the Model,

illustrations: a list of media resource(s) that illustrate this Model of Coin, this field can be overridden by the same <code>illustrations</code> field of each Coin of this Model if present, media resource fields are:

max_scans: an integer indicating the maximum number of Scans recommended by the Minter for Coins of this Model, if any (e.g. for Models of Coins made of degradable materials that might become unusable after too many exchanges),

guarantee_duration: integer defining duration of the guarantee in days, if any (or -1 for unlimited guarantee), starting from the <code>date</code> of each Coin of this Model, in such case any of these Coins having their integrity compromised can be returned (or “cashed” online) for a new Coin instead of their redeemable asset,

asset_producer: the Account address of the entity that is producing the asset,

asset_supplier: the Account address of the entity that is supplying the asset,

asset_manager: the Account address of the entity that is managing the asset,

asset_vault: the Account address of the entity that is safekeeping the asset,

returnable: boolean indicating if Coins of this Model can be returned/refunded to the Minter after being cashed (for Coins which are not physically destroyed after having their sealing opened, e.g. for read-once self-erasing microchip),

Any other field can be freely added, please contribute to help improving and standardizing them.

Optionally, Model records can be made private by having all their fields (except checkoin_version and uuid) serialized into a JSON string encrypted with the first half of the Coins' Visible Scan Data's Passphrases (this first half prefix must be the same for all the Passphrases of all the Coins of this Model in this case, if the length of a Passphrase is odd the first half is the longest), then nested into the encrypted field. However, this encryption might slow down the Scan process as the Blacklight will have to decrypt it for the Blacklight's server.

Coin

A medium presenting a single Visible Scan Data, a single description of the asset it holds (e.g. “0.01Ƀ”), the mention “Exchange me, keep me, or cash me!”, and holding a single Sealed Cashing Data, Typically a flat cardboard or plastic object (but it can be anything, it's up to the innovation of the Minters).

asset_pointer: a string indicating where the asset is located (typically a cryptocurrency address),

preloaded: boolean indicating if the Coin was provided by the Minter with the asset present at the asset_pointer (e.g. “US government” “forbids” to sell preloaded cryptocoins, it has to be loaded later on by the user),

encrypted_signature: Minter's signature of all the other fields (mandatory, optional and free) alphabetically ordered and serialized in a non-indented JSON string, then encrypted with the Visible Scan Data's Passphrase of the Coin. So the holder of the Coin can prove he/she is physically holding it by making the Blacklight decoding the signature and make it match by the Blacklight's server,

sealer: the Account of the entity that places the Asset into the Coin and seals it, if not performed by the Minter.

Optional fields:

expiry_date: ISO 8601 timestamp recommended by the Minter to cash the Coin, whether it be because of the physical lifetime of the Coin or of the asset,

public_key: the public key of the Coin, in case it carries a key signing microchip holding the corresponding private key (e.g. flat printed circuit USB pins, NFC, PUF, etc.), the user plugs the Coin to the Blacklight which sends it a random message to be signed, and finally checks the resulting signature against the public key for authentication,

first_owner_batch_quantity: an integer indicating the number of Coins of this same Model received by the same first owner (in total, including previous batches if any), indeed, once Coins are in circulation, the probability of having many Coins of the same Model in one's hand is very low, which dissuades from counterfeiting (duplication costs are only worth for big quantities, each Coin being able to be duplicated only once without being detected if the original Coin is kept out of circulation by the counterfeiter), but this probability is higher when receiving the first batch, the lower the number of received Coins, the lower the counterfeiting risk,

if homologue fields on the Coin's Model are present, mandatory if absent:

quantity: decimal number representing the quantity of Asset Type held by the Coin, if Model's homologue field is present it overrides it otherwise it becomes mandatory,

illustrations: see homologue field on the Model, to be used when the Coin does not look exactly as its Model's illustrations, because of handcrafting constraints, or because of security reasons (unique paint splash, coloured fibres inlaid in paper, etc.),

The communication protocol between the Blacklight and the microchip (for key signing and read-once self-erasing) isn't covered by these specifications, but it is likely to become a separated document. Other functions could be added to such microchips (e.g. holding the cryptocurrency's private key in memory instead of having it printed on the Coin, read-once auto-erased cryptocurrency's private key, self-generating cryptocurrency's private key so the Minter can never have access to it, etc.).

Any other field can be freely added, except for homologue fields on the Coin's Model, please contribute to help improving and standardizing them.

Optionally, a Coin record can be made private by having all its fields (except checkoin_version, uuid and encrypted_signature) serialized into a JSON string encrypted with the Visible Scan Data's Passphrase of the Coin, then nested into the encrypted field. However it might slow down the Scan process as the Blacklight will have to decrypt it for the Blacklight's server.

Visible Scan Data

An UUID with a unique dedicated Passphrase (of unspecified length), typically a QR Code visible on the outer surface of the object, preferably not requiring manual intervention to be unveiled it in order to facilitate mass scanning, along with the mention “Scan me with a Checkoin(.Org) Blacklight App”.

The data can be presented in two formats:

the 128 bits UUID immediately followed by the Passphrase,

encapsulated and encoded in a URL:

http(s)://checkoin.org/ckn/UUID#PASSPHRASE

For security reasons the Blacklights that will Scan the data has to be third party components, this is a key element in Checkoin's security design. However, in case the user has no knowledge of Checkoin, the Visible Scan Data should point out a neutral and safe location to download such a Blacklight App. To do so, and in order to reduce the single point of failure risk, the Visible Scan Data can propose multiple entry points for acquiring a Blacklight:

via the mention “Scan me with a Checkoin Blacklight App”, so the user is likely to search for a Blacklight App via a search engine or his/her smartphone's application store,

or

via the mention “Scan me with a Checkoin.Org Blacklight App”, so the user is likely to visit checkoin.org to learn about Checkoin and find the list of highlightedBlacklights, or search for a Blacklight App via a search engine or his/her smartphone's application store,

and/or

by presenting the data in the URL format, so any QR Code reader will open the dedicated landing page on checkoin.org that may present some very basic information about the Coin, Checkoin itself, and for sure list the highlighted' Blacklights proposed for install. Once installed, the Blacklight App should intercept URLs that match the //checkoin.org/ckn/ pattern instead of letting it being opened by the default application.

Sealed Cashing Data

Data allowing its holder to retrieve an asset in his/her possession without any other condition than being the first to claim it (typically the QR Code of an Armory cold storage wallet, offline wallet passphrase, the public+private key of a wallet, etc., but not limited to cryptocurrencies, it can give access to any redeemable asset). The data must be hidden by an irreversible seal which when opened shows obvious evidence of tampering to the naked eye (e.g. wax seal, thick scratch-card, etc.), or to the Blacklight “eye” (e.g. read-once self-erasing microchip).

For security reasons the Minter should not store this data, but might want to keep a hash of it associated to the Coin's uuid (e.g. to authenticate a compromised guaranteedCoin to be replaced).

Blacklight

A device (or smartphone application, etc.) able to perform a Scan of the Visible Scan Data of a Coin, exchange information about it with the Network (through its dedicated server), make verifications, and, if the Visible Scan Data is legit, display human readable information about the Coin's health.

A Blacklight might also be able to scan multiple Coins at once to provide a quick general estimation of a handful of Coins (e.g. for cash registers Blacklights).

The Blacklight mustn't ever send the Visible Scan Data's Passphrase anywhere, if any encrypting or decrypting needs to be performed by the Blacklight's server (or any third device, software, entity, etc.), the information to be encrypted or decrypted must be sent to the Blacklight for it to perform the process and send back the result to the server. Any decrypted information sent by the Blacklight mustn't be stored anywhere at anytime, and must have been erased from any cache memory once the Scan process has ended on the user side.

The communication protocol between the Blacklights and their servers isn't covered by these specifications, but it is likely to become a separated open and standardized REST API. The Blacklights are likely to communicate by default with servers owned and managed by their fabricators (for obvious technical an business model reasons), but they should be able to communicate with any server in an interoperable manner (while allowing some extra features to be server-specific), as a alternative or rescue option (e.g. partial Internet failure/censorship).

Blacklights applications and devices also have a corresponding record on the Chain.

Scan

A Scan is the scanning process performed by the Blacklight, and, unless the user explicitly asks for a “silent scan”, it also becomes a record on the Pool about the time and location of the Blacklight during the Scan (optionally encrypted). A “silent scan” doesn't mean that the geolocation information isn't sent to the Blacklight server for consistency analysis, it means that it is not recorded, however, in such case of “silent scan”, the Blacklightmust ask the user if he/she agrees to have this data sent outside of the Blacklight.

The default action is to make such a record, but in some cases the Blacklight can suggest the user to perform a “silent scan” (e.g. if the location is based on the IP address of the Blacklight and there is a geographical incoherence the Blacklight may ask “We detected a geographical mismatch. Are you using a VPN? If yes, you might want to perform a “silent scan” not to provide inconsistent information that can damage the integrity of the coin.”).

location: a comma separated string of the two coordinates representing the geolocation of the Blacklight when the Scan has been performed, as decimal degrees with negative numbers for South and West,

location_method: a slug defining the method used for geolocalizing the Blacklight when the Scan has been performed (e.g. "gps", "ipv4", "ipv6", "zipcode", "manual", "fixed_blacklight", etc.),

location_precision: integer defining the precision of the location in meters, -1 if unknown,

date: ISO 8601 timestamp of when Scan has been performed,

signature: Blacklight server manager's signature of all the other fields alphabetically ordered and serialized in a non-indented JSON string, so it can be trusted by being replicated on the Pool).

For privacy reasons there is no free fields for this type of record.

Upon user's request the fields location, location_method and date can be serialized into a JSON string encrypted with the Visible Scan Data's Passphrase of the Coin, and nested into the encrypted field. It allows to greatly reduce the possibility of tracking of the Scan by monitoring the Network, made virtually impossible to anyone not physically possessing the Coin (except if previous user(s) made a copy of the Passphrase or leaked it). However this process may slow down the scan process as it involves more back and forth encrypting and decrypting communications between the Blacklight and the Blacklight's server.

Checkoin

Checkoin may refer to checkoin.org, the technology, its specifications and its instantiation, as well as the future non-profit and neutral entity representing Checkoin and its community. This entity will be conceived and set up after a period of observation of the Checkoin ecosystem, and is likely to operate by its own rules upon smart contracts. Until then, this entity is its founder's natural person, Camille Harang. For the time being Checkoin is a codename, it might change – or not – by the time the first official specifications are being released.

Getting in

Crowdsourcing

If you wish to contribute to Checkoin, you are welcome to do so by using the GitHub tools, whether it be for technical improvements, remarks, questions, technology scouting, suggestions, or anything else. Please verify that there is no issue covering the topic you wish to introduce beforehand, otherwise feel free to open one. Once the topic has been discussed and decided you can fork the raw version of this document and make a pull request. Don't forget to append you name to the authors list if it's your first contribution.

Each raw version of this document (not the fair use illustrations of the checkoin.org website) is published under the Creative Commons BY-ND license in order to provide consistency and avoid confusion for each new version. But you are of course allowed to fork it to propose improvements to Checkoin, also, by doing so, you allow Checkoin to modify and republish your modifications under the same Creative Commons BY-ND license.

Crowdfunding

Checkoin is an ambitious industrial project, it will require an adequate funding to match the required standards to manifest it into reality. To do so, you are invited to make donations to fuel the continuous “rolling crowdfunding”, meaning that the development roadmap goes on as the funding comes in.

Rewards

If you are donating via “anonymous” cryptocurrencies, please register your donationbefore making the transaction.

The rewards will be distributed accordingly to the amount of the donation (that can be cumulated with other donations later on), with an advantage for the early donors (based on a timing ratio factor to be determined).

Contributors will also be eligible for rewards, but remember that one's work estimation is very subjective, depending on the time invested, experience, skills, ego, efficiency, aspirations, rivalry, etc. Checkoin will make efforts to be as fair and grateful as possible on this, but a disclaimer is required: if you have high expectations on rewards and are easily disappointed, you might want to go for a donation instead.

The rewards will be defined and adjusted in an empirical manner. I (Camille Harang, founder) had the idea of Checkoin after discovering the Satori Coin, I first started to conceive innovative physical cryptocoins, before realizing that a technology like Checkoin needed to be implemented beforehand to allow these Coins to circulate safely. After having dedicated myself to this task, I reserve the right to be eligible to reward(s), whether I want to dive into the minting adventure, or not… That's why I came up with the idea of the “highlight service or product” reward, in case I still feel like proposing Checkoin service(s) in the future. But that's a very subjective idea, maybe you'd like something else that I didn't think about? That's why you are invited to choose your reward!

→ You choose!

Please contribute to propose reward(s) you would like to receive. It can be anything as long as it doesn't threat to jeopardize or alter the project (e.g. technological security or privacy disruptions, unclear conflict of interest, etc.),

→ Your Checkoin service or product highlighted

The website checkoin.org will list upon request any service or product related to Checkoin (Blacklights, Models, Minters, Auditors, market places for Coins, Asset Producers, Asset Suppliers, Asset Managers, Asset Vaults, etc.), but the donors' products and services will be highlighted on the top of the lists. If you want your company to become the CoinBase-like or BitPay-like of the Checkoin's ecosystem, this highlight might be the competition advantage that'll make the difference. The duration and position of the highlight will depend of the donor's choice, according to the amount and of the donation (with a maximum of 3 years for the highest donation), and starts whenever the donor decides so.

Originally Checkoin is not a currency, just a physical transport layer for third party assets. However, once Checkoin will be up and running, and after a period of observation, Checkoin will research and develop a new currency that will be specifically dedicated to physical cryptocoins (likely to run upon the technology running Chain), and tailor made to the specificities of Checkoin and its ecosystem. For example, its value could be expression of the average of all the circulating assets, and be proposed as the stable currency of reference for stating prices on Blacklights, price tags, etc. This currency will be independent from Checkoin, or autonomous (e.g. definitive smart contracts), its money supply and eventual growth are to be defined, please contribute to propose other features and characteristics for this future currency. The donors will have a seigniorage privilege on the initial money supply of this currency, proportionally to the amount and timing of their donation.

Roadmap

Collaborative writing and finalization of the first specifications,

Official website for the community, development, documentation, business meeting point, etc.

Technology scouting,

Open Source implementation of the Chain, Pool, and directly related software,