So Bitcoin is a couple of orders of magnitude short of overtaking banking.
Of course, BTC is also many orders of magnitude short of banking in the volume of trusted transactions it enables—this is hardly an apples-to-apples comparison! A single BTC transaction is actually rather economically costly, and this will only become more fully apparent to BTC users over time, as the current block-creation subsidy keeps dwindling further.
Now don’t get me wrong, BTC and other crypto-currencies are still interesting as a heroic effort to establish decentralized trust and enable transfers of value in problematic settings, such that a conventional financial system is unavailable. But the amount of hype that surrounds them is rather extreme and far from justified AFAICT.
(In the long run, there is some chance that we’ll come up with forms of automated “proof of work” that have beneficial side-effects, such as solving instances of interesting NP-hard problems. If so, this might reduce the collective cost of using crypto-currencies significantly, maybe even make them competitive with the traditional banking system! In fact, a prime example of this exists already although the chosen problem is little more than a mere curiosity. Clearly, we need a better characterization of what problems make for a good crypto-currency target!)
Bitcoin is a settlement network, used for periodic netting of positions. The fact that settlement is primarily used for direct payment now is chiefly due to the fact it is easy to do—path of least resistance—and transactions are still cheap. As bitcoin develops it will be used more by 2nd layer protocols that use the block chain only for reallocation of funds among settlement parties, and for this it is unclear how much larger the bitcoin volume needs to be above current levels.
Creating proof of work schemes that have resellable secondary value actually undermines the security provided by proof of work. The security provided by proof of work is the cost of the work minus the resellable outputs, so it is exactly the same or worse than if you just had fewer miners doing useless work and a few specialized servers doing the useful portion. It is possible though that we could come up with a scheme that has secondary value that is purely in the commons and that would be strictly better. For example, a proof of work that acts as unwinding a ticking timelock encryption, so it can be used to reliably encrypt messages to future block heights.
In terms of expected utility payout, working on such a scheme would be of very high benefit, more than most any task in any other domain I can think of, and I encourage people to take up the problem.
Bitcoin is a settlement network, used for periodic netting of positions. The fact that settlement is primarily used for direct payment now is chiefly due to the fact it is easy to do
I’m not sure that there’s any real distinction between “direct payment” and “settlement”. For that matter, while BTC may in fact be strictly preferable to physical/paper-based settlement in resource use (though even then I’m not sure that the difference is that great!), that’s rather small consolation given the extent to which electronic settlement is used today. (In fact, contrary to what’s often asserted, there seems no real difference between this sort of electronic settlement and what some people call a “private, trusted blockchain”; the latter is therefore not a very meaningful notion!)
forms of automated “proof of work” that have beneficial side-effects, such as solving instances of interesting NP-hard problems
Would breaking cryptography be a good example of this? Like, someone enters a bunch of public keys into the system, and your “proof of work” consists of finding the corresponding private keys. Then we could construct cryptocurrencies based on hacking competing cryptocurrencies; that could be fun!
(Yeah, I guess the important obstacle is that you want the “proof of work” to scale depending on the needs of the network. Too difficult: the process is slow. Too simple: there are too many outcomes to handle. Must adjust automatically. But you can’t provide enough real private keys with an arbitrary difficulty.)
Breaking cryptosystems? That exact construct would be so much more useful than that. It’d let you have a ticking time-lock encryption service—I encrypt a message using the keys from the next block until block number N at some point in the future. You now have a message that will decrypt at a specified time in the future automatically and without intervention. That is a tremendous public resource to say nothing of its use within the system as a smart contracting primitive.
Unfortunately known methods of achieving this (e.g. breaking low-bit EC keys using Pallard’s rho algorithm) don’t meet the basic requirements of a proof of work system, the chief problem here being non-progress-free.
Of course, BTC is also many orders of magnitude short of banking in the volume of trusted transactions it enables—this is hardly an apples-to-apples comparison! A single BTC transaction is actually rather economically costly, and this will only become more fully apparent to BTC users over time, as the current block-creation subsidy keeps dwindling further.
Now don’t get me wrong, BTC and other crypto-currencies are still interesting as a heroic effort to establish decentralized trust and enable transfers of value in problematic settings, such that a conventional financial system is unavailable. But the amount of hype that surrounds them is rather extreme and far from justified AFAICT.
(In the long run, there is some chance that we’ll come up with forms of automated “proof of work” that have beneficial side-effects, such as solving instances of interesting NP-hard problems. If so, this might reduce the collective cost of using crypto-currencies significantly, maybe even make them competitive with the traditional banking system! In fact, a prime example of this exists already although the chosen problem is little more than a mere curiosity. Clearly, we need a better characterization of what problems make for a good crypto-currency target!)
This is a bogus argument (hehehe, sorry).
Bitcoin is a settlement network, used for periodic netting of positions. The fact that settlement is primarily used for direct payment now is chiefly due to the fact it is easy to do—path of least resistance—and transactions are still cheap. As bitcoin develops it will be used more by 2nd layer protocols that use the block chain only for reallocation of funds among settlement parties, and for this it is unclear how much larger the bitcoin volume needs to be above current levels.
Creating proof of work schemes that have resellable secondary value actually undermines the security provided by proof of work. The security provided by proof of work is the cost of the work minus the resellable outputs, so it is exactly the same or worse than if you just had fewer miners doing useless work and a few specialized servers doing the useful portion. It is possible though that we could come up with a scheme that has secondary value that is purely in the commons and that would be strictly better. For example, a proof of work that acts as unwinding a ticking timelock encryption, so it can be used to reliably encrypt messages to future block heights.
In terms of expected utility payout, working on such a scheme would be of very high benefit, more than most any task in any other domain I can think of, and I encourage people to take up the problem.
I’m not sure that there’s any real distinction between “direct payment” and “settlement”. For that matter, while BTC may in fact be strictly preferable to physical/paper-based settlement in resource use (though even then I’m not sure that the difference is that great!), that’s rather small consolation given the extent to which electronic settlement is used today. (In fact, contrary to what’s often asserted, there seems no real difference between this sort of electronic settlement and what some people call a “private, trusted blockchain”; the latter is therefore not a very meaningful notion!)
Switching from proof of work to proof of stake for most transactions seems to be a more likely solution to the problem.
Would breaking cryptography be a good example of this? Like, someone enters a bunch of public keys into the system, and your “proof of work” consists of finding the corresponding private keys. Then we could construct cryptocurrencies based on hacking competing cryptocurrencies; that could be fun!
(Yeah, I guess the important obstacle is that you want the “proof of work” to scale depending on the needs of the network. Too difficult: the process is slow. Too simple: there are too many outcomes to handle. Must adjust automatically. But you can’t provide enough real private keys with an arbitrary difficulty.)
Breaking cryptosystems? That exact construct would be so much more useful than that. It’d let you have a ticking time-lock encryption service—I encrypt a message using the keys from the next block until block number N at some point in the future. You now have a message that will decrypt at a specified time in the future automatically and without intervention. That is a tremendous public resource to say nothing of its use within the system as a smart contracting primitive.
Unfortunately known methods of achieving this (e.g. breaking low-bit EC keys using Pallard’s rho algorithm) don’t meet the basic requirements of a proof of work system, the chief problem here being non-progress-free.