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.

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.

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/

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

M1312test1312[m]: it's just a spammer, best to ignore

here is one example of it:

if i would believe the json representation of the txhex i send out 10 piconero less then i intended

forget the pastebin above it is a working example, one that fails to add up is: pastebin.com/MgpvkLpS

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

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:

Search for #36

spoke0_: I don't suppose you have a level 2 log of this being created ?

no but i can get it

What does output this ?

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.

Thanks for the note.

selsta, is the reason for not having ccache enabled for the "Test" step, that we want to rule out ccache manipulating the binaries?

yes there is a reason, it resulted in illegal instruction issue IIRC

the resulting binary did not run

OK. It runs perfectly on my branch now.

I will PR this separately.

try running multiple times

ok

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

resulted

OK. makes sense.

A generic build would help with this.

But it's better to have one exception to the rule and not mix too many inputs.

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?

Short comment to the above - it saves 52 minutes on each subsequent run.

of testing time.

mj-xmr: how large is the cached data?

github actions allows 2GB per repo

selsta: Compressed with tar gz, less than 7 MB

that's good

github uses zstd

as long is it isn't 1 GB or so

it's fine

"Cache Size: ~6 MB (6165322 B)"

From guthub logs.

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?

i.e. what does export_outputs(all) export when all=false?

only the new ones from the last export

IIRC

k, thanks

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.

.merge+ 6810 7005 7332 7366 7368 7394 7373 7398 7400 7401 7402

.merge+ 7274

Added

.merges