>> since the bank itself could never prove its reserve level of deposit met the percentage set by government

There’s no minimum reserve set by the fed anymore: https://www.federalreserve.gov/monetarypolicy/reservereq.htm

Other countries exist.

See https://en.wikipedia.org/wiki/Reserve_requirement

Many countries don't have a reserve requirement. The US was a bit of a laggard.

Minimum reserve requirements were always a bit silly. You want your banks to have a thick capital cushion for its debt. Whether they have reserves on hand is an operational problem they can solve themselves, and doesn't have systemic consequences.

It's not really about the reserve requirements, but about basic accounting requirements, which all banks do have. At its fundamentals, bank balances are not some storage of "your money", they are recording of how much the bank legally owes you (or vice versa). And of course the bank has to know exactly what liabilities they have according to their contracts, so they need to see the balances. They also need to be able to add arbitrary quantities of new money to the FHE scheme when cash is paid in and remove it when it is paid out.

Or, more succinctly, what makes a bank a bank is that it will loan out money deposited by other people.

If the money is just sitting there and can't be moved or even counted without the owner's private key, it's not a bank, it's a vault.

>> what makes a bank a bank is that it will loan out money deposited by other people

No, a bank creates money to loan out from nothing. No deposits required.

As a sibling comment points out, other jurisdictions exist so here's the UK central bank's explainer on the topic: https://www.bankofengland.co.uk/explainers/how-is-money-crea...

but once the bank has made the loans, it has to keep track of how many it has made and how many are delinquent. i could be missing something.

Yeah of course, but that's not the point the parent was contesting. They claimed a bank loans from funds deposited which isn't the case.

If a bank chooses to create an asset (your liability) by loaning money to you, if you then fail to repay, then they're in a bad spot. They're certainly not allowed to just delete the records of the loan being issued to get rid of the delinquent asset on their balance sheet.

I love/hate this. It's one of those ideas that's incredibly appealing to people who already have other ways of doing it, and incomprehensible to people who would actually benefit from it. Most things of that ilk get blown up because once it's peddled to the masses, consumers don't verify that it's actually run the way it's supposed to be run, and someone writes in a backdoor (FTX). Then it just takes a few hyped up claims and burst bubbles before it becomes a punchline.

What would be sort of awesome, though, would be a distributed bank (or prediction market, or casino) along these lines. If every node can donate processing power to run totally encrypted transactions, it's a game changer. You could finally rely on client-side processing to deal poker hands and process game states without a central server, for example.

> You could finally rely on client-side processing to deal poker hands and process game states without a central server, for example.

Interesting. I had given up on that idea. Not just for poker, but MMOs n stuff. Figured anything of importance had to run server-side.

it does. But if you could drop an encrypted VM on each client - where the instructions and responses were encrypted, and even frozen/dumped states were encrypted... you'd finally have no need for centralized game servers to arbitrate who sees which part of a hidden state. You could put every player's secrets, and the secrets of the game state, on each client and use their processing in parallel.

> What would be sort of awesome, though, would be a distributed bank (or prediction market, or casino) along these lines I think this is already possible for poker, and will never be possible for prediction markets.

Prediction markets require human resolution of "fuzzy" questions. For example, who won the 2020 US presidential election? You can see why the limiting factor isn't the machine.

But for poker, why do you need FHE? To play poker, you have to deal two hole cards and five community cards. First each player gets two secret ("hole") cards, then three community cards are dealt ("flop"), then potentially another ("turn"), then potentially another ("river"). This could be done programmatically as such:

1. Each player generates five secrets: k_HOLE, HOLE, FLOP, TURN, RIVER

2. Each player derives public key K_HOLE from k_HOLE.

3. Each player publishes the hash of each secret in addition to K_HOLE.

4. Each player publishes their value of HOLE, which is checked against the hash from previous step.

5. To get the two hole cards for you, calculate H(HOLE_1 || HOLE_2 || ... || HOLE_N), decrypt the resulting value using k_HOLE (secret to you), then deterministically turn this into cards (for example: hash it, then map the first half into 52 values and the second half into 51 values)

6. Once it's time for the flop, all players publish FLOP. Then calculate H(FLOP_1 || FLOP_2 || ... || FLOP_N).

7. Repeat for turn and river as necessary.

The only difficult part is how to handle colors, but I don't think this is a serious issue, since nobody counts cards in poker anyway. (We can trivially ensure flop, turn and river don't repeat cards, so it's just a question for the hole cards vis-a-vis the community cards)

EDIT: Looks like someone has already tried to do this seven years ago: https://github.com/zweicoder/PokerPhase

Given a pair of hole cards and a hash from a server for everything else, you can do this. But a fair poker hand is dealt from a truly randomized deck. Some central server needs to be the arbiter of randomness (not to mention being the actual escrow service for the money in the pot -- which is the other service provided by prediction markets besides deciding how to resolve bets). Those things - randomness, arbitration and escrow - still can't be completely devolved to client-side processing, or at least not without recourse to ludicrous hacks like public ledgers (aka blockchains) which still run the risk of 51% attacks.

Encrypt the whole VM and all i/o on each client though, so that the machine state itself is encrypted at all times, and you can trust their generation of the hole cards (as far as you can trust a PRNG).

Under this new paradigm, though, the power over the systems probably goes to some new certificate authority that doubles as a routing (signaling) service.

> Some central server needs to be the arbiter of randomness

What, no? My hash-based system is entirely random. The only issue is that draws are done with replacement, so two players may both have e.g. six of spades in their hand. This is aesthetically unappealing, but doesn't alter the actual maths of the game. (There are more complex solutions to this, however)

> not to mention being the actual escrow service for the money in the pot

FHE doesn't solve this, since FHE can't actually interface with your bank. Even if it could, I could just log in on my phone or physically walk into a bank branch to freeze my account before I have to pay out, so you still need a solution for the money layer.

> you can trust their generation of the hole cards

You can do trustless generation of hole cards already, as described in my post.

Sure. And then, after you've transferred 5 dollars to me, I say "What 5 dollars? What are you talking about?" and refuse to hand over the thing that you thought you bought.

Add perfect anonymity to the mix and I get to do it over and over again, too.

You could set it up so whoever initiates a transfer could get a kind of receipt that proves they initiated a transfer of X dollars to whomever.

So if Alice transfers 5 dollars to Bob and Bob says "What 5 dollars? What are you talking about?", then Alice could say, well here's my receipt, that's signed by my private key and the private key of the FHE bank, that shows that I sent the money to Bob and the FHE bank executed the transfer.

You get this for free with FHE. In the event of a dispute, you can reveal the randomness and message that produce the public ciphertext given the user's public key.

You could still design the scheme such that the sender can produce a cryptographic proof. Equally applicable for tax auditing etc.

You don't need FHE for that. It's possible through some zero-knowledge schemes, such as zk-SNARKS, which is implemented in and popularized by shielded transactions on Zcash.

You don't need zk-SNARKS for that. It's possible through some schemes, such as blind signatures, which have been successfully implemented many times but their usage for currency has (iirc) proved legally problematic.

For the uninitiated:

https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurit...

Chaumian mints are gaining some popularity in the bitcoin world: https://fedimint.org/

Sure, and apparently there's a coin for that too, by Chaum himself[0] :P

(If it's not obvious: Blind signature as such are solid but I wouldn't suggest anyone to give a cent to this sketchy project)

AFAIK (and I'd be thrilled to be proved wrong) we still haven't figured out how to solve double-spend using blind signatures without a blockchain and so the schemes I've seen so far invariably involve either that or a trusted mint and are therefore less interesting to use as currency.

Assuming you already have a base digital currency (like bitcoin), they can still be interesting on/as a higher layer.

[0]: https://xx.network/blog/decrypt-how-david-chaum-went-from-in...

GNU Taler does something similar, except without homomorphic encryption. It only anonymizes the payer however.

What purpose would this serve? Just anonymity for the sake of anonymity, or something else?

Note: this was a genuine question, with genuine interest in the answer. Why the downvotes?

Seems a fair question. In a private banking context, it would potentially eliminate the need to pay escrow fees to a third party, without resorting to massively inefficient public ledgers. In the context of e.g. stock trading, it might mean that a traditional bank can connect buyers and sellers over a peer to peer connection and guarantee that their trades execute in order without even needing a centralized book. That's maybe a slightly extreme take, and probably a ways off. But I think anonymity is the least important of what becomes available if you can trust client-side processing.

its basically a thought experiment.

one of the things i never understood about bitcoin was the idea of the public ledger. one of the main things about most people and businesses in general is that they do not want to draw attention to their actual flows of money. the idea everyone would want their entire purchase and payment history "out there" in public never made sense to me.

but if you could actually make bitcoin anonymous, then what would happen? would it be adopted more? or would the government actually have to crack down?