04:05:34 <mrnaif> > <@eynno[m]:libera.chat> > <@mrnaif[m]:libera.chat> I don't. I am creating my own solution, basically adding monero support to the main btcpay's competitor in opensource space (:
04:05:34 <mrnaif> > 
04:05:34 <mrnaif> > Who is their primary competitor? 
04:05:34 <mrnaif> bitcartcc
04:06:22 <mrnaif> <endogenic> "mrnaif Mochi101 you could just..." <- I've written 4 possible ways on how to implement sending transactions. Which one makes more sense, what do you think? Also, do you mean the moneroexamples/openmonero backend?
04:09:21 <selsta> .merges
04:09:21 -xmr-pr- 8572 8575 8602 8603 8604 8610 8611 8615 8616 8618 8627 8628 8635 8636 8642
04:11:16 <Mochi101> selsta, you program?
04:11:46 <Mochi101> I need a programming that's willing to do the community a favor.
04:12:03 <Mochi101> Should be a quick fix.
04:12:03 <selsta> If you are asking for btcpayserver, I took a look at it but didn't spend much time on it yet
04:12:12 <Mochi101> yes
04:12:30 <Mochi101> the issue with confirmation?
04:12:32 <selsta> yes
04:12:36 <Mochi101> ok
04:13:13 <Mochi101> are you seth?
04:13:39 <selsta> nope
04:14:08 <Mochi101> should just be able to add a line here: https://github.com/btcpayserver/btcpayserver/blob/bbe1442c284f32a133aafb548756b403a144013e/BTCPayServer/Services/Altcoins/Monero/Payments/MoneroLikePaymentData.cs#L36
04:14:29 <Mochi101> I think... but I am no programmer.
04:14:39 <selsta> will try to make a patch for it
04:14:44 <Mochi101> <3
04:14:54 <Mochi101> even just that it fails
04:15:07 <Mochi101> because there is a major risk there for digital goods
04:15:44 <Mochi101> I confirmed in a non-malicious way that it's vulnerable.
04:15:55 <mrnaif> Mochi101: Which risk is there btw? Don't want to make the same mistake when implementing
04:16:28 <Mochi101> mrnaif, it'll be patched soon
04:16:28 <selsta> check unlock_time to make sure the funds aren't locked
04:16:35 <Mochi101> hehehe
04:16:39 <Mochi101> selsta, jfc
04:16:47 <selsta> https://github.com/monero-project/monero/#blockchain-based
04:17:10 <Mochi101> yeah
04:19:27 <selsta> Mochi101: I remember you bringing this up 2 years or so
04:20:49 <Mochi101> yeap
04:20:55 <Mochi101> 2019
04:21:19 <selsta> we updated the dev docs now to make it clearer https://deploy-preview-2083--barolo-time-757cf9.netlify.app/resources/developer-guides/wallet-rpc.html
04:21:25 <Mochi101> May or so...
04:22:12 <Mochi101> selsta, the problem is the way people "program" these days... they throw a whole bunch of libraries together and call it a day and don't try to understand the tools.
04:26:36 <selsta> well in 2 years you can go through merchants and exchanges again, i'm sure lots will still have it unfixed lol
04:29:05 <Mochi101> oh is there chatter?
13:10:11 <woodser[m]> <mrnaif[m]> "Well no, they use wallet-rpc..." <- you can create unlimited client-side wallets which use one daemon to create, sign, and publish txs using monero-javascript too, unless I'm missing one of your requirements
14:32:54 <mrnaif> > <@woodser[m]:libera.chat> > <@mrnaif[m]:libera.chat> Well no, they use wallet-rpc, which limits them to only one wallet per server. That's why I want it to work with only daemon RPC connection and nothing else, removing the limitation... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/e2aba87ae4818e922eb15c3e03d8d38e54420d45>)
14:33:59 <Mochi101> mrnaif, what are you building?
14:34:57 <mrnaif> adding monero support to my payment processor as I've told yesterday 
14:35:19 <Mochi101> ok... https://www.getmonero.org/resources/moneropedia/account.html
14:35:27 <Mochi101> Why don't you go this route?
14:36:13 <Mochi101> specifically Multiple Accounts
14:36:27 <mrnaif> Well, I chose integrated addresses because they suit the invoicing system better and otherwise I would need to sync full wallet state to discover first unused subaddress,  but maybe with wallet2 bindings it might be easier
14:37:05 <Mochi101> Well, you're trying to shoehorn things after the fact then.
14:37:31 <jozsef[m]> An initial review was done on https://github.com/monero-project/monero/pull/8515 and addressed/replied. What is the proper way to make progress on it? Ask for another reviewer?
14:37:37 <Mochi101> Start with the idea that you'll use Monero with multiple accounts... it's very effective.
14:38:05 <Mochi101> lol jozsef[m] 
14:38:31 <Mochi101> jozsef[m], just because you put in a PR doesn't mean it'll get looked at or done. 
14:38:49 <jozsef[m]> It did.
14:39:33 <jozsef[m]> and I did not expect it to "get magically done", that's why I'm asking what's a good next step.
14:39:54 <Mochi101> ok
14:40:06 <mrnaif> Mochi101: Does it automatically track which subaddress is used and which is not? To use a fresh subaddress for each invoice?
14:40:06 <mrnaif> Let's say I restore a wallet on a different server, how would it know which subaddress to create without full wallet sync?
14:40:37 <Mochi101> mrnaif, they're deterministic
14:41:10 <Mochi101> so if you creat 100 with a wallet locally... and you create 100 with the same wallet remotely... they will be the same
14:41:54 <mrnaif> In electrum btc wallet they are also deterministic, but it doesn't remove the need to sync the wallet to discover previously used addresses for example, of course, given main address and index the address is always the same, that's not the question 
14:42:36 <Mochi101> it has a look ahead feature
14:42:47 <Mochi101> I forget how far
14:43:38 <mrnaif> Could you send me the link to the docs describing that? I never saw this before
14:46:17 <Mochi101> not much documentation on it
14:46:18 <Mochi101> https://www.reddit.com/r/Monero/comments/f1tlug/expanding_the_subaddresslookahead_on_an_existing/
14:48:23 <mrnaif> Hm, I see gap limit issue is still present. Will think what's better. Is lookahead a number of sequential addresses without txes (gap limit), or is lookahead just a number of subaddress to scan?
14:48:52 <Mochi101> number to scan 
14:49:58 <Mochi101> I recall someone mentioning there is very little overhead in bumping that up to a very large number.
14:50:22 <Mochi101> but don't take me on that 100%
14:50:42 <mrnaif> What's the default value for lookahead? How much does it find by default?
14:51:14 <Mochi101> no idea really
14:51:21 <Mochi101> you could look at the code for that
14:51:45 <Mochi101> or try to be nice and ask someone more knowledgeable than me
14:52:03 <Mochi101> and patient
14:52:50 <mrnaif> Okay, thanks. One more idea to try
15:01:26 <selsta> mrnaif: "Is lookahead a number of sequential addresses without txes (gap limit)" <-- this
15:02:08 <selsta> by default the lookahead is 50 accounts and 200 addresses
15:02:43 <mrnaif> Oh nice, even better, thanks! I guess it's available in wallet2 API too, right?
15:03:32 <selsta> yes
15:04:06 <selsta> virtual void setSubaddressLookahead(uint32_t major, uint32_t minor) = 0;
15:06:51 <Mochi101> my bad... I remember that now... the without tx part
15:07:08 <Mochi101> My RAM is becoming corrupted
16:18:13 <sneurlax[m]> I'm working on cross-compiling CakeWallet's style of static monero library for windows from linux (ubuntu 20.04) and having issues.  When finally linking the static library, I'm missing references to `__imp_`-prefixed classes in a few libraries (wallet_api, cryptonote_core, net, common, unbound, epee, and crypto from openssl)... So it'll say `undefined reference to __imp_WSAStartup`, for example, in `libwallet_api.a` even though when I
16:18:13 <sneurlax[m]> `grep -r __imp_WSAStartup`, `libwallet_api.a` has it.  I wrote up the setup and situation in [this gist](https://gist.github.com/sneurlax/22e9b3b4686333b9dca360fe71fb39b5) with [error log here](https://gist.github.com/sneurlax/20a8f82757d61b939374162b41c15e0e) and would appreciate any tips or guidance
16:19:44 <moneromoooo> That rings a bell, I think it's some Windows system lib that you'd need to link in.
16:20:39 <moneromoooo> I'd search the web for that name, and see what lib it says it's in.
16:42:36 <sneurlax[m]> Yep, I had that issue and a few more for a similar project which was resolved by also linking crypt32, ws2_32, and wsock32 to the OpenSSL static lib, which I'm doing for the OpenSSL built from source for monero in this setup as well but isn't being found (`libcrypto.a(b_sock.o):b_sock.c:(.text+0xd5): undefined reference to __imp_WSAStartup` but `$grep -r __imp_WSAStartup >> Binary file build/prefix_x86_64/lib/monero/libwallet_api.a
16:42:36 <sneurlax[m]> matches`).  It could definitely be a missing library or header still and I'll keep looking into that, thanks
16:44:58 <sneurlax[m]> $ objdump -t build/prefix_x86_64/lib/monero/libwallet_api.a
16:44:58 <sneurlax[m]> ...
16:44:58 <sneurlax[m]> [2422](sec  0)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_WSAStartup
16:53:05 <jozsef[m]> Can I use wallet2 to encrypt some text with the public spend key (of some other wallet) so only that other wallet can decrypt the text? As I see it, the problem with using `wallet2::encrypt()` for this is that it takes a secret key. What if I just pass the public spend key to it? Will that work?
16:59:12 <moneromoooo> The libs have to be after the user on the link line.
16:59:57 <moneromoooo> jozsef[m]: I don't think so, though it is fairly easy to add I think.
17:00:17 <moneromoooo> And passing a pubkey will not work. You do different ops on either.
17:02:22 <sneurlax[m]> OK sorry I don't understand
17:04:09 <moneromoooo> Most linkers are one pass. Or were, at least. So they read the files in order, keeping a list of unresolved symbols, and resolve them if they're found in the file they're currently reading.
17:04:22 <sneurlax[m]> do you mean the import order is wrong or I should also be including eg user32 or whatever that lib is?  The same import order works to resolve the same issue for the same crypto.a elswhere
17:04:54 <moneromoooo> In other words, if you link against -lfoo -lbar, foo contains x, bar contains y, y uses x, it will fail.
17:05:17 <moneromoooo> Because it did not know x was used when it parsed libfoo.
17:05:40 <moneromoooo> Assuming something else uses y from your program, recursively.
17:06:21 <moneromoooo> I do not know if the import (link ?) order is wrong since I have no idea what you did.
17:06:34 <moneromoooo> But even if I knew, I do not know what is where in Windows, so that would not help.
17:06:38 <sneurlax[m]> OK!  I'll doublecheck that, thanks.  There are a lot more libraries involved here than where that OpenSSL change fixes it elsewhere so that seems very likely
17:06:49 <moneromoooo> I'm just saying link order is a common issue.
17:07:42 <jozsef[m]> Okay, thanks moo. I am thinking this overload might be okay:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/6d7fb5d4519a4d71391429c1f40315a2f5d47dbe>)
17:11:16 <jozsef[m]> Okay, maybe not. I need to think about it more.
18:15:29 <woodser[m]> > <@mrnaif[m]:libera.chat> > <@woodser[m]:libera.chat> > <@mrnaif[m]:libera.chat> Well no, they use wallet-rpc, which limits them to only one wallet per server. That's why I want it to work with only daemon RPC connection and nothing else, removing the limitation... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/2bc114185e385dcca6ba383556c0bae4122dee10>)
19:33:14 <rbrunner> For my TechWallet, I use 3 monero-wallet-rpc instances and do some primitive round-robbing, with opening and closing of wallets if needed
19:33:43 <rbrunner> Uses a few dozen lines of C# code and seems to work already pretty well. Certainly not an absolute roadblock.
19:35:42 <rbrunner> And for the often-heard argument "But with 1000 simultanious users ..." - alright, let's talk again when you have them :)
19:37:43 <Rucknium[m]> Is there a technical reason why monero-wallet-rpc cannot have more than one wallet open at a time? Other than "it's written that way right now."
19:40:46 <rbrunner> The latter. Like many, many things in Monero :)
19:41:28 <rbrunner> I would suspect many other coins aren't even as far as that, with single-wallet-at-a-time RPC server.
19:43:56 <Rucknium[m]> Maybe. But other coins can just look up payment receipts on the blockchain database. Can't do that with Monero.
19:44:28 <Mochi101> thank god
21:52:17 <mrnaif> <rbrunner> "For my TechWallet, I use 3..." <- But each wallet-rpc instance would be blocked until full sync (worst case 2 hours)? Or how do you set the restore height?