 |
February 14, 2014, 08: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.
|
