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

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