Is gox's "non-modifiable transaction id" a good idea?

[jl2012]

Please keep this a technical discussion.

Gox proposes to use the hash of the signed string as a non-modifiable transaction id. Is it a good or bad idea?

I think for standard SIGHASH_ALL transactions this should work.

[mightycount]

Please keep this a technical discussion.

Gox proposes to use the hash of the signed string as a non-modifiable transaction id. Is it a good or bad idea?

I think for standard SIGHASH_ALL transactions this should work.

I believe over-engineering a working protocol is never a good idea. MtGox problem is far simpler and they would never have any issues if they broadcasted transactions to the network.

[flower1024]

i dont like the idea to do a hardfork just for one company when there is a working solution publicly available (for years btw).
they should just fix their custom client to work the same was as the reference client.

[jl2012]

i dont like the idea to do a hardfork just for one company when there is a working solution publicly available (for years btw).
they should just fix their custom client to work the same was as the reference client.

No, you don't get it. There is no hardfork, not even a softfork. The just propose an alternative way to identify a transaction

[flower1024]

i dont like the idea to do a hardfork just for one company when there is a working solution publicly available (for years btw).
they should just fix their custom client to work the same was as the reference client.

No, you don't get it. There is no hardfork, not even a softfork. The just propose an alternative way to identify a transaction

then this means that mtgox just can implement it in there custom client and continue? why would they even need bitcoin foundation for that?

anyway: i still think they should just do the same as the reference client.

[jl2012]

i dont like the idea to do a hardfork just for one company when there is a working solution publicly available (for years btw).
they should just fix their custom client to work the same was as the reference client.

No, you don't get it. There is no hardfork, not even a softfork. The just propose an alternative way to identify a transaction

then this means that mtgox just can implement it in there custom client and continue? why would they even need bitcoin foundation for that?

anyway: i still think they should just do the same as the reference client.

Because if the proposal is not widely adopted, their customer won't understand the new tx id format.

[TierNolan]

No, you don't get it. There is no hardfork, not even a softfork. The just propose an alternative way to identify a transaction

They basically want a new RPC call then? 

If so, since they already (apparently) have custom code, they can just do it themselves.

[flower1024]

i dont like the idea to do a hardfork just for one company when there is a working solution publicly available (for years btw).
they should just fix their custom client to work the same was as the reference client.

No, you don't get it. There is no hardfork, not even a softfork. The just propose an alternative way to identify a transaction

then this means that mtgox just can implement it in there custom client and continue? why would they even need bitcoin foundation for that?

anyway: i still think they should just do the same as the reference client.

Because if the proposal is not widely adopted, their customer won't understand the new tx id format.

what do you mean by "understanding"?
it is enough if the reference client credits my balance.

[jl2012]

i dont like the idea to do a hardfork just for one company when there is a working solution publicly available (for years btw).
they should just fix their custom client to work the same was as the reference client.

No, you don't get it. There is no hardfork, not even a softfork. The just propose an alternative way to identify a transaction

then this means that mtgox just can implement it in there custom client and continue? why would they even need bitcoin foundation for that?

anyway: i still think they should just do the same as the reference client.

Because if the proposal is not widely adopted, their customer won't understand the new tx id format.

what do you mean by "understanding"?
it is enough if the reference client credits my balance.

Yes, you are right. But I think they want to provide the hash to the client, as a prove of delivery. (but actually, this could not be a proof...)

[flower1024]

Yes, you are right. But I think they want to provide the hash to the client, as a prove of delivery. (but actually, this could not be a proof...)

i think you misunderstood the problem.
the problem is that mtgox sent a in an old tx format which prevents miners to include it in a block. someone "fixed" it for them and rebroadcastet (and this made a new txid). mtgox did not recognize that the tx has gone through and (maybe, hopefully not) refunded it to its customers balance.

the problem you are referring to is that some of their tx just did not go through. this is just a followup: as they did not recognize the original transaction has gone through they tried to reuse the ouputs in a new tx.

EDIT: the only necessary proof is that mtgox has signed the transaction.

[TierNolan]

Because if the proposal is not widely adopted, their customer won't understand the new tx id format.

Fair enough.  They should submit a BIP for a 2nd TX-ID scheme and then get the block explorers to support it.

[gmaxwell]

Please keep this a technical discussion.
Gox proposes to use the hash of the signed string as a non-modifiable transaction id. Is it a good or bad idea?
I think for standard SIGHASH_ALL transactions this should work.

I'm a little concerned that some people might think using it makes reissued transactions safe— like apparently MtGOX does!— when it doesn't, you must double-spend for mutual exclusion safety.

But other than that, it sounded potentially useful to me.  Code at: https://github.com/sipa/bitcoin/commits/normtxid

I worry that if we don't use the Bitcoin transaction mechanisms for masking (as that patch does) it'll never get all the malleability right, but if we do people will have a hard time reimplementing in objective brainfuck correctly.

Probably beyond comment on that approach we need another implementation in not-C++ and do a test on the testnet and bitcoin blockchains and see that the implementations agree on all txn, then again with random fuzzing.

[jl2012]

everytime i send btc to my customer, i also send email notification of the txid. so now this practice should be avoided because huge chance that txid can be altered? and should we store the txid into our database? if not, how we determine each transaction from our end?

what should we do as merchant/developer to anticipate this malleability issue?

Merchants need a way to record transactions immediately. They can't just wait for several confirmations and search the blockchain for a txid. I think gox's proposal should be adopted.

[Elo]

Merchants need a way to record transactions immediately. They can't just wait for several confirmations and search the blockchain for a txid. I think gox's proposal should be adopted.

Such merchants are using Bitcoin for something it was not designed to do.

Bitcoin transactions take an hour to confirm, on average.

If you want fast confirmations, you need to build a fast confirmation system on top of Bitcoin. This will likely use semi-trusted third parties that reconcile balances with one another, and can be publicly audited through the blockchain.

[Amitabh S]

Gox is doing it wrong. They and everyone need to use inputs to identify a tx.

Obviously the signatures won't authenticate any other signatures. So someone with the private key of inputs can always create another tx (using a new signature) with exactly same inputs/outputs.. there is no way to prevent this.. especially in distributed protocols like coinjoin. So the tx will always be malleable until confirmed.

[jl2012]

Gox is doing it wrong. They and everyone need to use inputs to identify a tx.

Obviously the signatures won't authenticate any other signatures. So someone with the private key of inputs can always create another tx (using a new signature) with exactly same inputs/outputs.. there is no way to prevent this.. especially in distributed protocols like coinjoin. So the tx will always be malleable until confirmed.

This is called double-spend attack, not malleability. To distinguish these 2:

• Double-spend attack could only be launched by private key holder
• Malleability (attack) could be done by anyone (there is a malleability attack bot running now)

[Jan]

Gox is doing it wrong. They and everyone need to use inputs to identify a tx.

Obviously the signatures won't authenticate any other signatures. So someone with the private key of inputs can always create another tx (using a new signature) with exactly same inputs/outputs.. there is no way to prevent this.. especially in distributed protocols like coinjoin. So the tx will always be malleable until confirmed.

This is called double-spend attack, not malleability. To distinguish these 2:

• Double-spend attack could only be launched by private key holder
• Malleability (attack) could be done by anyone (there is a malleability attack bot running now)

Correct. The malleability 'attack' is intensifying. I am trying to track it daily in this thread: https://bitcointalk.org/index.php?topic=459678.msg5072427#msg5072427
I think that it is important that we fix this. It affects all wallets that allow spending of unconfirmed transactions-sent-to-self, including bitcoin-qt.