[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