[PATCH] 'xlisttransactions'の実装

SVN 117 に対する xlisttransactions RPC を実装するパッチはこちら：http://pastebin.ca/1910553 現時点では、オプションは無視され、見つけたすべてのトランザクションをダンプする。

Raw パッチ：http://pastebin.ca/raw/1910553

編集：パッチの現在のホームは http://yyz.us/bitcoin/patch.bitcoin-listtransactions

編集 2：RPC コマンドは xlisttransactions にリネームされた

いくつか簡単な提案：

キー名に”class”を使うと、少なくとも JavaScript、おそらく他の言語でも”class”が予約語であるため問題が生じる。“type”や”variety”など他の同義語の方が後の問題が少ない。

あるいは、そのフィールドを削除して、クレジットを正の数、デビットを負の数で報告する方が良いかもしれない。そして別の”generated”フィールド（ブール値の true または false）を追加する。

各エントリはトランザクションを参照するので、“tx_id”として SHA256 の 16 進エンコードされたトランザクション ID を追加することを提案する。そうすれば listtransactions が refundtransaction JSON-RPC 拡張（および将来の gettransactiondetails でトランザクションの親、トランザクションが含まれるブロックなどを取得できるもの）とうまく連携する。

コードは以下のようになる：

            uint256 tx_hash = transaction.GetHash();
            string tx_id = tx_hash.GetHex();
            mapJSONResponse.push_back(Pair("tx_id", tx_id));

いくつか簡単な提案：

キー名に”class”を使うと、少なくともJavaScript、おそらく他の言語でも”class”が予約語であるため問題が生じる。“type”や”variety”など他の同義語の方が後の問題が少ない。

もう少し具体的にしてもらえるか？主要なプログラミング言語はすべて、JS を含め、任意の文字列の内容に対して合理的に非感受性だ。文字列の内容には言語の予約キーワードやパーシングトークンを確実に含められる。

各エントリはトランザクションを参照するので、“tx_id”として SHA256 の 16 進エンコードされたトランザクション ID を追加することを提案する。そうすれば listtransactions が refundtransaction JSON-RPC 拡張（および将来の gettransactiondetails でトランザクションの親、トランザクションが含まれるブロックなどを取得できるもの）とうまく連携する。

そのためのコードはこのようになる： Code: uint256 tx_hash = transaction.GetHash(); string tx_id = tx_hash.GetHex(); mapJSONResponse.push_back(Pair(“tx_id”, tx_id));

追加した、提案ありがとう。

listtransaction バージョン 7 を公開： http://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactions

提案された txn_id フィールドを追加した——素晴らしい提案だ、ギャビン！ユニークなトランザクション ID が欲しかったところだ 😊

listtransactions を何に使う必要があるのか？

listtransactions を実装しなかった理由は、Web 開発者に使わせたくないからだ。受信した支払いの監視にそれを利用するのは非常に簡単だろう。しかし、その方法で何も取りこぼさないようにする信頼できる方法はない。getreceivedbyaddress と getreceivedbylabel を使った確実なサンプルコードを用意して「これを使って！ これを使って！ listtransactions は使わないで！」と言えるようになるまで、listtransactions を実装すべきではないと思う。

listtransactions を実装する時には、対策の一つとしてすべてテキストにする方法があるかもしれない。フィールドをコメント、確認数、クレジット、デビットなどに分解すべきではない。「0/unconfirmed 0:0:0 date comment debit 4 credit 0」のような整形済みの 1 つの文字列にして、プログラマーが間違った使い方をしにくくすることができるだろう。これはサーバーの状態を確認するためだけのものだ。ただ、HTML の列にフォーマットしたい Web インターフェースにとっては少し面倒かもしれないが。

受信した支払いの監視のために、それに飛びつくのは非常に簡単だろう。だがその方法では、何も取りこぼさないようにする信頼できるやり方が存在しない。getreceivedbyaddressとgetreceivedbylabelを使った確かなサンプルコードが用意できて、「これを使え！ これを使え！ listtransactionsは使うな！」と指し示せるようになるまでは、listtransactionsを実装すべきではないと思う。

「信頼できるやり方が存在しない」というのは、もう少し具体的に言ってもらえるか？

既存の getreceivedby*の仕組みは、明らかに信頼できない。トランザクションを合計値にまとめてしまうからだ。銀行の ATM に行って入金を二回続けて行ったとき、銀行の明細には「ATM 入金 80 ドル」とは出ない。異なるトランザクション ID を持つ「ATM 入金 40 ドル」が二件並ぶはずだ。

俺は何か見落としているか？ listtransactions は getreceivedby*の合計よりも信頼できそうに思える。

ギャビン・アンドレセンの投稿（2010年7月30日 13:18 UTC）

簡単な提案を二つほど。

キー名に “class” を使うと、少なくともJavaScriptや、おそらく他の “class” が予約語の言語で問題が起きる。“type” や “variety”、その他の類義語にしておけば、後々の問題が少ない。

もう少し具体的に言ってくれるか？ 主要なプログラミング言語はどれも、JSを含めて、文字列の中身については素直に無頓着のはずだ。文字列の中身には言語の予約キーワードや構文トークンを含めて構わない。

マップをオブジェクトに変換するのはかなり一般的だから、こういう構文を使えるようにしたい。 foo.tx_id …つまり foo[‘tx_id’] の代わりにだ。特に、データをテンプレートシステムに渡すような場合（それが object.field 構文しか理解しないこともある）には。

そして foo.class はやはりうまくいかない。

listtransactions のバージョン 8 に更新した： http://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactions

ギャビンの提案を取り入れ、class を category にリネームした。

listtransactions を実装しなかった理由は、Web 開発者に使わせたくないからだ。受信した支払いの監視にそれを利用するのは非常に簡単だろう。しかし、その方法で何も取りこぼさないようにする信頼できる方法はない。getreceivedbyaddress と getreceivedbylabel を使った確実なサンプルコードを用意して「これを使って！ これを使って！ listtransactions は使わないで！」と言えるようになるまで、listtransactions を実装すべきではないと思う。

なぜ信頼できないのですか？ GUI が提供しているのと同じ情報を返すだけですし、それで支払いの監視はちゃんと動くじゃないですか…

listtransactions を実装する時には、対策の一つとしてすべてテキストにする方法があるかもしれない。フィールドをコメント、確認数、クレジット、デビットなどに分解すべきではない。「0/unconfirmed 0:0:0 date comment debit 4 credit 0」のような整形済みの 1 つの文字列にして、プログラマーが間違った使い方をしにくくすることができるだろう。これはサーバーの状態を確認するためだけのものだ。ただ、HTML の列にフォーマットしたい Web インターフェースにとっては少し面倒かもしれないが。

ユーザーを自分自身から守るという方針を採用すべきではないと思います。もしやるなら、せめて “devmode” スイッチか設定行でオフにできるようにすべきでしょう。

listtransactions を何に使う必要があるのか？

listtransactions を実装しなかった理由は、Web 開発者に使わせたくないからだ。受信した支払いの監視にそれを利用するのは非常に簡単だろう。しかし、その方法で何も取りこぼさないようにする信頼できる方法はない。getreceivedbyaddress と getreceivedbylabel を使った確実なサンプルコードを用意して「これを使って！ これを使って！ listtransactions は使わないで！」と言えるようになるまで、listtransactions を実装すべきではないと思う。

どうやら君は明らかに CLI より GUI を好んでいるようだ。 だが GUI は本当にひどいインターフェースだ。例えば SSH アクセスできる 5 つのノードがあって、こんなふうにループで状態を定期的に収集したい場合などに：

#!/bin/bash
while read host;
do
   ssh "$host" "hostname; bitcoind listtransactions"
   echo =============
done > report.txt < hostlist
そして report.txt を人間にメールで送る、といった使い方だ。
これが君にとって正当なユースケースであることを願う。

listtransactions を何に使う必要があるのか？

listtransactions を実装しなかった理由は、Web 開発者に使わせたくないからだ。受信した支払いの監視にそれを利用するのは非常に簡単だろう。しかし、その方法で何も取りこぼさないようにする信頼できる方法はない。getreceivedbyaddress と getreceivedbylabel を使った確実なサンプルコードを用意して「これを使って！ これを使って！ listtransactions は使わないで！」と言えるようになるまで、listtransactions を実装すべきではないと思う。

サトシに同意せざるを得ない。“credit/debit” という追加フィールド以外で、これは getreceivedbyaddress や getreceivedbylabel とどう違うんだ？ 誰かもっと分かりやすく説明してくれないか？

これらすべての関数呼び出しに対する俺の唯一の不満は、IP to IP の直接支払いがまったく表示されないことだ。現状では、IP to IP で支払いを送っても、これらのコマンドでは見つけられない。残高が正しいことは分かるが、それがどこから来たものかは分からない。どちらのコマンドもそのトランザクションについての情報を表示してくれないからだ。

もし listtransactions（または getreceivedbyaddress と getreceivedbylabel）が IP to IP トランザクションをリスト表示できるなら、それは有用だろう。

[edit] 生成コインは表示されるようだ、これは実際に有用だ。それと、現状の getreceivedbyaddress と getreceivedbylabel は、そもそも表示するトランザクションの選び方にバグがあるようだ。

生成されたブロックは「成熟」するまで mixed_debit として表示される。成熟は約120確認後だ。成熟後に50 BTCが入金される。これはbitcoinにおけるすべての生成ブロックの標準ポリシーだ。

これの意味が分からなかった。表向きには、コインがブロックチェーンの確実な一部となるまで使われないようにするためだとされている。

ブロックが作成された後、120ブロックの成熟時間は、そのブロックが使用可能になる前にメインチェーンの一部であることを絶対に確実にするためだ。その間ノードは何かをしているわけではなく、自分のブロックの後にさらにブロックが追加されるのを待っているだけだ。その間オンラインである必要はない。

問題は、もしすぐに使えるようにしたとしても、それは自身の生成を含むブロックチェーンの分岐の中でしか使えないということだ。その分岐が最長でなければ、それを生成したトランザクションも、それを使ったトランザクションも、いずれにせよロールバックされる！ 通常のトランザクションよりも疑いの目で見るべき正当な理由はない。特にそれらは非常に小さいからだ。10000 BTC のトランザクションは、0.01 BTC のトランザクションより成熟に時間がかかるわけではない。

ByteCoin