But what I'd picked up in my reading (perhaps wrongly but please feel free to correct me) was that the bitcoin protocol had been changed (I assume, after the Contracts.Providing a Deposit algorithm had been expounded) to effectively deprecate the use of nLockTime greater than zero in a transaction since such a transaction will be immediately marked as invalid and deleted from the transaction queue.
That's correct, transactions with lock time set in the future are considered non-standard and won't be relayed. This is to prevent possible DOS attacks where you could spam the network with such transactions.
I have an additional query about how Alice can know that ExpiryTx is otherwise valid apart from having not yet reached its nLockTime, i.e. that it has two valid signatures, without submitting it to the bitcoin network? And if the only way for Alice to check that ExpiryTx as two valid signatures is to submit it then does the bitcoin network give a nuanced report of the transaction's validity, e.g. indicating that the signatures are valid even if the nLockTime is invalid
You can check that the transaction is valid yourself:
- you can decode it to see if all parameters are ok - all outputs are pointing where they should be, and the nLockTime is properly set
- you can pick signatures from inputs and check them yourself using the same algorithms that Bitcoin software uses
That said, I have a feeling that we misunderstood ourselves regarding the use of some terminology. When I'm referring to "transaction malleability", I'm not talking about ability for the author of the transaction to submit a new version of it based on lock time parameter. I'm talking about someone else (let's call her Eve) being able to tweak certain tx parameters in a way that the signature is still valid, but the TXID is different. This can happen without Eve knowing Bob or Alice - she can set up a node that will catch transactions as they propagate in the network and re-submit them with tweaked parameters. She won't gain anything by doing this, but she can mess up with software and protocols that expect that TXID's don't change, effectively pulling of a DOS attack on those.