03:29:28 @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. 03:30:02 It is just not good practice to randomly pick specific amounts for a constant that depends on other constants. 03:31:06 ( 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 ) 03:48:39 > That constant seems to be the limiting factor for levin throughput. 03:48:39 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 https://mrelay.p2pool.observer/e/5p2W9tIKTjZwUkpw ] 03:48:39 > It is just not good practice to randomly pick specific amounts for a constant that depends on other constants.[... more lines follow, see https://mrelay.p2pool.observer/e/5p2W9tIKTjZwUkpw ] 10:34:16 @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 https://mrelay.p2pool.observer/e/387jgdMKN1p1UEVG ] 11:52:30 There's other constants within the protocol which also cause this limit. It isn't solely derivative of the packet size. 11:52:58 So no, this isn't the constant the block size limit is derived from. It's a constant limiting the largest safe block size. 11:53:11 (among others)