MtGox: Green address option

[MagicalTux]

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.

[1713443756]

1713443756

[1713443756]

1713443756

[Coinabul]

https://bitcointalk.org/index.php?topic=32818.0

Thats the link Mark to the instawallet thread.

[Shuai]

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)

[dancupid]

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)

It doesn't change the transaction time - it just means the receiver can trust the transaction at zero confirmations.
If all the exchanges used this, it would mean that the prices should stop lagging the mt.gox price.

[joepie91]

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)

It doesn't change the transaction time - it just means the receiver can trust the transaction at zero confirmations.
If all the exchanges used this, it would mean that the prices should stop lagging the mt.gox price.

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.

[MagicalTux]

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)

It doesn't change the transaction time - it just means the receiver can trust the transaction at zero confirmations.
If all the exchanges used this, it would mean that the prices should stop lagging the mt.gox price.

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.

Actually, no. We produce both transactions instantly, and send the second one without waiting for confirmations.

[joepie91]

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)

It doesn't change the transaction time - it just means the receiver can trust the transaction at zero confirmations.
If all the exchanges used this, it would mean that the prices should stop lagging the mt.gox price.

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.

Actually, no. We produce both transactions instantly, and send the second one without waiting for confirmations.

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.

[jav]

Awesome! :-)

[dvide]

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.

[dancupid]

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.

B cannot send to C with zero confirmations from A, so it only works if B already has a store of bitcoins. C won't know about A, so it will just be 6 confirmations as normal (though becasue C trusts mt.gox with everything C owns,  C can just accept B at zero)

[MagicalTux]

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.

[Maged]

B cannot send to C with zero confirmations from A, so it only works if B already has a store of bitcoins.

Nope, B doesn't need a store of Bitcoins. It is perfectly valid for the transaction A -> B to be in the same block as the transaction B -> C. That being said, the transaction B -> C is guaranteed to have extremely low priority, and will require an extra fee if you want it to be in the same block as transaction A -> B. However, since C trusts B, it is perfectly safe for B not to include a fee and for C wait a few days for the transaction to confirm.

[dancupid]

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?

[dvide]

B cannot send to C with zero confirmations from A, so it only works if B already has a store of bitcoins.

Nope, B doesn't need a store of Bitcoins. It is perfectly valid for the transaction A -> B to be in the same block as the transaction B -> C. That being said, the transaction B -> C is guaranteed to have extremely low priority, and will require an extra fee if you want it to be in the same block as transaction A -> B. However, since C trusts B, it is perfectly safe for B not to include a fee and for C wait a few days for the transaction to confirm.

Interesting. Though this of course means that C would have to wait a few days too before they are able to spend those bitcoins themselves? So even though they can be confident that it will eventually confirm, allowing instant point of sale transactions, they should be aware that they might not be able to spend those bitcoins for a while?

[mndrix]

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.

[Maged]

B cannot send to C with zero confirmations from A, so it only works if B already has a store of bitcoins.

Nope, B doesn't need a store of Bitcoins. It is perfectly valid for the transaction A -> B to be in the same block as the transaction B -> C. That being said, the transaction B -> C is guaranteed to have extremely low priority, and will require an extra fee if you want it to be in the same block as transaction A -> B. However, since C trusts B, it is perfectly safe for B not to include a fee and for C wait a few days for the transaction to confirm.

Interesting. Though this of course means that C would have to wait a few days too before they are able to spend those bitcoins themselves? So even though they can be confident that it will eventually confirm, allowing instant point of sale transactions, they should be aware that they might not be able to spend those bitcoins for a while?

Nope, they can spend it instantly, too. However, whoever receives the transaction would have to completely trust the sender AND the owner of the green address (in this case, MtGox). If C wants to send the coins to someone who doesn't trust them, though, they would, of course, have to wait until B -> C is confirmed. (or more accurately, C could still send the coins, but D wouldn't consider the coins received until both B -> C and C -> D were confirmed with enough confirmations)

Remember, the blockchain doesn't say who currently owns a coin. It just says what the network agrees can be trusted, even if you don't trust the person who sent you the coins at all. This is an important point to remember, since it is likely that in the future person-to-person transactions won't reach the blockchain until someone finally spends the coins at a merchant and the merchant pays a high enough fee to have the entire unconfirmed history locked in.

[MagicalTux]

Remember, the blockchain doesn't say who currently owns a coin. It just says what the network agrees can be trusted, even if you don't trust the person who sent you the coins at all. This is an important point to remember, since it is likely that in the future person-to-person transactions won't reach the blockchain until someone finally spends the coins at a merchant and the merchant pays a high enough fee to have the entire unconfirmed history locked in.

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.

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

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

[Maged]

Remember, the blockchain doesn't say who currently owns a coin. It just says what the network agrees can be trusted, even if you don't trust the person who sent you the coins at all. This is an important point to remember, since it is likely that in the future person-to-person transactions won't reach the blockchain until someone finally spends the coins at a merchant and the merchant pays a high enough fee to have the entire unconfirmed history locked in.

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.

I know, hence the "future" part. And it's not my idea, it's something that Mike has been pushing for for a long time. It's such a natural evolution, though, that I feel that it's inevitable that it'll happen.

[dvide]

B cannot send to C with zero confirmations from A, so it only works if B already has a store of bitcoins.

Nope, B doesn't need a store of Bitcoins. It is perfectly valid for the transaction A -> B to be in the same block as the transaction B -> C. That being said, the transaction B -> C is guaranteed to have extremely low priority, and will require an extra fee if you want it to be in the same block as transaction A -> B. However, since C trusts B, it is perfectly safe for B not to include a fee and for C wait a few days for the transaction to confirm.

Interesting. Though this of course means that C would have to wait a few days too before they are able to spend those bitcoins themselves? So even though they can be confident that it will eventually confirm, allowing instant point of sale transactions, they should be aware that they might not be able to spend those bitcoins for a while?

Nope, they can spend it instantly, too. However, whoever receives the transaction would have to completely trust the sender AND the owner of the green address (in this case, MtGox). If C wants to send the coins to someone who doesn't trust them, though, they would, of course, have to wait until B -> C is confirmed. (or more accurately, C could still send the coins, but D wouldn't consider the coins received until both B -> C and C -> D were confirmed with enough confirmations)

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.

[Maged]

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.

That's exactly it. It's a careful balance between making things more convenient for your customers and waiting longer to get paid. However, as credit cards show, businesses have long decided that customer convenience is FAR more important than how long it takes for them to get paid. (credit cards can take between days and weeks before the money is actually in the businesses bank account)