 |
February 13, 2014, 05:13:29 AM |
|
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.
|
