Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: