Bitcoin Embedded Property Chains

There were many attempts to re-purpose Bitcoin’s secure transfer mechanism of its own units to transfer property rights. I present a new breakthrough approach.

Even those skeptical of Bitcoin’s monetary value recognize that it transfers its own units with unprecedented security, un-censorable and global.

Having the same utility to transfer any other asset, that is e.g. USD, Land, Equity, would be enormously useful. There were many attempts to do this with all kinds of overlay protocols and side chains linked to the Bitcoin chain.

None of these approaches managed to establish a design pattern until now that would have been as widely used as a much less secure option offered by Ethereum.

Property transfer

One could interpret a certain coin (UTXO) of Bitcoin as the right to a property and then track its movement to new owners. This is the basic Idea of most overlay designs.

There are technical issues with this, but more importantly why would anyone respect the transfer of property right expressed with the Bitcoin transaction the real world?

Transfer of property rights is usually possible through a 3rd party who maintains a register. The transfer is only valid if that registrar thinks it is valid.

Smart Contracts

There could be arbitrary rules applied by the registrar that a transfer must comply, so the registrar approves it. Attempts to capture the rules in a smart contract as advocated with Ethereum have been consistently failing for technical reasons or remained far from the complexity of the reality.

Validators

A better approach is to ask the consent of the registrar for the transfer transaction to be valid. This practically means the registrar also has to sign the transfer transaction in Bitcoin so it becomes valid. This way Bitcoin does not have to know the rules the registrar applies, just that the registrar agrees that the transaction is valid.

There could be many independent validators that together act as a registrar by contributing to a threshold signature. This allows us to implement a consent by majority opinion of the validators.

Side Chains

There are many features that would make Bitcoin more useful if they would be available there and many rules that if validated by the Bitcoin nodes would support more uses of it. Since preferences and goals differ it is very hard to reach consensus and sufficient support for a change even if it is undoubtedly useful. This made people experiment with side chains that freely define their own rules and how value is moved between Bitcoin and the side chain.

The problem with side chains is lower security. First they can not compete with Bitcoin’s POW and second it takes time until their unique design is perceived similarly trustworthy as Bitcoin’s.

Embedded Chains controlled by Covenants

It would be much more attractive from the security viewpoint if side chain was only a logical construct embedded into the main Bitcoin chain.

For this we have to find the bare minimum of backward compatible changes to Bitcoin that allow a logical isolation of transactions making up the chain and ensure additional validation of those with arbitrary added rules.

I proposed earlier the introduction of generalized covenants for the purpose of supporting full reserve banking and posted an more generic example this morning onto the developer’s mailing list how these could be used to create a a property right chain embedded into Bitcoin. There you find technical details, here I explain the concept in plain english.

The first problem to solve is that a coin (UTXO) that is considered to represent something else than Bitcoin may not escape the validations mandatory for transfers of that asset. A covenant achieves this by encumbering the coin with a restriction that it can only be sent to addresses that require a signature of the validator of its asset class. A covenant may also mandate that any coin that arises from splitting or merging of a coin associated with the covenant also inherits the covenant. This creates a transitive control of validators for the asset class.

The second problem is to ensure coins can only be split and merged such that before mentioned transitivity is well defined. That is e.g. that one should not be able to create Bitcoin transaction that would merge coins encumbered with a covenant with plain coins or coins bound to a different covenant.

I am pretty sure that both changes can be implemented and hope that fellow developer will agree that this design pattern for embedded chains constitutes the most powerful yet least invasive way to significantly extend Bitcoin’s use, so it has the chance of being deployed to the network.

The example I gave is a generic property chain embedded into Bitcoin, that could represent movement of ownership rights of just about anything provided their registrar is willing to sign transactions for the Bitcoin network.