JSON-RPCメソッドのアイデア:指定されたtxidより新しいトランザクションをリストする
この方法でlisttransactionsを使うのは安全ではない。
listtransactionsに消極的だったことで批判されてきたのは知っている。その消極的な理由を説明させてほしい。
トランザクションは動的だ。過去のトランザクションが未承認になったり、消えて戻ってきたり、無効になって消えたり、別の二重支払いに置き換えられたりする可能性がある。日付が変わったり、順序が変わったりすることもある。
プログラマーは自然にlisttransactionsをこう使いたがる:前回聞いた時以降の新しいトランザクションを教えてくれれば、自分で集計や静的な記録を保持する。これは通常の使用ではすべてうまく動作するように見えるが、金額を何かに使用する場合、非常に悪用可能だ:
- 過去のトランザクションが無効になって消えたことをどうやって知るのか?
- ブロックチェーンの再編成があった場合、トランザクションが再度承認された時に二重カウントするのは容易だ。
- トランザクションは異なるtxidの二重支払いに置き換えられる可能性がある。両方の支払いをカウントしてしまうだろう。
以前のトランザクションは既に見たから新しいトランザクションだけ見ればよいというモデルは正しくない。古いトランザクションはいつでも変わり得る。
受け取った支払い金額に基づいてアクションを起こす時は、常にbitcoinに戻って現在の残高合計を問い合わせる(またはmoveやsendfromを使用する)必要があり、残高が減る可能性に備えなければならない。
正しい方法で行うことを容易にするアカウント機能ができた今、listtransactionsを持つ準備がより整った。
所定のminconfレベルでの通常のリスクの話をしているのではなく、この方法で使用した場合のlisttransactionsの追加的な落とし穴について話している。
Quote from: satoshi on December 08, 2010, 10:36:45 PM2) ブロックチェーンの再編成があった場合、トランザクションが再度承認された時に二重カウントするのは容易です。
OPのlisttransactions
ある明らかな方法で使うために特注されたように見える関数があり、その方法が目立たない罠であるというのは正しくないように思う。
Quote from: jgarzik on December 08, 2010, 11:07:22 PMQuote from: satoshi on December 08, 2010, 10:36:45 PM3) トランザクションは異なるtxidの二重支払いに置き換えられる可能性があります。両方の支払いをカウントしてしまうでしょう。 listtransactionsはこの問題に何も追加しません。listreceivedbyaddressを通じてすでに脆弱なもの以上のものではありません。 両方の支払いが同じアドレス宛てだとする。getreceivedbyaddressは常にどの時点でも一方か他方の支払いだけをカウントし、両方をカウントすることは決してない。
listtransactionsを使うと、両方をカウントするのは非常に容易だ。最初の支払いを見て、カウントする。2番目の支払いを見て、カウントする。合計は二重カウントだ。
Quote from: jgarzik on December 09, 2010, 12:58:05 AM「
Gavin、listtransactionsにすべてのアカウントのトランザクションをリストするオプションを付けられるか?
インターフェースがどうあるべきかわからない。もしかすると:
listtransactions
ただしコマンドラインからは難しいだろう。
インターフェースの良い解決策が思いつかないのが問題だ。""のような特殊ケースとして""かもしれない。ユーザーがアカウント名""を作成できないようにする必要があるだろう。
Quote from: jgarzik on December 09, 2010, 04:13:50 PMもちろん、それはトランザクションで追跡するのは十分簡単です。 トランザクションで「簡単に」追跡できるというのがどういうことかわからない。