On 03/09/17 18:31, Matthew John Toseland wrote: > Thoughts? I'm not a dev any more, but thinking about Bitcoin and other > stuff maybe there are some ways forward that we've missed... > > Dispute resolution, spam and distributed data structures > -------------------------------------------------------- > > A key is disputable if: > 1) It is an SSK or similar signature-based type where multiple valid > values are possible, and > 2) It is popular enough for ULPRs et kick in, i.e. most nodes have > copies of and ULPR subscriptions to this key. > > For any disputable key, any darknet node can vote at most once. Votes > are relayed in a fixed path across the darknet, so that only one vote > passes a given directed edge for a given key. Ideally, votes are blind > while they are being routed; the previous iteration of the key publishes > a public key and then later broadcasts the private key. > > It follows that votes are pseudonymous (i.e. can be correlated), and > heterogeneous node degree may reduce some people's voting power. However > overall this should be Good Enough (tm). > > Disputable keys are used for the root of big distributed datastructures, > such as the set of all valid posters on WoT, a keyword search index, a > PKI indexed by any suitable identifier etc. (A block chain is of course > another way to do this) > > We can enforce any set of invariants on such data structures via the > voting system, as well as incorporating explicit user input. For example: > > The agreed root is the root of a hash tree. But we don't need to > traverse the tree: > - The index is divided by hash length into blocks of a large enough size > that the individual blocks won't fall out. > - The root includes the minimum and maximum USK offsets for all blocks > in the index. It includes the base hashes for this version and the last > few versions of the root. > - As long as this range is small, we can fetch a block directly by its > hash. The block will contain proof that it is included in the hash tree. > This proof includes the actual CHK nodes as blobs, which will be > randomly inserted/healed. > - Each node also includes version range information. > - All updates to the tree must maintain the invariant that the gap > between the minimum and maximum value is reasonable. We can enforce this > using the voting system above. In the absence of detectable attacks, > hashing should tend to ensure this anyway. > > Ideally there would be only one such tree, so that we could use classic > timestamping service tricks such as publishing the current hash etc. > > Thoughts on network architecture > -------------------------------- > > We can provide strong anonymity, and reasonable robustness guarantees on > a darknet. We can't achieve this on an opennet. We still need some sort > of guest mode, and we need strong incentives to move to the proper > darknet. So what should Freenet look like? > > Core darknet > - High uptime, reasonable bandwidth. > - Many F2F links. > - Eligible to participate in dispute resolution as above. > - Stores data permanently, i.e. has a store not just a cache. > - Some tunneling system similar to PISCES for privacy. > - Single coherent network. > > Non-core darknet > - Similar to darknet, but lower performance. > - May be penalised by load management. > - May have less access to dispute resolution because of having very few > links. > - May still use tunneling. > - In extreme cases (e.g. 1 link), lower security / need to trust peers more. > > Gateway nodes > - Hybrid, connect to both opennet and darknet nodes. > - Eligible to become a seednode; responds to announcements. > - May also qualify as core darknet nodes. > - Must be able to prove connectivity to the Core Darknet. > - Requests entering guests are treated as lower priority than > intra-darknet traffic, and reset HTL when they become true darknet traffic. > - Requests are never routed from darknet to opennet. > > Guest/opennet nodes > - Cache only. No store. > - User requests a set of gateways from a seed service. > - If true transient, entirely reliant on gateway. Requests are sent > directly to the gateway, possibly using tunneling. Tunneling requires > trusting the gateway, although if there are multiple gateways we can > compare them, especially we keep a versioned network map using the > dispute resolution mechanism.
Another detail: A network map is not used at all in darknet tunnel setup. It's not updated every time a link goes down. It may not even be updated when a node is added to the core darknet. It's just a trick to make it easier to detect when your gateway nodes are on different networks i.e. one of them is dishonest. > - If semi-permanent, can announce to gateways and get a bunch of opennet > nodes to talk to. Requests will be routed through local opennet for some > limited HTL, and then sent to gateway. > - Limited to no access to dispute resolution. > > Seeds: > - Any gateway may be a seed, and gateways' identities are assumed to be > public. > - Seed service maintains a list of gateways, demands some trivial proof > of work (e.g. CAPTCHA, unique gmail address a la Tor), and returns a > list of gateways and access tokens. > - Seed service requires gateways to prove their connectivity to core > darknet, and may implement its own scarcity, robustness and connectivity > policies. >
