Yap_Stone_Money

Exotic Transaction Types with Bitcoin

An audio recording entitled The future of Bitcoin: new applications and rebuilding the banking system has been making the rounds. The talk hails from the Bitcoin 2012 conference last weekend in London. In it, BitcoinJ author Mike Hearn discusses some of the shortcomings of both Bitcoin and the standard banking model and how the Bitcoin protocol can be modified (or in some cases already includes the basic framework) to include exotic new transaction types to solve both Bitcoin’s woes and the woes of the traditional model. Hearn sees many of these transaction types in our mid-to-long term future (5 to 10 years) though he stresses that everything in the talk is implementable today by any reasonably skilled programmer. In today’s post we’ll briefly discuss each of these transaction types and find out which ones you want to see implemented first.

In before the inevitable questions: the featured image at the top of today’s post is a type of stone money known as a Rai – it’s the first thing that popped into my head when I starting thinking about exotic currencies and transactions.

Micro-Payment Channel

Because of the distributed nature of Bitcoin, there are a lot of checks and balances to prevent someone from flooding the network – in essence the transactions from a single node are rate-limited and while that’s ok for most of the transactions we handle daily, there are some edge cases, like billing for metered services, where you might need dozens or even hundreds of transactions in a few seconds.

The way it works, essentially, is that you broadcast one transaction to the network for a fairly large amount of bitcoin, and then you and the nodes involved in that transaction can modify it as much as you’d like, hundreds of times per second even, without broadcasting to the network. When the transaction is finalized, the outputs of the transaction are broadcast as normal and whatever portion of the original coins you haven’t spent return to your wallet.

Dispute Mediation (multisig aka M of N)

Bitcoin has no chargebacks, which is an intentional feature, but this also means that unless you go out of your way to set something up beforehand, there is no way to dispute a legitimately failed transaction. The current method most folks utilize is escrow via a mutually trusted neutral 3rd party – I send my coins to Party X, the merchant sends the product to me and if things go well, Party X forwards the merchant my coins. If something goes wrong, we all work something out and Party X forwards the coins to whoever is appropriate. This of course introduces the difficulty of finding a mutually trustworthy escrow agent since if someone less-than-trustworthy is chosen they can run away with all your coins. Worse yet, there’s always the possibility of a trustworthy and experienced escrow agent getting hacked and losing your coins through no fault of their own.

There is a way, however, to implement a transaction where all three parties involved participate in the initial transaction and it can only be completed if a certain number of parties agree, in the example above we’d choose 2 out of 3. This way if the merchant and I don’t dispute the transaction, we can finalize it without the escrow agent’s intervention. In the event of a dispute, the merchant and I cast opposing votes as to how the transaction should be finalized and the escrow agent casts the deciding vote – but best of all, the escrow agent never actually has access to any of the coins unless either I or the merchant also sign off on the transaction.

This not only lowers the bar on finding a mediator, but also on becoming a mediator: this means that your escrow agent can be an expert on the thing you’re trading and not have to also be an expert on Bitcoin and related security.

It’s also possible to implement what Hearn referred to as an “Oracle” – a program that has the ability to sign off on transactions. If the condition for completing your transaction is something that a program can test for then such an Oracle could act as a mediator without ever requiring human intervention at all.

Lock Times

Less of a transaction type and more of a feature which can be added to any transaction, lock times allow for the creation of a transaction whose outputs only become valid after a certain date and time. These could be used, for example, to gift moneys that only become valid after a child’s 18th birthday – a very common legal transaction which would no longer require human intervention or legal enforcement with Bitcoin and lock times.

Assurance Contracts

While they never use the term itself on their site, the most commonly understood example of assurance contracts may well be the popular crowd-funding site KickStarter. For those not familiar, a KickStarter contract happens like this: The project founder submits their idea and the estimated amount of money it will take to make that idea a reality. If the combined value of all pledges is greater than or equal to the amount they specified, they get the money and start work on their project. If the value of all pledges isn’t enough, they get nothing and the money goes back to all the investors. This is another transaction type that would be fairly easy to implement in Bitcoin, with the added bonus of not requiring any third parties.

Smart Property

The basic concept here is to allow the transfer of ownership or extend access rights to digitally-controlled devices such as cars that use RFID keyfobs to start or wireless/keyless entry systems for homes and offices by embedding messages in the Bitcoin block chain. The wielder of a given Bitcoin address can sign arbitrary messages with his or her private key to verify ownership of an address, and it’s possible to embed access data in a transaction that could be understood by access systems that can parse the block chain.

I could set up a rule, for example, that access to my front door may be granted or revoked by key A (me) or key B (my wife). My friend has key C and I want to give him access to my front door, so I use key A to sign a transaction that has some data in it telling my keyless entry system that the wielder of key C may enter. My friend shows up and authenticates at my door with key C and is allowed entry. Later I can sign another method revoking access. This honestly isn’t much different than how many current keyless entry systems work, but is cryptographically stronger and would be outrageously convenient in a future world filled with NFC-enabled smartphones and Bitcoin wallets.

This could also be used to better secure collateral on loans. When I buy a car, the lender can simply sign a message giving me time-limited access to the car. If I fail to make payments, they simply refuse to send the message and the car won’t start for me any more – they still retain access and can sign access rights to a repo company if necessary, or given that lack of payment loses me access to the vehicle it might be more reasonable to have longer grace periods, given that I now have stronger motivation to pay my bill. At the end of a successful loan, a similar transaction could grant me full ownership rights and remove the loan company’s access to the vehicle.

Better yet, the entire contract could be written into the Bitcoin protocol and neither party would ever have to trust the owner at all – if the lender disappears, resells the debt, etc. it means nothing to the borrower since what controls access is Bitcoin, not the lender. Similarly if you’ve got LoJack/OnStar/etc and a cryptographically secure way to revoke access rights, repos suddenly get a lot easier to perform but impossible to perform fraudulently. Stuck with a car you can’t use because you’re missing the payments? Sell it to someone else by transferring the contract – they start making payments, it starts working for them. Easy peasy.
Imagine the implications for law enforcement if warrants had to be digitally signed by a judge or if the property owners had to digitally sign to allow entry and the systems themselves enforced this – no more questionable gathering of evidence and no more unlawful searches in one technological swoop.

Cross-Chain Trading

There are several alternate cryptocurrencies already in existence, and several more works-in-progress. While many are dismissed as useless slightly tweaked Bitcoin variants, others like NameCoin (NMC) serve an additional purpose. There are tons of other ideas for things that could be done with Bitcoin alt chains but they then bear the difficult problem of exchanging across chains.

If you want to trade BTC for NMC you need an exchange (or other third party) or a lot of trust in the person you’re making the exchange with. Contracts worked into the protocols of both chains could be implemented that allow a secure and trust-free exchange of funds across chains via the exchange of secret keys embedded in the transactions. Hearn suggests this could be used to open a bonds market using the Bitcoin protocol on an alternate block chain to exchange bitcoins for contracts and then use those contracts to pay dividends in bitcoins.

It’s also entirely possible that access systems could be set up on the traditional currency side of the fence to allow similar exchanges of traditional moneys, thus enabling peer-to-peer exchanges which would be much more difficult to shut down, steal from or otherwise compromise.

Which transaction types would you like to see implemented first?
(You may select up to 3)

View Results

Loading ... Loading ...
No tips yet.
Be the first to tip!

Tip With Bitcoin

1J8KWj7drho8b5gyDzwcd788a3LDxXuZ19

Each post has its own unique address, so your tips also tell me what you liked!
Vote with your wallet!

  • 256

    It's extremely important to bear in mind that the simplicity of the protocol is key to making "all bugs shallow". I hope these are done eventually, *on top of* btc, not on the btc protocol itself. I'd rather take a paranoid risk-management stance than see lots of (cool) innovations rapidly changing the protocol.

    Indeed, these are very cool ideas.

    • http://codinginmysleep.com David Perry

      One of the cool things about the way Bitcoin was implemented is that it supports transactions which are essentially miniature scripts. Within certain confines (safety first!) you can essentially write a transaction in the form of its own program, so whatever exotic transactions you can assemble from the building blocks Bitcoin makes available, you are free to implement.

      As long as the Bitcoin protocol maintains the security of those building blocks, it's done its share of the job, it's then up to the users what features they want available and I'm sure there will be no shortage of specialty clients in the future with all variety of exotic transaction support, whether or not those transaction types find their way into the Satoshi client.

  • Pingback: Exotic Transaction Types with Bitcoin | Bitcoin News Bits - CoinBits.com()

  • http://twitter.com/agilestack Gary Rowe (@agilesta

    You can see more detail about this from the Bitcoin Stack Exchange Q & A site here: http://bitcoin.stackexchange.com/questions/547/us… (contains various launching links to more detail)

  • Pingback: LiteBit | Exotic Transaction Types with Bitcoin()

  • Pingback: Bits and Pieces 22ndSep | DGC()

  • Pingback: When is "Good" Good Enough for Bitcoin? » Coding In My Sleep()

  • http://twitter.com/JoeCascio @JoeCascio

    When it comes to retail transactions, there are several use cases that might be addressed by some of these capabilities.

    Examples:
    * Self-serve gas pump. You want to be able to "fill 'er up", but you don't know how much the total is until after you've pumped the gas. Most stations require cash customers to pay first. I suppose that could work with bitcoin, too, but it makes for either not filling all the way, or having to go back for change.
    * Subscriptions. You want to allow auto-payment of recurring charges agreed to in advance. Many companies take credit cards to do this now. How to implement with bitcoin?
    * Guaranteeing a hotel reservation. This is done now with credit cards. How to implement with bitcoin?