[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でトランザクションの親、トランザクションが含まれるブロックなどを取得できるもの）とうまく連携する。
コードは以下のようになる：
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におけるすべての生成ブロックの標準ポリシーだ。
生成されたブロックは「成熟」するまでmixed_debitとして表示される。成熟は約120確認後だ。成熟後に50 BTCが入金される。これはbitcoinにおけるすべての生成ブロックの標準ポリシーだ。
これの意味が、ずっと分からない。表向きには、コインがブロックチェーンの確実な一部となるまで使われないようにするためだとされている。
サトシ・ナカモトの投稿（2009年11月22日18:34 UTC）ブロックが作成された後、120ブロックの成熟時間は、そのブロックが使用可能になる前にメインチェーンの一部であることを絶対に確実にするためだ。その間ノードは何かをしているわけではなく、自分のブロックの後にさらにブロックが追加されるのを待っているだけだ。その間オンラインである必要はない。
問題は、もしすぐに使えるようにしたとしても、それは自身の生成を含むブロックチェーンの分岐の中でしか使えないということだ。その分岐が最長でなければ、それを生成したトランザクションも、それを使ったトランザクションも、いずれにせよロールバックされる！ 通常のトランザクションよりも疑いの目で見るべき正当な理由はない。特にそれらは非常に小さいからだ。10000 BTCのトランザクションは、0.01 BTCのトランザクションより成熟に時間がかかるわけではない。
ByteCoin