Thanks, though note this:
Exolix: "Users must undergo AML/KYC procedures" source: https://kycnot.me/service/exolix
Trocador: "Trocador's partners may require KYC checks and monitor transactions" source: https://kycnot.me/service/trocador
Haveno itself is a testing version which does not allow real trading.
You need to find other software based on Haveno, which allows real trading (uses Monero mainnet servers while Haveno itself a testnet?).
Possibly most popular is Reto (RetoSwap). Its official Github repository is https://github.com/retoaccess1/haveno-reto
I am yet to find any list of Haveno mainnet software. Btw. here is some guide which explains steps for trading inside Haveno based trading software: https://internetlifeforum.com/showthread.php?28833-Exchanging-Monero-and-fiat-privately-without-KYC-using-open-source-software-Haveno
Haveno Reto mainnet official repository https://github.com/retoaccess1/haveno-reto
Haveno Pay by mail docs: https://docs.haveno.exchange/the-project/payment_methods/Pay_By_Mail/
Ok, so spending received XMR within 15 blocks (block time seems to be 2 minutes, so half a hour) is too early and spending every 6 months incoming payments in one single tx to my secondary wallet i suppose is too long time.. hmm, that is all quite complicated, I can't asses/compare these times (30 minutes vs 1 month vs 6 months) significance of the impact on anonymity. But thank you.
I think that when I am having link like https://lemmings.world/post/10530999 or knowing a title of the post, i can not discover in which community it has been posted... When I check same number of post on different instance: https://lemmy.ml/post/10530999 it does NOT work. Yet the search works: https://lemmy.ml/search?q=10530999 is there no other/easier way than opening one big instance after another (for example from the list https://lemmyverse.net/?order=posts&open=true ) and use search like that?
The more outputs you have/use, to more traceable you get
Thanks for your input. ChatGPT says "using more outputs in your transactions can potentially lead to unintentional traceability if those outputs are later used in a larger transaction. This is why it is important to carefully plan and manage how you use outputs in your transactions to maximize privacy." So it confirms what you have said.
So I guess that I should avoid manually adding multiple outputs in aim to decrease chance of a tracking, I am saying that since i am usually getting small transactions and spending in big ones (which would "consolidate" small outputs and more less invalidate my anonymization effort). So I guess i will do just churning with single output to my secondary wallet and in case i want to "join" funds from "home" and "work" accounts, I can do:
C)
3rd party -> work -> work2nd
KYC'ed 3rd party -> home -> home2nd -> home3rd -> work2nd
and then spend big transaction from work2nd (or maybe i can skip the step "home3rd -> work2nd" and source the big transaction from various accounts, yet someone claimed last year "It seems that at the present moment, neither the Monero GUI/RPC/CLI wallets implement the ability to transfer from multiple addresses." and I can confirm I am unable to find it in Monero GUI [btw. it is very slow to sync (even tens of minutes if not ran for 2 weeks+), i am NOT running node and i am using Tor proxy inside it]. Feedback to what I have written is much appreciated.
don’t use a churn output with an unchurned output
You mean that the churning by sending from my wallet to this same wallet(i can also say account or sub account of the wallet) (sending to self) just part of its ballance, will result in churned and non churned outputs in that wallet and these will be joined together if i later (after a week) send a big transaction (or wallet sweep) causing my previous churning be pointless? Maybe in this case is better for simplicity to always churn (part or full balance - i do not know if there is any benefit in sending in parts or in full) to second account within my wallet (instead of sending to self/same address) to prevent this. And i will be sending XMR to a third parties only from that secondary account?
Thanks, I see that the cross-posting works like this: "In order to cross post, I need to first create the post in one community, then after I create the post, I can click the two nested squares icon under the title of the post (with the pop-up text “cross post”) that shows up on mouse-over." https://lemmy.world/post/354611
I assume that you mean to receive XMR on own wallet 1, wait for example one week, send to own wallet 2, wait a few days and then spend it (for example in an e-shop)?
According to @[email protected] [email protected] suggestions, i assume that to improve this, i can split the first transaction between my wallets into two payments (hours or a day delay between each) and each sent to different wallet of mine, then making sure i do not send these two outputs later into same wallet of mine, which would compromise my anonymization attempt? Is this split into 2 payments doubling the difficulty to trace the payment?
The method described in this whole post of mine can be considered very unlikely to be traced by any government in the next decade? Thank you
Thanks, I would like to be able to understand how big improvement would be to send the same or similar amount to secondary wallet of mine when comparing to direct sending mentioned by you. I think that i want above average protection, but i am unable to estimate impact (on TX traceability) of 1,2 more transactions of similar amount between my wallets and i am not enough technical to read and understand tens of technical pages of the Monero whitepaper.
no, when i use ! like this: https://lemmings.world/c/[[email protected]](/c/[email protected]) then it returns error "couldnt_find_community"
There is several feature requests for this already, you may upvote: https://github.com/qbittorrent/qBittorrent/issues/9063
Here is an idea what one can do to reduce seeding of a high peer count torrents:
-> You end up seeding only low seeded torrents. After several months or a year, you can repeat the process.