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

You can only use Firstbits on addresses that already appear in the block chain, i.e. that have received some coins. I think in a point of sale setting you would typically generate new addresses to better keep things separate, so they don't yet have a Firstbit representation.

Why not compressing with firstbits the destination address too?
If you don't want the modified client to receive all the blocks, it could use a web service. I guess that's too risky.

I also wanted to document a few things that could be done to help the adoption of the green address technique. As my time permits, I will be working on some of these in the future as well, but of course I won't complain if someones beats me to it. :-)

• Write a patch for the Bitcoin daemon that makes it possible to access input addresses used by a transaction using the RPC interface and get this patch accepted into mainline.
• Summarize the information in this thread (especially regarding the format of the QR code) into an implementation guide to be put on the wiki.
• Write a standalone daemon which manages a single private key and creates green address style transactions using this key. Although I'm not very familiar with BitcoinJ, I would imagine that this might be a nice project to use BitcoinJ for. Having such a daemon, would make it easier for other sites to start offering the green address feature as well.
• Using the above daemon add green address functionality to Vibanko's source code and have it accepted into the official version running on vibanko.com .
• Lobby for other ewallet and exchange sites to offer this feature.
• Modify an ATM to use this technique. :-)

So these are some ways how you can help out, if you think this green address idea has promise! :-)

I have thought some more about the situation where a merchant wants to only accept green address transactions. It seems to me, that this would be the typical setup anyway, as this is a security feature and as such only works when it's applied all the time. If you still allow standard transactions, a possible attacker will always opt to use them. This means, it needs to be very straightforward for honest customers to use this technique, so that an attacker can not claim to just be a clueless customer ("aw, I forgot to tick the check mark for the green address feature, sorry about that"). It does not necessarily have to be impossible to send a standard transaction, just elaborated enough that it looks suspicious if someone goes to the trouble of doing that.

This leads me to believe, that the right thing to do is to deliberately break address format compatibility. I'm thinking of simply prefixing a G to a Bitcoin address which is presented to receive a green address transaction. A compatible client can recognize this and simply remove the G from the address before sending, while clients without support will throw an error. While the error will probably not be very helpful ("invalid address!"), it will at least prevent the user from attempting something that won't work.

So combined with other conventions mentioned in this thread - and also employing the reduction technique (a for amount etc.) to compress the link a little bit - I would imagine the following setup for a hypothetical ATM machine accepting Bitcoins:

First step: The machine presents the link bitcoin:G14Z1mazY4HfysZyMaKudFr63EwHqQT2njz?a=5&ga=r&gal=1cdysw as a QR code.

meaning: An amount of 5 BTC (a=5) should be transferred to 14Z1mazY4HfysZyMaKudFr63EwHqQT2njz (the address with the G removed) using a green address (ga=r, short for green_address=required) and will be accepted from the green address defined by the Firstbits 1cdysw (gal=1cdysw, short for "green_address_list=1cdysw" which could list several acceptable addresses separated by commas).

A compatible client will be able to read the address correctly and double-check that its green address provider (e.g. Instawallet) has a green address that appears in the list of accepted addresses. An incompatible client will simply throw an error, as the address looks invalid to it.

This should reduce the number of standard transactions that happen regardless of these measures to situations where someone does it deliberately (to attack the system or just to be annoying) or very rare cases of honest users somehow managing to still send a standard transaction ("fixing" the address by hand maybe). These cases could be dealt with with a refund process. In the case of the ATM, the machine could simply say something like "Sorry, I received a standard transaction to this address which I can not accept, please receive your refund note" and then the ATM's machine will print a note containing the private key of the Bitcoin address that was displayed. The person can then get their erroneously send money back, by importing this private key. 

There is now a point of sale implementation based on this approach. See this thread: https://bitcointalksearch.org/topic/m.475829 .

I'm not sure if some people try to use this feature to launder Bitcoins, but I just want to point out that it doesn't bring any particular advantage in that respect.

You can already use Instawallet, just like pretty much any site with a largish wallet.dat, to launder Bitcoins. Just sent them there, wait some time, then withdraw them from your account and chances are pretty good that you will get different coins. You are welcome to use Instawallet in this way and even save yourself the cost for some of the Bitcoin laundry sites around. ;-) (Of course the coins could be linked using Instawallet's logs, but that risk can be reduced by routing the coins through multiple sites. That way they can only be linked if the attacker has access to the logs at all of the sites.)

Whether or not you additionally route it through the green address doesn't really change much. So in that light, I would ask you to refrain from it. It puts unnecessary additional strain on the block chain. Currently Instawallets green address transfers require 2 transactions (from the specific wallet to the green address and then from the green address to the destination).

Note though, that this technique doesn't necessarily require 2 transactions. The green address could be replenished only from time to time with a single large transaction. But that is an optimization that I haven't implemented yet.

You're welcomed.
Yes, I think the second idea would need this system and decentralized ripple working. So it's for the future.

Yes, but the buyer has to trust them, so it only makes me vaguely uncomfortable.  Still:


I'm much happier with this, too.  I hadn't seen firstbits before; neat!

Cheers,
Rusty.

I don't think interpreting them as prefixes is such a good idea. Someone can come up with an address that matches the prefix in ways you didn't plan.

But as jtimon points out, it seems indeed like a good idea to interpret them like Firstbits does. So only the first match in the block chain counts. Sounds like a good idea to me! Allow a field "green_address_list" (short "gal") to specify acceptable addresses in Firstbit format directly in the QR code and only use the "green_address_details" mechanism when that starts to get too long to fit comfortably into the QR code. Thanks for the suggestion!

As to Ripple: Definitely an interesting candidate to provide a more general approach to this. I have written a little bit about that here: https://bitcointalksearch.org/topic/m.362094 . But that's still a little into the future, I would guess.

Very good idea, POS payments look easier now.
A little suggestion. Can't firstbits make green_address_details shorter?

And for the future, I think it can be improved with Ripple. If the green addresses holders participate in a Ripple network, they can improve the liquidity of their clients. For example, if the client has a mtgox account, mtgox has a Ripple connection with instawallet, and the merchant trusts instawallet but not mtgox, the trade can still be done.
But for this a protocol would be needed between servers.
First the normal steps would be followed, but if it customer can't pay through any of the addresses on the merchant's whitelist, he will ask to his server to try to make a ripple payment to one of these addresses and if it can, the server receiver of the ripple payment will make the bitcoin payment.
Note that thanks to ripple both servers doesn't have to trust each other directly. They can agree with their trusted partners the settlement conditions and the credit limits they like. Since the settlement of debts can be made through the green addresses, different servers can have information on each other's immediate solvency and avoid running out of "green funds".

OK, I would suggest a comma-separated set of prefixes for green-addresses, and optionally a "gad" URI as well.  This has some nice features:

• You can specify that you accept any address by simply listing "1".  This might be used to indicate slower service for non-green addresses.
• You can specify the full hash, if it fits.
• Since you trust your green providers anyway, you can trust them to sort out distinct address prefixes.  They'll only be annoying their own customers if they choose one which clashes

Cheers,
Rusty.

You should make the green address look green: 1GreenkXsfH7usrBZBZUGnv6dZ9TtvsBhs

For those looking to create green-address-style transactions themselves: This is the commit adding the feature to Instawallets Bitcoin daemon:

  https://github.com/javgh/bitcoin/tree/greenaddress

It's a little bit hacky, as it's tailored for Instawallet and has a specific address hard-coded, but is probably still a good place to start if you are looking to duplicate this functionality.

It basically modifies the coin selection method. In the case where a green address transaction is created, it only selects coins from the green address and also makes sure that any change goes back to the address (so we are not running out of funds). In the case where a standard transaction is created, it makes sure to _not_ use coins from the green address, as to have them available for later.

The feature is then made available through the RPC method "sendgreen". Sendgreen expects to be passed a Bitcoin account, which you can use to keep track of how many coins you have ready to send via a green transaction.

Sounds intriguing. I love the simplicity of InstaWallet. Anything you can do to make it easy for small retail businesses would be great.

This can't be faked, no. The client will consider the transaction as invalid right away and not display it at all.


As far as sending these transactions from Instawallet is considered, this is already in production, yes. The best way of checking for the green address still needs to be worked out though, as the Bitcoin daemon currently provides no easy access to this information. So you might want to wait until that is sorted out before you try to integrate it. Alternatively you can write a nice patch yourself or bug the developers about it. Yay for open source. =)


As was later pointed out, you seem to be confusing some concepts. Orphan blocks have no impact on this approach at all. A green address transaction isn't really all that different from a normal transaction. And those don't disappear either when they end up in an orphaned block. They will just be confirmed with another block instead.


Yes, I plan to add this at some point.


I don't want to have "trust" in the name. It is presumptuous. Whether or not someone trusts a particular address is up to them. It has nothing to do with the address itself, so it shouldn't have a name that pretends so.



I invite you to implement such a protocol and have it gain widespread acceptance. No seriously, I also think that something like this is needed at some point. Not only in the context of green addresses, but for Bitcoin payments in general to be augmented with additional information. But my proposal for the QR codes solves the "users doesn't grok green address concept" in 80 % of all cases and requires minimal modifications to existing tools. That's a valuable thing in itself as well.


Nice idea! It seems to me, that this would be better as a separate site, as it is targeting a different user group with a different set of requirements, as you are pointing out. As such, anyone is free to to start such a site! But you might be interested to hear, that I'm working on a similar idea, however not web-based, but as a standalone tool.

I just had an idea: The InstaWallet can have a simple form field calculator where the employee can enter the dollar total and click "convert". The calculator would make the conversion based upon the latest exchange rate and the BTC amount would be generated and displayed.

Jav,

I have an idea to make InstaWallet easier for small retail businesses. I call it the "InstaWallet Cash Register". Here's how it would work:

You make a couple, simple modifications to your wallet page so that it shows 1.) the current exchange rate, and 2.) the last three transactions/payments received. Example Screen info:

Recent Payments Received:

qweru454834454jdkdjv8cjkad -   0.501 BTC
kdyylsldjfjghe884fi33l4kngn&4 -  0.735 BTC
ietmvidiiww489yv94nkdnviind9 - 2.325 BTC

Wallet Balance: 3.561 BTC

Here is the reasoning and set-up for the business owner:

The employee running the cash register needs a quick and easy way to accept payment from bitcoin users. Ahead of time, the business owner generates an InstaWallet page on the cash register computer and then creates a bookmark or hotlink to the page. Next, a QR code is generated, printed, and posted on the front of the cash register. Now the business is ready.

Example Transaction:

1. Customer walks up and scans the QR code while placing his order, he also opens up his own bookmarked InstaWallet on his smart phone and tells the employee that he would like to pay with bitcoin
2. Employee rings up the total and clicks on the InstaWallet hotlink
3. Employee manually converts the order total to BTC using the displayed exchange rate and tells the customer his total (perhaps a calculator can be provided right on the wallet screen? Or maybe this conversion could be automated some other way.)
4. Customer makes the payment (using the "green" option if he wants to)
5. Payment pops up on the business cash register InstaWallet page - this is easy to see and verify by the employee because it is the latest transaction of the last three transactions and the total received matches the order total.
6. Employee rings up the transaction as cash received and the deal is done.
7. At the end of the day this cash register wallet is emptied by sending the balance to the business owner's private wallet.
8. Each cash register can have its' own unique InstaWallet page bookmarked

Additional Comments:

I only suggest the InstaWallet listing the last 3 transactions for simplicity. It can easily be any number of recent transactions and perhaps this can be as simple as giving the operator the option to click and select the number of recent transactions to be displayed.

If you wanted, you could even do the same and list the most recent payments sent. Recent payments received and sent can be set up as a scrolling feature if you wanted.

To generate revenue you could charge a flat transaction fee like they do for debit cards. Something like the BTC equivalent of 25 cents per transaction.

I like this idea because it makes it easy for small retail establishments to set up and it makes it easy for the employee to quickly process the transaction. The only hiccup is forcing the employee to manually make the conversion for each transaction. Perhaps there is a way to automate this too.

Ideas anyone? I think starting with just displaying the last three transactions and showing the current exchange rate would make this easy enough for many business owners to set up and begin using right away. I came up with this idea because I tried to visualize how I would help my favorite restaurant to begin accepting bitcoin.

Thanks,
Trader Steve

If you want to do this, I suggest that all of the players who want to join the Green address should set up a central service, to check the balance of everyone owns to others, which will minimum the risk and promote the trustworthy.

Great idea. Instawallet continues to impress.

Great idea! Very simple. Actually I was thinking recently about Tradehill's instant person to person BTC transfers. I was thinking it might be a nice idea for somebody like Meze Grill to open a Tradehill account that their customers can use to pay into, if they like. If both parties trust Tradehill, which seems reasonable, it would provide a means to have instant BTC payments. And then Meze Grill could always withdraw their bitcoins regularly to their own wallet - even instantly after every payment if they want.

But this is good too. Hope the idea takes off and more sites and clients implement it.