原始文献 / 论坛帖 / Re: JSON-RPC method idea: list transactions newer than a given txid
Re: JSON-RPC method idea: list transactions newer than a given txid
Bitcointalk · 2010-12-08 20:21:49 UTC
用 listtransactions 这么干是不安全的。
我知道有人批评我不情愿加 listtransactions。让我解释一下我的顾虑。
交易是动态的。过去的交易可能变成未确认、消失又回来、变无效消失，或者被一笔不同的双重支付替换。它们的日期会变，顺序会变。
程序员天然倾向于这样用 listtransactions：把我上次问过之后的新交易喂给我，我自己记账或存静态记录。这在一切正常使用中都好像管用，但只要你拿金额做点什么，它就高度可利用：
1）过去的交易变无效消失了，你怎么知道？
2）区块链重组时，交易被重新确认，很容易重复计数。
3）一笔交易可以被一笔 txid 不同的双重支付替换。你会把两笔都数进去。
“因为以前的交易都见过了，所以只需要看新交易”这个模型是错的。旧交易随时可能变。
任何时候你根据收到的付款金额采取行动，都必须回头问比特币要一个当前余额总数（或用 move、sendfrom），并做好它可能变少的准备。
现在有了 Accounts 功能，做对的事更容易了，我们也更有条件提供 listtransactions。
英文原文
It's not safe to use listtransactions this way.
I know I've been criticized for being reluctant about listtransactions. Let me explain my reluctance.
Transactions are dynamic. Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend. Their date can change, their order can change.
Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them. This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
The model where you assume you only need to see new transactions because you've already seen previous transactions is not true. Old transactions can change at any time.
Any time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.
Now that we have the Accounts feature making it easier to do it the right way, we're better prepared to have listtransactions.