Currently, if a non-zero lock time is given, the system drops the 16 most significant bits and continues until a valid signature is obtained. However, Tom expresses hesitancy in adding more fields to this process as it can significantly increase decompression time. He mentions that the ideal use case for transaction compression is small high-security transactions, which typically do not require a lock time. Tom suggests considering dropping the grinding of the lock time in favor of grinding the block height instead. This would involve both parties agreeing on a single block height for the transaction, potentially saving several bytes. Tom mentions that he is currently working on adding an ideal transaction specification to the document.Overall, Tom's email raises concerns about the efficiency of the current approach in handling lock time in transactions and proposes an alternative solution that could potentially save space.