SN-3759 已核对来源，附原文与上下文。
我说的不是某个 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.
