Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

If one views blockchain money in the distributed spirit of Bitcoin, the idea of a "private cryptocurrency" will seem like an oxymoron. If it's a private blockchain JPM controls, JPM might as well run a traditional database. Yes, I agree.

But setting that aside, here's my best guess at what JPM is trying to do: Maybe it's not the blockchain as storage that matters but the programming API that their institutional customers can use for transferring money between accounts.

Maybe instead of thinking of JPM's blockchain as a broken version of Bitcoin's ideals for public money creation, JPM's main use is to let the big customers move money on their own -- using a forked version of Ethereum (called Quorum). Some of JPM's code examples on github.[0]

There are pre-existing places where JPM customers can move financial instruments. Their dark pool exchange called JPMX is one example.[1] JPM's customers can trade stocks there outside of NASDAQ/NYSE.

But what about cash instead of stocks? I think that's what JPMCoin tries to be. Yes, their's already the SWIFT network[2] for wire transfers but I don't think banks want to expose that to account holders to the same flexible degree that the Quorum programming language would allow.

So, JP Morgan wants to enable their customers to instantly transfer money with their other customers without the legacy of SWIFT messages. For obvious reasons, they won't use the PayPal API, or the Stripe API. Instead, they use a flavor of the Ethereum API to let their customers execute "programmable money".

The real Ethereum is too volatile for business-to-business money transfers. But with JP Morgan's financial backing to reliably convert JPMCoin to $USD, that would instill confidence for account holders to use it.

In my opinion, JPMCoin isn't that revolutionary since it's only intended for their big institutional customers. Time will tell if their customers will adopt it or ignore it.

[0] https://github.com/jpmorganchase/quorum-examples/tree/master...

[1] https://en.wikipedia.org/wiki/Dark_pool#Broker-dealer-owned_...

[2] https://en.wikipedia.org/wiki/SWIFT_message_types

> Maybe it's not the blockchain as storage that matters but the programming API

Even if that was true, you could easily implement a compatible API that doesn't use a blockchain under the hood, especially seeing as it is centralized by JPM.

I see this as JPM just trying to ride the hype wave, and as a contingency if blockchains go mainstream (spoiler: they won't).

You could implement a compatible API, but it turns out that consistent distributed payment systems are a hard problem, and blockchains are a solution to that.

It's not a distributed payment system, its a centralized one (owned and controlled in every way by JP.)

There's no reason to add the problems of distributed data to your payment systems unless you HAVE to.

> owned and controlled in every way by JP

The benefits of private transactions without notifying the processor (and circumventing financial regulation, or at least delaying it), is immediately obvious. It's a distributed payment system. The control you mention, is subjective.

There's distributed and there's distributed. Blockchain might be overkill, but it solves the "JPM's transactional database of financial transactions is down" problem.

I’m curious why you don't think DLT will find traction. I don't have a strong opinion either way, but it seems that a number of good use cases have been floated for it to replace “trusted third parties” and other intermediaries, minimize corruptibility, etc.

> a "private cryptocurrency" will seem like an oxymoron

There is one sense in which a private cryptocurrency could be tremendously useful: a currency with a ledger maintained by a TTP but where transactions were authorized with proper digital signatures would be both more efficient and much more resistant to fraud than any other current (no pun intended) method of transferring money.

Can you not trivially build a traditional server that requires API requests to be signed?

Yes, but that by itself won't solve the problem. You need some way of auditing the TTP to insure that they don't cheat by, say, censoring transactions, or printing money for themselves. And this auditing process has to preserve user privacy. You don't want the world to know what your bank balance is. Making this work is not trivial.

Arguably, the IRS needs to know your transactions

I think people don't want other people to know their balance, but remember, Uncle Sam prints the money, so he gets what he wants.

I do think we'll move to a cashless society exactly for this reason. It might be blockchain based. But I'm skeptical it will be a utopian move where we can all inspect the chain and verify no one is cheating.

I am pretty sure in the future the IRS will have the ability to know the details of every USD denominated transaction. Even still, I'm skeptical this will do much to stop tax evasion and fraud.

It's not necessary for everyone to be able to verify that no one is cheating. It is only necessary for everyone to be able to verify that the TTP isn't cheating.

Whether or not such a system exists is mostly orthogonal to the question of whether or not cash exists. Cash can be eliminated whether or not it's replaced with a reasonable alternative, and the reasonable alternative can exist without eliminating cash. The nightmare scenario is the elimination of cash, and replacing it with an insecure, inefficient system run by a bunch of rent-seeking oligarchs. (Sadly, that outcome also seems to be the most likely in the U.S.)

A blockchain is not a particularly good solution for auditability though. A simple signed transaction log does the job just as well with much less complexity and overhead. Neither approach solves the privacy issue.

A signed transaction log doesn't solve the censorship issue either.

And a private blockchain does?

No. "A currency with a ledger maintained by a TTP" != "private blockchain."

And how do you make sure that the entity in charge didn't just remove transactions from the log? Let's add a cryptographic commitment to the whole transaction set with each transaction.

But then how do you order them to know which one came first. What if two transactions come at the same time? Let's split them into chunks that will be added every X minutes.

And how do you make sure that the chunks aren't messed with/reordered/whatever? Let's make each chunk reference the previous one through a hash.

Oh wait.

Without PoW the crypto you describe does nothing to stop the TTP from re-writing history. The TTP can just re-generate the chain starting from the block they wish to re-write.

With both a private blockchain and a signed transaction log you have to rely on the tx log/blockchain being published so that third parties can verify that all updates are consistent.

> With both a private blockchain and a signed transaction log you have to rely on the tx log/blockchain being published so that third parties can verify that all updates are consistent.

Maybe it is?

Hash chaining over logs predates the blockchain by a fair whack of time. If you don't mind a trusted authority cross-signing, it's a lot easier and a lot faster.

You don't need the batching mechanism quite so badly and ACID databases have a pretty good track record at establishing a trustworthy ordering of events.

Sure, but such service could be compromised.

If the system allows customers to verify the ledger it makes compromising the system much harder.

I'm confused what this offers over USDC. Banks can already issue USD backed tokens with this model. USDC is already being traded on several exchanges. I'm sure I'm missing something obvious.

It comes down to who is doing the coin creation and redemption. In the case of USDC, Coinbase is handling it. In the case of JPMC, JPMorgan would handle it.

The general public's trust in JPMorgan is probably higher than their trust in any crypto company that has yet to exist for an entire decade.

JPMorgan - and other banks - have a huge incentive to run their own "stablecoin" creation/redemption business, because it can in some ways allow them to skirt their reserve requirements, while also possibly netting them a tiny operating profit if they sell newly-minted JPMC above the price they redeem them for (leading to profit on the spread).

> In the case of USDC, Coinbase is handling it.

It's handled by CENTRE who's founding members are Circle and Coinbase.. but the network will grow to include any compliant banking institution.

> because it can in some ways allow them to skirt their reserve requirements

It can do what now??

> and other banks - have a huge incentive to run their own "stablecoin"

Every bank can release their own version of Paypal too. Why would the network effect of JPMC overtake USDC when any regulated bank can become a USDC issuer? USDC is sitting at a 255MM market cap.

Excellent point! Now let's hope the governments follow the example and provide a similar blockchain for their fiat currency.

That's what we need to do business here on earth, not volatile currencies lead by shady entities.

Reply on news.ycombinator.com