Published on: 2015-10-20T06:31:16+00:00
Rusty Russell and Anthony Towns discussed the frequency of channel updates to be sent over IRC in the Lightning-dev mailing list. Rusty estimated that pubkey-channel-relationships would be relayed every 10 days at approximately 264 bytes, while node addresses/IP would be sent every 12 hours at around 133 bytes, and channel-status would be sent once an hour at 176 bytes. However, Rusty noted that sending updates once per hour might be optimistic as channels approach exhaustion. Rusty's design point was for 1 million nodes, ideally on a cell phone.In the short term, Bitcoin used IRC as the peer protocol because it was easy to debug and implement. Rusty plans to aim for that while researching more ambitious proposals. Anthony agreed with Rusty's plan and suggested being able to log the entire network dynamics. Doing the above estimates over IRC would require doubling the byte size to encode keys/sigs into hex and adding about 32B per message for IRC protocol overhead.Assuming approximately 10 channels per node, the estimated bytes per node per day would be 560B for pubkey-channel-relationships, 564B for node addresses/IP, and 384B for channel-status, respectively, totaling 93,284B/node/day. Rusty acknowledged that they would get kicked off freenode long before reaching that number but believed it would allow them to master the other parts of the protocol first, up to a few hundred nodes.Rusty Russell has proposed using IRC as the peer protocol for the Lightning Network. The network includes three types of information that need to be shared: pubkey-channel-relationships, node addresses/IP, and channel-status. These three types of data are static and relayed every 10 days, every 12 hours, and once an hour respectively. The estimate for the size of these transmissions is 264 bytes, 133 bytes, and 176 bytes respectively. While these estimates seem reasonable, Russell believes that once per hour transmission may be optimistic when channels approach exhaustion.The goal for the Lightning Network is to accommodate one million nodes, ideally on a cell phone. Bitcoin used IRC as the peer protocol in the short term. Rusty Russell plans to use IRC as well while researching more ambitious proposals. He also wants to log the entire network dynamics. However, doing this over IRC would require doubling the byte size to encode keys/sigs into hex and adding maybe 32B per message for IRC protocol overhead. This would result in 560B/channel/10 days, 298B/node/12h, and 384B/channel/1h. Assuming ~10 channels per node and converting to bytes/node/day, this results in 560B/node/day, 564B/node/day, and 92,160B/node/day. Therefore, the total is 93,284B/node/day which is about 1.054 KiB/s per thousand nodes. If a single server relays this to a thousand nodes, that’s 8.2 megabit/s outgoing already. Thus, the plan probably maxes out somewhere between 500-3000 nodes. Finally, it is noted that bitcoin only used IRC to get IP addresses to connect to, which were encoded in the nicks used, rather than anything being actually said. It seems like that got up to 10000 nodes.In this communication, Mats Jerratsch introduces three different broadcast messages that require different handling. The first message is Pubkey-Channel-Relationships which is static and relayed every 10 days, with a size of 264 Bytes. The second message is Node addresses/IP, which depends on the nodes, with dynamic/static IP and approximately sent every 12 hours, with an estimated size of 133 Bytes. The third message is Channel-Status (capacity, fee, ...) that varies highly depending on actual traffic and node usage, and it should be sent once an hour with an estimated size of 176 Bytes.Rusty suggests that when channels approach exhaustion, fees may rise significantly, and you want to know if capacity is sufficient for the amount you're sending. A random beacon model requires only partial topology knowledge, which makes these numbers scale much better. However, it introduces another factor. Rusty suggests realizing it as some kind of gossip protocol or using some DHT approach. Bram Cohen was supportive of using BitTorrent's DHT for (1 and 2). For #3, they need their own inline protocol. A new node would want to retrieve the full dataset before opening a channel with a new node. So they need to design a way of retrieving the full dataset for fresh nodes, probably in some load-distributed way.In the short term, Bitcoin used IRC as the peer protocol. It is easy to debug and trivial to implement, so Rusty aims for that while they research their more ambitious proposals.The author is discussing three different broadcast messages that require different handling due to their varying levels of dynamism.
Updated on: 2023-07-31T18:24:21.840890+00:00