More on paid cjdns and network trust

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.

Trust

One of the first things to come up was: how should we determine trust?  Before discussing how to implement trust, we must first determine the parameters that must be met by this system.  We came up with the following:

  • Anyone can gain trust: any node on the network can gain a high level of trust by doing all the right things and not being evil
  • Trust must be easy to lose: if a node with a high level of trust consistently messes up, or does not follow the rule “don’t be evil,” then they must quickly and easily lose the trust that they had
  • It must be as automated as possible: we do not want subjective human opinions getting in the way of our carefully generated trust network
  • The trust of any node should be the same throughout the network: this one may not be as im

Now, on to the methods we discussed to establish trust:

Time Peered

This is very similar to what I proposed in my previous blog post.  Essentially, trust between two nodes would grow with time, as long as they remained successfully peered and payment and service continued on time and with little interruption.  The trust between each two nodes would then, in some way, propagate through the rest of the network.

Link Quality

Inspired by ideas set forth in Rainfly_x’s original blog post, link quality would determine the trust of a node by its routes, latency, and bandwidth.  Nodes with better values for these metrics would have better trust throughout the network.  Of course, then we run into the issue of how to run these link quality tests.  The only solution we came up with was to implement a two layer system, where the top layer is humans deciding which link quality testers they would trust, and then the system automatically determining the trust of nodes from there.  Unfortunately, this does break our automated rule, so we are open to suggestions on how to fix that.

“Core Network”

Cjd proposed this interesting idea: why not have trust originate from the “core network” of hyperboria, and then flow outwards from there.  We already have what many would consider to be the “core” of the network; that is, nodes such as seanode, forida.noble, fremont.noble (assuming derp doesn’t shut it down), and others.  This “core” could probably be determined by making a network map of hyperboria from multiple perspectives, and then determine which nodes have a high number of peers and are most in the center of the network.  As it is now, the core is fairly obvious if you look at a generated map (here or here).  This may or may not run into the same problems as link quality, with whose map to trust.  If this idea goes anywhere I will probably write a blog post on it some time in the future.

Uptime

Combining ideas from all of the previous, uptime would determine trust by the uptime of a node or link.  It would be determined similarly to “Core Network” or link quality, and be similar to time peered.  This is probably the most simple of all the ideas that came up, and I do not think it requires any more explanation.

Payment

The next thing I want to bring up from our discussion has to do with how to process payment.  This still follows many of the ideas that Rainfly_x set forth in his first blog post.  We need a method of payment that supports offline payments, to help first time users get onto the network, does not have high transaction fees (if any at all), and does not require a central authority.

Because of the problem with transaction fees, bitcoin probably should not be used for the everyday transactions.  This leaves us to use either Open Transactions or something totally new.

Open Transactions (OT)

I have not read up on OT as much as I maybe should have so far, but Dan seems to be a large supporter of it.  As I understand it, it currently has a couple issues, specifically with inflation and counterfeiting, but those should be addressed as the project matures.  If/when those are addressed, OT would almost perfect, considering that to my knowledge, it supports offline payments as well as other features we would find useful.

Other Ideas

We also floated a couple other ideas in case OT did not work out in the long run, only one of which actually has potential

Bitcoin clone

My (rather naive) idea was to make a currency similar to bitcoin, but that uses data transferred as a proof of work somehow.  We quickly found many issues with this proposal, and I am only putting it here in case it sparks some brilliant idea from a reader.

Multiple Currencies

Another of my ideas was to use have multiple currencies.  The group found this much more promising than my previous idea.  Essentially, it would work similarly to how currency worked in the US before the government introduced the USD.  The network would have multiple “banks,” each with their own currency.  Each node could decide what currency to accept, based on the trust of the banks (which goes back to our earlier discussion about trust in the network).  These currencies would probably be loosely based off of OT, with changes allowing the network to support multiple currencies.

Still, all of these have problems

Any currency that is specific to the hyperboria network – which is what we would like to have – still has one major issue: how to get on to the network in the first place.  While we talked at length about this, I do not feel that I have a good enough understanding of any of the proposed solutions to write about them.  We are still looking for ideas about this, and I will make another post once we have discussed this more.

Gateways

We also talked about gateways between hyperboria and the clearnet for a while.  However, I will save that for a later post, as it is not directly related to what I have written so far, and this post is currently well over 1000 words.

Conclusion(s)

To wrap it up, we had some potentially great ideas last night, and this could definitely be a jumping off point for future developments in paid cjdns and network trust.

Thank you for reading all this.  It is entirely possible that this post is riddled with errors; if it is, feel free to tell me about them.

To comment, or further discuss this, I am bentley on efnet and hypeirc, /u/matteotom on reddit, and my email is matthew.t.bentley@gmail.com.  Also, feel free to discuss this in the reddit comments (link coming soon, after I post to reddit).

3 thoughts on “More on paid cjdns and network trust

  1. Lucas says:

    I think even with the transaction fees on bitcoin it would be a useable currency in this situtation. Transaction fees are currently 0.0001 or $0.01 (aka one penny). Using bitcoin rapidly adjusting micropayments you would really only pay the fee every once in a while.

    See here for information about bitcoin micro transactions and how bitcoin already wants to use it for wifi hotspots.
    http://youtu.be/mD4L7xDNCmA?t=2m20s

    https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

    Open Transactions is awesome as well. If what your suggesting here is built it seems like a real win for building out a powerful sustainable network.

  2. Riccccardo says:

    With the proliferation of crypto-currencies out there these days, there really isn’t anything stopping anyone from starting HyperboriaCoin (HBC), issue out a lot of coin (more than the BTC 21 million, say 1 billion HBC), and make it a scrypt (Litecoin) derivative, because this allows even the small guys with CPU only miners to contribute since the difficulty to mine it would grow very slowly.

    If Hyperboria really takes off (I think it will), then the major crypto-currency exchanges would pick up HBC eventually and allow you to exchange it to Bitcoin, and eventually to your local currency.

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>