Topic: Instawallet introduces new approach to instant payment: Green address technique - page 5. (Read 30213 times)

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!


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


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.


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

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.



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.



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



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.

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

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://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 .