Bitcoin Forum

I wasn't intending to make this so public so soon - I and gmaxwell are still working on the technical details - but given the huge discussion the block-size issue seems to have spawned I think it'd be good to get the idea out in the open to show people we do have options other than just raising the block size, and those options don't have to be centralized.

Overview

Fidelity-bonded banking allows you to send payments instantly, while still preserving your financial privacy. The recipient of the funds doesn't have access to your financial information, such as where the funds came from, and the bank only knows where the funds came from, not where they went. The system ensures that everyone can effectively audit these banks, and if these audits uncover fraud, that fraud can be cryptographically proven to the world.

Trustbits is what I'm calling my particular implementation of the idea.


Sending Money

Lets look at how it works, starting with how you use it to pay someone:

1) The first step is to make a deposit. You send the bank your Bitcoins, and the bank waits until the payment is confirmed.

2) The bank gives you a receipt for your deposit. To preserve your privacy the receipt is made using a cryptographical technique called Chaum Blind Signatures. The way it works is easiest to understand with an analogy:

    a) Write down a very large random number on piece of pressure-sensitive carbon-copy paper.

    b) Now put that piece of paper in an unmarked, envelope and give the sealed envelope to the bank.

    c) The bank now signs the outside of the envelope, and by doing so, they also sign the pressure sensitive paper inside.

The signature is what makes the receipt valuable. The bank will use multiple signatures, and each type of signature designates that the receipt is worth a given number of Bitcoins, kinda like how we use different types of coins, each worth different amounts. A deposit of 11 Bitcoins might get you a receipt worth 10 Bitcoins, and another receipt worth 1 Bitcoin.

3) Give your receipt to the person you want to pay. They then give the receipt to the bank. The bank checks the signature to make sure the receipt is real - if it is the receipient either gets a new receipt of their own, or the bank can transfer them Bitcoins directly.

Regardless of where the funds go the bank adds the number on the receipt to a list of spent receipts; that way the receipt can only be used once. With a really big random number the probability of two people picking the same number can be astronomically small, just like how the probability of two people picking the same secret key for their Bitcoins is astronomically small.


The bank and the receipient don't know where the funds came from, the receipt is just a signature and a random number. At the same time, because the receipt was in the envelope when it was signed, the bank doesn't know what receipt they signed when they accepted the deposit.

Fraud Proofs

For everything the bank does, they've been signing these receipts with their cryptographic identity. These receipts are really promises, and if the bank ever breaks a promise, the software can create a machine-readable proof that the promise was broken, and that proof can be broadcast to the world.

Bitcoin itself relies on the idea that information is easy to copy, but hard to censor. Fraud proofs will be distributed world wide on a censor-proof P2P network, so if a bank ever commits fraud, such as failing to redeem a valid receipt, everyone will immediately know and their software can immediately stop using that bank.


Fidelity Bonds

While the bank will lose future business, we also want to make the bank lose money now. We do this by forcing the bank to purchase a bond before they start their business; if they commit fraud, they lose their bond. Because the banks funds are all publicly known - they're on the blockchain visible to all - every client will never deposit more funds with the bank than the bond is worth. Even if the owner of the bank wants to close the bank down, it's still in their incentive to behave honestly, keep the bond intact, and resell it to someone else.


Trusted Computing

IBM and a few other companies make special computers that supports a feature called Remote Attestation. The hardware itself is made to be nearly tamperproof with special techniques, similar but more advanced than the ones that keep smartcards secure, and inside the hardware is a mechanism by which anyone can ask the hardware what software is running on it. That software can then be carefully audited by security experts.

Now the owner of the bank can't even take your funds; the software keeps the keys to the funds safe, and the hardware makes sure the software can't be changed without everyone knowing. The manufacturer of the hardware can take your funds, but then they would lose the value of the fidelity bond. Finally these special trusted computers are widely used for all sorts of purposes, including many existing banking applications. If, say, IBM ever created a dishonest one it would have huge ramifications beyond just Bitcoin.


So how do Fidelity Bonds work?

Like Bitcoin, the value of a bond is just something we all agree on; also like a Bitcoin the bond is just information in a computer network. What happens is you create one of these bonds by sacrificing, that is throwing away, Bitcoins in a way linked to your cryptographic identity and the promises the bank agrees to uphold. (the contract)

A bond is only considered to be valid if the bank hasn't broken their contract. The moment they do the bond itself hasn't changed, again, it's just information, but it's worthless know. This is kinda like a reputation: Coca-Cola's name doesn't actually change if they put rat poison into their drinks, but their reputation will still be ruined when people find out.


What happens if the bank suddenly shuts down?

Of course, only the bank can give you your Bitcoins back. However Bitcoin itself has a feature called time-locked transactions. This allows the bank to give you a Bitcoin transaction that won't be valid for some time period, perhaps 6 months, that lets you get your deposit with them back. If the bank suddenly shuts down you'll be able to get your money back after that time. Of course, it'd be better to get it back immediately, but this isn't really any different to how the legal system takes a few months to clean up after a bank failure, except in this case whether or not you get your funds back is governed by math rather than humans.


How can I pay someone who doesn't use the same bank as me?

Centralization is a bad thing - we need it to be possible for many different banks to co-exist. Fortunately with fraud proofs and trusted computing it's possible for software to automatically evaluate the trustworthyness of a bank; humans aren't required. Thus when you send money to someone their client software will evaluate if the transfer is valid automatically regardless of which bank you happen to use. Similarly bank-to-bank transfers can happen automatically too, either by issuing receipts to each other, or by creating a regular Bitcoin
transaction to settle their debts.

It'll even be possible for you to operate your own bank, although it's expected that most people will just use banks run by others. The fraud shutdown mechanisms will be very fast and very stringent, so if you want to run a bank yourself you run a high risk of losing your fidelity bond if you don't know what you are doing.


What I need from the community to make this happen

Ok, so I need 5,000BTC for a year, I need a team of five programmers, and...

...no seriously, I don't want any of that stuff. Of course I'd be working on Trustbits with more of my time if I could, but competition is healthy and we shouldn't be putting all our hopes in one particular idea for off-chain transactions any more than we should be putting all our hopes in just raising the block size somehow. There are plenty of smart people around here, maybe you've got a better idea than fidelity-bonded banks that I haven't thought of? Maybe you can do a better job of fidelity-bonded banks than I can? Maybe you know how to somehow make Bitcoin scale anyway? The way I see it, we have 2-3 years before the blocksize becomes a serious issue, and if people start working on off-chain transaction projects now, we'll have plenty of good options by that time.

It's also not just a blocksize issue: off-chain transactions can have a lot of advantages by themselves like instant payments and mathematically proven privacy. Regardless of what happens to the blocksize, alternatives to on-chain transactions are healthy and can provide capabilities that Bitcoin itself can't.

For the "Trusted Computing" part, does the bank operator know the bitcoin address private keys and keep a backup?

The private keys are kept secure by the hardware. They get generated within the hardware, and can't leave unless the software lets them.

Backups are still possible too. In reality you would run, say, 3 or 5 of these trusted hardware computers, and either the software would have a mechanism to send the private keys securely to the backups, or you would use n-of-m multisignature transactions; there are a lot of possible options.

Regardless of the whole block-size issue, which I believe can be easily resolved in the future, I agree that there is definitely a need for off-chain transactions because of their speed and privacy. Any company which would want to use Bitcoin doesn't want the whole world to know how much money they make and who their clients are, so a third party to store your Bitcoins is a great idea. That's why we have banks today. Also, I'd like it very much to receive interest on my bitcoins someday.

Your idea seems sound to me, although I'm not quite satisfied by your answer what would happen in case a bank runs off with your money. The time-locked transactions doesn't seem to be very practical (and isn't this feature disabled because of the zero-confirmation risk?) and someone operating a bank would only have to run away once to a tropical island with your money for you to lose it all. Having said that, it seems to me that your idea could be a perfect blueprint for a serious commercial bank to offer Bitcoin-related services.

Time-locked transactions are not disabled. What is disabled is broadcasting such a transaction over the Bitcoin network when it's still locked. When you transaction reaches it's unlocked time, you're free to broadcast it. Don't get me wrong, it'd suck to have to wait 6 months to get your money back, but the big advantage is if the bank is using, say, trusted computers and they screw up and all the computers (and their backups) stop working, you can still get the money back. (note that part of the bank's contract with you can be that they pay for the fees involved in getting those tx's confirmed if they screw up)

It's the same thing with the "bank runs off with the money scenario" Unlike an on-chain transaction, you can only make it unprofitable because they lose their bond, and because breaking into trusted computers is extremely expensive; the security of the best IBM cryptocard's is rated in terms of how many hundreds of thousands to millions of dollars it would take to hack into one, and that only lets you compromise one bank, not all of them. It's also the same technology that was developed to keep nuclear weapons secure. Finally breaking into one of those trusted computers also takes a lot of time and physical access, so if your time-locked transaction gives you the money back before the attacker succeeds, they haven't gotten anything out of all their hard effort.

The receiver still has to validate the received funds with the bank, so it isn't really offline? Only in the sense that no bitcoin block network/blockchain is needed.

Edit: sorry, my bad, misread the title as "offline" instead of "off-chain".

I'm glad to see people thinking of innovations!

I haven't wrapped my head around this, so I'm not sure if it's a great idea yet, but I'm also glad people are in favor of off-chain transaction options. I posted (https://bitcointalk.org/index.php?topic=145072.msg1540470#msg1540470) in one of the block size issue threads about Bitcoin Clearing Houses to facilitate such transfers.

The obvious benefits are instant transfers, zero or low fees (revenue could be ad or features supported), and of course awesome scalability.

I note this doesn't centralize things because there is no power to create coins or prevent their transfer as users could revert to the core network. Someone posted skeptically about creating a target for authorities, saying exchanges are a bit of a weak point, but that's not a worry as I see it. The reason Bitcoin exchanges are vulnerable is they convert traditional system currency into bitcoins. With a clearing house everything is digital, and clearing servers could be hosted anywhere in the world.

One question I have about the Fidelity-bonded banks is what is the profit model?

Absolutely. They're off-chain, not offline.

In fact you have to remember that to be fully audit the bank you need to be running a fully validating node monitoring the blockchain and the transactions coming over the network. This is a big part of why I'm so against increasing the blocksize limit.


Transaction fees probably. Where you might pay, say, $2 or even $20/tx for an on-chain transaction, a fidelity-bonded bank could be a penny or two to cover server costs.

The real cost is the time-value of money implied by the fidelity bonds, so banks with the biggest bonds will have to charge more based on the value of that money. For a bank backed 100%, that's probably around 5%/year on your deposits,(1) so I expect people would continue to maintain most of their funds on-chain, and only keep a portion of their savings deposited with banks. Equally if the trusted hardware idea turns out to be secure, the banks don't need to hold fidelity bonds as large.

There also appear to be ways for the Bitcoin network itself to allow you access to your funds, without the banks involvement, but exactly how that might work is still something myself and gmaxwell are thinking about. Essentially you would have the option of redeeming your deposit immediately, and Bitcoin would process that directly. Quite possibly the rules could make those redemptions always have priority over attempts by the bank to move the money elsewhere for any other reason.

1) Remember that the fidelity bonds are denominated in Bitcoins, so changes in the price of Bitcoins don't affect the time-value-of-money implied.

Obviously the bank could charge transaction fee, for bitcoin deposit, bitcoin withdrawal, and internal transfer.

Ah. I read the following too quickly and thought it mentioned zero fees:

It's also not just a blocksize issue: off-chain transactions can have a lot of advantages by themselves like instant payments and mathematically proven privacy. Regardless of what happens to the blocksize, alternatives to on-chain transactions are healthy and can provide capabilities that Bitcoin itself can't.

In my mind off-chain should mean zero fees, since it should be an improvement, and on-chain already means very low fees.

Yes, but ultimately someone has to pay for the hardware and security cost of Bitcoin. For 100% of the mining reward were paid by fees, rather than inflation, fees would already have to be about $2USD (http://blockchain.info/charts/cost-per-transaction) per transaction.

I can definitely see the fees for fidelity banks being pennies or even hundredths of a penny. There aren't any humans involved, so everything is done automatically with very small marginal costs and relatively low barriers to entry.

Is it possible for everyone to audit the amount of bitcoin held by the bank and the amount of circulating receipts, to make sure they keep full reserve?

I thought that's how Bitcoin already works (the low fee, no humans/low barrier to entry part).

The mining subsidy of coins is to incentivize miners to participate thus securing the network. At the point the subsidy runs out there should be so many transactions on the system that even low fees would make mining worth while. Unless you're including the block size limit issue in the pricing?

Absolutely. The contract the bank publishes will state what address deposits will be held at. When you send funds to the bank, you'll know to only send your Bitcoins to that address. At the same time, anyone can check how many funds are sitting there, either from confirmed transactions, or pending transactions in the mempool.

Banks will be forced to publish accurate audit logs by the protocol, and those logs will reveal exactly how many receipts are in circulation backed by their deposits. Publishing an invalid log will be considered fraud.



It would be, other than mining, which is has to be made expensive artificially or it has no purpose.


Right now there aren't enough transactions to be even close to paying for all the mining security we do have. When we hit the block size limit, to pay for the amount of security we have right now IIRC tx fees need to be about $0.1/tx, but if Bitcoin is going to grow we're going to need more security than that.

Incidentally, there are technical reasons why even bank transactions should be forwarding fees to miners, albeit fees that are orders of magnitude less than on-chain transactions. Basically part of what constitutes fraud on the part of the bank would be failing to forward the sum of those fees to miners.

I'm not trying to be argumentative, I think Fidelity banks might provide great functionality for privacy if I can wrap my head around it.

But what I was trying to say is Bitcoin is intentionally designed to keep fees either very low or no cost. Let's say there is no block size issue (pretend everyone has T1 lines and near supercomputers for desktops). If this were the case Bitcoin would always have low or zero fees because the coin subsidy pays for network security during years transaction count is small, and by the time that runs out you'll have enough transactions to pay for all the equipment/power costs. Right?

If that were true, then yes, we could stick to on-chain transactions for everything. But because the current system scales by O(n^2), that is for n transactions, the total cost is n^2, there will be a point when you can't have decentralization and low costs. Trustbits scales by n, so for n transactions, the total cost is still n.

Look at it this way: if Bitcoin became the world's currency, it would need to support something like a hundred thousand transactions every second. You're just not going to have a decentralized system at that scale.

Ten years ago, even Bitcoin at it's current scale would be impossible without a lot of centralization. Unfortunately Moores law is already sputtering, so we're probably not going to get the far faster computers we all want in the future.

Anyway, regardless of who is right, if people don't work on alternatives like Trustbits now, we won't have any options at all in the future.

Hmm. I can see a few issues with this, but before I lay out my reasons I just want to re-emphasize the things Peter and I do agree on - that there can and will be innovative ways of doing transactions that lessen the load on the core Bitcoin network. And whilst I'm not sure Chaum banks are it, I do also agree that trusted computing will have a large role to play in future.

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).

I guess the first and most obvious problem is that Chaum already tried to make Chaum-banks when he first invented his scheme, and it was a failure. That is despite the fact he was highly motivated - he believed his idea would make him a millionaire and be the future of finance. So it's worth examining history to figure out why he failed and whether anything has changed since. This is especially true since the patent on his scheme expired years ago and yet nobody rushed to try again.

Although I hate to bring it up, one problem Chaum had was regulatory. By its very nature a Chaum bank is, well, a bank. This leads to two problems:

1) The fact that it gives its users strong privacy directly contradicts almost all existing banking laws which forbid anonymous accounts.
2) The fidelity bond is a great idea. So great in fact that in some parts of the world (like the EU) have written it into law already. You have to put up a large bond (eg a million euros) in order to issue what they call e-money, electronic cash backed by deposits.

Bitcoin manages to avoid both these problems by virtue of not having any banks, not having any issuer and not being backed by any deposits. Because all transfers are P2P existing laws, which are written on the assumption that all finance revolves around institutions, typically don't apply. Notable exception: rules governing the reporting of large "cash" transactions.

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.

I haven't even touched on the issue of fees. Even in the absence of such regulation, I don't think starting such a bank would exactly be easy, if only because of the gigantic bonds required to establish trust in a new player.

Ultimately, Chaum banking failed because it was simply regular banking that offered anonymous accounts, with the twist that you could trust mathematics instead of the Swiss. Even in the absence of laws banning such practices, I don't think it solves the fundamental issues that make banking problematic in todays world, like organizations that become "too big to fail". Bitcoin however does, which is why it's important that we make it scale as well as possible.

From a first glance, this proposal sounds very similar to what the OpenTransactions project has implemented. (see the highlighted parts above)

https://en.bitcoin.it/wiki/Open_Transactions

Unfortunately I hadn't the time to look into any details regarding OpenTransactions, but as far as I know, they have a server already running and just need help to create a more understandable client front-end plus they need an entrepreneur to turn this into a real business.
At least that is the state of affairs I recall from their posts.


From reading your proposal, I get the impression that you have focussed more on the trust part, how that could be organised, and how automated verification could work. Maybe this proposal could complement what the Open Transaction folks have achieved.


So my question is, since you're probably way more knowledgeable in this field:
How does this proposal relate to Open Transactions, what do you intend to do different, what are the similarities?

All right, in that case I'm convinced. Obviously it has to be tried and tested, but I think the idea itself is awesome. I've thus far imagined that the traditional banking system would have to step in to offer the same kind of services they're doing right now with fiat money, but if you're able to realize this, then Bitcoin would become even more of a game changer than it already is going to be.

Aha, can you walk me through what you think ten years ago would look like? Let's say the year 2000 (http://answers.yahoo.com/question/index?qid=20090920100726AA6UtZV):

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.

I ask because I believe I have a solution to the block size issue, which I plan to post next week. However, the issue of large volume of transactions is still going to be interesting to structure.


I totally agree about addressing the issue now while the community is still relatively small so that friction and fractures are handled better.

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.



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.



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.


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.

A situation where the very kernel of (what I call an) accounting system was light weight and higlhy distributed is very compelling to me.  The second layer may be heavy and centralized.  This is regretable and there will be fraud and abuse, but shutting such an overall system down becomes a possibly unwinnable game of whack-a-mole.

I've never put much faith in Moore's law.  The equipment accessible to me (in private life) is closer to what I used a decade ago than it is distant.  Come what may of Moore's law, I don't expect general accessibility to mirror the developments very closely.  Particularly if general accessibility poses a threat.


Garzik, Maxwell, an now ~retep are individuals who I find unusually credible.  I'll be following the work of these persons closely and potentially lending support as my resources allow.

Right, but couldn't companies do it and give people pay access? In other words, right now the issue is about ability to run full nodes from home. The argument is that would then need to be handled by larger external sources. My question is can't that still be called decentralized, as in distribution of hardware powering the currency?

I, in my capacity as Digitalis Data Services (see WHOIS knotwork.com and WHOIS knotwork.net) run the Digitalis Open Transactions server:

https://bitcointalk.org/index.php?topic=53329.0

I also run the OTdemo Open Transactions server, which allows anyone to issue assets.

Open Transactions already does Chaumian blinded tokens, however creation of "mints" for each asset as the asset is created is not automatic currently thus assets people make up for themselves to issue on the OTdemo server do NOT have the ability to mint Chaumain blinded cash tokens for their asset; currently creating the mints for them would require my intervention.

My policy for blockchain based coins such as BBQcoins, DeVCoins, and suchlike* is intended to be more like e-gold or Pecunix than like MtGox or Vircurex: stone-cold wallets, I hope never to have to dig coins out of cold storage because they are there to back tokens and tokens exist to be used. Unless I am closing down the business I expect to continue to need tokens thus to continue to leave the coins in the cold vault in order to continue to have full one to one correspondence between the number of tokens and number of coins regardless of whether I own the tokens (having not sold them yet or having bought them back) or someone else owns the tokens.

Thus I perforce must operate at more-than-100% reserve, as any "hot wallet" funds must be over and above - distinct from - the coins the tokens represent.

I also hope, like e-gold (not sure exactly how Pecunix works) that selling these tokens to end-users and buying them back from end-users will be done by others; e-gold called such others market-makers. Those market-makers apparently could ship physical gold to e-gold's vault facilities and maybe also order bars of gold shipped out to them, but Joe Sixpack never sees/touches gold, he buys and sells tokens from and to those market-makers. (He could buy the tokens with coins or gold though I guess if the market-maker offered such options, or sell them back for coins or gold, etc.)

As to this "trusted computing", I am not sure which brands Open Transactions might incorporate soonest, currently interfaces to that kind of hardware are not yet at the top of to-do lists I think.

-MarkM-

...

* "Suchlike": I hear some similar coins seem to claim to be money; I hear money has regulatory problems. Other than such problems, such similar coin types are technically pretty much interchangeable / compatible. Should some particular flavour be problematic, other flavours abound. Currently none have been proven problematic as far as I am aware. Thus currently my server supports a number of such assets, see http://galaxies.mygamesonline.org/digitalisassets.html

Pretty big silly burden on that bank to have to keep copies of every signature it has ever payed out just incase someone tries to double claim anytime in the future

Edit. Added quote, i was refering to the original idea not open transactions.

That is another profit-centre for the server: mints last X time and new ones are made every X/2 time, for example on my server cash lasts 6 months and new mints are made every 3 months.

Nice clients would automatically refresh your cash for you so you would not need to remember to.

But if it did expire, thanks you just paid for the service. :)

-MarkM-

Have I got this correct?
When I make a deposit and the bank gives me a receipt for the same amount, the receipt itself is a time-locked transaction repaying me the amount I deposited?
At a later date, either
 - the transaction is now unlocked, (and at the same time becomes invalid as a receipt) and I broadcast the transaction myself to redeem my deposit, or
 - I (or whoever I've transferred it to) deposits the receipt in return for funds/another receipt


Another question: who looks after the fidelity bonds and what's to stop them from running off with the money or simply sabotaging the system by refusing to release the bond when the bank shuts down?

The project lead of Open Transsctions plans that bitcoin's multi-signature transactions system could be used to allow coins to be locked up in m-of-n style, where you could have n custodians and any m of them must sign any transaction that tries to move the coins.

Not sure how bitcoin is coming along with m-of-n transactions though.

-MarkM-

Great, although I feel the solution is still quite complex, off-chain transaction is definitely the right direction, it maintains the highest trust because of integrity of bitcoin protocol, provide unlimited scalability and network resource saving, and provide needed transparency at retail level (charge back/dispute)

Actually I doubt that people are really going to use bitcoin to do daily spending, fiat money serve the purpose quite well, no need to duplicate that effort. Bitcoin just need more and better exchanges at each country: Daily tranactions - fiat, long term saving - bitcoin

The one I am talking about is the IBM example you gave. Could they just unplug the original and replace it with an alternative? You said the hardware could not be replaced:




...but the whole machine, could it be replaced?

Unlikely, because you would not be likely to know what private-key to engrave/burn/store into your replacement chip/emulator.

-MarkM-

I like the concept. A decentralized trust protocol.

I'm assuming that the devices you mention take the place of keyservers in this scheme?

I'm not a coder by any stretch but am very advanced in breaking things if you need a semi-pro luser for testing. Let me know what I can do to assist. The more efforts at off-chain transactions means continued improvement of these still new toolsets.

I think it's possible to run on darknet. The fidelity bond, trusted computing, and transaction fee make sure the operator honest. It's at least better than Silk Road.

If bitcoin was invented in 1996, the block size limit would have been set to 10KB. This is exactly why the 1MB hard-limit is arbitrary and is not intended to be kept constant forever.

I say that if people want to work on off the chain systems... that's all great and dandy. But don't FORCE us to use them. By refusing to raise the block size limit you aren't letting the free market decide what it wants to use on top of bitcoin. You are forcing it to use whatever there is. And there might not be anything except for........ other cryptocurrencies.

Only one question: is this bank doing 100% reserve?

That is absurd. One could equally well say by failing to use the block size we already have you aren't sending the market the "more size needed" signal.

"Damn, stuck with vast amounts of unsold inventory, should I restock? Maybe order larger quantity than last time around even?"

-MarkM-

if it's absurd.. then what does this mean?


obviously he is saying the blocksize becomes a serious issue down the road... not now. Is that absurd as well? because it's basically what I said.
If you make the bitcoin network incapable of scaling and you don't work on an off the chain system like this thread is about then "we have no options"

Good question. Maybe its a prediction / assumption that we'll be stuck with excess inventory for a couple more years?

Exchange rates are falling though, so maybe the sky really is falling?

Oh wait, are they falling, really? Or just wobbling on their continued journey upward?

-MarkM-

retep, I just want to say that I am impressed by the amount of thought going in to off-chain systems like this. It is far easier to criticize detail than to put together such a structured concept. I hope that they become a reality as an available service one day.

Well, security is a spectrum, but regardless I don't think you can tap high-speed memory buses with a few thousand dollars worth of equipment, and it goes without saying that you can't easily access anything that's held in the L1/L2 caches. So you have some secure memory there and can write your software such that it encrypts data that won't fit into the cache, if you want to.


How does that work? Unless your plan is to run the entire bank inside the remotely attested secure world, complete with all the code that talks to Bitcoin, you can't know that the bank didn't just issue themselves some tokens without making a deposit.

And if you want to run the entire bank inside a trusted computer, sure, that plan would work, but then you don't need Chaums technique. The secure program can just generate a key and then accept encrypted deposit/withdraw commands. The database can itself be encrypted before it goes to/from disk.


What makes you think most people will keep the whole chain? All you actually need is the pruned UTXO set and that is only a few hundred megabytes today. Bitcoin could operate just fine with only 5 different organisations holding complete copies of the chain. I can't imagine any time when hard disk size is the constraining factor on running a full node.

thankyou

Would there be a limit to the number of receipts a bank can sign every 10 minutes?

How about Facebook, Twitter, Dropbox, LinkedIn, and...well...other such entities?

BTW, I agree that hard disk size is not a constraining factor.  I doubt that very many people have to much concern about that particular aspect of things.  Those who are serious about leveraging the system to it's full potential will probably store the blockchain in RAM anyway I would guess.

The OP's idea is well thought out...but is this a good idea? I mean, recreating banks? Seriously?

What the hell happened to revolutionary ideas? Now people want to recreate banks? What about replacing the financial infrastructure? Why are we talking about supplementing B&M banks with their digital equivalent?

I will never support an artificial code based highly restrictive limit on the Bitcoin economy. I argue the miners will by far be the most screwed if the limit does not increase; if the limit never increases, then once the limit is reached, there's no reason for new users to join. 

Multiple chains and off chain does scale "better" though, regardless of whether fully p2p with vast swarms of ubiquitous commodity full peers all of basically the same scale can be scaled up to any desired scale or not. Right?

-MarkM-

I already mentioned this to you on IRC, but I'll repeat it again: tapping high-speed memory busses is a lot easier than you would think if they go off-chip. You can always first force the memory bus to run slower than it should with the over/underclocking settings, and then secondly build some custom hardware directly on the bus itself with a cheap microscope and a steady hand to sample the signal. After all, it's crypto, provided you don't actually crash the computer, you can try over and over again until you finally hit the key.

L1/L2 cache though... much, much much harder, especially on 22nm where probing busses even for the people at Intel becomes exceptionally difficult due to capacitance. The stuff we talked about on IRC re: L2 cache locking looks like it could really work.


Actually you can. Just make every chaum-token related thing update a counter of all the outstanding chaum tokens, with fraud being any mis-update of that counter. The audit log gets signed and so on, and published publicly. The tokens themselves are still perfectly private - it's just a counter.

Anyway I explained in more detail about my further fidelity-bonded ledgers idea on the bitcoin-dev email list: http://sourceforge.net/mailarchive/message.php?msg_id=30531383 (http://sourceforge.net/mailarchive/message.php?msg_id=30531383)


I considered doing that, but I think the security in depth of chaum + trusted hardware is safer. You don't want to give attackers an incentive to break the hardware to break the security in addition to steal money; your most formidable opponents are likely to not care about theft.


If block-space is cheap, what make you think the UTXO set isn't going to just keep growing, and at a high rate? It's also the most expensive storage because it needs to support a lot of IOPs, yet all validating nodes must have a full copy.

Also, "5 different organizations", so basically you just need to take out five targets to do a heck of a lot of damage to Bitcoin... lovely.

This is what I don't get about you, on the one hand you're saying fidelity-bonded banks have a serious problem due to legality, they're banks basically, yet on the other hand you're happy to see a system so centralized that you expect just half a dozen entities in the world are able to maintain full historical chain data required to validate the blockchain in a truly trust-free manner. What exactly do you expect to happen when countries decide "OK, Bitcoin is illegal now."? Do you have any plans other than, "OK, you win"?


Well I mentioned banks because it's the simplest version of the idea that I could explain on the non-technical forum and that can be done with Bitcoin without any core technical changes to the protocol. If you're interested, I also wrote up a non-banking version, fidelity-bonded ledgers (http://sourceforge.net/mailarchive/message.php?msg_id=30531383), which can be setup such that you are only relying on the third-party to keep an accurate ledger of transactions - they can't steal funds at all. That version requires a soft-fork though to enforce the validation rules, so implementing it is less certain.



For a given bank, yes, based on how much investment they made in hardware. A few hundred to a few thousand dollars worth of hardware could process thousands of transactions a second though; the requirement for audit logs verifiable by others is likely the real issue. A really high volume bank will actually operate, at the technical level, multiple "sub-banks" to split the load up, all of which can be made transparent to the user. (similar to how you care that you pay bitpay, not that you pay a particular address they gave you)



Thank you! I also need to give credit to Gregory Maxwell: while I came up with these ideas, they've been refined through discussions with him mainly, in particular it was his suggestion to combine the fidelity bonds with trusted hardware, and he realized they provide orthogonal protections from fraud.

Mike:
Chaum "banking" with bitcoin-backed tokens (recall bitcoins are not money in law) is a completely different regulatory animal than Chaum banking with the state-backed fiat money of the realm. I would suggest comparing the regulatory challenges of the two is moot.

Retep:
The fidelity bond idea is interesting, it could be just what OpenTransactions needs to complete it's semi-trusted server federation model .... it already does much of what you have outlined in the OP (but you probably already know this).

An unspent output represents real value held by someone. Even dust-spam represents value. I think over time wallets will start to automatically defragment their outputs, perhaps at night when overall traffic is lower. It makes sense for wallets to do this because it'll lower required fees next time you do spends, and it can help with privacy too.

So with such wallets the UTXO set size should be more or less related to the number of users, with occasional swings due to changes in how people use the system. With a stable user base and wallets that have targets for output sizes I can't see why it'd grow forever.


The 5 different organizations scenario was deliberately extreme to make a point - the only thing a full copy of the chain is needed for is bootstrapping new nodes when you don't have access to a copy of the database you trust. In a world where most nodes run 24/7 and are somewhat stable (think high capacity Tor nodes), bringing up new nodes isn't a very common event. I'm not saying it'd actually be 5 nodes.

Also, remember that in a world where Bitcoin has so much usage only 5 organizations can hold a copy of the chain, the issue of whether Bitcoin is OK or not has already been resolved almost by definition. If Bitcoin has as many users as VISA governments aren't going to ban it. Unilateral and extreme government action is a risk in the early days when the system is small. If it ever got really big then democratic support would be enough to ensure that people can store a copy of the chain without problems. Heck maybe even governments themselves would do it as a public service.


Unfortunately I don't think you are correct about either of those things. Have you actually read the relevant regulations? I have, at least for the UK/EU versions (but they are largely standardized around the world). In the EU the laws are written such that anyone who issues what they call "e-money" must post a bond, and e-money is defined as electronic tokens that represent stored value. Like I said, it's basically an already existing implementation of the fidelity bond idea, the goal is to increase user trust. So the law already agrees with retep on that!

Here's an exact quote from the EU directive in question. I think FinCEN has passed similar regulations in the USA.


That's pretty broad and would certainly encompass Chaumian tokens.

As to your belief that "bitcoin is not money in law", where did you get that idea? Are you seriously going to stand in front of a judge and argue with a straight face that something which is called Bitcoin, which floats against other currencies, which is traded on exchanges, and which is accepted for payment by a large number of merchants ... is not money? What makes you think that argument will work?

There are all kinds of laws that can theoretically impact Bitcoin transactions and each one defines what it applies to slightly differently, but I'd be interested to see which laws you think would apply to dollars but not Bitcoins. Because I haven't found one yet.

Need I remind you that Chairman of the Fed. Res., Ben Bernanke testified under oath to congress, in answer to question by Ron Paul that "gold is not money", his words. In the eyes of the law, only the state-issued fiat is money ... they have been very specific about that in order to secure the monopoly they enjoy issuing private banking (Fed. Res.) contract law debt notes as "money". Also the courts use legal tender laws to decide what is and isn't  "money". Read the case precedent of all those people that tried to pay Federal taxes in gold, the constitutional money .... it is broad and deep.

But say we follow your reasoning, you are effectively saying then that all crypto-currency blockchains that might have Chaum tokens issued against them will also be considered money. Are you going to stand up in front of a judge and argue that Namecoin Chaumian tokens are money? Or Litecoin Chaum tokens are money? Or Devcoins Chaumian tokens?

Painting people as ridiculous in front of the judge is easy to do ... how about we stick to the facts?

There's no specific part of law that defines money for all other laws. Each set of laws and regulations tends to define it for itself. So you need to point at some specific regulation that would apply to transactions denominated in dollars but not Bitcoins. Do you have an example? It's definitely not the case for AML laws or the EU e-money laws.


I'm not going to argue that in front of a judge because if those tokens had deep markets and were being exchanged in return for goods and services like Bitcoin is, I would instantly lose. Why bother making an argument you know you can't win?

My own proposed solution is, when BTC are bailed onto a server, instead of giving the coins directly to the server (and risking that the server will steal them, or get hacked)...

...instead of giving the coins directly to the server, you put them into a voting pool composed of say, 50 or 100 servers, where you need X-out-of-Y vote from the other servers, to bail coins back out of the pool. Note: You don't need to do this for every single transaction, since OT transactions occur off-chain. Instead, you just need to do this when moving actual BTC in or out of the pool.

The technical details are described more in-depth here: http://bitcoin.stackexchange.com/a/834/309

This is not just an OT solution -- everyone should be doing this. All those server heists, where they lost hundreds of thousands? Those never needed to happen. Use voting pools use voting pools use voting pools stop getting fucked.

The problem I have with portraying off-blockchain transaction systems like this as allowing us to avoid having to deal with large blocks and the problems that may arise from them, is that they don't.  Don't get me wrong, they are helpful, but we can't rule out success, and an inaccessible blockchain is also a security risk to users.  For example, a billion users plus a refusal to significantly raise the block size limit, and the vast majority of users are virtually shut out from engaging in blockchain transactions at all. *  That means they can't use the blockchain as a trust-free, infrequently accessed savings store, or even engage in runs on their banks when they have to.  It also means that because only a relative trickle of transaction flow goes through the blockchain, and because the greater system's security relies on this flow continuing, that the damage/cost ratio for a flooding attacker can become very high if the growth of the number of users outstrips the growth of block sizes.

Bottom line is: we don't get to decide what the optimally secure block size limit is.  It's defined by some balance between computing technology's enabling of decentralization on the one hand, and the number of users and their need for reasonable access to the blockchain on the other.  So in the event of success, we'll have to find ways to work with large blocks one way or another.

* To give a sense of how inaccessible the blockchain would become: 2000 txs/block * 144*365 blocks/year / 1B users = 0.1 txs/year/user.  Ridiculous as one blockchain transaction every ten years already is, keep in mind that wealth is not distributed equally, and so probably 90% of these people would be cut off altogether.

No-one is saying the limit will never be raised, including myself. If Bitcoin is adopted by a billion people like you suppose we can probably safely raise the limit past the point where you can run Bitcoin nodes anonymously and cheaply - a billion users are a large enough political force to keep Bitcoin safe.

Right now we can support about 18 million transactions per month. (7tx/s) It's easy to see how with off-chain transaction systems that could represent a similar number of people holding significant wealth in Bitcoin, and additionally a much greater number of people whose Bitcoin holdings are at the level where the security of directly holding their own on-chain balances isn't required. I myself keep about $200 worth of BTC in Instawallet and Easywallet accounts for day-to-day spending, and I consider the low risk of them getting stolen to be acceptable considering the privacy advantages of eWallets. Remember that's with neither service really offering any security or auditing beyond "trust us"

The market cap is currently 500 million, probably more like 250 million with the early lost coins taken into account. 250 million / 10,000 = $25,000, so it's reasonable to suppose there are around 10,000 users with significant holdings of Bitcoins. For Bitcoin to get to the level where the users with significant holdings of Bitcoins can't do a transaction a month you could expect the price to increase by about 1,800 times, and thus the market cap to be just under a trillion dollars; the total USD M2 money supply is $10 trillion. Looking at it another way, the earliest prices recorded on blockchain.info are $0.06, so since then the price has only gone up by 600 times - we're a long, long way from getting to the point where people who need on-chain security can't do a transaction a month.

My criteria is that for the foreseeable future it must be possible to run a fully validating Bitcoin node on relatively inexpensive equipment (hundreds to low thousands) and it must be possible to run that Bitcoin node behind relatively censorship resistant network connections. (think Tor) It's the latter requirement, dependent on network bandwidth, that is hardest to meet. Even with block sizes average 200KB or so mining on Tor incurs a fairly high orphan rate, roughly a few percent, so with 1MB blocks Bitcoin doesn't really meet that criteria right now. Hopefully it will in the future if Tor becomes faster, but we just don't know if anonymous networking will become easier to harder. With that in mind I don't yet support increasing the block size, and when I do, I'll probably be considering an early retirement.

Okay, so we can say that the number of users N with significant holdings scales roughly with the exchange rate R (measured in today's USD) as

N = 200*R

If we say the blockchain should accommodate 10 transactions per month for each of these users, then the block size target should be

B = 10*N txs/month * 500 bytes/tx / 144*30 blocks/month = 1.2 N bytes/block

or

B = 230*R bytes/block

This becomes 1MB when R is around $4000, around 80 times what it is today, or 800,000 users with "significant" holdings.

Fair enough.  Qualitatively we agree then that the block size limit should scale with the number of users.  Using the exchange rate as a proxy for this seems quite reasonable.

Yeah I can see upgrading my connection when my bitcoins are worth $4000 each.

I'd argued for exchange rate as a biggie earlier but to be honest I'd upgrade at even just a few hundred dollars per bitcoin.

To be really honest though, its the ASIC fiasco that is my main sticking-point. I don't want to commit to more recurring monthly expenses while I still do not know whether I'll ever be able to upgrade from a single 5870 GPU to some kind of ASIC.

-MarkM-

Agreed. We all tend to think way to centralist.
Also we tend to focus too much on "the" blockchain. Most of those block-chain-size-limit-will-kill-us-in-far-future arguments are moot.
We'll get merge mining. We'll get cross wise merge mining of a multitude of chains. There likely won't be "the" master chain in the far future.

Similarly, there won't be just "the" bitcoin fidelity bond bank.  ;)
What I hope we're building is a network of small-sized low-regulated financial entities, which back each other cross wise.

correct me if im wrong but isnt what you are describing basically the solution to the prisoners dilema?

Good thoughts, though I think in the end the machines will catch up.  People will do without the banks despite the 'maths issues' raised. Decentralization wins.