Smart Property

Smart property is physical, real world property whose ownership is controlled via the Bitcoin block chain. Examples could include cars, phones or even houses. Making property smart allows it to be traded with radically less trust. This reduces fraud, mediation fees and allows trades to take place that otherwise would never have happened. For example, it allows strangers to loan you money over the internet taking your smart property as collateral, which should make lending more competitive and thus credit cheaper.

Smart property was first proposed by Nick Szabo in his 1997 paper, The idea of smart contracts. There are currently no implementations of this idea.

Background

Primitive forms of smart property are already common - if you own a car, it is probably required to come with an immobilizer. Immobilizers augment the physical key with a protocol exchange ensuring only the holders of the correct cryptographic token can activate the engine. They have dramatically reduced car theft, for example, immobilisers are fitted to around 45% of all cars in Australia, but account for only 7% of the cars that are stolen.

Many other forms of modern property are protected against theft using cryptography, for example, some smartphones will refuse to release certain keys if the correct PIN unlock isn't entered, and cryptography not only renders a stolen device fairly useless but makes it impossible to steal somebodies phone number as well.

Although these are victories for cryptography, the potential of cryptographically activated property has not been fully explored. The private key is usually itself held in a physical container (like a key or SIM card) and can't be easily transferred or manipulated. Smart property changes this, allowing ownership to be intermediated by Bitcoin miners.

Theory

This section assumes you have read and understood the page on contracts.

Let's start with the example of a car. The cars computer requires authentication using an ownership key. The ownership key is a regular Bitcoin ECDSA-256 key. The car starts its life at the factory gate with the public part of a newly created ownership key. A small token amount of Bitcoins are deposited on that key, call the amount T (it could be 0.0001 BTC for example). Additionally the car has a digital certificate from its manufacturer, and an identification key which has the public part in the certificate. This allows the car to prove things like its existence, age or mileage to third parties.

When the car is sold, the following protocol is used:

1. The buyer generates a nonce (random number) and asks the seller to send them the car data.
2. The seller gives the car that nonce, and the car returns a data structure signed with its identification key. The data contains the nonce, the cars public cert, data about the car, the public key of the current owner, and the transaction+merkle branch which transferred ownership last time. This ensures the buyer knows what they are getting and that it came from the real seller (it's not a replay).
3. The seller selects a key to receive the payment, k1, and names their price P.
4. The buyer generates a new ownership key, k2.
5. The buyer creates a transaction with two inputs and two outputs. The first input signs for P coins. The second input is connected to the output holding T coins for the ownership address. The first output sends P coins to k1 and the second output sends T coins to k2. This transaction is not valid because only the first input can be signed. The buyer passes this partially complete transaction to the seller, who then signs the second input with the cars current ownership key and broadcasts the transaction.
6. They wait for some confirmations.
7. The buyer presents the car with the Bitcoin transaction, a merkle branch linking it to the block header and then enough blocks to fill in the gap from the cars current ownership transaction. The car sees that the new transaction re-assigns ownership and is further along in the chain than its current one, plus it has enough work piled on top to be sure the tx won't be reversed. It then updates its ownership information. The car does not need to keep a full record of the chain nor all headers, but rather just enough data to be able to connect future blocks to the one it was previously presented with.

In practice this process would likely be handled using smartphones with NFC hardware - the act of touching the phone containing the ownership key to the dashboard would start your wallet app in a special mode that knows how to do smart property trades, after inputting the price the buyer and seller would then touch their phones together to finalize the deal. Although the cryptography is complex they would never need to know anything about it. The phone could double as a way to start the car as well.

Loans and collateral

Being able to trade physical property without fraud risk is useful, but we can add an extra layer to allow for secured low-trust loans. Consider a loan with which to start a small business. Rather than deal with a bank, you decide to allow people from around the world bid on your debt so you can get the best rates. For this to work, the strangers need some assurance that if the loan is not repaid, they get to keep the collateral - yet you still need to be able to use the car to set up the business.

We can do this by adding access keys to the ownership key. By signing a message with the ownership key, access keys can be added or removed. Access keys can be temporary in nature. This means that for the duration of the loan, you can re-assign ownership of the vehicle to the creditor whilst keeping an access key for yourself.

It would be best if the debtor had an assurance that, on repaying his debt, the cars ownership would indeed revert to his control. We can implement this as follows:

1. The creditor generates k1 and k2. k1 is used to receive the loan repayments. The loan size is L.
2. The creditor signs Tx1 that takes L coins from k1 and assigns it k2. This transaction also has an input/output re-assigning ownership of the car back to the debtor which is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. This transaction is not valid because the loan has not yet been repaid, so the output sums to more value than the inputs. The creditor sends this transaction to the debtor who keeps it.
3. As the debtor re-earns the money they spent, they add inputs to Tx1 to increase its value. This doesn't break the signature on the ownership key input/output pair because it was signed with SIGHASH_ANYONECANPAY so is independent of other inputs.
4. Once the transaction has enough inputs to sum to L, the debtor broadcasts the transaction, thus repaying their debt and simultaneously retaking ownership of the vehicle.

Because access keys can be given time limits, if the debtor does not repay the loan by its maturity period his access key expires and the car will no longer start for him. The new owner can now either come and pick it up himself, or if he doesn't want to (eg he is in another country), he can sell it using the low-trust sales protocol described above and collect the money that way.

Most loans are repaid in multiple installments. The same protocol as above can work in this case by embedding some control data in the extra input/output pair, the ownership key would not change but the signature would cover a command that extends the lifetime of the access key for another month. The vehicle would know how to parse the data out of the transaction.

Implementation details

For expiring access keys, the device must have a trustable source of time. Some devices like cars and phones keep time by themselves, but in cases where that isn't practical the block chain itself can be used as a source of time. Each time the smart property is used or unlocked with a time-limited access key, enough block headers would need to be presented to provide a rough estimate of the current time. For instance providing all headers up to the current time would give a good estimate of the time as of 12 blocks ago, and that can be extrapolated by adding a couple of hours to the current time. The device would not need to store anything beyond a single header because it does not need to handle re-orgs. This works for anything where drift of a few hours is acceptable, but isn't suitable for revoking access to minute/second precision.

Smart phones play a key role in smart property because they have the ability to bridge devices without network access to the network, using Bluetooth or NFC radio. For instance, requiring internet access for a smart lock on a house door is too expensive and impractical. However, a lock with an NFC touchpoint that understands how to check block header progression is quite feasible. The only operations needed to implement Bitcoin-linked smart property is hashing, ECDSA and a small amount of storage. Smartcard chips that implement everything required are common and cheap.