[Lightning-dev] Specifications of Broadcasting Layers
Rusty Russell
rusty at rustcorp.com.au
Tue Oct 20 06:31:16 UTC 2015
Anthony Towns <aj at erisian.com.au> writes:
> On Mon, Oct 19, 2015 at 11:18:30AM +1030, Rusty Russell wrote:
>> > (1) Pubkey-Channel-Relationships (see other post on ML)
>> > Very static, relayed every 10 days // 264 Bytes
>> > (2) Node addresses/IP
>> > ... approx every 12h // 133 Bytes [...]
>> > (3) Channel-Status (capacity, fee, ...)
>> > ... once an hour? // 176 Bytes [...]
>> These estimates seem about the right ballpark to me. But once per hour
>> may be extremely optimistic when channels approach exhaustion.
>
>> Yeah, my design point has been 1M nodes. Ideally, on a cell phone :)
>
>> In the very short term, Bitcoin used IRC as the peer protocol. It has
>> the advantage of being really easy to debug, and trivial to implement,
>> so I'm going to aim at that while we research our more ambitious
>> proposals...
>
> I'm totally a fan of being able to log the entire network dynamics too...
>
> So doing the above over IRC means maybe doubling the byte size to encode
> keys/sigs into hex, and adding maybe 32B per message for IRC protocol
> overhead. So:
>
> 560B/channel/10 days
> 298B/node/12h
> 384B/channel/1h
>
> Assume ~10 channels per node and converting to bytes/node/day:
>
> 560B/node/day
> 564B/node/day
> 92,160B/node/day
> = 93,284B/node/day total
We'll get kicked off freenode long before that. But it allows us to
master the other parts of the protocol first, up to a few hundred nodes.
Cheers,
Rusty.
More information about the Lightning-dev
mailing list