4 ms·

"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

"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

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