[Some Support]

DavidXanatos, on 06 August 2013 - 08:21 PM, said:

Actually I think that even NeoKad once hardened and open sourced (not GPL though but something like http://piratepad.net/x43RU73nQN ) could be used by mods as there will be some kad for IPv6 needed as eMules kad is made for IPv4 only.

Obviously it cannot be used by any mods or forks of eMule under such a anti-FLOSS license.

(On a sidenote: I don't suppose you solved any of the IPv6 problems and if that's the case then it takes about one cmalicous client with a big pipe to bring the whole network down. I doubt that this is more future-proof then the IPv4 Kad, esp. since fairly large scaled attacks on Kad are made since years).

[DavidXanatos]

Some Support, on 07 August 2013 - 08:46 PM, said:

DavidXanatos, on 06 August 2013 - 08:21 PM, said:

Actually I think that even NeoKad once hardened and open sourced (not GPL though but something like http://piratepad.net/x43RU73nQN ) could be used by mods as there will be some kad for IPv6 needed as eMules kad is made for IPv4 only.

Obviously it cannot be used by any mods or forks of eMule under such a anti-FLOSS license.

(On a sidenote: I don't suppose you solved any of the IPv6 problems and if that's the case then it takes about one cmalicous client with a big pipe to bring the whole network down. I doubt that this is more future-proof then the IPv4 Kad, esp. since fairly large scaled attacks on Kad are made since years).

well, the only thing it can not be is linked with eMule's binary, but it can be very well redistributed as a separate process and be communicated with using pipes or sockets.
as explained in the FSF's GPL FAQ: www.gnu.org/licenses/gpl-faq.html#MereAggregation

NeoKad is not designed to be used as a library linked into various individual applications anyways, but to be installed on a system as service that always runs in background and provides its services to any application under whatever license that requests them.

PS: the license is not anti-FLOSS, it is only anti-Strong-Copyleft, it is perfectly compatible with FLOSS licenses like BSD or MIT and others: http://de.wikipedia....e:FLOSS-Lizenz.
Actually it is much more free and libre than the restrictive GPL.

PPS: to give you a hint how one can harden a system in a IPv6 environment, one could allow nodes at first to participate only in a limited way in the routing, and make them solve prove of work problems to so to say get credits to be allowed to full participate in the network. (-> bitcoin) This way an attacker does not only have to have the most IP's in the network but also the most computing power, much much much more expensive such an attack this makes, young Padawan.
And as I explained in a different thred already its not needed to be resilient against the NSA, its enough if it is not economically viable for the MAFIAA.

PPPS: This is actually of topic, so in case there are any objections to be disputed please split and lets continue the argument separately.

David X.

This post has been edited by DavidXanatos: 07 August 2013 - 09:22 PM

[Some Support]

DavidXanatos, on 07 August 2013 - 09:49 PM, said:

Actually it is much more free and libre than the restrictive GPL.

Not in my oppinion as you have additional terms which restrict developers, but besides this it's just pointless. All it does is disallowing it's use with the GPL without having any advantages. If If I would take that code and modify it, you would NOT be allowed to reuse it yourself (if I would republish the code at all, which I don't have to according to this license). So why care wether it is in a GPL or proprietary binary?

In any case, eMule is and always was a GPL project and obviously I don't support any tries to circumvent this (even if there are legal possiblities which result in ugly technical hacks) only so you can dictate terms on how to use it.

Quote

PPS: to give you a hint how one can harden a system in a IPv6 environment, one could allow nodes at first to participate only in a limited way in the routing, and make them solve prove of work problems to so to say get credits to be allowed to full participate in the network. (-> bitcoin) This way an attacker does not only have to have the most IP's in the network but also the most computing power, much much much more expensive such an attack this makes, young Padawan.

"Look we can make it like Bitcoin somehow - that works after all? How different can it be from Kad?". Right. It might work - i honestly can't say for sure because while I know how Bitcoins work in general, I didn't looked into all its inner mechanics. But one thing is certain: It is not a trivial matter of copying over Bitcoins sourcecode and it will work for Kad. It will need its own detailed concept. Once thats out, I'm pretty sure there are lots of people (inlucing me) and researchers who would love to look into that - after all, none of the researches who investigated possible attacks on Kad came up with a similar working idea yet.
IPs aren't a scarce ressource in IPv6 you can ignore that completely, but if an attacker needs more computing time than one can reasonable expect him to possess without interfering with the system load of valid users (normal users don't want to become miners, mind you) than this can be a solution. I don't see it yet, tho.

Quote

And as I explained in a different thred already its not needed to be resilient against the NSA, its enough if it is not economically viable for the MAFIAA.

Again, look at the current attacks against Kad.

[hooligan3000]

excuse my question
but how works the attacks against kad?

[DavidXanatos]

Quote

Not in my oppinion as you have additional terms which restrict developers

Well but it only restricts developers from restricting others.

Lets take a closer look on the license draft, shell we:

Text spinets from the MIT License
Text parts analogs to the clauses of the BSD license
Relevant new clause, changing everything
Backup Clause

P2P Community License
=====================
Copyright © <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software with the following restrictions:

1. No part of it may be included in software projects that are solely distributed
under strong copy-left restricted licenses, like GPL.
a. No part of this project can be put under a strong copy-left license.
b. Dynamic linking of this software or parts of it as a library is not
considered as an inclusion and is hereby permitted.

2. The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

3. All advertising materials mentioning features or use of this software must
display the following or equivalent acknowledgment: "This product includes
software developed by <copyright holders>, and its contributors."

4. Neither the name of the project nor the names of its contributors may be
used to endorse or promote products derived from this software without
specific prior written permission.

The authors of the original version reserve the right to put the entire project under
an arbitrary additional license including all contributions made by 3rd parties.

There otherwise exists no restrictions in using this software, including
without other limitation the rights to use, copy, modify, merge, publish,
distribute, sub-license, and/or sell copies of the Software, and to permit
persons to whom the Software is furnished to do so, subject to the
above conditions.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON
INFRINGEMENT.IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

As you can see the only restriction that is in place that isn't in the MIT or BSD license is the blue clause 1, that basically only prohibits other developers from limiting the freedoms granted by this license by infecting the code with some own GPLed code snippet.

Quote

All it does is disallowing it's use with the GPL without having any advantages. If If I would take that code and modify it, you would NOT be allowed to reuse it yourself (if I would republish the code at all, which I don't have to according to this license). So why care wether it is in a GPL or proprietary binary?

The advantage is that if you don't want me to to reuse the code you have to keep it for your self.
Those limiting greatly the chance of your code spreading and becoming in any way needed for the network.

And if you release it so that it may find its way into other releases we can freely use it in our MAFIAA prove closed source build.

With GPL you could prevent me from using my own, though by you slightly changed, code in my own projects, and thats a shit!
I put a lot of work into the NeoKad and why should people that possibly added only a few lines or at best a few pro-mil of code be allowed to dictate me how I can use the entire project?

And in case I should loose in future interest in maintaining the project we have the backup clause that would allow us to double license the code additionally under an incompatible licence like the GPL.

So as you see the license is free and very liberal and I thought about any eventuality.

Quote

In any case, eMule is and always was a GPL project and obviously I don't support any tries to circumvent this (even if there are legal possiblities which result in ugly technical hacks) only so you can dictate terms on how to use it.

Well, as we see form the above I don't dictate anything, I only prevent others form dictating me.

Quote

"Look we can make it like Bitcoin somehow - that works after all? How different can it be from Kad?". Right. It might work - i honestly can't say for sure because while I know how Bitcoins work in general, I didn't looked into all its inner mechanics. But one thing is certain: It is not a trivial matter of copying over Bitcoins sourcecode and it will work for Kad. It will need its own detailed concept. Once thats out, I'm pretty sure there are lots of people (inlucing me) and researchers who would love to look into that - after all, none of the researches who investigated possible attacks on Kad came up with a similar working idea yet.
IPs aren't a scarce ressource in IPv6 you can ignore that completely, but if an attacker needs more computing time than one can reasonable expect him to possess without interfering with the system load of valid users (normal users don't want to become miners, mind you) than this can be a solution. I don't see it yet, tho.

First of all, I don't copy source code over from any ware, all that is in NeoLoader binarys is is my very own code. All foreign code is located in DLL's.

I will write a detailed post on how to use Bitcoin techniques to harden Kad for an environment where IP's are not scarce later today.

David X.

[Some Support]

DavidXanatos, on 08 August 2013 - 06:24 AM, said:

Well, as we see form the above I don't dictate anything, I only prevent others form dictating me.

Because you convienently skipped the "Addition clause for networking applications" part.

Quote

infecting the code with some own GPLed code snippet.

The evil GPL cancer infecting other source. Where have I heard this before?

Well, there isn't much point discussing your little anti GPL crusade and at this point it doesn't really matters anyway, so lets leave it at this.

Quote

First of all, I don't copy source code over from any ware, all that is in NeoLoader binarys is is my very own code. All foreign code is located in DLL's.

Oh right.

Quote

I will write a detailed post on how to use Bitcoin techniques to harden Kad for an environment where IP's are not scarce later today.

I would like it if would take yourself a bit more time for this, but present a detailed, worked out concept for Kad which can really be evaluated rather than one which leaves too many questions open to actually understand it. Of course I'm not judging anything yet, I just doubt that a few hours are enough for that.

[fox88]

One interesting fact that I read about Bitcoin: the total amount of coins is fixed to avoid devaluation. That should not be very much suitable for a network where few peers stay nearly permanently while most come for relatively short time spans and then go away - possibly for good.

This post has been edited by fox88: 08 August 2013 - 08:20 AM

[DavidXanatos]

Some Support, on 08 August 2013 - 08:00 AM, said:

DavidXanatos, on 08 August 2013 - 06:24 AM, said:

Well, as we see form the above I don't dictate anything, I only prevent others form dictating me.

Because you convienently skipped the "Addition clause for networking applications" part.

Which is not longer part of the actual draft, but placed separately at the bottom with other source material links.

but lets take a look on it anyway:

Addition clause for networking applications:
5. Every in any way altered version of this software, must identify itself appropriatly during the initial phase of any network communication with other instances of this software.
a. The identification string must be unique and persistent for each distribution.
Usage of a random identifiers or an identifier already used by a different
distribution is strictly prohibited.
b. The identification string may be concatenated with a version or build identifier.
c. The placement and notation of the identification string must be implemented by
all modified versions of this software following the precedent set forth by the
original version.

Why does it limit your freedoms if you are prohibited form miss labelling your product as my product?
Its basically a trademark restriction nothing more.

Quote

I would like it if would take yourself a bit more time for this, but present a detailed, worked out concept for Kad which can really be evaluated rather than one which leaves too many questions open to actually understand it. Of course I'm not judging anything yet, I just doubt that a few hours are enough for that.

The concept is not being developed in a few hours just a synopsis formulated in clean English.
We have been working on the ideas for quite a long time now, actually.

EDIT: And here it is short explicit and in hopefully clean English:

The concept of using Bitcoin techniques is quite simple, we have to increase the cost of creating new identity's, sufficiently to make it not feasible for an attacker to provide a substantial portion of the networks nodes.To make this not to cumbersome for new users to use the network, we allow new nodes to participate with limited rights just from the start.So that for example the users can run searches and also publish them selves as sources, but they will be allowed to participate in the routing only in a limited way and will not be used to index content.This way for example we can already prevent eclipse attacks, as unverified nodes wont be able to send anyone on a wild goose chase.An other problem publishing spam entries can be tackled by making each file publishment cost the node some credits, to be obtained by prof of work. Simmilary to how NameCoin does it: http://de.wikipedia.org/wiki/NamecoinA central difference would be of cause that all publishments would have only limited lifetime, and our block-chain would not go back infinitely in time but would have to be truncated.The Complexity of a problem would also not be exponentially increasing with time for the network as bitcoin does, but on a network level constant growing only linearly with hardware capabilities. Also having a going long time back consensus record (out block chain) of node behavior would allow us to monitor node behavior and exile misbehaving nodes, as well as actually reducing the cost for nodes that are in for a reasonable time and are behaving well.

This system can be understood as a kind of a decentralized web of trust, as long as at attacker tries to infiltrate an already large network he will fail, though if he tries to infiltrate it form the very begin he will likely take it over. I don't see yet how this particular bootstrap issue could be solved algorithmically, a blond solution is to start the network closed and open it only once enough users have been found.

An important design aspect would be to make it unable to be faster than a normal users by employing Dedicated hardware, like litecoin.org did, by employing a prof of work problem that can not be simplified a lot using ASIC's, in their particular case they employ a problem that needs a loot of memory. http://en.wikipedia.org/wiki/Litecoin

Now please note that this is a concept that is under development, it is currently not implemented in a productive way.

Also thee system will have to be a little bit more complicated in order not to break the NeoKad inherent anonymity, that is obtained using recursive lookups. But thats not so difficult, a node will have in addition to its main identity, also a set of so called releaser identity's used to associate publications with. This ID's will not bee persistent, but only used temporarily, and it will not be a mater of public record what nodes are operating which releaser ID's.

Cheers
David X.

This post has been edited by DavidXanatos: 08 August 2013 - 11:19 AM

[Some Support]

Quote

EDIT: And here it is short explicit and in hopefully clean English

That is what I meant with leaving more questions open than answering. You describe what you would like to have (and the basic idea itself is of course not new), without telling HOW you want to achieve that. There isn't really any answer in this short description.

What I would like to know for example:
How does one node excactly becomes "privileged" to route? How does a standard Kad search works in your new system. How does a node verifies that every of those hundreds of results it gets is "allowed" to participate in routing and can be asked for closer results / added to its own routing table? Or do you trust all results you got from a valid node, so that the attacke just needs a single node in your search to mess it up? How much bandwidth overhead would this have on one single source? How much CPU overhead?

Where do you "obtain" your credits from when you want to publish? For every node you want to sent a store request too? How and why does this take an attacker more time than a valid client?

I see several other question, regarding new attack types based on such a sheme, how effective it really can be if you compare a slow valid user against one single attacker with specialized hardware (for example on bitcoin, on old Pentium 3 can mine 1MH/s while the best specialized rig can do 1,500,000 MH/s), what effect it will have on the network with all the nodes which do not participate in routing, etc

But as long as there is zero detail, there isn't a point to ask these questions yet. And it would be really a good idea to ask them BEFORE implementing it.

At least some diagrams, pseudo code etc would be really helpful.

Also lets ignore the "inherent anonymity" for the time being it doesn't makes sense to mix up two complex problems if there is no need to.

[DavidXanatos]

Quote

How does a node verifies that every of those hundreds of results it gets is "allowed" to participate in routing and can be asked for closer results / added to its own routing table?

The node does a search for each of the results retrieving the relevant pieces of the block chain to verify how much credits the nodes accumulated and for how long they are known in the network.

The block chains integrity is guaranteed in the same way bitcoin does it, so I will not explain it her in detail.

Quote

Or do you trust all results you got from a valid node, so that the attacke just needs a single node in your search to mess it up?

No, see above, see bitcoins way of ensuring the integrity of the block chain, a attacker would have to infiltrate more than the half of the trusted inner network to be able to start manipulating the block chain.
To do this he would need a loooot of time and a loooot of resources, more than should be economical viable, assuming he tries to attack a decent sized network and not a network with a hand full nodes that is in its infancy. Though even then while possible its still not economical reasonable.

Quote

How much bandwidth overhead would this have on one single source? How much CPU overhead?

This I haven't looked into yet, first the system must fully work than it will be optimized.

Quote

Where do you "obtain" your credits from when you want to publish? For every node you want to sent a store request too?

You solve prove of work problems, like in bitcoin to mine coins, solve problems ate counted in the block chain and attributed to your releaser ID, and you can use them once used they are marked as used.
While using them it is noted how long you set the validity of the published entry, so that the block chain can be purged form time to time.
You will not need credits for every request to every node, but only once for one particular packet to one particular TargetID. You wil be able to store the packet with it hashed content under a given target ID to every node who feels responsible for the target ID.

Quote

How and why does this take an attacker more time than a valid client?

It does not, but the point is that if an attacker can only participate like a normal user or a small bunch of normal users their influence will be negligible.

Quote

I see several other question, regarding new attack types based on such a sheme, how effective it really can be if you compare a slow valid user against one single attacker with specialized hardware (for example on bitcoin, on old Pentium 3 can mine 1MH/s while the best specialized rig can do 1,500,000 MH/s), what effect it will have on the network with all the nodes which do not participa in routing, etc

This actually is even explained in the short description, we don't use problems that can much faster be solved using specialised hardware, just like litecoin does. http://en.wikipedia.org/wiki/Litecoin
Litecoin uses scrypt in its proof-of-work algorithm: a sequential memory-hard function first conceived by Colin Percival.^[8] The original intended benefit of using scrypt was to avoid giving advantage to GPU, FPGA and ASIC miners over CPU miners, which occurs in the Bitcoin protocol. However, this turned out to be an incorrect assumption: GPU mining in Litecoin's implementation of scrypt is currently ten times more efficient than CPU mining.^{[citation needed]} FPGA and ASIC implementations are more expensive to create for scrypt than for SHA-256, which is used in the Bitcoin protocol.^[9]

As you see her the difference is by far not so drastic, if your choice of the problem is good.

David X.

This post has been edited by DavidXanatos: 08 August 2013 - 02:17 PM

[Some Support]

Alright, I will look into it once you finished its details (or created some paper).

I'm somewhat unconvinced this will work on several levels - starting that Bitcoin is a network of miners who actively like to dedicate lots of CPU power as they get "paid" for it going over the fact that such a Kad would have to do billions of transaction and even more verifications per day (bitcoin currently does about 50k per day), creating impossible levels of overhead up.

But then, I don't know enough about yet it to judge it and at this point I find it to murky to invest time looking deeper into it. It might work as a small network of supernodes. Or some other way. It will be interesting to see what you create out of it.

[Tuxman]

Some Support, on 08 August 2013 - 09:00 AM, said:

The evil GPL cancer infecting other source. Where have I heard this before?

The problem is that he's right here.
http://noordering.wo...pl-is-not-free/

[Zangune]

Are we really discussing the differences between GPL and BSD licenses?
Aren't Linux, BSDs' Unix derivates and Apple histories enough?

[Tuxman]

We are not discussing the differences, we are just discussing why the GPL is not a free license and (thus) should not be chosen.

[Some Support]

Tuxman, on 08 August 2013 - 05:41 PM, said:

We are not discussing the differences, we are just discussing why the GPL is not a free license and (thus) should not be chosen.

You state your oppinion as a fact. Those who choose the GPL for new projects clearly prefer its terms and conditions. Those unhappy with these terms are most often those who want to actually use code from others, which is GPLed without contributing it back. That's not surprising, when I write closed source stuff, I'm unhappy about each piece of code which I cannot use due to such a license too.

On the other hand, when I work for free and invest my time into code, my goal is to bring the project forward and on a bigger level to spread knowledge and not to help some copy and paste programmer to make some quick bucks by using my work in his proprietary product without providing any useful contribution to the project.

But I feel like this discussion is like 10 years old...

[Tuxman]

Some Support, on 08 August 2013 - 07:09 PM, said:

You state your oppinion as a fact.

At least I support my opinion with real-life examples (see the link for nice colorful pictures, pretty much explaining the issue).

Some Support, on 08 August 2013 - 07:09 PM, said:

Those unhappy with these terms are most often those who want to actually use code from others, which is GPLed without contributing it back.

You do know that one of the largest BSD-licensed pieces of software (namely FreeBSD) is contributed a lot of code which evolved from "closed source" improvements by Apple?

Some Support, on 08 August 2013 - 07:09 PM, said:

I'm unhappy about each piece of code which I cannot use due to such a license too.

You can freely use any code licensed under the terms of the BSD license for anything - which is not true for the GPL.

[Some Support]

Tuxman, on 08 August 2013 - 06:19 PM, said:

At least I support my opinion with real-life examples (see the link for nice colorful pictures, pretty much explaining the issue).

I don't see any issue in this real life example. Joe said "do with my code whatever you want" and Fred said "Only use my code that way". So if Joe wants to use Freds code, then thats how he has to do it. Those different views are discussed in the few comments on this blogpost.

Quote

You do know that one of the largest BSD-licensed pieces of software (namely FreeBSD) is contributed a lot of code which evolved from "closed source" improvements by Apple?

Yes and that's nice from Apple. But if they wouldn't be nice FreeBSD would be out of luck. You do know that the largest free OS - Linux - is using the GPL and profits from its terms and conditions?

Quote

Some Support, on 08 August 2013 - 07:09 PM, said:

I'm unhappy about each piece of code which I cannot use due to such a license too.

You can freely use any code licensed under the terms of the BSD license for anything - which is not true for the GPL.

I know and I was talking about the GPL in this context and explained why I find it ok that way in the next paragraph.

[Tuxman]

Some Support, on 08 August 2013 - 07:29 PM, said:

I don't see any issue in this real life example.

I do.

Some Support, on 08 August 2013 - 07:29 PM, said:

if Joe wants to use Freds code, then thats how he has to do it

If Fred wants to use Joe's code, he has to accept his conditions ("you are not allowed to decide about your code's license freely") too.

Some Support, on 08 August 2013 - 07:29 PM, said:

You do know that the largest free OS - Linux

"Large" in which way?

Some Support, on 08 August 2013 - 07:29 PM, said:

- is using the GPL and profits from its terms and conditions?

That's why most firewall operating systems are based on BSD: Linux is not useful in security-related environments where closed source enhancements are important.

This post has been edited by Tuxman: 08 August 2013 - 05:36 PM

[Some Support]

Tuxman, on 08 August 2013 - 06:34 PM, said:

I do.

I figured.

Quote

If Fred wants to use Joe's code, he has to accept his conditions ("you are not allowed to decide about your code's license freely") too.

Right.

Quote

"Large" in which way?

Quote

That's why most firewall operating systems are based on BSD: Linux is not useful in security-related environments where closed source enhancements are important.

Right, thats why for-profit companies use work from others, put in their own closed source "enchantments" so that they have an advantage over their competition and which will never find the way back to the original project then sell it for $$$. And for a firewall closed source is not an security advantage. If you are ok with that as a developer of the original project, that's fine. I would not be.

[DavidXanatos]

Some Support, on 08 August 2013 - 07:10 PM, said:

Right, thats why for-profit companies use work from others, put in their own closed source "enchantments" so that they have an advantage over their competition and which will never find the way back to the original project then sell it for $$$. And for a firewall closed source is not an security advantage. If you are ok with that as a developer of the original project, that's fine. I would not be.

I beg to differ!
May be working under the absurd assumption that your firewall is flawless you could be right.
But working under any remotely reasonable assumption your firewall is everything but flawless, and to break through it one just have to find the flaws you so meticulously hidden inside.
And well, if it is open source you need much less skilled hackers to find your screw-ups, than if it is closed and they have to dig through the entire disassembly.

Its the same case with my proprietary 2nd transport layer for NeoKad, of cause given enough manpower you can break in and start logging, but to do that you will need really good people for a lot of money,
in comparation if it would be all open source, any half brained moron could add some logging lines and press compile. And start screwing users.
Keeping this small yet essential part closed gives me a massive edge against the code monkeys from the MAFIAA.

And once they are in and burned through a pile of perfectly good money, I just upload an already for a long time waiting update and on the next day they can start on square one.

Making the MAFIAA burn their money is fun!

David X.