Re: JSON-RPC メソッドのアイデア:指定された txid より新しいトランザクションをリストする

所定の minconf レベルでの通常のリスクの話をしているのではなく、この方法で使用した場合の listtransactions の追加的な落とし穴について話している。

サトシ・ナカモトの投稿(2010年12月8日 13:36 UTC)
  1. ブロックチェーンの再編成が起きた場合、再承認されたときにトランザクションを二重にカウントしやすい。

OP の listtransactions [count=10] [txid]の例は、プログラマーが前回の listtransactions 呼び出しの最後の txid を渡せば同じトランザクションを二度と見ることはないと非常に簡単に仮定してしまうことを暗示しており、それは事実ではない。既に受け入れた txid を追跡するための独自の永続マップや辞書を維持しなければ、支払いを二重カウントするのは非常に容易だ。

ある明らかな方法で使うために特注されたように見える関数があり、その方法が目立たない罠であるというのは正しくないように思う。

ジェフ・ガージックの投稿(2010年12月8日 14:07 UTC)
サトシ・ナカモトの投稿(2010年12月8日 13:36 UTC)
  1. トランザクションは、異なるtxidを持つ二重支払いで置き換えられる可能性がある。両方の支払いをカウントしてしまう。

両方の支払いが同じアドレス宛てだとする。getreceivedbyaddress は常にどの時点でも一方か他方の支払いだけをカウントし、両方をカウントすることは決してない。

listtransactions を使うと、両方をカウントするのは非常に容易だ。最初の支払いを見て、カウントする。2番目の支払いを見て、カウントする。合計は二重カウントだ。