我说的不是某个 minconf 水平下的正常风险，我说的是这样使用 listtransactions 带来的额外陷阱。
I'm not talking about the normal risk for a given minconf level, I'm talking about additional pitfalls from listtransactions when used this way.
中本聪原话中本聪原帖 ↗2) 发生区块链重组时，交易重新确认后很容易被重复计数。
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
楼主的 listtransactions
The OP's example of listtransactions
一个函数看起来就是为某种显而易见的用法量身定做的，而那种用法却暗藏陷阱——这似乎不太妥当。
It doesn't seem right to have a function that seems tailor made to be used a certain obvious way, and that way is a non-obvious trap.
其他参与者原话jgarzik原帖 ↗在这个问题上，listtransactions 带来的风险并没有超出使用 listreceivedbyaddress 时已有的风险。
listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.
假设两笔支出都指向同一地址。getreceivedbyaddress 在任一时刻只会计入其中一笔支出，绝不会两笔都算。
Suppose both spends are to the same address. getreceivedbyaddress would always count only one or the other spend at any given time, never both.
用 listtransactions，两笔都算进去就太容易了。你看到第一笔支出，计入；看到第二笔支出，又计入。总额被重复计算。
Using listtransactions, it would be very easy to count both. You see the first spend, you count it. You see the second spend, you count it. Total is double counted.
当前版本尚未建立逐条校对状态记录。来源核验、历史审校与当前译文校对是不同事项。
译文内容版本：fcf22023761e。用于比对文本，不代表校对等级或更新时间。
请填写对应原文、现译文、建议译法和理由。复制后通过你联系本站作者的渠道提交；此处不会自动发送。
JSON-RPC method idea: list transactions newer than a given txid
