Following the thread from Instawallet about green address, we have decided to give it a try on MtGox.

When withdrawing on MtGox, you can check the option "Use green address" to cause your coins to be sent through the address 1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q (or pass the option green=1 to the withdraw.php API).

We have however used a slightly different implementation than Instawallet here, ensuring there is never any coin remaining on this address, reducing the interest for "bad people" to guess its private key.

Each time a transaction is sent via our "green address", a first transaction is generated to send a random amount of bitcoins (larger than the total amount of coins withdrawn) to the address, then a second transaction is generated to get the coins "out". Transactions are always sent by pair and are broadcasted together.

This, however, causes transactions sent via the "green address" option to normal targets to take longer, as two transactions needs to be confirmed. Bitcoin services recognizing our green address will, however, be able to process those deposits in real time instead of waiting for confirmations.


We are thinking of rotating the MtGox green address once in a while, with new green address announced ~1 month in advance.


Any comment on this is welcome.

whats the point of the green address if its not 100% instant?

I dont think reducing transaction time from 60 minutes to 20 minutes or whatever is gonna be much of a difference (also why things like solidcoin isnt a good solution)

The problem is, I believe, that to forward a transaction that *arrives* at the green address, it has to wait for 2 confirmations before it is able to send it to the actual recipient.

Ah, never mind, I misread your mention of two transactions. I assumed it was about the storage->green transfer, rather than the storage->green plus green->target transactions for a system that does not recognize green addresses.

So if I'm understanding this correctly, it works like this:
A -> B -> C

A and B both belong to MtGox. B is the green address. C is the external recipient.

Since A -> B is an internal transaction only, you don't need to wait for confirmations at B because you know that you're not going to double spend it anyway. So this allows you to initiate the B -> C transaction right away. Likewise, if C trusts MtGox to not attempt a double spend, then C can also accept this transaction without waiting for confirmations (assuming they know the green address). So this means it gets from A to C instantly.

However, if C does not trust MtGox, or does not know about their green address, they will now have to wait for 12 confirmations before this transaction will show up as 'confirmed' in their Bitcoin client. Am I getting that right? Not sure how that bit works.

EDIT: Following the discussion below, the last bit was wrong, as I suspected. It's possible that both A -> B and B -> C can even be included in the same block! If that happens, then it would only take the usual 6 confirmations for C to show 'confirmed' in his client. So no change there.

However, this is not 100% reliable. This is because B -> C will likely have a lower priority for miners to include it into a block, due to there not being any confirmations yet for A -> B. So it's also entirely possible that it could take days for B -> C to get included into a block, in which case C would not see any confirmations for all of that time. So it's not that C would have to wait for 12 confirmations; that was completely wrong. It's that they won't necessarily begin to see any confirmations at all for maybe even a few days (though probably a lot less than that; the point is that it's not very well known at this point). They could end up seeing 0 confirmations for a while. However, if you trust MtGox and know their green address, you can be confident that it will eventually confirm. And it is also possible that in the future, miners could increase the priority of including those transactions that come from well established green addresses, which might eliminate this problem entirely. I'm not sure if this would have other ramifications though.

Obviously this means that if you're sending bitcoins to a merchant via MtGox, don't just use the green address every time. Only use it if the merchant says they are explicitly willing, because otherwise it might take a long time for the merchant to get confirmations on their side, and if so they're not going to release their goods to you for a while. And if you're going to be accepting bitcoins from the MtGox green address, be aware that you might not be able to purchase goods from others with those bitcoins for a while, for the same reason.

Actually if you look at : http://blockexplorer.com/address/1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q

Look at transactions 597d00408b... and 557c87f205....

597d00408b... is "A to B"
557c87f205... is "B to C"

Both happened in the same block, which is the expected behaviour.


Previous tests did not always end in the same block, so I believe some miners may consider the second transaction lower priority as it involves not yet confirmed coins. In the case of those two transactions it was as fast as a normal transaction, but it cannot be guaranteed in 100% of the cases.

If we look at the previous transactions we can see it was sometimes coming out with a difference of 1 block, or even more. If pools could put priority on green addresses it'd (mostly) solve this issue.

WOW! -I've learnt something new. How do I get the bitcoin client to let me do that?

Given a transaction hash, how can one use the Bitcoin API to ascertain the source address for a transaction?  `gettransaction $hash` in v0.4.0 doesn't provide the information.  I know BlockExplorer shows the input addresses, but sites accepting Bitcoin payment probably want to use their local bitcoind.

Thanks.

I don't think the client currently considers a fee on a transaction as a reason to give higher priority to "parent" transactions. It does sound awesome however, and I like the idea.


We are using a custom client to do that, I do not think the bitcoin client would let you do that at this point.

Yeah, that's true. I wasn't saying that it wasn't possible specifically. Just that in practice you won't be able to buy things with those bitcoins for a while. Let's say C wants to use those bitcoins to buy a new suit from merchant D. The merchant isn't going to agree to give up the suit until the bitcoins have some confirmations at D's address, which as you have stated may take a few days because of the very low priority (though probably a lot less than a few days, given the tests MagicalTux has showed; and miners might be willing to increase the priority on including transactions coming from well established green addresses). So in practice, anybody who accepts bitcoins from the MtGox green address should be aware that they may have to wait a while longer than normal before they can use those bitcoins to purchase goods with.