Bitcoin overlay protocols

[Hal]

In discussion on the BitDNS thread I came up with an idea for overlaying other protocols onto Bitcoin. From one point of view, Bitcoin is a global, decentralized, yet consistent database. This DB is used to record transfers of coins, but it could potentially be used for more. There are many applications for a global consistent database.

Borrowing from my BitDNS description, the way this would work is we would use the mysterious and extravagant "scripting" system to add additional data to regular Bitcoin transactions. These would look like NOPs to current clients and be ignored, but overlay aware clients would look inside this NOP block and see the extra protocol-specific data, and interpret it according to the overlay protocol.

Specifically i could imagine using OP_NOP1 to signal overlay data, then OP_PUSHDATA to push the specific data, then OP_DROP to drop it from the stack, followed by the regular tx opcodes. This will have no effect on regular clients and look like a regular transaction (can be a dummy tx, 0.01 to yourself) but overlay aware code sees a protocol transaction.

As an example, Bitcoin could be used as an inexpensive timestamp service, allowing you to prove that a certain document existed on or before a certain date. All you need to do is create a dummy transaction to yourself, and hack the client to do an OP_PUSHDATA of the hash of the document, then OP_DROP it. The hash will be around for all time in the block chain and stand as proof that the document existed at that date.

[1713269672]

1713269672

[1713269672]

1713269672

[1713269672]

1713269672

[1713269672]

1713269672

[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 <transaction data>" OP_DROP ...

[RHorning]

My largest concern is turning the Bitcoin transaction database into a more generic database for things completely unrelated to transactions.  In other words, I think stuff which isn't a transaction ought to be strongly encouraged to have a completely separate database for that information.  Perhaps a reference to that other database, but we shouldn't by design shove things into bitcoin transactions like jpeg binaries or Wikileaks documents.  Not only is that a waste of bandwith and storage space, it ultimately does more harm than good for Bitcoin as a piece of software on a whole bunch of levels.

It isn't that we can't, because such data can be put into a Bitcoin transaction.  I'm suggesting we shouldn't.

I should note that one possible "savior" to keep this from happening is that there is a transaction fee for large data dumps... as it should be.  Of course that is only going to drive up transaction costs if that happens regularly too and crowd out transactions for pure monetary exchange.

I've seen Twitter used as a file system, so I suppose this would be no different.  Any arbitrary limits could be compensated with through multiple transactions, but I think there ought to be another way to get that accomplished if that was a goal.

Perhaps for the BitDNS the data payload would be small.  If so, that wouldn't be the end of the world but other projects would also be dumping data into Bitcoin data as well and any single project would find that they are fighting an uphill battle.

BTW, I also agree with theymos so far as when the block chain for Bitcoins is huge that it would make the ability to implement a good DNS server much more difficult and something you likely wouldn't be hosting on a small computer.  This also seems like a strong argument to have a separated database.

[Hal]

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?

[theymos]

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_CHECKSIG

And I add some extra data to it:

Code:

"BitDNS v0001 asdf" OP_DROP OP_DUP OP_HASH160 43716564ed4d679067da12bee139fd294c1f1b84 OP_EQUALVERIFY OP_CHECKSIG

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.

[Anonymous]

I think a separate block chain should be formed for different services. The idea of polluting the financial transactions with an overhang of porn doesnt seem wise 

Speaking of twitter fs I actually looked into that as a way of possibly sending a wallet.dat file to another twitter user. It might be a way to hide in plain sight .

[Hal]

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?

[theymos]

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?

The client doesn't know how to solve the transaction's scriptPubKey. It can evaluate a complete scriptSig+scriptPubKey, but it can't produce a matching scriptSig for a strange scriptPubKey because it doesn't recognize the scriptPubKey's template. A patched client can solve the transaction. An unpatched client won't even recognize a non-standard transaction as its own when scanning the block chain.

If a client is sending strange transactions, then the receiving client also needs to be modified to receive them. If that's the case, then there's no problem.

[Hal]

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.

[theymos]

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.

Interesting idea. You don't need to convert it to an address -- Bitcoin deals with plain hashes internally, so you can just use the hash output. (Of course, using an address makes it possible to use existing versions of Bitcoin as a generic timestamp server.)

It might be better for the network to use OP_DROP. It is provable that "<constant> OP_DROP" is irrelevant information, so later versions of Bitcoin might allow people to delete that part of transactions to save space.

[grondilu]

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.

This is a highly important post, imo.  Thanks.

When I first red Satoshi's design paper, I immediately thought that there would be something very useful with this concept of a distributed time server.  However, I wasn't quite able to see exactly what it would be.

I think you've pined it.

Say I'm an artist and I've just created something that holds into a file.  In order to protect the paternity of my work, signing is not enough.  Because anyone could sign a copy of the unsigned file.  Therefore I have to find a way to prove that I've been the first one who signed this document.

Bitcoin can allow me to do this, just as you described it.  I sign my file.  I turn the hash of the signed document into a bitcoin address, and I send a small amount to this address.

I think this could have a huge impact on artistic creation.