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

Jan

legendary

Activity: 1043

Merit: 1002

Quote from: jl2012 on February 11, 2014, 08:26:43 AM

Quote from: Amitabh S on February 11, 2014, 08:03:05 AM

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://bitcointalksearch.org/topic/m.5072427
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.

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: Amitabh S on February 11, 2014, 08:03:05 AM

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)

Amitabh S

legendary

Activity: 1001

Merit: 1005

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.

Elo

newbie

Activity: 14

Merit: 0

Quote from: jl2012 on February 10, 2014, 11:37:49 PM

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.

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: buffett on February 10, 2014, 11:26:41 PM

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.

gmaxwell

staff

Activity: 4284

Merit: 8808

Quote from: jl2012 on February 10, 2014, 01:05:21 PM

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.

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: jl2012 on February 10, 2014, 01:24:24 PM

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.

flower1024

legendary

Activity: 1428

Merit: 1000

Quote from: jl2012 on February 10, 2014, 01:32:46 PM

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.

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: flower1024 on February 10, 2014, 01:26:04 PM

Quote from: jl2012 on February 10, 2014, 01:24:24 PM

Quote from: flower1024 on February 10, 2014, 01:18:03 PM

Quote from: jl2012 on February 10, 2014, 01:15:29 PM

Quote from: flower1024 on February 10, 2014, 01:12:39 PM

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

legendary

Activity: 1428

Merit: 1000

Quote from: jl2012 on February 10, 2014, 01:24:24 PM

Quote from: flower1024 on February 10, 2014, 01:18:03 PM

Quote from: jl2012 on February 10, 2014, 01:15:29 PM

Quote from: flower1024 on February 10, 2014, 01:12:39 PM

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.

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: jl2012 on February 10, 2014, 01:15:29 PM

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.

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: flower1024 on February 10, 2014, 01:18:03 PM

Quote from: jl2012 on February 10, 2014, 01:15:29 PM

Quote from: flower1024 on February 10, 2014, 01:12:39 PM

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.

flower1024

legendary

Activity: 1428

Merit: 1000

Quote from: jl2012 on February 10, 2014, 01:15:29 PM

Quote from: flower1024 on February 10, 2014, 01:12:39 PM

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

legendary

Activity: 1792

Merit: 1111

Quote from: flower1024 on February 10, 2014, 01:12:39 PM

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

legendary

Activity: 1428

Merit: 1000

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.

mightycount

member

Activity: 101

Merit: 10

Quote from: jl2012 on February 10, 2014, 01:05:21 PM

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.

jl2012

legendary

Activity: 1792

Merit: 1111

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.

Topic: Is gox's "non-modifiable transaction id" a good idea? (Read 1002 times)