<3​21bob321:monero.social> repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/538

<3​21bob321:monero.social> am i blind and cant see the cost ?

Clicking on 'changes' will show the funding breakdown . "amount" is the total with the milestones below. 273 XMR

<3​21bob321:monero.social> also seems like they will ask for more money later ?

<3​21bob321:monero.social> other question is will they maintain it after this

<n​apoly:matrix.org> not sure what makes you think that.. there is definitely a space for another ccs tho..

<n​apoly:matrix.org> there isn't any maintenance in the sense of '1-year maintenance for XY XMR.'.. however, we are committed to ensuring a smooth migration for merchants and providing some post-release support. honestly, we need to figure out a sustainable model to fund maintenance, as it's clear that the Monero bounties haven't been effective in this case.

<o​frnxmr:xmr.mx> Isnt btcpayserver already creating the plugin

<o​frnxmr:xmr.mx> Q2.How many bounties have you opened or claimed, to make the assumption that bounties arent effective?

<n​apoly:matrix.org> Good question!.. I was just hunting bounties after finishing up putting Haveno into production, as you might remember... I wasn’t planning to create plugins here, nor was I aware that the BTCPayServer team was moving towards a plugin architecture.. There were some signs, tho.. like them not wanting to merge my changes and the lack of anyone claiming ownership of the code.. Here'<clipped message>

<n​apoly:matrix.org> s a comment for context: btcpayserver/btcpayserver #6239#issuecomment-2373616306.

<n​apoly:matrix.org> ..long story short, it took us some time to figure all this out.. There are different scenarios now, like leaving the migration to Dorier (which he wanted to avoid—that’s the whole point of the plugin architecture). That said, he doesn’t fully grasp what we’re solving here, since their focus is mainly on BTC.

<n​apoly:matrix.org> This work should also help prepare for multi-wallet support and make things more flexible down the road.....

<n​apoly:matrix.org> check the CCS.. i did not open any

<o​frnxmr:xmr.mx> So how can you say its not effective?

<o​frnxmr:xmr.mx> the ccs says it wants to be assigned so some active bounties

<n​apoly:matrix.org> cuz btcpayserver guys r fixing our shit

<n​apoly:matrix.org> and they r tired of it

👀

<o​frnxmr:xmr.mx> btcpayserver/btcpayserver #6239#issuecomment-2481847461 this comment is accurate afaict. Pr seems broken anyway?

<n​apoly:matrix.org> and why should i continue to fix it.. once the code base have completely shifted.....

<o​frnxmr:xmr.mx> It runs 1 wallet, which means 1 daemon

<o​frnxmr:xmr.mx> Your ccs claims to add lws, which invalidates the pr in entirety and disqualifies the bounties 🤔

<o​frnxmr:xmr.mx> Even your prior or is fundamentally broken, cuz cake node would need to have tx-notify enabled

<o​frnxmr:xmr.mx> The warning doesn't make sense either, cuz if you had access to setup tx/block-notify, you can obviously trust the node

<o​frnxmr:xmr.mx> So whether codebase shifted or not, the pr was invalid for multiple reasons. (Not understanding btcpayserver). Seems the one not grasping what youre trying 2 do is you, tbf. Doirier noted That the pr could be trivially ported to the plugin

I emailed kukks and he said monero plugin will be in version 2.1

<o​frnxmr:xmr.mx> github.com/btcpayserver/btcpayserver-monero-plugin

Welcome napoly. Tap on ofrn profile and hit `Block contact`.

👍️😎

<o​frnxmr:xmr.mx> Good luck blocking me from irc. Why'd u leave on matrix?

/ignore -regexp -pattern ofrnxmr *

<o​frnxmr:xmr.mx> Lmk how it goes

"Regardless of your choice, I believe a multi-wallet Monero plugin is an important goal and efforts of @napoly should be encouraged. The current single-wallet plugin poses security risks when the server is shared with other parties."

And yet once again, ignoring ofrn would improve your Monero community experience!

<o​frnxmr:xmr.mx> Did i say anything about multiwallets etc? No, shithead

<o​frnxmr:xmr.mx> the proposal calls for including lws ya fkn noob. Clearly that would allow multiwallets

<o​frnxmr:xmr.mx> My point was that the plugin is already started by nicholas, and there is no mention of such in the proposal.

And this is the type of verbal diarrhea all the channels this tool subjects to.

Beautiful.

<o​frnxmr:xmr.mx> Napoly's pr from a few months ago was to add remote rpc, and missed 1. Block-notify 2. was put on store settings, which doesnt account for the fact that rpc is per instance, not per store 3. Even under lws you cant use a random remote node. the node has to be configured to allow lws (zmq)

<o​frnxmr:xmr.mx> So thx for your half-a-cent of insight, but next time, try to know what youre talking about

The best part is that he never shuts the fuck up!

<o​frnxmr:xmr.mx> And stop projecting onto me. You ragequit matrix and irc because you arent allowed to tell ppl to kill themselves on a daily basis.

See? Keeps going!

<s​yntheticbird:monero.social> username checks out?

syntheticbird meooooooooooowwwwwwwwwwwwwwwwwww.

purrrrrrrrrrrrrrrrrrrrrrrrrr.

<s​yntheticbird:monero.social> PUUUURRRRRRRRRrrrrrr

<s​yntheticbird:monero.social> didn't know dukenukem was rotten

<s​yntheticbird:monero.social> thats a plot twist

<o​frnxmr:xmr.mx> its one of his like 26 accounts

what kind of world do you live in, kitty kat.

<j​0j0xmr:monero.social> So the plugin is already developed and this CCS isn't necessary?

lol.

<o​frnxmr:xmr.mx> The ccs has additions, but correct. There is a plugin

<s​yntheticbird:monero.social> According to ofrnxmr, the issue is that this CCS didn't mentioned the already in development plugin. Maybe there is a sensible difference between the two ?

<s​yntheticbird:monero.social> ah ok alright

<j​0j0xmr:monero.social> So it would make sense to make the CCS about maintaining and adding to the existing plugin then?

<p​lowsof:matrix.org> "After the release of version 2.1, the btcpayserver-monero-plugin repository will be transferred to someone trusted within your community."

<o​frnxmr:xmr.mx> Ccs plans to add lws (and with it, multiwallet support). But the existence of a plugin for btcpayserver 2.1 is already being worked on by btcpayserver devs

<j​0j0xmr:monero.social> Remote node and multi-wallet support.

<o​frnxmr:xmr.mx> Yes

<j​0j0xmr:monero.social> Since they are looking for a community member to transfer ownership to.

<o​frnxmr:xmr.mx> Lws included multiwallet, remote node not feasible with lws

<o​frnxmr:xmr.mx> Lws requires zmq ports (both) exposed

<j​0j0xmr:monero.social> Can be either/or though.

<j​0j0xmr:monero.social> Choose local daemon + LWS or use remote node.

<o​frnxmr:xmr.mx> maintaining an rpc instance and an lws instance sounds like wrong approach. But lws only comes with another issue: no wallet support

<o​frnxmr:xmr.mx> So every btcpayserver merchant will have to use mymonero's broken wallet? Lol 🤷‍♂️

<j​0j0xmr:monero.social> Why does BTCPayServer need LWS support? Isn't that better for spending rather than receiving?

<j​0j0xmr:monero.social> It just needs to be online and synced.

<o​frnxmr:xmr.mx> Lws just makes it easy to create multiple "view" wallets on the server

<o​frnxmr:xmr.mx> But it makes it harder for merchants to use those wallets, bcuz it requires the lws server be online to use the wallet

<j​0j0xmr:monero.social> But then requires a local daemon on the BTCPay server.

<o​frnxmr:xmr.mx> btcpayserver (and lws) down? Rip wallet

<o​frnxmr:xmr.mx> restore seed somewhere else

<p​lowsof:matrix.org> the monero-lws is presumably for providing btcpayserver to multiple third parties? napoly whats the reason for it?

<o​frnxmr:xmr.mx> Mymonero seed? 13 words? Rip

<p​lowsof:matrix.org> we may have to fund someone to come up with a fee model in that case!

<o​frnxmr:xmr.mx> Imo the proposal is premature (shouldnt be made before plugin is passed off from by pay server to "us") and not well thought out

<o​frnxmr:xmr.mx> Having multiple wallets using rpc is possible. Just need multiple rpc instances.

<o​frnxmr:xmr.mx> remote nodes with rpc require block-notify, unless the core code is changed to watch for blocks

<o​frnxmr:xmr.mx> I havent tried lws in probably over a year now, but maybe theres an easy way to import a view key from a full wallet

<p​lowsof:matrix.org> for more context here is a request for hosting for third parties btcpayserver/btcpayserver #1505

<p​lowsof:matrix.org> similar to how you can host monero payment processors for your friends with bitcart docs.bitcart.ai/deployment/thirdpartyhosting

my landlord talking bout something, sponsored by xmr!D

<o​frnxmr:xmr.mx> Right. Using rpc the only way would be to run multiple instances of wallet-rpc

<r​ucknium:monero.social> Each instance of wallet-rpc uses a bunch of RAM. Not good for a small VPS.

<o​frnxmr:xmr.mx> Let me see how much ram my rpc is using

<p​lowsof:matrix.org> 2GB (during wallet sync). bitcart (and acceptxmr) dont have this limitation as they use monero rust libraries (or similar)

<o​frnxmr:xmr.mx> 2gb is so 2024

<o​frnxmr:xmr.mx> Also next release fixes broken initial sync where it (fast) syncs from genesis bcuz it doest know the cirrent block

<o​frnxmr:xmr.mx> Looks like 50mb for rpc right now

<o​frnxmr:xmr.mx> 44000kb is res

<o​frnxmr:xmr.mx> So for an instance running multiple wallet-rpc's it would be ~50mb/instance under normal weather

vtnerd we dont need monero-lws anymore^

<s​yntheticbird:monero.social> vtnerd gonna have a heart attack reading this.

(jokes, we need wallets that use it!) but is this new lower memory usage/performance true?

<s​yntheticbird:monero.social> he spent so much effort into it

<s​yntheticbird:monero.social> vik (Cake): We need Remote Wallet functionnality (aka LWS) into Cake Wallet

<s​yntheticbird:monero.social> Pretty please

with background sync - there is a hackish way to download the wallet files and have a monero-lws experience but , its a hack

due to the wonders of jbermans work

<o​frnxmr:xmr.mx> Lower memory usage should be true. Basicswap runs monero and wownero rpcs, both at sub-50mb sizes. And a fix (merged) for sync missing tip block fixes initial sync. Current (released) fix for close wallet fixes resyncing the same blocks repeatedly

<o​frnxmr:xmr.mx> Background sync seems more like a cli feature. Rpc can open a view wallet and maintain its sync with minimal resources

<o​frnxmr:xmr.mx> Still, the problem here is if you use the btcpayservers LWS, you require a the LWS server (btcpay) to remain online

<o​frnxmr:xmr.mx> Otherwise you have to share tour view key with multiple lws servers (is that even supported? Switching servers?)

<s​yntheticbird:monero.social> ofrnxmr as always you find a problem that is one because it goes beyond the scope of the original thing.

<s​yntheticbird:monero.social> Of course LWS needs to stay online, it's a Server remember

<s​yntheticbird:monero.social> Light Wallet Server

<p​lowsof:matrix.org> does kewbit know c#?

<o​frnxmr:xmr.mx> 🔭

<o​frnxmr:xmr.mx> 🔬

<o​frnxmr:xmr.mx> No inbetween!

<p​lowsof:matrix.org> asking for a friend

<s​yntheticbird:monero.social> Claude do so kewbit might

<o​frnxmr:xmr.mx> This is my point tho

<o​frnxmr:xmr.mx> Having a wallet for lws would mostly be beneficial for creating the wallet on the server automagically

<o​frnxmr:xmr.mx> But if you cant switch servers, then it might have issues for the wallet to rely on the btcpayserver .. in which case it might be better for lws to only be used for btcpay, and not for the hot wallet

<o​frnxmr:xmr.mx> (hot wallet = full wallet. Btcpay = view = lws)

<s​gp_:monero.social> lws support is certainly interesting, though my recommendation is to not focus on that as an immediate priority for BTCPay Server. Later, it would be nice to support multiple wallets with one server in a more elegant way than running multiple monero-wallet-rpc instances

<s​gp_:monero.social> I asked for MAGIC Grants to maintain the repo, since we already use BTCPay Server, we like the project, and we at least have the resources already to maintain it. Plus, we could support fundraising efforts (either directly through us or initiated through the CCS, and working with those proposal submitters) to add more features to the repo github.com/btcpayserver/btcpayserv<clipped message>

<s​gp_:monero.social> er/pull/6535#issuecomment-2585846522

<s​gp_:monero.social> Siren (comfy): we're happy to support MoneroPay and Metronero as well, if that makes sense for you. As much as I like BTCPay Server, there is definitely value on building a tool where Monero is a first-class citizen rather than a plugin, and one where the architecture is much simpler

<s​gp_:monero.social> one of our other goals is to bring a Monero app (monerod, monero-onion-explorer, lws, ...) to TrueNAS Scale as well

<s​gp_:monero.social> Scale recently changed apps from Kubernetes to Docker so the integration should be much simpler

<s​iren:kernal.eu> We will submit a proposal for Metronero and MoneroPay later this month or early February.

<o​frnxmr:xmr.mx> What do you think abt using multiple wallet rpc in the interim? Should be much easier to implement

<o​frnxmr:xmr.mx> Solves the issue multiple wallets, and has minimal impact on resources but adds wallet security

<o​frnxmr:xmr.mx> I imagine its not an overall "difficult" task to add a new walletrpc that binds to an incremental port associated with the store

<s​gp_:monero.social> that approach is my preferred option in this exact moment, through it's possible that the implementation would be too messy to be useful. It's not really about the resource consumption so much as it is an exercise of reliably using Docker in a production environment for an arbitrary number of those running instances

<s​gp_:monero.social> that will take some tinkering to figure out

<s​gp_:monero.social> on a related note, getting a review of this would be nice so that the subaddress lookahead can be set by RPC command monero-project/monero #8981

<o​frnxmr:xmr.mx> i thought it couldnt be changed after wallet creation, nice if it can be implemented

<v​tnerd:monero.social> I’ve been working on a frontend C++ api for LWS that is very similar to the wallet_api in monerod. Hopefully that will help? Its still not really a wallet solution

<s​gp_:monero.social> my suggestion is to keep things simple and just support it as an RPC option for creation/restore: monero-project/monero #8954#issuecomment-2394093863

<v​tnerd:monero.social> multiple people are now using LWS as an alerter system basically, with a wallet by the end user elsewhere

<v​tnerd:monero.social> *alert

<s​gp_:monero.social> Hmm, that might be sufficient for view-only BTCPay server setups then if I'm understanding correctly?

<s​gp_:monero.social> Supporting view-only (cold wallet) might be a good way to narrow the initial scope

<o​frnxmr:xmr.mx> i think its expected that btcpay is view-only (even with rpc)

<o​frnxmr:xmr.mx> This was what i thought. That it could only be set at creation restore (but that wallet-rpc didnt have a param for it. Had to use cli)

<o​frnxmr:xmr.mx> But if it can be set post-creation, even better.

<o​frnxmr:xmr.mx> How does subaddr lookahead work with lws though?

<s​gp_:monero.social> ideally btcpay server could support hot wallets as well like it does with bitcoin, but I don't think I've ever used it that way. I don't know if any sending for Monero is currently supported

<v​tnerd:monero.social> LWS has to be run with subaddresses enabled. Then there’s an API call to request subaddress index creation

<o​frnxmr:xmr.mx> > using set to interactively manage it after wallet creation/restored doesnt have any effect. It also errors if you try to use --wallet-file along with the runtime flag.

<o​frnxmr:xmr.mx> > option a) adding the rpc param to existing create and restore rpc endpoints would bring feature parity to cli.

<o​frnxmr:xmr.mx> > option b) adding a new rpc endpoint that can modify an existing wallet and enabling interactive modification for existing wallets via cli

<o​frnxmr:xmr.mx> > i'm not sure if b) is non-existent due to technical limitation, but as stated earlier, it intentionally throws errors if trying to use subaddress-lookahead flag when specifying am existing wallet.

<o​frnxmr:xmr.mx> But what about lookahead :P

<o​frnxmr:xmr.mx> Problem that merchants have is people (sometimes intentionally) spamming unpaid invoices

<v​tnerd:monero.social> the lookahead is handled by the client (via api)

<o​frnxmr:xmr.mx> Does that mean the client will request new subaddresses "manually"

clients always have to do that anyway. They have to generate the subaddress themselves.

so clients can easily keep track of things they’ve requested or they can just tell the server I want to scan this range right when they boot up

it wouldn’t be tough to add some sort of lookahead flag to the LWS though

maybe just more annoying to clutter the logic

<o​frnxmr:xmr.mx> rpc / cli / wallet2_api all do it "automatically" to stay N subddresses ahead of the last input

some clients require an upsert for example though so lookaheads are not always the solution

A lookahead can become very inefficient in some circumstances

and wasteful

<o​frnxmr:xmr.mx> How?

<o​frnxmr:xmr.mx> 🤯 nvm this is a non-issue

<o​frnxmr:xmr.mx> The backend doesnt need lookaheads, the spend wallet does

<o​frnxmr:xmr.mx> If someone spams 500 fake invoices, the backend will still see the next real one. Its my disconnected spend wallet that wont see it

<s​gp_:monero.social> Correct

<o​frnxmr:xmr.mx> ^ 📢 vik (Cake)

<3​21bob321:monero.social> Not sith lord ?

<o​frnxmr:xmr.mx> Sith left chat

<s​yntheticbird:monero.social> sithposting

<h​ill-zilla:matrix.org> Hi

<s​yntheticbird:monero.social> Hi