6 ms·

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 malicio

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.
- noxer 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?" The XRPL does this by broadcasting. Every node tells everyone what they think is right, therefore everyone can see who lies and more importantly no one can see who you listen too. Its hard to trick me if you dont even know whom I listen too. And you cant test it because once you lie to me you lie to everyone and that the last time anyone listened to you. The "zero trust" thing is an illusion. All decentral systems trust that the majority of something does "the right thing". Some system use the majority of hashpower other use other metrics and some lets you pick and include or exclude participants. BTC for example doesn't give you any options you simply trust that from 100% hashpower more than 50% is controlled by honest people. Its not zero trust its more like zero choice trust.
  - ric2b 5y ago
    > All decentral systems trust that the majority of something does "the right thing". There's a difference between assuming a majority of relevant nodes are honest and relying on your ability to identify that majority.
    - noxer 5y ago
      Yes, one thing is unavoidable, you have to assume that the majority is honest else the system simply can not work. Identifying the majority is however optional. BTC for example does not. You pick the longest chain you can find at a given time. You assume the majority saw the same as the longest. If a longer shows up you switch and again you assume the majority saw that too and switched swell. Other systems like the XRPL dont assume, every node defines from whom they want a majority. If 99% of them made a Tx final then there is no way that at a later point in time this final state can be changed because 1% can not ever reach a majority. The only thing that could happen is that the network forks and different parts of the network reach majority on different states. This problem is solved by raising the majority needed to 80% rather than >50% and on top of that is is further reduced by intentionally overlapping the nodes who are defined by each node. Essentially you need many nodes who listen to each other both ways. So I choose your node to be part of my nodes that must reach majority and you list my node. If you have 10 nodes all listen to the other 9 and require that form the other 9 80% agree then there is no way the network can ever fork. No 2 different states could ever reach 80%, its just not possible. Now these 10 nodes are publicly known so if you operate a node you have to pick from these nodes the one you want but you must make sure that your node can not reach a majority without them. So you could pick all 10 and then add for example 5 others. Your node can hen also not fork because the 5 alone can never reach an 80% majority. and so on and on. every new node must have ~80% overlap to prevent forking. And all of that is super simple because the nodes are public and use public key encryption to identify themself.
- ric2b 5y ago
  > some distributed medium that can't be edited, like Twitter. It this supposed to be a joke? Twitter is the exact opposite of that. > Then the threat model moves to "do we trust the person with the keys to this twitter account?" > However, this is also "zero trust," Ok, it's a joke.
noxer 5y ago
> while the BTC model is based on zero-trust. Its based on trusting that never more than 50% hashpower colludes You still trust its just no defined whom you trust. Its an illusion of no trust. Any decentral system can somehow be fooled if someone has a majority of "something". There is simply no way to prevent that. For BTC this is "something" is hashpower for other system like the XRPL it is the scarcity of mutual trust. But the quorum is actually 80%. And an attacker cannot know how much "mutual trust" his nodes have with others. >There is nothing stopping someone malicious from spinning up thousands of nodes that all say the current hash is Y Thats true but is irrelevant because the node decides whom it asks. And if it gets conflicting answers it would not accept a final state. As the owner of a node you add a list of other nodes that should be asked. Lets say you have 20 nodes on that list the fact that someone spins up thousands of nodes doesn't mean anything. No one connects to them and if they do only to send data or receive data that can be validated like a signed Tx. The nodes have no power. Listing to a node is completely voluntary. Obviously people listen to nodes which are publicly known who operates them and therefore it also clear that they are not operated by the same entities. In reality such nodes are run by exchanges, companies that use the network and universities that do blockchain research. But anyone could its just up to you how you convince anyone to use yours. Maybe you can create one that almost everyone will use. maybe even two. But your army of thousand nameless nodes is never gonna be added by anyone. They are just listing and if they speak no on listens to them. Also very important is the fact that a successful Sybil attack could not do much that's useful. Even if all the 20 nodes my node was told to listen to, declares a double spend as final, my node would not. You cant change the code I run and the code says the state is invalid. You created more tokens and that's not possible. It doesn't need to know the Tx that lead to this to know its wrong. The node would simply halt and all I have to do is remove the dishonest nodes from my list an add honest nodes and it keeps going. And the fact that a node lied is public so once an attack was attempted the node is "burned" no one will ever trust it again. In other words an immense amount of work and month and month more likely years of luring people into trusting all your nodes would give you the power to halt the network once (or more likely only a certain node) for an indefinite time (because it depend on human interaction) then all your work is toast. Assuming you would even manage to get enough nodes. You dont see who listens to your nodes so you fire blind and only have once shot. >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. The fundamental problem it solved was the double-spending problem without an arbitrator of truth. But it is technically only partially solved because there is no final state. However if you can reach decentral consensus over anything (a single bit) then the double spending problem isn't even a real problem anymore. If there are 2 conflicting transaction at the same time simply pick one that render the later one invalid because it attempts to move non-existing tokens[1]. Here is the doc about Sybil attacks on the XRPL https://xrpl.org/consensus-protections.html#sybil-attacks https://xrpl.org/consensus-protections.html#sybil-attacks there is probably more technical stuff to read about it the official forum threads from 2013 or so. [1] https://xrpl.org/consensus-principles-and-rules.html#the-double-spend-problem https://xrpl.org/consensus-principles-and-rules.html#the-dou...
Retric 5y ago
The solution is to use the hash power between points of consensus. Aka everyone thinks node A is state last year and here are the next N transactions resulting in the current state X. Sybil attack says no it’s actually B and here are the next N transactions resulting in state Y. You can compare the effort it takes for history A vs History B. Now, unlike traditional 51% attacks you don’t just need hashing power that instant but instead for very long periods. As such you can compute a minimum history such that actual 51% attacks are significantly cheaper. That might seem weaker, but Bitcoin’s trust is simply an economic argument. The actual consensus risk is from someone hacking a few nodes thus enabling a 51% attack at near zero cost.
- noxer 5y ago
  You mean like hacking a few mining pools like 4 and then performer 51% attack at near zero cost. Sounds silly but you get the point. The hacking argument is just not realistic. And it gets less and less relisting to more nodes there are. (and more realistic the fewer mining pools are needed for a 51% attack) BTW if you would have full control over any 4 XRPL validator nodes at your choice you could do absolutely nothing. No double spend, not even halt the network, nothing at all. You could turn them off and only a few nerds who constantly check the network would notice. User of the actual network would not.
  - Retric 5y ago
    The solution I posted isn’t based on consensus, like Bitcoin even 1 node with a stronger history should win. Validator nodes aren’t the weak points. It’s as you say the mining pools themselves, internally they need to be coordinated and have access to the Bitcoin network so they can’t be air gapped. So while all major pools have solid network security as they’re major targets, it’s still an actual risk.
    - noxer 5y ago
      The risk is probably way smaller than intentionally collude to make a shitton of money and let it crash and burn. The perfect exist scam if you want. If china for example would actually put an ultimatum on chines miners to shut down. It could potentially make perfect financial sense to leave with a big boom and make as much money as possible before closing.

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.
noxer 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?" The XRPL does this by broadcasting. Every node tells everyone what they think is right, therefore everyone can see who lies and more importantly no one can see who you listen too. Its hard to trick me if you dont even know whom I listen too. And you cant test it because once you lie to me you lie to everyone and that the last time anyone listened to you. The "zero trust" thing is an illusion. All decentral systems trust that the majority of something does "the right thing". Some system use the majority of hashpower other use other metrics and some lets you pick and include or exclude participants. BTC for example doesn't give you any options you simply trust that from 100% hashpower more than 50% is controlled by honest people. Its not zero trust its more like zero choice trust.
- ric2b 5y ago
  > All decentral systems trust that the majority of something does "the right thing". There's a difference between assuming a majority of relevant nodes are honest and relying on your ability to identify that majority.
  - noxer 5y ago
    Yes, one thing is unavoidable, you have to assume that the majority is honest else the system simply can not work. Identifying the majority is however optional. BTC for example does not. You pick the longest chain you can find at a given time. You assume the majority saw the same as the longest. If a longer shows up you switch and again you assume the majority saw that too and switched swell. Other systems like the XRPL dont assume, every node defines from whom they want a majority. If 99% of them made a Tx final then there is no way that at a later point in time this final state can be changed because 1% can not ever reach a majority. The only thing that could happen is that the network forks and different parts of the network reach majority on different states. This problem is solved by raising the majority needed to 80% rather than >50% and on top of that is is further reduced by intentionally overlapping the nodes who are defined by each node. Essentially you need many nodes who listen to each other both ways. So I choose your node to be part of my nodes that must reach majority and you list my node. If you have 10 nodes all listen to the other 9 and require that form the other 9 80% agree then there is no way the network can ever fork. No 2 different states could ever reach 80%, its just not possible. Now these 10 nodes are publicly known so if you operate a node you have to pick from these nodes the one you want but you must make sure that your node can not reach a majority without them. So you could pick all 10 and then add for example 5 others. Your node can hen also not fork because the 5 alone can never reach an 80% majority. and so on and on. every new node must have ~80% overlap to prevent forking. And all of that is super simple because the nodes are public and use public key encryption to identify themself.
ric2b 5y ago
> some distributed medium that can't be edited, like Twitter. It this supposed to be a joke? Twitter is the exact opposite of that. > Then the threat model moves to "do we trust the person with the keys to this twitter account?" > However, this is also "zero trust," Ok, it's a joke.

noxer 5y ago

> while the BTC model is based on zero-trust. Its based on trusting that never more than 50% hashpower colludes You still trust its just no defined whom you trust. Its an illusion of no trust. Any decentral system can somehow be fooled if someone has a majority of "something". There is simply no way to prevent that. For BTC this is "something" is hashpower for other system like the XRPL it is the scarcity of mutual trust. But the quorum is actually 80%. And an attacker cannot know how much "mutual trust" his nodes have with others. >There is nothing stopping someone malicious from spinning up thousands of nodes that all say the current hash is Y Thats true but is irrelevant because the node decides whom it asks. And if it gets conflicting answers it would not accept a final state. As the owner of a node you add a list of other nodes that should be asked. Lets say you have 20 nodes on that list the fact that someone spins up thousands of nodes doesn't mean anything. No one connects to them and if they do only to send data or receive data that can be validated like a signed Tx. The nodes have no power. Listing to a node is completely voluntary. Obviously people listen to nodes which are publicly known who operates them and therefore it also clear that they are not operated by the same entities. In reality such nodes are run by exchanges, companies that use the network and universities that do blockchain research. But anyone could its just up to you how you convince anyone to use yours. Maybe you can create one that almost everyone will use. maybe even two. But your army of thousand nameless nodes is never gonna be added by anyone. They are just listing and if they speak no on listens to them. Also very important is the fact that a successful Sybil attack could not do much that's useful. Even if all the 20 nodes my node was told to listen to, declares a double spend as final, my node would not. You cant change the code I run and the code says the state is invalid. You created more tokens and that's not possible. It doesn't need to know the Tx that lead to this to know its wrong. The node would simply halt and all I have to do is remove the dishonest nodes from my list an add honest nodes and it keeps going. And the fact that a node lied is public so once an attack was attempted the node is "burned" no one will ever trust it again. In other words an immense amount of work and month and month more likely years of luring people into trusting all your nodes would give you the power to halt the network once (or more likely only a certain node) for an indefinite time (because it depend on human interaction) then all your work is toast. Assuming you would even manage to get enough nodes. You dont see who listens to your nodes so you fire blind and only have once shot. >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. The fundamental problem it solved was the double-spending problem without an arbitrator of truth. But it is technically only partially solved because there is no final state. However if you can reach decentral consensus over anything (a single bit) then the double spending problem isn't even a real problem anymore. If there are 2 conflicting transaction at the same time simply pick one that render the later one invalid because it attempts to move non-existing tokens[1]. Here is the doc about Sybil attacks on the XRPL https://xrpl.org/consensus-protections.html#sybil-attacks https://xrpl.org/consensus-protections.html#sybil-attacks there is probably more technical stuff to read about it the official forum threads from 2013 or so. [1] https://xrpl.org/consensus-principles-and-rules.html#the-double-spend-problem https://xrpl.org/consensus-principles-and-rules.html#the-dou...

Retric 5y ago

The solution is to use the hash power between points of consensus. Aka everyone thinks node A is state last year and here are the next N transactions resulting in the current state X. Sybil attack says no it’s actually B and here are the next N transactions resulting in state Y. You can compare the effort it takes for history A vs History B. Now, unlike traditional 51% attacks you don’t just need hashing power that instant but instead for very long periods. As such you can compute a minimum history such that actual 51% attacks are significantly cheaper. That might seem weaker, but Bitcoin’s trust is simply an economic argument. The actual consensus risk is from someone hacking a few nodes thus enabling a 51% attack at near zero cost.

noxer 5y ago
You mean like hacking a few mining pools like 4 and then performer 51% attack at near zero cost. Sounds silly but you get the point. The hacking argument is just not realistic. And it gets less and less relisting to more nodes there are. (and more realistic the fewer mining pools are needed for a 51% attack) BTW if you would have full control over any 4 XRPL validator nodes at your choice you could do absolutely nothing. No double spend, not even halt the network, nothing at all. You could turn them off and only a few nerds who constantly check the network would notice. User of the actual network would not.
- Retric 5y ago
  The solution I posted isn’t based on consensus, like Bitcoin even 1 node with a stronger history should win. Validator nodes aren’t the weak points. It’s as you say the mining pools themselves, internally they need to be coordinated and have access to the Bitcoin network so they can’t be air gapped. So while all major pools have solid network security as they’re major targets, it’s still an actual risk.
  - noxer 5y ago
    The risk is probably way smaller than intentionally collude to make a shitton of money and let it crash and burn. The perfect exist scam if you want. If china for example would actually put an ultimatum on chines miners to shut down. It could potentially make perfect financial sense to leave with a big boom and make as much money as possible before closing.