ビットコイン・インスティテュート

提案:Bitcoinと一緒に短いメッセージを送れるようにしないか?

11件のメッセージ BitcoinTalk ShadowOfHarbringer, grondilu, サトシ・ナカモト, MoonShadow, FreeMoney, ByteCoin 2010年10月23日 — 2010年10月24日
ShadowOfHarbringer 2010年10月23日15:11 UTC

Bitcoinは素晴らしいが、通常の銀行振込にはあってBitcoinにないものが一つある:振込名義だ。

各トランザクションに短い(512バイト以下の)メッセージを含められるようにすべきではないだろうか。 メッセージは公開鍵/秘密鍵で暗号化し、受取人だけが内容を確認できるようにすることもできる。

どう思う?

追伸: 間違っているかもしれないが、メッセージはハッシュ処理のランダム性を高めるためにも使えるのではないだろうか? もし違うなら気にしないでくれ。

grondilu 2010年10月23日15:28 UTC

支払いラベルは必要ない。

ShadowOfHarbringer 2010年10月23日15:45 UTC
grondiluの投稿(2010年10月23日15:28 UTC)

支払いラベルは必要ない。

たしかに「必要ない」が、人々にとって便利ではあるはずだ。

何らかの理由でひとつのBTCアドレスを使い続けたい人もいるだろう。 それに大きな金融機関は、トランザクションごとに別の口座番号を使うという考えをあまり好まないだろう。

ShadowOfHarbringer 2010年10月23日17:59 UTC

興味深いものを見つけた。

http://stackoverflow.com/questions/1138345/best-compression-algorithm-for-short-text-strings

短いテキスト文字列の圧縮に優れた小さなOSプロジェクトがGitHubにある。http://github.com/antirez/smaz

これで384バイトをさらに200バイト未満や175バイト未満にまで縮小できる可能性がある。

grondilu 2010年10月23日18:07 UTC

ハッシュ計算にメッセージを考慮する必要があるかどうかも気になる。考慮しなければ、後から削除することも可能になる。

このメッセージというアイデアはまったく好きになれない。プロトコルに必要ないものだから、うまく収まる場所を見つけるのは難しいと思う。ただ、自分はプログラマーではないが。サトシの意見を聞いてみたい。

追記:面白いアイデアを思いついた。数値の精度を小数点以下8桁をはるかに超えて、例えば128桁にまで拡張したとする。

その小数桁を使ってメッセージを符号化するのはどうだろう? このサービスには自然と「手数料」が発生し、プロトコルを何も変更する必要がない。

追記2:いやあ、このアイデアは大好きだ 😊

追記3:128桁も必要ない。間違っていたら教えてほしいが、32桁あれば64文字セットで17文字の非圧縮メッセージを符号化できる。(32*log(10)/log(64) = 7.717)

ShadowOfHarbringer 2010年10月23日18:33 UTC
grondiluの投稿(2010年10月23日18:07 UTC)

このメッセージというアイデアはまったく好きになれない。プロトコルに必要ないものだから、うまく収まる場所を見つけるのは難しいと思う。ただ、自分はプログラマーではないが。サトシの意見を聞いてみたい。

ああ、自分もそれは気になる。

ECDSAはメッセージを暗号化できない。署名のみ可能だ。

全員が見られるように平文メッセージを永続的に記録するのは賢明ではない。いつ事故が起きてもおかしくない。

メッセージシステムを作るなら、ビットコインネットワークと並行する別のシステムにすべきだ。メッセージはブロックチェーンに記録すべきではない。メッセージは、誰からのものかを証明するためにビットコインアドレスの鍵ペアで署名できるだろう。

ShadowOfHarbringer 2010年10月23日19:41 UTC
サトシ・ナカモトの投稿(2010年10月23日19:02 UTC)

ECDSAはメッセージを暗号化できない。署名のみ可能だ。

全員が見られるように平文メッセージを永続的に記録するのは賢明ではない。いつ事故が起きてもおかしくない。

メッセージシステムを作るなら、ビットコインネットワークと並行する別のシステムにすべきだ。メッセージはブロックチェーンに記録すべきではない。メッセージは、誰からのものかを証明するためにビットコインアドレスの鍵ペアで署名できるだろう。

システムの仕組みを正確には理解していなかったようだ。つまりbitcoinと一緒にメッセージを送ると、それも長い間ずっとblock chainに永久保存されることになる。

あなたの言う通りだな、satoshi。

MoonShadow 2010年10月24日04:29 UTC
ShadowOfHarbringerの投稿(2010年10月23日15:11 UTC)

Bitcoinは素晴らしいが、通常の銀行振込にはあってBitcoinにないものが一つある:振込名義だ。

もしかしたら短いメッセージを含められるようにすべきかもしれない(メッセージは公開鍵/秘密鍵で暗号化して、受信者だけが内容を見られるようにすればいい)。

どう思う?

追伸:間違っているかもしれないが、メッセージはハッシュ処理のランダム性を高めるためにも使えるのではないだろうか? もし違うなら気にしないでくれ。

これは暗号化されたjabberやメール、その他のさまざまな方法を使って外部で行うこともできる。特定のトランザクションに関連付けられたメッセージの送信を許可するために必要なのは、トランザクションの合計値を生成して短いメッセージに貼り付け、その後ろに短いメッセージを平文または公開鍵暗号などの合意された暗号化方式で続け、最後にそのトランザクションの署名に使ったのと同じBitcoinキーで署名するだけだ。このメッセージは任意の方法で受信者へ送ることができ、ブロックの中に含まれることは決してない。しかし検証可能であり、トランザクションが受信者にどう届くかに関係なく、特定のトランザクションと確定的に関連付けることができる。

FreeMoney 2010年10月24日06:02 UTC
ShadowOfHarbringerの投稿(2010年10月23日15:45 UTC)
grondiluの投稿(2010年10月23日15:28 UTC)

支払いラベルは必要ない。

たしかに「必要ない」が、人々にとって便利ではあるはずだ。

何らかの理由でひとつのBTCアドレスを使い続けたい人もいるだろう。 それに大きな金融機関は、トランザクションごとに別の口座番号を使うという考えをあまり好まないだろう。

それを「取引番号」と呼べば、毎回違うものでなければならないと言い張るだろう。

ByteCoin 2010年10月24日20:53 UTC
サトシ・ナカモトの投稿(2010年10月23日19:02 UTC)

全員が見られるように平文メッセージを永続的に記録するのは賢明ではない。いつ事故が起きてもおかしくない。

どんな悪影響が出ると予想しているのかな?

これはECDSAのブロードバンドサブチャネルのおかげで、現行のシステムでもある程度可能だ。

私はブロックチェーン全体を覚えておく必要のないフルクライアントの実装をサポートするため、blockchain上に任意の情報を分散させる方法を探していた。http://bitcointalk.org/index.php?topic=505.0を見てくれ ― “Balance Sheets” についてのスレッドだ。 データをエンコードする素朴なやり方は、いくつものアドレスへ送金して、たとえば受信アドレスの最初の数バイトを調べることでデータをデコードする方法だが、これは比較的少ないデータを送るのに多数のトランザクションが必要となり、帯域の無駄が大きい。

DSAの興味深い性質として、32バイトのメッセージに署名しようとすると、各署名は64バイトの長さになる。つまり署名には、何もないところから生み出された32バイトの情報が含まれているということだ。アルゴリズムを調べてみるといいhttp://en.wikipedia.org/wiki/Digital_Signature_Algorithm。この情報はランダムパラメーターkから来ている。署名はg^kという数と、kとg^kの両方を含む別の式とのペアで構成される。もしg^kが自分のデータを含むようにkを選べるなら、blockchainに巨大な塊で平文データを含めることができる。(不)幸にも、これを行うのは困難でなければならない。さもなければECDSAは安全ではないということになる。

しかし、もし実質的に秘密鍵を公開すれば、誰でも簡単な代数を使って、その鍵で署名されたすべての署名に使われたk値を復元できる。これに気づいたのは私が最初ではない。http://en.wikipedia.org/wiki/Subliminal_channelsを見てくれ。 その鍵に関連付けられた金をすべて使い切っていれば、もうその鍵はどうでもよくなる。(もちろん誰かがその鍵にさらに金を送れば、みんなが先を争ってそれを使おうとするだろう!)だから、何日でも何か月でも普通のトランザクションに大量のデータをエンコードしておき、その後で実質的に秘密鍵を公開すれば(そのためのエレガントな方法がある)、すべてのデータが丸見えになる。

もちろん私の “balance sheet” スキームは、この問題(もし問題だとすれば)にそれほど悩まされない 😉

ByteCoin