I'm happy to announce that the "green address feature" just went live on Instawallet.org.
Green address techniqueThe idea is simple: When you send money using Instawallet and activate this option, your transaction will be created in such a way that it only uses coins from a specific Instawallet address: 1CDysWzQ5Z4hMLhsj4AKAEFwrgXRC8DqRN. By looking for this "green address", others can verify that this transaction was created by Instawallet.
This allows Instawallet to act as a trusted third party for instant payments. If you trust that Instawallet will not perform double-spends, you can accept transactions from this green address without having to wait for confirmations. This mechanism has the advantage, that it is "in-band": As long as you are receiving Bitcoin transactions, you can implement this check. Furthermore, the technique can be easily implemented by other third parties (Mybitcoin.com, Mt.Gox, Tradehill, etc.). It is up to the recipient to decide from which green addresses they allow zero-confirmation transactions.
In summary: This mechanism allows to implement secure, zero-confirmation transactions with the help of a trusted third party while staying completely within the Bitcoin protocol.
Possible uses:
- instant payment at a vending machine
- instant payment at a store
- instant deposit at a gambling website
- lots of other possibilities!
Implementation notesIn theory, checking for a specific green address is very easy. In practice, unfortunately, the Bitcoin daemon currently provides no way of accessing this information using the RPC interface. A patch will have to be written and used. But this is a temporary problem, which should be easy to fix. Of course Blockexplorer or Bitcoincharts also provide a way of checking the input addresses used by a transaction.
VisionI hope this technique gains some traction and will be implement by a number of online wallets. It could then - for now, until a more sophisticated solution emerges - provide a way to do secure instant payments. By having this implemented by multiple parties, it should help to keep everyone honest and fees low (Instawallet currently provides this feature free of charge).
Merchants will have to decide which green addresses they accept and it might be necessary to standardize on a protocol that would communicate this automatically. I propose the following convention for the moment: When using a bitcoin URI (
bitcoin:14Z1mazY4HfysZyMaKudFr63EwHqQT2njz?amount=5) the additional parameter (green_address=r) should indicate, that the recipient _requires_ the use of a green address. This allows clients which recognize this parameter to prevent a "standard" transaction from being used, where it might end up not being accepted - let's say at a vending machine, where instant payments are the only option. Of course you can not prevent people from sending you money ;-) , but this would at least provide an automatic way of warning them about the fact, that you might not accept just any transaction.
Going further, it might become necessary at some point for a merchant to communicate which green addresses they accept. For this I propose the additional parameter "green_address_details=URI", where URI points to a JSON document describing acceptable green addresses. The format for this document should be extensible, as to allow both static addresses as well as pointing to yet other places (maybe some from of global green address directory?).
To keep Bitcoin URIs short (as they have to fit into QR codes), I also propose that for each of the possible arguments a short version is defined that can be used instead:
- a for amount
- l for label
- ga for green_address
- gad for green_address_details
Turning an URI like "bitcoin:...?amount=5&green_address=r" into "bitcoin:...?a=5&ga=r". While on the topic of Bitcoin URIs: I would have preferred for the amount value to be in Satoshis, but it seems that specifying it in BTC has already become common practice, so I guess I won't go against the grain on that issue then.
Short termThe above suggestions are of course still a long way off and might not materialize. For the moment it should be fine to assume the acceptable green address implicitly (as, of course, only Instawallet is implementing it right now anyway) and thus only support the additional parameter "green_address=r" or "ga=r". I will be putting together a small point-of-sale demo shortly, to demonstrate the use of this technique. (Merchant shows QR code, customer scans code and uses Instawallet to pay, merchant checks for green address and the sale is complete).
Looking forward to your comments!
Update: Those looking to create green-address-style transactions themselves, might want to have a look at this Github branch
https://github.com/javgh/bitcoin/tree/greenaddress and my comments about it further down (
https://bitcointalksearch.org/topic/m.418326 ). Although in the long run it might be better to implement this as a standalone solution, possible based on bitcoinj, which would only manage a single green address. This would keep it from interfering with other activities.
Update: There is now a point of sale implementation based on this approach. See this thread:
https://bitcointalksearch.org/topic/m.475829 .