4 ms·

> Technically, BitCoin is hardly scalable. As every participant needs to be aware of every transaction, that gives O(N^2) computational/storage cost, assuming N

> Technically, BitCoin is hardly scalable. As every participant needs to be aware of every transaction, that gives O(N^2) computational/storage cost, assuming N is participants and transactions~participants. That's not true. The Bitcoin protocol defines a "simplified payment verification" method that does not require clients to store the full block chain. The Bitcoin network does need a sufficient number of full clients to ensure that an attacker cannot get access to over 50% of the processing power in the network, but the number of full clients could be much lower than the number of simple clients. If Bitcoin ever becomes a major economy, the full clients will be sitting in data centers with lots of bandwidth, and most people will use simple clients.

gritzko 15y ago
So, the claim of being P2P goes to the wind first :) Second. When accepting a coin, a node needs to check the coin was not spent since the last time it changed hands. If the buyer claims he got it 1 month ago (and shows a proof), then the seller needs to check a month worth of transactions, just in case it was double-spent. Note the terrible asymmetry of the attacker's and the defender's costs. Third. Today I had to reread the paper (by Nakamoto) and I am surprised (again) by the level of wishfulness and naïveté. Sec 5 (page 3) says: "the nodes that were working on the other branch will then switch to the longer one". Does he realize that in a distributed system nodes might have totally different opinions on the number and length of those branches? And that those opinions might change. It is easy to imagine nodes hopping between branches with no global agreement possible. His very way of thinking has zero intuition about distributed/asynchronous systems, sorry. Obviously, that may be cured by introducing well-provisioned central sites, as you say. But then, all that crypto-trickery becomes entirely meaningless and the system loses its raison d'être. Well-provisioned mutually-recognized sites/banks may do it exactly the way they do it these days. Sorry for the rant.
- weavejester 15y ago
  "So, the claim of being P2P goes to the wind first" It depends on how pedantic you are about the term "P2P". I guess you could argue that any P2P network that includes supernodes is not a true P2P network, but in practise I've never heard that objection. "If the buyer claims he got it 1 month ago (and shows a proof), then the seller needs to check a month worth of transactions, just in case it was double-spent. Note the terrible asymmetry of the attacker's and the defender's costs." Not really. Finding out whether an address can spend a coin is just a hashtable lookup. It's not like we have to use linked lists! So the cost for the defender is trivial. An attacker, however, has to orphan the current block chain, which requires controlling at least 50% of the computational power in the Bitcoin network. For instance, let's say Alice gives Bob 1 BTC. Bob waits for 6 confirmations before accepting it as valid, which is the standard length the official Bitcoin client uses. This means that there is a chain of 6 blocks verifying the transaction; if Alice wants to double-spend, she needs to get rid of that chain, which she can only do if she can produce a longer alternative block chain. This means she has to produce blocks at a faster rate than everyone else on the network, which requires that she possess over 50% of the computational resources. "Does he realize that in a distributed system nodes might have totally different opinions on the number and length of those branches? And that those opinions might change. It is easy to imagine nodes hopping between branches with no global agreement possible." No, because clients always choose the longest block chain. It's possible that for a little while the block chain will branch, but that situation is inherently unstable; eventually one branch will produce a block faster than the other, and everyone will switch to the winning branch.
  - gritzko 15y ago
    Finding out whether an address can spend a coin is just a hashtable lookup. Trying to follow your perspective. You likely assume that every node has a dossier tracking every single coin. That dossier is summarized as a hash table. Right? there is a chain of 6 blocks verifying the transaction Does it mean a transaction needs 1 hour to settle or I'm confusing something for something? (1 block is created in 10 minutes) everyone will switch to the winning branch Well... suppose I'm an attacker who briefly mobilized some significant CPU resources (a GPU cluster, a million zombie PCs). I make nodes face two chains of equal length. Once new block arrives and nodes rush to the "winner" branch, I help the other branch win, so they rush back. You see, it is far more serious than "using it to defraud people by stealing back his payments" (Sec 6, last paragraph). The strategy of "alerts" (Sec 8) might be open to attacks as well. "Bad" nodes might also do alerts. etc etc ...and that is just off the top of my head. In very general terms, I also don't like the approach on the following reason. With strong crypto, I may encipher something, so even the biggest Google cluster will not be sufficient to break it any time soon. So, it is mathematically strong, in a sense. BitCoin weakens it to a majority vote in terms of CPU cycles uselessly burnt. That appears really weird to me.
    - weavejester 15y ago
      "Trying to follow your perspective. You likely assume that every node has a dossier tracking every single coin. That dossier is summarized as a hash table. Right?" Now I've had chance to think about it, it's probably a tree rather than a hash table, but the general idea is the same. There's no way you'd do a brute force O(N) search if N is very large. "Does it mean a transaction needs 1 hour to settle or I'm confusing something for something?" Yes, but it depends on how important the transaction is to you. If you receive the equivalent of $10, you may consider 1 confirmation enough, but if the amount was $10,000, then you'd probably want to wait for 6 confirmations just to make sure. The Bitcoin client tends to err on the side of caution, and considers transaction unconfirmed until they have 6 confirmations. "Well... suppose I'm an attacker who briefly mobilized some significant CPU resources (a GPU cluster, a million zombie PCs)" You'd need a lot of resources. The Bitcoin network currently runs at 17190 Tflops, which is about equivalent to 2.5 million desktop CPUs. If bitcoin ever becomes a major currency, this value will be much higher, and out of the range of most botnets. "I make nodes face two chains of equal length. Once new block arrives and nodes rush to the "winner" branch, I help the other branch win, so they rush back." What would be the point in doing that? "BitCoin weakens it to a majority vote in terms of CPU cycles uselessly burnt." What's the alternative? A centralized server is likely to be far more vulnerable to attacks (just ask Sony!).

gritzko 15y ago

So, the claim of being P2P goes to the wind first :) Second. When accepting a coin, a node needs to check the coin was not spent since the last time it changed hands. If the buyer claims he got it 1 month ago (and shows a proof), then the seller needs to check a month worth of transactions, just in case it was double-spent. Note the terrible asymmetry of the attacker's and the defender's costs. Third. Today I had to reread the paper (by Nakamoto) and I am surprised (again) by the level of wishfulness and naïveté. Sec 5 (page 3) says: "the nodes that were working on the other branch will then switch to the longer one". Does he realize that in a distributed system nodes might have totally different opinions on the number and length of those branches? And that those opinions might change. It is easy to imagine nodes hopping between branches with no global agreement possible. His very way of thinking has zero intuition about distributed/asynchronous systems, sorry. Obviously, that may be cured by introducing well-provisioned central sites, as you say. But then, all that crypto-trickery becomes entirely meaningless and the system loses its raison d'être. Well-provisioned mutually-recognized sites/banks may do it exactly the way they do it these days. Sorry for the rant.

weavejester 15y ago
"So, the claim of being P2P goes to the wind first" It depends on how pedantic you are about the term "P2P". I guess you could argue that any P2P network that includes supernodes is not a true P2P network, but in practise I've never heard that objection. "If the buyer claims he got it 1 month ago (and shows a proof), then the seller needs to check a month worth of transactions, just in case it was double-spent. Note the terrible asymmetry of the attacker's and the defender's costs." Not really. Finding out whether an address can spend a coin is just a hashtable lookup. It's not like we have to use linked lists! So the cost for the defender is trivial. An attacker, however, has to orphan the current block chain, which requires controlling at least 50% of the computational power in the Bitcoin network. For instance, let's say Alice gives Bob 1 BTC. Bob waits for 6 confirmations before accepting it as valid, which is the standard length the official Bitcoin client uses. This means that there is a chain of 6 blocks verifying the transaction; if Alice wants to double-spend, she needs to get rid of that chain, which she can only do if she can produce a longer alternative block chain. This means she has to produce blocks at a faster rate than everyone else on the network, which requires that she possess over 50% of the computational resources. "Does he realize that in a distributed system nodes might have totally different opinions on the number and length of those branches? And that those opinions might change. It is easy to imagine nodes hopping between branches with no global agreement possible." No, because clients always choose the longest block chain. It's possible that for a little while the block chain will branch, but that situation is inherently unstable; eventually one branch will produce a block faster than the other, and everyone will switch to the winning branch.
- gritzko 15y ago
  Finding out whether an address can spend a coin is just a hashtable lookup. Trying to follow your perspective. You likely assume that every node has a dossier tracking every single coin. That dossier is summarized as a hash table. Right? there is a chain of 6 blocks verifying the transaction Does it mean a transaction needs 1 hour to settle or I'm confusing something for something? (1 block is created in 10 minutes) everyone will switch to the winning branch Well... suppose I'm an attacker who briefly mobilized some significant CPU resources (a GPU cluster, a million zombie PCs). I make nodes face two chains of equal length. Once new block arrives and nodes rush to the "winner" branch, I help the other branch win, so they rush back. You see, it is far more serious than "using it to defraud people by stealing back his payments" (Sec 6, last paragraph). The strategy of "alerts" (Sec 8) might be open to attacks as well. "Bad" nodes might also do alerts. etc etc ...and that is just off the top of my head. In very general terms, I also don't like the approach on the following reason. With strong crypto, I may encipher something, so even the biggest Google cluster will not be sufficient to break it any time soon. So, it is mathematically strong, in a sense. BitCoin weakens it to a majority vote in terms of CPU cycles uselessly burnt. That appears really weird to me.
  - weavejester 15y ago
    "Trying to follow your perspective. You likely assume that every node has a dossier tracking every single coin. That dossier is summarized as a hash table. Right?" Now I've had chance to think about it, it's probably a tree rather than a hash table, but the general idea is the same. There's no way you'd do a brute force O(N) search if N is very large. "Does it mean a transaction needs 1 hour to settle or I'm confusing something for something?" Yes, but it depends on how important the transaction is to you. If you receive the equivalent of $10, you may consider 1 confirmation enough, but if the amount was $10,000, then you'd probably want to wait for 6 confirmations just to make sure. The Bitcoin client tends to err on the side of caution, and considers transaction unconfirmed until they have 6 confirmations. "Well... suppose I'm an attacker who briefly mobilized some significant CPU resources (a GPU cluster, a million zombie PCs)" You'd need a lot of resources. The Bitcoin network currently runs at 17190 Tflops, which is about equivalent to 2.5 million desktop CPUs. If bitcoin ever becomes a major currency, this value will be much higher, and out of the range of most botnets. "I make nodes face two chains of equal length. Once new block arrives and nodes rush to the "winner" branch, I help the other branch win, so they rush back." What would be the point in doing that? "BitCoin weakens it to a majority vote in terms of CPU cycles uselessly burnt." What's the alternative? A centralized server is likely to be far more vulnerable to attacks (just ask Sony!).