02:02:36 <monerobull[m]> epic
06:09:14 <ErCiccione> > <@escapethe3ra[m]:libera.chat> > <@erciccione[m]:libera.chat> Network upgrade (hard fork on mainnet): 16th July, Block 2668888
06:09:14 <ErCiccione> > 
06:09:14 <ErCiccione> > is this final? want to post a short report
06:09:14 <ErCiccione> I'd say so, yes
06:59:17 <merope> Is the hardfork going to be a "single" fork or "double" fork with a 720-block transition?
07:01:29 <moneromooo> Double.
07:29:09 <merope> I assume the second fork height will be 2668888 + 720, right?
07:35:43 <moneromooo> Not set yet.
07:40:09 <merope> Alright 
13:27:35 <lousiF> https://decrypt.co/98023/monero-faithful-threaten-bank-run-on-centralized-exchanges
16:58:17 <rbrunner> Say again, how much will fees typically rise after the hardfork? In what ballpark is the factor of the rise?
16:58:19 <rbrunner> I know I read the answer at least once somewhere, but could not find it again even with quite some effort
17:00:23 <moneromooo> Restart with --offline --fixed-difficulty 1 after changing the HF table to switch to the next version on the next block. Mine a few blocks, then bc_dyn_stats 1.
17:06:52 <rbrunner> Oh, that's so much work, and I am so lazy :)
17:07:20 <rbrunner> Maybe it's really time to do this, also the question of transaction size is interesting and could be checked first-hand with this
17:08:21 <moneromooo> I think it's at least 5x. Might be a fair but more though.
17:12:11 <sech1> It is 5x
17:13:22 <moneromooo> ty
17:14:24 <rbrunner> Ok, thanks to both. That will need some gentle introduction to not put people into shock. E.g. by showing how low they will *still* be, even if 5 times higher
17:14:30 <rbrunner> But not a dev problem :)
17:16:11 <moneromooo> Those people are the reason I'd bump by another x2...
17:18:14 <w[m]> 30x, am I wrong?
17:18:56 <w[m]> * I thought it was 30x. Am I wrong?
17:22:09 <UkoeHB> no 5x sounds right
17:36:17 <sech1> new code just removes "fee /= 5" from the code
17:36:29 <sech1> so it's 5x more, not accounting for fee algorithm changes
17:37:47 <moneromooo> That sounds... odd :D
17:48:42 <jkirsch> Hey all. Can anyone help me with this information: When a node requests a seed peer list from a seed node, what is the criteria the seed node uses for choosing which nodes to include in its response? ie, Which nodes are sent back by IP address x if I launch the daemon with --seed-node x ? It doesn't seem to be either node x's white list top 250 or
17:48:43 <jkirsch> the entire white list.
17:52:41 <moneromooo> You can't request a seed peer list. I assume you mean a peer list ?
17:52:51 <moneromooo> If so, then there are a few steps IIRC:
17:52:58 <moneromooo> - take the white peers
17:53:10 <moneromooo> - remove the ones that were already sent to that peer
17:53:18 <moneromooo> - shuffle the remaining list
17:53:25 <moneromooo> - send the first N in the list
17:54:00 <moneromooo> This is from memory, it might be wrong, but it's the gist of it. See p2p_node.inl I think.
17:54:15 <moneromooo> I think you can grep Yao to get to the code that does it.
17:56:18 <jkirsch> Great that's very helpful thanks, I'm trying to figure out why the peer list the seed sends back may contain over 1,000 entries (sometimes over 2,000 :O )
17:56:44 <rbrunner> Hmmm, my testnet daemon does not want to hardfork after I added two more entries in the "hardforks.cpp" 'testnet_hard_forks' array for 15 and 16 and mined the necessary blocks.
17:56:51 <moneromooo> You might have found an asshole node, which tries to stuff your peer list with malicious nodes.
17:57:00 <moneromooo> Or a bug.
17:57:03 <rbrunner> What is the most probable stupid mistake I make?
17:57:29 <moneromooo> The heights are wrong.
17:57:35 <moneromooo> You're running the old binary.
17:57:46 <rbrunner> I did not compile :)
17:58:05 <rbrunner> No, I believe to have checked that all already. Hmmm.
18:01:12 <rbrunner> Does it tell me something useful if the command "hard_fork_info 15" outputs: version 15 not enabled, 0/10080 votes, threshold 0
18:01:30 <moneromooo> Try hard_fork_info 115
18:01:48 <jkirsch> Very interesting. Across the ~4,200 unique IPs on my 11 nodes' white lists, ~2,200 responded with >1,000 nodes when I used them to seed. Gonna investigate.
18:01:48 <rbrunner> Same result
18:01:54 <moneromooo> Then it's not useful :)
18:01:58 <moneromooo> Try hard_fork_info
18:02:01 <rbrunner> Yup.
18:02:29 <rbrunner> In any case, I don't have to "enable" hardforks myself, do I? The array entry should be enough, if done properly.
18:02:58 <moneromooo> There's a number of asshole nodes. They're basically either some known jerk with a massive chip on the shoulder, or one of probably many spy companies.
18:03:33 <rbrunner> Simply "hard_fork_info" gives me the expected 14: version 14 enabled, 10080/10080 votes, threshold 0
18:03:55 <moneromooo> Does "status" tell you, forking in xx ?
18:05:07 <rbrunner> I didn't do a "status" before I started to mine. Maybe I drop blocks and try again.
18:09:16 <rbrunner> No, with 48 blocks below the supposed forkheight "status" does not tell me something. I think I recompile that bloody thing from scratch.
18:16:43 <rbrunner> I think I found it: If you don't adjust the timestamps as well in that array so that they are in the future, it somehow might not work. Anyway, on v16 now.
18:17:43 <moneromooo> Odd. It should insult you about it if you don't.
18:17:56 <moneromooo> Check log again ?
18:20:33 <sethforprivacy> Created a check-list for the v15 fork now that the height has been set:
18:20:33 <sethforprivacy> https://github.com/monero-project/meta/issues/690
18:21:13 <sethforprivacy> Please watch that for updates and keep the items on it in mind as we get closer to tagging/testnet fork date.
19:33:59 <rbrunner> I have now master plus BP+ plus higher fees plus ringsize 16 running; only view tags are missing, but their influence should be minuscule
19:34:35 <rbrunner> I did a 1 in / 2 out tx and compared it with other such txs on the testnet blockchain
19:34:56 <rbrunner> Result: Sizes 1526 versus 1417 bytes = 7.7% larger
19:35:29 <rbrunner> Fee: 0.000077830000 versus 0.000014620000, about a factor of 5.3 higher.
19:35:56 <moneromooo> Why is is larger ?
19:36:05 <rbrunner> Higher ringsize?
19:36:11 <rbrunner> 16 instead of 11
19:36:12 <moneromooo> Oh.
19:36:16 <moneromooo> Thanks :)
19:36:35 <rbrunner> I think BP+ mitigates quite a bit, but not completely.
19:36:44 <moneromooo> Yes, you had said it. I read too fast -_-
19:37:05 <rbrunner> Maybe I was the first one to make such a transaction? I am so proud :)
19:38:26 <UkoeHB> lol congrants rbrunner 
19:38:36 <rbrunner> Gee, thanks.
19:38:54 <UkoeHB> was the fee pr merged already? I can't keep track
19:39:20 <rbrunner> No, I had to cherry-pick. The ringsize PR as well. Fortunately everything rebased already.
19:39:49 <rbrunner> A true frankenstein release.