Here is an idea for how miners can get paid.

Let us start with a fork of Bitcoin. We will start a new block chain just like Bitcoin did two years ago. There will be coins in this chain, which I will call bitdnscoins. People can pay bitdnscoins to each other via transactions in the BitDNS block chain, just like with Bitcoin. Block miners get 50 bitdnscoins.

However in addition to bitdnscoin transactions there would also be domain name transactions. Here is the main idea: at any time a bitdnscoin can be converted into a new domain name registration via a special transaction. This uses up the bitdnscoin and it can't be used again. There would also be 'maintenance' domain name transactions where an existing domain name is transferred to a new owner or has other data fields changed.

Bitdnscoins represent the right to register a new domain name. They are valuable for this reason. You would acquire them by mining, or more commonly by buying them, with Bitcoins, dollars, etc. To register a new name you need a bitdnscoin.

And the incentive for miners to include transactions? Same as for Bitcoin: transaction fees. Registering a new domain name costs 1 bitdnscoin. But you can pay more, and the excess goes to the miner. Pay 1.2 bitdnscoins for your new domain name, and 0.2 of that goes to any miner who includes your transaction. That's the incentive.

Oh, right. Sorry, and thanks!

Traces on optimized code are unreliable. Can you build without optimization?

Running ./bitcoin.exe -addnode 192.168.1.48 (which is another computer running Bitcoin) produces error: You must set rpcpassword=<password> in the configuration file...

Same error with -connect. I don't have a bitcoin.conf.

Is this right? I'm not interested in rpc, I just want to speed up initial block download.

When I create the file as required, I then get error: couldn't connect to server.

I tried telnet 192.168.1.48 8333 and did make a connection, got back the word 'version and a bunch of gibberish.

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.

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?

Thanks for the comments. To clarify, do you mean that transactions with OP_PUSHDATA and OP_DROP, etc would be rejected by current clients?

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.

I see, that makes sense. I have an idea about the transaction fee. What if this were integrated with Bitcoin itself? This would be a different kind of transaction that would be mixed with regular Bitcoin transactions and included in regular Bitcoin blocks. Then the block creator would automatically receive the transaction fee just like all the other tx fees in the block.

If that sounds good, I see a way this could be implemented into the current Bitcoin system compatibly with current clients. We could 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 BitDNS aware clients would look inside this NOP block and see the extra DNS data, and interpret it as BitDNS transfers.

Specifically i could imagine using OP_NOP1 to mean BitDNS, then OP_PUSHDATA to push the DNS info, 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 BitDNS aware code sees a BitDNS transaction. This is actually a powerful general technique for adding overlay protocols to Bitcoin.

Looking on the bright side, if Bitcoin did get known as the Wikileaks currency, attacked by governments all over the world, at least we'd get our Wikipedia page back!

Let me clarify how I understand the BitDNS idea. First, I think it is somewhat misnamed, as we would not propose to replace the entire decentralized DNS infrastructure of A records, CNAMEs, TTL values, etc. What we want to change is the registrar function, which keeps track of who owns each name.

A domain name entry in this system has 3 parts:

 - the name itself (e.g. example.bitdns)
 - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
 - the IP address of the authoritative DNS server for the name (e.g. 1.2.3.4)

When you generate a block you get to create 50 of these entries, and you then own those 50 names. Of course they have to be new names that were not in earlier blocks.

Subsequently a name might have two things happen to it:
 - the IP address of the DNS server might change
 - it might be transferred to a new owner

Both of these might be handled the same way, via a BitDNS transaction. The transaction would contain:
 - the domain name
 - the new owner key hash
 - the new IP address of the DNS server
And it would be signed by the old owner private key.

As with Bitcoin, transactions would be broadcast and incorporated into the next block by miners.

Is this what people have in mind?

I suspect the first targets if Bitcoin got associated with Wikileaks would not be miners or participants, but the money changers. People buying and selling Bitcoins for dollars and other currencies would be natural targets for shutting down. Without them, Bitcoin is back to being play money.

I've played the Foresight Exchange play-money prediction market at ideosphere.com since 1995. It would be great to see a Bitcoin version. The way it works is you create a "claim", which is a prediction that might or might not come true. Normally these have a due date for when they'll be judged. You also name another player as the judge. The claim creator can bet on the claim but the judge can't.

Once the claim is created people can offer to buy "yes" or "no" shares at prices ranging from 0.00 to 1.00, which can be thought of as the probability that the claim will come true. When a pair of yes and no offering prices match, a pair of shares are created and given to the bidders, while their accounts of FX$ play money are decreased.

At the due date the claim is judged. If it is true, owners of YES shares are payed off at FX$1.00 per share, and if false, owners of NO shares receive similar payoffs.

It's pretty impressive that the game has gone on so long. Many of the claims will not come due for decades into the future. I think this game could be a good model for a real money version based on Bitcoin.

One reason price might follow difficulty is that mining should not be too profitable (because nothing should be too profitable, the world doesn't leave free money lying around). Therefore the price of Bitcoins can't rise too much above the cost of mining (counting equipment depreciation among the costs of course). The cost of mining is proportional to the difficulty (approximately). Therefore we might expect to see price proportional to difficulty.

We do see a nearly proportional relationship in the 1st graph, but that data set was incomplete. I'd like to see that last graph redone with a linear difficulty scale so we could see how the proportionality holds up with more data.