03:47:43 <selsta> .merge+ 8618
03:47:43 <xmr-pr> Added
03:49:27 <kayabaNerve> I'm trying to work with digest_auth and monerod which is... as painful as can be expected. I have old code doing it against monero-wallet-rpc, and it works, except it never set a body in the DigestAuth. I have no idea why/how, I just know it is what it is. I'm currently just trying a basic get_height call, which doesn't have a body anyways, and I'm getting 401 Unauthorized no matter what I do. Is there some quirk of epee I should be on the 
03:49:27 <kayabaNerve> lookout for? Does monerod use it differently than monero-wallet-rpc?
03:51:04 <kayabaNerve> `--rpc-login user:pass` on monerod, my code is using "user" and "pass".
03:52:50 <kayabaNerve> I know the lib is valid since I've used it ~2y ago successfully (and yes, this is the same version). "/get_height" for the method, which is slash prefixed...
04:07:40 <kayabaNerve> Turns out I used a different socket and that turns the nonce stale :/ That'd do it.
13:15:54 <freemint> Is it possible to only search the parts of the parameter space during mining whose random programs don't contain AES or other CRYPTO accelerator dependend instructions?
13:19:04 <sech1> They all do
13:46:07 <freemint> I found nothing which suggests that randomx always passes build random programms which have instruction Y or Z inside. Can you point me to a reference?
13:46:59 <sech1> AES is not a part of random programs, it's calculated at the beginning and the end of every RandomX hash
13:47:56 <sech1> regardless of this, what you're actually asking about is explained here: https://github.com/tevador/RandomX/blob/master/doc/design.md#12-the-easy-program-problem
13:48:03 <sech1> no way around it, sorry
13:55:08 <freemint> Ah i thought the custom functions listed here: https://github.com/tevador/RandomX/blob/master/doc/design.md#3-custom-functions where primitive operations of the VM not pre/post processing.
14:02:51 <freemint> So there is on purpose no means to speed up monero mining by vectorizing the emulator, as there you can SIMD the two random programs as they are expected to be totally distinct?
14:03:35 <freemint> *as you can't SIMD any two random programs
14:04:21 <hyc> correct, all programs are distinct
14:11:01 <freemint> understood that settles all my questions and i will not consider porting Monero to https://en.wikipedia.org/wiki/NEC_SX-Aurora_TSUBASA . Someone asked me whether that card could mine Monero when i talked about it. Now i can tell them it will perform like 2 Raspberry Pi 4s.
14:17:56 <freemint> ... Wait how do GPU miners work then with total Warp divergence those random programs would have?
14:21:15 <hyc> poorly
14:22:11 <freemint> So they are basically forced to execure one thread per warp?
14:24:03 <freemint> Or is there something else that can be done that i am missing.
14:36:05 <DataHoarder> they use CPUs
14:46:55 <sech1> freemint GPU implementation executes up to 8 threads per warp, but there's a whole stage of preprocessing VM instructions and reordering, to find instructions that can run in the same warp
14:47:50 <sech1> https://github.com/SChernykh/RandomX_CUDA/blob/master/RandomX_CUDA/randomx_cuda.hpp
14:47:59 <sech1> check init_vm and inner_loop functions
14:49:44 <freemint> sech1, Thanks.
14:50:01 <sech1> for example, it merges FADD_R, FADD_M, FSUB_R, FSUB_M, FMUL_R into a single FMA instruction on GPU, so it can run in parallel
14:50:18 <sech1> I mean, they're all implemented via FMA instruction with different arguments
14:50:38 <sech1> it's still very slow and inefficient compared to CPU
14:50:53 <freemint> Good God. this gonna be brutal for the any NEC SX Aurora TSUBASA implementation.
14:51:19 <freemint> yeah, nope, nope, nope. That's not gonna work at all.
14:53:25 <freemint> This card is working on 256 words of 8 bytes. So 16384 bits per instruction.
14:54:18 <freemint> Thanks for the letting me deepen my understanding of Monero and enteraining my musings.
14:56:23 <freemint> And i really appreciate the design of Monero and RandomX. Good work!
16:07:42 <woodser[m]> we're trying to restore an old multisig wallet with 0.18.1.2 software. loading it, the wallet says "Some owned outputs have partial key images - import_multisig_info needed". typing `export_multisig_info my_multisig_info` shows the error "Error: This multisig wallet is not yet finalized". are old multisig wallets compatible with the new software, or is there some extra steps to restore?
16:09:12 <UkoeHB> woodser[m]: https://github.com/monero-project/monero/pull/8329#issuecomment-1216946632
16:09:38 <woodser[m]> yes just found my way too it, thanks :)
16:32:39 <woodser[m]> UkoeHB: I tried with `export_multisig_info force-update-use-with-caution woodser_multisig_info` but we're still getting "Error: This multisig wallet is not yet finalized". am I issuing the command correctly?
16:56:29 <UkoeHB> woodser[m]: did you then import that info?
16:58:00 <UkoeHB> err and the command is exchange_multisig_keys, no?
17:53:40 <woodser[m]> the error occurs before being able to import
17:54:26 <UkoeHB> Sorry I didn’t mean import
17:54:39 <woodser[m]> ah yes, it produces a different error with ` exchange_multisig_keys force-update-use-with-caution woodser_multisig_info`: Error: Failed to perform multisig keys exchange: Multisig kex msg decoding error.
17:55:23 <UkoeHB> Is that with simplewallet or MMS?
17:55:46 <woodser[m]> actually I have it working now with only `exchange_multisig_keys force-update-use-with-caution`
17:55:49 <woodser[m]> this is the cli
17:56:04 <woodser[m]> splendid, I think we're good to go now :) thank you
17:57:20 <UkoeHB> Hmm well glad it worked (should need two commands though, not sure why that’s would work)
17:58:18 <woodser[m]> it's prompting to share multisig hex with peers and use `exchange_multisig_keys force-update-use-with-caution` with their hex
19:11:38 <mrnaif> Hi! What is more recommended to be used for a payment processor in monero nowadays: integrated addresses or subaddresses? Initially I thought integrated addresses are the way to go, but I found out subaddresses do exist too.
19:12:05 <moneromoooo> Subaddresses.
19:29:08 <cryptogrampy[m]> <mrnaif[m]> "Hi! What is more recommended..." <- Hi Mrnaif- integrated addresses are currently slated for deprecation, but they have a couple unique characteristics that can't be achieved with subaddresses today (at least that I know of).  Some good discussion here: https://github.com/monero-project/monero/issues/7889
19:31:04 <mrnaif> Yep, I've just read it. The main downside of subaddresses right now is that I would need to write an electrum analogue in monero where it would scan the blockchain up to some gap limit and discover addresses possibly. From that github issue it looks like consensus hasn't been reached yet? It is very convenient to just generate a random id and tie it to address merchants input.
19:32:34 <moneromoooo> monero automatically does this lookahead for you.
19:33:07 <mrnaif> How exactly? Is it in wallet-rpc?
19:33:56 <moneromoooo> By... er... just doing it. It's in monero-wallet-rpc by virtue of being in wallet2, which monero-wallet-rpc is based on.
19:34:57 <moneromoooo> I might have missed your point since I don't know what you mean by "an electrum analogue" though.
19:35:01 <mrnaif> I mean that I can't use wallet-rpc, I am able to use only the daemon RPC commands because I want to allow multiple different wallets processing payments at once
19:35:33 <moneromoooo> So... you reimplement monero-wallet-rpc, essentially ?
19:36:16 <mrnaif> moneromoooo: It can work with only one wallet at a time, which is not possible in context of a mass-scale payment processor that can work for many merchants/stores/etc on one instance
19:37:16 <mrnaif> moneromoooo: Electrum is a lightweight bitcoin wallet, they use something similar to subaddresses, and they scan the blockchain up to the gap limit (which means, if there are 20 addresses with 0 transactions, 21 one with transactions won't be found by default)
19:37:45 <moneromoooo> Right. That's the bit wallet2 also does.
19:38:14 <mrnaif> Sorry, I am a bit new to monero, I don't know what wallet2 is (:
19:38:15 <endogenic> mrnaif: use the lightwallet server
19:38:33 <endogenic> http://github.com/vtnerd/monero-lws
19:38:45 <endogenic> i built a client for it too about 6-7 yrs ago
19:38:53 <endogenic> i'm working on a better one now
19:38:54 <moneromoooo> wallet2 is the code that's shared between monero-wallet-cli, monero-wallet-rpc, monero-wallet-gui. The "engine" really.
19:38:58 <endogenic> it'll be out soon
20:26:01 <woodser[m]> trying to build the old v0.18.1.0 release (727bc) on linux, we're hitting errors like:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/22d4366dd35e490c327152c49462212aeb5891ce>)
20:34:23 <selsta> does anyone know about podman https://github.com/monero-project/monero/issues/8639 ?
20:34:27 <selsta> do we support this?
20:43:01 <moneromoooo> If it helps, Townforge builds with podman as a submodule of Feather wallet.
20:43:13 <moneromoooo> With monero... close to latest release.
20:56:56 <selsta> I just have to figure out what podman is exactly
20:57:26 <moneromoooo> It's a mostly compatible alternative to docker that doesn't require a deamon.
20:57:37 <moneromoooo> And is generally not a fucking pain in the arse.
20:59:20 <moneromoooo> (mostly compatible meaning, you just replace "docker" with "podman" in command lines and it'll generally work, without the pain in the arse part)
20:59:35 <selsta> oh so it uses dockerfiles?
20:59:38 <selsta> as input?
20:59:39 <moneromoooo> Yes.
20:59:43 <selsta> ok then it makes sense