Bitcointalk · JSON-RPC method idea: list transactions newer than a given txid

中本聪,2010 年 12 月 9 日

SN-3759 已核对来源,附原文与上下文。

阅读语言
中文译文

我说的不是某个 minconf 水平下的正常风险,我说的是如此使用 listtransactions 带来的额外陷阱。

2) 发生区块链重组时,交易重新确认后很容易被重复计数。

楼主的 listtransactions [count=10] [txid] 示例似乎在暗示——而且程序员亦很容易假定——只要传入上一次调用 listtransactions 的最后一个 txid,就不会再看到同一笔交易,然而事实并非如此。倘若你不自己维护一个持久的映射或字典来记录哪些 txid 已然接受过,就很容易把支付重复计数。

一个函数看起来就是为某种显而易见的用法量身定做的,而那种用法却是个不显眼的陷阱——这总说不过去。

listtransactions 并没有给这个问题添加任何东西,超出了 listreceivedbyaddress 已然暴露的风险之外。

假设两笔支出都指向同一地址。getreceivedbyaddress 在任一时刻仅仅会计入其中一笔支出,绝不会两笔都算。

用 listtransactions,两笔都算进去就太容易了。你看到第一笔支出,计入;看到第二笔支出,又计入。总额被重复计算。

ORIGINAL · 英文原文
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) 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.

3) 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.
来源
Bitcointalk 原始链接 ↗ 记录编号 SN-3759