3 ms·

>identities means you must have a central authority to issue them These are cryptographic identities. You create one by publishing the public key of your node.

• withinboredom 5y ago
  Doesn’t this mean you have to trust whomever made the list? Let’s say I have a pretty large following (I don’t) and I created my own trust list after accusing the authors of the “trusted list” or social engineering a situation that causes people to lose trust. Then I could take over the network with my “trusted” list. I’m sure people would figure out what’s going on, but now I’ve destroyed all trust in a trusted list and destroyed the network.
  • noxer 5y ago
    You make the list for your node. There are published lists but they are only a recommendation by whoever published the list. You may use one or many lists and/or add/remove nodes how you see fit. So you dont need to trust them you should trust your own list. However its importation to understand that if you happen to add a few non-honest nodes they cant cause any real damage. Since your node checks all the rules and signatures itself it can not be tricked into accepting malicious transactions + once such a node would "lie" it would be publicly visible for anyone. The "lie" would be signed by that nodes identity. So everyone knows whom to remove from the list. Meaning every non-honest node has to act honest forever it will be forever "burned" because its known "evil" once it didn't act honest. >I created my own trust list It would exist alongside every other already published list. If your list doesn't have a huge overlap with other existing lists its de-facto irrelevant because that would mean your list only contains unknown nodes and no one would use it. >causes people to lose trust They dont have to trust the list publisher, damaging the list publishes reputation is somewhat pointless the list itself or better the nodes on there stay valid. Lets say there are nodes on the list that run since 8 years have low downtime and never once tired to somehow harm the network. That "trust" doesn't go away. In a sense time or age is a trust indicator that can not be forged. You would need to reasonably proof that the nodes identity actually got transferred to someone else who wants to use it to harm the network. And you would need to do this for every node on the list that you want people to remove. >Then I could take over the network with my “trusted” list. If your list contains mostly nodes that you operate/control. And a majority of the other nodes actually would use your list and your list alone (not combine it with the existing lists) then maybe you could reach the 80% quorum which could be considered "taking over". You could for example vote in an amendment to change the code the nodes run. But for that you have to publish the code first and then the amendment would need 2 weeks 80% votes to become active. Whatever is in that code if its bad and 80% vote for it anyway it would be obvious that the yes voting nodes are compromised and all the honest nodes, again, simply have to remove them. Realistically no one would even install the software update if its not going through the official GitHub where the involved devs would want time for audits and all that before someone installs it. Also would most likely be installed on the test net which is centralized so it can be enabled fast and everyone can test it. So the most damage someone could do if he successfully compromise lots of validator nodes is that he could stop the network possibly for several days because people have to remove the nodes manually to reach consensus again. It would of course be very bad but at the same time its incredibly unlikely to happen and there is not much incentive to even try. Its not like you could print money if you stop the network.
• api 5y ago
  If that's the case and there is no cost, I still don't get how this is resistant to sophisticated and well-resourced sybil attacks. What's to stop someone from just firing up 10,000 nodes in the cloud?
  • noxer 5y ago
    No one listens to these 10k newly created nodes. If they all add each other to listen to each other they essentially create a fork as soon as they divert somehow from the rest of the network and no one would care. The attacker then has full control over the fork but again no one listens to it so its pointless. You would need to convince a majority of nodes to listen to your nodes and stop listen to the nodes who dont listen to you. There is zero reason why anyone would do this. Even if you could bribe some to do it, it would likely never be close to 80% and it would be incredible hard to hide the attempt. The number of nodes for each node to list to would need to drastically increase. If we do the math with 10 nodes to gain 80% control you would need to add 40 nodes so there is a total of 50 nodes and you control 80% of them. If you are one of the 10 nodes its obvious you would never add 40 new nodes in a short time. There is no benefit form adding many nodes anyway the goal is to have the most reliable and de-central nodes list possible not as many as possible. https://xrpl.org/consensus-protections.html#sybil-attacks https://xrpl.org/consensus-protections.html#sybil-attacks
  • isaacimagine 5y ago
    10,000 nodes are only as powerful as the amount of trust the rest of the network lends to them. If nobody trusts those nodes, they will have no impact. If the nodes all trust each other and a single outside node trusts one of them, that node is worth 1 vote, not 10,000. Under the Stellar Consensus Protocol, the people you trust is your 'quorum slice.' If you take a transitive closure of trust over all slices, you'll arrive at the set of nodes you rely on. The most trusted nodes will appear in a lot of quorum slices, and essentially form a core trusted quorum. An algorithm similar to PAXOS is run by all nodes, but the results in the core quorum will override outer nodes until consensus is reached. Thus as long as no malignant nodes are in the core quorum, they will not impact consensus. If a node confirms something contrary to what everyone else confirms, you know it is malignant. And in the rare case that a malignant node becomes highly trusted (which would mean it isn't acting malignantly), then confirms contrary, Stellar prioritized safety and will come to a halt until trust graphs are readjusted to remove the bad actor (which removal can be done automatically if it's provably acting malignantly, i.e. signing invalid messages.)