お元気でいることを願っている。ようやくGoogleの弁護士全員を説得した。Apache 2ライセンスでBitCoinJを公開する：
まだ不完全で、特にブロックチェーンの分岐を適切に処理できていないが、残りの部分は順次実装していく。ドキュメントとコメントに多くの労力を費やしたので、現在のコードを理解・ビルドできなかった新しい層にBitCoinを開放できればと思う。今後1〜2ヶ月で、完全なクライアントモード実装に必要な大きな欠落部分を仕上げる予定だ。
素晴らしいニュースだ。クライアント要件のみのクリーンな書き直しでは多くの複雑さを省くことができるし、Java の開発者にも門戸を開くことになる。
マイク・ハーンのメール（2011年3月7日 14:13 UTC）忙しいところ申し訳ないが、いくつか質問に答えてもらえないだろうか。
喜んで質問に答える。
マイク・ハーンのメール（2011年3月7日 14:13 UTC）完全なSPVの実装の一環として、プロトコルにgetmerklebranchメッセージを追加することを考えている。これはトランザクションハッシュを指定すると{blockhash, branch}のペアのセットを返すもので、
それは CMerkleTx だ。
マイク・ハーンのメール（2011年3月7日 14:13 UTC）フルチェーンを保存せずにブロードキャストされたトランザクションをブロックに組み込まれる前に検証できるようにするものだ。このアプローチについてどう思うか？
理解できない。マークルブランチはトランザクションをブロックにリンクするが、それはブロックが Proof of Work を示す場合にのみ意味を持つ。まだ解かれていないブロックにリンクしても何も証明しない。
ネットワークノードが 0-conf トランザクションを検証できるのは、完全なトランザクションインデックスを持っているためで、以下のことが可能だ：
- 依存関係に対して署名を検証する。
- 存在するすべてのトランザクションを知っているため、まだ別の支出を見ていないと言える。
トランザクションの依存関係に対する CMerkleTx について話しているのか？それなら 1)は得られるが、2)は得られない。
存在するすべてのトランザクションを知らない場合、2)をどうやって実現するか分からない。他のノードを信頼するしかないだろう。その信頼は複数のノードに分散させることができる。ノードは有効と認めるトランザクションのみをリレーする。接続しているすべてのノードからトランザクションの inv メッセージを受信した場合、それらのノードはそのトランザクションが有効であり、最初に見た支出であることを証明している。
マイク・ハーンのメール（2011年3月7日 14:13 UTC）また、最近さまざまなトランザクションタイプの探求を考えている。例えばtestnetでIsStandard()チェックを削除するなどだ。
非常に良いアイデアだ。-testnet では間違いなく許可すべきだ。
マイク・ハーンのメール（2011年3月7日 14:13 UTC）単純なコインの移動以外のトランザクションについて、あなたが事前に多くの思考を費やしたことは明らかだが、残念ながらそのいずれも論文やコード内に文書化されていない。エスクロー、マルチペイなどはいずれも興味深いが、スクリプト言語で何ができるかのアイデアリストをまとめてもらえないだろうか。
最後に、トランザクション置換を可能にするコードは無効化されているが、コメントにはその理由が書かれていない。これは単に攻撃対象領域・複雑さを減らすためか、それともより深い理由があるのか？
攻撃対象領域を減らすためだけだ。トランザクション手数料の引き上げには役立たない。トランザクションは 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 の直前に、当事者と数人の証人ノードが見た中で最も高いシーケンスのトランザクションをブロードキャストする。