お元気でいることを願っている。ようやくすべての弁護士を説得し、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の直前に、当事者と数人の証人ノードが見た中で最も高いシーケンスのトランザクションをブロードキャストする。