(theymosの引用投稿)
場合によってはそれが適切かもしれない。Bitcoinでは、軽量クライアントが各ブロックの80バイトのブロックヘッダーだけをダウンロードしてもトランザクションを安全に検証できるが、これはネットワークがブロックに含める前にトランザクションを検証しているからこそ可能だ。ネットワークはオーバーレイトランザクションを検証できないので、オーバーレイクライアントはブロックチェーン全体をダウンロードする必要がある。ブロックチェーンが1,000,000ブロックに達し、BitDNSを使うために1TB以上のデータをダウンロードしなければならなくなると、これは問題になる。
より軽微な問題として、これらのトランザクションに関連付けられたBitcoinが使用不能になる。トランザクションが使用されると、ネットワークはそれを忘れることが許されるので、その中のデータを存続させたい限りトランザクションを未使用のまま保持しなければならない。また、Bitcoinクライアントは非標準のトランザクションを認識しない。改造されていないクライアントを使っている相手にこれらのトランザクションを送ると、単に無視される。
OP_NOP1をフラグとして使う必要はない。こうすればよい:
“BitDNSv0001
Quote from: theymos on December 04, 2010, 11:02:56 PM
また、Bitcoinクライアントは非標準トランザクションを認識しない。これらのトランザクションを改造されたクライアントを使っていない相手に送ると、単に無視される。
コメントありがとう。確認だが、OP_PUSHDATAやOP_DROPなどを含むトランザクションは現在のクライアントに拒否されるということか?
Quote from: Hal on December 05, 2010, 12:29:31 AM
コメントありがとう。確認だが、OP_PUSHDATAやOP_DROPなどを含むトランザクションは現在のクライアントに拒否されるということか?
ネットワークには拒否されないが、2つの標準トランザクションと少しでも異なるトランザクションは標準クライアントでは受信できない。
例えば、179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uBへの標準トランザクションを取ると: Code:OP_DUP OP_HASH160 43716564ed4d679067da12bee139fd294c1f1b84 OP_EQUALVERIFY OP_CHECKSIGこれに追加データを加えると: Code:“BitDNS v0001 asdf” OP_DROP OP_DUP OP_HASH160 43716564ed4d679067da12bee139fd294c1f1b84 OP_EQUALVERIFY OP_CHECKSIG179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uBは、その変更されたトランザクションの読み方を知らないため、クライアント上で私のトランザクションを見ることすらできない。ただし、ブロックチェーンには残る。
Quote from: theymos on December 05, 2010, 12:39:54 AM
179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uBは、その変更されたトランザクションを読む方法を知らないため、自分のクライアントでそのトランザクションを見ることすらできない。ただし、ブロックチェーンにはまだ存在する。
ありがとう。これは単にトランザクション表示のUIの問題なのか、それともクライアントが価値の移転をまったく認識しないのか? もしそのアドレス179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uBがその値を使おうとした場合(クライアントがパッチされてそれを許可するとして)、そのトランザクションは有効として受け入れられるのか?
上で述べたタイムスタンプの概念を実装する簡単な方法を思いついた。タイムスタンプしたいファイルに対してsha1sumを実行する。結果をBitcoinアドレスに変換する(例えば http://blockexplorer.com/q/hashtoaddress 経由で)。そしてそのアドレスに少額の支払いを送る。
お金は永遠に失われる。さらに使う方法がないからだ。しかしタイムスタンプのBitcoinアドレスはブロックチェーンにファイルの存在の記録として残り続ける。
これはBitcoin分散データベースの良い使い方とは言えないかもしれないが、人々がこれを行うことを止めるものはないので、行われる可能性があることを認識すべきだ。