We have not done a thorough analysis or inventory, but there were a number of transactions (not many--definitely less than 200 in the entire blockchain) that were duplicates under the new rules yet valid under the old rules. That is to say, they had exactly the same operations and expiration time but different signatures as you said. Almost all of such transactions were quite old; there was at least one extremely recent one but it was very small and did not look like an attack. It is difficult to say whether anything else appeared as an attack without doing a full review of the offending transactions. It is not a priority, but I can take a closer look if you think that is important.
If so, does the new code allow for such possibilities in the future (using some nonce or something) or does the new client somehow construct the transactions to not ever be identical?
In practice, nothing really changes for the end-user because subsequent identical transactions they construct will likely have different expiration dates. I do not know how those previously mentioned transactions with identical operations and expiration dates were created. There is also an additional reserved field in transactions that is currently not used, but could include a nonce if this ever becomes a problem in the future.
Thank you for your responses.
I guess whether I am worried about it or not depends on how the expiration time is calculated. Can the expiration time be left unset in the transactions? Did the client at any point in time in BitShares history leave the expiration time blank? Does the client by default use some fixed offset after the time the transaction is constructed as the expiration time? Is the granularity of the expiration time 10 seconds or less?
If the old client didn't set an expiration time, then it is totally understandable why there could be multiple duplicates (in the sense that they are the same operation) that are each legitimate. But if the client always sets an expiration time and uses a fixed offset from the current time as the expiration time, I find the probability of creating a transaction with the same operations and same expiration time to be incredibly unlikely. I can understand it is not a priority since there doesn't seem to be anyone in the community claiming they had any funds stolen or unauthorized withdrawals, but it is incredibly peculiar that there were duplicates (assuming the expiration time is always set to a fixed offset of the current time) and it would be interesting to investigate further.
However, the 3 of us that put together the upgrade all still managed to completely overlook this problem due to the stress of trying to fix the malleability security issue as fast as possible. The moral of the story is--security issue or not--we need a better process for live upgrades:
Right, that is understandable. It was a good learning experience at least, and fortunately there was no permanent damage or loss of funds. Hopefully this experience will help improve the procedures to follow for testing and quality assurance of upgrades. I'm excited for DevShares.