Instawallet introduces new approach to instant payment: Green address technique

[jav]

I'm happy to announce that the "green address feature" just went live on Instawallet.org.

Green address technique

The 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 notes

In 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.

Vision

I 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 term

The 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://bitcointalk.org/index.php?topic=32818.msg418326#msg418326 ). 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://bitcointalk.org/index.php?topic=38893.msg475829#msg475829 .

[1714163023]

1714163023

[1714163023]

1714163023

[1714163023]

1714163023

[BitPay Business Solutions]

I'm happy to announce that the "green address feature" just went live on Instawallet.org.

Looking forward to your comments!

Jan - we loved this idea the first time we heard it.  We'll work with you to support this 100% on the merchant side.

[netrin]

Something like this was inevitable, but none the less brilliant. Glad to see Instawallet ahead with simple innovations.

What is the significance of the name "Green" address?

I would have hoped your address would be more memorable, perhaps a "vanity" address with short 5 character firstbits. The best I can do for mnemonic is CoDe-YeS-W.

implemented by other third parties (Mybitcoin.com, Mt.Gox, Tradehill, etc.). It is up to the recipient to decide from which green addresses
...
In 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.

Why not patch the C++ client to accept a list of "green addresses" from bitcoin.conf and display 0/green_unconfirmed in the transaction log? I expect you'll find support for it. Later we can consider a more complex DECENTRALIZE WOT model. You are in the best position to immediately implement this and see how sticky the patch is. We vote with fork pulls.

honest and fees low (Instawallet currently provides this feature free of charge).

As long as it's free, it'll be a value-add for your service. I would never pay for this a la carte.

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)

Fair enough if the community finds consensus or demands this, but I don't immediately see the need. I would be worried that merchants will just as soon accept "Google" bitcoin payments only to the detriment of great services like Instawallet.

[jav]

Jan - we loved this idea the first time we heard it.  We'll work with you to support this 100% on the merchant side.

Thanks! And by the way: Congratulations on the launch of your merchant services! :-) I saw excerpts of the Bitcoin show about it and it looks great!

What is the significance of the name "Green" address?

No special meaning (well maybe green as a symbol for "go ahead, it's safe"). I just picked a name for it so it's easier to talk about it.

I would have hoped your address would be more memorable, perhaps a "vanity" address with short 5 character firstbits. The best I can do for mnemonic is CoDe-YeS-W.

I was thinking of creating a vanity address, but then decided not to do it. I was wondering if people might start relying on recognizing the address from memory. That might be dangerous, as it is not hard to create another vanity address that looks similar and that might slip by such a "manual check". So this way people might rather give the task of comparing it to a computer, which tends to not be fouled by these things. ;-)

Why not patch the C++ client to accept a list of "green addresses" from bitcoin.conf and display 0/green_unconfirmed in the transaction log? I expect you'll find support for it. Later we can consider a more complex DECENTRALIZE WOT model. You are in the best position to immediately implement this and see how sticky the patch is. We vote with fork pulls.

Interesting suggestion. But I think that is putting a little bit too much stuff into the Bitcoin daemon which isn't really related to the "core" protocol. I would (and probably will soon) rather go the way of providing an RPC call that returns input addresses used by a transaction and then build an external tool around that.

Fair enough if the community finds consensus or demands this, but I don't immediately see the need. I would be worried that merchants will just as soon accept "Google" bitcoin payments only to the detriment of great services like Instawallet.

My reasoning here is, that in some situations you can _only_ accept instant payments and it's a little bit of a problem when you have to rely on the user to actually do that (you know how users can be). Let's say you build an ATM machine based on this: ATM machine shows QR code, says "please use a green address", receives the transaction, checks the green address and gives you some bills. Great until the first user comes along who ignores the "please use a green address" (such a person will appear very quickly) and sends a "normal" transaction. Now your machine is in trouble. It can't accept a zero-confirmation transaction and blocking the machine until enough confirmations are there isn't really an option either. There is also no easy way of returning the money, but of course you can't just keep it either. So it turns into a support case where you have to manually intervene and return the funds.

On the other hand, if the ATM machine could already signal this "please use a green address" in the QR code itself, then the mobile app (at some point hopefully) would understand that and - even if it doesn't support this mechanism - prevent the user from doing something that won't work anyway.

Well, maybe a big sign on the ATM machine saying "Only green address from Instawallet accepted here" would also work, but I'm not entirely convinced on that. =)

[wumpus]

Very nice idea, great that someone finally implemented it!

And now we have a good reason to let the be able to show the source addresses somehow

Fair enough if the community finds consensus or demands this, but I don't immediately see the need. I would be worried that merchants will just as soon accept "Google" bitcoin payments only to the detriment of great services like Instawallet.

I think this fear is unfounded. The green address would only help for trusting 0-confirmation transactions from certain sources. The rest can wait for 1..6 confirmations as normal.

[kjj]

If you expect a lot of services to show up and offer these, you are going to need to find a way to negotiate which providers are acceptable to a merchant.

[bitplane]

A client with a decent interface could just have an address book with a "trusted" checkbox next to people in the address list. If an address belongs to a trusted party, it could be a green "0/unconfirmed (trusted)" or whatever.

Merchants and providers could just let users download a vCard containing their bitcoin address, and/or have it embedded in their contact pages using an appropriate XHTML microformat.

[jav]

If you expect a lot of services to show up and offer these, you are going to need to find a way to negotiate which providers are acceptable to a merchant.

Indeed. This is what I was aiming at with this paragraph:

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?).

[CryptoCommodity]

Question - where would I be able to see this specific address?  When I look at my Bitcoin Client received transactions it simply states "From: unknown" and doesn't provide the address the coins originated from.  

People can use blockexplorer.com to see the orginating address but that isn't instant.

[jav]

Question - where would I be able to see this specific address?  When I look at my Bitcoin Client received transactions it simply states "From: unknown" and doesn't provide the address the coins originated from.  

An existing tool that can show this is the list of unconfirmed transactions at http://bitcoincharts.com/bitcoin/ .

[realnowhereman]

Brilliant idea.

Well done.

There is probably scope for making this green address idea peer-to-peer in parallel with bitcoin itself.

For example, one could broadcast an address to a "green" node, and it will be rebroadcast until one of the nodes broadcasts back with, say, a GPG signature of the key.  Then you can load up as many public keys from trusted "green" providers as one wishes in your shopping basket.

[jimbo77]

Pretty neat. Can someone fake the from address? It won't make it in a block but could they fake a transaction with a fake from address? Or if the private key was stolen you would have to have some way of revoking the "green address".

[Trader Steve]

Very nice!

[coblee]

I like the concept but don't like the name. Green is used these days as something eco friendly, which has nothing to do with this concept.

You should call it something like "trusted address" or maybe a geeky name like "zero conf address"

Just my 2 bitcents.

[Trader Steve]

Question: Does this help with anonymity or does it create some "plausible deniability"?

[coga]

Is this service already in production? I would certainly like to support it on btcbuy.info , I am advertising my service as a "quick" one, but the fact is that I have to wait for a confirmation, which often adds a lot of extra time to the wait

[symbian]

This won't work out if you got eventually an orphan block first confirmed transaction. The block may be marked ORPHAN if integrity of the network would be broken for some time, so this transaction will be confirmed in other chain a lot of blocks later or may be even lost(?). That's why it's recommended to wait untiil 100 confirmations. I suppose it's quite easy to separate bitcoin clients and break network for hours or days.

[coga]

This won't work out if you got eventually an orphan block first confirmed transaction. The block may be marked ORPHAN if integrity of the network would be broken for some time, so this transaction will be confirmed in other chain a lot of blocks later or may be even lost(?). That's why it's recommended to wait untiil 100 confirmations. I suppose it's quite easy to separate bitcoin clients and break network for hours or days.

Sometimes it is cheaper to bear a loss, than to lose a customer

[BitPay Business Solutions]

Jan - off-topic but can you add a QR image to your website home page that has the wallet bitcoin address?  you can get a free generator from Google's Chart API.  That will make it much easier to send money to the Instawallet!

[netrin]

No special meaning (well maybe green as a symbol for "go ahead, it's safe"). I just picked a name for it so it's easier to talk about it.

I suppose the name 'instawallet' was already taken. I agree with a later poster. Green has little to do with it. Rather instant and trustworthy = Instantrust?

I would have hoped your address would be more memorable, perhaps a "vanity" address with short 5 character firstbits. The best I can do for mnemonic is CoDe-YeS-W.

I was thinking of creating a vanity address, but then decided not to do it. I was wondering if people might start relying on recognizing the address from memory. That might be dangerous, as it is not hard to create another vanity address that looks similar and that might slip by such a "manual check". So this way people might rather give the task of comparing it to a computer, which tends to not be fouled by these things. ;-)

Are you familiar with firstbits? It is short, unambiguous and decentralized - indeed all that is required is the block chain and a simple algorithm. Your "green" address is 1cdysw and nothing more (nor less). The genesis address was '1'. All others are 2+ characters.

However, I guess the SENDING address does not need to be as memorable as the RECEIVING address.

Why not patch the C++ client to accept a list of "green addresses" from bitcoin.conf and display 0/green_unconfirmed in the transaction log? I expect you'll find support for it. Later we can consider a more complex DECENTRALIZE WOT model. You are in the best position to immediately implement this and see how sticky the patch is. We vote with fork pulls.

Interesting suggestion. But I think that is putting a little bit too much stuff into the Bitcoin daemon which isn't really related to the "core" protocol. I would (and probably will soon) rather go the way of providing an RPC call that returns input addresses used by a transaction and then build an external tool around that.

It seems a purely presentation layer feature. I already see 0/unconfirmed transactions. All that has to happen is that the presentation logic recognizes the sending address, matches it against a list, and displays 0/green_unconfirmed.

in some situations you can _only_ accept instant payments ... ATM machine shows QR code, says "please use a green address", ... user comes along who ignores the "please use a green address"

Sure, but then you need a hand shaking protocol and never send the receiving address before confirming the client/user groks the green address concept.

  USR: Hello, I wanna buy a cola
  ATM: Hello, it's 0.25 BTC, payable by 1A, 1B, 1C, 1CDysW, 1D green addresses
  USR: Great, I love green addresses, what's your address?
  ATM: 1bitcola
  USR: You can expect that from 1CDysW
  ATM: Got it, Thanks. Now here's your cola