IPv6 + IPv4 Co-existing together

Development & Technical discussion about Timekoin.
Forum rules
Bug Collecting Database is Click Here
GitHub Account is Click Here
User avatar
Posts: 131
Joined: Sat Sep 08, 2012 8:09 am

Re: IPv6 + IPv4 Co-existing together

Post by joanofarc »

koinmaster wrote:I agree to keep the two separate for currency generation, the rules for ipv4 have worked just fine for years, no need to mess with them. Maybe the v6 peers can try out the new method of doing some easy crypto work and checking the response and if a good, valid way to verify peers, maybe migrate that out to ipv4 someday.

I see nothing wrong with gateway peers, they perform an additional service they should get some extra currency for doing the double shift. If future does not need them, they will fade away for something better. I like that things in timekoin keep evolving, so I always support trying new things like this! :D
Timekoin is not completely "CPU free" you actually use some when doing the database polling and encryption processing, if someone does clone out thousands of IPs would it really work? It would be like needing *at least* thousands of Pi devices at each IP, even the lowly Pi times a thousand is still more than any server or desktop machine could muster speed wise?
Posts: 6
Joined: Tue Feb 18, 2014 1:47 pm

Re: IPv6 + IPv4 Co-existing together

Post by JohnES »

I started thinking about this and realized in IPv6, the smallest practical network prefix is 64-bits. Any larger prefix will break address auto-configuration, which assumes that the host can generate its own 64-bit address suffix automatically. We can safely assume that any number of addresses with the same 64-bit prefix are on the same end-user network.

Understanding this, we can limit abuse by limiting elections of generating peers to one peer per 64-bit prefix. Acquiring smaller prefixes is cost prohibitive, and the most common prefixes available for end use (58 or 60) only provide 16-64 possible 64-bit prefixes. This means even larger companies would only be able to get a handful of generating peers elected, while home users would have one 64-bit prefix per subscriber, keeping everything pretty fair.

This leaves potential issues with larger organizations with 48-bit prefixes. A 48-bit prefix would allow for potentially 65,000 elected peers. In this case, we could perhaps modify the election rules to slightly de-prioritize several election requests coming from within the same 48-bit prefix, making it just a little harder to get elected. The amount of time it would take to get all the addresses elected (and the cost of maintaining the 48-bit prefix from the ISP), I think would be just painful enough to deter anyone from trying this.

I think this, in combination with some kind of response time test (calculations, etc), as previously proposed, should tie the problem up nicely.
Post Reply