Paypal tells me that the way to get verified is to link my bank account. How would I use a VCC number to get verified? I already have a CC linked.

I came up with an even more extravagant estimate of $10 million a couple years ago on the cryptography list:

http://www.mail-archive.com/cryptography@metzdowd.com/msg10152.html

I compared the stock of bitcoins to total worldwide wealth, rather than GWP, which is the amount produced in one year.

What I meant about purchases taking longer would be in the range of several hundred to several thousand dollars. Today you can go into Best Buy and get a new TV for $1000, put it on your VISA and walk out. For a Bitcoin transaction in this range, the seller would probably want to wait for 2 or 3 confirmations to be safe against double spending, which would take 20-30 minutes. That's pretty inconvenient.

Doesn't the client check with multiple connected peers to make sure it has the latest block? Maybe there could be a window that displays all connected peers and the latest info from each. Then you could check that they all agree about chain length, etc.

Actually there is a very good reason for Bitcoin-backed banks to exist, issuing their own digital cash currency, redeemable for bitcoins. Bitcoin itself cannot scale to have every single financial transaction in the world be broadcast to everyone and included in the block chain. There needs to be a secondary level of payment systems which is lighter weight and more efficient. Likewise, the time needed for Bitcoin transactions to finalize will be impractical for medium to large value purchases.

Bitcoin backed banks will solve these problems. They can work like banks did before nationalization of currency. Different banks can have different policies, some more aggressive, some more conservative. Some would be fractional reserve while others may be 100% Bitcoin backed. Interest rates may vary. Cash from some banks may trade at a discount to that from others.

George Selgin has worked out the theory of competitive free banking in detail, and he argues that such a system would be stable, inflation resistant and self-regulating.

I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash. Most Bitcoin transactions will occur between banks, to settle net transfers. Bitcoin transactions by private individuals will be as rare as... well, as Bitcoin based purchases are today.

Thanks! I'm enjoying the countdown to 100,000. Looks like it might not happen until the 29th, but it'll be soon.

Actually you can't go to prison for not paying your taxes (in the US at least). There are no longer debtors' prisons. You can go to prison for not filing accurate tax forms, but not for failing to pay. The IRS may take away your income and possessions, you may be forced out on the street, but you will not go to prison.

Well there wasn't much interest in the bet, that's fine. Looks like Christmas was a little optimistic anyway. By my calculations, at current rates block 100,000 should show up in about 6 days, 2 1/2 hours, or about 10:30 PM UT on Dec 28.

That's what EFF did for accepting donations. See http://www.eff.org/helpout, about 12-15 lines down the page.

I see Bitcoin as ultimately becoming a reserve currency for banks, playing much the same role as gold did in the early days of banking. Banks could issue digital cash with greater anonymity and lighter weight, more efficient transactions.

Instead of a file as input, use the hash of a domain name, and you have a quick-n-dirty system for claiming ownership permanently (the name belongs to the key making the payment). Then as suggested in the BitDNS thread, use any common DHT implementation to broadcast the signed DNS records.

Would it be that hard for external miners to do the extra compare, and only return solutions that actually work? I hate to see too many special-case switches.

I'd predict that difficulty will stop rising once it becomes impossible to mine at a profit. Based on ribuck's figures, we're pretty much there if you account for GPU prices, and maybe a factor of 4 away even for people who only count electricity (because they use their cards for gaming etc). So unless the price of bitcoins rises, I expect difficulty to start leveling off soon.

I got sued back in the 90s over some messages sent via an anonymous remailer I ran. The EFF was an enormous help, found me a lawyer who worked pro bono. I really owe them.

"To implement this simply requires adding one new field to each transaction, the 'name' (or hash) of the 'stock' being transferred."

In the case of DNS this still leaves the problem of discovering where in the world are your DNS records hosted. I think you need one more piece of data, the IP addresses of your authoritative DNS name servers.

I'm unclear on who gets to register new names in your scheme, how much they have to pay, and who receives thevpayment. Also, are name registrations permanent and forever?

"1.c.   Codified verification that can rigorously check if a transaction is valid or not for that particular template."

Would this be codified by an extended scripting language, or by hard-coded logic in the client? I think it has to be a scripting language, otherwise it will be too hard to get agreement to add new templates. We would need to create scripting extensions to allow a wide range of new applications. For BitDNS we would need the ability to look back in the block chain and check if a given name has been registered before.

"3.   Every transaction must still comply with the existing enforced network rules. Such as no, double spending."

With the kinds of scripting extensions I anticipate, we could actually replace all these implicit, hard-coded Bitcoin rules with explicit scripted tests. The same kind of script that could test that a new BitDNS name had not been registered before, could be used to test that a Bitcoin transaction wasn't a double-spend.

There might be some  template applications where the double-spending rules don't make sense. Some of the BitDNS proposals don't do true Bitcoin transactions at all, they piggyback extra data on top of a dummy Bitcoin transaction where you just pay yourself. It would be nice to remove this unnecessary part.

In this view, the core logic of Bitcoin would check that blocks had the required difficulty, were properly formatted, and that their scripts all return true. Everything else would be done by application-specific layers.

I wonder if it would work to put a (possibly salted?) hash of the name into the block rather than the name itself? Then it would not be obvious what name is being registered, but you could still lookup registrations by name. This would not be perfectly secure, short names could be found from hashes by brute force, but it would make front-running much harder.

I thought of a possible problem with all these proposals: front-running by miners. This is where a miner sees an attempt to register a name, thinks it is a good name, and registers it for himself instead. Since domain registration fees are based on the value of average names, extra-good names wouldn't be covered by the fees and might be stolen in this way. Some existing registrars have been accused of a similar practice, registering names through agents after people query for name availability.

Seems like everyone's tugging in a different direction. Here are some of the specific issues:

1. Bitcoin main chain vs start a new chain, with DCCs ("DomainChain coins").

2. Permanent name registration vs renewal necessary.

3. Support for an unlimited family of applications vs just focus on DNS.

4. DNS "gateway" servers setting minimum transaction fees vs burning a DCC to register a domain.

5. Include in the block chain, in addition to domain name: just ownership public key, vs ownership public key plus authoritative DNS server IP addresses, vs arbitrary DNS records.

6. Single TLD .web or .p2p, etc., vs "advisory" TLDs which may be ignored, versus all TLDs being allowed in names.

Any other issues/design choices which can be factored out?

As a relative newbie to the code, I do find your version easier to read. It's easier to find the implementations of functions since most are class members and are now in named .cpp files. It's also nice to have the full class implementation in one place rather than having to flip back and forth between .h and .cpp files.

However that is for reading, and the needs of developers may be somewhat different. Obviously Satoshi knows the current layout intimately, and as the main developer it is up to him to see whether he could work with the new layout.

One concern I'd have with losing the inlinable .h functions is whether it could slow down either initial block load/verify/indexing, or mining (a bit moot with gpu miners these days).