Topic: Malleability - what is the official advice for developers with custom wallets? (Read 1218 times)

Would this alternative solution also work:

• Keep a separate known set of change addresses which are used for no other purpose.
• Do not credit change transactions until they have 1 confirm

?

Thanks for the advice

Is there a way to generate the hash without script-sig using bitcoind, or do I need to parse the hex?

Basically, I would recommend maintaining and tracking a "pre-signed" ID.  This is the hash of the tx without any script-sigs.  It is fairly straightforward to take a transaction and compute both IDs instantaneously.  Simply create a map/dictionary of PreSignID <--> TxID for all tx that you care about.  When new blocks come in, check the TxID as usual, but also compute the PreSignID and check whether you have a TxID associated with it.  If you do, treat that object as the original TxID (update your databases and the map).

Similarly, if you are querying directly whether a particular transaction is confirmed -- well you shouldn't have to do anything because you already updated the above map and DBs when you originally processed the tx.  For instance, if you were an exchange, above you would reassociate the new TxID with the customer account, and there would be no issue.

I am particularly fond of this because we it will help with multi-signature transactions, for parties to be able to reference particular unsigned/partially-signed transactions, while collecting signatures.  Though I'm pretty sure the payment protocol has some mechanism for this already... (does it?)

Also, if you are writing software that handles customer accounts, withdrawals etc.  You should have an explicit reissue/replace transaction function -- you would select the txID that you want to "reissue" and you would be sure to double-spend the original one, so that only one of them can be valid.  However, this has to be an explicit operation, since simply creating a new transaction with no context would, of course, not want to double-spend any unconfirmed tx.

Here was my proposal. https://bitcointalksearch.org/topic/recommended-fix-for-mt-goxs-withdrawal-problem-caused-by-transaction-malleabil-459000

Lol. Nice tongue in cheek match guys. Im thoroughly enjoying this 

https://bitcoinfoundation.org/

Bitcoin is not official. It is peer to peer. No masters, no rulers.

Hi guys,

I've been looking at the malleability problem in my own custom wallet which sits on top of bitcoind.

The only way I found to distinguish change transactions from deposits (a fundamental requirement) is to look at any inputs which get spent in the same transaction (by ID) as an unspent output is created.

Now, if malleability means that this transaction ID match is no longer reliable for mempool transactions, what I am supposed to use to distinguish change transactions?

Does this mean that mempool can no longer be used, full stop? Would be great to get some official advice on this.

Cheers, Paul.