Re: Bitcoin

了解しました。 ウェブサイトと FAQ は私が担当できます。 思いつく質問から FAQ を書き始めます。

それは素晴らしい。 あなた (dmp1ce) を SourceForge プロジェクトの開発者として追加し、 ウェブスペースなどを編集する権限を与えた。

プログラムへの機能提案があります: パスワードで保護された秘密鍵を作成し、 任意の場所に保存できる UI ツールです。 鍵のバックアップは、 コインの管理権を失わないため、 また複数のコンピューターでコインを使えるようにするために必要です。 パスワード保護は、 鍵ファイルを偶然見つけた人が金銭を使うことを難しくするために必要です。

その通り。 物事が動き始めれば、 これは絶対に必須の機能になる。 強力な暗号化で自分の資産を施錠でき、 物理的な金庫よりも安全にバックアップできるようになる。 これまでは他の機能を優先して後回しにしてきた。 ビットコインに価値が付くまではまだ重要でないからだ。

次にエスクロー機能の開発に取り組む予定だ。 これは物理的な物の取引をより安全にし、 法定通貨での裏付けが始まる前に必要だ。

PC の電源を入れているときはいつもビットコインノードを稼働させています、 ほぼ 24 時間。 ビットコインは素晴らしいプロジェクトで、 参加できるのは本当にクールです！

ありがとう！ 今ネットワーク上には incoming 接続を受けられない人が多くいるので、 受けられるノードは大いに助かる。 ノードが増えれば、 「(not accepted)」 の問題を抑える助けになる。 v0.1.6 でその発生確率を下げるまでの暫定対策だ。

FAQ の項目の一つとして、 incoming 接続を受けるためにポート 8333 をフォワードするファイアウォール設定の方法を入れるとよいと思う。 質問は「接続が 0 件のときどうすればよいか」 のようなものでよく、 答えは設定をしないと接続できるノードが限られる可能性がある、 となるだろう。

以下に、 フォーラムやメールで答えてきた質問の集成を載せる。 頻出質問が何で、 私がどう答えてきたかの参考になるはずだ。 全部や大半を使うつもりはなく、 取捨選択してくれ。 これまで答えた内容のダンプにすぎない。

簡単に答えられない論点は、 そもそも持ち出さない方がよい。 一般ユーザーはシステムが述べた通り動く (実際に動く) と仮定して満足するもので、 設計の細部に入ると、 システムを深く理解しなければ答えられない厄介な議論を開いてしまう。 これまで受けた高度な質問は人ごとに違っていて、 個別に答えるのが最善だった。

**** 質問と回答のダンプ ****

FAQ に使う質問はおそらく言い回しを変えるべきだ。

質問:

UI の下部に次のように表示される:

Generating 4 connections 4024 blocks 164 transactions

generating は理解できる。 4 つの他のノードに接続していると思う。 164 のトランザクション (失敗した生成試行を含む) を記録していることも分かる。 blocks の数字が何を表しているのか分からない。 各トランザクションに対して表示されるブロック数の合計よりずっと小さい。

これはブロックチェーンのブロック総数、 すなわちネットワークのブロックチェーンの数で、 全員が同じものを持っている。 すべてのビットコインノードが同じ数字を表示し、 誰かがブロックを生成するたびに約 10 分ごとに増えていく。 しばらく動かしていなかった場合、 接続後に不在中に生成された分をダウンロードして急速に追いつく。 (ステータスバーに 1 語、 最大でも 2 語で収まるように) どう説明するのがよいか、 アイデアはあるか？

トランザクションの隣のステータス列にある blocks 数字は、 そのトランザクションの後に来たブロックの数だ。 トランザクションはそれだけのブロック内に本質的に「入っている」 ことになる。

Satoshi

私の推測では ―― グローバルチェーンの長さであり、 最初の急速な進行は、 ソフトウェアがチェーン内の先行ブロックをダウンロードし、 有効であることを検証しているためだろう。

その通り。 もっと明確な表現を考えているところで、 「%d network blocks」 や「%d block chain」 のようなものを検討している。

(block not-accepted) の失敗が普段より多く出ているようなので、 何か意味があるかもしれないと思い知らせておく。

not-accepted のレートはどれくらいだった？ こちらでは異常は見えなかった。 仮に 4 件以上連続したら異常で、 おそらくネットワーク通信の喪失だ。 散発的に 25% 未満なら、 単なる不運だ。 不採用がランダムにある程度発生するのは正常で無害だ。 もちろんランダムな分布は偏ってパターンに見えることもある。

unaccepted ブロックの表示/非表示オプションは良いアイデアだ。 生成ブロック全体の表示/非表示も同様で、 着信トランザクションがより見やすくなる。 unaccepted ブロックの表示は、 ただ煩わしく不満を感じるだけだ。 不採用率は誰もが同じで、 プロセスの一部にすぎない。 デフォルトでは unaccepted ブロックを隠す方がよいだろう。 そもそも存在しなかったものを与えて取り上げる演出を避けられるし、 新規生成ブロックも少なくとも 1 confirmation が付くまでは表示しない方がよい。 通常より 15 分遅れて生成ブロックを知るだけのことで、 どのみち成熟まであと 119 ブロック残っている。 これは v0.1.6 の TODO だ。

Satoshi

（注：0.1.6 でこの問題をある程度軽減する改善を入れる。 また、 ネットワークが大きくなれば自然に改善する）

何らかの理由で、 あなたからの送金が From: unknown と表示される。 私のアドレス帳にあなたを追加したのに。

トランザクションリストに Generated (not accepted) という行がある。コインの生成の試みが何かうまくいかなかったようだ。何が起きたのか分からない――おそらく私のノードがブロックの解決に成功したものの、ネットワークに送信される前にオフラインになったのだろうか？

ビットコインアドレス宛に送られたトランザクションは常に from: unknown と表示される。 トランザクションは宛先しか伝えない。 ビットコインアドレス送信にはいくつかの問題があるが、 オンラインかどうかに関わらず誰にでも送れるフォールバックがあるのは大変ありがたい。 後で改善するアイデアがいくつかある。 今は、 もし現実世界のように大半のトランザクションが商人とのものになれば、 商人は必ず IP で受け取れるよう設定するだろう。 P2P ファイル共有ネットワークは、 ユーザーの大部分にファイアウォールのポートフォワードを設定させることに概ね成功している。

間接送金にコメントを添える方法を切実に探したが、 手段がなかった。 ビットコインは EC-DSA を使っている。 ブロックチェーンを今日の技術で実用的なほどコンパクトにするために必須だった。 EC-DSA の署名は RSA より一桁小さい。 だが EC-DSA は RSA のようにメッセージを暗号化できず、 署名検証にしか使えない。

Generated (not accepted) は通常、 2 つのノードがほぼ同時にブロックを見つけた場合に発生する。 一方が採用されない。 正常で避けられない。 v0.1.6 ではこれを隠す予定だ。 ただ混乱と苛立ちを生むだけで、 ユーザーに見せる理由がない。 ネットワークが今のように小さい間は、 incoming 接続を受けられないと、 ブロック告知を直接受け取れないため不利になる。

…今のところ Generated メッセージが 2 つ出ている。 だが Credit フィールドは 0.00 で残高は変わっていない。 コインが有効になるまでの age/maturity 要件のせいか？

そう、 credit フィールドは成熟するまで 0.00 のままで、 成熟すると 50.00 になる。 ちなみに、 行をダブルクリックすれば詳細が見える。

…正しく理解していれば、 すべてのトランザクションがハッシュ化される単一の (もしくは数本の) グローバルチェーンしか存在しない。 「経済の物語」 を記録するチェーンが 1 本しかないなら、 これはどうスケールするのか？ 全球規模で展開すれば、 1 時間に数百万、 数十億のトランザクションがチェーンにハッシュ化されることになる…

…インセンティブの節が分かりにくかった。 特に、 ノードを動かす理由が新規コインの鋳造からトランザクション手数料の徴収に移る引き金が何なのか分からない (BitCoin の要点はそもそもトランザクションコストをゼロにすることではないのか？)。 おそらくシステムを取り仕切る人間がいると想定するが…

…v1 のインフレスケジュールはどう決めたのか？ 2,100 万コインはどこから来たのか？ これらのコインの額面は何か？ 価値の結合と分割の方法に言及があるが、 仕組みが分からない。 例えば、 ビットコインは常に整数で表されるのか、 それとも小数を持てるのか？…

…本当に革命的なアイデアに出会うことは滅多にない。 新しい貨幣スキームでこれほど興奮したのは、 リップルを見つけた時以来だ。 リップルについて何か考えがあれば、 ぜひ聞かせてほしい。

グローバルチェーンは 1 本だけだ。

既存の Visa クレジットカードネットワークは世界で日に約 1,500 万件のインターネット購入を処理している。 ビットコインは既存ハードウェアでその何倍もスケール可能で、 コストも一桁安い。 実質的にスケール上限に達することがない。 興味があれば、 極端な規模にどう対処するか説明する。

ムーアの法則により、 ハードウェア速度は 5 年で 10 倍、 10 年で 100 倍速くなると見込める。 ビットコインが狂気じみた採用率で伸びても、 コンピューターの速度はトランザクション数の伸びを先行し続けると思う。

近いうちに手数料が必要になるとは見ていない。 だがノード運用が負担になりすぎる場合は、 トランザクション手数料を含むトランザクションのみを処理するノードを動かすことも可能だ。 ノードオーナーが受け入れる最低手数料を決める。 今そのようなノードは何も得られない。 誰も手数料を含めないからだ。 だが十分な数のノードがそうすれば、 手数料を含めるユーザーはより速く受理され、 含めなければ遅くなる。 市場が落ち着く手数料は最小限になるはずだ。 ノードが高い手数料を要求すれば、 そのノードは低い手数料のトランザクションを取り逃す。 むしろ可能な限り多くの有料トランザクションを処理することで、 出来高を増やしより多く稼げる可能性が高い。 移行はシステムを取り仕切る人間に制御されるのではなく、 個人が市場の力に反応するだけだ。

ビットコインの重要な側面は、 ネットワークのセキュリティが、 ネットワークの規模と保護すべき価値の量とともに成長することだ。 短所は、 開始時の小さい段階では脆弱だということだ。 ただし盗まれうる価値は常に盗むのに必要な労力より小さいはずだ。 誰かが別の動機で論点を証明したいなら、 私が既に認めている論点を証明することになる。

コイン数と分配スケジュールの選択は教育的推測だった。 難しい選択だった。 ネットワークが動き出すと固定されてしまい、 そのまま付き合うことになるからだ。 既存通貨と似た価格になる数字を選びたかったが、 未来を知らないでこれは非常に難しい。 最終的に中間を選んだ。 ビットコインが小さなニッチに留まれば、 単位あたり既存通貨より安くなる。 世界商取引の一部に使われると想像すれば、 全世界で 2,100 万コインしかないので、 単位あたりずっと高い価値になる。 値は 64 ビット整数で小数点以下 8 桁、 つまり 1 コインは内部的に 100000000 と表される。 典型的な価格が小さくなっても粒度は十分にある。 例えば 0.001 が 1 ユーロの価値になれば、 小数点の表示位置を変える方が楽だろう。 1 ビットコインが 1000 と表示され、 0.001 が 1 と表示される、 など。

リップルは信頼を扱う点で興味深い。 中央サーバーに集中させる以外で信頼を扱う唯一の他システムだ。

Satoshi