Hmm, calling bitcoin slow is a little strange. Are you talking about confirmations, where other networks take 100s of days? But since it's "not a technical post", I wonder whether technical knowledge is invited to his discussion.
Whether confirmations happen instantly (violating physical speed of light constraints imposed by reality) or take minutes or even months (ahem, Visa etc), does not seem to play any important role into whether something is fit for a consumer product. I'll give an example: even in the case of Visa's network, consumers are somewhat isolated from the long confirmation delays, and the costs imposed by confirmation delays are shoveled on to the merchants anyway. This is not because a centralized system like Visa requires that design, but rather because they made those choices when providing a product to merchants and consumers. Likewise, others have made similar products with bitcoin. That bitcoin confirmation delays are shorter has no bearing on whether a business can hold funds for 80000 days or whatever you want. This has little to do with suitability for productization. But perhaps this point is too nuanced for "a post that isn't technical".
My own opinion is that I don't really mind whether consumers are "directly" using bitcoin or not. I mean, I certainly don't care if they are manually bitbanging out their own bitcoin transactions or clicking buttons telling software to make transactions. That's a really trivial detail in the scheme of things....
As for being "completely incapable of handling transactions on the volume of the banking system itself", you mention settlement but I don't think you go far enough. Please, tell me the "correct" number of transactions for a civilization such as ours would create daily during normal activity. What is the "right" number and how should it be decided? Should the system exclude the transactions from someone making 100 trillion transactions per minute? What about 1 quadrillion per day? I suspect that this is an unanswerable, totally boring question. Instead, transactions should be based on batching and settlement, which is where the ideas for payment channels is coming from. There's also some recent talk on these lines called "lightning network". More broadly, see http://sourceforge.net/p/bitcoin/mailman/message/33405247/
Proof-of-Work (PoW) works because of the economic restriction provided by the second law of thermodynamics. Even though you can't know you're in the consensus set, you can put a raw economic cost on the probability of you being tricked. Bitcoin uses proof-of-work to tie Bitcoin consensus to a fundamentally scarce resource, namely negentropy. It is possible to use another physically scarce resource instead, but there is no alternative to the universal scarcity of negentropy. As maaku puts it, "I could be an AI trapped in a simulation with no knowledge of the outside world other than the foundational laws of physics, and from that be able to assert the validity of proof-of-work.".
As for Stellar and Ripple I would encourage you to read the recent d...
> Whether confirmations happen instantly (violating physical speed of light constraints imposed by reality) or take minutes or even months (ahem, Visa etc)
Visa payment confirmations take a second. Until settlements are final it takes 6 months because of chargebacks. However that's because of the Chargebacks and not because the system is incapable of settling quickly on the side of Visa.
The Bitcoin design does not permit that, because you cannot forcefully charge a user later or reimburse them. The protocol has no support for that.
> Please, tell me the "correct" number of transactions for a civilization such as ours would create daily during normal activity. What is the "right" number and how should it be decided?
The correct number is infinite. Whatever the amount of transactions is, the system needs to scale to that level. Banks have found various ways to achieve that by layering different systems together, Bitcoin however has no solution for this issue.
> As for Stellar and Ripple I would encourage you to read the recent discussion on HN where critical ledger vulnerabilities were enumerated quite thoroughly again: https://news.ycombinator.com/item?id=9341687
Those are only vulnerabilities if you already find the current banking system vulnerable. Fundamentally banks that exchange payments need to trust each other today. Ripple or Stellar just accept this and accept that as part of their designs. Within that frame of thought, the system is secure.
> "Does not scale"... well, to be fair, Visa also can't handle 100 quadrillion transactions per second.
It does not have to, because the system for the most part is a black box. How it works internally is irrelevant for the operation. If the Visa network would hit a technological stumble stone, they can replace parts of it or rewrite individual transactions. You cannot do that with Bitcoin.
> 51% attacks don't do what you think they do. Having lots of hashrate does not mean that consensus rules get thrown out the window. If that was true then the bitcoin network wouldn't have survived its first 12 months.
Having lots of hashrate can do quite a few things to your network. The reason bitcoin survived the first 12 months was a combination of many factors. If you want to bootstrap a cryptocurrency today that is bitcoin compatible you will have a problem on your hand. Miners just need to point their rig elsewhere and you're done.
> Hopefully my response has encouraged you (or someone else) to think carefully and critically.
> The Bitcoin design does not permit that, because you cannot forcefully charge a user later or reimburse them. The protocol has no support for that.
Well, yes, it's true that there's no direct "chargeback" primitive. But really giving someone back some fungible BTC is really just a matter of signing another transaction, which is already a primitive in the protocol or whatever.
> Whatever the amount of transactions is, the system needs to scale to that level.
.. even given the existence of physical limits? I suspect that a correct number is going to be "a system that allows any transaction to occur, but that prioritizes settlement" or something. This is the sort of problem that deserves stochastic simulation methinks.
> Banks have found various ways to achieve that
(Surely you don't mean infinite transaction volume. I'll assume for now that you don't.)
> Those are only vulnerabilities if you already find the current banking system vulnerable. Fundamentally banks that exchange payments need to trust each other today. Ripple or Stellar just accept this and accept that as part of their designs. Within that frame of thought, the system is secure.
Huh, actually I still disagree with you. So, I would argue that the current banking systems are using a different technical system for securing their accounts. They are not using decentralized consensus. They are not using "distributed systems". They are using something very different. They do not have to worry about replication failures or sybil nodes. Ripple, Stellar and Bitcoin all claim to, and I suspect only Bitcoin does based on my examination of their implementations and consensus mechanisms... [as elaborated in that link]
> they can replace parts of it or rewrite individual transactions. You cannot do that with Bitcoin.
Hmm that is an interesting claim. Do payment channels count as rewriting transactions? This is where transactions are replaced with successor transactions before they are confirmed in a block in the history. (my 2 second summary)
> Having lots of hashrate can do quite a few things to your network.
So 51% attacks (causing deep reorgs) can make their own coinbase transactions, change the order of transactions, fiddle with transaction malleability, exclude or censor transactions, include later transactions earlier in history. But they can't violate consensus rules (is not a trust issue), and I was replying to this aspect from your article text. Btw, reorgs happen quite frequently at the tip of the blockchain. Deep reorgs are exceedingly rare by comparison, but you can definitely catch a reorg of 1 to 3 blocks deep multiple times per day.
> [thinking carefully] I hope this goes both ways.
> Well, yes, it's true that there's no direct "chargeback" primitive. But really giving someone back some fungible BTC is really just a matter of signing another transaction, which is already a primitive in the protocol or whatever.
The point of chargebacks is that they exist on all payments in the creditcard network. When you pay with a creditcard you expect it, when you accept creditcard payments you do the same. Chargebacks are also not mandatory for Visa/Mastercard networks. For instance Maestro goes over the Mastercard network but settles much faster. It still allows reimbursing invalid payments but it's charged differently.
From a consumer point of view I think chargebacks need to be a strong element. Bitcoin might get this separately, but it needs this as a strong consumer facing feature: "this payment uses bitcoin insured" or whatever you would call it. Right now that does not exist and from my understanding, adding something like this would be nearly impossible to build, because chargebacks work as there are legal repercussions for misuse.
> .. even given the existence of physical limits? I suspect that a correct number is going to be "a system that allows any transaction to occur, but that prioritizes settlement" or something. This is the sort of problem that deserves stochastic simulation methinks.
Physical limits in what environments? Bitcoin right now does not survive a network partition which I think is a problem. Other systems exist that can allow subsets of the network to trade with each other and clear at a later point when the network heals. I don't argue for crazy things, I'm just arguing that Bitcoin cannot compete with already existing systems when it comes to scaling up to that level and providing the same level of service.
> Huh, actually I still disagree with you. So, I would argue that the current banking systems are using a different technical system for securing their accounts. They are not using decentralized consensus. They are not using "distributed systems". They are using something very different. They do not have to worry about replication failures or sybil nodes. Ripple, Stellar and Bitcoin all claim to, and I suspect only Bitcoin does based on my examination of their implementations and consensus mechanisms... [as elaborated in that link]
Banks have to deal with consensus as well if they engage in correspondence banking. Bitcoin attempts to guarantee that funds exist whereas banks don't do that. They send numbers around that are not based on anything. I think that's a big difference in philosophy more than anything else. Stellar and Ripple just attempt to modernize that aspect, provide it with a standardized protocol and replace humans with computers and to make it easier for new companies to participate in the network.
> Hmm that is an interesting claim. Do payment channels count as rewriting transactions? This is where transactions are replaced with successor transactions before they are confirmed in a block in the history. (my 2 second summary)
How would you go about tracking those payments then? As bitcoin has no real confirmation system for payments the current best bet you have is making an address up and waiting until something arrives there and then to wait for some amount of time until you can be reasonably sure that the money belongs there. With the Mastercard network right now (from my understanding) I can sever the links between Austria and the rest of the world, and I can still clear transactions from an Austrian account to an Austrian account and once the rest of the network reappears, nothing problematic happened. Bitcoin requires global consensus, so you cannot work on sub-partitions of the network.
> So 51% attacks [...] can't violate consensus rules
> From a consumer point of view I think chargebacks need to be a strong element. [...] right now that does not exist and from my understanding, adding something like this would be nearly impossible to build
A "chargeback" facility already exists-- if the sender and reciever choose to opt into it... E.g. https://www.bitrated.com/
How that feature set evolves will be interesting to see. The nice thing about it is that its optional and per the participants wishes, so it can take the shape and form suitable for the application.
> Bitcoin cannot compete with already existing systems
Are you referring to the Bitcoin currency or the Bitcoin network (as it exists today)? There are many ways to transact Bitcoin currency without directly using the bitcoin network (payment channels being one example) that can offer different tradeoffs while still preserving Bitcoin's base avoidance of centralized trust.
> How would you go about tracking those payments then?
Payment channel payments are purely between the participants. They can operate completely partitioned (and even offline).
The funds are effectively held in escrow in the Bitcoin network until the destination of the funds decides to terminate the channel and accept the greatest amount moved so far (or, if the receiver does not broadcast, the channel times out and the send can claw the funds back.)
5 comments
[ 4.1 ms ] story [ 20.0 ms ] threadWhether confirmations happen instantly (violating physical speed of light constraints imposed by reality) or take minutes or even months (ahem, Visa etc), does not seem to play any important role into whether something is fit for a consumer product. I'll give an example: even in the case of Visa's network, consumers are somewhat isolated from the long confirmation delays, and the costs imposed by confirmation delays are shoveled on to the merchants anyway. This is not because a centralized system like Visa requires that design, but rather because they made those choices when providing a product to merchants and consumers. Likewise, others have made similar products with bitcoin. That bitcoin confirmation delays are shorter has no bearing on whether a business can hold funds for 80000 days or whatever you want. This has little to do with suitability for productization. But perhaps this point is too nuanced for "a post that isn't technical".
My own opinion is that I don't really mind whether consumers are "directly" using bitcoin or not. I mean, I certainly don't care if they are manually bitbanging out their own bitcoin transactions or clicking buttons telling software to make transactions. That's a really trivial detail in the scheme of things....
As for being "completely incapable of handling transactions on the volume of the banking system itself", you mention settlement but I don't think you go far enough. Please, tell me the "correct" number of transactions for a civilization such as ours would create daily during normal activity. What is the "right" number and how should it be decided? Should the system exclude the transactions from someone making 100 trillion transactions per minute? What about 1 quadrillion per day? I suspect that this is an unanswerable, totally boring question. Instead, transactions should be based on batching and settlement, which is where the ideas for payment channels is coming from. There's also some recent talk on these lines called "lightning network". More broadly, see http://sourceforge.net/p/bitcoin/mailman/message/33405247/
Some argue that bitcoin is not "wasteful" because there is a real, meaningful use to byzantine agreement. I would recommend https://download.wpsoftware.net/bitcoin/asic-faq.pdf and https://download.wpsoftware.net/bitcoin/pos.pdf and https://download.wpsoftware.net/bitcoin/alts.pdf for some light reading on this subject.
Proof-of-Work (PoW) works because of the economic restriction provided by the second law of thermodynamics. Even though you can't know you're in the consensus set, you can put a raw economic cost on the probability of you being tricked. Bitcoin uses proof-of-work to tie Bitcoin consensus to a fundamentally scarce resource, namely negentropy. It is possible to use another physically scarce resource instead, but there is no alternative to the universal scarcity of negentropy. As maaku puts it, "I could be an AI trapped in a simulation with no knowledge of the outside world other than the foundational laws of physics, and from that be able to assert the validity of proof-of-work.".
As for Stellar and Ripple I would encourage you to read the recent d...
Visa payment confirmations take a second. Until settlements are final it takes 6 months because of chargebacks. However that's because of the Chargebacks and not because the system is incapable of settling quickly on the side of Visa.
The Bitcoin design does not permit that, because you cannot forcefully charge a user later or reimburse them. The protocol has no support for that.
> Please, tell me the "correct" number of transactions for a civilization such as ours would create daily during normal activity. What is the "right" number and how should it be decided?
The correct number is infinite. Whatever the amount of transactions is, the system needs to scale to that level. Banks have found various ways to achieve that by layering different systems together, Bitcoin however has no solution for this issue.
> As for Stellar and Ripple I would encourage you to read the recent discussion on HN where critical ledger vulnerabilities were enumerated quite thoroughly again: https://news.ycombinator.com/item?id=9341687
Those are only vulnerabilities if you already find the current banking system vulnerable. Fundamentally banks that exchange payments need to trust each other today. Ripple or Stellar just accept this and accept that as part of their designs. Within that frame of thought, the system is secure.
> "Does not scale"... well, to be fair, Visa also can't handle 100 quadrillion transactions per second.
It does not have to, because the system for the most part is a black box. How it works internally is irrelevant for the operation. If the Visa network would hit a technological stumble stone, they can replace parts of it or rewrite individual transactions. You cannot do that with Bitcoin.
> 51% attacks don't do what you think they do. Having lots of hashrate does not mean that consensus rules get thrown out the window. If that was true then the bitcoin network wouldn't have survived its first 12 months.
Having lots of hashrate can do quite a few things to your network. The reason bitcoin survived the first 12 months was a combination of many factors. If you want to bootstrap a cryptocurrency today that is bitcoin compatible you will have a problem on your hand. Miners just need to point their rig elsewhere and you're done.
> Hopefully my response has encouraged you (or someone else) to think carefully and critically.
I hope this goes both ways.
Well, yes, it's true that there's no direct "chargeback" primitive. But really giving someone back some fungible BTC is really just a matter of signing another transaction, which is already a primitive in the protocol or whatever.
> The correct number is infinite.
There are real physical limitations to information processing objects: http://diyhpl.us/~bryan/papers2/The%20physics%20of%20informa...
> Whatever the amount of transactions is, the system needs to scale to that level.
.. even given the existence of physical limits? I suspect that a correct number is going to be "a system that allows any transaction to occur, but that prioritizes settlement" or something. This is the sort of problem that deserves stochastic simulation methinks.
> Banks have found various ways to achieve that
(Surely you don't mean infinite transaction volume. I'll assume for now that you don't.)
> Those are only vulnerabilities if you already find the current banking system vulnerable. Fundamentally banks that exchange payments need to trust each other today. Ripple or Stellar just accept this and accept that as part of their designs. Within that frame of thought, the system is secure.
Huh, actually I still disagree with you. So, I would argue that the current banking systems are using a different technical system for securing their accounts. They are not using decentralized consensus. They are not using "distributed systems". They are using something very different. They do not have to worry about replication failures or sybil nodes. Ripple, Stellar and Bitcoin all claim to, and I suspect only Bitcoin does based on my examination of their implementations and consensus mechanisms... [as elaborated in that link]
> they can replace parts of it or rewrite individual transactions. You cannot do that with Bitcoin.
Hmm that is an interesting claim. Do payment channels count as rewriting transactions? This is where transactions are replaced with successor transactions before they are confirmed in a block in the history. (my 2 second summary)
> Having lots of hashrate can do quite a few things to your network.
So 51% attacks (causing deep reorgs) can make their own coinbase transactions, change the order of transactions, fiddle with transaction malleability, exclude or censor transactions, include later transactions earlier in history. But they can't violate consensus rules (is not a trust issue), and I was replying to this aspect from your article text. Btw, reorgs happen quite frequently at the tip of the blockchain. Deep reorgs are exceedingly rare by comparison, but you can definitely catch a reorg of 1 to 3 blocks deep multiple times per day.
> [thinking carefully] I hope this goes both ways.
Always. It's been a pleasure. :-)
The point of chargebacks is that they exist on all payments in the creditcard network. When you pay with a creditcard you expect it, when you accept creditcard payments you do the same. Chargebacks are also not mandatory for Visa/Mastercard networks. For instance Maestro goes over the Mastercard network but settles much faster. It still allows reimbursing invalid payments but it's charged differently.
From a consumer point of view I think chargebacks need to be a strong element. Bitcoin might get this separately, but it needs this as a strong consumer facing feature: "this payment uses bitcoin insured" or whatever you would call it. Right now that does not exist and from my understanding, adding something like this would be nearly impossible to build, because chargebacks work as there are legal repercussions for misuse.
> .. even given the existence of physical limits? I suspect that a correct number is going to be "a system that allows any transaction to occur, but that prioritizes settlement" or something. This is the sort of problem that deserves stochastic simulation methinks.
Physical limits in what environments? Bitcoin right now does not survive a network partition which I think is a problem. Other systems exist that can allow subsets of the network to trade with each other and clear at a later point when the network heals. I don't argue for crazy things, I'm just arguing that Bitcoin cannot compete with already existing systems when it comes to scaling up to that level and providing the same level of service.
> Huh, actually I still disagree with you. So, I would argue that the current banking systems are using a different technical system for securing their accounts. They are not using decentralized consensus. They are not using "distributed systems". They are using something very different. They do not have to worry about replication failures or sybil nodes. Ripple, Stellar and Bitcoin all claim to, and I suspect only Bitcoin does based on my examination of their implementations and consensus mechanisms... [as elaborated in that link]
Banks have to deal with consensus as well if they engage in correspondence banking. Bitcoin attempts to guarantee that funds exist whereas banks don't do that. They send numbers around that are not based on anything. I think that's a big difference in philosophy more than anything else. Stellar and Ripple just attempt to modernize that aspect, provide it with a standardized protocol and replace humans with computers and to make it easier for new companies to participate in the network.
> Hmm that is an interesting claim. Do payment channels count as rewriting transactions? This is where transactions are replaced with successor transactions before they are confirmed in a block in the history. (my 2 second summary)
How would you go about tracking those payments then? As bitcoin has no real confirmation system for payments the current best bet you have is making an address up and waiting until something arrives there and then to wait for some amount of time until you can be reasonably sure that the money belongs there. With the Mastercard network right now (from my understanding) I can sever the links between Austria and the rest of the world, and I can still clear transactions from an Austrian account to an Austrian account and once the rest of the network reappears, nothing problematic happened. Bitcoin requires global consensus, so you cannot work on sub-partitions of the network.
> So 51% attacks [...] can't violate consensus rules
I should probably reword that part.
A "chargeback" facility already exists-- if the sender and reciever choose to opt into it... E.g. https://www.bitrated.com/
How that feature set evolves will be interesting to see. The nice thing about it is that its optional and per the participants wishes, so it can take the shape and form suitable for the application.
> Bitcoin cannot compete with already existing systems
Are you referring to the Bitcoin currency or the Bitcoin network (as it exists today)? There are many ways to transact Bitcoin currency without directly using the bitcoin network (payment channels being one example) that can offer different tradeoffs while still preserving Bitcoin's base avoidance of centralized trust.
> How would you go about tracking those payments then?
Payment channel payments are purely between the participants. They can operate completely partitioned (and even offline).
The funds are effectively held in escrow in the Bitcoin network until the destination of the funds decides to terminate the channel and accept the greatest amount moved so far (or, if the receiver does not broadcast, the channel times out and the send can claw the funds back.)