技術的な説明

nixoid 2010年6月10日 20:38 UTC 原文 ·

みなさん、こんにちは。分散型通貨に興味があり、このプロジェクトの開発に参加するか、自分のバージョンを開発するかのどちらかを考えている。決断する前に、ドキュメントからは明確でないいくつかの技術的な点を確認したい。部分的には英語が母国語ではないからでもあるが。

  1. ウォレットを持ちたい場合、ノードを実行する必要があるのか?ウォレットは特定のノードに紐付けられるのか、それともフラッシュドライブに保存して任意のノードで使えるのか?残高はどこにどのような形式で保存されるのか?
  2. 受け取ったコインを検証するために、ネットワーク全体のトランザクションログをダウンロードする必要があるのか?
  3. あるノードがハッキング(または改変)され、ユーザーの ID(公開鍵)を使ってそのアカウントから送金するという潜在的な状況から、ユーザーはどのように保護されるのか?すべてが全員の間で同期されている場合、それは可能に見える。
  4. トランザクション中に 2 つのノード間でどのようなデータが正確にやり取りされるのか?(またはソースコードのどこを見ればいいか教えてほしい)
  5. トランザクション手数料についてもう少し詳しく書いてくれないか。なぜ必要で、どのように、どのような場合に使われるのか、など。
  6. ノードリストの分散化の計画はあるのか?(IRC で知ったのだが、Bitcoin は現在、ノードが freenode の IRC チャンネルに参加することで接続しており、真に分散化されていないようだ)
  7. ある時点以降、誰も新しいコインを生成できなくなるという理解で正しいか?既存の固定量のコインを使うだけになるのか。

回答に感謝する。

答えられるものに答えてみよう:

nixoidの投稿(2010年6月10日 11:38 UTC)

みなさん、こんにちは。分散型通貨に興味があり、このプロジェクトの開発に参加するか、自分のバージョンを開発するかのどちらかを考えている。決断する前に、ドキュメントからは明確でないいくつかの技術的な点を確認したい。部分的には英語が母国語ではないからでもあるが。

ノードを実行するか、誰か(MyBitcoin.com のような)を信頼してウォレットを預けるかのどちらかだ。

口座残高は wallet.dat という Berkeley DB ファイルに保存される(どのディレクトリかは OS による。Mac では~/Library/Application Support/Bitcoin/wallet.dat、Linux では~/.bitcoin/wallet.dat、PC については不明)。

wallet.dat を読めるアプリケーションは bitcoin のコードだけで、データベース構造は bitcoin の C++ソースコード以外にはどこにもドキュメント化されていない。 理論的にはいいえだが、軽量な検証を行うコードはまだ書かれていない。 サトシはウォレットデータベースの暗号化を計画しているので、読むためにはパスワードを入力する必要がある。(トランザクションを生成するためには秘密鍵が必要で、それが wallet.dat に保存されているものだ) 分からない。 このフォーラムにこれについての別のスレッドがある。「サトシの TODO リスト」スレッドを始めて、人々にボランティアを呼びかけてはどうか。 今後 N 年間(N は何年だ、20?)にわたって生成されるコインはますます少なくなる。これはバグではなく機能だ…

自分のバージョンの開発について:既存の C++実装と互換性のある 2番目の bitcoin 実装を作ることを考えているのか(俺の意見では良いアイデア)? それとも似ているが同じではないシステムを作ることか(俺の意見では悪いアイデア)?

QuantumMechanic 2010年6月12日 02:11 UTC 原文 ·

それに賛成だ。トランザクション手数料がうまくスケールしないのではないかという懸念がある。根拠のないものだといいが。

nixoidの投稿(2010年6月10日 11:38 UTC)

みなさん、こんにちは。分散型通貨に興味があり、このプロジェクトの開発に参加するか、自分のバージョンを開発するかのどちらかを考えている。決断する前に、ドキュメントからは明確でないいくつかの技術的な点を確認したい。部分的には英語が母国語ではないからでもあるが。

トランザクション手数料は、今から何年も先にブロックの価値が低くなった後、ブロック生成のインセンティブを与えるために必要です。また、多くのノードが(わずかな生成速度の恩恵しかないために)生成するブロックにトランザクションを記録しなくなった場合、インセンティブとしてトランザクション手数料を適用できます。

おそらく常に、無料でトランザクションをブロックに含めてくれるノードは存在するでしょうが、多くのノードがそうしない場合は数ブロック待つ必要があるかもしれません。

  1. ビットコインアドレスで送信する場合は何もない
  2. 分散型だ。最初にネットワークに接続した後は、IRC は不要だ。
nixoid 2010年7月17日 08:57 UTC 原文 ·

回答に重ねて感謝する。 俺はセキュリティと分散化について異なるビジョンを持っているようだ。 アルゴリズムの提案案かプロトタイプを完成させたら知らせる。

Quantumplation 2010年7月18日 03:47 UTC 原文 ·

ネットワークは標準的な DHT ノード発見の原則で動いている。今のところ、ノード発見を完全に分散化する真の方法は存在しない(誰かがリッスンしていないかとサブネット全体をスキャンするような馬鹿げた手段を除けば)。なぜなら、ネットワーク上の少なくとも 1人を知っていなければならないからだ。その 1人に接続すると、相手が他の接続を知らせてくれ、そこにも接続する、というふうに進む。

クライアントには「オンラインである可能性が高い候補」のリストが付属しているが、それでもある時点でそのすべてがオフラインになる可能性はある。IRC サーバーは、接続できる誰かを見つけるための最後の手段、バックアップとして提供されているだけだ。IRC ポートをブロックしてみれば、それが厳密には必要ないと分かる。

トランザクション手数料について:

今のところ、トランザクション手数料が使われるのは 1 つの場面だけだ。1回のトランザクションで非常に大量の Bitcoin を扱うときだ。その場合でも、手数料は極めて低い(パーセントの何分の一かといった程度)。

後になって、Bitcoin の生成が「割に合わなくなる」と、人々はこれらのブロックを解く理由が薄れていく(その結果、トランザクションの確認にどんどん時間がかかるようになり、ターゲット値はどんどん低くなり、攻撃者がシステムを侵害できる可能性が高まる)。「ブロック生成の主力たち」を商売として続けさせるために、小額のトランザクション手数料が導入されることになる。それによって、彼らの利益率はブロックを解くための電気代や冷却コストをわずかに上回るところに保たれる。

(少なくとも、これが PDF を読んだ俺の理解だ。)