More rough ideas for paid cjdns access

This is partially in response to rainfly-x’s post on the same topic.  I would recommend you go read this before reading what I’m writing.

When implementing paid bandwidth between nodes, the problem becomes: what do you do if a node accepts payment, but refuses to provide service?  After a short discussion with rainfly-x, we determined that it would not be to much of an issue if a node did this, because the payments would be small and an individual could simply blacklist the bad node.  However, we still want to limit the extent to which bad nodes receive payment as much as possible, to discourage people from making them.  Fortunately, nodes looking for payment would have to have verified speed tests from known sources, meaning not everyone with a wifi card could set up a bad node.

The most obvious solution to this issue is to have some sort of distributed black list, based off of some sort of web of trust (WOT).

How do we do this?

As the payer (client) and receiver of payment (server) continue to make payments and provide service, their mutual trust would go up.  When they first peer, trust would start at zero.  As time goes on, their trust would approach the maximum: 1.  Note that it would never actually reach 1, just continue to approach it.  At 1, the server and client would completely trust the black list of the other.  As it is, both the server and client would have to specify a value that would be considered “trustworthy,” above which they would accept black lists from the other, and below which they would not.

Now that we can establish trust, how do we determine the trust of a blacklist from a node that is not a direct peer?

It’s actually fairly simple: multiplication.  Each node will take the blacklist, with it’s trust values, from it’s peer, and then multiply each of those values by its own trust to that node.  For example: suppose we have nodes A, B, C, and D.  B and C have been peered for a while, and have a trust of 0.9.  B attempts to peer with A, and finds that A is a bad note.  That goes on B’s blacklist, with a trust of 1, because each node must trust itself 100%.  Then, B tells C about this.  C then multiplies B’s value by their mutual trust, giving C a value of 0.9 for the trust of the blacklist entry for A.  Assuming this is above the threshold that C has set for “trustworthy,” C will avoid peering with A in the future.  A couple days later, D peers with C.  Since their connection is new, their mutual trust will be low: let’s say 0.1.  When C passes its blacklist on to D, the value for A (0.9) gets multiplied by their trust, making D’s entry for A become 0.09.  This is likely much to low for D to trust, so D may attempt to peer with A in the future.

There are still a few things that need to be worked out before this idea would work properly:

  • First: how to deal with multiple peers giving me supporting or contradictory blacklist entries for a node?  Addition or subtraction would be first thing that comes to mind, but that cannot work because the trust must remain between 0 and 1
  • Second: How to ensure that a node doesn’t set arbitrary values for the trust of different entries?  The best answer I have at the moment is that each multiplication would have to be signed, but I’m not up to speed on how, exactly, that would work
  • Third: What would prevent a node from generating a new cjdns ip address, and then re-doing speed tests, so it is no longer on anyone’s blacklist?  Well, speed test operator would have to be on the lookout for speed test requests coming from the same physical location, but with a different ip address and pubkey.

Thank you for reading, I know this was a bit long.  Questions and comments can be directed to me on IRC (bentley on efnet and hypeirc), reddit (/u/matteotom), email (, or as a comment here (although I may or may not actually check those).

One thought on “More rough ideas for paid cjdns access

  1. [...] Last night, Dan, cjd, Rainfly_x, and myself had a nice long discussion about paid cjdns access, trust, and gateways.  This expands upon Rainfly_x’s ideas here and provides a lot of ideas at a higher level than my previous post here. [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>