(quoted post by theymos)
That might be suitable in some cases. With Bitcoin, lightweight clients can download just the 80-byte block headers for each block and still securely verify transactions, but this is only possible because the network verifies transactions before including them in blocks. The network can’t verify overlay transactions, so overlay clients will have to download the entire block chain. This will become a problem when the block chain is 1,000,000 blocks long and you have to download 1+ TB of data to use BitDNS.
A more minor problem is that the bitcoins associated with these transactions become unusable. If the transaction is spent, the network is allowed to forget about it, so you must keep the transaction unspent for as long as you need the data within it to stay alive. Also, Bitcoin clients will not recognize non-standard transactions. If you send one of these transactions to someone not using a modified client, they will just ignore it.
It’s unnecessary to use OP_NOP1 as a flag. Just say:
“BitDNSv0001
Quote from: theymos on December 04, 2010, 11:02:56 PM
Also, Bitcoin clients will not recognize non-standard transactions. If you send one of these transactions to someone not using a modified client, they will just ignore it.
Thanks for the comments. To clarify, do you mean that transactions with OP_PUSHDATA and OP_DROP, etc would be rejected by current clients?
Quote from: Hal on December 05, 2010, 12:29:31 AM
Thanks for the comments. To clarify, do you mean that transactions with OP_PUSHDATA and OP_DROP, etc would be rejected by current clients?
They would not be rejected by the network, but transactions that differ at all from the two standard transactions can’t be received by standard clients.
So if I take a standard transaction to 179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uB: Code:OP_DUP OP_HASH160 43716564ed4d679067da12bee139fd294c1f1b84 OP_EQUALVERIFY OP_CHECKSIGAnd I add some extra data to it: Code:“BitDNS v0001 asdf” OP_DROP OP_DUP OP_HASH160 43716564ed4d679067da12bee139fd294c1f1b84 OP_EQUALVERIFY OP_CHECKSIG179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uB will not even see my transaction in their client because they don’t know how to read that modified transaction. It will still be in the block chain, though.
Quote from: theymos on December 05, 2010, 12:39:54 AM
179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uB will not even see my transaction in their client because they don’t know how to read that modified transaction. It will still be in the block chain, though.
Ah, thanks. Is this just a UI issue with display of transactions, or do the clients not recognize the transfer of value at all? If that address 179c7kVKJNxJN1TJ8EqcFhzXDAkrMqr2uB goes on to spend its value (supposing its client was patched to allow it), would the transaction be accepted as valid?
I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address.
The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file’s existence.
I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done.