<spirobel:kernal.eu> @kayabanerve:matrix.org: the indirection is to talk about this constant. We would not talk about it now if it hadnt been randomly picked for bitcoin.

<spirobel:kernal.eu> It is just not good practice to randomly pick specific amounts for a constant that depends on other constants.

<spirobel:kernal.eu> ( and then have a debate about it, instead of the constants it depends on. especially with the sultans of blockchain scaling that show up when this word is mentioned )

<jeffro256> > That constant seems to be the limiting factor for levin throughput.

<jeffro256> The 100MB limit isn't the limiting factor for levin nor for throughput. It's a limit on the size of one packet, which limits the current block sync protocol, regardless of levin, because a node can try to download a whole block and its full transaction blobs on one packet, and doesn't currently have a way around it. We can kee [... too long, see mrelay.p2pool.observer/e/5p2W9tIKTjZwUkpw ]

<jeffro256> > It is just not good practice to randomly pick specific amounts for a constant that depends on other constants.[... more lines follow, see mrelay.p2pool.observer/e/5p2W9tIKTjZwUkpw ]

<spirobel:kernal.eu> @jeffro256: this is a change i would 100% support. (and probably everyone else) Changing the block sync protocol is something that takes time and needs further discussion though. I also agree with the assertion that not having a max block size constant carries the risk of not keeping the network in tact. It should be fixed [... too long, see mrelay.p2pool.observer/e/387jgdMKN1p1UEVG ]