Hello Team! If I want to offer an integration with a hardware wallet, do I just file an issue within a github repo?

A PR on github is probably best.

What do you mean with "offer"? Did you program it already? Or do you plan to offer to program it?

Is it "merged" with trezor or ledger, or is it a third appendage ?

Oh. I was assuming it was done, from the wording :D

<rbrunner> "What do you mean with "offer..." <- Just to offer, that's it. I don't have any plan. Moreover, I'm not related to the team of that wallet. I contacted their execs and asked about possible support of Monero, and this is the reply I got: "If monero or anyother blockchain team is interested, they can use our open source code and integrate. We may complete our integration but at the moment its not priority."

<moneromoooo> "Is it "merged" with trezor or..." <- The wallet is OPOLO. This is not an ad, JIC :)

Bought it a year ago during a kickstarter campaign, they claimed superior security, etc. After a year still there is no support for XMR - most private and secure crypto.

So... it's "I offer you the right to work to do this" ? :D Well, in that case I guess you can file an issue and hope someone who wants that does the work. But (assuming this is an unknown wallet) it's unlikely to get merged unless it's not a large amount of code. And ledger/trezor were large amounts of code already.

It seems the OPOLO people dumped some Trezor code without proper attribution into the GitHub repository for coin integration 2 years ago

And after a quick first glance their coin integration framework looks about a magnitude too primitive to include Monero

From their homepage: "THE HARDWARE WALLET OF THE DECADE". It's capitalized, it must be true :)

moneromoooo: any idea here? monero-project/monero #8685#issuecomment-1367590480

they only have this issue when self compiling so it has to be some dependency issue

Not really, but it's odd to see locking take so much, so my wild guess is that this lambda might be called repeatedly with it earlying out fast, assuming that trace is representative.

So it might be a boost bug in strand, but I don't know the first thing about this code, or a monero bug which causes this to be busy called.

I see on_interrupted is called from start_shutdown, which can call it back async.

vtnerd: you'd know about this code I think ?

I also see high cpu usage on monerod, running a local testnet after a bunch of tests

woodser[m]1: self compiled?

yes

which OS are you using?