00:00:19 <ofrnxmr[m]> Example... true story.
00:00:19 <ofrnxmr[m]> Local sheriff come down driveway, people come out of the house and tell them of theybare headlight uninvited again they will be shooting 
00:00:32 <ofrnxmr[m]> They see headlight again, and start shooting 
00:00:46 <fr33_yourself[m]> ofrnxmr[m]: I agree with this, but am unsure I possess sufficient defensive force against police in the area if they were unhappy that one didn't pay property taxes
00:00:50 <ofrnxmr[m]> Dont ask me "how". Go to those dark areas of the south and ask them. .
00:02:22 <ofrnxmr[m]> Go somewhere that you CAN defend yourself. Its not about being oaranoid, its the opposite.
00:02:23 <ofrnxmr[m]> Why worry about running away with my gold? I just mind my business and keep a sign at the end if my driveway 
00:02:23 <fr33_yourself[m]> Wouldn't that just lead to the sheriff coming back with more cops though? Isn't it kind of an uphill battle?
00:03:15 <ofrnxmr[m]> That was the sheriff..
00:03:40 <ofrnxmr[m]> And that was the sheriff coming back with more coos.. mind you, this was 20+ years ago and the guy has long since died
00:06:18 <fr33_yourself[m]> Yeah it's tough honestly. I sympathize with the agorist train of thought, operating counter-economically, but so much of the economy is already state captured it's tough to operate outside of it.
00:07:31 <ofrnxmr[m]> Yep. The game is rigged in most of the world
00:13:05 <nioc> I am not 100% monero
00:13:13 <nioc> I also have wownero 
00:18:38 <RavFX[m]> 100% monero
00:18:38 <RavFX[m]> Plus some random amount of fiat for local spending
00:19:53 <fr33_yourself[m]> rav which latam country are you in again?
00:20:15 <RavFX[m]> One of them :)
00:20:44 <fr33_yourself[m]> awww
00:21:01 <fr33_yourself[m]> fair enough if you don't want to tell
00:21:14 <fr33_yourself[m]> I'll just look at the monero nodes map :) hehe
00:21:47 <RavFX[m]> I own many, but none are in my country actually :p
00:24:09 <fr33_yourself[m]> big brain
00:26:18 <RavFX[m]> need more nodes in latam
00:26:19 <RavFX[m]> but unfortunately these did not buy much IP address in the beginning of Internet.
00:26:19 <RavFX[m]> Meaning a LOT of people are behind CGNAT.
00:26:19 <RavFX[m]> Meaning you have to get a server to host it or do some VPN shenanigans if you want to host it at home.
00:29:00 <fr33_yourself[m]> > <@gfdshygti53:monero.social> need more nodes in latam... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/41ebd5ce9149cb506471d827d8e6b80bcc7db87a>)
00:29:01 <RavFX[m]> I guess I could host an ipv6 node if I really wanted to host it local
00:31:25 <RavFX[m]> fr33_yourself[m]: Did not read all the buffer yet.
00:31:25 <RavFX[m]> And yes most if my stash is in XMR. And some in cash and metal.. (but mostly XMR)
00:31:25 <RavFX[m]> As an unbanked I don't really have more than that
00:32:49 <RavFX[m]> I do have land too, currently building on it too, if that can count
00:34:44 <fr33_yourself[m]> I gotcha, that's interesting
00:36:04 <RavFX[m]> Dumping as much state reliance as I can, have to own much of what I do need to live. I do not use any debt (except the fiat papers because it's debt based).
00:36:04 <RavFX[m]> Have my own electricity, I will be able to have my own food and water too (at least partly)
00:44:44 <fr33_yourself[m]> dang that is a solid position to be in
01:51:47 <Rucknium[m]> fr33_yourself: Pure scalability of BCH is much better than Monero. Obviously, BCH txs are smaller in size and more quickly verified. The biggest advantage is that you can discard old spent BCH txs. Use "UTXO commitments". You cannot discard Monero transactions because you don't know if they have actually been spent due to its privacy features.
01:52:59 <Rucknium[m]> User experience is much smoother with BCH. Don't have to wait to sync wallets. No lock time at all. BCH also has some on-chain programmability through bitcoin scripts and CashTokens.
02:01:10 <fr33_yourself[m]> <Rucknium[m]> "fr33_yourself: Pure scalability..." <- Wow, that's pretty interesting. Does that mean the blockchain of BCH can be actively downsized or pruned of old transactions thus reducing full node requirements?
02:03:16 <Rucknium[m]> Yes. Some people may want to keep the _entire_history, but it wouldn't be necessary for a merchant or even crypto exchange to keep the old irrelevant transactions to verify all new transactions.
02:03:33 <Rucknium[m]> This is something BTC, LTC, DOGE, etc could do too
02:05:54 <fr33_yourself[m]> Rucknium[m]: So if it was determined that the burden of running full nodes on BCH chain was too high, then full nodes could just discard parts of the history?
02:07:38 <Rucknium[m]> Yes because you dont need the full history really. Just all the coins that still exist, i.e. the UTXO set.
02:07:47 <fr33_yourself[m]> So BCH has the most technical merits opposed to Monero? As BCH can remove the burden full nodes bear by storing the chain history. However, BCH lacks privacy/anonymity that Monero offers and also lacks a Tail Emission
02:08:31 <Rucknium[m]> If you discarded some "old" Monero output public keys, your node might see a tx that uses that output as a decoy (or a real spend; you never know), and could not verify that the tx was valid
02:08:47 <Rucknium[m]> Both coins have pros and cons neither is perfect
02:08:54 <fr33_yourself[m]> Rucknium[m]: Do you think BCH's approach to Layer 1 scaling superior to BTC's Lightning Network approach to scaling?
02:10:37 <fr33_yourself[m]> Rucknium[m]: So it's impossible for Monero to ever discard old tx data in a manner similar to BCH?
02:20:22 <fr33_yourself[m]> <Rucknium[m]> "Both coins have pros and cons..." <- Does the miner security budget issue apply to BCH equally as Bitcoin since they have the same emission schedule? Or is it feasible that since BCH blocks are quite large that if the demand for transactions on the network were high enough it could subsidize miners?
02:39:02 <nioc> Fr Do you think is blocks are larger 
02:41:18 <nioc> fr33_yourself[m]: how big are fees if blocks are large?
02:45:03 <nioc> Monero
02:45:43 <nioc> Sorry Dave
02:47:44 <fr33_yourself[m]> <nioc> "fr33_yourself: how big are..." <- fees are low if blocks are large right?
02:53:41 <RavFX[m]> fees are low as long as there is space left available in block
02:53:41 <RavFX[m]> as all TX can be included in even with minimal fee.
02:53:41 <RavFX[m]> The reason BTC and ETH fee go on the roof is that the constipator (the word I often use for mempool) is often full with many block in backlog.
02:56:52 <nioc> Questions 
02:58:44 <Rucknium[m]> <fr33_yourself[m]> "Do you think BCH's approach to..." <- Yes. That's why I do some work in the BCH ecosystem and none in BTC.
03:00:47 <ofrnxmr[m]> Lightning isnt a btc scaling solution 
03:00:56 <ofrnxmr[m]> Its like a plugin 
03:01:39 <Rucknium[m]> <fr33_yourself[m]> "So it's impossible for Monero to..." <- We don't know. I've listed it as an open research question: https://github.com/monero-project/research-lab/issues/94  . Monero's current pruning setting removes some signatures and cryptographic proofs but not the output public keys.
03:01:39 <ofrnxmr[m]> It interacts with the main chain, it isnt bitcoin though 
03:01:40 <fr33_yourself[m]> So Monero and BCH are the best projects with technical merit
03:01:47 <ofrnxmr[m]> Bch scaling solution is a solution, not ignoring the problem and trying to out lipstick on it
03:02:29 <ofrnxmr[m]> The best? No
03:03:24 <ofrnxmr[m]> Or rather.. maybe, maybe not. What matters is that we actually do what we say
03:04:14 <ofrnxmr[m]> We dont talk about being money, while doing everything to make that an impossibility 
03:04:18 <Rucknium[m]> <fr33_yourself[m]> "Does the miner security budget..." <- Probably BCH has the same problems. Its problems are much worse than BTC's at the moment since the purchasing power of its block reward subsidy is so much lower. Right now BCH nodes do not allow a block re-org deeper than 10 blocks, but it's obviously an undesirable solution. It does not protect against a sabotaging 51% attack of mining empty blocks.
03:05:05 <ofrnxmr[m]> Rucknium[m]: Have you spoken to moo?
03:05:58 <ofrnxmr[m]> Iirc, the initial pr was by moo and said the current pruning was limited, and could go much further but this was good enough for now (not verbatim)
03:06:01 <fr33_yourself[m]> Rucknium[m]: So to some extent BCH is already in the state that BTC will be in once the fiat value of the block-reward + fees is too small to subsidize ASICs?
03:06:06 <Rucknium[m]> BCH's security solution is more txs multiplied by fewer fee per transaction. BCH transaction volume is lower than BTC now, so it's unclear if the plan will work. But that was Satoshi's original plan.
03:06:56 <ofrnxmr[m]> Bch tx volume isvt usually fake though 
03:07:50 <Rucknium[m]> https://satoshi.nakamotoinstitute.org/posts/bitcointalk/57/  "Right.  Otherwise we couldn't have a finite limit of 21 million coins, because there would always need to be some minimum reward for generating.  In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes.  I'm sure that in 20 years there will either be very large transaction volume or no volume."
03:10:16 <ofrnxmr[m]> 20 years = 5 halvings 
03:10:17 <Rucknium[m]> ofrnxmr[m]: I have not spoken to mooo about this, specifically. I think maybe he was saying that you could cut all signatures/proofs instead of 7/8. The 1/8 are kept so even if all nodes are pruned, new nodes can still verify all signatures.
03:11:13 <ofrnxmr[m]> So, 1-2 more (which aligns with my math) until its not reasonable to secure the netowkr, but it IS profitable to attack the people who store value on it
03:24:37 <fr33_yourself[m]> <Rucknium[m]> "https://satoshi.nakamotoinstitut..." <- but isn't it somewhat concerning that BCH isn't experiencing high tx volume even though we are still a good 2 more halvings away from the "20 years from now" referenced by Satoshi here?
03:26:01 <ofrnxmr[m]> Same mining algo, same miners
03:26:33 <ofrnxmr[m]> I guess the hope is that btc community will move to bch
03:27:18 <fr33_yourself[m]> ofrnxmr[m]: Do you know what the blocksize cap of BCH is?
03:29:06 <ofrnxmr[m]> Bch isnt fixed like bitcoin. While fixed, they are willing to increase it.
03:29:06 <ofrnxmr[m]> I think the cap right now is 8mb, with research into 32 and 256mb.
03:29:06 <ofrnxmr[m]> But thats a better question for ruck or google
03:29:31 <Rucknium[m]> fr33_yourself: Yes I am concerned. Frankly, I am starting to think that peer-to-peer electronic cash will remain niche for the foreseeable future. And that is fine. People who need XMR/BCH.BTC etc are using it and getting utility out of it today. If no mass adoption, then they have still be successful experiments.
03:29:43 <ofrnxmr[m]> Or is it 32mb already?
03:30:41 <ofrnxmr[m]> Rucknium:  regarding moo, iirc they said you could prune more than that, but the feature was only 7/8 for the time being 
03:30:54 <fr33_yourself[m]> Rucknium[m]: Yeah I guess the idea is to not get too committed to the idea of Monero succeeding over a long time horizon.
03:31:07 <ofrnxmr[m]> Why not? The idea is to help make it happen
03:31:31 <Rucknium[m]> ofrnxmr: That's basically correct. BCH block size is miner-configured and not a consensus rule. The BCH node implementation that most miners use, BCHN, has a default of 8MB. Miners can increase that at will. I have seen the mempool  not be cleared when it was full: BCH miners mined 8MB blocks.
03:31:38 <fr33_yourself[m]> Well yes, but the issue in my opinion has to do with sheer amount of data flowing through nodes over time.
03:32:20 <ofrnxmr[m]> What about it? At 1350tx/s that works out to... the maths has been done
03:32:31 <ofrnxmr[m]> For seraphis anyway
03:33:08 <fr33_yourself[m]> Can Monero store value over a long period of time? Basically, the informed individual wants out of fiat because banks inflate its supply punishing those who save it (Austrian school says you need saving and investment for economy to progress).
03:34:13 <ofrnxmr[m]> Yes..
03:35:03 <ofrnxmr[m]> Why would you assume it could not be? Security budget? 
03:35:35 <fr33_yourself[m]> Informed individuals don't want to feed Big Brother as we approach Sovereign Defaults and don't want to be squashed by the incoming taxation or inflation required to subsidize a system doomed from the start. Can Monero serve as a currency that will function in a counter-economy (black market) in a comparable manner to what Gold would've done after the FDR confiscation (if people had the balls to still transact with it
03:35:35 <fr33_yourself[m]> secretively inside the US)
03:36:28 <ofrnxmr[m]> Are you a bot
03:36:54 <ofrnxmr[m]> Or have you never heard of a darknet market..? Aka a black market?
03:38:19 <ofrnxmr[m]> Gold wouldnt have done anything after confiscation 
03:38:24 <ofrnxmr[m]> People lost certs
03:39:01 <ofrnxmr[m]> People have been dealing with "not your keys, not tour coins" for a very long time, long long before crypto
03:39:30 <nioc> The question bot
03:39:44 <ofrnxmr[m]> 25hrs a day
03:39:53 <ofrnxmr[m]> #monero-offtopic:monero.social 
03:39:58 <nioc> 8 days a week
03:40:17 <ofrnxmr[m]> Ofrnxmr goes to Google how many days in a year
03:41:18 <fr33_yourself[m]> <ofrnxmr[m]> "Why would you assume it could..." <- The only two unique risk factors that Monero faces that other chains do not are (1) dynamic block size expansion isn't moderated tightly enough and full nodes go offline due to lack of space on their drives. Basiscally an ironic outcome where the demand for Monero and success leads to its own node centralization and potential demise (2) higher complexity and more code churn
03:41:18 <fr33_yourself[m]> leading to a small (debatable in terms of size) increase in risk for bugs relative to other chains, combined with a higher chance that a bug has already been exploited and is undetected due to CT masking.
03:41:55 <fr33_yourself[m]> <ofrnxmr[m]> "Or have you never heard of a..." <- I know of captain desnake, aka u/desnake
03:42:36 <nioc> It isn't moderated, it is coded
03:42:38 <ofrnxmr[m]> 1. You have NO idea what youre talking about
03:42:39 <ofrnxmr[m]> 2. See 1
03:42:44 <ofrnxmr[m]> Pure speculation 
03:43:17 <ofrnxmr[m]> Its quite obvious you dont know what youre taljign about 
03:43:30 <fr33_yourself[m]> nioc: Yes, but the code can be tweaked and someday the algorithm may need to be tightened to prevent too many kb getting added to the chain per day
03:43:35 <ofrnxmr[m]> Tightening? Why? Do you think blocks just go to 900tb/block
03:43:37 <nioc> Wait, different definitions for the same word lol
03:43:40 <ofrnxmr[m]> They dont.
03:44:14 <nioc> It has been tweaked and it continues 
03:44:52 <ofrnxmr[m]> Yeah, like what are you even asking 
03:44:59 <ofrnxmr[m]> Do you run windows xp?
03:45:03 <fr33_yourself[m]> ofrnxmr[m]: I'm not informed of exactly how long it takes the algorithm to adjust to higher # of txs, but yes I understand that lt does not instantly increase the blocksize to tbs hehe
03:45:39 <ofrnxmr[m]> Well, tldr, eli5
03:45:46 <ofrnxmr[m]> You're getting colder 
03:46:01 <ofrnxmr[m]> Shoot and a wild miss
03:46:16 <fr33_yourself[m]> ofrnxmr[m]: Yeah I could be shooting in the dark regarding how the dynamic block size works. I should actually revisit Mastering Monero or ZTM 2 to check on an ELI5 of how that works again
03:46:18 <ofrnxmr[m]> Please #monero-offtopic:monero.social  if you are going to name stuff up, fud and speculate 
03:46:22 <ofrnxmr[m]> Make* stuff
03:46:37 <ofrnxmr[m]> 100% shooting in the dark and making 100% false accusations 
03:46:59 <ofrnxmr[m]> The clock size is limited to double the median of the last (I dont remember) blocks 
03:47:09 <fr33_yourself[m]> ofrnxmr[m]: no, I minimize my use of windows if at all possible
03:47:16 <ofrnxmr[m]> Right now that is 600kb
03:47:16 <ofrnxmr[m]> Or 3.2 mb / 10min 
03:47:24 <ofrnxmr[m]> Pruned = 1mb/10min 
03:47:27 <nioc> I don't prune and got tired waiting for my old 256GB drive to fill and moved to a 1TB anyway
03:48:47 <ofrnxmr[m]> This is not eli5 so I can forget and ask again tomorrow 
03:49:01 <ofrnxmr[m]> Please DYOR and ask for help with DYOR
03:49:32 <ofrnxmr[m]> You're asking real basic stuff, like youve never used monero and onlynread about it in "monero is garbage " threads written by btc maxis
03:49:50 <ofrnxmr[m]> Water is wet
03:49:54 <ofrnxmr[m]> Please dont ask me to explain
03:50:31 <ofrnxmr[m]> Just because someone convinced you that water might not be wet.. thats a query for Google, not researchers..
03:50:34 <ofrnxmr[m]> #monero-offtopic:monero.social 
03:51:32 <ofrnxmr[m]> A lot of the conversation was goodz dont get me wrong. But the repeat stuff youre asking now is #monero-offtopic:monero.social 
03:53:39 <ofrnxmr[m]> https://matrix.to/#/!WzzKmkfUkXPHFERgvm:matrix.org/$xYmFaYYq9jsj2ugu34OAZKKiHvnS-dBEUSIMtALxL8o?via=monero.social&via=matrix.org&via=libera.chat
03:54:00 <ofrnxmr[m]> Heres an ELI5 with images
03:55:09 <raas[m]> <fr33_yourself[m]> "I agree with your take. I also..." <- What is a pcn?
03:55:19 <fr33_yourself[m]> <ofrnxmr[m]> "You're asking real basic stuff..." <- Alright, I'll sign out for today. Thanks for putting up with me as long as you did. I like to be skeptically oriented, but yes the answer to my questions probably are answered in Mastering Monero and ZTM2   That being said, I think that changing the code controlling the dynamic block size algorithm should be kept in mind as a possibility that is in the community's hands, or
03:55:19 <fr33_yourself[m]> devs + researchers if hardware doesn't improve as some may hope.
03:55:51 <ofrnxmr[m]> Buddy
03:55:56 <ofrnxmr[m]> Look at the pictures 
03:55:59 <fr33_yourself[m]> raas[m]: payment channel network like lightning network
03:56:09 <ofrnxmr[m]> Before telling people to look into tightening 
03:58:13 <ofrnxmr[m]> And Fwiw I have my own thoughts on it
03:58:37 <ofrnxmr[m]> But im not in here fudding without info to back to my completely baseless claims 
03:58:46 <raas[m]> fr33_yourself[m]: Thanks
04:13:22 <fr33_yourself[m]> <ofrnxmr[m]> "Look at the pictures..." <- Thanks I checked them out. To be honest I didn't fully understand them. However I will review the pdfs. Indeed my comments may have come off as concern trollish. The info I referenced internally in my mind this morning prior to asking about Lightning and BTC were simply multiplying # of XMR daily transactions times 2kb and lastly multiplying by 365 to tinker around with how much the
04:13:23 <fr33_yourself[m]> chain would grow in fractions of a terabyte(s) under various given daily tx numbers. It was crude, but not baseless. For example, I looked at 100,000 tx to 1 mill tx per day for a year in Terabytes and just considered how that would look over time. But yeah there's nothing special about any of that so I should probably claim ignorance here
04:38:00 <ofrnxmr[m]> 100k tx * 1.5kb = 150mb/day * 365 = 54gb/yrs = 18gb storage req... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/417815cc2f59becb2e8cb1d331f01958c9caa77e>)
04:39:19 <ofrnxmr[m]> Napkin math
04:48:18 <fr33_yourself[m]> > <@ofrnxmr:monero.social> 100k tx * 1.5kb = 150mb/day * 365 = 54gb/yrs = 18gb storage req... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/7800b0a86032ddbbfecafa1ac0ce0f67d54c9092>)
04:48:59 <ofrnxmr[m]> Which is peanuts
04:52:16 <fr33_yourself[m]> I agree especially if Monero price increases with higher # of daily tx, as this makes SSD's cheaper to purchase for past Monero holders who decide to run nodes.
04:52:43 <fr33_yourself[m]> s/I/Especially/, s/agree especially//
04:58:26 <ofrnxmr[m]> Also since you dont need them
04:58:37 <ofrnxmr[m]> You can use an HDD etc as per ravfx
05:07:54 <fr33_yourself[m]> Well if this is all true, then the unique "risk factors" I mentioned earlier are trivial and pretty insignificant. After seeing everything in here today it is my belief that Monero is the best positioned crypto for the long run, since it has already reached it's final emission state and seems to be functioning well.
05:08:50 <fr33_yourself[m]> It does not depend on directly on tx volume and specialized hardware, but rather more so on price to finance CPU miners. 
09:16:10 <plowsof11> wownero has released an update which allows node operators to optionally place an address in a "donation_address" field in get_info https://git.wownero.com/wownero/wownero/releases 
09:19:39 <ofrnxmr[m]> Saw that
09:19:39 <ofrnxmr[m]> Pretty.. different? But not terrible 🤔
09:24:10 <plowsof11> when browser plugin to parse monero nodes get_info as html? 
09:26:08 <ofrnxmr[m]> Wen Monerobull, wen
09:53:57 <monerobull[m]1> What
09:54:48 <monerobull[m]1> I'm not a dev
09:55:54 <ofrnxmr[m]> Grafana 
09:56:03 <ofrnxmr[m]> You are now! Get to work! ❤️
13:29:43 <GuruJi[m]> Hi, how do I use sweep_all in a way not to fuck up my privacy? 
13:29:43 <GuruJi[m]> Let's say wallet has 3 accounts and each account has multiple addresses with funds sent to it. 
13:29:43 <GuruJi[m]> Now I want to use sweep_all (or something better) to empty my wallet but keep the privacy at least on the level of the original wallet. How do I do that?
13:32:08 <ofrnxmr[m]> Probably should have originally used separate seeds
13:32:08 <ofrnxmr[m]> Sweep all will combine the outputs
13:34:58 <ofrnxmr[m]> Depending on how many outputs and addresses you have, im not sure its easy to keep the q similar wallet structure without some leg work
13:40:09 <alpharabius[m]> What is the suicide stack?
13:45:36 <still_stuck[m]> <alpharabius[m]> "What is the suicide stack?" <- i think anything that allows you to live a happy life somewhere in south america
14:19:02 <GuruJi[m]> > <@ofrnxmr:monero.social> Probably should have originally used separate seeds
14:19:02 <GuruJi[m]> > 
14:19:03 <GuruJi[m]> > Sweep all will combine the outputs
14:19:03 <GuruJi[m]> Most probably yes. But now how do I solve the issue? Maybe something else than the sweep_all or something? Creating new wallet with similar structure with 3 accounts and number of addresses?
14:21:31 <plowsof11> are your moneros tainted? 
14:30:33 <alpharabius[m]> Any monero gui devs in chat?
14:30:43 <alpharabius[m]> I need to talk
14:31:35 <ofrnxmr[m]> About what
14:32:02 <Rucknium[m]> alpharabius: In #monero-gui
14:33:16 <alpharabius[m]> Rucknium[m]: Good looks g
14:33:51 <ofrnxmr[m]> (Context. I know what itd about)
14:33:53 <ofrnxmr[m]> Alpha
14:33:55 <GuruJi[m]> <plowsof11> "are your moneros tainted?..." <- As far as I understand it the monejor are fungible and cannot be tainted. 
14:33:55 <GuruJi[m]> My question is related to the sweep_all functionality (or any other command), to be able to clean my current wallet and send the funds to another wallet without compromising or lowering the existing privacy of my current wallet.
14:34:10 <ofrnxmr[m]> Dont waste their time PLEASE
14:34:10 <ofrnxmr[m]> They know already lol
14:34:45 <ofrnxmr[m]> The whole point of the DM is to not piss in the wind 
14:36:59 <GuruJi[m]> * As far as I understand it the moneroj are fungible and cannot be tainted. 
14:36:59 <GuruJi[m]> My question is related to the sweep_all functionality (or any other command), to be able to clean my current wallet and send the funds to another wallet without compromising or lowering the existing privacy of my current wallet.
14:38:01 <Rucknium[m]> Guru Ji: The best source is probably the Breaking Monero series. As far as I know, there has not been rigorous research on best practices to consolidate a large number of outputs. Some people say to consolidate and churn afterwards. Churning has not been rigorously analyzed.
14:38:44 <Rucknium[m]> To be more accurate, churning research has been started, but later abandoned a few times.
14:39:37 <ofrnxmr[m]> I would say churn first, consolidate some time later 
14:39:49 <sech1> sweep_all consolidates everything. If you don't want to consolidate some of your outputs together, you'll have to churn them separately a few times and only then do sweep_all
14:40:13 <ofrnxmr[m]> Churn in pieces, as to split the outputs and create more ring members, then rejoin some time later 
14:40:19 <sech1> churn each output a random number of times (2-4 times) with random interval. Then sweep_all
14:40:19 <ofrnxmr[m]> What sech1 said
15:06:59 <GuruJi[m]> Can you be more specific about churning? How do I separate different outputs not to be mixed? 
15:06:59 <GuruJi[m]> sweep_all seems to have parameter outputs=<N> which can split transactions into N even outputs? 
15:06:59 <GuruJi[m]> I am not sure if the sweep_all can send the N even outputs to N addresses.
15:07:47 <sech1> sweep_single command
15:13:47 <GuruJi[m]> So there is basically no command that would do it bulk? 
15:13:47 <GuruJi[m]> Let's say if you have in your current wallet N outputs and you would use sweep_all with N addresses (generated in the new wallet), wouldn't this solve the issue?
15:14:11 <sech1> sweep_all combines all your outputs
15:14:19 <sech1> if it's ok for you you can do it
15:14:42 <sech1> if not, you'll have to send fund to a new wallet from each of your original addresses
15:15:00 <merope> Feather Wallet allows more detailed coin control, afaik
15:15:16 <merope> Haven't tried it though
15:16:17 <sech1> coin control is not really needed in Monero, unless you have the feds on your tail wanting to find out if that DNM wendor with address X and this tiktoker with address Y get payments to the same wallet
15:16:27 <sech1> for all other cases, use sweep_all
15:16:42 <sech1> and watch breaking monero series
15:16:51 <sech1> it will save you from many silly questions
15:18:43 <sech1> particularly watch everything about poisoned outputs and EAE/EABE attacks
15:19:34 <GuruJi[m]> sech1: This I do actually, just didn't catch the way how to sweep while wallet without unnecessarily compromising existing privacy
15:19:57 <sech1> churn every single output separately
15:20:00 <sech1> then sweep_all
15:20:03 <sech1> I already told you
15:20:15 <sech1> churn a few times
15:20:17 <GuruJi[m]> * This I do actually, just didn't catch the way how to sweep whole wallet without unnecessarily compromising existing privacy
15:20:31 <ofrnxmr[m]> Part about subaddresses / accounts / Janus etc 
15:20:47 <ofrnxmr[m]> .. probably
15:26:51 <GuruJi[m]> <sech1> "churn every single output..." <- "Churning" is sending a single output to a new address and repeating multiple times?
15:27:53 <sech1> you can send it to the same address
15:28:02 <sech1> churning = sending to any address you control
15:30:26 <GuruJi[m]> Thank you it is more clear now
15:44:19 <RavFX[m]> churn every output that are not from you, no less than a few days after reception, no more than 2-3 weeks after reception.
15:44:19 <RavFX[m]> One at a time, at random time.
15:44:20 <RavFX[m]> I think you want ideally the churned output to be in a period where that output tx is used a lot in decoys, And that would be the reason you don't churn it right after reception or after a few months
15:44:49 <RavFX[m]> Minimum 1 day of waiting before churn imo
15:45:46 <GuruJi[m]> > <@gfdshygti53:monero.social> churn every output that are not from you, no less than a few days after reception, no more than 2-3 weeks after reception.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/2696d4a20dd2aceff729b97f875241946f6e3643>)
15:47:29 <RavFX[m]> The same, It "might" just get an inferior anonymity set, Nothing prevent you from churning it again later
15:48:29 <RavFX[m]> Do we have an actual good approved optimal procedure for churning? I think we got lot of discussion about it in the past.
15:48:29 <nioc> I'll just repost what some wise man said.......
15:48:32 <nioc> coin control is not really needed in Monero, unless you have the feds on your tail wanting to find out if that DNM wendor with address X and this tiktoker with address Y get payments to the same wallet
15:49:13 <nioc> but yes it's good to know how things work
15:50:25 <RavFX[m]> Yeah, mostly useful again EAE/EABE attack.
15:50:25 <RavFX[m]> So you do it for all coin that come from untrusted CEX so they don't get informations if you send the same coin back to them later
15:51:08 <Rucknium[m]> RavFX[m]: No. It's on my medium-term TODO list.
15:51:34 <Rucknium[m]> A few people have started research and then abandoned it. Surae, knacc, another person
15:51:40 <RavFX[m]> But also because you don't know if the person you send the Monero to will just dumping right to the same CEX you brought it from.
15:54:35 <RavFX[m]> But normal usage of monero should be fine assuming no threat.
15:54:35 <RavFX[m]> If you use monero like you're bank account like you should, then you will accumulate "coin" and the wallet will send optimally and should rarely use more than one input.
15:54:35 <RavFX[m]> Risk higher for people who buy and dump regularly on CEX and only hodl monero for short period of time
15:56:05 <sech1> Monero CLI/GUI like to use 2 inputs even when they have 1 input with enough XMR in it
15:58:01 <Rucknium[m]> sech1: So they tend toward consolidation to one output over time?
15:58:14 <RavFX[m]> Most of mine seam to be 1 input.
15:58:14 <RavFX[m]> But I use Feather
15:59:13 <RavFX[m]> I do prefer having many coin in my wallet
15:59:13 <RavFX[m]> So if needed I can do many spend in a row
16:01:05 <GuruJi[m]> The fact is that the wallet is old and unused for some time. The amount of moneroj there is not moon but not trivial. Albeit not from any illegal activity or something similar. I left it unattended for some time and would be more happy to have in a more guarded wallet. My stupid.
16:01:05 <GuruJi[m]> I am just trying to find a way how to move it to more safe wallet without unnecessary privacy compromise. Otherwise what would be the point of using privacy coin in the first place 🪙
16:01:05 <GuruJi[m]> I understand it with churning it with sweep_single before sweep_all. If I do sweep_all first, is there a way to churn it afterwards to get at least the similar anonymity set I used to have in the old wallet?
16:02:52 <RavFX[m]> Send it to yourself, wait 3-4 days, send it to yourself again?
16:02:52 <RavFX[m]> If you really want to churn.
16:02:52 <RavFX[m]> Else, just... send it to your new wallet
16:03:13 <RavFX[m]> sweep all, to the same wallet then send the only output to other wallet (3-4 days after)
16:04:38 <sech1> If you sweep_all first, you can just keep doing sweep_all a few more times after that (it will just sweep the only output)
16:04:46 <sech1> each sweep increases your anonymity set
16:04:57 <sech1> but do it with random intervals from hours to days between sweeps
16:06:09 <GuruJi[m]> Thank you people 🐸
16:08:01 <GuruJi[m]> Last question. sweep_all empties all accounts, whole wallet, right? I saw some old threads like 4 years ago that claimed the sweep_all didn't actually sweep it all. 
16:11:10 <sech1> it can sweep the whole wallet, or just one account
16:11:13 <sech1> sweep_all [index=<N1>[,<N2>,...] | index=all] [<priority>] [<ring_size>] [outputs=<N>] <address> [<payment_id (obsolete)>]
16:11:39 <sech1> index=all by default, but it can be an account index
16:12:04 <sech1> or comma-separated list of account indices
16:12:22 <sech1> oh, there's even sweep_account <account> [index=<N1>[,<N2>,...] | index=all] [<priority>] [<ring_size>] [outputs=<N>] <address> [<payment_id (obsolete)>]
16:12:27 <sech1> I need to read docs more often :D
16:12:48 <sech1> and that one has index too (I assume it's subaddress index)
16:13:00 <sech1> so you can do very fine-grained sweeping
16:13:14 <plowsof11> i need to add sweep_account to the docs
16:13:54 <sech1> sweep_all: If the parameter \"index=<N1>[,<N2>,...]\" or \"index=all\" is specified, the wallet sweeps outputs received by those or all address indices, respectively. If omitted, the wallet randomly chooses an address index to be used. If the parameter \"outputs=<N>\" is specified and  N > 0, wallet splits the transaction into N even outputs.
16:15:07 <sech1> plowsof11 for me source code is "the docs" :D
16:15:12 <plowsof11> no rpc method for sweep_account :( 
16:15:55 <RavFX[m]> plowsof11: Nothing prevent you from adding one :)
16:17:27 <plowsof11> lack of ability != nothing 
16:17:53 <plowsof11> maybe sweep_account is === sweep_all with an index specified 
17:13:56 <CidadodoMonerist> Hello guys
17:14:08 <CidadodoMonerist> Whats popping?
17:36:25 <ofrnxmr[m]> Nohello.net probably
19:09:18 <DanIsnotthemanBr> Hello from the other side
19:10:05 <ofrnxmr[m]> Hi
19:25:25 <DanIsnotthemanBr> 🤨
21:30:11 -xmr-pr- [meta] Rucknium opened issue #782: Monero Research Lab Meeting - Wed 18 January 2023, 17:00 UTC
21:30:11 -xmr-pr- > https://github.com/monero-project/meta/issues/782
21:42:16 <anhdres[m]> First Monero Garden update: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/346#note_20361
21:57:05 <plowsof11> Thank you anhdres! looking forward to the first version. the push/pull/squash cool kids will get a chance to keep it updated and contribute in the future 👍️