Bitcoin Forum
December 11, 2016, 12:00:29 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 »  All
  Print  
Author Topic: MtGox: Green address option  (Read 19651 times)
MagicalTux
VIP
Hero Member
*
Offline Offline

Activity: 617


Working on new MtGox features


View Profile WWW
October 14, 2011, 12:31:47 PM
 #1

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.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Coinabul
Hero Member
*****
Offline Offline

Activity: 588


Coinabul - Gold Unbarred


View Profile WWW
October 14, 2011, 12:40:16 PM
 #2

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

Thats the link Mark to the instawallet thread.

Coinabul.com - Gold Unbarred
Website owners, let me put my ads on your site! PM me!
Shuai
Full Member
***
Offline Offline

Activity: 189


View Profile
October 14, 2011, 01:16:53 PM
 #3

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
Hero Member
*****
Offline Offline

Activity: 954



View Profile
October 14, 2011, 01:21:16 PM
 #4

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
Sr. Member
****
Offline Offline

Activity: 294


View Profile
October 14, 2011, 02:06:11 PM
 #5

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.

Like my post(s)? 12TSXLa5Tu6ag4PNYCwKKSiZsaSCpAjzpu Smiley
Quote from: hawks5999
I just can't wait for fall/winter. My furnace never generated money for me before. I'll keep mining until my furnace is more profitable.
MagicalTux
VIP
Hero Member
*
Offline Offline

Activity: 617


Working on new MtGox features


View Profile WWW
October 14, 2011, 02:16:49 PM
 #6

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
Sr. Member
****
Offline Offline

Activity: 294


View Profile
October 14, 2011, 02:18:43 PM
 #7

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.

Like my post(s)? 12TSXLa5Tu6ag4PNYCwKKSiZsaSCpAjzpu Smiley
Quote from: hawks5999
I just can't wait for fall/winter. My furnace never generated money for me before. I'll keep mining until my furnace is more profitable.
jav
Sr. Member
****
Offline Offline

Activity: 249


View Profile
October 14, 2011, 02:32:23 PM
 #8

Awesome! :-)

Hive, a beautiful wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit. Tweets @hivewallet. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn.
dvide
Jr. Member
*
Offline Offline

Activity: 59



View Profile
October 14, 2011, 02:45:26 PM
 #9

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
Hero Member
*****
Offline Offline

Activity: 954



View Profile
October 14, 2011, 02:57:47 PM
 #10

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
VIP
Hero Member
*
Offline Offline

Activity: 617


Working on new MtGox features


View Profile WWW
October 14, 2011, 03:08:34 PM
 #11

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
Legendary
*
Offline Offline

Activity: 1260


View Profile
October 14, 2011, 03:14:46 PM
 #12

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
Hero Member
*****
Offline Offline

Activity: 954



View Profile
October 14, 2011, 03:15:32 PM
 #13

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
Jr. Member
*
Offline Offline

Activity: 59



View Profile
October 14, 2011, 03:20:51 PM
 #14

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
Michael Hendricks
VIP
Sr. Member
*
Offline Offline

Activity: 447


View Profile
October 14, 2011, 03:33:19 PM
 #15

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
Legendary
*
Offline Offline

Activity: 1260


View Profile
October 14, 2011, 03:48:55 PM
 #16

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
VIP
Hero Member
*
Offline Offline

Activity: 617


Working on new MtGox features


View Profile WWW
October 14, 2011, 03:53:04 PM
 #17

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
Legendary
*
Offline Offline

Activity: 1260


View Profile
October 14, 2011, 03:57:42 PM
 #18

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
Jr. Member
*
Offline Offline

Activity: 59



View Profile
October 14, 2011, 04:10:55 PM
 #19

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
Legendary
*
Offline Offline

Activity: 1260


View Profile
October 14, 2011, 04:20:25 PM
 #20

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)

Pages: [1] 2 3 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!