4 ms·

> 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

by 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. :-)

the_mitsuhiko 12y ago
> 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 I should probably reword that part.

by kanzure 12y ago

the_mitsuhiko 12y ago

> 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 I should probably reword that part.