|
Title: Is gox's "non-modifiable transaction id" a good idea? Post by: jl2012 on February 10, 2014, 06: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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: mightycount on February 10, 2014, 06:08:35 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: flower1024 on February 10, 2014, 06: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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: jl2012 on February 10, 2014, 06:15:29 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 Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: flower1024 on February 10, 2014, 06:18:03 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: jl2012 on February 10, 2014, 06:24:24 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: TierNolan on February 10, 2014, 06:25:41 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: flower1024 on February 10, 2014, 06:26:04 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: jl2012 on February 10, 2014, 06:32:46 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...) Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: flower1024 on February 10, 2014, 06:36:47 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: TierNolan on February 10, 2014, 06:38:20 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: gmaxwell on February 10, 2014, 09:31:16 PM Please keep this a technical discussion. 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.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. 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: jl2012 on February 11, 2014, 04:37:49 AM 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: Elo on February 11, 2014, 11:56:20 AM 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: Amitabh S on February 11, 2014, 01:03:05 PM 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. Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: jl2012 on February 11, 2014, 01:26:43 PM 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:
Title: Re: Is gox's "non-modifiable transaction id" a good idea? Post by: Jan on February 11, 2014, 02:26:59 PM 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:
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. |