This seems like an amazingly centralized thing to do in software, the primary advantage of which is supposed to be its decentralization.
Ian. On Thu, Mar 27, 2014 at 10:24 PM, Matthew Toseland < [email protected]> wrote: > Proposal: > > Implement transient mode: > - No routing. > - No real anonymity (but may use tunnels later). > - Can do requests and inserts. > - Seednodes give transient node a Transient Announcement Token, and > relay the announcement, give the node a bunch of random peers. > - Such tokens are limited by time and IP address. > - Transient nodes get lower priority than "real" peers. > - Useful in some special cases e.g. webcafe, over Tor, etc, especially > if we have tunneling. > - Makes more sense than core opennet for people with really slow > connections who aren't on darknet. > > New installs: > - Start off in transient mode. > - Can add darknet peers. > - Can pay to become a Core Opennet Node. > - We can avoid most of the wizard questions, and talking about uptime, > until after the user starts looking at upgrading to core status. > - Make sure the node is working before taking payment; avoid a lot of > technical support aggravation! > > Payment: > - *One time fee* for creating a Core Opennet Node. > - Amount to be discussed. Lets say $5 (too low -> credit card overhead / > bitcoin inconvenience becomes dominant). > - Some of it may go to FPI. > - In the long run maybe other charities (would have to be a whitelist). > - If BTC, some of it may be provably destroyed (or recycled to miners). > - Payment mechanisms: > -- BTC. (Verifiable by anyone on the block chain, so not necessarily > centralised; can be somewhat anonymous) > -- Paypal. (Centralised, trust in FPI) > > Tunnels and verification: (Largely from PISCES) > - Every X period, we agree a peer list with our peers. > - This is timestamped and signed, and given to our peers, and inserted > to a known key. > - Nodes construct tunnels telescopically, downloading the peers list at > each stage, choosing a random peer from the list. > - Sometimes the node chooses not to use the tunnel, in which case it > requests the peer list for some of the nodes. > - If the peers list for a given node at a given timestamp is different > to that found, we have proof of dishonesty. > -- We can then insert this (using a special collision-detection > keytype), give the proof to the node's neighbours via the tunnel, and > blacklist the node. > - Modifications for opennet core nodes: > -- We only route to a node once it is in our published peer list. > -- We gather data that only our peers (not our tunnel partners) should > know: IP address, location, bandwidth used in last timeslot for each > peer, etc. > -- We add a nonce and then hash this; the hash is included in the peers > list for each node. > -- We exchange the full data when we add a connection, thus checking it > only with peers who need to know. > -- We can enforce length limits on peer lists, so an attacker who wants > to connect to 10,000 nodes will need to create 100+ nodes. > > Core Opennet Nodes: > - To create a Core Opennet Node Certificate, we need to pay, see above. > -- Bitcoin: Some of this is destroyed (or given back to the miners). > Some may go to FPI. > --- This is verifiable and transparent. > -- Also possible to pay FPI directly via paypal etc. > - Core Opennet Node Certificate includes > -- Location. This is fixed, so we cannot exploit announcement. > --- This makes MAST, announcement DoS and routing table injection much > much harder. > - Core Opennet Nodes have performance requirements: > -- Uptime (reasonably high, 80%?). > --- May be enforcible, at least partially. > --- Could involve seednodes, nodes chosen by some verifiable random > process, etc. > -- Bandwidth (significantly higher than current nominal requirement, say > 50KB/sec?). > --- Possibly require padding / CBR even if no traffic. > --- Could track bandwidth usage in peers list etc. > --- This could be enforced, if we use signatures from peers etc. Of > course our own fictional owned peers could lie, but this isn't > necessarily a problem, as they can't use those links to talk to the > network (most attacks limited by the number of connections you have into > the network). > -- Disk space. (Not enforcible, bad guys can have lots of disk space > anyway) > -- Actual performance. (To research; how to quantify?) > -- Failing to meet enforcible requirements can cause a node to be > dropped from the core opennet list. It can get back on however. > > Existing nodes get a Core Opennet Node Certificate for free on some > particular day prior to this infrastructure going live. An attacker > could get in at that point, but if he misses it, he'll have to pay. > > Some vague ideas about marketing: > - "You are now running Freenet! You can browse the content on Freenet, > but your node is in 'transient mode'. This means you are not > contributing to the network and have only minimal anonymity. You can: > Become part of the core (open) network: Faster performance, more > security. ($5). Become part of the dark network, maximum security, by > connecting to your friends (free)." > - Mention on the website, of course. > - Long term aim to have hardware Freenet boxes to solve uptime problem. > - Running darknet avoids paying. That's okay. We want people to run > darknet! > -- It may even help a little with viral growth. > -- But we probably lose some potential users... Is it worth it to have > security that isn't total crap? I don't know. > - People who want to contribute may actually be happy to pay a little as > a one-off. > - Will people see this as a scam / multi-level thing? > -- Probably not if we are honest on the webpage. No dangerous surprises. > -- It clearly isn't multi-level, as you don't get a part of the sign-up > fee for your friends if they use opennet; and if they don't, they don't > pay at all. > -- Even Java comes with a third party search toolbar; people's standards > aren't that strict. > > WoT introduction tokens: > - CAPTCHAs are clearly not a long term solution. > - We could blind tokens from an opennet introduction, but what about > darknet? > - Probably best to aim to create one mechanism for both darknet and > opennet. > - Something like the Scarce SSKs proposal, limited by the number of > connections you have. > > > _______________________________________________ > Devl mailing list > [email protected] > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- [image: OneSpot] <http://www.onespot.com/> *Ian Clarke* / Co-Founder & CTO Email: [email protected] Web: http://www.onespot.com Personal Blog: http://blog.locut.us/ LinkedIn: http://www.linkedin.com/in/iancjclarke _______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
