Jun 15 00:57:39 <john-connor-afk>	UDP datagrams can be dropped in mass without any disruption.
Jun 15 00:57:45 <_hightek>	he was actually saying that he is amazed by your work etc, so I don't think it was FUD
Jun 15 00:57:52 <_hightek>	he was just probably asking
Jun 15 00:58:06 <john-connor-afk>	The Bittorrent DHT for example uses ZERO re-tranmsission and it has 4 Million nodes.
Jun 15 00:58:45 <john-connor-afk>	+ This UDP database is only 100x more advanced than Kademlia.
Jun 15 00:58:48 <_hightek>	yeah, I read somewhere in a paper that UDP can be 100% reliable if the network is "strong" enough
Jun 15 00:58:49 <john-connor-afk>	It’s all nonsense.
Jun 15 00:59:24 <_hightek>	okay, thank you for clarification ^^
Jun 15 00:59:53 *	busoni (~busoni@unaffiliated/busoni) has joined
Jun 15 00:59:54 <john-connor-afk>	The reasn this is sorta BS is because you should never rely on nodes to even respond.
Jun 15 01:00:32 <john-connor-afk>	That said using RTO and the fastest route makes packet less moot in any situation.
Jun 15 01:00:50 <john-connor-afk>	Because multiple UDP packets are dispatched to many nodes for a single request.
Jun 15 01:01:01 <_hightek>	also read somewhere that having small packet sized actually helps driving up accuracy
Jun 15 01:01:06 <john-connor-afk>	Thsi redundancy makes re-tranmission an over-head and would be use-less.
Jun 15 01:01:07 <_hightek>	Oh, I get what your saying
Jun 15 01:01:09 *	BayMax has quit (Ping timeout: 256 seconds)
Jun 15 01:01:39 <john-connor-afk>	I compress packets to the tune of 300%. Read the code.
Jun 15 01:01:40 <_hightek>	so even if it has a 0.99% failure rate, since many nodes get the request it is unrealistic that it can fail
Jun 15 01:01:43 <_hightek>	to reach destination
Jun 15 01:01:45 <john-connor-afk>	Here let me show:
Jun 15 01:01:55 <john-connor-afk>			Slot #62
Jun 15 01:01:56 <john-connor-afk>			Storage Nodes:
Jun 15 01:01:57 <john-connor-afk>			 endoint:127.0.0.1:51941 uptime:130037 last_update:86 timeouts:0 rtt:2 stats_udp_bps_inbound:1164 stats_udp_bps_outbound:926
Jun 15 01:01:59 <john-connor-afk>			Slot #63
Jun 15 01:02:00 <john-connor-afk>			Storage Nodes:
Jun 15 01:02:01 <john-connor-afk>			 endoint:127.0.0.1:49221 uptime:130019 last_update:212 timeouts:0 rtt:1 stats_udp_bps_inbound:547 stats_udp_bps_outbound:522
Jun 15 01:02:02 <john-connor-afk>			 endoint:127.0.0.1:63721 uptime:130030 last_update:266 timeouts:0 rtt:0 stats_udp_bps_inbound:37 stats_udp_bps_outbound:33
Jun 15 01:02:05 <john-connor-afk>	33 bytes per second :D
Jun 15 01:02:40 <john-connor-afk>	Do you see I have the RTT for the entire UDP network?
Jun 15 01:02:48 <_hightek>	haha yeah, so with these sollutions the chances for transmission to fail is not statistically possible
Jun 15 01:02:53 <john-connor-afk>	You know the good routes already.
Jun 15 01:02:54 <_hightek>	impossible*
Jun 15 01:03:24 <john-connor-afk>	It is possible but the other packets all drop too? That is 100% unlikely.
Jun 15 01:03:41 <_hightek>	yep, I see where this is heading
Jun 15 01:03:59 <_hightek>	I'm hyped to see this in action, really nice way of implementing it.
Jun 15 01:04:03 <john-connor-afk>	[DEBUG] - next_message: Using slot# 10, for slot# 10
Jun 15 01:04:04 <john-connor-afk>	[DEBUG] - next_message: Using slot# 9, for slot# 10
Jun 15 01:04:05 <john-connor-afk>	[DEBUG] - next_message: Using slot# 55, for slot# 54
Jun 15 01:04:07 <john-connor-afk>	[DEBUG] - on_response: Got (5258) new node: 127.0.0.1:53603, Slot#40.
Jun 15 01:04:08 <john-connor-afk>	[DEBUG] - next_message: Using slot# 27, for slot# 27
Jun 15 01:04:10 <john-connor-afk>	[DEBUG] - next_message: Using slot# 55, for slot# 54
Jun 15 01:04:11 <john-connor-afk>	[DEBUG] - next_message: Using slot# 9, for slot# 10
Jun 15 01:04:13 <john-connor-afk>	[DEBUG] - next_message: Using slot# 24, for slot# 27
Jun 15 01:04:14 <john-connor-afk>	[DEBUG] - next_message: Using slot# 8, for slot# 10
Jun 15 01:04:16 <john-connor-afk>	[DEBUG] - next_message: Using slot# 9, for slot# 10
Jun 15 01:04:17 <john-connor-afk>	[DEBUG] - next_message: Using slot# 55, for slot# 54
Jun 15 01:04:19 <john-connor-afk>	[DEBUG] - next_message: Using slot# 24, for slot# 27
Jun 15 01:04:20 <john-connor-afk>	[DEBUG] - next_message: Using slot# 54, for slot# 54
Jun 15 01:04:22 <john-connor-afk>	[DEBUG] - next_message: Using slot# 55, for slot# 54
Jun 15 01:04:23 <john-connor-afk>	[DEBUG] - next_message: Using slot# 23, for slot# 19
Jun 15 01:04:25 <john-connor-afk>	[DEBUG] - next_message: Using slot# 27, for slot# 27
Jun 15 01:04:26 <john-connor-afk>	[DEBUG] - next_message: Using slot# 17, for slot# 19
Jun 15 01:04:28 <john-connor-afk>	[DEBUG] - next_message: Using slot# 16, for slot# 19
Jun 15 01:04:29 <john-connor-afk>	[DEBUG] - next_message: Using slot# 40, for slot# 42
Jun 15 01:04:32 <john-connor-afk>	^^
Jun 15 01:04:32 <john-connor-afk>	Nodes using backup paths.
Jun 15 01:04:32 <john-connor-afk>	IE* Slot 40 is faster to slot 42 so it uses it instead of slot 40.
Jun 15 01:04:53 <john-connor-afk>	I gotta go shower but I have cross my T’s,
Jun 15 01:05:17 <_hightek>	okay, thank you very much for the explanations
Jun 15 01:05:19 <_hightek>	have a good shower :D
Jun 15 01:06:02 *	VNLBOT removes voice from gaagaa
Jun 15 01:08:47 <john-connor-afk>	_hightek: I have patent for this design. It’s 10 years old and already deployed.
Jun 15 01:08:48 *	jimdigriz_mobile (~jimdigriz@5.172.234.103) has joined
Jun 15 01:08:52 <john-connor-afk>	You may have missed that.
Jun 15 01:08:56 *	jimdigriz is now known as Guest82386
Jun 15 01:09:04 *	jimdigriz_mobile is now known as jimdigriz
Jun 15 01:09:08 <_hightek>	john-connor-afk missed this bit of information, was probably afk or something, wow.
Jun 15 01:09:44 <_hightek>	and I guess that it's used on a bigger network, since that was the point of implementing it in this way :P
Jun 15 01:10:01 *	VNLBOT removes voice from WeedFreddy
Jun 15 01:10:41 *	Guest82386 has quit (Ping timeout: 252 seconds)
Jun 15 01:10:47 <mrM4D>	!cmc
Jun 15 01:10:47 <VNLBOT>	VNL | Pos: 92 | Cap: $224,055.20 | Price: $0.029 | Supply: 7,664,225 | Vol: 32.3974 | Change: 1.70%
Jun 15 01:10:56 <john-connor-afk>	Yes the same code runs a multi-million node network.
Jun 15 01:11:02 <john-connor-afk>	I own the patent.
Jun 15 01:11:13 <john-connor-afk>	It’s highly modified for VNL though.
Jun 15 01:11:46 *	minklemoss (4d0cc894@gateway/web/cgi-irc/kiwiirc.com/ip.77.12.200.148) has joined
Jun 15 01:11:57 <minklemoss>	evening all
Jun 15 01:12:33 <minklemoss>	!net
Jun 15 01:12:33 <VNLBOT>	Network: 277.66 GH/s | PoW: 12,153.88 | PoS: 1.29 | Blocks: 133,010
Jun 15 01:12:33 <VNLBOT>	PooledTX: 0 | Blocktime: 1434323296 (4m 16s) | Type: proof-of-stake
Jun 15 01:12:33 <VNLBOT>	pool01.vanillacoin.net | 58.52 MH/s | 2 workers
Jun 15 01:12:34 <VNLBOT>	vnl.suprnova.cc | 0 KH/s | 0 workers | Last:  117,832 (5w 2d 21h 11m 37s)
Jun 15 01:12:34 <VNLBOT>	vnl.idcray.com | 0 KH/s | 0 workers | Last: 117,830 (5w 2d 21h 14m 2s)
Jun 15 01:12:35 <VNLBOT>	www.nicehash.com | 0.00 GH/s
Jun 15 01:12:44 <john-connor-afk>	“The database mechanism of the system 10 illustrated in FIG. 3 will now be described in detail. In a system according to the invention, the peer-to-peer structure indicated by 90 in FIG. 2, a first client node (FC) 20 of the system 10 longing to store a credential object 110 at the first database node 120 thereof proceeds as follows:”
Jun 15 01:12:53 <john-connor-afk>	Patent ^^
Jun 15 01:13:02 <john-connor-afk>	Be back in 30 mins.