Topic: Fidelity-bonded banks: decentralized, auditable, private, off-chain payments (Read 8970 times)

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.

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

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.

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-

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.

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.

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.

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.

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?

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?

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.

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

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


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

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-

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. 

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.

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

thankyou

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.

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.