Bitcointalkへのサトシナカモトの投稿和訳 No.21~30

サトシナカモトの投稿の翻訳

BitcointalkへのSatoshi Nakamotoの投稿のNo.21~No.30を翻訳しました。

No.20までと比較し、参加者が増えるとともに論点が増え、質問内容も多様化してきたように思われます。Satoshiの投稿は、基本的にはNo.1から見ていった方が分かりやすいでしょう。このHPも閲覧数は現在あまり多くありませんが、今後大きな需要があれば、各投稿同士の関連性や、Satoshiの投稿だけではなく質問者の投稿も訳していければと思います。
(まずはSatoshiの投稿を訳しきる事が優先かつ、大労働ですが・・・)

No. 21 Re: A few suggestions

それは素晴らしいですね。FreeBSDで問題なく稼働しますか?

headers.hの変更を行いましたが、一貫性を保つために__BSD__としました。定義の完全なリストについてはhttp://docs.wxwidgets.org/stable/wx_cppconst.htmlを参照ください。
#ifdef __BSD__
#include <netinet/in.h>
#endif

malloc.hはWindowsでのみ必要とされます。何かしらの問題を引き起こさないよう、これは__WXMSW__セクションに移動させる予定です。


備考:
The Madhatter氏に対する回答(内容は以下の原文で確認可能)。

原文:

https://bitcointalk.org/index.php?topic=12.msg77#msg77

No. 22 Re: A few suggestions

現在は、オプションで “Minimize to the tray”を設定し、それを “bitcoin -min”として実行することで、最小化したまま開始できます。可視部分は20×20の小さいアイコンのみであり、これをダブルクリックすることでUIにアクセス可能です。
注:64-bit Karmic Koalaでトレイアイコンが消えてしまうバグがあります。64-bitの問題かKarmicの問題のどちらかかは分かりませんが、32-bit Jauntyでは上手く行きました。

Linux上で「システム起動時にBitcoinを開始する」機能は、version 0.2で実装する時間がなかったため、グレイアウトとしました。また、Linuxを扱う様な方は手動でも構わないのではないかとも考えています。その機能をLinux上で使用するためには、-minスイッチについて知る必要があるでしょう。

“-datadir = <directory>”スイッチを押すことで、必要な場所にデータディレクトリを格納できます。実は、既にどなたかが、TrueCrypt USBドライブにそれを格納しています。


備考:
The Doctor氏に対する回答(内容は以下の原文で確認可能)。

原文:

https://bitcointalk.org/index.php?topic=12.msg79#msg79

No. 23 Re: Is my second Transaction working correctly? +Transfer Question

IPアドレスで送信する場合、転送は即時に行われます。ビットコインアドレスで送信し、その時点で受信者がオンラインでない場合、30分以上要する事もあります。

また、受信したトランザクションが表示される前に、受信者をブロックチェーンと同期させる必要があります。つまり、下部のステータスバーに「x接続 33200ブロック xトランザクション」と表示されるように、少なくとも33000ブロック必要となります。

Quote from: sirius-m on January 05, 2010, 01:20:06 AM


Quote
ただし、トランザクションが完了すると、次の新しいトランザクションは開始されませんでした。いえ、もしかしたら開始しているのかもしれませんが。なお、リストにはトランザクションは1つのみであり、ステータスの下には131ブロックと表示されています。この挙動で問題ないでしょうか?同じトランザクションで処理が継続され、120ブロック毎にコインが生成されるのでしょうか?それとも、新しいトランザクションを開始するのでしょうか?


トランザクションのブロック数は、トランザクション後にネットワーク全体によって生成された新しいブロックの量です。チェーン内の新しいブロックはそれぞれ、作成者に属する新しいコインとなります。トランザクションリスト内の、1つの”generated”トランザクションは、1つのブロックを生成した事を意味します。 初めて”block”の概念を理解する際には、多くの方が最初は混乱してしまいます。

ステータスに以下の通り、”x confirmations”と表示させれば、明確になるかもしれません。
2/unconfirmed
3/unconfirmed
4/unconfirmed
5/unconfirmed
6 confirmations
7 confirmations
8 confirmations

各ブロックは、本質的には、別のノードがそれまでの全トランザクションに同意した事を意味します。


備考:
AgoraMutual氏に対する回答(内容は以下の原文で確認可能)。

原文:

https://bitcointalk.org/index.php?topic=17.msg85#msg85

No. 24 Re: 64bit support

まだ64-bit版はコンパイルしていません。64-bitの数字は数か所のみで使用され、SHA-256は32-bitのアルゴリズムのため、64-bit版が高速化に寄与することは無いでしょう。しかしながら、64-bitのOSを使用している方には便利かもしれません。もし機会があれば-m64を試し、何が問題か確認してみます。

ia32-libsのインストールにより、64-bit版のLinux上で32-bit版を実行可能です。(sudo apt-get install ia32-libs)。Debianパッケージを作成した場合、自動的にそれをディペンデンシーとして引き出す事が可能となります。


備考:
The Madhatter氏に対する回答(内容は以下の原文で確認可能)。

原文:

https://bitcointalk.org/index.php?topic=18.msg97#msg97

No. 25 Re: Number of connections?

コインは1つ以上の任意のノードの接続で、同速度で生成されます。

接続が多くなるほど冗長性も増加します。一方で、接続が1つのみであった場合に、そのノードが低速、ビジー状態、またはあなたのみに接続されている場合はどうでしょうか?接続が複数の場合、ネットワークへの接続が確実になりますが、それは実際には問題ではありません。というのも、ネットワークには確かに接続されているためです。従って、2つまたは3つの接続があるだけで十分です。


備考:
RogerRabbit氏に対する回答(内容は以下の原文で確認可能)。

原文:

https://bitcointalk.org/index.php?topic=21.msg112#msg112

No. 26 Re: TOR and I2P

その事は私も随分考えていました。.onionアドレスのバックエンドサポートを追加し、それらに接続する形にしようと思います。

ユーザーが.onionアドレスを作成するためには多くの手順を経る必要があるため、.onionアドレスはそれほど使用されていません。 .onionアドレスを生成するようにTORを構成してから一旦再起動し、生成されたアドレスで構成します。これは、TORが自動的にファイル共有プログラムに統合できないようにする事を目的としています。


備考:
The Madhatter氏に対する回答(内容は以下の原文で確認可能)。

原文:

https://bitcointalk.org/index.php?topic=22.msg113#msg113

No. 27 Re: Bitcoin crash when sending coins

それはウォレットファイルをコピーすると生じる現象です。ウォレットファイルを別のコンピュータにコピーすると、それぞれのウォレット内のお金が両方とも自分のものだと一旦看做されます。一方のコンピューターで、あるコインを消費すると、もう一方はそのコインが既に使用された事を知らないため、使用済みコインを改めて使用する事を試みますが、エラーとなってしまいます。

これは重要なエラーメッセージである事が改めて分かったため、「お金は既に使用されたようです…このエラーは別のコンピュータでウォレットファイルのコピーを使用した場合に生じます」と言ったような形にすべきでしょう。

ウォレットファイルを移動またはバックアップする事はできますが、一度に1つの系列および1つの場所に限られています。そこからコインを移す際には、以前のコピーウォレットを使用してはいけません。

これに対して良い提案があります。コインを使用する前のバックアップを復元する場合に、どのコインが既に使用済か発見するための、再同期機能の追加です。この機能の実装は難しくはありませんが、まだ実装されていません。そのため、これをリストに追加します。この機能の実装によって、エラーメッセージが出されてしまうような状況は、大分回避されるでしょう。


備考:
riX氏に対する回答(内容は以下の原文で確認可能)。

原文:

https://bitcointalk.org/index.php?topic=27.msg156#msg156

No. 28 Re: A newb’s test – anyone want to buy a picture for ?

はい、それは技術的な限界です。ビットコインアドレスによる送信は、トランザクションをネットワークに入力し、受信者はそのネットワークからトランザクションを検出します。それらに直接接続している必要性や、その際にオンラインである必要性はありません。

私は短いメッセージを含めるための方法を切望していましたが、問題は全世界の方々がメッセージを閲覧できる事です。メッセージが完全に非公開である事が認識されている限り、それは起こるべくして起こるでしょう。

残念ながら、ECDSAは署名のみ可能であり、メッセージを暗号化する事はできません。また、ECDSAのサイズは小さい必要があります。 RSAはメッセージを暗号化できますが、ECDSAよりも何倍もサイズが大きくなってしまいます。


備考:
RogerRabbit氏に対する回答(内容は以下の原文で確認可能)。

原文:

https://bitcointalk.org/index.php?topic=25.msg159#msg159

No. 29 Re: Blocks never stop generating?

ステータス上で “#blocks”と記載されている箇所は、”#confirmations”に変更しています。その方が明確だと考えています。

また、トランザクション上でダブルクリックをすれば、その詳細が分かります。


備考:
Sabunir氏に対する回答(内容は以下の原文で確認可能)。

原文:

https://bitcointalk.org/index.php?topic=28.msg160#msg160

No. 30 Re: Bitcoin crash when sending coins

再同期のアイデアでは、ウォレットを確認し、ブロック索引と照合して、現在のコンピューターにより認識されていないトランザクションが、既に使用されたものか検出します。これは、ウォレット・ファイルのコピーが別のコンピュータで使用された場合や、ウォレットを使用する前にバックアップするために、リストアする場合に発生します。現在では、ソフトウェアは、トランザクションが使用された際にwallet.datにマークすることで、使用状況を常に把握しています。

ウォレットマージツールを実装する事は可能ですが、再同期のアイデアが問題の殆どを解決する場合、その需要は大幅に減少します。再同期によって、お金を1つの財布から別の財布に送付する事で、同様の結果が得られます。受領者は再同期する事でオーバーラップ分のコインが使用済みである事を確認し、新しいトランザクションで受領します。


備考:
riX氏に対する回答(内容は以下の原文で確認可能)。

原文:

https://bitcointalk.org/index.php?topic=27.msg170#msg170

コメント