Hi, > > If the user doesn't want to pay much with the tradeoff of less security, the > incoming-connection fee and outgoing connection payments could be chosen in a > way that they zero each others out. > If the user wants high security, he could chose higher incoming connection > fees and pay lower outgoing connection fees.
So, if $BADGUY wants to ensure that he is a large part of the network he will simply set his incoming fee to zero and everybody will happily connect to him, anyway. Greetings, -- * David ‘Bombe’ Roden <[email protected]> On 11.06.2014, at 16:51, xor <[email protected]> wrote: > Signed PGP part > I haven't read most of this thread, but there are some things which I have to > say nevertheless > I think we can agree that the whole problem of Opennet attacks, in particular > Sybil attacks, is the scarcity problem: How can we make the resource of > Freenet nodes / user identities / pseudonyms scarce enough to ensure that 1 > attacker cannot pretend to be 10000 entities? > > I've discussed this problem for years with everyone because WOT also depends > on its solution: Someone MUST NOT be able to generate 100000 trusted > identities to ensure that Sone, Freetalk, etc. cannot be spammed. > > Further, it applies to the Internet as a whole. For E-Mail is spammed because > mail addresses are NOT scarce. > > There seem exactly 3 solutions to it: > 1. Centralization / government / moderation: A single entity is given the > trust to validate other identities. This approach is used in most of the > Internet, which is also why privacy on the net sucks. Of course Facebook > cannot be spammed because they moderate heavily, but they are also one hugh > company with the data of BILLIONS of people. > We should NOT want this as its completely opposite to the goals of Freenet. > > 2. Catpchas. Some believe they are safe because their complexity can be > arbitrarily increased, some believe that anything which is too difficult for > software to solve cannot be solved by humans as well. > > 3. Hashcash. Bitcoin has solved this in a beautiful way. I would go as far as > saying that the Bitcoin algorithm is NOT something which solves the problem of > creating digital money. It rather solves the abstract problem of generating > scarcity on the Internet, and the fact that digital money can be generated > using this is just a coincidence. > > Any solutions which people usually mention fall into one of these categories. > Now while you might have noticed that I am rather pro-Bitcoin, I would still > say that I am unbiased enough to claim that it is the best solution of > generating scarcity which exists nowadays. And it probably already has > millions of users, and a load of developers working on it (3800 forks on > Github at the moment). > So I think IF we go for the rather strange approach of making people pay for > Freenet, we should use the de-facto standard of Bitcoin instead of re- > inventing the wheel. > Good thing is: There is already a Java implementation of it (bitcoinj). > > As for the implementation, how about this - notice that it would still be > decentralized: > 1. Allow users to configure an arbitrary Bitcoin fee which people who want to > initiate an incoming connection to the users node need to pay. If someone > wants to attack your node specifically, he then needs to pay enough so most of > your connections belong to him. There could be both an initial connection fee > and a continuous per-time-connected fee. > 2. Allow the user to give Freenet an arbitrary amount of Bitcoins which it may > spend on outgoing connections to other peers. Ideally it would automatically > chose peers which are cheap enough so a sufficient amount of connections are > outgoing (50% outgoing, 50% ingoing would probably be the natural senseful > division). > > Seed nodes would then serve as some kind of marketplace where connections are > traded. > If the user doesn't want to pay much with the tradeoff of less security, the > incoming-connection fee and outgoing connection payments could be chosen in a > way that they zero each others out. > If the user wants high security, he could chose higher incoming connection > fees and pay lower outgoing connection fees. > > Bonus: > - Setting required and paid fees to zero would emulate the existing Opennet > behavior. > - The ability to earn money would encourage people to use Freenet. > - It is still a decentralized solution. > > But a very bad side effect might be that EVERYONE will set their incoming > connection fee higher than outgoing payment, resulting in the network to break > completely because nobody will have many connections because nobody is willing > to pay for them. This might be prevented by not allowing the user to chose > fees freely and instead only implementing automatic adjustment of the fees > with some configurable bias (for example security levels LOW, MEDIUM, HIGH), > hoping that people are too lazy to patch their node so they can chose > arbitrary fees. > > As for when to implement this: We haven't even made Darknet as easy to use as > it could be, so I don't think there is a justification for this now. > Further, Bitcoin still needs some time to mature. I'd see we should at least > way until the problem of making Bitcoin truly anonymous is solved: > - Currently it is pseudonymous only: Bitcoin addresses do not tell anything > about your identity, and you can generate as many of them as you want to. > However, the transaction history between all addresses is stored in the > network FOREVER because it is technically necessary. There are several > solutions available to this (CoinJoin, stealth addresses, ZeroCoin), and they > are still under development. > - The existing Bitcoin node implementations don't make any effort to NOT tell > the other nodes which addresses belong to your IP. You still need to run it > behind Tor to get true pseudonymous addresses. > > Still, there is a huge incentive of making Bitcoin anonymous as it is by > nature something which is interesting for governments to screw its users. So I > would say we just have to wait for it to be anonymized, it will happen. > > Greetings, > xor > > _______________________________________________ > Devl mailing list > [email protected] > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
