これらのことは、ある時点以降は listreceivedbyaddress であっても避けられず安全でないという重要なポイントだと思う。そこで、現在のメインライン Bitcoin でのウェブサイトの動作と listtransactions を比較することが有益だと思う。これを承認ポイントと呼ぼう。あなたの質問に答えると……
サトシ・ナカモトの投稿（2010年12月8日 13:36 UTC）
- 過去のトランザクションが無効になり消えたことをどうやって知るのか？
bitcoinmarket や mtgox などのサイトは、6 承認を「承認ポイント」、つまりトランザクションが「安全」と見なせる瞬間としている。過去のトランザクションが無効になり消えた場合、ウェブサイトは潜在的な損失を避けられない。ユーザーはすでに PayPal-USD や LR-USD や Pecunix GAU を受け取って消えているからだ。
ウェブストアや実店舗でも同じだ。顧客が商品を受け取る承認ポイントがある。その後に TX が無効になった場合、店舗は避けられない損失を被る。顧客はすでに購入した商品を持って去っているからだ。
サトシ・ナカモトの投稿（2010年12月8日 13:36 UTC）
- ブロックチェーンの再編成が起きた場合、再承認されたときにトランザクションを二重にカウントしやすい。
txid 0x1234 の承認数が、大量のブロック再編成のために 0 から 10 に、また 0 にと激しく変動していると仮定しよう。
listreceivedbyaddress であれ listtransactions であれ、トランザクションが「店舗承認済み」の信頼レベルを超える瞬間という二値の承認ポイントがある。その承認ポイントで顧客は購入した商品を持って去り、それ以降のブロックチェーンや TX の動作に関係なく店舗は損失を被る。
プログラマーがミスをして、承認数が常に増加すると仮定する可能性があることは同意する。しかし、そのヒューマンエラーも listreceivedbyaddress で使用した場合に危険をもたらす。
サトシ・ナカモトの投稿（2010年12月8日 13:36 UTC）
- トランザクションが異なるtxidの二重支払いに置き換えられることがある。両方の支出をカウントしてしまう。
この点については、txid が変わるため、listtransactions がここで追加的な危険をもたらすことに同意する。ただし、新しい二重支払いが JSON-RPC ユーザーが探している宛先 Bitcoin アドレスと一致する場合に限る。
それでもこの場合も、ユーザーのセキュリティは完全に信頼レベルに依存する：TX が 6 承認前に置き換えられた場合、ソフトウェアはおそらく何も気づかない。TX が 6 承認後に置き換えられた場合、顧客はすでに購入した商品を持って去っており、Bitcoin ユーザーは損失を被る。
これは単に Bitcoin 自体に固有のものだ。ブロックチェーンの再編成は 50 ブロック後に起こるかもしれない。しかし、ウェブサイトはユーザーに商品を受け取る前に 50 ブロック待たせたくない。これはよく知られた自動販売機問題だ。listtransactions は listreceivedbyaddress ですでに脆弱なもの以上にこの問題に何も追加しない。
取引は二値の「承認ポイント」の後に置き換えられる可能性がある。Bitcoin のすべてのユーザーは、クレジットカードのチャージバックリスクや万引きリスクと同様に、これをビジネスプランに織り込む必要がある。