From rusty at rustcorp.com.au  Tue Oct 20 06:31:16 2015
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 20 Oct 2015 17:01:16 +1030
Subject: [Lightning-dev] Specifications of Broadcasting Layers
In-Reply-To: <20151019235501.GC18268@navy>
References: <CAE8CtVkRWnc1fiaPrMk=2mMP9jMvFAi5UNcSg4_iVx=GGTR6BQ@mail.gmail.com>
	<87mvvfy97l.fsf@rustcorp.com.au> <20151019235501.GC18268@navy>
Message-ID: <87y4eyf3uz.fsf@rustcorp.com.au>

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.