5 ms·

>All that matters is the valid history with the largest weight (longest chain rule in PoW). No, that exactly the believe that comes from BTCs implementation an

by noxer 5y ago

>All that matters is the valid history with the largest weight (longest chain rule in PoW). No, that exactly the believe that comes from BTCs implementation and while it may be true for BTC its completely irrelevant for other systems. Imagine there is a room full of people all have a paper with the exact same transactions in order on it. Now a new person joins and copies someones paper and then verifies all Tx. Ok, now he only has the chain for one person that's not enough he needs the chain form as much other people as possible to assure he has the longest. Its perfectly fine to ask the others to only tell him the hash of the whole thing to see if he has the same chain. So why even copy the chain first he could just start asking for the hash of the whole thing and if they all have the same there is no point to copy the chain. He just needs to copy the last state (balances) so he can add Tx as well. (BTC does not have accounts with balances so BTC does not have the concept of "only the last state" but instead of the whole chain only the ends of the tree can be used to reduce the size. but again this is ONLY relevant for BTC and BTC clones/forks its NOT a property of DLTs in general)

c01n 5y ago
>So why even copy the chain first he could just start asking for the hash of the whole thing and if they all have the same there is no point to copy the chain. Well if I control enough nodes I can send you fake hashes (51% attack).
- jimmydorry 5y ago
  51% is actually a different attack. The type of attack you are thinking of is called a Sybil Attack [1]. [1] https://en.wikipedia.org/wiki/Sybil_attack https://en.wikipedia.org/wiki/Sybil_attack
  - deleted 5y ago
    [deleted]
- noxer 5y ago
  See other message. Listening to a nodes is voluntary and secret you dont know who or if at all anyone listens to your node. If you simply created a bunch you can be sure no one will listen to them. It doesn't matter how many % they make up.
jimmydorry 5y ago
The model you propose is weak to sybil attacks [1] and is based on trust, while the BTC model is based on zero-trust. There is nothing stopping someone malicious from spinning up thousands of nodes that all say the current hash is Y (with transactions that break the rules of the blockchain) while the remaining minority of nodes say the hash is actually X (the original longest chain). It is only by calculating the hash yourself, based on the full transaction history, that your node can be satisfied that it is on the longest chain. _*After*_ you have confirmed that you have the valid chain, it is possible to prune all the history to just the balances and to only validate new blocks as they come in, but in the case of a fork or malicious actors, your node may end up out of sync. There may be other ways of tackling this issue that I am not aware of, but this problem in particular is one of the fundamental problems that Blockchains / Bitcoin were designed to solve (consensus among peers that is not disrupted by hostile actors). I have yet to see a better solution for this particular problem. [1] https://en.wikipedia.org/wiki/Sybil_attack https://en.wikipedia.org/wiki/Sybil_attack
- sillysaurusx 5y ago
  One way to sidestep this: every few minutes, post the longest hash to some distributed medium that can't be edited, like Twitter. Then the threat model moves to "do we trust the person with the keys to this twitter account?" However, this is also "zero trust," because you can write a program to verify every tweet as it's tweeted, and run that on a server somewhere. But, now that I've written this, I suppose Vitalik's "Limits to Blockchain Scalability" addresses this: even if it's theoretically possible to validate the hashes on a supercomputer somewhere, you want your users to be the ones doing this validation, because otherwise it would be possible to compromise the "zero trust" model described above by compromising one twitter account and N verification servers. When N is small, this might be a realistic concern, especially if the verification servers are continuously pulling code changes from a central source code repo.
  - TimJRobinson 5y ago
    If you write out to a centralized service like Twitter than you may as well just use a centralized database, it's much more efficient than a blockchain. A core property of a decentralized blockchain is that every person using the chain has equal opportunity to participate in the security of the chain, there are no "blessed users" and you should be able to use it without trusting any other user on it.

by noxer 5y ago

c01n 5y ago

>So why even copy the chain first he could just start asking for the hash of the whole thing and if they all have the same there is no point to copy the chain. Well if I control enough nodes I can send you fake hashes (51% attack).

jimmydorry 5y ago
51% is actually a different attack. The type of attack you are thinking of is called a Sybil Attack [1]. [1] https://en.wikipedia.org/wiki/Sybil_attack https://en.wikipedia.org/wiki/Sybil_attack
- deleted 5y ago
  [deleted]
noxer 5y ago
See other message. Listening to a nodes is voluntary and secret you dont know who or if at all anyone listens to your node. If you simply created a bunch you can be sure no one will listen to them. It doesn't matter how many % they make up.

jimmydorry 5y ago

The model you propose is weak to sybil attacks [1] and is based on trust, while the BTC model is based on zero-trust. There is nothing stopping someone malicious from spinning up thousands of nodes that all say the current hash is Y (with transactions that break the rules of the blockchain) while the remaining minority of nodes say the hash is actually X (the original longest chain). It is only by calculating the hash yourself, based on the full transaction history, that your node can be satisfied that it is on the longest chain. _*After*_ you have confirmed that you have the valid chain, it is possible to prune all the history to just the balances and to only validate new blocks as they come in, but in the case of a fork or malicious actors, your node may end up out of sync. There may be other ways of tackling this issue that I am not aware of, but this problem in particular is one of the fundamental problems that Blockchains / Bitcoin were designed to solve (consensus among peers that is not disrupted by hostile actors). I have yet to see a better solution for this particular problem. [1] https://en.wikipedia.org/wiki/Sybil_attack https://en.wikipedia.org/wiki/Sybil_attack

sillysaurusx 5y ago
One way to sidestep this: every few minutes, post the longest hash to some distributed medium that can't be edited, like Twitter. Then the threat model moves to "do we trust the person with the keys to this twitter account?" However, this is also "zero trust," because you can write a program to verify every tweet as it's tweeted, and run that on a server somewhere. But, now that I've written this, I suppose Vitalik's "Limits to Blockchain Scalability" addresses this: even if it's theoretically possible to validate the hashes on a supercomputer somewhere, you want your users to be the ones doing this validation, because otherwise it would be possible to compromise the "zero trust" model described above by compromising one twitter account and N verification servers. When N is small, this might be a realistic concern, especially if the verification servers are continuously pulling code changes from a central source code repo.
- TimJRobinson 5y ago
  If you write out to a centralized service like Twitter than you may as well just use a centralized database, it's much more efficient than a blockchain. A core property of a decentralized blockchain is that every person using the chain has equal opportunity to participate in the security of the chain, there are no "blessed users" and you should be able to use it without trusting any other user on it.