<m​03w:matrix.org> MoneroKon needs some love and piconeros, changing organisation type and more transparent financials also

<m​03w:matrix.org> using a cold + hot wallet setup as CCS, but the hot one will be a RINO multisig (read till the end)

<m​03w:matrix.org> funding.monerokon.com

<1​23bob123:matrix.org> Hmm

<a​ndrewski:matrix.org> working now thanks

<o​frnxmr:monero.social> Ty plow

<p​lowsof:matrix.org> passing the thanks forward to ofrnxmr from the last person who did it to me

<1​23bob123:matrix.org> Pay it forward

<k​eepemup:matrix.org> Is using torsocks with monerod better than using the --proxy switch?

<r​ecanman:agoradesk.com> Torsocks IIRC uses ld_preload, so it might leak if it doesn't use libc

<r​ecanman:agoradesk.com> I would assume that it does but I'm not sure

<n​aphtha:kyun.host> someone

<n​aphtha:kyun.host> please help me find a monero nostr client i saw a couple days ago

<n​aphtha:kyun.host> it had a monochrome color scheme

<n​aphtha:kyun.host> like full black and white

<t​imklsfr:matrix.org> Hello, I was transferred money to the address, but they came to me, who would help me so that I could figure out what the problem is?

@timklsfr I think you might need some translation help - it is unclear what your issue is.

<u​nkn8wn69:matrix.org> Guys whats your setup for running monerod node via tor?

<u​nkn8wn69:matrix.org> I've been using torsocks command infron of rest. But wanted to know what you guys have best experience with

<u​nkn8wn69:matrix.org> Yes ive read that. So general would be better to seperately run a tor proxy and just use --tx-proxy?

tx-proxy only sends transactions over Tor, blocks get sent over clearnet

you can use --proxy as an alternative for torsocks

<a​lfieedwards:monero.social> Why not whonix approach? You could run monerod in an environment where all traffic is torified. Like a vm in Xen host or docker container.

<u​nkn8wn69:matrix.org> Im using local raspi

<u​nkn8wn69:matrix.org> And i want it to be available on local wifi yk

<u​nkn8wn69:matrix.org> I mean probably would somehow be possible with a whonix vm on my raspi but ig it would also take too much ram

<a​lfieedwards:monero.social> Custom docker setup could solve that. There are solutions plus you may always foward a port from it.

<a​lfieedwards:monero.social> And it will protect from any IP leaks.

<u​nkn8wn69:matrix.org> Yeah i tried with monerosuite, but I didnt find a good docker image for tor proxy that supports amdv7

<u​nkn8wn69:matrix.org> Yeah i tried with monerosuite, but I didnt find a good docker image for tor proxy that supports amd64

<u​nkn8wn69:matrix.org> Yeah i tried with monerosuite, but I didnt find a good docker image for tor proxy that supports arm64

<a​lfieedwards:monero.social> Guess you would have to build custom docker images for it and then routing traffic with iptables.

<a​lfieedwards:monero.social> blog.jessfraz.com/post/routing-traffic-through-tor-docker-container there is an example, of course jess/tor image would not work for amd64.

<u​nkn8wn69:matrix.org> Yes, thank you tho. Maybe (tho less secure) I could also use my local mashines tor proxy

<u​nkn8wn69:matrix.org> using this in the docker-compose:

<u​nkn8wn69:matrix.org> environment:

<u​nkn8wn69:matrix.org> - http_proxy=socks5://127.0.0.1:9150

<u​nkn8wn69:matrix.org> - https_proxy=socks5://127.0.0.1:9150

<a​lfieedwards:monero.social> It may not work as Socks5 aren't meant to use as HTTPS proxy.

<a​lfieedwards:monero.social> HTTPTunnelPort [address:]port|auto [isolation flags]

<a​lfieedwards:monero.social> Open this port to listen for proxy connections using the "HTTP CONNECT" protocol instead of SOCKS. Set this to 0 if you don’t want to allow "HTTP CONNECT" connections. Set the port to "auto" to have Tor pick a port for you. This directive can be specified multiple times to bind to multiple addresses/ports. See SOCKSPort for an explanation of isolation flags. (Default: 0)

<a​lfieedwards:monero.social> in torrc

<a​lfieedwards:monero.social> I have some complex problem with sending transfers over RPC that I have been struggling for months to solve without success. I see some solutions however each one has its drawbacks. Anyone would want to help and think about this together?

That is on topic here. Just explain your issue and wait, maybe someone will have something to say about it.

<a​lfieedwards:monero.social> I have developed a custom payment processing system for an service. In past it was running on some decommissioned Bitcoin wallet software which allowed better control of coins. In particular, system was able to:

<a​lfieedwards:monero.social> 1. Generate unique address for every payment.

<a​lfieedwards:monero.social> 2. Handle coins of each address separately.

<a​lfieedwards:monero.social> 3. Send funds to recipient and a change as a service fee to cold wallet, which from network fee was also subtracted.

<a​lfieedwards:monero.social> Third point was the most important, as this feature (subtract fee parameter set to true for a chosen destination besides address and amount) allowed to avoid dust change left on each deposit address.

<a​lfieedwards:monero.social> Today, system works only on Monero with official wallet software:

<a​lfieedwards:monero.social> 1. Generates unique subaddress for every payment.

<a​lfieedwards:monero.social> 2. Sends funds to recipient (from whole wallet) and then saves information about service fee earned.

<a​lfieedwards:monero.social> 3. Once each day it sends accumulated service fee (from whole wallet) to cold address.

<a​lfieedwards:monero.social> This works most of the time. Unfortunately, for larger amounts (+30 XMR, sometimes +20XMR) it fails to send as created transaction is too large. Error message suggests using transfer_split, however this is not the perfect solution in my opinion. Recipient may receive funds in many smaller amounts and to better describe the issue, imagine sending 1000 XMR in 100 transfers, 10 XMR e<clipped message>

<a​lfieedwards:monero.social> ach. It should work like in Bitcoin, except there is no subtract fee parameter in transfer RPC call.

<a​lfieedwards:monero.social> So there are a few concepts I came up with:

<a​lfieedwards:monero.social> 0. This is point 0 since it was already tested without much success. I simply consolidated funds (grouped in less, bigger amounts) when moving them to new wallet. It helped for some time, transfer sizes were smaller and it doesn't cost me any code changes. Cons: change coins made wallet big again and solution stopped working...

<a​lfieedwards:monero.social> 1. Calculate best (with lowest numer of txs) combination of transfer_split if transfer fails and resend. Cons: one transaction split to many transfers...

<a​lfieedwards:monero.social> 2. Consolidate funds on separate wallet account for "bigger" transactions. Cons: how much is bigger? Transfer size limit may be reached anyway...

<a​lfieedwards:monero.social> 3. Rewrite system to work similar to previous one. Cons: will sweep_all work to consolidate service fees from subaddresses of finished transactions? Will it not lock itself? A lot of coding is required...

<a​lfieedwards:monero.social> Tl;DR current system works but it is not perfect. It should be more scalable...

<a​lfieedwards:monero.social> and... there is no much control over change in Monero wallet software or I could not find it in RPC docs.

would this open PR give you more control over change? monero-project/monero #8861

<a​lfieedwards:monero.social> Yes, exactly. I have been thinking with bypass like using sweep_all in some clever ways. It would however, at best, make transfers stand out (just one destination without change for sweep_all etc)

wallet2 will automatically include a dummy output if there would otherwise be only one.

<a​lfieedwards:monero.social> And FYI, this feature (subtract_fee flag) is available in Wasabi Wallet (for Bitcoin)

<a​lfieedwards:monero.social> Thanks, I have not studied source code that much. This PR would allow to set subtract from subaddress, however it would be best to set it to destinations instead.

<a​lfieedwards:monero.social> Or both, the more control the better as there might be other cases.

So what you need, in addition to the patch above, is a way to set the change address to something else than the default, right ?

<a​lfieedwards:monero.social> In my case it would be sending net value to recipient and sending any rest minus network fee to cold wallet in single transfer. Another case would be refunds, where all funds minus network fee are sent to recipient.

I have an old patch that does this, can't recall if it's working though. I can post it if someone else wants to check it and fix it if it needs to be.

<a​lfieedwards:monero.social> I guess it wouldn't be needed to set change address in my case. If I set destinations to recipient_address (without subtract_fee flag) and coldwallet_address (with subtract_fee flag) for total of subaddress balance, then wallet shouldn't create change address.

Ah, yes. I believe this is correct.

<a​lfieedwards:monero.social> I know subaddress balance, I just don't know network fee yet (and wouldn't set any arbitrary fee value to not stand out).

You could try the patch linked above then. It shouldn't require a fork nor make txes look different so is usable now.

<a​lfieedwards:monero.social> I will test that, thank you.

<a​lfieedwards:monero.social> Is there any ETA on this PR? It would be best to use this feature in official release.

Looks like there are unaddressed comments, so the author may have decided the changes aren't worth doing, or simply did not notice. There's an at least two week delay before a patch can be merged (absent urgent needs), but this lapsed long ago on this one.

After a patch is merged though, a release happens at irregular intervals, and a new feature would only be included in a major release (ie, not a bugfix release).

So... not in the near future.

Jeffro256 ^

<a​lfieedwards:monero.social> I have asked jeffro256 via PM.

<p​lowsof:matrix.org> a moment of silence for jeffros inbox x