Instawallet introduces new approach to instant payment: Green address technique

[jav]

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. 

[1713860901]

1713860901

[1713860901]

1713860901

[1713860901]

1713860901

[jav]

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! :-)

[jtimon]

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

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.

[jav]

Why not compressing with firstbits the destination address too?

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.

[netrin]

Hi Jav, I certainly agree with your thinking that the protocol should pro-actively prevent accidentals and your solution would do that elegantly. I am concerned though that you are setting a kludge precedent. It's not like many systems accept the URI notation today anyway. The G-prefix is a good solution at this time, but I would urge you to continue the discussion of a simple, robust, extensible URI format. It would be a pity if every great new idea prefixed bespoke symbols in order to deliberately invalidate addresses.

EDIT: For example, It could be that the G-prefix should be interpreted to mean further protocol parameters required where 'ga' is one such parameter.

[helloworld]

EDIT: For example, It could be that the G-prefix should be interpreted to mean further protocol parameters required where 'ga' is one such parameter.

Yeah, or an X for eXtended info. Has X been used on some project yet?

[dooglus]

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.

How about if you were to direct the 'change' from all withdrawals to your green address.  So even if I do a regular withdrawal, the change gets returned to your green address.  That way you should get away without ever having to manually 'replenish' the green address.

[jtimon]

There's only a green address for each payment processor instead of one green address per user.
Why should you deposit in the green address (which the payment processor controls, not you) by default?

[jav]

EDIT: For example, It could be that the G-prefix should be interpreted to mean further protocol parameters required where 'ga' is one such parameter.

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

How about if you were to direct the 'change' from all withdrawals to your green address.  So even if I do a regular withdrawal, the change gets returned to your green address.  That way you should get away without ever having to manually 'replenish' the green address.

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.

[netrin]

EDIT: For example, It could be that the G-prefix should be interpreted to mean further protocol parameters required where 'ga' is one such parameter.

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

The entire history of hardware and software kludge was spawned from the utterance, "It seems to me that we won't be running out of..."

The "G" does not identify the address. It identifies what can be done with the address. At its simplest, it says "stop! do not send as legacy clients normally would. You must handle this differently or abort."

This might be followed by numerous parameters such as price, expiration of offer, ordernumber, productnumber, etc. Those same parameters might be used by other systems that do not require green address senders, but still require preemptive processing. A service might require that sent coins only come from previously registered addresses, or from political affiliation, or from non-anonymous addresses, or from an address that had not been used in a long time. There are many potential services with a functionally equivalent halt/bootstrap early in the transaction process.

I believe that at 30 or 58 characters, prefixes are already a scarce resource. Alternate Fadcoins (such as GeistGeld, a G prefix I presume) are popping up every week. With multiple bitcoin prefixes, we won't have a clue what any address is; we'll then need a parameter just to identify the currency. '1' has clearly been bitcoin. 'X' could be bitcoin with required extensions. But much beyond that and you will lose control of the prefix.

[dooglus]

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

What's "too much"?  What's the downside to having funds held by the 'green' address?

[jav]

The entire history of hardware and software kludge was spawned from the utterance, "It seems to me that we won't be running out of..."

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.

The "G" does not identify the address. It identifies what can be done with the address. At its simplest, it says "stop! do not send as legacy clients normally would. You must handle this differently or abort."

This might be followed by numerous parameters such as price, expiration of offer, ordernumber, productnumber, etc. Those same parameters might be used by other systems that do not require green address senders, but still require preemptive processing

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.

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

What's "too much"?  What's the downside to having funds held by the 'green' address?

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.

[netrin]

The "G" does not identify the address. It identifies what can be done with the address. At its simplest, it says "stop! do not send as legacy clients normally would. You must handle this differently or abort."

This might be followed by numerous parameters such as price, expiration of offer, ordernumber, productnumber, etc. Those same parameters might be used by other systems that do not require green address senders, but still require preemptive processing

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.

And I ping pong agree. Even with Green addresses, I think the vendor must realistically include parameters anyway, specifically which green (type or list of) addresses it will accept.

G23456789123456789?green=instawallet,mtgox&absolutelynot=mybitcoin.com

[netrin]

Jav, have you considered contacting MtGox, TradeHill, Bit-Pay and other well known exchange/merchant/wallets regarding faster transactions, perhaps with a signed balance sheet outside of the p2p network, but rebalanced in the normal bitcoin network? I could imagine certain legal contracts, auditing, and norms (balance never to exceed w BTC, balancing the accounts every x hours, no transactions greater y BTC, no more than z transactions per hour). For example, Instawallet and Tradehill could simply sign transaction+balance.

Code:

Tradehill (1jds7agyah) to Instawallet (183658354), 70 BTC, 20111007-124000, balance InstaWallet owes  11 to Tradehill since block 140000. Confirmation #TH-IW-123124
Instawallet (198765432) to Tradehill (1kldyasdfta), 10 BTC, 20111007-123500, balance InstaWallet owes  81 to Tradehill since block 140000.  Confirmation #TH-IW-123123
Instawallet (12345689) to Tradehill (1abcdefghijk), 5 BTC, 20111007-123456, balance InstaWallet owes  71 to Tradehill since block 140000. Confirmation #TH-IW-123122

Users could transfer a reasonable buffer of coins to a unique InstaWallet (or child allowance in a few years) then spend and confirm transactions instantly (I expect most merchants will use a proxy/ewallet in the near future). Rather than wait for confirmation at checkout, users receive confirmation while eating breakfast, shopping, or waiting in queue, then the merchant relies on trusted third parties rather than the block chain. It's similar to green addresses (recipients still need to trust the green address). The merchant only needs to trust their receiving party (InstaWallet, for example) who accepts the counter party risk of their partners (TradeHill, for example).

[jtimon]

Jav, have you considered contacting MtGox, TradeHill, Bit-Pay and other well known exchange/merchant/wallets regarding faster transactions, perhaps with a signed balance sheet outside of the p2p network, but rebalanced in the normal bitcoin network? I could imagine certain legal contracts, auditing, and norms (balance never to exceed w BTC, balancing the accounts every x hours, no transactions greater y BTC, no more than z transactions per hour). For example, Instawallet and Tradehill could simply sign transaction+balance.

I suggested that they could use ripple between them. They could make ripple IOUs "legal debts" through a contract.
Of course it would be better if there were a decentralized ripple implementation.

And for the future, I think it can be improved with Ripple...

[netrin]

jtimon, I added a note on the bottom of my previous post.

Yes, I think Ripple is precisely the model. However, Ripple seems (though I haven't looked at the system in detail) to be a bit like the problem global finance faces today with credit default swaps. Credit gets passed around until default 'ripples' around the network unpredictably. I'm proposing a much more flat system with immediate (hourly) rebalancing. How does ripple mitigate counter-counter-counter-party risk?

But it's true, if a <--(trusts)--> b <--(trusts)--> c <--(trusts)--> a, then rebalancing could be a bit more elegant. It could be that rebalancing ("margin calls") must occur for the previous x blocks after y confirmations. For example 140000-140100 must be balanced after the 140200'th block.

I'm just concerned about a <--(trusts)--> b <--(trusts)--> c |--(does not trust)--| a

[jtimon]

Yes, I think Ripple is precisely the model. However, Ripple seems (though I haven't looked at the system in detail) to be a bit like the problem global finance faces today with credit default swaps. Credit gets passed around until default 'ripples' around the network unpredictably.

Actually the current system is hierarchical and ripple would be more resiliant to "defaults". Now we have to trust the banks (they create the money), but with ripple we could trust our friends, neighbors and partners instead.
http://ripplepay.com/essay/

I'm proposing a much more flat system with immediate (hourly) rebalancing.

ewallets could clear their ripple balances every hour too. As frequently as they want (well, the limit is in bitcoin blocks). The advantage is that each ewallet company could trust a few others instead of all other companies out there and they can still be indirectly connected in the ripple graph.

How does ripple mitigate counter-counter-counter-party risk?

les say we have this trust graph:

A <-> B <-> C
A pays 10 to C, so now A owes 10 to B and B owes 10 to C
B buys something for 10 to A and their debt gets cleared
C wants to buy something from B but B rejects to make good on his debt.
C asks to be paid back in the currency that was the denomination of the IOUs, say bitcoins but B says no again.
C takes the losses. He shouldn't had to trust B in the first place.
If B was C supplier he won't be that anymore
If B was C friend he won't be that anymore

[jav]

Jav, have you considered contacting MtGox, TradeHill, Bit-Pay and other well known exchange/merchant/wallets regarding faster transactions, perhaps with a signed balance sheet outside of the p2p network, but rebalanced in the normal bitcoin network?

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.

[netrin]

Yes, I suppose that's true, an unconfirmed bitcoin transaction from a known address is functionally equivalent if not better than for example a PGP signed IOU.

[jtimon]

Green transactions with multiple hops is a great beginning. It allows you to pay to a merchant that doesn't trust your e-wallet provider directly. As you say, the e-wallet providers can use ripple later when multiple tx fees become a concern.