04:55:58 <3​21bob321:monero.social> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/538 04:55:59 <3​21bob321:monero.social> am i blind and cant see the cost ? 05:31:33 Clicking on 'changes' will show the funding breakdown . "amount" is the total with the milestones below. 273 XMR 05:34:11 <3​21bob321:monero.social> also seems like they will ask for more money later ? 05:34:56 <3​21bob321:monero.social> other question is will they maintain it after this 08:45:23 not sure what makes you think that.. there is definitely a space for another ccs tho.. 08:49:15 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. 09:33:33 Isnt btcpayserver already creating the plugin 09:42:52 Q2.How many bounties have you opened or claimed, to make the assumption that bounties arent effective? 09:55:14 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' 09:55:15 s a comment for context: https://github.com/btcpayserver/btcpayserver/pull/6239#issuecomment-2373616306. 09:55:17 ..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. 09:55:19 This work should also help prepare for multi-wallet support and make things more flexible down the road..... 09:55:51 check the CCS.. i did not open any 09:57:39 So how can you say its not effective? 09:57:41 the ccs says it wants to be assigned so some active bounties 10:01:08 cuz btcpayserver guys r fixing our shit 10:01:40 and they r tired of it 10:02:31 👀 10:03:17 https://github.com/btcpayserver/btcpayserver/pull/6239#issuecomment-2481847461 this comment is accurate afaict. Pr seems broken anyway? 10:04:24 and why should i continue to fix it.. once the code base have completely shifted..... 10:04:54 It runs 1 wallet, which means 1 daemon 10:06:17 Your ccs claims to add lws, which invalidates the pr in entirety and disqualifies the bounties 🤔 10:07:14 Even your prior or is fundamentally broken, cuz cake node would need to have tx-notify enabled 10:08:21 The warning doesn't make sense either, cuz if you had access to setup tx/block-notify, you can obviously trust the node 10:11:59 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 10:31:02 I emailed kukks and he said monero plugin will be in version 2.1 10:33:08 https://github.com/btcpayserver/btcpayserver-monero-plugin 15:04:38 Welcome napoly. Tap on ofrn profile and hit `Block contact`. 15:04:56 👍️😎 15:06:35 Good luck blocking me from irc. Why'd u leave on matrix? 15:09:40 /ignore -regexp -pattern ofrnxmr * 15:10:13 Lmk how it goes 15:30:12 "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." 15:30:40 And yet once again, ignoring ofrn would improve your Monero community experience! 15:33:43 Did i say anything about multiwallets etc? No, shithead 15:34:25 the proposal calls for including lws ya fkn noob. Clearly that would allow multiwallets 15:35:40 My point was that the plugin is already started by nicholas, and there is no mention of such in the proposal. 15:38:41 And this is the type of verbal diarrhea all the channels this tool subjects to. 15:38:47 Beautiful. 15:39:43 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) 15:40:24 So thx for your half-a-cent of insight, but next time, try to know what youre talking about 15:40:55 The best part is that he never shuts the fuck up! 15:41:24 And stop projecting onto me. You ragequit matrix and irc because you arent allowed to tell ppl to kill themselves on a daily basis. 15:41:34 See? Keeps going! 15:41:38 username checks out? 15:41:56 syntheticbird meooooooooooowwwwwwwwwwwwwwwwwww. 15:42:00 purrrrrrrrrrrrrrrrrrrrrrrrrr. 15:42:04 PUUUURRRRRRRRRrrrrrr 15:42:48 didn't know dukenukem was rotten 15:43:00 thats a plot twist 15:43:13 its one of his like 26 accounts 15:43:14 what kind of world do you live in, kitty kat. 16:17:04 So the plugin is already developed and this CCS isn't necessary? 16:18:03 lol. 16:18:42 The ccs has additions, but correct. There is a plugin 16:18:48 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 ? 16:18:57 ah ok alright 16:19:57 So it would make sense to make the CCS about maintaining and adding to the existing plugin then? 16:20:06 "After the release of version 2.1, the btcpayserver-monero-plugin repository will be transferred to someone trusted within your community." 16:20:10 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 16:20:13 Remote node and multi-wallet support. 16:20:16 Yes 16:20:37 Since they are looking for a community member to transfer ownership to. 16:20:58 Lws included multiwallet, remote node not feasible with lws 16:21:12 Lws requires zmq ports (both) exposed 16:21:25 Can be either/or though. 16:21:54 Choose local daemon + LWS or use remote node. 16:22:12 maintaining an rpc instance and an lws instance sounds like wrong approach. But lws only comes with another issue: no wallet support 16:22:52 So every btcpayserver merchant will have to use mymonero's broken wallet? Lol 🤷‍♂️ 16:22:55 Why does BTCPayServer need LWS support? Isn't that better for spending rather than receiving? 16:23:09 It just needs to be online and synced. 16:23:33 Lws just makes it easy to create multiple "view" wallets on the server 16:24:03 But it makes it harder for merchants to use those wallets, bcuz it requires the lws server be online to use the wallet 16:24:17 But then requires a local daemon on the BTCPay server. 16:24:19 btcpayserver (and lws) down? Rip wallet 16:24:29 restore seed somewhere else 16:24:45 the monero-lws is presumably for providing btcpayserver to multiple third parties? napoly whats the reason for it? 16:24:53 Mymonero seed? 13 words? Rip 16:25:12 we may have to fund someone to come up with a fee model in that case! 16:25:57 Imo the proposal is premature (shouldnt be made before plugin is passed off from by pay server to "us") and not well thought out 16:27:39 Having multiple wallets using rpc is possible. Just need multiple rpc instances. 16:27:41 remote nodes with rpc require block-notify, unless the core code is changed to watch for blocks 16:36:23 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 16:43:10 for more context here is a request for hosting for third parties https://github.com/btcpayserver/btcpayserver/issues/1505 16:45:30 similar to how you can host monero payment processors for your friends with bitcart https://docs.bitcart.ai/deployment/thirdpartyhosting 16:49:01 my landlord talking bout something, sponsored by xmr!D 16:49:17 https://www.youtube.com/watch?v=aP_gi9Fu6Io 16:54:10 Right. Using rpc the only way would be to run multiple instances of wallet-rpc 16:57:03 Each instance of wallet-rpc uses a bunch of RAM. Not good for a small VPS. 16:58:16 Let me see how much ram my rpc is using 16:59:39 2GB (during wallet sync). bitcart (and acceptxmr) dont have this limitation as they use monero rust libraries (or similar) 17:00:01 2gb is so 2024 17:01:07 Also next release fixes broken initial sync where it (fast) syncs from genesis bcuz it doest know the cirrent block 17:04:30 Looks like 50mb for rpc right now 17:04:47 44000kb is res 17:15:24 So for an instance running multiple wallet-rpc's it would be ~50mb/instance under normal weather 17:15:54 vtnerd we dont need monero-lws anymore^ 17:16:47 vtnerd gonna have a heart attack reading this. 17:16:49 (jokes, we need wallets that use it!) but is this new lower memory usage/performance true? 17:16:54 he spent so much effort into it 17:17:30 vik (Cake): We need Remote Wallet functionnality (aka LWS) into Cake Wallet 17:17:33 Pretty please 17:17:43 with background sync - there is a hackish way to download the wallet files and have a monero-lws experience but , its a hack 17:18:38 due to the wonders of jbermans work 17:21:01 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 17:22:14 Background sync seems more like a cli feature. Rpc can open a view wallet and maintain its sync with minimal resources 17:24:26 Still, the problem here is if you use the btcpayservers LWS, you require a the LWS server (btcpay) to remain online 17:24:30 Otherwise you have to share tour view key with multiple lws servers (is that even supported? Switching servers?) 17:25:14 ofrnxmr as always you find a problem that is one because it goes beyond the scope of the original thing. 17:25:27 Of course LWS needs to stay online, it's a Server remember 17:25:31 Light Wallet Server 17:26:08 does kewbit know c#? 17:26:14 🔭 17:26:15 🔬 17:26:17 No inbetween! 17:26:19 asking for a friend 17:26:26 Claude do so kewbit might 17:26:57 This is my point tho 17:27:35 Having a wallet for lws would mostly be beneficial for creating the wallet on the server automagically 17:28:54 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 17:29:44 (hot wallet = full wallet. Btcpay = view = lws) 17:47:53 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 17:49:09 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 https://github.com/btcpayserver/btcpayserv 17:49:09 er/pull/6535#issuecomment-2585846522 17:52:38 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 17:54:10 one of our other goals is to bring a Monero app (monerod, monero-onion-explorer, lws, ...) to TrueNAS Scale as well 17:54:43 Scale recently changed apps from Kubernetes to Docker so the integration should be much simpler 18:02:59 We will submit a proposal for Metronero and MoneroPay later this month or early February. 18:21:02 What do you think abt using multiple wallet rpc in the interim? Should be much easier to implement 18:23:28 Solves the issue multiple wallets, and has minimal impact on resources but adds wallet security 18:24:03 I imagine its not an overall "difficult" task to add a new walletrpc that binds to an incremental port associated with the store 18:24:07 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 18:25:15 that will take some tinkering to figure out 18:28:05 on a related note, getting a review of this would be nice so that the subaddress lookahead can be set by RPC command https://github.com/monero-project/monero/pull/8981 18:31:14 i thought it couldnt be changed after wallet creation, nice if it can be implemented 18:32:48 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 18:32:55 my suggestion is to keep things simple and just support it as an RPC option for creation/restore: https://github.com/monero-project/monero/issues/8954#issuecomment-2394093863 18:33:07 multiple people are now using LWS as an alerter system basically, with a wallet by the end user elsewhere 18:33:14 *alert 18:34:01 Hmm, that might be sufficient for view-only BTCPay server setups then if I'm understanding correctly? 18:34:43 Supporting view-only (cold wallet) might be a good way to narrow the initial scope 18:41:31 i think its expected that btcpay is view-only (even with rpc) 18:42:40 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) 18:43:01 But if it can be set post-creation, even better. 18:43:47 How does subaddr lookahead work with lws though? 18:44:09 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 18:45:53 LWS has to be run with subaddresses enabled. Then there’s an API call to request subaddress index creation 18:45:59 > 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. 18:47:10 > option a) adding the rpc param to existing create and restore rpc endpoints would bring feature parity to cli. 18:47:11 > option b) adding a new rpc endpoint that can modify an existing wallet and enabling interactive modification for existing wallets via cli 18:47:13 > 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. 18:48:47 But what about lookahead :P 18:48:47 Problem that merchants have is people (sometimes intentionally) spamming unpaid invoices 18:49:34 the lookahead is handled by the client (via api) 18:54:10 Does that mean the client will request new subaddresses "manually" 18:54:33 clients always have to do that anyway. They have to generate the subaddress themselves. 18:54:58 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 18:55:27 it wouldn’t be tough to add some sort of lookahead flag to the LWS though 18:55:35 maybe just more annoying to clutter the logic 18:55:41 rpc / cli / wallet2_api all do it "automatically" to stay N subddresses ahead of the last input 18:55:51 some clients require an upsert for example though so lookaheads are not always the solution 18:57:08 A lookahead can become very inefficient in some circumstances 18:57:19 and wasteful 18:59:01 How? 18:59:53 🤯 nvm this is a non-issue 19:00:04 The backend doesnt need lookaheads, the spend wallet does 19:01:34 If someone spams 500 fake invoices, the backend will still see the next real one. Its my disconnected spend wallet that wont see it 19:08:40 Correct 19:16:56 ^ 📢 vik (Cake) 19:34:56 <3​21bob321:monero.social> Not sith lord ? 19:35:59 Sith left chat 19:37:27 sithposting 21:14:57 Hi 21:15:52 Hi