03:42:54 * willshu[m] uploaded an image: (202KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/KFEXsmTFYiXLDaumWizTOwPR/Screen%20Shot%202022-08-22%20at%2011.42.33.png >
03:43:14 <willshu[m]> What does `Too few outputs, outputs may be corrupted` mean?
03:44:10 <selsta> willshu[m]: https://github.com/monero-project/monero/pull/8421
03:44:43 <selsta> it means the input is invalid
05:17:53 <ooo123ooo1234567> <ooo123ooo1234567> "ok go to do something from this,..." <- (bulletproofs++ is ready, but 100% nothing had changed here, let's check it)
05:21:36 <moneromooo> selsta: done
05:31:10 <ooo123ooo1234567> https://paste.debian.net/hidden/09bb1d1d/, performance of unoptimized code relatively to bp and bp+
05:32:42 <selsta> more than twice as fast? or did I read it wrong?
05:34:02 <selsta> sounds almost too good
05:35:53 <ooo123ooo1234567> it took only 11 days to write implementation since 11th Aug
05:36:20 <selsta> is this only due to bulletproofs++ or did you find other verification speed improvements?
05:51:45 <ooo123ooo1234567> probably incorrect questions
05:51:53 <ooo123ooo1234567> does anybody fixed that deadlock ?
05:52:16 <ooo123ooo1234567>  * is that deadlock (reported by ...) fixed or not yet ?
05:55:31 <ooo123ooo1234567> no - judging by commits in master
05:56:05 <ofrnxmr[m]> Was it reproducible? 
05:56:31 <ofrnxmr[m]> Gingeropolous I believe reported 
06:06:32 <ooo123ooo1234567> according to history (since 7th May) it's better to work offline than wasting time on useless talk here
06:07:02 <ooo123ooo1234567> funny that even that deadlock isn't yet fixed relatively to implemented bp3 with checked security in the same period of time
06:09:49 <jberman[m]> I couldn’t repro ginger’s deadlock using the stacktrace. I gave it around 1-1.5 days. Would appreciate you sharing how you tackled the problem. I’d like to use it as a learning process to improve
06:26:43 <jberman[m]> <willshu[m]> "What does `Too few outputs..." <- A prior import must have corrupted the vouts array; the output’s position in the vouts array is expected to be its internal output index. If the size of the vouts array is < internal output index, that should be impossible. Did you do any sort of custom import/overwrite any code yourself? If not it may be related to the issues PR 8513 is fixing but not certain yet
06:45:03 * willshu[m] uploaded an image: (197KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/HyWLTVooYpvTXCDumsoRohyq/Screen%20Shot%202022-08-22%20at%2014.44.50.png >
06:45:40 <willshu[m]> <jberman[m]> "A prior import must have..." <- I set up the view-only wallet each time so there is no prior import.
06:48:15 <willshu[m]> <jberman[m]> "A prior import must have..." <- In this case, one deposit is at primary address. another is at a subaddress with index `1:181192`. I am pretty sure there are only two deposits to this wallet. Is it because the index is too large?
06:48:38 <willshu[m]> s/view-only/offline/
07:51:46 <jberman[m]> checking if I can repro
19:19:12 <selsta> .merge+ 8486
19:19:12 <xmr-pr> Added
21:18:17 <UkoeHB> tevador: I'm trying to get your mx25519 library added as a submodule to my branch but getting a compile error (`error: use of undeclared identifier 'asm'`). Is there anything wrong with this commit? https://github.com/UkoeHB/monero/commit/f7c53b83a22f6d301e105058a490c541fc0e5a0c
22:21:44 <selsta> UkoeHB: as a first step, does https://github.com/tevador/mx25519/ compile on your system?
22:22:45 <selsta> I think the ASM code needs some modifications so that it runs on macOS
22:27:39 <selsta> I got it to compile on my Intel Mac, the ARM Mac code needs work
22:30:25 <selsta> UkoeHB: you have to link against mx25519 in CMake, use the RandomX PR as an example: https://github.com/monero-project/monero/pull/5549/files
22:42:54 <selsta> also https://stackoverflow.com/questions/35131350/error-asm-undeclared-first-use-in-this-function
23:35:47 <jberman[m]> will.shu: trying to import an output received to a high index one-off subaddress should throw on import (right here: https://github.com/monero-project/monero/blob/b6a029f222abada36c7bc6c65899a4ac969d7dee/src/wallet/wallet2.cpp#L13298)
23:36:05 <jberman[m]> You need to manually look ahead for that subaddress before importing the outputs into the wallet
23:36:30 <jberman[m]> But I still don't see how to trigger this "outputs may be corrupted" error you're seeing. It would be very useful if you could either share your output hex with me, or even better repro on testnet and share the wallet keys
23:37:28 <jberman[m]> moneromooo: perhaps we should also assume manually imported outputs are trusted, and move this above `generate_key_image_helper`: https://github.com/monero-project/monero/blob/b6a029f222abada36c7bc6c65899a4ac969d7dee/src/wallet/wallet2.cpp#L13211-L13212
23:38:48 <jberman[m]> Or alternatively, we could check if the output belongs to the account first, then expand the lookahead if so, then generate key image
23:39:18 <jberman[m]> wait scratch that^ that was dumb. can't do that. need to expand the lookahead first or fail