> <@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 (:

>

> Who is their primary competitor?

bitcartcc

<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?

.merges

selsta, you program?

I need a programming that's willing to do the community a favor.

Should be a quick fix.

If you are asking for btcpayserver, I took a look at it but didn't spend much time on it yet

yes

the issue with confirmation?

yes

ok

are you seth?

nope

should just be able to add a line here: github.com/btcpayserver/btcpayserve…yments/MoneroLikePaymentData.cs#L36

I think... but I am no programmer.

will try to make a patch for it

<3

even just that it fails

because there is a major risk there for digital goods

I confirmed in a non-malicious way that it's vulnerable.

Mochi101: Which risk is there btw? Don't want to make the same mistake when implementing

mrnaif, it'll be patched soon

check unlock_time to make sure the funds aren't locked

hehehe

selsta, jfc

yeah

Mochi101: I remember you bringing this up 2 years or so

yeap

2019

we updated the dev docs now to make it clearer deploy-preview-2083--barolo-time-75…es/developer-guides/wallet-rpc.html

May or so...

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.

well in 2 years you can go through merchants and exchanges again, i'm sure lots will still have it unfixed lol

oh is there chatter?

<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

> <@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 <libera.ems.host/_matrix/media/v3/do…87ae4818e922eb15c3e03d8d38e54420d45>)

mrnaif, what are you building?

adding monero support to my payment processor as I've told yesterday

ok... getmonero.org/resources/moneropedia/account.html

Why don't you go this route?

specifically Multiple Accounts

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

Well, you're trying to shoehorn things after the fact then.

An initial review was done on monero-project/monero #8515 and addressed/replied. What is the proper way to make progress on it? Ask for another reviewer?

Start with the idea that you'll use Monero with multiple accounts... it's very effective.

lol jozsef[m]

jozsef[m], just because you put in a PR doesn't mean it'll get looked at or done.

It did.

and I did not expect it to "get magically done", that's why I'm asking what's a good next step.

ok

Mochi101: Does it automatically track which subaddress is used and which is not? To use a fresh subaddress for each invoice?

Let's say I restore a wallet on a different server, how would it know which subaddress to create without full wallet sync?

mrnaif, they're deterministic

so if you creat 100 with a wallet locally... and you create 100 with the same wallet remotely... they will be the same

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

it has a look ahead feature

I forget how far

Could you send me the link to the docs describing that? I never saw this before

not much documentation on it

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?

number to scan

I recall someone mentioning there is very little overhead in bumping that up to a very large number.

but don't take me on that 100%

What's the default value for lookahead? How much does it find by default?

no idea really

you could look at the code for that

or try to be nice and ask someone more knowledgeable than me

and patient

Okay, thanks. One more idea to try

mrnaif: "Is lookahead a number of sequential addresses without txes (gap limit)" <-- this

by default the lookahead is 50 accounts and 200 addresses

Oh nice, even better, thanks! I guess it's available in wallet2 API too, right?

yes

virtual void setSubaddressLookahead(uint32_t major, uint32_t minor) = 0;

my bad... I remember that now... the without tx part

My RAM is becoming corrupted

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

`grep -r __imp_WSAStartup`, `libwallet_api.a` has it. I wrote up the setup and situation in [this gist](gist.github.com/sneurlax/22e9b3b4686333b9dca360fe71fb39b5) with [error log here](gist.github.com/sneurlax/20a8f82757d61b939374162b41c15e0e) and would appreciate any tips or guidance

That rings a bell, I think it's some Windows system lib that you'd need to link in.

I'd search the web for that name, and see what lib it says it's in.

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

matches`). It could definitely be a missing library or header still and I'll keep looking into that, thanks

$ objdump -t build/prefix_x86_64/lib/monero/libwallet_api.a

...

[2422](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 __imp_WSAStartup

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?

The libs have to be after the user on the link line.

jozsef[m]: I don't think so, though it is fairly easy to add I think.

And passing a pubkey will not work. You do different ops on either.

OK sorry I don't understand

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.

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

In other words, if you link against -lfoo -lbar, foo contains x, bar contains y, y uses x, it will fail.

Because it did not know x was used when it parsed libfoo.

Assuming something else uses y from your program, recursively.

I do not know if the import (link ?) order is wrong since I have no idea what you did.

But even if I knew, I do not know what is where in Windows, so that would not help.

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

I'm just saying link order is a common issue.

Okay, thanks moo. I am thinking this overload might be okay:... (full message at <libera.ems.host/_matrix/media/v3/do…5d4519a4d71391429c1f40315a2f5d47dbe>)

Okay, maybe not. I need to think about it more.

> <@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 <libera.ems.host/_matrix/media/v3/do…4185e385dcca6ba383556c0bae4122dee10>)

For my TechWallet, I use 3 monero-wallet-rpc instances and do some primitive round-robbing, with opening and closing of wallets if needed

Uses a few dozen lines of C# code and seems to work already pretty well. Certainly not an absolute roadblock.

And for the often-heard argument "But with 1000 simultanious users ..." - alright, let's talk again when you have them :)

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."

The latter. Like many, many things in Monero :)

I would suspect many other coins aren't even as far as that, with single-wallet-at-a-time RPC server.

Maybe. But other coins can just look up payment receipts on the blockchain database. Can't do that with Monero.

thank god

<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?