回复：JSON-RPC 方法构想：列出比给定 txid 更新的交易
原始发布页
打开来源页面查看 1 个交叉存档
我说的不是某个给定 minconf 级别下的正常风险，而是以这种方式使用 listtransactions 时带来的额外陷阱。
引用自：satoshi，2010 年 12 月 08 日 10:36:45 PM
- 当区块链发生重组时，交易再次得到确认后，很容易被重复计数。
楼主给出的 listtransactions <account> [count=10] [txid] 示例似乎暗示，而且程序员也很容易认为：如果把上一次调用 listtransactions 时最后一个 txid 传入，他们就绝不会多次看到同一笔交易，但事实并非如此。如果你不维护自己的持久映射或字典来跟踪已经接受了哪些 txid，就很容易重复计算付款。
一个函数看起来像是专门为某种显而易见的用法量身定制，而这种用法却是个不易察觉的陷阱，这似乎不太妥当。
引用自：jgarzik，2010 年 12 月 08 日 11:07:22 PM
引用自：satoshi，2010 年 12 月 08 日 10:36:45 PM
- 一笔交易可能被具有不同 txid 的双重支付所取代。你会把两笔支出都计算进去。
除了 listreceivedbyaddress 已经存在的漏洞之外，listtransactions 并没有给这个问题增加任何东西。
假设两笔支出都付到同一个地址。getreceivedbyaddress 在任何给定时刻都只会计算其中一笔支出，绝不会把两笔都计算进去。
使用 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.
Quote from: satoshi on December 08, 2010, 10:36:45 PM
- When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
The OP's example of listtransactions <account> [count=10] [txid] seems to imply and it would be very easy for programmers to assume that if they pass in the last txid of the previous call to listtransactions, they will never see the same transaction more than once, which is not the case. It would be very easy to double-count payments if you don't maintain your own persistent map or dictionary to track which txid's you've already accepted.
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.
Quote from: jgarzik on December 08, 2010, 11:07:22 PM
Quote from: satoshi on December 08, 2010, 10:36:45 PM
- A transaction can be replaced by a double-spend with a different txid. You would count both spends.
listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.
Suppose both spends are to the same address. getreceivedbyaddress would always count only one or the other spend at any given time, never both.
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.