01:03:20 nice, tyvm 01:04:26 I'd wait till people who are looking at it have come up with best practices, lest this gets established as a matter of course for most people who'd gain nothing from it. 01:05:19 IOW, it should be applied when needed rather than a matter of course. Maybe clear notices in the tool would work to make it plain to users. 01:17:08 Also, in order for the tool to schedule txes, it will need to keep the wallet keys handy. Care should be taken with those, since it'll likely be unattended. Many people don't lock their terminal when away. 01:23:51 A couple days ago, someone mentioned tagging subaddresses as linked to an identity (sorry, can't recall who mentioned this). Churning would be enabled for those only. 01:24:15 If you pre-roll the txes and schedule them, this may show if the delay is long, due to an offset in fake oyt selection. 01:24:32 I actually have some very old code that did this in the wallet... 01:24:57 Poisson distributes delays and sends whenever current time is >= threshold whenever the wallet's open. 01:25:51 Anyway, I'm very wary of chain bloat from people who'd use this as cargo cult as a matter of course. 01:33:23 > I'd wait till people who are looking at it have come up with best practices, lest this gets established as a matter of course for most people who'd gain nothing from it 01:34:15 valid, but bored to the tits and this is something to spend the time with so :shrug: 01:35:12 i will say however, it has to be pretty hard to research churning with basically no up to date churning software out there, the most recent one I say was a 4 year old python project 01:39:19 > A couple days ago, someone mentioned tagging subaddresses as linked to an identity (sorry, can't recall who mentioned this). Churning would be enabled for those only. 01:39:34 wouldn't this require tags to be put on chain? i thought tags was just something that your wallet keeps track of locally 01:40:16 whats Poisson? 01:48:07 No, you'd tag your own address, stored in the wallet cache. Poisson's a particular distribution, models well block times. Might or might not be well suited for churning. 01:54:04 ah okay makes sense 01:54:04 thanks 02:21:09 Ah yeah, ring members is another way to 'date' a tx creation, since outputs are selected from a gamma distribution. Youngest output in a ring should be ~near in time to when a tx is created 03:12:51 I suppose you can offset the gamma picks if you know when the tx is scheduled to go. If you pick one that's too young, you reroll. So it's not going to be perfect, but probably good enough. 03:13:32 You probably can't pre-create a string of churns though, since you won't know where your first outputs lands as an index. 03:21:10 What would you guys think of adding a 'Paranoid' mode to the wallet? Manually confirm every incoming transaction to make sure you know who sent it, and blacklist/quarantine offending outputs (poisoned output attack protection) 04:20:54 > You probably can't pre-create a string of churns though, since you won't know where your first outputs lands as an index. 04:21:18 moneromooo: can you clarify what you meant? do you meant i cant create one churn, and then another churn that uses the output of the first churn and scheudle them that way? 05:23:39 bonedaddy: that's right; to spend an output you reference its on-chain index, so you can't 'spend' outputs that haven't been added to the chain (i.e. make transactions with them) 07:46:54 needmoney90: per subaddress would be nice 07:48:46 Basically, we dont have solid coin control at the moment, and its kind of necessary to deal with targeted attacks 08:14:07 needmoney90: You can blacklist offending outputs 08:14:19 As well as use 'sweep_single' to manage outputs individually 08:14:29 sure, but it's...touchy 08:14:34 we need a better UI 08:14:37 UX 13:57:23 having a command to churn key image would be a nice shortcut 14:26:42 You can with sweep_single basically 14:50:31 * sethsimmons sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/UxtmhdMcgJitWiWasuoslqgu/message.txt > 18:34:19 any diea what would cause the error listed here https://github.com/monero-project/monero/issues/4718 ? im using nitrogen nebula version clients, which are definitely released after the supposed fix, and im 99% certain i have the require funds 18:52:18 Wrong issue ? That was just someone sending funds after a hardfork with an old client that was not allowed to the network any more. There is no fix there. 19:01:21 yes my mistake https://github.com/monero-project/monero/issues/3869 19:06:33 If you are using a remote daemon, it may be lying to you (purposefully or not). Or there may be a bug. 19:12:08 Or you are on testnet with a client that's more than three days old. 19:34:00 > Or you are on testnet with a client that's more than three days old. 19:34:14 what do you mean by this? im running a local testnet/private network 19:34:31 i started monerod with `--testnet --no-igd --hide-my-port --data-dir testnet/node1/datadir --fixed-difficulty 100 --offline --detach` 19:34:41 i started monero-wallet-rpc with `--testnet --disable-rpc-login --prompt-for-password --rpc-bind-port 6061 --wallet-dir=testnet/node1` 19:35:02 ive had this testnet active for i think, 6-7 days? 19:40:37 Try rescan_bc in the wallet and sending again. 19:40:46 ok thanks 19:40:56 Just don't try to use that client on the actual testnet. 19:41:12 yea im just using it for local development 19:45:03 I've created an issue for the automatic churning of flagged subaddresses idea, would love any feedback from those with thoughts on the matter! 19:45:03 https://github.com/monero-project/monero/issues/6801 19:49:02 -xmr-pr- sethsimmons opened issue #6801: Allow automatic churning of incoming transactions to "flagged" subaddr... 19:49:02 -xmr-pr- > https://github.com/monero-project/monero/issues/6801 20:23:08 what would cause a transfer to fail with the error "not enough money" even though i have enough unlocked funds? im using monero-wallet-rpc 20:49:25 fluffypony: https://github.com/monero-project/unbound/pull/16 20:49:32 .soon 23:24:07 Question about the internals. How is the RandomX VM managed? Specifically talking about detached tips which you can't verify the work of without knowing the cache key which forces a cache regen which is... expensive. 23:25:31 Does Monero just bite that cost or is there some optimization in play, such as saving historical cache states to disk and therefore not requiring a regen? Or keeping the old VM around for a few blocks after a new key is put in play? 23:25:59 I understand you can't pre-emptively optimize for a brand new key. Mainly focused on DoS attacks based on dated RandomX instantiations.