バージョン0.3.18

11 件のメッセージ BitcoinTalk Theymos, サトシ・ナカモト, nanotube, chaord, da2ce7, sturle, ShadowOfHarbringer, ギャビン・アンドレセン 2010年12月5日 — 2010年12月9日

Quote from: Hal on December 05, 2010, 02:22:21 AM

ああ、ありがとう。これは取引の表示に関するUI上の問題だけなのか、それともクライアントが価値の移転をまったく認識しないのか? そのアドレス179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uBがその価値を使おうとした場合(クライアントがそれを許可するようパッチされていると仮定して)、その取引は有効として受け入れられるだろうか?

クライアントは取引のscriptPubKeyの解き方を知らない。完全なscriptSig+scriptPubKeyを評価することはできるが、scriptPubKeyのテンプレートを認識しないため、奇妙なscriptPubKeyに一致するscriptSigを生成できない。パッチされたクライアントなら取引を解ける。パッチされていないクライアントは、ブロックチェーンをスキャンする際に非標準の取引を自分のものとして認識すらしない。

クライアントが奇妙な取引を送信する場合、受信側クライアントもそれを受信するように変更する必要がある。その場合は問題ない。

Quote from: Hal on December 05, 2010, 11:43:56 PM

上で述べたタイムスタンプの概念を実装する簡単な方法を思いついた。タイムスタンプしたいファイルに対してsha1sumを実行する。結果をBitcoinアドレスに変換する(例えば http://blockexplorer.com/q/hashtoaddress 経由で)。そしてそのアドレスに少額の支払いを送る。

お金は永遠に失われる。さらに使う方法がないからだ。しかしタイムスタンプのBitcoinアドレスはブロックチェーンにファイルの存在の記録として残り続ける。

これはBitcoin分散データベースの良い使い方とは言えないかもしれないが、人々がこれを行うことを止めるものはないので、行われる可能性があることを認識すべきだ。

興味深いアイデアだ。アドレスに変換する必要はない——Bitcoinは内部的にプレーンハッシュを扱うので、ハッシュ出力をそのまま使える。(もちろん、アドレスを使えば既存のBitcoinバージョンを汎用タイムスタンプサーバーとして使える。)

ネットワークにとっては OP_DROPを使う方がいいかもしれない。「<定数> OP_DROP」は無関係な情報であることが証明可能なので、Bitcoinの将来のバージョンではスペースを節約するためにその部分の取引の削除を許可するかもしれない。

変更点:

  • 0.3.17からダウングレードして再びアップグレードした場合のwallet.dat互換性問題を修正
  • ブロックに既知のトランザクションタイプのみを含めるIsStandard()チェック
  • 初回ブロックダウンロードを少し高速化するJgarzikの最適化

このリリースの主な追加は、Gavinが取り組んできたアカウントベースのJSON-RPCコマンドです(詳細はhttp://bitcointalk.org/index.php?topic=1886.0)。

  • getaccountaddress
  • sendfrom
  • move
  • getbalance
  • listtransactions

ダウンロード: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/

nanotube 2010年12月9日 原文 · 個別ページ

Bitcoinのブロックチェーンにデータをエンコードすることは、取引を特別に作成するだけですでに可能であることも考慮してほしい。

あるいは、タイムスタンプと支出の証明(つまり手数料付きの通常の取引)のみを使い、実際のデータストレージは外部サービスに押し出すこともできる。

しかし、取引に64バイトか128バイトのランダムデータを許可するだけで全員が楽になるのではないか? これらのBitcoinのサイドバンド利用は、マイニングインセンティブを増やしネットワークのセキュリティを高めることで、ネットワーク全体としてのみ有益だろう。

chaord 2010年12月9日 原文 · 個別ページ

Quote from: nanotube on December 09, 2010, 06:19:05 AM

Bitcoinのブロックチェーンにデータをエンコードすることは、取引を特別に作成するだけですでに可能であることも考慮してほしい。

あるいは、タイムスタンプと支出の証明(つまり手数料付きの通常の取引)のみを使い、実際のデータストレージは外部サービスに押し出すこともできる。

しかし、取引に64バイトか128バイトのランダムデータを許可するだけで全員が楽になるのではないか? これらのBitcoinのサイドバンド利用は、マイニングインセンティブを増やしネットワークのセキュリティを高めることで、ネットワーク全体としてのみ有益だろう。

個人的にはnanotubeの意見に同意する。特に、やる気があれば標準的なトランザクションに任意のデータをすでに偽装できるという事実を考慮すると。ソースコードは見ていないが、理解している限りでは、はるかに心地よい(政治的にも技術的にも)解決策は次のようなものだろう:

デフォルトで、128バイト(または合意できる閾値)を超える非標準トランザクションを禁止する?

上記のオプションがなぜ開発者に却下されたのか聞きたい。

Bitcoinトランザクション自体がブロックチェーンの主要な用途であるべきだという点には同意するが、良い通貨は自らを孤立させる必要もない。

da2ce7 2010年12月9日 原文 · 個別ページ

法則を提案する:

「チェーンを作った者が、その見た目を決める権利がある」

sturle 2010年12月9日 原文 · 個別ページ

Quote from: da2ce7 on December 09, 2010, 10:07:38 AM

法則を提案する:

「チェーンを作った者が、その見た目を決める権利がある」

これと組み合わせれば機能する: 「誰もがブロックを受け入れるか破棄するかを選べる」

ジャンクだらけのブロックで全員がスパムされるのは望まないので、ジャンクを含まない競合するブロックを生成して無効化を試みたい。もちろんジャンクは最終的には入るが、マイナーの大多数がスパムフィルターをオンにしない限り。

この件についてはサトシを完全に支持する。

Bitcoinチェーンにデータを保存する可能性を残すことは、災害が起こるのを待っているようなものだ。誰かが児童ポルノをチェーンにエンコードするのを待つだけだ——それは永遠にそこに残る。そして政府はそれと戦うための完璧なプロパガンダの機会を得る。「普通の」人々は、変質者、マフィア、金融詐欺と関連付けられるなら、Bitcoinをまったく使わないだろう。

新しいトランザクションテンプレートは必要に応じて追加できる。数日以内に、それを受け入れて処理するGPUパワーが十分にあるだろう。ネットワークのサポートは、新しいトランザクションの受信と解釈の方法を理解するクライアントが十分に揃うよりもはるかに前に完全なものになる。

タイムスタンプハッシュはすでに可能だ:

txin: 0.01
txout: 0.00 <appid, hash> OP_CHECKSIG
fee: 0.01

BitDNSのような実際のアプリケーションが実際にハッシュの挿入を開始する準備ができたら、タイムスタンプ用の特定のトランザクションテンプレートをいつでも追加できる。

Hal Finneyのユーザーフレンドリーなタイムスタンプのアイデアが気に入っている。ファイルのハッシュをビットコインアドレスに変換して0.01を送信する:

Quote from: Hal on December 05, 2010, 11:43:56 PM

上で述べたタイムスタンプの概念を実装するシンプルな方法を思いつきました。タイムスタンプを付けたいファイルにsha1sumを実行します。結果をhttp://blockexplorer.com/q/hashtoaddressなどを通じてビットコインアドレスに変換します。そしてそのアドレスに少額を送金します。

そのお金は永遠に失われます。それ以上使う方法がないからです。しかしタイムスタンプのビットコインアドレスは、ファイルの存在の記録としてブロックチェーンに残り続けます。

これはビットコインの分散データベースの良い使い方とは言えないかもしれませんが、人々がこれを行うのを止めることはできないので、行われる可能性があることを認識しておくべきです。

数ヶ月前、0.3.9のバグが発見された頃、受け入れ可能な取引タイプのホワイトリスト化の方が、問題を引き起こすことがわかった取引タイプのブラックリスト化よりも良い方法だとサトシに個人的に伝えた。

ユーザーが入力したHTMLの

受け入れ可能な取引タイプのホワイトリスト化が正しいことだと今でも確信している。

「開発者によって却下された」については——何も却下されていない! まだサトシと話していないが、任意の追加データを含む第三の「標準」取引タイプのアイデアには前向きだ。その議論を行い、-testnetで実装し、突いてみて、悪用される可能性のあるあらゆる方法を想像してみて、利益とコストを見積もり……一般的なコンセンサスがそれが良いアイデアだと判断されれば、本番環境に展開しよう。

新しいトランザクションタイプをいかに素早く追加できるかに気づいた時、ホワイトリスト方式についてGavinと同じ考えに至った。

Quote from: nanotube on December 09, 2010, 06:19:05 AM

Bitcoinのブロックチェーンにデータをエンコードすることは、取引を特別に作成するだけですでに可能であることも考慮してほしい。

あるいは、タイムスタンプと支出の証明(つまり手数料付きの通常の取引)のみを使い、実際のデータストレージは外部サービスに押し出すこともできる。

しかし、取引に64バイトか128バイトのランダムデータを許可するだけで全員が楽になるのではないか? これらのBitcoinのサイドバンド利用は、マイニングインセンティブを増やしネットワークのセキュリティを高めることで、ネットワーク全体としてのみ有益だろう。

それはすでに可能だ。 OP_CHECKSIG。は33〜120バイトにできる。

タイムスタンプハッシュサイズの任意データ用の第3のトランザクションタイプもサポートする。すでにできるのだから、持たない理由はない。ノードにインデックスを作成する必要がないことを伝えることになる。