In a comment that now seems to have been removed, a reader points to this stop-and-recall service from SWIFT, which again basically asks whether blockchain is really necessary for any of this: https://www.swift.com/our-solutions/swift-gpi/stop-and-recall
Is it cynical to see JPM selling JPM Coin at a premium? Is it too heterodox to consider power as a motivating force?
If the Fed were smart (will current Fed tightening be seen as a policy error, like defending the gold standard during the Great Depression?), could they compete by paying the inflation rate as interest on CBDC accounts, using as excuse the mainstream argument that monetary policy can be implemented directly on an individual level, by encouraging microfoundations to save in inflationary times? (Will JPM claim its Coin pays off higher ...?)
Power is a motivating force. But I think JPM's power comes from being systemic and so making narrower spreads to capture more flow with an implicit backstop.
Hmm. I'm not convinced that you need blockchain for any of this. You don't need blockchain to be able to encrypt privileged information. And you don't need blockchain to be able to avoid storing data on a single central server either.
You also don't need blockchain to be able to execute programmable contracts.
I know, I spent several hours on the post and still haven't convinced myself.
It seems like there is a gap in the language. We have "crypto," "blockchain," "fintech," "CBDC." I have some confidence that programmable contracts are a big part of where this is going. I think there are some other pain points in the payment system, as this post tried to get into. Blockchain *per se* does not seem to be strictly necessary. So is there a name for the minimum technical feature that the wholesale payment system needs to absorb to respond to some of these perceived needs?
Well, blockchain is a particular kind of distributed database. As I understand it, blockchain's defining characteristic is that it can reach a "distributed consensus" about the ordering of transactions without the need for a defined finite set of decision-makers. If you know who your decision-makers are, you can just have them vote.
Any distributed database can be used for decentralized data storage. Any major website or internet service avoids storing data on a single central server. That's normal. And they don't use blockchain. So, decentralized data storage is not a special feature of blockchain .
The book that I would recommend for a general overview of distributed databases is "Designing Data-Intensive Applications" by Martin Kleppmann. It's one of the rare technical books that's fun to read from cover to cover. Kleppmann only briefly touches on blockchain, but I felt like I came away from the book knowing how to think about blockchain in the context of similar technologies.
And this is after I'd already gone through and picked apart the original Bitcoin source code line-by-line. I already felt pretty solid on the technical mechanics of Bitcoin & blockchain.
Once you've got a distributed database, programmable contracts can then be implemented as stored procedures on the distributed database. Again, this is not a feature that's specific to blockchain.
If you want to verify privileged information without being able to read it, you can encrypt the information and use use zero-knowledge proofs. This requires cryptography, of course, but it doesn't require blockchain.
This is super helpful - you are clarifying the distinction between blockchain and other distributed databases, a distinction which is likely to be important as some variation on these technologies is absorbed as incremental changes in the institutional framework.
In a comment that now seems to have been removed, a reader points to this stop-and-recall service from SWIFT, which again basically asks whether blockchain is really necessary for any of this: https://www.swift.com/our-solutions/swift-gpi/stop-and-recall
Is it cynical to see JPM selling JPM Coin at a premium? Is it too heterodox to consider power as a motivating force?
If the Fed were smart (will current Fed tightening be seen as a policy error, like defending the gold standard during the Great Depression?), could they compete by paying the inflation rate as interest on CBDC accounts, using as excuse the mainstream argument that monetary policy can be implemented directly on an individual level, by encouraging microfoundations to save in inflationary times? (Will JPM claim its Coin pays off higher ...?)
Power is a motivating force. But I think JPM's power comes from being systemic and so making narrower spreads to capture more flow with an implicit backstop.
Hmm. I'm not convinced that you need blockchain for any of this. You don't need blockchain to be able to encrypt privileged information. And you don't need blockchain to be able to avoid storing data on a single central server either.
You also don't need blockchain to be able to execute programmable contracts.
I know, I spent several hours on the post and still haven't convinced myself.
It seems like there is a gap in the language. We have "crypto," "blockchain," "fintech," "CBDC." I have some confidence that programmable contracts are a big part of where this is going. I think there are some other pain points in the payment system, as this post tried to get into. Blockchain *per se* does not seem to be strictly necessary. So is there a name for the minimum technical feature that the wholesale payment system needs to absorb to respond to some of these perceived needs?
Well, blockchain is a particular kind of distributed database. As I understand it, blockchain's defining characteristic is that it can reach a "distributed consensus" about the ordering of transactions without the need for a defined finite set of decision-makers. If you know who your decision-makers are, you can just have them vote.
Any distributed database can be used for decentralized data storage. Any major website or internet service avoids storing data on a single central server. That's normal. And they don't use blockchain. So, decentralized data storage is not a special feature of blockchain .
The book that I would recommend for a general overview of distributed databases is "Designing Data-Intensive Applications" by Martin Kleppmann. It's one of the rare technical books that's fun to read from cover to cover. Kleppmann only briefly touches on blockchain, but I felt like I came away from the book knowing how to think about blockchain in the context of similar technologies.
And this is after I'd already gone through and picked apart the original Bitcoin source code line-by-line. I already felt pretty solid on the technical mechanics of Bitcoin & blockchain.
Once you've got a distributed database, programmable contracts can then be implemented as stored procedures on the distributed database. Again, this is not a feature that's specific to blockchain.
If you want to verify privileged information without being able to read it, you can encrypt the information and use use zero-knowledge proofs. This requires cryptography, of course, but it doesn't require blockchain.
This is super helpful - you are clarifying the distinction between blockchain and other distributed databases, a distinction which is likely to be important as some variation on these technologies is absorbed as incremental changes in the institutional framework.
I will have a look at Kleppmann's book.