Topic: MtGox: Green address option - page 3. (Read 21627 times)
You're completely missing the point. The 'solution' 'solves' the 'problem' of cryptographic failure. If the cryptography fails in a cryptographic currency, it's game over.
(Because it removes the ability to consolidate multiple withdrawals into a single transaction.)
no it does not.A1, A2, A3 -> B -> C1, C2, C3
it only means one extra transaction.
Quote
The problem it solves does not actually exist. It's entirely imagined.
no, some people do not want to wait for transactions to comfirm, an want thier money secure fast.if i trust mtgox not to double spend, it can be you as a trusted party, i don't need to thrust my customers, only mtgox, and only for a short period of time.
the problem is not imagined.
why? its not sub-optimal... please explain. both transactions in the same block is completely valid. its actually a beautiful solution, to a rather complex problem. if you trust mtgox, and their green address, you can comfirm the tx without it being included in a block.
No, green addresses are great. Tux is concerned that someone will derive the private key from the public elliptic key, transaction messages, or some side-channel attack. In order to minimize the damage, he's transferring coins as input and output of the same address/block. However, if a private key can be derived, losing a few coins will be the least of our worries. The entire bitcoin network and several other systems will be destroyed.A condom to protect against meteors. Awkward, inadequate, unlikely.
why? its not sub-optimal...
It's sub-optimal because it at least doubles the number of transactions required. In many cases, it more than doubles them. (Because it removes the ability to consolidate multiple withdrawals into a single transaction.)Quote
please explain. both transactions in the same block is completely valid. its actually a beautiful solution, to a rather complex problem. if you trust mtgox, and their green address, you can comfirm the tx without it being included in a block.
The problem it solves does not actually exist. It's entirely imagined.I think the A->B->C transactions within a single block is an interesting thought and practical experiment, but it seems to be a sub-optimal solution to a non-extant problem.
why? its not sub-optimal... please explain. both transactions in the same block is completely valid. its actually a beautiful solution, to a rather complex problem. if you trust mtgox, and their green address, you can comfirm the tx without it being included in a block.
I think the A->B->C transactions within a single block is an interesting thought and practical experiment, but it seems to be a sub-optimal solution to a non-extant problem. It's a bit like wearing a condom to protect against a meteor impact; Awkward protection from a highly unlikely but otherwise catastrophic event.
...ensuring there is never any coin remaining on this address, reducing the interest for "bad people" to guess its private key... rotating the MtGox green address... ~1 month in advance.
Is a private key attack a realistic concern? If so, the implications for your business and our entire economy are devastating.Maybe we can interpret it as they use guessable passphrase to generate the private key, so they fear it will be guessed by someone else
...ensuring there is never any coin remaining on this address, reducing the interest for "bad people" to guess its private key... rotating the MtGox green address... ~1 month in advance.
Is a private key attack a realistic concern? If so, the implications for your business and our entire economy are devastating. 
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)
It should be noted that those "green" transactions are usually simple, they always contain only one input, and two outputs. They should be easy enough to integrate the blockchain without too much delay, and if we can get pools and/or big individual miners to mine those in priority, things would be even better.
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) 
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.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.
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.
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.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.
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.
Thanks.
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.
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.
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?
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.
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.
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.
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.
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)
Jump to: