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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
