<p​rivacywave:matrix.org> Do people sell local nodes. Is that a thing.

<p​rivacywave:matrix.org> Like somebody charged a few dollars for access to a private node, is that feasible

<m​onerobull:matrix.org> fyi before i get accused of being literally hitler again

<m​onerobull:matrix.org> i just nuked 2 monero.town accounts that were recently created with their only ever activity being to shill openmonero and put down haveno

<m​onerobull:matrix.org> using chatgpt text (just like the openmonero admin)

<m​onerobull:matrix.org> .town was created to combat bots and this shit will not be tolerated

<m​onerobull:matrix.org> openmonero has repeatedly attacked haveno in what is obviously just self-interest, trying to get more people to use their inferior, less secure centralized exchange (that already has been "hacked" lol)

<m​onerobull:matrix.org> bad actor behavior

<3​21bob321:monero.social> Openmonero spams bs in monerotopia room anyway

<x​mrcookies:envs.net> It is probably partly self interest of course, but I think some of their criticisms of Haveno are valid. There is a lot more money at risk when offers all sits there prefunded. Nothing is stopping malicious admin/arbitrators from pretending to be a takers, ruling in their own favor, and sweeping the whole orderbook. Instead there should at least be an option to fund the trade only<clipped message>

<x​mrcookies:envs.net> when it's taken (security deposit would still be required to post an offer) to greatly reduce the incentive and damage.

<m​onerobull:matrix.org> trades are only funded when they are taken, this particular issue is when the arbitrator and taker collude or are the same person

<m​onerobull:matrix.org> easily solved by expanding the passphrase offers to a more broader sense than no deposit offers

<m​onerobull:matrix.org> woodser: would it be possible to just slap the passphrase requiremetn as an option for regular deposit offers with minimal other changes?

<m​onerobull:matrix.org> woodser: would it be possible to just slap the passphrase requirement as an option for regular deposit offers with minimal other changes?

<m​onerobull:matrix.org> youd still keep the deposits but have the passphrase as an optional, additional, requirement

<m​onerobull:matrix.org> should solve the arbitrator collusion vector

<x​mrcookies:envs.net> I think this is a good idea if you met the trader somewhere outside Retoswap, and using Retoswap as the place to do the trade. But not sure how that would help someone just browsing Retoswap offers or makers that simply post an offer and wait for anyone to take it. Unless I'm not understanding

<m​onerobull:matrix.org> you put contact details in the offer

<m​onerobull:matrix.org> like a matrix username

<m​onerobull:matrix.org> the buyer then writes you, asking for the passphrase

<m​onerobull:matrix.org> it makes trades a lot slower and adds a ton of friction but it makes it impossible for a rogue arbitrator to just take the whole orderbook

<m​onerobull:matrix.org> imo it should be an option for people who want that extra security

<x​mrcookies:envs.net> I think I see what you're getting at now and seems like it would achieve the same effect. I like the idea. At least having the option to do that

<m​onerobull:matrix.org> no deposit offers already work this way and its actually quite pleasant

<m​onerobull:matrix.org> with regular offers and (currently) no haveno app, you might have offers up but cant respond to them in a timely manner but if someone first pings you, you know that you can expect that a trade will happen, at least in a general timeframe

<f​iatdemise:matrix.org> What's coming next after v18.4.1? Will that only have bug fixes, or will it have features too?

<o​frnxmr:monero.social> Bug fixes

<o​frnxmr:monero.social> 1842 is next

<f​iatdemise:matrix.org> How about after that? I'm trying to get an idea of when multi recipient URI will get deployed.

<f​uckqubic51:matrix.org> Will qubic really 51 monero? Whats the current situation?

<o​frnxmr:xmr.mx> The pr is not against release branch

<o​frnxmr:xmr.mx> So it wont be released until we branch from master (and it needs reviews & testing anyway)

<o​frnxmr:xmr.mx> Branching from master is in the plans, but the pr isnt even merged. Have you tested it?

<o​frnxmr:xmr.mx> I don't think mobile wallets need the pr to implement the functionality

<o​frnxmr:xmr.mx> They dont run a parse_uri call when pasting in an address (afaik). They parse it themself

<f​iatdemise:matrix.org> I haven't tested yet, no. Don't know how. I've been pestering Cake to look into it, they said they would and it shouldn't be a big lift, but no ETA. Mentioned to Edge too, said should be possible, but again, no ETA.

<o​frnxmr:xmr.mx> I dont think either of them use upstream functionality for uris

<o​frnxmr:xmr.mx> the pr adds functionality for cli and perhaps rpc

<o​frnxmr:xmr.mx> To test it, youd pull in the pr on top of master branch, then built it, then try to do a transfer with a multi destination URI

<o​frnxmr:xmr.mx> But for generating URIs, youd just make sure the URI is compatible with what is proposed in the PR, and then cake would add ability to recognize it to their pastes and qr scanning

<o​frnxmr:xmr.mx> ```

<o​frnxmr:xmr.mx> monero:46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em;888tNkZrPN6JsEgekjMnABU4TBzc2Dt29EPAvkRxbANsAnjyPbb3iQ1YBRk1UXcdRsiKc9dhwMVgN5S9cQUiyoogDavup3H?tx_amount=239.39014;132.44&tx_description=donations

<o​frnxmr:xmr.mx> ```

<o​frnxmr:xmr.mx> Here is the expected syntax that cake has to recognize

<o​frnxmr:xmr.mx> Pinging [@anon_contributor_xmr:monero.social](https://matrix.to/#/@anon_contributor_xmr:monero.social) and [@diego:cypherstack.com](https://matrix.to/#/@diego:cypherstack.com) as well

<o​frnxmr:xmr.mx> Spec is here github.com/monero-project/monero/blob/master/docs%2FURI_SCHEME.md

<d​iego:cypherstack.com> Josh Babb: ^