00:27:25 Nova comunidade Monero Brasil, no Clouthub. 00:27:25 https://clouthub.com/g/Monerobrasil 01:05:49 https://www.youtube.com/live/1kEKhxUCyn4?feature=share&t=4049 01:05:49 Doomberg asking Saylor if he would be able to reveal Microstrategy's bitcoin public wallet addresses 😅 01:05:49 I understand his reasoning as a business and not saying he should have to reveal the details. Pretty funny though to hear him say how he wants to keep that private.. well no shit 01:07:41 "we wouldn't want people looking at our transactions" 01:34:13 Classic moment 01:35:16 well of course.. 01:40:22 It triggers me that George doesn't have a real Austrian on his channel to debunk his Monetarist/Friendmanite views 01:40:36 George is fractional reserve believer 07:40:43 https://www.themoneromoon.com/p/the-monero-moon-issue-58 09:34:46 my node is saying 2781242 (2 minutes behind) but the blockheight at xmrchain is at 2781307 which is like 60 blocks ahead what gives? 09:35:09 * at xmrchain.net is 09:35:31 your node is behind 09:37:23 actually nevermind I'm looking at the tail of monerod.logm, monerod status is showing the right numbers relative to web explorers 09:37:32 s/logm/log/, s//`/, s//`/ 10:57:45 hey 13:13:48 who[xmpp]: hi, i'm not too familiar with xmr (only used it for like a year or so). wanted to ask, based on my understanding of ring signature cryptography used, I need to send my funds across multiple wallets to increase my anonymity set? 13:14:33 who[xmpp]: so i'd be making new wallets and passing the funds around to them? 13:15:10 who[xmpp]: and if yes, would it work the same if i just used a subaddress rather than generating a whole new wallet? 13:15:38 who[xmpp]: apologies in advance if i have any misconeptions or anything, would be happy if someone could correct me :) 13:19:26 you don't even have to use different subaddresses, just send from whatever address/subaddress you have back to itself 13:19:40 this is called "churning" 13:21:10 its effectiveness is still debated, and there are some pitfalls/caveats to watch out for - doing it badly can actually make it easier to associate outputs together 13:21:41 but the general idea is that (if done properly) it can indeed increase the set of possible paths that your funds have taken 13:27:34 who[xmpp]: > its effectiveness is still debated, and there are some pitfalls/caveats to watch out for - doing it badly can actually make it easier to associate outputs together 13:27:34 ah okay, do you know what those pitfalls/caveats you mentioned are? 13:28:39 who[xmpp]: with my caveman understanding of things i just figured i'd just be sending it to the same address like 7-8 times 13:43:10 That's kind of excessive, even in the most extreme threat/paranoid scenarios 13:43:16 2-3 times is plenty 13:43:54 But you have to be careful about associating outputs together, as well as the timing of each churning operation 14:01:27 churning 7-8 times in quick succession is a sure way to be visible 14:01:42 churn 2-3 times with random intervals, ranging from several hours to several days 14:11:40 who[xmpp]: > But you have to be careful about associating outputs together, as well as the timing of each churning operation 14:11:40 hmm, so if i receive xmr from various different wallets i shouldn't just combine them all when churning (assuming thats what you mean by associating them with each other)? 14:19:28 depends on your threat scenario, for a caveman it would seem that churning is not necessary :) 14:19:46 probably the same for most people 14:29:33 Question. When trying to mine p2pool using Monero GUI, is it normal that it downloads block again, and again, and it finishes and then its back to download blocks again and never do anything else but download blocks after just finishing downloading blocks? 15:09:13 @who[xmpp] correct. Ideally, you would churn each output individually at first, and only combine them at the end (if necessary) 15:30:53 Anyone has used uquid.com? Is it trustworthy? 16:27:17 uquid.com/monero-debit-card 16:32:10 seems like a scam to me and i wouldn't trust some random service on the internet to hold my money on it. There is also no way to get your money back in any case where you aren't satisfied with your payments as this is crypto. 16:34:23 You can check the sites with some other crypto currencies such as uquid.com/bitcoin-debit-card or uquid.com/ethereum-debit-card -- quite unserious how they also pasted the same text everywhere. 16:39:36 All Countries approver? srsly? Smell scammy considering most crypto card issuers pulled in 2017-2018 then put them back but with big limitation (like EU only, Russia than USA). Most/all majority world countries excluded. 16:39:41 s/approver/approved/ 19:00:37 Seed nodes for clearnet are hardcoded into the monerod source, does that mean that old versions may not work without an existing p2pstate.bin, because the hardcoded seed nodes might no longer exist? 19:23:55 dANBs[m]: When churning, don't do it immediately (maybe wait a few days between transactions, at least; longer could be better), and try to avoid doing so with the same amount each time, to reduce similarity between transactions or close correlations in time with the same address showing up. Doing it between different addresses should in theory be slightly better, I think. This is based on my 19:24:01 understanding, and I'm not exactly an expert. 19:26:00 dANBs[m]: The sooner you have to move money, the more important it probably is to make it a substantially different quantity, I'd think. It's also probably a good idea to move things after a significant protocol change (again, according to my understanding). 19:31:35 "Seed nodes for clearnet are..." <- If you're talking about older versions as in previous hardforks, they're not gonna be compatible with the current network anyway. They'll just get rejected (and they'll reject the hardcoded seed nodes themselves) 20:27:05 is it safe to share transaction id with the receiving party? 20:27:31 yes (they will know the transaction id when the funds arrive) 20:54:13 wait holy shit scan_block is in? 22:31:55 amoe: you can always specify for own seed node with `--seed-node` 22:32:11 *your own 23:45:45 oh its still scan_tx , not scan_block 23:48:35 i was wondering if scan_block was undocumented 23:49:14 yeah scan_tx has been improved/fixed by jberman - my testing the past month (including background scanning with view-key only has found no issues)