所定のminconfレベルでの通常のリスクの話をしているのではなく、この方法で使用した場合のlisttransactionsの追加的な落とし穴について話している。
サトシ・ナカモトの投稿（2010年12月8日22:36 UTC）
- ブロックチェーンの再編成が起きた場合、再承認されたときにトランザクションを二重にカウントしやすい。
OPのlisttransactions <account> [count=10] [txid]の例は、プログラマーが前回のlisttransactions呼び出しの最後のtxidを渡せば同じトランザクションを二度と見ることはないと非常に簡単に仮定してしまうことを暗示しており、それは事実ではない。既に受け入れたtxidを追跡するための独自の永続マップや辞書を維持しなければ、支払いを二重カウントするのは非常に容易だ。
ある明らかな方法で使うために特注されたように見える関数があり、その方法が目立たない罠であるというのは正しくないように思う。
ジェフ・ガージックの投稿（2010年12月8日23:07 UTC）サトシ・ナカモト
- トランザクションが異なるtxidの二重支払いに置き換えられることがある。両方の支出をカウントしてしまう。
listtransactionsは、listreceivedbyaddressを通じて既に脆弱な範囲を超えて、この問題に何も加えない。
両方の支払いが同じアドレス宛てだとする。getreceivedbyaddressは常にどの時点でも一方か他方の支払いだけをカウントし、両方をカウントすることは決してない。
listtransactionsを使うと、両方をカウントするのは非常に容易だ。最初の支払いを見て、カウントする。2番目の支払いを見て、カウントする。合計は二重カウントだ。