Spread Stamp - Gox in percentage. If theres a fix for gox withdrawals, expect to see the candle to dive down real hard.
Topic: MtGox is implementing a fix for withdrawals. Price will go this way ^ (Read 2337 times)
February 14, 2014, 04:05:46 AM
Spread Stamp - Gox in percentage. If theres a fix for gox withdrawals, expect to see the candle to dive down real hard.
February 14, 2014, 04:02:28 AM
long goxBTC on leverage for a real gamble. Then your BTC will go ^^
either that or to 0
either that or to 0
February 14, 2014, 03:49:32 AM
MagicalTux:
...when customers are withdrawing bitcoins, litecoins, or any other coin based on Bitcoin we may support in the future.
...when customers are withdrawing bitcoins, litecoins, or any other coin based on Bitcoin we may support in the future.
Why the constant mentions of litecoin? They blew it. They'll be defunct before they ever get LTC implemented. If they were still relevant the trollbox would be going apesh*t right now.
Gonna go check just in case, I need some humor.
February 14, 2014, 03:26:12 AM
Obviously the price on mtgox will go this way ^ and the spread will reduce. Also some bots might bring the price up on other exchanges. However, ultimately I think the price on other exchanges should end up even lower since there will be more coins flooding the market as everyone withdraws from gox.
February 14, 2014, 03:24:32 AM
MagicalTux:
This is getting us nowhere. There is indeed so many things we could do on our own even at MtGox, however this merge request's purpose is to define a standard others using Bitcoin can agree to and that can be implemented.
Getting rid of malleability would be the ideal idea, but this won't happen anytime soon no matter how everyone tries. It can be made harder, but not impossible.
On the other hand, I believe keeping track of what is actually signed when a transaction is issued makes sense, and it seems that some others here agree to that.
Re-issuing of transactions should be done using the same inputs, but as of today this poses a problem as said txs won't be relayed as easily as clean txs. There is also the fact that people using regular bitcoind as backend won't be able to do that either.
Keeping only a service-specific ID stored in the transaction is not a solution either, as it would be difficult to index globally (ie. we have to find the right txs from the whole blockchain).
Anyway we came up with this new hash solution because:
it requires no change to the protocol and will not cause any forks or issue to people not using it
because bitcoind already has facilities to exclude the txin script from a tx to hash it, it is very easy to implement
because it's a hash of what is actually signed, anything causing this hash to change would also invalidate the signature
As for CoinJoin, I believe the client will have a view of the transaction before it is actually sent (to ensure it includes its outputs and to sign it). As such it is perfectly possible to fetch this hash at that stage, even before knowing the actual tx hash (and it could remove the need for the client to see the actual tx to know its hash as they potentially wouldn't need it anymore)
more MagicalTux:
Just to update this thread, it seems that this discussion is mostly stale now. We (at MtGox) will implement this new hash index in our transactions database and start working with it (we will announce a maintenance as we will have to stop bitcoin deposits too during the database schema update) and will start providing this new hash when customers are withdrawing bitcoins, litecoins, or any other coin based on Bitcoin we may support in the future.
We will also provide an API that will allow our customers to use this hash to retrieve the transaction hash as seen in the blockchain once the transaction is confirmed, and will hope others (blockchain.info?) will index this value one day.
We also invite other exchanges and businesses which may need to keep track of bitcoins they send to use this same method, since dealing with multiple variations of the same thing wouldn't be very productive.
If nobody does it, we will also post some test vectors for regular (in=>out) transactions in the near future.
a comment by gmaxwell:
Reissuing a transaction without reusing the inputs is unsafe. You cannot do this and be confident you will not be robbed, because there is nothing preventing both transactions from going through. No amount of checking can provide protection in that case, because the prior transaction may not have gone through yet but still may go through for as long as it has not been conflicted— or even after it has been, if the conflict can be removed in a reorg. It may be slow, it may not work super well, but it is the only way to prevent transactions from being paid twice. This has nothing to do with malleability: You simply cannot pay someone twice and not risk them actually getting paid twice, unless their original payment is impossible or the transactions are mutually exclusive.
If including this patch is going to make even one service believe they can safely reissue in this manner than we must not do it.
Pull requests here are not used to define standards, normally "standards"— in so far as we have them at all in the Bitcoin community— are defined using BIPs. The GitHub page was a quick way to get code up so that people could start commenting on it— and get it if they needed something to use internally to help sort things out.
It is not our responsibility to run your service, so if you're waiting on anything on this pull req you are doing something wrong. You already issue several kinds of mtgox proprietary ID with your transactions.
anything causing this hash to change would also invalidate the signature
This isn't true for all transactions, it's true for the conventional ones you issue— indeed. Some transaction types are inherently malleable and no ID can be both unique and non-malleable for them.
Keeping only a service-specific ID stored in the transaction is not a solution either, as it would be difficult to index globally
I am not a fan of putting an extra ID in transactions because it bloats them, it's bad for privacy, and can potentially be simulated in other transactions (unless you go through the heroic effort of making it a signature)... But there is no reason why it should be any more difficult to index than any other data from a transaction. Instead of running the normalized ID extraction, you run the service ID extraction, and index that if there is one.
This is getting us nowhere. There is indeed so many things we could do on our own even at MtGox, however this merge request's purpose is to define a standard others using Bitcoin can agree to and that can be implemented.
Getting rid of malleability would be the ideal idea, but this won't happen anytime soon no matter how everyone tries. It can be made harder, but not impossible.
On the other hand, I believe keeping track of what is actually signed when a transaction is issued makes sense, and it seems that some others here agree to that.
Re-issuing of transactions should be done using the same inputs, but as of today this poses a problem as said txs won't be relayed as easily as clean txs. There is also the fact that people using regular bitcoind as backend won't be able to do that either.
Keeping only a service-specific ID stored in the transaction is not a solution either, as it would be difficult to index globally (ie. we have to find the right txs from the whole blockchain).
Anyway we came up with this new hash solution because:
it requires no change to the protocol and will not cause any forks or issue to people not using it
because bitcoind already has facilities to exclude the txin script from a tx to hash it, it is very easy to implement
because it's a hash of what is actually signed, anything causing this hash to change would also invalidate the signature
As for CoinJoin, I believe the client will have a view of the transaction before it is actually sent (to ensure it includes its outputs and to sign it). As such it is perfectly possible to fetch this hash at that stage, even before knowing the actual tx hash (and it could remove the need for the client to see the actual tx to know its hash as they potentially wouldn't need it anymore)
more MagicalTux:
Just to update this thread, it seems that this discussion is mostly stale now. We (at MtGox) will implement this new hash index in our transactions database and start working with it (we will announce a maintenance as we will have to stop bitcoin deposits too during the database schema update) and will start providing this new hash when customers are withdrawing bitcoins, litecoins, or any other coin based on Bitcoin we may support in the future.
We will also provide an API that will allow our customers to use this hash to retrieve the transaction hash as seen in the blockchain once the transaction is confirmed, and will hope others (blockchain.info?) will index this value one day.
We also invite other exchanges and businesses which may need to keep track of bitcoins they send to use this same method, since dealing with multiple variations of the same thing wouldn't be very productive.
If nobody does it, we will also post some test vectors for regular (in=>out) transactions in the near future.
a comment by gmaxwell:
Reissuing a transaction without reusing the inputs is unsafe. You cannot do this and be confident you will not be robbed, because there is nothing preventing both transactions from going through. No amount of checking can provide protection in that case, because the prior transaction may not have gone through yet but still may go through for as long as it has not been conflicted— or even after it has been, if the conflict can be removed in a reorg. It may be slow, it may not work super well, but it is the only way to prevent transactions from being paid twice. This has nothing to do with malleability: You simply cannot pay someone twice and not risk them actually getting paid twice, unless their original payment is impossible or the transactions are mutually exclusive.
If including this patch is going to make even one service believe they can safely reissue in this manner than we must not do it.
Pull requests here are not used to define standards, normally "standards"— in so far as we have them at all in the Bitcoin community— are defined using BIPs. The GitHub page was a quick way to get code up so that people could start commenting on it— and get it if they needed something to use internally to help sort things out.
It is not our responsibility to run your service, so if you're waiting on anything on this pull req you are doing something wrong. You already issue several kinds of mtgox proprietary ID with your transactions.
anything causing this hash to change would also invalidate the signature
This isn't true for all transactions, it's true for the conventional ones you issue— indeed. Some transaction types are inherently malleable and no ID can be both unique and non-malleable for them.
Keeping only a service-specific ID stored in the transaction is not a solution either, as it would be difficult to index globally
I am not a fan of putting an extra ID in transactions because it bloats them, it's bad for privacy, and can potentially be simulated in other transactions (unless you go through the heroic effort of making it a signature)... But there is no reason why it should be any more difficult to index than any other data from a transaction. Instead of running the normalized ID extraction, you run the service ID extraction, and index that if there is one.
February 14, 2014, 03:16:18 AM
No doubt that MtGox is probably going to shut down due to future trust issues that users have with them, but it looks like they'll be allowing withdrawals very soon.
Source:
http://theblogchain.com/2014/02/14/breaking-mark-karpeles-posts-to-say-mtgox-is-implementing-a-solution/
So, buying now might be a fantastic idea. If you can stomach it (I can't), I hear MtGox has some cheap BTC
Source:
http://theblogchain.com/2014/02/14/breaking-mark-karpeles-posts-to-say-mtgox-is-implementing-a-solution/
So, buying now might be a fantastic idea. If you can stomach it (I can't), I hear MtGox has some cheap BTC
Jump to: