5 ms·

FBA does not require to know who your friends are you just need to know enough nodes. If some of the nodes are not your friend aka they lie to you, you would kn

by noxer 5y ago

FBA does not require to know who your friends are you just need to know enough nodes. If some of the nodes are not your friend aka they lie to you, you would know as soon as they lie and you can simply stop listen to them. This however requires identities. You cant just listen to anyone because someone could simply fire up 1000 lying nodes and if you pick 100 at random you'd have mostly lying nodes. You would figure out if they lie but then you have to stop listen to them all and you are offline. In practice this is not a real problem because obvious you would pick old nodes and not the 1000 freshly generated "identities". The assumption that you know nothing about any other node is a more or less made up thing for theoretical analysis that has no relevance in the real world. You dont start a network form zero you just want to join an existing one and you know its there so you might as well know who is there.

api 5y ago
Ahh, okay, but requiring identities means you must have a central authority to issue them or they must be extremely costly (proof of work or similar). Of course this doesn't make this useless. If identities are all you need then you've devolved the role of the central authority to nothing more than something that says who you are. If there is no provision for centralized identity revocation then you don't have a censorship problem because once you have an identity you have it forever. Identities could also be anonymized keys where only the central authority knows the true identity, minimizing privacy exposure surface area. Decentralization isn't boolean. This is more decentralized than Raft. Edit: I suppose proof of work for identities could be less costly than continuous PoW. The work required just has to be high enough to make sybil attacks expensive enough to meet your threat model threshold.
- noxer 5y ago
  >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. There is no authority needed. You decide if you believable a given identities to be who they calm to be. Lets say HN would run a node they would simply publish the public key on their website and if it has been there for weeks you can reasonably assume the page wasn't hacked and the key actually belong to the operators of HN. (The key can also be signed with the domain cert) It doesn't really matter that 100 other nodes could claim to be operated by NH too. There is no need for a central authority because every user can easily figure out which one is the real key. People can curate lists of nodes they "trust" and publish thous to make it easier for new people. Since everyone can publish such a list the curator of such a list is also no authority. The obvious downside of this is ofc that only existing "names" will be recognized. If you just say here is my key and I have a cool website then most people would not add you for a long time. (You can still participate in the network.) But this is also wanted because everyone should only add nodes that are reliable, have the proper hardware and maintenance and all that. Basically being part of the community helps to exclude someone who just make a bunch of identities that look like they belong to different people. Even if no one adds your node to the list you can still participate by relaying info form other nodes since the data is signed by the origin node someone who gets the data from you can still use that data even if it does not use your nodes data. There are a few ledgers running on these principles today most notably the XRPL[1] since 8+ years. [1]https://xrpl.org/intro-to-consensus.html https://xrpl.org/intro-to-consensus.html
  - 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.

by noxer 5y ago

api 5y ago

Ahh, okay, but requiring identities means you must have a central authority to issue them or they must be extremely costly (proof of work or similar). Of course this doesn't make this useless. If identities are all you need then you've devolved the role of the central authority to nothing more than something that says who you are. If there is no provision for centralized identity revocation then you don't have a censorship problem because once you have an identity you have it forever. Identities could also be anonymized keys where only the central authority knows the true identity, minimizing privacy exposure surface area. Decentralization isn't boolean. This is more decentralized than Raft. Edit: I suppose proof of work for identities could be less costly than continuous PoW. The work required just has to be high enough to make sybil attacks expensive enough to meet your threat model threshold.

noxer 5y ago
>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. There is no authority needed. You decide if you believable a given identities to be who they calm to be. Lets say HN would run a node they would simply publish the public key on their website and if it has been there for weeks you can reasonably assume the page wasn't hacked and the key actually belong to the operators of HN. (The key can also be signed with the domain cert) It doesn't really matter that 100 other nodes could claim to be operated by NH too. There is no need for a central authority because every user can easily figure out which one is the real key. People can curate lists of nodes they "trust" and publish thous to make it easier for new people. Since everyone can publish such a list the curator of such a list is also no authority. The obvious downside of this is ofc that only existing "names" will be recognized. If you just say here is my key and I have a cool website then most people would not add you for a long time. (You can still participate in the network.) But this is also wanted because everyone should only add nodes that are reliable, have the proper hardware and maintenance and all that. Basically being part of the community helps to exclude someone who just make a bunch of identities that look like they belong to different people. Even if no one adds your node to the list you can still participate by relaying info form other nodes since the data is signed by the origin node someone who gets the data from you can still use that data even if it does not use your nodes data. There are a few ledgers running on these principles today most notably the XRPL[1] since 8+ years. [1]https://xrpl.org/intro-to-consensus.html https://xrpl.org/intro-to-consensus.html
- 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.