09:45:01 moneromooo: I don't have a PoC, but 100 post v4 blocks are a problem 14:33:14 * moneromooo going to restrict some requests some more soon ^_^ 15:44:41 vtnerd_: do you think utf8canonical should be changed for the boost code you pasted (in another patch) ? 15:46:35 Also, the "only works if log_filter returns codepoint equal or 15:46:46 " comment is just about buffer overflow, right ? No other reason ? 15:47:33 (ie, a copy on first longer would work) 16:05:45 What do people think of the "peer claims higher version, we might be forked" message ? Looks there's a neverending supply of cunts making this message useless now. Remove ? 16:06:36 Or move to info/debug. 16:08:26 I’d move it to info instead completely removing it 16:11:49 Can it realistically be used for any meaningful action by the user? 16:12:17 Yes: go to getmonero.org to see if they forgot to update for a fork. 16:12:57 But in the face of so much spam? 16:13:01 There might be a way to test for plausibility by asking for some PoW hashes and checking for diff... 16:13:10 Oh no. Now it's mostly pointless. 16:13:18 Yeah that's what I mean 16:13:24 * moneromooo takes it to debug 16:21:20 If you're taking requests :) , the "Last scheduled hardfork time suggests..." message could be made less frequent. Perhaps every 6, 8, or 12 hours, rather than every 2? 16:23:28 I removed this one. Though I kept the other one, not sure why. I'll remove it too. 16:29:36 I thought you removed it already 16:30:18 ah wait there are two 16:30:29 that’s what you meant 16:30:43 Yes, I did not remember/notice there was another. 16:38:07 should we remove unknown seed nodes from code? 16:38:42 (those that have been down for a while) 16:39:14 I have no objections since we have a few new ones now. 16:39:25 Might want to ping pony about the IPs. 16:39:31 we have 8 online 6 offline 16:39:38 those are apparently not fluffys 16:39:45 or he forgot about them :) 16:50:02 moneromooo: for some reason a bunch of your recent PRs have been doubled up (e.g. 6568/6569) 16:50:49 release-v0.16 and master branch 16:50:49 Looks fine to me. One is for master, the other for release-v0.16. 17:40:06 Is the current version of the 'utf8canonical' method already the "release candidate"? Can I test that again now? 17:43:57 Or you do wait for some more feedback from vtnerd in this, moneromooo? For my own stuff I would propose to make optimizations together with vtnerd only in the master PR, so the branch PR gets ready early 17:44:10 +1 17:50:35 I've made the changes I thought were worth it, I don't intend to change it again unless bug. All the other stuff can be done in another PR. 17:51:36 Alright, thanks. Will play with the method interactively a little more with the help of the MMS then. Alice in Chinese Hanzi and all :) 17:52:27 The only difference is tolower -> towlower IIRC. 18:26:06 Alright, I am through with my release PR. 18:26:24 The master PR will have to wait for the weekend, but I guess that does not matter :) 19:28:53 Any windows coder here ? There's a (presumably) easy patch that could be made, to detect FAT where the blockchain is and complain, since it will break for files > 4 GB. 19:29:24 moneromooo: wll have a look 19:29:30 Thanks. 19:37:37 FAT16 as opposed to FAT32? who still uses FAT16? 19:39:31 No idea about the details of which variant is fine or not. I guess a Windows coder will know where to find that info :P 19:39:51 But there's been at least two reports of this on github. One just a few days ago. 19:40:54 OK, a month and a half. And it was FAT32. Maybe there are variants of FAT32 ? https://github.com/monero-project/monero/issues/6429, 6th April. 19:41:39 hmmmm 19:42:54 lol FAT-16? It's really old ~Windows 2000 19:43:41 ah you're right, filesize limit on fat32 is 4GB 20:10:55 luigi1111w: can you merge 6551 tonight? 20:20:10 6532, 6540, 6541, 6543, 6545, 6554, 6560, 6562, 6567, 6569 20:20:21 ^ these would also be nice to merge 20:20:38 then we need 1 more merge list tomorrow and then we can tag 20:49:12 moneromooo : just noticed that easylogging doesn't include any boost headers, so dunno. I liked the separate encode/decode functions (more flexible/reusable) and the code could be copied 20:50:01 selsta yes 20:59:24 theres a few more checks for invalid utf8 encodings: (1) top two bits of every trailer byte is checked, (2) "overlong" encodings, (3) invalid "surrogate" values, and (4) invalid values in the first byte 21:48:46 fwiw, we've got comprehensive UTF8 validators/normalizers in the OpenLDAP source tree, if you want them 21:49:25 we found it was as much time to scan first for bad sequences, and copy, as it was to simply copy unconditionally (without scanning first) 22:18:17 Hrm. I'll leave it for now then. 22:33:26 xiphon would you mind approving 6554 if it's how you want now? 22:33:47 luigi1111w: on it 22:49:41 luigi1111w: it’s approved now 22:50:01 so I checked some of the down seed nodes, looks like fluffy added them 3 years ago 22:51:12 maybe he did forget about them 22:51:50 thanks 23:40:55 vtnerd_: what is left so that the supercop PR can get merged? 23:41:08 (the one in the supercop repo) 23:41:11 only an approval? 23:41:40 IIRC I checked the asm but wanted luigi to check the crypto semantics. 23:41:50 (the C parts) 23:42:00 Other than that it was good to go. 23:42:07 I asked luigi to look at it 23:42:12 he did I think 23:42:15 (or someone else with crypto knowledge) 23:42:23 Oh good, then it can go in. 23:43:05 I tested it on my laptop and it works quite well so would be cool to get into the next major release :D 23:44:08 Except the assert might splatter key material onto the disk. Would be nice to remove it. 23:44:27 Can be done later I guess. 23:44:57 Approved.