Bitcoin Forum

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 .

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

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 (http://firstbits.com/?a=1CDysW). 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.

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

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

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.

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.

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

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.

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

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.

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

Very nice!

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.

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

Is this service already in production? I would certainly like to support it on btcbuy.info (http://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

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

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!

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?



Are you familiar with firstbits (http://firstbits.com/?a=1CDysW)? 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.


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.



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

+1

Any thoughts on this?

I've patched my UI so that it shows the list of input addresses in the transaction details in "-debug" mode. Could be useful, it should eventually move out of debug mode but that'd need a user friendly way to present it.

It's anonymous until someone looks at instawallet's logs. In the blockchain your BTC would not be known unless you deposited then took out a really unique amount. If the person can't see their logs then they can't know who's BTC are yours if you took out with a green address.

I think you're confusing a couple of different things. The network enforces (I think?) 120 confirmations for generated coins, because in the event of a network split, coins generated and then spent during the split are the most problematic. For regular transactions, the client enforces a wait of 6 confirmations, but that is merely a client rule.

Great idea! Very simple. Actually I was thinking recently about Tradehill's instant person to person BTC transfers (http://forum.bitcoin.org/index.php?topic=31119.0). 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.

Great idea. Instawallet continues to impress.

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.

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

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.

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.

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

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.

You should make the green address look green: 1GreenkXsfH7usrBZBZUGnv6dZ9TtvsBhs :)

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.

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

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://bitcointalk.org/index.php?topic=28565.msg362094#msg362094 . But that's still a little into the future, I would guess.

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.

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

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.

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

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. 

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

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.

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.

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.

Yeah, or an X for eXtended info. Has X been used on some project 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.

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?

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.

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.

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

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.

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

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.


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

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.

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

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/

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.


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

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.

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.

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.

This is a great idea.

It would be nice to have a public, pgp-signed list of trusted addresses.  Each site that has a green address should at least host their own with some sort of protection from tampering.

EDIT: And ripple sounds awesome! I have been doing this with my roommates with a spreadsheet, but ripple is way cooler.

I see a few implementations now of web services offering a green address option for sending bitcoins. But are there currently any that have stated they will accept them? Clearly, the easy step is for web services to offer a green address, because it doesn't involve any risk. The harder step is convincing services to accept green addresses, because that involves a certain amount of trust.

Instawallet will directly accept transactions from green addresses at some point. I am currently reworking the backend to make this easier for me to achieve and also be able to manage the risk (e.g. put a limit on the amount of unconfirmed funds that can be pending at any moment).

How will this list of green addresses be populated?

For now I will just decide on a case by case basis. I think the Bitcoin community is still small enough that there aren't that many players and those that are interested to get on the list should just get in touch with me.

jav, is your PM not working ? :)

I think it is (?). The last PM I received from you is from November 26 and I thought I had replied to it. Although I can't find it in my outbox right now - I'll send it again.

Now I got your answer, thanks.
Hope you will support my proposal.

Is there a reason instawallet doesn't accept its own green address? It'd be mice if I didn't have to wait 6 confirms if the coins were sent with the green address.

That is a good question.

The reason is that receiving from green addresses in general is not implemented yet, so it's also not available for this specific address. I want to do this properly, be able to manage the risk and limit the damage if a green address that I accept is compromised for some reason. Unfortunately I currently don't have time to work on it much, as other obligations keep me busy.

What are you trying to do though? If you send to another Instawallet without forcing it through the green address the system will be able to do an internal transfer and it will clear instantly.

He might be wondering the same thing that I was: whether NOT using the green address could possibly reveal the original sending Instawallet address.

When sending between Instawallets? No, it does not reveal the address in any way. It doesn't hit the blockchain at all, so it isn't visible from the outside. It's just changing the balance in the database for the affected Instawallets.

I sometimes see people doing stuff like this: "Outside -> Instawallet A -> Instawallet B -> Instawallet C -> Outside". I guess they want to launder these coins, or something. There is really not much point in moving funds around inside Instawallet like that. The coins that are finally send out from Instawallet C aren't more mixed or something than what you would have gotten from Instawallet A.

Hi,
what do you think about this comment (https://github.com/bitcoin/bitcoin/pull/769#issuecomment-3805631)?

Ciao!

Good question.
In the bitcoin development mail list, in the aliases thread, there was a considerable criticism against firstbits. I claimed that firstbits was still valuable for systems such as green addresses where the length of the url is a constraint because of QR codes and luke claimed that "green addresses are also broken by design".
I would like to see, Jav, discussion about this between you and luke-jr. Because I strongly disagree with him on this point.

Seems like a good suggestion.

I'm sure there are better/more efficient ways to achieve the green address goals if you manage to get some required changes into the Satoshi client. I didn't really look at this option too much, because my impression is that the whole green address thing is somewhat controversial and a number of people are not convinced that it is even needed, so it seemed to me that it would probably not be accepted by the dev team.

That's why I looked at solutions that would work with the current code base. Maybe some would consider this as "broken by design", I like to think of it as "pragmatic".

But I currently don't have the time anyway to continue working on this, as some "RL stuff" has gotten in the way. So sure, if some superior solution makes it into the code base then I'm all for it.

I've already told you about the potential of this combined with ripple-like bitcoin transactions or just combined with Ripple.


What a pity. I think green addresses is a great idea.

The key problem with "green addresses" is that it encourages service providers to spam the blockchain with moves of funds to a single address. Since these same services cannot have users send directly to the "green address", the need for an extra transaction/input to move funds to one is almost always needed.

On the other hand, it's possible to simply add an extra signature to transactions, signed by the "green address", which gets relayed with it. Service providers can check for this signature. Miners can (but don't currently) omit this signature from blocks, so it doesn't cause permanent bloat.

Thanks for explaining this.  I was just about to ask what bloat there was.


How simple is simple?

And why is the system built so miners can change things like signatures? Couldn't that be bad?

Luke-Jr, thank you for your answer.

I'm very interested in this subject (instant transfer and zero-confirmation transactions).

Could you explain in simple words your technique, in a similar way to this one (https://bitcointalk.org/index.php?topic=48170.msg574495#msg574495), please?

Thanks!

Miners can change signatures, but obviously if they break the rules, their block will still be invalid. An extra signature that isn't needed to verify the transaction can therefore safely be stripped.

Actually no bloating is needed to use green addresses. That was just a bad implementation.

This is a brilliant idea and I hope it's implemented in the code. :D

Quick update: I summarized the ideas discussed here in a paper and also did some more implementation work. See: https://bitcointalk.org/index.php?topic=102517.0