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.

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.

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

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.

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

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.

...also, for more sober experimentation, see block #54512, 0000000010bf4453b170a6756d911e207734ae181af6c8c02b42787d5885b333 and 54507, which seems to have broken blockexplorer.com/testnet

THE MAX BLOCK SIZE MUST BE INCREASED TO AT LEAST 1.7MiB NOW!

This is why:

No-one is saying there isn't a problem with the system that doesn't need to be addressed. We absolutely do need a way to somehow discourage the creation of small-value outputs, and the fact that we don't yet is a flaw in Bitcoin.

One possible solution would be to simply make any transaction with an output value less than the minimum fee non-standard, so that those transactions won't be relayed or mined by miners. After all, if the value is less than the minimum fee, there isn't any rational reason to spend the output. (the fee is zero with sufficient priority mind you, but zero-fee tx's probably won't get mined forever)

The bigger problem is that it's only the size of blocks that is the limited resource - the incentive structure should make transactions that reduce the UTXO set cheaper, but actually coming up with rules that effectively do that without causing other problems is hard.

DNS is unauthenticated (1) and we really don't want to give your ISP's sysadmins a way to trivially trick you into sending coins to the wrong place on a mass scale.

1) DNSSEC was supposed to authenticate DNS ,but it's not used very much.

Bitcoin's almost higher than the number of days in ANY month!

!!!!!

Market cap isn't very meaningful when the money supply - the non lost coins - isn't known.

Bingo.

The right solution is to send packet on a fixed schedule. Batch outgoing payout transactions and periodically, say every 100ms for Satoshidice, send all the batched transactions out in random order. Because the sends now happen on a fixed schedule, all timing information with a resolution less than the schedule is destroyed completely.

This idea can be done by a totally different computer too. For instance you can put the scheduler in a separate Bitcoin node, or even as a separate router box that applies the fixed schedule to every IP packet.

Sukrim's video mentions a slight variant of the fixed schedule, pad to max, at 22:17. He calls it slow and inefficient, but in the case of Satoshidice a fixed 100ms delay would be perfectly acceptable.

Exactly.

The reason behind this rule is to limit the damage in the event that a block, or potentially a whole bunch of blocks, get orphaned by a better chain. The problem is that while normal transactions can always make their way back to the chain - they just become unconfirmed and can always be reconfirmed - when a block is orphaned the coinbase transaction simply no longer exists and thus transaction that spent that output are invalid. There could be a heck of a lot of those transactions, and thus a lot of peoples' payments disrupted.

The 100 block rule makes that really unlikely to happen because 100 block getting orphaned in a row is really unlikely to happen. Satoshi probably chose 100 blocks, rather than say 6 or something, to be conservative; making miners wait 16 hours before they can spend their reward is a pretty minor disadvantage compared to the huge amount of harm invalidating transactions can do. Personally I would have picked a week myself, but unlike Satoshi I have to sleep.

The value of this rule was really demonstrated a few years ago with the overflow bug. Basically a flaw was discovered where a special transaction could create an enormous number of coins out of thin air. The flaw was (very) quickly patched and miners upgraded, but it still took a good 50 blocks or so before the patched chain finally overtook the un-patched one. Because of the 100 block rule all the transactions on the un-patched chain eventually were confirmed on the patched one.

It may be the default, but if you don't make sure SIGHASH_ALL is actually being used an attacker can make bets and use the malleability as a way of recovering their loses while denying that they did it. I also explained elsewhere how people could agree to help each other recover their loses using this method, and that cooperation can happen without any central co-ordination at all.

No, the re-roll there happens because the tx gets mined, and thus the first tx gets removed from your mempool, and you see the second one. After the fact it will look like you received a bet but never paid out.


If sorting the txin's makes it easier to code, that's fine, but remember that regardless you must ensure at least one of the signatures uses SIGHASH_ALL or anyone can add extra txin's and change the lucky number.

Fees are still pretty tiny in comparison to the block reward, and some people are willing to pay that small price because they don't like Satoshidice.

Don't assume everyone is a perfectly rational economic actor, or even that perfectly rational actors are using the same set of assumptions that you are.

Sheesh... When I brought up 56k modems, I stated quite clearly they are too slow to mine on, because the orphan rate would be way too high. However, they are fast enough to keep up with the chain, letting you validate it and make sure some centralized cartel of miners aren't trying to rip you off via inflation.

For an acceptably low orphan rate, say 2%, you need a much faster connection that a 56k modem, because you need to be able to download a whole block within a about 10 seconds.

This is the great thing about the current 1MiB blocksize cap: you can run a full node on a 56k dial-up connection. Yes, you'll have to get a copy of the blockchain somehow to start, probably by finding someone local with a copy, or getting a copy delivered to you on DVD's by mail, but once you have that copy a 56k dial-up modem is fast enough to keep up with the full blockchain. The real-world speed of a 56k modem is about 4KiB/second. On the other hand even if every single block is 1MiB that's only 1.7KiB/second. You'll have to leave your node running at least 50% of the time to keep up, and trying to mine using that node won't be practical due to the huge orphan rate, but it really is possible.

Rejections are is not a significant risk for miners. That's the whole point of my original post on the issue. If your blocks are built upon by the majority of hashing power, you come out ahead in the long run. Your orphan rate does increase proportionally, but if, say, 5% of the hashing power never sees your blocks, the increase in varience is low, yet you get the very real benefit of 5% less competition. In the long run there is no "might" - it's simple statistics, and I haven't seen anyone offer a rebuttal based on analysis rather than hand-waving.


I agree with you there. But if large blocks turn out to not be an option, for whatever reason, we need alternatives, and creating those alternatives take time. We've probably got two or three years before the limit becomes a big issue, maybe less, and as you know raising the limit will take at least a few months for the consensus to be achieved among all users. Right now what I'm hearing from you and Mike Hearn is a defacto "yeah, we'll just keep upping the blocks size, I just don't know yet by how much or if it'll be one-time thing or a floating limit". This attitude leads to people not working on alternatives and if alternatives don't exist by the time the limits are reached, like it or not, raising the limit will be the only option regardless of the downsides.

You already know about the fidelity-bonded banking stuff I'm working on, but it really bothers me that I don't seem to have much competition. Frankly I'd be happy to see someone else come up with an even better idea that I haven't thought of, or just come up with a better implementation of bonded banks than me. That outcome is much more likely to happen if you make it clear that if off-chain value transfer systems are developed not raising the limit is an option.