11:45:09 <r4v3r23[m]> UkoeHBcan you confirm how cold-signing will work in seraphis? i remember you said somewhere key images won't need to be imported/exported, but will outputs/enotes still need to be? or will it be simplified down to just unsigned tx/signed tx?
12:14:10 <UkoeHB> r4v3r23[m]: yes just unsigned tx / signed tx
12:15:06 <r4v3r23[m]> thanks
12:32:16 <rbrunner> Where do I start my search for the problem if a release build is successful but a debug build fails, while linking as it seems, with some missing symbol
12:32:40 <rbrunner> I try to compile UkoeHB's latest seraphis_lib branch, "make" goes through, "make debug" gives me this error: https://paste.debian.net/1285853/
12:43:29 <moneromoooo> Check the lib with work_while_waiting is linked in after scan_ledger_chunk_async.cpp.
12:43:40 <moneromoooo> If you're unlucky, there's a circular dep.
12:48:52 <rbrunner> What is "work_while_waiting"?
12:50:33 <moneromoooo> I can only guess. I did not work with that code.
12:51:12 <rbrunner> Ah, you reference a symbol in that code. I was taking it as the name of some analysis tool, linker option, or whatever :)
12:51:39 <moneromoooo> Yes, it's the one the error complains about.
12:51:48 <rbrunner> Alright, thanks.
13:13:56 <UkoeHB> rbrunner: nuke you build directory and try again, might fix it
13:14:27 <UkoeHB> this line is quite suspicious src/wallet/CMakeFiles/wallet_rpc_server.dir/wallet_rpc_server.cpp.o
13:15:09 <rbrunner> Well, that's more or less random, I compiled with 4 threads, and that's just what was compiled in one of them before another one had the error
13:15:46 <rbrunner> But good idea anyway, C++ dev's equivalent of "Have you already tried switching it off and on again" :)
13:17:40 <UkoeHB> ah righ
14:16:43 <recanman[m]> Would this regex be correct for a standard monero address? /(?:^[48][0-9AB][1-9A-HJ-NP-Za-km-z]{93}$)/
14:16:47 <recanman[m]>  * Would this regex be correct for a standard monero address? /(?:^\[48\]\[0-9AB\]\[1-9A-HJ-NP-Za-km-z\]{93}$)/
14:16:51 <recanman[m]>  * Would this regex be correct for a standard monero address?
14:16:52 <recanman[m]> `/(?:^\[48\]\[0-9AB\]\[1-9A-HJ-NP-Za-km-z\]{93}$)/`
14:17:10 <recanman[m]> I found a few online but some didn't work with subaddresses, so I changed them around a bit
14:17:21 <recanman[m]> recanman[m]: > <@recanman:agoradesk.com> Would this regex be correct for a standard monero address?
14:17:21 <recanman[m]> > `/(?:^\[48\]\[0-9AB\]\[1-9A-HJ-NP-Za-km-z\]{93}$)/`
14:17:21 <recanman[m]> I don't mean to match integrated addresses
14:24:14 <recanman[m]> Is the only monero javascript library this onehttps://github.com/monero-ecosystem/monero-javascript?
14:24:19 <recanman[m]> s/onehttps/one https/
14:32:43 <sech1> Test it on https://regex101.com/
14:33:00 <sech1> I checked a few addresses and it matched them
14:33:21 <recanman[m]> Thank you, I just wanted to make sure I didn't miss any edge cases
14:35:46 <sech1> [0-9AB] can be changed to [1-9AB]
14:35:59 <sech1> because base58 doesn't have '0'
14:36:09 <recanman[m]> Thank you
15:21:01 <UkoeHB> rbrunner: it is also failing for me, I must have broken something
16:59:16 <hyc> jeffro256[m]: of course not.
17:22:08 <woodser[m]> I'm wondering if this is a valid assertion added to the release-v0.18 branch to check if outputs are frozen before using them: https://github.com/monero-project/monero/blob/ab826008d614a3722398642942c291be9650be6d/src/wallet/wallet2.cpp#L2008
17:23:14 <woodser[m]> for example, can key images be imported to the multisig participants in different orders and times, so the key image ordering could be different?
17:23:48 <woodser[m]> asking because this wasn't asserted in the code prior, and my multisig wallets were working
17:28:50 <woodser[m]> whereas now I hit that exception on signing the multisig tx
18:35:55 <jberman[m]> I recall double checking in the scan_tx PR that multisig does rely on consistently ordered key image imports
18:36:22 <jberman[m]> need to re-check, not sure why you didn't run into issues prior to that change
18:51:13 <UkoeHB> I don't think you can rely on ordering, an oversight in that PR?
19:10:58 <jberman[m]> ^that makes more sense. Nevermind what I said. I had checked that multisig relies on consistent ordering of m_transfers which key image imports shouldn't affect
19:19:23 <UkoeHB> rbrunner: ok should be fixed
19:39:37 <moneromoooo> m_transfers should be ordered in (canonical) blockchain order.
19:52:23 <rbrunner> UkoeHB: Thanks, will have a look probably on Sunday.