08:46:15 -xmr-pr- sohamb03 opened issue #6792: Errors with static linking on CentOS
08:46:15 -xmr-pr- > https://github.com/monero-project/monero/issues/6792
10:05:36 <grydz> Hi everyone, I though the bug we encounter (total_received < r.second.first. THROW EXCEPTION: error::wallet_internal_error) was due to our modification with CLSAG but after reverting our changes on the Monero app and tested using MLSAG, I have the same error!
10:06:01 <grydz> It means that when using master branch and doing MLSAG like before, it doesn't work anymore.
10:07:05 <grydz> Is there any changes introduced in `check_tx_proof()`?
10:08:13 <grydz> Or in InProof OutProof?
10:13:18 <selsta> https://github.com/monero-project/monero/commit/6bfcd310158ff749d6857f5b0d2a53fad6a4e2bd
10:13:20 <selsta> maybe? no idea
10:24:40 <grydz> Oh, thanks. Might be related!
12:01:52 <sethsimmons> IMO it would be a nice solution to be able to flag any subaddress in your wallet as one with a higher risk of monitoring (like a subaddress used to receive from an exchange) and have the wallet mix inputs to that subaddress output by output as they come in.
12:02:14 <sethsimmons> ErCiccione: selsta sech1 knaccc "IMO it would be a nice solution to be able to flag any subaddress in your wallet as one with a higher risk of monitoring (like a subaddress used to receive from an exchange) and have the wallet mix inputs to that subaddress output by output as they come in."
12:02:29 <ErCiccione[m]> That would be niot great UX for the user tho
12:02:37 <sethsimmons> moneromooo: this may be an interesting convo for you, chatting about ways to resolve/approach solving merge analysis
12:03:08 <sethsimmons> <ErCiccione[m] "That would be niot great UX for "> It would be as simple as right clicking a subaddress and flagging it
12:03:21 <sethsimmons> And then each time you create a subaddress being prompted if you'd like to flag it
12:03:27 <sethsimmons> With a quick tip on why you may or may not want to
12:03:27 <ErCiccione[m]> Yeah, but it's still an action more than a normal user is willing to make
12:03:37 <knaccc> yeah that sounds hard for most people to grasp
12:03:40 <sethsimmons> <sethsimmons "And then each time you create a "> Force a choice at creation of SAs
12:04:03 <sethsimmons> Could even not worry about specifics of the attack but just ask if it's an exchange or other party you do not trust
12:04:12 <sethsimmons> And link out to more detail for the curious
12:04:47 <ErCiccione[m]> I think the ideal solution require small or better no input at all from the final user
12:04:59 <sethsimmons> But then you run into massive chain bloat
12:05:04 <sethsimmons> Because you have to do every output churning
12:05:16 <sethsimmons> There's not way to know at the protocol level who things are coming from obviously
12:05:30 <sethsimmons> So you would have to distrust all inputs and churn every one
12:05:38 <sethsimmons> Miners would love it though :P
12:05:58 <knaccc> there is a forcing factor here that does simplify things, which is that we're hitting a wall with wallet scanning duration anyway
12:06:13 <knaccc> and if we take that seriously, then that changes how we see things
12:06:24 <sethsimmons> supercop + the tagging idea make a big enough change there to help with this?
12:06:40 <sethsimmons> (can't remember the name of the tagging that was suggested on-chain)
12:07:00 <ErCiccione[m]> The tagging idea would be great UX, but sounds like a risky move that would require a lot of auditing before getting implemented
12:07:37 <ErCiccione[m]> but yeah i agree with knaccc, that would make things different since chain bloat would have a totally different meaning and effect
12:08:31 <sethsimmons> You still would have major issues with disk usage no matter what, as you'd necessarily be doubling (at minimum) the disk/verification of every real transaction
12:08:41 <sethsimmons> *disk usage and compute
12:09:01 <sethsimmons> Churning every input by default seems like way too much for the network honestly
12:09:13 <sethsimmons> Yeah its fine now when we have ~10k transactions a day
12:09:26 <knaccc> even if we don't recommend churn, it'll already be too much soon, from a wallet scanning time perspective
12:10:13 <knaccc> if monero continues to get more popular
12:10:40 <sethsimmons> Do you have a specific proposal for wallet scanning in mind?
12:10:51 <sethsimmons> I honestly don't really have any issues with current scan times, but I may be in the minority here.
12:11:18 <sethsimmons> My oldest wallet scans from restore height to present in ~7m
12:11:43 <sethsimmons> Mobile is obviously slower but is only like 30s each time I open the app to sync up
12:11:59 <sethsimmons> Not sure from restore height how long it takes but thats less likely to happen on mobile more than once
12:12:45 <knaccc> "If the transaction volume were to increase 30x from here, it would take 86 hours per year of transactions scanned"
12:12:50 <knaccc> that's wallet scanning time
12:13:04 <knaccc> and we'll accelerate the path to getting 30x from here if we recommend churn
12:13:07 <sech1> time for someone to implement GPU accelerated wallet scanning
12:13:41 <sethsimmons> <sech1 "time for someone to implement GP"> This would certainly be a big boost if its viable across GPU platforms, especially mobile
12:13:54 <sech1> OpenCL is cross-platform
12:15:05 <knaccc> my list of current solutions to the wallet scanning time problem is: 1. GPU EC ops, 2. https://github.com/monero-project/research-lab/issues/75
12:15:07 <sethsimmons> Do we have any kind of RFP/request process to put out a call for devs on a specific topic?
12:15:46 <sethsimmons> Like GPU-boosted wallet scanning?
12:16:47 <sech1> we have CCS
12:17:05 <sethsimmons> But that only works one way -- dev says they want to do work and asks for money
12:17:17 <knaccc> ooh someone has done a BSD-licensed opencl curve25519 here https://github.com/PlasmaPower/nano-vanity/tree/master/src/opencl
12:17:22 <sethsimmons> I am not a dev, but would campaign to fund someone for GPU-boost
12:17:27 <dsc_> GPU accelerated wallet scanning? Is that possible?
12:17:31 <dsc_> amaze.jpg
12:17:32 <knaccc> for sure
12:17:46 <sech1> GPUs can do any computations, it's possible
12:17:47 <ErCiccione[m]> I've been thinking of some kind of bounty structure for stuff like this for quite some time
12:17:49 <dsc_> that would be so awesome
12:17:54 <ErCiccione[m]> we had a similar structure on the old forum
12:18:03 <sech1> the speedup of GPU over CPU in this specific task is unknown though
12:18:03 <knaccc> the idea was rejected about 3 years ago, it's already been discussed
12:18:17 <knaccc> people were worried it would mean that we'd leave devices behind
12:18:32 <knaccc> and also that it would be very difficult to debug and make work over dozens of devices
12:18:33 <dsc_> CPU fallback
12:18:35 <dsc_> ^^
12:18:36 <knaccc> and be a huge pain
12:18:42 <dsc_> fair
12:18:48 <knaccc> well CPU fallback to suddenly take 86 hours is a problem
12:18:56 <sech1> yes, OpenCL is good in theory, but nightmare in practice. Sometimes it breaks even across same GPU, but different drivers.
12:19:01 <knaccc> this has existed for years
12:19:03 <knaccc> https://pdfs.semanticscholar.org/0435/fca0ce2d1a23967f53333b9cf963d136fc07.pdf
12:19:10 <knaccc> i think they reported a 50x speedup, from memory
12:20:24 <sech1> OpenCL kernels can be self-tested at startup, so it's possible to detect broken devices or drivers and fallback to CPU
12:21:20 <sethsimmons> Yeah as long as there was fallback I'm not sure the issue
12:21:32 <sethsimmons> Especially if the wallet would alert you to the fallback and direct you to somewhere for troubleshooting
12:22:11 <knaccc> the problem is that it'd be a developement nightmare. hyc was against it, i'm not sure if that's still his position
12:22:29 <knaccc> it's something that gets discussed and rejected every year or so
12:22:47 <knaccc> i'm personally against it too
12:23:21 <knaccc> because i don't think it's the right solution to this problem
12:23:30 <sech1> this is wallet-side, right? So we can expect some 3rd-party wallets doing this in the future.
12:23:36 <knaccc> i'd rather eliminate wallet scanning altogether
12:23:51 <knaccc> yeah wallet-side only, although the tech could speed up nodes too
12:24:03 <selsta> how?
12:24:24 <knaccc> selsta how to what?
12:24:39 <selsta> node syncing?
12:24:52 <knaccc> node syncing uses CPU intensive EC ops to verify rings etc
12:25:02 <knaccc> so we'd just GPU accelerate that
12:25:33 <selsta> we didn’t implement ASM speedups there due to potential issues in the EC library, afaik same would apply for GPU acceleration
12:25:43 <selsta> issue in wallet scan wouldn’t be as severe
12:25:44 <knaccc> what were the potential issues?
12:29:27 <selsta> Less tested overall.
12:30:15 <knaccc> selsta was kind of test failure was most concerning? timing attacks, incorrect results, crash bugs...?
12:30:27 <knaccc> what*
12:30:37 <selsta> AFAIK incorrect results.
12:30:58 <knaccc> ouch.
12:31:12 <knaccc> so turns out crypto is hard, who would have thought :)
12:32:08 <selsta> No, there was no incorrect result, that’s only the worry AFAIK
12:32:17 <selsta> but vtnerd can explain this better
12:32:41 <knaccc> i assume there are nasty edge cases that are really hard to find
12:32:45 <sethsimmons> Maybe we can bubble this up to try and get some closure/feedback: https://github.com/monero-project/research-lab/issues/75
12:33:09 <sethsimmons> This seems more immediately approachable than GPU-boosted scanning since that has been reviewed and dismissed already, and no technical user exists right now to drive that.
13:59:06 <grydz> Thanks selsta for pointing the right commit! Just updated our application to InProofv2 and everything is working :)
14:00:30 <grydz> Could we remove InProofv1 from Ledger's Monero application?
14:05:43 <sarang> Would it need to verify such proofs?
14:11:46 <grydz> It's at least verified in `sanity_check()`
14:13:09 <grydz> The HW just generates the proof which is verified on the client side.
14:20:38 <sarang> Got it
14:20:48 <sarang> I suppose that was already handled by default on the Monero side automatically
14:20:57 <sarang> since the proof generator was updated in-place
14:21:15 <sarang> So it looks like full success now? :)
14:22:16 <grydz> Just need to test a little bit more! But it should be ok and we don't need any modification on the client side :)
14:32:05 <sarang> Nice! So to confirm, there will be no expected additional PRs made to the Monero codebase for Ledger support?
14:37:28 <grydz> I suppose it's done!
14:38:30 <grydz> We won't need another PR.
14:39:24 <sarang> Great!
14:46:16 <moneromooo> .merge+ 6757
14:46:17 <xmr-pr> Added
16:14:04 <sarang> So grydz, everything will be ready to go for Ledger users, provided they update firmware when Ledger releases it?
16:15:20 <grydz> Right, we'll release Monero app version 1.7.0 which will be available for FW 1.6.1 on Nano S and FW 1.2.4-4 on Nano X.
16:17:14 <sarang> Is there an estimate on the release date for that?
16:17:20 <sarang> (in case people ask)
16:24:04 <grydz> As soon as I'm sure Monero app 1.7.0 works fine with MLSAG and CLSAG, I'll release it.
16:24:28 <grydz> Could be in a few days.
16:25:22 <grydz> We'll ensure it will be released by the end of September :D
16:25:34 <sarang> Oh wow! Nice
16:26:01 <sarang> Yeah, AFAIK the plan is still to release the Monero binaries ~17 September, and hit the upgrade height ~17 October
16:26:19 <sarang> Meaning users need to update software between those dates for uninterrupted functionality
16:26:31 <grydz> Sure, I was aware of that.
16:28:27 <grydz> Hope I could release it before thursday. If not, as I'll be off between 04/09 and 21/09, it will be done before the end of September.
16:28:36 <sarang> moneromooo: know if a fork height has been set?
16:28:43 <sarang> grydz: great!
16:28:49 <sarang> Thanks for all your hard work on this; it's greatly appreciated
16:29:03 <sarang> I'm very happy users will have Ledger support from day one of the upgrade
16:29:12 <moneromooo> I know, and it has.
16:29:21 <sarang> Excellent
16:29:24 <grydz> Thanks to all of you for your help :)
16:29:29 <sarang> I'll contact the Trezor team, who wanted to know when this happens
16:29:35 <sarang> grydz: always happy to help
19:36:05 <pyu> split
19:46:27 <grydz> Using my own stagenet Monero node (v0.16.0.3), is there any reason why I always get: "Error: daemon is busy. Please try again later"?
19:47:01 <selsta> Does your wallet display this?
19:47:07 <grydz> Yes.
19:47:12 <moneromooo> If it's not found the network yet and is not running with --offline.
21:46:15 -xmr-pr- woodser opened pull request #6793: update error message to "No unlocked balance in the specified account"
21:46:15 -xmr-pr- > https://github.com/monero-project/monero/pull/6793