SN-3810 已核对来源，附原文与上下文。
不是 locktime。
Not locktime.
有一个面向遥远未来的可能设计：
There's a possible design for far in the future:
你有意写一笔双重支出。用同样的输入和输出再写一遍，但这次带上手续费。当你的双重支出进入区块时，第一笔支出就失效了。收款方其实不会察觉，因在新交易生效的那一刻，旧交易就失效了，新交易直接取而代之。
You intentionally write a double-spend. You write it with the same inputs and outputs, but this time with a fee. When your double-spend gets into a block, the first spend becomes invalid. The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.
说起来容易，实现起来难。要写出一个能正确构造双重支出的客户端、在钱包里管理两个版本直到其中之一被选中、处理好所有边角情况，工作量不小。现有代码里的每一个假设都是「你不会试图写双重支出」。
It's easier said than implemented. There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases. Every assumption in the existing code is that you're not trying to write double-spends.
比特币矿工侧也需要一些改动，让交易池有可能接受双重支出，但只严格限于输入输出匹配且手续费更高的情况。目前，双重支出从不被交易池接受，因此每个节点都在用它见到的第一笔交易进块来作证。
There would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher. Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.
