01:31:18 I can tell you why you can't stop the 'spam'. You are thinking in cult doctrine. If it was real spam, and I was selling Viagra for example - you could easily ban keywords and urls. Instead, stop being a sheep, think like a cult leader. Recoginse that this 'spam' is just some bullshit that you tell to the sheep. 01:31:18 When you do that, solution will present itself. Observe. 'spam' -> 'FUK talks bad things about Monero on our IRC' (Don't say that out loud obviously, that will get you excommunicated) Solution? Get off-the-shelf sentiment analyser, detect anyone who 'talks bad things about Monero' and ban them. 08:19:41 Word of guys running Monero community should be BELIEVED. Why would anyone that stole money and laughed at the losers that took the bait ever have a reason to lie to you? www.reddit.com/r/Monero/comments/6d5yt5/what_fluffypony_just_did_is_not_ok/ 08:45:52 i have a case where a transaction doesn't add, i use describe_transfer to get a json representation and then i subtract change_amount+fee from amount_in i end up with less then recipients.amount 08:45:57 M1312test1312[m]: it's just a spammer, best to ignore 08:46:10 -xmr-pr- perfect-daemon opened pull request #7460: async_protocol_handler_config: fix deadlock 08:46:10 -xmr-pr- > https://github.com/monero-project/monero/pull/7460 08:46:10 -xmr-pr- perfect-daemon opened pull request #7459: async_protocol_handler_config: fix deadlock 08:46:10 -xmr-pr- > https://github.com/monero-project/monero/pull/7459 08:46:11 -xmr-pr- xmrdog opened issue #7458: monero_blockchain_import: "Block verification failed" 08:46:11 -xmr-pr- > https://github.com/monero-project/monero/issues/7458 08:47:28 here is one example of it: 08:47:35 https://pastebin.com/sWCSkDVj 08:50:30 if i would believe the json representation of the txhex i send out 10 piconero less then i intended 09:01:52 forget the pastebin above it is a working example, one that fails to add up is: https://pastebin.com/MgpvkLpS 09:03:05 but as you can see from the first and second the one that fails (second one) has larger amount_in size so it looks like a overflow bug 09:59:28 I have just realized, that my workflows failed to link, because I have used up all my diskspace. In case somebody wants to clean his/her project, here's info: 09:59:29 https://github.community/t/delete-old-workflow-results/16152/36 09:59:40 Search for #36 10:08:54 spoke0_: I don't suppose you have a level 2 log of this being created ? 10:09:13 no but i can get it 10:10:55 What does output this ? 10:31:10 -xmr-pr- Singularcrowd opened issue #7468: Did Riccardo Spagni change his mind after saying he wants to pump and ... 10:31:10 -xmr-pr- > https://github.com/monero-project/monero/issues/7468 10:31:11 -xmr-pr- Singularcrowd opened pull request #7467: Did Riccardo Spagni change his mind after saying he wants to pump and ... 10:31:11 -xmr-pr- > https://github.com/monero-project/monero/pull/7467 11:56:20 regarding my issue with the result from describe_transfer, it was caused by me using the javascript function JSON.parse that has issues with parsing large number types. So it is not an issue with the wallet. Sorry for posting without investigating this issue in depth. As a note I fixed it by switching to json-bigint npm package. 11:56:51 Thanks for the note. 13:18:36 selsta, is the reason for not having ccache enabled for the "Test" step, that we want to rule out ccache manipulating the binaries? 13:19:27 yes there is a reason, it resulted in illegal instruction issue IIRC 13:20:09 the resulting binary did not run 13:20:32 OK. It runs perfectly on my branch now. 13:21:11 I will PR this separately. 13:21:35 try running multiple times 13:21:43 ok 13:55:06 mj-xmr: IIRC the problem was that on a different run a different hardware host was used so the previous cache resulting in illegal instruction error message 13:56:25 resulted 13:56:35 OK. makes sense. 13:56:54 A generic build would help with this. 13:57:24 But it's better to have one exception to the rule and not mix too many inputs. 15:29:17 Did you know that all witdraw-buyer-seller-depoist chains are trackable in Monero? No? You should have read Breaking Monero. How many people are you endangering with your 'privacy' coin? 15:31:10 -xmr-pr- mj-xmr opened pull request #7469: [DON'T MERGE yet] core_tests: cache data for each test separately, the... 15:31:10 -xmr-pr- > https://github.com/monero-project/monero/pull/7469 15:34:06 Short comment to the above - it saves 52 minutes on each subsequent run. 15:34:17 of testing time. 15:53:18 mj-xmr: how large is the cached data? 15:53:31 github actions allows 2GB per repo 15:58:51 selsta: Compressed with tar gz, less than 7 MB 15:59:11 that's good 15:59:12 github uses zstd 15:59:27 as long is it isn't 1 GB or so 15:59:30 it's fine 16:00:09 "Cache Size: ~6 MB (6165322 B)" 16:00:15 From guthub logs. 16:10:15 export_outputs(all) where all=false appears to skip outputs with m_key_image_known && !m_key_image_request. what does that mean in more laymen terms? 16:14:18 i.e. what does export_outputs(all) export when all=false? 16:14:45 only the new ones from the last export 16:14:49 IIRC 16:15:28 k, thanks 18:34:02 OK. 7469 is ready for a review. I'm relatively happy with the changes and it is shown in the "Checks" that the core_tests took 7 minutes. 20:54:48 .merge+ 6810 7005 7332 7366 7368 7394 7373 7398 7400 7401 7402 20:57:20 .merge+ 7274 20:57:20 Added 20:57:24 .merges 20:57:24 -xmr-pr- 6810 7005 7274 7332 7349 7366 7368 7373 7394 7398 7400 7401 7402 23:16:10 -xmr-pr- cabelo opened pull request #7476: dependencies in openSUSE 23:16:10 -xmr-pr- > https://github.com/monero-project/monero/pull/7476