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!

It means that when using master branch and doing MLSAG like before, it doesn't work anymore.

Is there any changes introduced in `check_tx_proof()`?

Or in InProof OutProof?

maybe? no idea

Oh, thanks. Might be related!

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.

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."

That would be niot great UX for the user tho

moneromooo: this may be an interesting convo for you, chatting about ways to resolve/approach solving merge analysis

<ErCiccione[m] "That would be niot great UX for "> It would be as simple as right clicking a subaddress and flagging it

And then each time you create a subaddress being prompted if you'd like to flag it

With a quick tip on why you may or may not want to

Yeah, but it's still an action more than a normal user is willing to make

yeah that sounds hard for most people to grasp

<sethsimmons "And then each time you create a "> Force a choice at creation of SAs

Could even not worry about specifics of the attack but just ask if it's an exchange or other party you do not trust

And link out to more detail for the curious

I think the ideal solution require small or better no input at all from the final user

But then you run into massive chain bloat

Because you have to do every output churning

There's not way to know at the protocol level who things are coming from obviously

So you would have to distrust all inputs and churn every one

Miners would love it though :P

there is a forcing factor here that does simplify things, which is that we're hitting a wall with wallet scanning duration anyway

and if we take that seriously, then that changes how we see things

supercop + the tagging idea make a big enough change there to help with this?

(can't remember the name of the tagging that was suggested on-chain)

The tagging idea would be great UX, but sounds like a risky move that would require a lot of auditing before getting implemented

but yeah i agree with knaccc, that would make things different since chain bloat would have a totally different meaning and effect

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

*disk usage and compute

Churning every input by default seems like way too much for the network honestly

Yeah its fine now when we have ~10k transactions a day

even if we don't recommend churn, it'll already be too much soon, from a wallet scanning time perspective

if monero continues to get more popular

Do you have a specific proposal for wallet scanning in mind?

I honestly don't really have any issues with current scan times, but I may be in the minority here.

My oldest wallet scans from restore height to present in ~7m

Mobile is obviously slower but is only like 30s each time I open the app to sync up

Not sure from restore height how long it takes but thats less likely to happen on mobile more than once

"If the transaction volume were to increase 30x from here, it would take 86 hours per year of transactions scanned"

that's wallet scanning time

and we'll accelerate the path to getting 30x from here if we recommend churn

time for someone to implement GPU accelerated wallet scanning

<sech1 "time for someone to implement GP"> This would certainly be a big boost if its viable across GPU platforms, especially mobile

OpenCL is cross-platform

my list of current solutions to the wallet scanning time problem is: 1. GPU EC ops, 2. monero-project/research-lab #75

Do we have any kind of RFP/request process to put out a call for devs on a specific topic?

Like GPU-boosted wallet scanning?

we have CCS

But that only works one way -- dev says they want to do work and asks for money

ooh someone has done a BSD-licensed opencl curve25519 here github.com/PlasmaPower/nano-vanity/tree/master/src/opencl

I am not a dev, but would campaign to fund someone for GPU-boost

GPU accelerated wallet scanning? Is that possible?

amaze.jpg

for sure

GPUs can do any computations, it's possible

I've been thinking of some kind of bounty structure for stuff like this for quite some time

that would be so awesome

we had a similar structure on the old forum

the speedup of GPU over CPU in this specific task is unknown though

the idea was rejected about 3 years ago, it's already been discussed

people were worried it would mean that we'd leave devices behind

and also that it would be very difficult to debug and make work over dozens of devices

CPU fallback

^^

and be a huge pain

fair

well CPU fallback to suddenly take 86 hours is a problem

yes, OpenCL is good in theory, but nightmare in practice. Sometimes it breaks even across same GPU, but different drivers.

this has existed for years

i think they reported a 50x speedup, from memory

OpenCL kernels can be self-tested at startup, so it's possible to detect broken devices or drivers and fallback to CPU

Yeah as long as there was fallback I'm not sure the issue

Especially if the wallet would alert you to the fallback and direct you to somewhere for troubleshooting

the problem is that it'd be a developement nightmare. hyc was against it, i'm not sure if that's still his position

it's something that gets discussed and rejected every year or so

i'm personally against it too

because i don't think it's the right solution to this problem

this is wallet-side, right? So we can expect some 3rd-party wallets doing this in the future.

i'd rather eliminate wallet scanning altogether

yeah wallet-side only, although the tech could speed up nodes too

how?

selsta how to what?

node syncing?

node syncing uses CPU intensive EC ops to verify rings etc

so we'd just GPU accelerate that

we didn’t implement ASM speedups there due to potential issues in the EC library, afaik same would apply for GPU acceleration

issue in wallet scan wouldn’t be as severe

what were the potential issues?

Less tested overall.

selsta was kind of test failure was most concerning? timing attacks, incorrect results, crash bugs...?

what*

AFAIK incorrect results.

ouch.

so turns out crypto is hard, who would have thought :)

No, there was no incorrect result, that’s only the worry AFAIK

but vtnerd can explain this better

i assume there are nasty edge cases that are really hard to find

Maybe we can bubble this up to try and get some closure/feedback: monero-project/research-lab #75

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.

Thanks selsta for pointing the right commit! Just updated our application to InProofv2 and everything is working :)

Could we remove InProofv1 from Ledger's Monero application?

Would it need to verify such proofs?

It's at least verified in `sanity_check()`

The HW just generates the proof which is verified on the client side.

Got it

I suppose that was already handled by default on the Monero side automatically

since the proof generator was updated in-place

So it looks like full success now? :)

Just need to test a little bit more! But it should be ok and we don't need any modification on the client side :)

Nice! So to confirm, there will be no expected additional PRs made to the Monero codebase for Ledger support?

I suppose it's done!

We won't need another PR.

Great!

.merge+ 6757

Added

So grydz, everything will be ready to go for Ledger users, provided they update firmware when Ledger releases it?

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.

Is there an estimate on the release date for that?

(in case people ask)

As soon as I'm sure Monero app 1.7.0 works fine with MLSAG and CLSAG, I'll release it.

Could be in a few days.

We'll ensure it will be released by the end of September :D

Oh wow! Nice

Yeah, AFAIK the plan is still to release the Monero binaries ~17 September, and hit the upgrade height ~17 October

Meaning users need to update software between those dates for uninterrupted functionality

Sure, I was aware of that.

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.

moneromooo: know if a fork height has been set?

grydz: great!

Thanks for all your hard work on this; it's greatly appreciated

I'm very happy users will have Ledger support from day one of the upgrade

I know, and it has.

Excellent

Thanks to all of you for your help :)

I'll contact the Trezor team, who wanted to know when this happens

grydz: always happy to help

split

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"?

Does your wallet display this?

Yes.

If it's not found the network yet and is not running with --offline.