BitcoinJのオープンソースリリースとプロトコルに関する質問
Satoshiさん、こんにちは。
お元気でいることを願っている。ようやくすべての弁護士を説得し、GoogleのもとでApache 2ライセンスを使用してBitCoinJをリリースすることができた：
http://www.bitcoin.org/smf/index.php?topic=4236.0
まだ不完全で、特にブロックチェーンの分岐を適切に処理できていないが、残りの部分は順次実装していく。ドキュメントとコメントに多くの労力を費やしたので、現在のコードを理解・ビルドできなかった新しい層にBitCoinを開放できればと思う。今後1〜2ヶ月で、完全なクライアントモード実装に必要な大きな欠落部分を仕上げる予定だ。
お忙しいところ恐れ入るが、いくつか質問にお時間をもらえれば幸いだ。
完全なSPVの実装の一環として、プロトコルにgetmerklebranchメッセージを追加することを考えている。これはトランザクションハッシュを指定すると{blockhash, branch}のペアのセットを返すもので、フルチェーンを保存せずにブロードキャストされたトランザクションをブロックに組み込まれる前に検証できるようにするものだ。このアプローチについてどう思うか？
また、最近さまざまなトランザクションタイプの探求を考えている。例えばtestnetでIsStandard()チェックを削除するなどだ。単純なコインの移動以外のトランザクションについて、あなたが事前に多くの思考を費やしたことは明らかだが、残念ながらそのいずれも論文やコード内に文書化されていない。エスクロー、マルチペイなどはいずれも興味深いが、スクリプト言語で何ができるかのアイデアリストをまとめてもらえないだろうか。
最後に、トランザクション置換を可能にするコードは無効化されているが、コメントにはその理由が書かれていない。これは単に攻撃対象領域・複雑さを減らすためだろうか、それともより深い理由があるのだろうか？シーケンス番号がトランザクション自体ではなくトランザクション入力のプロパティである理由も完全には理解できていない。
早くコミュニティに戻ってきてくれることを願っている！これを見たかどうか分からないが：
http://bitcoin.sipa.be/speed-lin.png
ネットワークにとってエキサイティングな時期だ！
ありがとうございます！
/mike
お元気でいらっしゃることを願っています。ようやくすべての弁護士を説得し、GoogleのもとでApache 2ライセンスを使用してBitCoinJをリリースすることができました：
まだ不完全で、特にブロックチェーンの分岐を適切に処理できていませんが、残りの部分は順次実装していきます。ドキュメントとコメントに多くの労力を費やしたので、現在のコードを理解・ビルドできなかった新しい層にBitCoinを開放できればと思います。今後1〜2ヶ月で、完全なクライアントモード実装に必要な大きな欠落部分を仕上げる予定です。
素晴らしいニュースだ！クライアント要件のみのクリーンな書き直しでは多くの複雑さを省くことができるし、Javaの開発者にも門戸を開くことになる。
お忙しいところ恐れ入りますが、いくつか質問にお時間をいただければ幸いです。
喜んで質問に答える。
完全なSPVの実装の一環として、プロトコルにgetmerklebranchメッセージを追加することを考えています。これはトランザクションハッシュを指定すると{blockhash, branch}のペアのセットを返すもので、
それはCMerkleTxだ。
フルチェーンを保存せずにブロードキャストされたトランザクションをブロックに組み込まれる前に検証できるようにするものです。このアプローチについてどう思われますか？
理解できない。merkleブランチはトランザクションをブロックにリンクするが、それはブロックがProof of Workを示す場合にのみ意味を持つ。まだ解かれていないブロックにリンクしても何も証明しない。
ネットワークノードが0-confトランザクションを検証できるのは、完全なトランザクションインデックスを持っているためで、以下のことが可能です：
- 依存関係に対して署名を検証する。
- 存在するすべてのトランザクションを知っているため、まだ別の支出を見ていないと言える。
トランザクションの依存関係に対するCMerkleTxについて話しているのか？それなら1)は得られるが、2)は得られない。
存在するすべてのトランザクションを知らない場合、2)をどうやって実現するか分からない。他のノードを信頼するしかないだろう。その信頼は複数のノードに分散させることができる。ノードは有効と認めるトランザクションのみをリレーする。接続しているすべてのノードからトランザクションのinvメッセージを受信した場合、それらのノードはそのトランザクションが有効であり、最初に見た支出であることを証明している。
また、最近さまざまなトランザクションタイプの探求を考えています。例えばtestnetでIsStandard()チェックを削除するなどです。
非常に良いアイデアだ。-testnetでは間違いなく許可すべきだ。
単純なコインの移動以外のトランザクションについて、あなたが事前に多くの思考を費やしたことは明らかですが、残念ながらそのいずれも論文やコード内に文書化されていません。エスクロー、マルチペイなどはいずれも興味深いですが、スクリプト言語で何ができるかのアイデアリストをまとめていただけないでしょうか。
最後に、トランザクション置換を可能にするコードは無効化されていますが、コメントにはその理由が書かれていません。これは単に攻撃対象領域・複雑さを減らすためでしょうか、それともより深い理由があるのでしょうか？
攻撃対象領域を減らすためだけだ。トランザクション手数料の引き上げには役立たない。トランザクションはnLockTimeから有効になる。ある時点で有効でなくなるトランザクションは機能しない。一度有効になったトランザクションは、永久に有効でなければならない。
以下のスレッドを参照してほしい：
http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119
http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729
シーケンス番号がトランザクション自体ではなくトランザクション入力のプロパティである理由も完全には理解できていません。
コントラクトのためだ。記録されていないオープントランザクションは、nLockTimeまで置換し続けることができる。複数の当事者からの支払いを含む場合がある。各入力の所有者が自分の入力に署名する。新しいバージョンを書くには、それぞれがより高いシーケンス番号に署名しなければならない（IsNewerThanを参照）。署名することにより、入力の所有者は「全員が資金を投入し、出力がこうであるなら、私は自分の資金を投入することに同意する」と言っている。SignatureHashにはSIGHASH_SINGLEのような他のオプションもあり、これは「この1つの出力（つまり自分のもの）が望み通りであれば同意し、他の出力については気にしない」という意味だ。これが高いnSequenceNumberで書かれた場合、当事者はその1つの条件を除いて交渉から離脱できる。あるいはSIGHASH_NONEで署名して完全に離脱することもできる。
当事者はOP_CHECKMULTISIGを使用してより高いnSequenceNumberのトランザクションを作成し、署名を完了するために当事者のサブセットの署名を必要とする、事前に合意されたデフォルトオプションを作成できる。当事者はこのトランザクションを保留し、必要に応じて十分な署名が集まるまで回覧する。
nLockTimeの1つの用途は、一組の当事者間での高頻度取引だ。全員一致の合意によりトランザクションを更新し続けることができる。資金を提供する当事者が次のバージョンに最初に署名する。一方の当事者が変更への合意を停止した場合、最後の状態がnLockTimeで記録される。必要であれば、各バージョンの後にデフォルトトランザクションを準備して、n-1の当事者が応答しない当事者を排除できる。中間トランザクションをブロードキャストする必要はない。最終結果のみがネットワークに記録される。nLockTimeの直前に、当事者と数人の証人ノードが見た中で最も高いシーケンスのトランザクションをブロードキャストする。
存在するすべてのトランザクションを知らない場合、2)をどうやって実現するか分かりません。他のノードを信頼するしかないでしょう。その信頼は複数のノードに分散させることができます。ノードは有効と認めるトランザクションのみをリレーします。接続しているすべてのノードからトランザクションのinvメッセージを受信した場合、それらのノードはそのトランザクションが有効であり、最初に見た支出であることを証明しています。
おっしゃる通りだ。入力の検証について話していたのだが、すべてのオープントランザクションを把握しなければ確かに意味がない。したがって、CMerkleTxを取得できることは重要ではない。
攻撃対象領域を減らすためだけです。トランザクション手数料の引き上げには役立ちません。トランザクションはnLockTimeから有効になります。ある時点で有効でなくなるトランザクションは機能しません。一度有効になったトランザクションは、永久に有効でなければなりません。
以下のスレッドを参照してください： http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119 http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729
なるほど。つまり現在、手数料は事前に決めなければならないため厄介で、低すぎた場合にトランザクションを修正する方法がなく、ネットワークはいずれ忘れるものの、ウォレットにはコインを使ったと記録されたままになる。これはすでに起こり始めている。
コントラクトのためです。
なるほど。システムのまだ探索されていない領域全体が目の前に開けた :-) 仲介者を信頼する必要なしに分散コントラクトやエスクロートランザクションを形成するという概念は、BitCoin自体とほぼ同じくらい斬新な概念だと思う。
もっと質問がある！
プロトコルにはpublisher/subscriberチャネルを設定するための未完成の部分があり、ネットワークを介した分散ルーティングを扱っている。これの目的は何だったのか？P2Pマーケットのアイデアだったのか、それとも予想されるトランザクション手数料のブロードキャストなど、何かもっと低レベルの機能だったのか？
数ヶ月前にBitCoinを一般化することについて興味深い議論があったが、あなたがそれをどのように達成しようとしていたかを完全に理解するのは難しかった。複数の独立したチェーンの上に別のmerkleツリーを配置するという概念は理解できたと思う：
http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171
しかし、後方互換性のために200バイトを持つというあなたのコメントは理解できなかった。また、これは明らかだと思うが、念のため確認する。あなたのアイデアでは、代替チェーンはBitCoinとまったく同じ形式と検証ルールのセット（同じスクリプト言語など）を共有し、すべてのマイナーは非金融的な性質のブロックであっても検証できるということか？そして、別々のブロックチェーンを持つ意味は、単にクライアントモード実装のストレージコストと帯域幅を管理することなのか？
ありがとうございます！
以下のスレッドを参照してください： http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119 http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729
なるほど。つまり現在、手数料は事前に決めなければならないため厄介で、低すぎた場合にトランザクションを修正する方法がなく、ネットワークはいずれ忘れるものの、ウォレットにはコインを使ったと記録されたままになる。これはすでに起こり始めています。
ネットワークは忘れないし、所有者のクライアントは再ブロードキャストし続ける。オーバーフロートランザクションは、残りの0.3.8ノードが減少する中でも数ヶ月間ネットワークに記憶されていた。
優先度には経過時間が含まれるため、トランザクションが待機するにつれて経過時間が増え、最終的には十分な優先度を持つようになる。
上記のリンクの1つで、手数料を増やすために正直な二重支払いを送信することを検討している。多くの作業が必要だが、実行は可能だ。現時点ではその価値はないと思う。
現在のシステムでは、ノードが現在の条件に十分な手数料を含めるようにし、ネットワークがすべてのトランザクションを最終的に処理するようにしており、十分に機能している。Gavinは、ノードが自分のトランザクションを書き込む際に優先度をチェックしていなかった見落としを修正している。
処理速度の不確実性を心配するユーザーは、手数料を含めることへの動機付けと考えるべきだ。
プロトコルにはpublisher/subscriberチャネルを設定するための未完成の部分があり、ネットワークを介した分散ルーティングを扱っています。これの目的は何でしたか？P2Pマーケットのアイデアでしたか、それとも予想されるトランザクション手数料のブロードキャストなど、何かもっと低レベルの機能でしたか？
クライアントに組み込んだeBayスタイルのマーケットプレイスを実装しようとしていた。Publish/subscribeは商品オファーや評価・レビューのブロードキャストに使用される予定だった。レビューはあなたが生成したブロックによって重み付けされる。JSON-RPCを優先して正しく放棄した。これにより他の開発者が外部で実装できるようになった。publish/subscribeの「中間で出会う」メカニズムは興味深い概念だったが、それを使用するものは何も残っていない。
これは最も技術的に要求の厳しいユースケースを探索し、ブロックチェーンが開始された後のルールのロックイン性を考慮して、将来必要になる可能性のあるすべてをBitcoinがサポートできることを確認するためのコード作成の一部だった。
数ヶ月前にBitCoinを一般化することについて興味深い議論がありましたが、あなたがそれをどのように達成しようとしていたかを完全に理解するのは難しかったです。複数の独立したチェーンの上に別のmerkleツリーを配置するという概念は理解できたと思います：
http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171
しかし、後方互換性のために200バイトを持つというあなたのコメントは理解できませんでした。また、これは明らかだと思いますが、念のため確認します。あなたのアイデアでは、代替チェーンはBitCoinとまったく同じ形式と検証ルールのセット（同じスクリプト言語など）を共有し、すべてのマイナーは非金融的な性質のブロックであっても検証できるということですか？そして、別々のブロックチェーンを持つ意味は、単にクライアントモード実装のストレージコストと帯域幅を管理することですか？
いいえ、他のチェーンはBitcoinのルールには従わない。それらは完全に独立したチェーンだ。マイナー以外は何も共有しない。他のネットワークのProof of Workの定義は、自分のブロックのハッシュを含むBitcoin形式のブロックを（自分のチェーンの難易度に従って）解くことだ。Bitcoinブロックが有効であるか、Bitcoinによって使用されているかは気にしないが、マイナーが両方のチェーンを同時に作業できるようにする。
BitDNSブロックをハッシュする手順：
- BitDNSブロックをハッシュする
- Bitcoinブロックを構築する
- BitcoinブロックのTx 0のscriptSigにBitDNSハッシュを挿入する
- Bitcoinブロックをハッシュする
そのハッシュがBitDNSのターゲット以下であれば、BitDNSブロックは有効だ。
BitDNSブロックには、ハッシュに使用されたBitcoinブロックを再構築するために必要な約200バイトのデータが必要だ：
- Bitcoinブロックヘッダー
- Tx 0へのmerkleブランチ
- Tx 0（ちなみに、Tx 0のprevハッシュは常に0なので、省略すると32バイト節約できる）
素材となる「Bitcoinブロック」がBitcoinチェーンで実際に有効であったかどうかは問題ではない。ただし、有効であった可能性はある。BitDNSにとっては、その複雑なハッシュ計算を行うために必要な単なるソルトの集まりだ。マイナーがBitDNSのみをマイニングしていてBitcoinに関心がない場合、すべてゼロの空白Bitcoinブロック（nonceを除く）を使用するだろう。
アイデアをさらに拡張性のために発展させるなら、BitDNSブロックハッシュをTx 0に入れる代わりに、BitDNSを含むmerkleツリーのルートを入れることを検討してくれ。これが概念的に最上部にあるmerkleツリーだ。