提案：Bitcoin と一緒に短いメッセージを送れるようにしないか？
Bitcoin は素晴らしいが、通常の銀行振込にはあって Bitcoin にないものが一つある：振込名義だ。
各トランザクションに短い（512 バイト以下の）メッセージを含められるようにすべきではないだろうか。 メッセージは公開鍵/秘密鍵で暗号化し、受取人だけが内容を確認できるようにすることもできる。
どう思う？
追伸： 間違っているかもしれないが、メッセージはハッシュ処理のランダム性を高めるためにも使えるのではないだろうか？もし違うなら気にしないでくれ。
興味深いものを見つけた。
http://stackoverflow.com/questions/1138345/best-compression-algorithm-for-short-text-strings
短いテキスト文字列の圧縮に優れた小さな OS プロジェクトが GitHub にある。
http://github.com/antirez/smaz
これで 384 バイトをさらに 200 バイト未満や 175 バイト未満にまで縮小できる可能性がある。
ハッシュ計算にメッセージを考慮する必要があるかどうかも気になる。考慮しなければ、後から削除することも可能になる。
このメッセージというアイデアはあまり好きではない。プロトコルに必要ないものだから、うまく収まる場所を見つけるのは難しいと思う。ただ、自分はプログラマーではないが。サトシの意見を聞いてみたい。
追記：面白いアイデアを思いついた。数値の精度を小数点以下 8 桁をはるかに超えて、例えば 128 桁にまで拡張したとする。
その小数桁を使ってメッセージを符号化するのはどうだろう？このサービスには自然と「手数料」が発生し、プロトコルを何も変更する必要がない。
追記 2：このアイデア、最高だ 😊
追記 3：128 桁も必要ない。間違っていなければ、32 桁あれば 64 文字セットで 17 文字の非圧縮メッセージを符号化できる。（32*log(10)/log(64) = 7.717）
ハッシュ計算にメッセージを考慮する必要があるかどうかも気になる。考慮しなければ、後から削除することも可能になる。
ああ、自分もそれは気になる。
ECDSA はメッセージを暗号化できない。署名のみ可能だ。
全員が見られるように平文メッセージを永続的に記録するのは賢明ではない。事故が起きるのを待っているようなものだ。
メッセージシステムを作るなら、ビットコインネットワークと並行する別のシステムにすべきだ。メッセージはブロックチェーンに記録すべきではない。メッセージは、誰からのものかを証明するためにビットコインアドレスの鍵ペアで署名できるだろう。
ECDSAはメッセージを暗号化できない。署名のみ可能だ。
全員が見られるように平文メッセージを永続的に記録するのは賢明ではない。事故が起きるのを待っているようなものだ。
メッセージシステムを作るなら、ビットコインネットワークと並行する別のシステムにすべきだ。メッセージはブロックチェーンに記録すべきではない。メッセージは、誰からのものかを証明するためにビットコインアドレスの鍵ペアで署名できるだろう。
システムの仕組みを正確には理解していなかったようだ。つまり bitcoin と一緒にメッセージを送ると、それも長い間ずっと block chain に永久保存されることになる。
あなたの言う通りだな、satoshi。
Bitcoinは素晴らしいが、通常の銀行振込にあるものがひとつ欠けている。それは支払いタイトルだ。
もしかしたら短いメッセージを含められるようにすべきかもしれない（メッセージは公開鍵／秘密鍵で暗号化して、受信者だけが内容を見られるようにすればいい）。
どう思う？
追伸：間違っているかもしれないが、メッセージはハッシュ処理のランダム性を高めるためにも使えるのではないだろうか？もし違うなら気にしないでくれ。
これは暗号化された jabber やメール、その他のさまざまな方法を使って外部で行うこともできる。特定のトランザクションに関連付けられたメッセージの送信を許可するために必要なのは、トランザクションの合計値を生成して短いメッセージに貼り付け、その後ろに短いメッセージを平文または公開鍵暗号などの合意された暗号化方式で続け、最後にそのトランザクションの署名に使ったのと同じ Bitcoin キーで署名するだけだ。このメッセージは任意の方法で受信者へ送ることができ、ブロックの中に含まれることは決してない。しかし検証可能であり、トランザクションが受信者にどう届くかに関係なく、特定のトランザクションと確定的に関連付けることができる。
grondiluの投稿（2010年10月23日 15:28 UTC）支払いラベルは必要ない。
たしかに「必要ない」が、人々にとって便利ではあるはずだ。
何らかの理由でひとつのBTCアドレスを使い続けたい人もいるだろう。 それに大きな金融機関は、トランザクションごとに別の口座番号を使うという考えを本当に好まない。
それを「取引番号」と呼んでみろ。連中は毎回違うものでなければならないと言い張るぞ。
全員が見られるように平文メッセージを永続的に記録するのは賢明ではない。事故が起きるのを待っているようなものだ。
どんな悪影響を想定しているのだ？
これは 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