18:12:28 <gingeropolous> there's no time, so whose to say I didn't mine them and the network just didn't hear about it
18:12:30 <sech1> you could mine on top of older sidechain blocks, as long as you mine on current mainchain tip
18:12:47 <sech1> but then all your blocks will be included as uncles and you'll get less reward for them
18:13:40 <gingeropolous> roight, so better to try to mine on the tip
18:13:52 <sech1> which incentivizes you to improve your network setup :P
18:14:27 <gingeropolous> even though its more likely that a tip block will get orphaned, but then thats no worse than mining on old sharechain blocks
18:14:51 <sech1> tip block is unlikely to get orphaned because everyone tries to extend it with a new block
18:15:18 <gingeropolous> yeah. i assume sharechain is effectively monero, so fluffyblocks are used?
18:15:23 <sech1> of course different miners can have different idea of the "tip block" depending on their latency
18:15:49 <gingeropolous> well there's no txs. nvermind. 
18:15:51 <sech1> sharechain stores only block templates + some additional data
18:16:05 <sech1> in a sense, it's fluffyblocks (only transaction hashes)
18:16:33 <sech1> plus miner tx payout doesn't have to be sent over the network at all because it's calculated from consensus
18:16:37 <gingeropolous> zmq notify will do lots here
18:16:48 <sech1> yes, it uses zmq heavily
18:17:02 <gingeropolous> nice
18:17:26 <sech1> so really each sidechain block will take at most 5-6 KB over the network
18:18:04 <sech1> I could go to extremes like sending only first 4 bytes of each tx hash first and the send the rest
18:18:18 <sech1> then each node could restore full block after receiving only first 1 KB of data
18:18:33 <sech1> which fits into network MTU which is nice
18:18:55 <gingeropolous> is there any downside to that?
18:19:02 <sech1> *could restore with like 99.9% probability
18:19:10 <sech1> and will have to wait for the full data in other 0.1%
18:19:22 <sech1> if there are some tx in mempool with identical first 4 bytes of hash
18:20:25 <sech1> but this is not for the first release
18:20:47 <Rucknium[m]> sech1: I know the game theory terms because I had to learn them. Sometimes I wish I could forget. That was partly a trolling comment on my part, but it's also a real critique of claims that some behavior is predicted by "game theory". In even the basic Nash equilibrium concept, the equilibrium is in general not guaranteed to be unique.
18:21:10 <sech1> I wrote down my reasoning
18:21:29 <sech1> It's not guaranteed and really depends on distribution of miner hashrate percentages
18:22:11 <sech1> if you take 25% from uncle block, "small" miners are everyone with less than 25%. As long as no miner is more than 25% of the pool, it's guaranteed
18:22:23 <wfaressuissia[m]> gingerpolous, this encoding will be ambiguous in case of many txs with the same hash prefix 
18:22:28 <sech1> so then it becomes similar to "51%"
18:23:24 <sech1> yes, first 4 bytes are ambiguous (in theory), I just plan to send them first and then the rest 28 bytes for each tx
18:23:42 <sech1> so as soon as you receive the first packet (less than 1 KB, fits into MTU), you can try to restore full block
18:23:49 <sech1> should be efficient
18:24:50 <sech1> your mempool might not even have some transactions from that block (latency) which is more realistic case of when you can't restore full hash from first 4 bytes
18:27:56 <jberman[m]> <sech1> "but then all your blocks will be..." <- Why aren’t “small” miners with lower hash rate than their share of the uncle reward incentivized to only try to mine orphans on an individual level? Isn’t that the individual small miner’s profit maximizing strategy?
18:30:25 <sech1> Imagine you're a miner with 0.05% of pool's hashrate, you can barely mine 1 block in the PPLNS window. If you include some other uncle block, you suddenly receive 125% of your usual reward from that block you mined
18:31:03 <sech1> so including uncles increases your reward by 25% on average. As your hashrate increases, this reward increase gets less and less
18:31:28 <sech1> and if you have more than 25% of pool's hashrate, your reward starts decreasing if you include uncles (think of the case when you have 100% hashrate)
18:32:38 <sech1> but even if you have high % of hashrate and don't include, someone else will include that uncle block and 100% of that block's reward will be in the PPLNS window
18:33:00 <sech1> but 25% of it won't go to you which will reduce your reward more compared to the case when you included it as a big miner
18:34:12 <gingeropolous> but hey, ultimately, its open source and permissionless so folks could create an uncle-free separate p2pool, and the market will decide
18:34:34 <gingeropolous> so, potato potato
18:34:35 <sech1> I might even make it a knob in pool's config, right?
18:34:49 <gingeropolous> ooooh knobs. 
18:34:58 <sech1> this will change consensus and create a separate p2pool chain
18:35:03 <sech1> there will definitely be more than 1
18:35:04 <moneromooo> A knob to turn the potato into a banana for gingeropolous.
18:35:06 <gingeropolous> flags. all the flags
18:35:23 <gingeropolous> no one mispells bananannaa
18:35:26 <sech1> because if everyone's on p2pool, it's not fun even with 10 second blocks
18:36:01 <sech1> I want to leave an option to adjust consensus (like genesis block hash and some other params) so everyone can just mine their own separate chain
18:36:56 <gingeropolous> yeah, and even just an ID
18:37:30 <sech1> yes, an ID in each block that must be set to predefined value
18:37:34 <sech1> taken from config
18:37:47 <sech1> it might be even just a string, essentially a pool name
18:38:05 <moneromooo> "anonpuddle24"
18:38:20 <sech1> I'm thinking of more like local p2pools
18:38:30 <sech1> "WestcoastPool420"
18:38:44 <sech1> because network latency
18:56:20 <gingeropolous> yep. awesome.
18:56:29 <mj-xmr[m]> .merges
18:56:29 -xmr-pr- 7786 7792 7795 7800 7801 7802 7805 7809 7810 7811 7812 7816 7817 7818 7839
21:22:51 <wfaressuissia[m]> "https://github.com/monero-project/monero/blob/master/CMakeLists.txt#L500", hyc, that zeromq was always linked with shared libs
21:23:26 <wfaressuissia[m]> so `make release-static` doesn't make any sense
21:38:21 <wfaressuissia[m]> "https://github.com/monero-project/monero/pull/6824" at least after this commit, since krb5 package doesn't even have static libs in debian/ubuntu
23:24:59 <Rucknium[m]> Does Monero have more than one full node implementation? I am aware that BCH has 6 full node implementations and I'm wondering about Monero.
23:25:23 <UkoeHB> Not that I’m aware of.
23:30:24 <Rucknium[m]> Ok. I'm thinking down the road it may make sense for me to write an R package for RPCing monerod. I wanted to see if I would have to take into account another implementation.
23:59:29 <hyc> wfaressuissia[m]: yeah the gssapi/krb5 deps are all dynamic https://paste.debian.net/1207114/