By the way, IBMs trusted computing system is pretty much a dead end these days, it's very hard to obtain the hardware. It was never that good anyway, you had to sign consulting contracts to get the SDKs and other things. Intel/AMD have a much better system and I think x86 PC based remote attestation is the way to go for a lot of reasons. See the XMHF project (trustvisor).
The Intel/AMD stuff isn't secure though yet. While the IBM stuff really does bring the security to the level where your attackers need immense resources, because memory isn't encrypted PC-based trusted computing is still vulnerable to attackers with just a few thousand dollars worth of equipment. There is pressure to make the PC stuff secure for cloud computing, so it remains an open question what is the right approach.
Anyway, implementing trusted computing is the last step for any of this stuff; I don't want to have to solely rely on it.
Could you run a Chaum bank on the darknet? I don't think so. Even if the bank has put up a fidelity bond, the temptation to engage in fractional reserve banking would be immense, and could result in a lot of profit before the inevitable bank run. You can't really tell if this is happening because the coins you deposit are expected to be constantly moving as other people cash out their blinded tokens. I don't fully understand the time locking proposal for this reason - the blinded tokens only have value if you can turn them back into Bitcoins again, and that inherently means that your deposit can't be frozen or locked in any way.
Who says banks can engage in fractional reserve banking? You can force chaum-token redemption to be recorded in audit logs, and those logs prevent them from getting away with that. The logs themselves can be made public, and making them public still doesn't reveal anything.
Incidentally, this is why I mentioned above that there are probably good technical reasons why even off-chian chuam transactions would still require fees: you want to ensure that proving fraud is cheap, which means keeping the size of the proofs down. I expect that there would be some period in which all tokens are expected to be turned over for a given set of deposit addresses, which limits the total size of any given audit log. Because fidelity bonds themselves are only useful if fraud can be proven, I expect new bonds to get purchased over time to "start fresh".
As for time locking: I expect the tokens to themselves be Bitcoin transactions in some fashion, albeit locked so they can't be used immediately. But that discussion is out of the scope of this forum I think; I'm writing up tech specs like I did for fidelity bonds.
From a first glance, this proposal sounds very similar to what the OpenTransactions project has implemented. (see the highlighted parts above)
OpenTransactions is basically a toolkit, and yes, I do plan to do more work studying it to determine what aspects of their ideas are applicable to fidelity-bonded banks, and equally maybe they're do the same for fidelity bonds.
Aha, can you walk me through what you think ten years ago would look like? Let's say
the year 2000:
Quote:
I bought a new Gateway desktop in 2000 It had windows ME.
10 GB hard drive, 860 processor. Also at that time I was on dial up.
Boy, you talk about speed. I didn't have it.Small hard-drives were a huge issue 10 years ago. I can't see people buying multiple harddrives, just to experiment with this new-fangled "Bitcoin thing" The block size would have probably been set to something more like 100KiB, and a year or two in this exactly discussion would already be happening.
