4 ms·

> Whether confirmations happen instantly (violating physical speed of light constraints imposed by reality) or take minutes or even months (ahem, Visa etc) Vis

> 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 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.

kanzure 12y ago
> 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. > The correct number is infinite. There are real physical limitations to information processing objects: http://diyhpl.us/~bryan/papers2/The%20physics%20of%20information%20processing%20superobjects%20-%20Anders%20Sandberg%20-%201999.pdf 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. :-)

kanzure 12y ago

> 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. > The correct number is infinite. There are real physical limitations to information processing objects: http://diyhpl.us/~bryan/papers2/The%20physics%20of%20information%20processing%20superobjects%20-%20Anders%20Sandberg%20-%201999.pdf 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. :-)