nice, tyvm

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.

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.

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.

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.

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.

I actually have some very old code that did this in the wallet...

Poisson distributes delays and sends whenever current time is >= threshold whenever the wallet's open.

Anyway, I'm very wary of chain bloat from people who'd use this as cargo cult as a matter of course.

> 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

valid, but bored to the tits and this is something to spend the time with so :shrug:

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

> 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.

wouldn't this require tags to be put on chain? i thought tags was just something that your wallet keeps track of locally

whats Poisson?

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.

ah okay makes sense

thanks

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

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.

You probably can't pre-create a string of churns though, since you won't know where your first outputs lands as an index.

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)

> You probably can't pre-create a string of churns though, since you won't know where your first outputs lands as an index.

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?

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)

needmoney90: per subaddress would be nice

Basically, we dont have solid coin control at the moment, and its kind of necessary to deal with targeted attacks

needmoney90: You can blacklist offending outputs

As well as use 'sweep_single' to manage outputs individually

sure, but it's...touchy

we need a better UI

UX

having a command to churn key image would be a nice shortcut

You can with sweep_single basically

any diea what would cause the error listed here monero-project/monero #4718 ? im using nitrogen nebula version clients, which are definitely released after the supposed fix, and im 99% certain i have the require funds

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.

yes my mistake monero-project/monero #3869

If you are using a remote daemon, it may be lying to you (purposefully or not). Or there may be a bug.

Or you are on testnet with a client that's more than three days old.

> Or you are on testnet with a client that's more than three days old.

what do you mean by this? im running a local testnet/private network

i started monerod with `--testnet --no-igd --hide-my-port --data-dir testnet/node1/datadir --fixed-difficulty 100 --offline --detach`

i started monero-wallet-rpc with `--testnet --disable-rpc-login --prompt-for-password --rpc-bind-port 6061 --wallet-dir=testnet/node1`

ive had this testnet active for i think, 6-7 days?

Try rescan_bc in the wallet and sending again.

ok thanks

Just don't try to use that client on the actual testnet.

yea im just using it for local development

I've created an issue for the automatic churning of flagged subaddresses idea, would love any feedback from those with thoughts on the matter!

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

fluffypony: monero-project/unbound #16

.soon

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.

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?

I understand you can't pre-emptively optimize for a brand new key. Mainly focused on DoS attacks based on dated RandomX instantiations.