On Thursday 25 Jul 2013 07:48:39 Peter Todd wrote: > On Mon, Jul 22, 2013 at 03:18:32PM -0500, Robert Hailey wrote: > > Judging from a business-process perspective, if it were up to me (and it's > > not!) I would elect to do these two options. > > > > Direct paypal > > .... for those that want it now (and they likely have a paypal account). I > > presume this is pretty easy. > > > > Vanilla Yubikeys > > ... for those who don't want to use paypal (but don't mind waiting). Atop > > of the base amount of work that the other mechanisms need anyway, this is > > trivial. > > > > In such a case, we then only alienate those who are both paranoid *AND* > > impatient; plus we give them a choice, and don't require that they obtain > > the yubikey in any particular way (only that it has the stock identity). > > > > What's more, implementing both of these options is probably simpler than > > implementing *only* a BTC workflow. > > Speaking of Bitcoins... > > As Matthew Toseland said at the top of this thread: > > > Surveillance: Connect to every node, log all the inserts for a month > > (freenet content doesn't last long if not requested). Connect it to > > announced content. Surprisingly cheap, given our relatively low > > bandwidth usage per peer etc, and it will become cheaper per node as the > > network grows because bandwidth (and everything else) gets *really* > > cheap in large volumes. This is a Sybil attack: The only way to beat it > > is by using some sort of scarcity. > > Have you guys looked into using Bitcoin fidelity bonds? Basically the > idea is you associate your pseudonym with the act of destroying or > giving away some Bitcoins - a scarce resource - thus making a normally > cheap pseudonym expensive. Since they are denominated in Bitcoins the > cost for the attacker is the same as the defender - often not the case, > eg. bandwidth or ip addresses which are much cheaper in bulk. Verifying > fidelity bonds (specifically the Bitcoin sacrifice proofs within them) > is quite cheap to do and requires only block headers - about 5MB of data > a year. > > Basically the security model is now an attacker has to outspend the > defenders in terms of Bitcoins sacrificed. Not perfect, but it may be of > value, especially in conjunction with other protections. They do have > potential anonymity issues, but we're talking about opennet where the > attacker knows your IP address anyway. There's also a varient of > proof-of-sacrifice where you prove you attempted to create Bitcoins, a > proof that has no linkage to any other Bitcoin transaction.
AFAICS this is a slightly more complex form of "pay to join", with the dubious advantage that nobody gets the money. In theory this might help people to not think we're scammers (although transient mode is more important to that end) ... but by the time you've explained it, you've lost them anyway, so I doubt it's worth the additional complexity. It's likely that for the foreseeable future, any attempt to charge an entry fee will result in losing a lot of nodes... (Not existing nodes, but potential nodes). > > Of course they could also be useful for anti-spam on FMS/Front/Sone and > so forth, especially as captcha-solving technology gets better. The > "puzzle" system is clever, but probably won't work forever. Yes. :( Bitcoin isn't all that anonymous at the moment, and isn't very convenient, and people's access to money varies enormously. There are other possible answers for spam-proof announcement for services inside Freenet, but only on darknet.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
