JSON-RPCメソッドのアイデア：指定されたtxidより新しいトランザクションをリストする
特定のトランザクションIDより新しいトランザクションをリストするJSON-RPCメソッドがあれば非常に便利であろう。これにより、開発者は最新の既知のtxidを記録し、任意の頻度でそのメソッドをポーリングするだけで、新しいトランザクションを容易に監視できるようになる。
実現方法の一つとして、listtransactionsを拡張してオプションのtxid引数を受け付けるようにすることが考えられる： Code:
+1
自分はまだその部分に手を付けていないし、時間を見つけて鍵のインポート/エクスポートに取り組みたいが、それは自分のスクリプトのいくつかにとって非常に助かるものだ。
Quote from: davux on December 08, 2010, 05:07:21 PM
特定のトランザクションIDより新しいトランザクションをリストするJSON-RPCメソッドがあれば非常に便利であろう。これにより、開発者は最新の既知のtxidを記録し、任意の頻度でそのメソッドをポーリングするだけで、新しいトランザクションを容易に監視できるようになる。
実現方法の一つとして、listtransactionsを拡張してオプションのtxid引数を受け付けるようにすることが考えられる： Code:
新しい取引を監視するコードを追加するなら、ギャビンのmonitorパッチを含めるべきだ： https://github.com/gavinandresen/bitcoin-git/tree/monitorreceived
WalletTxはウォレットに順次追加されるのだから、古いtxidはウォレットの前の方に現れると仮定できるのではないか？
そうであれば、単に線形検索を行い、そのtxid以降のtxidを出力し続けるだけで済む。
誰かこれを確認できるだろうか？
この方法でlisttransactionsを使うのは安全ではない。
listtransactionsに消極的だったことで批判されてきたのは知っている。その消極的な理由を説明させてほしい。
トランザクションは動的だ。過去のトランザクションが未承認になったり、消えて戻ってきたり、無効になって消えたり、別の二重支払いに置き換えられたりする可能性がある。日付が変わったり、順序が変わったりすることもある。
プログラマーは自然にlisttransactionsをこう使いたがる：前回聞いた時以降の新しいトランザクションを教えてくれれば、自分で集計や静的な記録を保持する。これは通常の使用ではすべてうまく動作するように見えるが、金額を何かに使用する場合、非常に悪用可能だ：
- 過去のトランザクションが無効になって消えたことをどうやって知るのか？
- ブロックチェーンの再編成があった場合、トランザクションが再度承認された時に二重カウントするのは容易だ。
- トランザクションは異なるtxidの二重支払いに置き換えられる可能性がある。両方の支払いをカウントしてしまうだろう。
以前のトランザクションは既に見たから新しいトランザクションだけ見ればよいというモデルは正しくない。古いトランザクションはいつでも変わり得る。
受け取った支払い金額に基づいてアクションを起こす時は、常にbitcoinに戻って現在の残高合計を問い合わせる（またはmoveやsendfromを使用する）必要があり、残高が減る可能性に備えなければならない。
正しい方法で行うことを容易にするアカウント機能ができた今、listtransactionsを持つ準備がより整った。
Quote from: genjix on December 08, 2010, 08:20:57 PM
WalletTxはウォレットに順次追加されるのだから、古いtxidはウォレットの前の方に現れると仮定できるのではないか？
そうであれば、単に線形検索を行い、そのtxid以降のtxidを出力し続けるだけで済む。
誰かこれを確認できるだろうか？
ウォレットはkey/valueのdb4データベース（およびRAM内のkey/valueマップ）だ。
どちらのデータ構造も時間順に並んでいない。
davuxのリクエストの動機は理解できる。リリースしたeコマースプラグインの開発中に、ウォレットに対する「ダンプ」メソッドの使用が長期的に実現可能かどうか疑問に思った。時間が経つにつれ返されるデータは増える一方だからだ。
アカウントやアドレスにJSON-RPCコールバックURLを添付でき、そのアカウントやアドレスの承認やその他のステータス変更のたびに呼び出され、コールバックがクリアされるまで続くのが理想だ。これでウォレットのポーリングの必要が完全になくなる。
それについての「機能リクエスト」投稿をどこかに書いた。
ある時点で、取引を受け入れるウェブサイトや人は、このリスクを受け入れなければならない。listreceivedbyaddressを使おうとlisttransactionsを使おうと、これは避けられない。これがlisttransactionsへの消極的姿勢がとても奇妙に見える理由だ。
Bitcoinを受け入れるほぼすべての取引所やウェブサイトは、取引が承認され商品が発送されるか金銭が交換される二値の決定点に達する。その二値の決定点以降、ブロックチェーンが再編成されたり取引が消えたりしても、ウェブサイトにできることは損失を受け入れることだけだ。
ウェブサイトの観点からは、「listtransactions 6」と「listreceivedbyaddress 6」の間に実効的な違いはゼロだ。ウェブサイト運営者にとっての最終結果は同じだからだ：商品は発送済み/注文は承認済み/金銭は交換済み。
これらのことは、ある時点以降はlistreceivedbyaddressであっても避けられず安全でないという重要なポイントだと思う。
取引は承認ポイントの後に置き換えられる可能性がある。Bitcoinのすべてのユーザーは、クレジットカードのチャージバックリスクや万引きリスクと同様に、これをビジネスプランに織り込む必要がある。
Quote from: satoshi on December 08, 2010, 08:21:49 PM
この方法でlisttransactionsを使うのは安全ではない。
listtransactionsに消極的だったことで批判されてきたのは知っている。その消極的な理由を説明させてほしい。
トランザクションは動的だ。過去のトランザクションが未承認になったり、消えて戻ってきたり、無効になって消えたり、別の二重支払いに置き換えられたりする可能性がある。日付が変わったり、順序が変わったりすることもある。
プログラマーは自然にlisttransactionsをこう使いたがる：前回聞いた時以降の新しいトランザクションを教えてくれれば、自分で集計や静的な記録を保持する。これは通常の使用ではすべてうまく動作するように見えるが、金額を何かに使用する場合、非常に悪用可能だ：
- 過去のトランザクションが無効になって消えたことをどうやって知るのか？
- ブロックチェーンの再編成があった場合、トランザクションが再度承認された時に二重カウントするのは容易だ。
- トランザクションは異なるtxidの二重支払いに置き換えられる可能性がある。両方の支払いをカウントしてしまうだろう。
以前のトランザクションは既に見たから新しいトランザクションだけ見ればよいというモデルは正しくない。古いトランザクションはいつでも変わり得る。
受け取った支払い金額に基づいてアクションを起こす時は、常にbitcoinに戻って現在の残高合計を問い合わせる（またはmoveやsendfromを使用する）必要があり、残高が減る可能性に備えなければならない。
正しい方法で行うことを容易にするアカウント機能ができた今、listtransactionsを持つ準備がより整った。
つまりそれは開発者のアプリにおける設計上の問題であり、listtransactionsに固有の問題ではない。listtransactionsを不注意に使うと危険になりうるということだ。OK、しかし多くのプログラミングツールにもトラップがある。例えば、スレッドを使ったプログラミングは設計上のトラップだらけだ。だからといってそのツールを開発者に提供すべきではないということではなく、ドキュメントでそれらのトラップについて強く警告すべきだということだ。
私の主張：listtransactionsを利用可能にしつつ、APIとして正確にドキュメント化し、使用時に犯してはならない設計ミスを説明しよう。
所定のminconfレベルでの通常のリスクの話をしているのではなく、この方法で使用した場合のlisttransactionsの追加的な落とし穴について話している。
Quote from: satoshi on December 08, 2010, 10:36:45 PM
では、引用したメッセージで私が挙げた問題にどう対処しますか？
OPのlisttransactions
ある明らかな方法で使うために特注されたように見える関数があり、その方法が目立たない罠であるというのは正しくないように思う。
Quote from: jgarzik on December 08, 2010, 11:07:22 PM
これらのことは、ある時点以降はlistreceivedbyaddressであっても避けられず安全でないという重要なポイントだと思う。
取引は承認ポイントの後に置き換えられる可能性がある。Bitcoinのすべてのユーザーは、クレジットカードのチャージバックリスクや万引きリスクと同様に、これをビジネスプランに織り込む必要がある。 Quote from: satoshi on December 08, 2010, 10:36:45 PM では、引用したメッセージで私が挙げた問題にどう対処しますか？
両方の支払いが同じアドレス宛てだとする。getreceivedbyaddressは常にどの時点でも一方か他方の支払いだけをカウントし、両方をカウントすることは決してない。
listtransactionsを使うと、両方をカウントするのは非常に容易だ。最初の支払いを見て、カウントする。2番目の支払いを見て、カウントする。合計は二重カウントだ。
「
moveの「トランザクション」にはトランザクションIDがないが、アカウント残高には影響する（listtransactionsにも表示される）。
listtransactionsを呼び出して、返された最後のアイテムのtxidを保存しようとすると、コードがぐちゃぐちゃになる。「category」が「move」だった場合、txidは存在しない…
ポーリングの排除について：かなり近いうちに「monitorreceived」パッチをクリーンアップする予定だ。トランザクションが入ってきたりブロックが承認されたりした時にURLにPOSTする…しかし「accounts」から学んだ教訓に基づいて再設計するためにじっくり考える必要がある。非常にミニマルなAPIになるかもしれない。通知は「おい、txid <123ae4221…>がN回の確認に達したぞ、gettransactionとgetbalanceを呼んで最新情報を取得した方がいいかもしれない」というものだ。
Quote from: gavinandresen on December 09, 2010, 12:41:44 AM
「
より後に発生したトランザクションを一覧する」を持たないもう一つの理由を追加しよう： moveの「トランザクション」にはトランザクションIDがないが、アカウント残高には影響する（listtransactionsにも表示される）。
listtransactionsを呼び出して、返された最後のアイテムのtxidを保存しようとすると、コードがぐちゃぐちゃになる。「category」が「move」だった場合、txidは存在しない…
ポーリングの排除について：かなり近いうちに「monitorreceived」パッチをクリーンアップする予定だ。トランザクションが入ってきたりブロックが承認されたりした時にURLにPOSTする…しかし「accounts」から学んだ教訓に基づいて再設計するためにじっくり考える必要がある。非常にミニマルなAPIになるかもしれない。通知は「おい、txid <123ae4221…>がN回の確認に達したぞ、gettransactionとgetbalanceを呼んで最新情報を取得した方がいいかもしれない」というものだ。
あなたとサトシの「txid以降のtx」についての意見に同意する。自分のlisttransactions（現在はxlisttransactions）パッチは、意図的にその機能を持っておらず、これまでも持ったことがない。
Quote from: jgarzik on December 08, 2010, 11:07:22 PM
これらのことは、ある時点以降はlistreceivedbyaddressであっても避けられず安全でないという重要なポイントだと思う。
取引は承認ポイントの後に置き換えられる可能性がある。Bitcoinのすべてのユーザーは、クレジットカードのチャージバックリスクや万引きリスクと同様に、これをビジネスプランに織り込む必要がある。
それが常に当てはまるわけではない。顧客がウェブサイトに残高を持っている場合もある。ウェブサイトの運営者は、過去の取引が無効になり消えた場合、確実に知りたいだろう。
Quote from: ribuck on December 09, 2010, 11:48:56 AM
Quote from: jgarzik on December 08, 2010, 11:07:22 PM
これらのことは、ある時点以降はlistreceivedbyaddressであっても避けられず安全でないという重要なポイントだと思う。
取引は承認ポイントの後に置き換えられる可能性がある。Bitcoinのすべてのユーザーは、クレジットカードのチャージバックリスクや万引きリスクと同様に、これをビジネスプランに織り込む必要がある。
それが常に当てはまるわけではない。顧客がウェブサイトに残高を持っている場合もある。ウェブサイトの運営者は、過去の取引が無効になり消えた場合、確実に知りたいだろう。 Quote from: jgarzik on December 08, 2010, 11:07:22 PM これらのことは、ある時点以降はlistreceivedbyaddressであっても避けられず安全でないという重要なポイントだと思う。
取引は承認ポイントの後に置き換えられる可能性がある。Bitcoinのすべてのユーザーは、クレジットカードのチャージバックリスクや万引きリスクと同様に、これをビジネスプランに織り込む必要がある。
確かに、それは取引で十分簡単に追跡できる。
Quote from: jgarzik on December 09, 2010, 12:58:05 AM
Quote from: gavinandresen on December 09, 2010, 12:41:44 AM
「
以降に発生した取引をリストする」を持たないもう一つの理由を追加する： あなたとサトシの「txid以降のtx」についての意見に同意する。自分のlisttransactions（現在はxlisttransactions）パッチは、意図的にその機能を持っておらず、これまでも持ったことがない。
ユーザーに最近のN件のトランザクション履歴を表示するようなものに設計されている限り、問題ない。アカウント機能により正しい方法で支払い検出を行うことが容易になった今はなおさらだ。
Gavin、listtransactionsにすべてのアカウントのトランザクションをリストするオプションを付けられるか？
インターフェースがどうあるべきかわからない。もしかすると：
listtransactions
ただしコマンドラインからは難しいだろう。
インターフェースの良い解決策が思いつかないのが問題だ。""のような特殊ケースとして""かもしれない。ユーザーがアカウント名""を作成できないようにする必要があるだろう。
Quote from: jgarzik on December 09, 2010, 04:13:50 PM
Quote from: ribuck on December 09, 2010, 11:48:56 AM Quote from: jgarzik on December 08, 2010, 11:07:22 PM
過去の取引が無効になり消えた場合、ウェブサイトは潜在的な損失を避けられない。ユーザーはすでにPayPal-USDやLR-USDやPecunix GAUを受け取って消えているからだ。
それが常に当てはまるわけではない。顧客がウェブサイトに残高を持っている場合もある。ウェブサイトの運営者は、過去の取引が無効になり消えた場合、確実に知りたいだろう。
確かに、それは取引で十分簡単に追跡できる。
トランザクションで「簡単に」追跡できるというのがどういうことかわからない。