When a new opennet node is created, we create 40 ConnectionTokens. A ConnectionToken is basically just a public/private keypair.
In order to validate the tokens and thus be able to use them, we ask 5 seednodes to sign our tokens. The seednodes require CAPTCHAs or some similar basic scarcity mechanism that can be dealt with during the installation process (one CAPTCHA per node, to sign the whole batch of tokens). Unlike WoT CAPTCHAs, these can be generated once for each challenge, with limits on how many can be sent per connection and IP address (no more than N over period T). These limits could perhaps be shared between the seednodes, possibly stored on Freenet in a similar mechanism to what is described below. CAPTCHAs would also have a time limit, to make it harder to reuse them or farm them out. Also, we can use any kind of centralised or networked captcha - for instance, the OCR-of-ancient-texts form - because the seednodes are not even pretending to be invisible. If you need to be invisible you need to use darknet, period. To actually use our tokens: - When we connect to a node, we present a ConnectionToken, with its initial validation. - Every X period, each node we are connected to issues a challenge. This is just a random nonce (with an appropriate prefix), plus the current time and our current IP address. We sign it using the token and return it. The token is then inserted, to two separate locations (for robustness). If the inserts collide, we disconnect and remove the node from our peers list. The location we insert a ConnectionToken to will depend on the hash of the pubkey and the time (quantised to the period X). The original token signature is checked, and so are the validation signatures. Hence these cannot be forged to boot a node off the network. Up to this point, we have created scarcity in simultaneous connections: For the price of solving a few CAPTCHAs, plus limits on IP address reuse, the announcee gains the ability to use 40 connections. We can then add two more layers: 1. We can limit by IP address overall. We route the inserts by IP+time, rather than (or as well as) by hash+time. Since every node involved can verify the validation signatures, there is no serious danger of spam attacks. We allow a certain, limited number of collisions - given an authority and a size limit, it is safe and reasonable to allow a single slot to return multiple results. A possible attack would be obtaining a bunch of tokens and then inserting tokens with a bogus IP address to deny access to a specific IP address or IP range. One way to deal with that would be forcing the inserter to prove posession of the IP address, e.g. by getting several seednodes to sign a dated certificate. This would mean more load on seednodes, and traffic to the seednodes every time you change IP address, but it would be small, and traffic to the seednodes every time you change IP is pretty much the reality already. Whether we want to limit by larger ranges is another question. It's possible but there are worries that if Freenet is popular on a specific ISP, there might be a legitimate reason for many people being on the same IP range? 2. We can require hashcash for renewals. Hashcash is problematic because slow computers and fast computers differ by a large factor in their abilities. However, if an attacker can obtain lots of CAPTCHA solutions relatively cheaply, it would be useful to have an ongoing cost for each announced identity. Even if that ongoing cost is relatively small it could be costly if the attacker is trying to overwhelm a large network. So the proposal is that initially we allow the node to connect just on the strength of the CAPTCHA, but after a certain time period we require a hashcash solution. This could be based on the identity hash, but it would probably be better if it was issued by the currently connected peer. It would be included in the insert, and would include the time of issuance with a fixed deadline for completion. It would be provably solvable (e.g. H(A | X) last N bits = Y, find X), and ideally would involve enough branching that GPUs don't help much. If the node changes connections, it would not go away, because the node would look up the previous insert and see the puzzle there. The deadline could be adjusted automatically for downtime: We don't want to make life more difficult for low-uptime nodes. We would use a TUK-style request, similar to what is proposed for IP addresses, to find the last such insert for the identity. Longer-term question: Can this help to solve the problem of WoT introduction without using CAPTCHAs? We could have the seednodes mint blind coins, possibly using scarcity in IPs and hashcash as well e.g. requesting a coin on the basis of a token? Interesting idea, but there is probably a simpler solution: We could assume the anti-Sybil mechanism described above works, and use exactly the same mechanism proposed for darknet: Each connection can generate one introduction token or Scarce SSK per X period per link. Which gives us an unspammable space which can be used for introduction to the WoT or DNS-style services. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101203/45d160da/attachment.pgp>
