The problem I see with this approach is that it doesn't seem to scale too well. Let's say you accept green transactions from 20 different providers and you receive a new transaction. Now you have to check all those 20 websites, since you don't know from which one the transaction comes.

A second disadvantage I see, is that it adds a bit of latency. After receiving the transaction, you will have to fetch that website (or websites), which will also usually include an SSL handshake (keep-alive could be used in some way, I guess). Not such a big problem, but still a disadvantage compared to green addresses.

Awesome! :-)

I haven't yet talked with them regarding this sort of thing, as I first want to develop a more flexible back end that could actually handle these things. But I would definitely like to see some progress in that direction. I think it would be great, if one could do something like Instawallet mobile app -> Bit-Pay -> TradeHill all in a matter of seconds.

I'm not opposed to doing this outside the p2p network, if some kind of standard could be agreed on, but for the moment I will probably focus on doing all of these with green transactions. Bitcoin transactions are still pretty cheap so I'm currently not too worried to pay for one or two extra transaction hops. And everyone already speaks Bitcoin and the communication channel is clear.

And I would imagine it to be easier to get parties on board, as even an unconfirmed transaction is worth more than just some IOU delivered via a web service. The latter can easily be screwed up by some bugs in the code, whereas the former requires to actually perform a double spend attack before it becomes a problem. So I would feel much more comfortable accepting some other e-wallets green transactions, then just their promises that they will pay later. I would think, that parties like MtGox and TradeHill feel the same way.

As transactions get more expensive, one could then switch to another, cheaper mechanism and only settle from time to time in the blockchain to save on fees. This is where I could see Bitcoin going to in the long term anyway, as a backbone system to a ripple-style web of trust or maybe something open-transaction-like as well.

As a side note: I think green transactions can be used as a poor man's Ripple system as well for the moment. If a merchant accepts Instawallet's green address, and someone convinces me to accept their green address, then they can route their payment through Instawallet to have it be accepted by the merchant.

Instawallet just moved to a new server! Response times should be much better now. :-)

I think I see what's going on. In your code you use setRequestProperty which - as far as I can tell - is used to set an extra HTTP header. But for a HTTP POST call you need to send the arguments in the body of the request. It should look something like this:


Here is some example code, which puts together a POST call: http://www.exampledepot.com/egs/java.net/Post.html . That example code also uses URLEncoder.encode() to encode the arguments, although since this will always only be Bitcoin addresses and numbers I guess it isn't really necessary.

There is no specific check for the content type, no. Hard to tell what's going on.  I just tested the Python client again and here the payment command works. If you like, you can post the relevant part of your Java source code here (probably also interesting to other people developing against the API) or send me a PM with it and I can see if I can figure out what's going on.

It might also be interesting to have a look at the actual request being sent. So I would either use something like Wireshark to have a look at what is send to the server or alternatively run a dummy server (easy on Linux with for example netcat - just do "netcat -l -p 8080 -vv" and it will listen on port 8080 for TCP connections) and then have your code connect to that (set the URL to "http://127.0.0.1:8080/") and see what netcat displays.

What tool or programming language are you using to access the API? Sounds like the "address" parameter is somehow not transmitted or maybe none of the parameters. It needs to be an HTTP POST call - so depending on how you go about this, you might have to switch your tool or library into HTTP POST mode. The sample client shows how to do that in Python: https://github.com/javgh/iw-console/blob/master/iw-console.py .

Slow, I'm afraid. My new job keeps me pretty busy.


Cool to hear Instawallet being used in this way! Unfortunately I can't lift the rate limits for you as there aren't any rate limits. Just a smallish server with too much load. But I am planning on switching to a new server fairly soon, so that should hopefully help!


I don't go out of my way to _not_ log users, which means that typical settings are in effect on the server - for example the webserver records a log file which could be used to associate IP addresses with Instawallet URLs.
Cookies aren't used anymore (in the beginning they were used to store the last visited Instawallet, but I have since changed that). So the site doesn't track any specific sessions - the URL is the only identifier needed and it's available as part of every request.
URLs are generated randomly and have no special connection to the Bitcoin address. The link between them is stored in a database, like you said.


I do think Instawallet can be a useful tool to increase anonymity. If you make two payments from your private wallet, it might be possible to link them using the block chain. If you do the same with Instawallet, it can always be argued that the second payment was some other Instawallet user (as to the outside, Instawallet just looks like one large wallet).

Of course if someone has access to Instawallets logs - like I mentioned above - they can get the IP address that initiated the payment. Using Tor could be an option here, to hide your real IP from that.

I'm aware of that. Conversely the world is full of over-engineered specs. I think it's sometimes better to just take a stand on something, even if there is a risk of being wrong - but that's just my opinion.

And I think in this case it's even less of an issue, because if we really start running out of characters - proving my assumption wrong - we could still switch midway and pick one of the 'last remaining' characters to be the general prefix for all following extensions.

That said, I was lately thinking that it might be best to select a character that isn't in Bitcoin's Base58. Since that limits the selection somewhat, I might then indeed go with the more general approach.


I agree - I was just pointing out that one would definitely need a version parameter or a "what type of extension is it" parameter among these. So the system can decide whether it is able to interpret the remaining parameters correctly.


Currently Instawallet's normal transactions explicitly don't use coins from the green address (to not deplete it). So I would either have to adjust that or make sure that enough 'non-green' funds are available.

That's a good point! I have thought about it a little bit, but I think it doesn't make much of a difference either way. I see two options: You just have one general prefix (G or X or whatever) and then you need some kind of version or type parameter so the system can figure out whether it understands this particular extension. Or you treat the prefix character as the version/type information and whenever the system doesn't recognize a particular character it can conclude that it doesn't understand this particular extension. It seems to me that we won't be running out of possible prefix characters just yet, so both approaches look to me about the same in terms of "kludginess".


Interesting idea! :-) You would probably have to monitor though, whether you get enough funds this way and maybe turn it of if it's too much and add extra transfers if it's not enough. Given that transactions are still really cheap, I don't think I would go to the trouble of that. Neat trick though. =)

@jtimon: He is talking about regular Instawallet transactions, where currently the change is going back to a new, random Bitcoin address (standard Bitcoin behaviour) and which instead could be used to replenish the green address.

This is pretty cool! You guys are churning out products at an amazing rate - impressive! :-)

Do many of your merchants choose to get paid in USD? I have lately been thinking, that - while Bitcoin is still young and the exchange rate is volatile - it might be a good idea to not only protect the merchant from exchange rate volatility, but also the customer. So a customer would keep USD on their phone and only exchange those to Bitcoins at the last minute.

Of course this first seems a little paradoxical, to go from USD to Bitcoin back to USD. But one could think of Bitcoin as the common interface here, allowing variable partners on both sides.

A disadvantage is, that it would introduce the fees for an additional exchange step. On the other hand, the customer would have to exchange from USD to Bitcoin at some point anyway, so as long as the fee is on a percentage basis, it doesn't really make a difference whether they do it once in advance or always "just-in-time" for smaller amounts. And it might be possible to still be cheaper than credit cards even with all that factored in.

Obviously the exchanges are in the best position to offer this feature. If they have a mobile app, it should not be too difficult to offer a special payment screen, where the right amount of Bitcoins are bought on the market and then immediately transferred.

With a solution like this, customers would more or less have the impression of simply paying USD with their phone and as far as they are concerned, Bitcoin is just some technology that makes it happen in the background.

DavinciJ15, if you have some money to throw at the protection of the Namecoin network, you could place a bet on one of the Bitcoin betting sites that the attack will be _successful_. Then you invite people to bet against you and encourage them to tilt the chances in their favor by contributing hashing power. Additional plus for you: if the attack succeeds anyway, you get to keep your bounty.

I don't know what is a reliable betting site these days, but I have seen one existing bet here already: http://betsofbitco.in/item?id=101 .

I thought as much. :-) Just to make that clear: I didn't want to imply that you were suggestion such an attack. I understand you were just discussing the theoretical technical side of it and I just quoted you for some context. I was mostly talking to others in this thread, who seem to entertain such an idea.

It would also be an asshole move. Of course young projects can easily be trampled to death by cyber bullies. That proofs nothing at all about the technical side of SolidCoin. Even if one day a clearly superior alternative to Bitcoin emerges (and I don't believe SolidCoin to be that), then this SuperiorCoin will most likely go through the same vulnerable phase and it would be a disservice to the progress of crypto-currencies to take advantage of this vulnerability and kill it off early.

If you think, like me, that SolidCoin does not bring enough advantages over Bitcoin to be a serious competitor, then just let them alone and run their course. I don't see it cause much harm. It even provides a nice field test for some of the alternative approaches, like the new difficulty adjustment algorithm. If this turns out to be a worthwhile change, it could be even adopted for Bitcoin in the future, starting from some checkpoint block number, and we would already have a better understanding how that would play out.

Are you just stating this as a general problem or are you suggesting that SolidCoin solves/helps with this problem? SolidCoin has 3 minutes between blocks, right? I don't see how that makes much of a difference. The thing is, you still need to take variance into account. Sure, on average you have a block every 3 minutes. But that means that for a 95 % chance of finding a block, you need to wait about 9 minutes (math here: http://www.wolframalpha.com/input/?i=-log%281-0.95%29%2F%281%2F3minutes%29 ). Which in turn means, that in 5 % of the cases you actually have to wait even longer than 9 minutes. So what have we really gained?

Sure, there might be situations where "wait for a little while" (SolidCoin) is acceptable, whereas "wait for quite some time" (Bitcoin) would not be. But I can't think of that many situations to see this as much of an advantage.

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.

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. 

Really interesting idea! I was thinking that this might be a good technique to combine with a payment processor. Customers would then only have to form a single one of these "business relationship sessions" - namely with the payment processor - and could still pay instantaneously everywhere where the payment processor is accepted. Merchants would accept standard, zero-confirmation transactions from the payment processor on the assumption, that the payment processor is honest.

If the changes to Bitcoin necessary for this would be made, I would probably try to adopt something like this for Instawallet. Combined with the green address technique, that seems to me like a pretty workable solution for instant payments to any number of merchants without the customer having to risk depositing coins in an e-wallet.

There is now a point of sale implementation based on this approach. See this thread: https://bitcointalk.org/index.php?topic=38893.msg475829#msg475829 .