**\<i-a>** Hello all, it is time for our firmware meeting to start. I am not sure if it is not too early to have a meeting like this, but let's see.
**\<i-a>** Strange, there were so many people saying they have questions about code and now nobody is here:) So I will give a quick update on our project:
**\<i-a>** Ok here is the quick update: USB communications is working, alse we can generate wallet by using internal random number generator (thanks god for m2049r, nice job)
**\<i-a>** Maybe you have some recommendation how to move from here? My questions could look silly, but thats because I am personally just learning monero.
**\<m2049r[m]>** :)
**\<i-a>** On the other hand, there are other people working and maybe my questions could help also to them.
**\<m2049r[m]>** is there anyone here who is actually taking part in this meeting besides us two?
**\<hotoatmeal>** is the plan to use the same strategy that the ledger guy came up with, where private keys are sent (encrypted) from the device to the wallet?
**\<qqitty>** CS noob looking to study xmr code this weekend. any design books/web guides to read like Huang's dissecting BTC?
**\<hotoatmeal>** m2049r[m]: I'm mostly passively participating, until that question
**\<dEBRUYNE>** m2049r[m]: Most people will probably just read until they want to say something :p
**\<i-a>** hotoatmeal: We are here to speak about the plan.. I think if we want to do all the signing stuff in the device, we would need more memory.In case we need more memory, we will just setup a new device with bigger mcu.
**\<m2049r[m]>** i would like an implementation where the keys never ever leave the device - we have to see if thats possible with the hardware constraints we have.
**\<hotoatmeal>** I would like that too!
**\<i-a>** It is still organic and you have perfect opportunity to bend the way how it is being developped:)
**\<i-a>** Me too.
**\<m2049r[m]>** there may be multiple implementations, with different roads to success.
**\<hotoatmeal>** I don't yet understand how to find transaction outputs without revealing the view key
**\<m2049r[m]>** without having studies the code i think it should be possible to hook into the code and have the device take over when keys are in play.
**\<hotoatmeal>** if that's not possible, then the entire blockchain would have to be fed through the device over usb.... might be quite slow.
**\<m2049r[m]>** (into the wallet client code)
**\<m2049r[m]>** yes - but thats probably not a good idea - and were back to sending the keys to the client
**\<hotoatmeal>** yeah :/
**\<hotoatmeal>** too bad homeomorphic encryption systems are so slow
**\<hotoatmeal>** otherwise you could trustlessly give the client an encrypted version of your view key, let it scan the blockchain for you, and provide the relevant txo's (also encrypted)
**\<hotoatmeal>** and have the device decrypt the computed result
**\<m2049r[m]>** i need to read up on how exactly the keys are used in the clients - any specific hint on where to get started?
**\<hotoatmeal>** cryptonote paper is where I got started
**\<hotoatmeal>** also looking at the ledger guy's patch
**\<m2049r[m]>** i am not sure the communication to & from the device needs to be encrypted - are you worried about usb sniffers?
**\<jbdatko>** hotoatmeal, can you link that patch?
**\<m2049r[m]>** and if yes, whats the attack?
**\<hotoatmeal>** so two separate things, both with different reasons for encryption
**\<qqitty2>** Thanks @hotoatmeal. I'll go dive into the cryptonote WP
**\<m2049r[m]>** cryptonote paper seems mostly vague
**\<hotoatmeal>** ledger guy's patch encrypts the communication because it's transferring raw key data
**\<hotoatmeal>** should be a no-brainer that that should be encrypted
**\<luigi1111>** Paper is pretty clear unless you want implementation specifics
**\<m2049r[m]>** heh yes
**\<hotoatmeal>** this other thing about H-E, is a separate idea, and that's to allow someone else to scan the blockchain on your behalf, without revealing your view key to them (losing your privacy)
**\<m2049r[m]>** paper is clear - i meant vague in the sense of implementation specifics
**\<m2049r[m]>** H-E?
**\<luigi1111>** I think you pretty much have to have client do the scanning
**\<luigi1111>** Not the hw
**\<hotoatmeal>** homeomorphic encryption
**\<dEBRUYNE>** jbdatko: It's under open PRs on the monero repository
**\<luigi1111>** Unless you have some hw acceleration it's just too slow
**\<i-a>** luigi1111: yes but is there a way how to do it?
**\<luigi1111>** How to do which
**\<hotoatmeal>** i.e. someone else performs math on encrypted values that they can't see, and returns the result to you
**\<i-a>** how to let PC scan the whole blockchain and prepare outgoing tx in a way, that the are sent to device just for signing.
**\<luigi1111>** Sure
**\<luigi1111>** The cold wallet signing basically does this already
**\<hotoatmeal>** the problem is that H-E implementations of crypto algos are really really really slow
**\<hotoatmeal>** like hours for a single round of AES
**\<luigi1111>** That'd probably be slower than the device doing the scanning ^^
**\<luigi1111>** :)
**\<hotoatmeal>** yeah
**\<i-a>** :(
**\<hotoatmeal>** but in terms of mathematical purity / elegance... I really want that kind of solution to work :)
**\<i-a>** Ok, another question: If device did he whole scanning. How much memory we need on the device? I think that downlink from peers is usually slower than USB, so limitations is more in memory requirement at the device.
**\<m2049r[m]>** how big of a problem would it be to reveal the viewkey to the client?
**\<luigi1111>** Not memory
**\<luigi1111>** Cpu
**\<luigi1111>** I don't think it's an issue
**\<luigi1111>** I mean it isn't perfect
**\<luigi1111>** But it has the benefit of being workable
**\<hotoatmeal>** revealing to the client just means that you can't have a non-daemon client
**\<luigi1111>** Sure you can
**\<i-a>** yes but it is fine for now I think.
**\<luigi1111>** You could have a remote node
**\<hotoatmeal>** well, yeah
**\<luigi1111>** All the way to mymonero
**\<m2049r[m]>** the client wallet cache - is that encrypted?
**\<moneromooo>** Yes.
**\<m2049r[m]>** thought so - so the device would need to do that as well.
**\<hotoatmeal>** is it possible to give the client an image of the view key, and then have it search the blockchain for some subset of txo's that /might/ match (as a coarse filter)?
**\<endogenic>** vtnerd
**\<jbdatko>** hotoatmeal, thank you
**\<hotoatmeal>** (reducing the amount of work the device has to do, but not giving up the full key data?)
**\<m2049r[m]>** how would that work?
**\<jbdatko>** AES accelerators on MCU are pretty good now, so depending on the MCU it might not be completely horrible (sorry I'm jumping in w/o knowing the full context)
**\<endogenic>** hotoatmeal: mrl has been workin on this problem for some time
**\<hotoatmeal>** endogenic: anything I'm saying known not to be worth pursuing? (by proofs that it doesn't work, or somesuch)
**\<m2049r[m]>** we have space for secure elements on the board - things which can do aes and other things in hardware.
**\<luigi1111w>** you need ed25519 acceleration
**\<luigi1111w>** which I doubt exists
**\<m2049r[m]>** yeah, except that.
**\<hotoatmeal>** heh. now it needs an fpga
**\<luigi1111w>** I don't really see any way around it
**\<luigi1111w>** mymonero as a hw client would actually be quite desirable
**\<luigi1111w>** and quite an upgrade
**\<luigi1111w>** well it all depends on perspective :)
**\<endogenic>** :)
**\<luigi1111w>** the most secure/private arrangement would be user owned daemon -> wallet/client -> hw
**\<luigi1111w>** but you can delegate the first two for privacy loss
**\<luigi1111w>** well the first one isn't really privacy loss
**\<i-a>** our nordic semiconductor candidate has ed25519 hw block, but we still didnt get them.
**\<luigi1111w>** or a different type or of privacy
**\<luigi1111w>** i-a that's interesting
**\<luigi1111w>** I'd be curious to see perf numbers
**\<m2049r[m]>** i-a but thats with an nda so we cant be open source, no?
**\<luigi1111w>** for some usable ed25519 operation
**\<i-a>** luigi1111w: nRF52840, it has secure crypto cell or something like that.
**\<i-a>** Of course there are other problems, like a non open design and so on.
**\<msvb-mob>** cryptocell is available without nda.
**\<luigi1111w>** I mean something like signatures/sec
**\<i-a>** another question is if this cryptocell ed25519 is fast enough to be usable.
**\<luigi1111w>** that was my only question :)
**\<i-a>** Unfortunately I dont know now. But I will try to find out. It seems like as-fast-as-possibe ed25529 od device is a must.
**\<hotoatmeal>** do you have a ballpark for how fast it would have to be to be usable?
**\<msvb-mob>** cec1702 has the cuve too.
**\<i-a>** msvb-mob: nice, can we somehow determine their performance?
**\<m2049r[m]>** they sortof claim its 10x a software solution but dont show numbers
**\<luigi1111w>** software solution on that power of hw?
**\<luigi1111w>** IDK, something similar to an older cpu
**\<msvb-mob>** i-a: I don't know how to measure performance without testing the devices on real hardware, unfortunately.
**\<m2049r[m]>** thats the question luigi - its blabla
**\<m2049r[m]>** can we GET real hardware?
**\<luigi1111w>** :)
**\<i-a>** msvb-mob: hmm:( are we going to have cec1702 to do some testing?
**\<luigi1111w>** I think it would be really cool if such a device could be made
**\<luigi1111w>** but I'm skeptical
**\<msvb-mob>** m2049r[m]: I can send you a nRF52840-DK if you want.
**\<luigi1111w>** we know the viewkey delegation works, at least
**\<msvb-mob>** i-a: The nRF is easy (there's a devkit for that) but to test the CEC1702 we must make the boards ourselves first.
**\<luigi1111w>** (mymonero and openmonero both use the exact same idea already)
**\<msvb-mob>** I think the MCUs are already in my lab.
**\<i-a>** msvb-mob: that is not a big deal, if you know the are comming, i can send you a board asap.
**\<i-a>** (lets say gerbers on monday/tuesday)
**\<i-a>** msvb-mob: what about nda on this cec1702? Or do they have some problem?
**\<msvb-mob>** The CEC1702 is not NDA encumbered.
**\<i-a>** perfect candidate -\_-
**\<msvb-mob>** Yes, I think so too.
**\<m2049r[m]>** the CEC1702 & the nRF52840 would replace our MCU?
**\<i-a>** m2049r[m]: I think yes, because our mcu is lacking ed25519
**\<msvb-mob>** m2049r[m]: They are both Cortex-M4 MCUs so they could do so. If they aren't large enough to contain transactions in memory or code in program storage we could use them as coprocessors probably.
**\<msvb-mob>** Would be a bit weird.
**\<m2049r[m]>** we have to see what they mean by ed25519. do we need just signing & verifying or do we also need curve arithmetic luigi1111w
**\<luigi1111w>** signing and verifying sorta-mostly-ish include all the operations needed
**\<luigi1111w>** I guess that's not really true
**\<luigi1111w>** but the operations that need accelerated would be, mostly
**\<m2049r[m]>** the data sheets says:
**\<m2049r[m]>** Elliptic Curve point multiply with Curve25519
**\<m2049r[m]>** The Edwards-curve Digital Signature Algorithm (EdDSA), using Curve25519
**\<m2049r[m]>** (CEC1702)
**\<iDunk>** ed25519 != Curve25519.
**\<i-a>** nRF does both i think
**\<i-a>** yes
**\<i-a>** but cec1702 doesn't have ed25519:( or I cannot find it in datasheet.
**\<m2049r[m]>** the nrf can create keys, sign & verify. "The generation is performed using EC Edwards ed25519 algorithm."
**\<i-a>** cec1702 has only Curve25519
**\<luigi1111w>** if they are going off of nacl or similar they have both
**\<luigi1111w>** the signing is ed
**\<luigi1111w>** and the box stuff is curve255
**\<msvb-mob>** i-a: No ECDSA on CEC1702? I don't have the documents with me now.
**\<i-a>** ok so to be clear:
**\<i-a>** The Elliptic Curve Digital Signature Algorit
**\<i-a>** hm (ECDSA), using all supported NIST curves
**\<i-a>** he Edwards-curve Digital Signatur
**\<i-a>** e Algorithm (EdDSA), using Curve25519
**\<luigi1111w>** that could be naming issues though :)
**\<i-a>** maybe ed25519 is hidden somewhere, but it isn explicitly mentioned, Curve25519 is mentioned.
**\<i-a>** \*isnt
**\<luigi1111w>** yeah they are often bundled together
**\<m2049r[m]>** so you are saying we need new hardware in any case?
**\<luigi1111w>** to attempt to "do everyone on device", yes (and I'm doubtful it's possible)
**\<luigi1111w>** to do a client-delegated arrangement, no
**\<hotoatmeal>** these slides say they can do ~1400 ECDH's /s on a cortex A8: https://cr.yp.to/talks/2012.11.29/slides.pdf
**\<msvb-mob>** i-a: The ED25519 API is on pages 60-61 of the CEC/MEC Family Devices ROM API Users Guide.
**\<i-a>** msvb-mob: thank you,)
**\<msvb-mob>** For example ed25519\_valid\_sig (validate signature) is a function.
**\<hotoatmeal>** and Ed25519 was only a bit slower
**\<hotoatmeal>** what's the rough size of the blockchain, counted in txo's?
**\<luigi1111w>** total size isn't that useful
**\<luigi1111w>** size over past month much more so
**\<hotoatmeal>** growth rate too
**\<luigi1111w>** yeah with some assumed groth
**\<luigi1111w>** growth
**\<luigi1111w>** 200k txs last month
**\<luigi1111w>** so maybe 450k outputs
**\<luigi1111w>** double that at least gets you 1mi/mo
**\<luigi1111w>** checking an output is something like 2x ECDH
**\<hotoatmeal>** so it'll get slower by 20 mins, every month
**\<hotoatmeal>** ouch
**\<luigi1111w>** if you don't use it
**\<luigi1111w>** but yeah
**\<hotoatmeal>** (assuming you need to re-scan the entire chain each time... but maybe that can be cached)
**\<luigi1111w>** there would be quite some catchup time
**\<i-a>** not sure if relevant, but this could be ECDSA performance on CEC device: https://imgur.com/a/WQKqp ?
**\<luigi1111w>** if you leave it unplugged for some time
**\<luigi1111w>** oh
**\<luigi1111w>** I would sure assume you cache
**\<luigi1111w>** if you don't it
**\<luigi1111w>** it's pretty unworkable
**\<hotoatmeal>** yeah
**\<luigi1111w>** you'd have to leave it plugged in a few hours before you could spend each time :)
**\<hotoatmeal>** the worst case of initializing a new device though is pretty bad
**\<hotoatmeal>** though I guess you could just sweep everything to it, and ignore all of the chain that happened before then
**\<luigi1111w>** restored device
**\<luigi1111w>** new device has no txs
**\<hotoatmeal>** right
**\<hotoatmeal>** at least the restore point is something you can make note of, encrypt, and then store like any other backup
**\<m2049r[m]>** are you suggesting we keep the chain/cache on the device?
**\<luigi1111w>** no
**\<luigi1111w>** definitely not the chain
**\<luigi1111w>** I'm still skeptical it's workable at all, just exploring the idea
**\<m2049r[m]>** gottit
**\<hotoatmeal>** do bulletproofs change the costs here?
**\<hotoatmeal>** s.do.will.
**\<m2049r[m]>** do we have constraints about how big the device may be?
**\<endogenic>** yes
**\<luigi1111w>** hotoatmeal no
**\<endogenic>** :P
**\<luigi1111w>** m2049r[m] just tote a computer around
**\<luigi1111w>** NP
**\<luigi1111w>** "this is my hardware wallet"
**\<m2049r[m]>** what if we use a rpi3 to do all the work & store the caches for all the wallets onboard?
**\<m2049r[m]>** :)
**\<endogenic>** now we're cookin with gas
**\<luigi1111w>** it's pretty slow too
**\<luigi1111w>** normal client scanning on computer seems pretty ok to me
**\<m2049r[m]>** how fast does it need to be? do we want full USB3 speeds?
**\<luigi1111w>** by compromising your computer, the hacker now compromises just your privacy
**\<luigi1111w>** rather than
**\<luigi1111w>** you know
**\<luigi1111w>** all your money
**\<i-a>** you can run node on rp3, so it probably isnt so slow..?
**\<hotoatmeal>** m2049r[m]: delegating the viewkey to the computer means it doesn't have to be very quick at all
**\<luigi1111w>** i-a how long does initial sync take
**\<hotoatmeal>** (the device / usb, that is)
**\<luigi1111w>** how long would it take to scan a restored wallet
**\<m2049r[m]>** that would have been the first path to explore
**\<i-a>** luigi1111w: ok, got it:/
**\<endogenic>** i-a no no that's just bc node is fast... because it's asynchronous (now it's my turn to troll)
**\<luigi1111w>** is an rpi significantly better than a normal computer?
**\<luigi1111w>** m2049r[m] if you slim the data down to close to minimum I don't think bandwidth is much concern
**\<luigi1111w>** lemme see
**\<m2049r[m]>** so bottleneck is always computation then. and we want it fast so we dont take forever to sync up again.
**\<luigi1111w>** I'd guess around 240 bytes per tx
**\<m2049r[m]>** if we keep cache on device (sdcard or whatnot) then it can be shared between clients.
**\<luigi1111w>** so even .25MBps would overwhelm the device most likely
**\<m2049r[m]>** 240 either way?
**\<luigi1111w>** no just computer->**device
**\<hotoatmeal>** another idea: put the viewkey on a separate device that's always connected to a computer
**\<msvb-mob>** There have been some requests for SD cards, so it would be nice to try to put one on at least the developer edition board (since it has more space.)
**\<m2049r[m]>** yes - use a viewonly wallet.
**\<msvb-mob>** m2049r[m]: Shift devices makes quite a nice hardware wallet (Bitbox) with a SD card.
**\<endogenic>** do you guys suppose there's any reason why this isn't a match for the mymonero lightwallet server you run alongside the daemon?
**\<luigi1111w>** I don't
**\<endogenic>** i might be misunderstanding
**\<luigi1111w>** I think it's great
**\<luigi1111w>** it's also great for existing mymonero users (privacy issues notwithstanding, of course)
**\<luigi1111w>** but I guess we're discussing the edge of what's possible
**\<luigi1111w>** for having a device that does basically no delegation for maximal security and privacy in all cases
**\<m2049r[m]>** you are saying to have the device connect to an openmonero instance?
**\<luigi1111w>** or maybe just rainbows and unicorns
**\<endogenic>** m2049r[m]: no
**\<endogenic>** i was envisioning some sort of stripped down protocol...vtnerd and i are working on that anyway in the api overhaul
**\<m2049r[m]>** ok, what are you saying?
**\<luigi1111w>** he's talking about mymonero not openmonero
**\<endogenic>** so if you're running your own local server
**\<luigi1111w>** though in theory they are similar
**\<endogenic>** which is written in C++ and in the monero-cli repo alongside the official daemon
**\<endogenic>** it almost seems like it's more a question of protocol and transport
**\<endogenic>** that is
**\<endogenic>** if we really are talking about delegating scanning
**\<endogenic>** of course you have the view key disclosure tradeoff but that's why you run your own server locally
**\<m2049r[m]>** i thought mymonero was closed source and not for anyone to run their own?
**\<luigi1111w>** it is
**\<luigi1111w>** but it won't be for much longer
**\<luigi1111w>** supposedly :)
**\<endogenic>** yep
**\<endogenic>** vtnerd's prioritized it recently
**\<m2049r[m]>** heh
**\<endogenic>** he hadnt been able to before
**\<endogenic>** too many pesky users!
**\<endogenic>** but anyway
**\<endogenic>** this idea does seem to overlap with simplewallet/monero-gui's job too
**\<luigi1111w>** the theory of mymonero locally vs gui/cli is pretty similar
**\<luigi1111w>** yes
**\<endogenic>** does that count as a jinx?
**\<luigi1111w>** slow motion
**\<endogenic>** mm
**\<endogenic>** anyway, whatever software we need, we can build
**\<endogenic>** might be a good idea to just ask what the ideal situation is for the capabilities we have on the hardware side then fill the gaps
**\<m2049r[m]>** we agree that we need lots of well-performing ed25519 operations on the device - no matter which road is taken?
**\<m2049r[m]>** and possibly some form of storage (sdcard,eMMC?)
**\<luigi1111w>** m2049r[m] more is better
**\<luigi1111w>** but it doesn't need to be "a lot" for the delegated road
**\<luigi1111w>** which includes basically everything that's not "do it all on device"
**\<luigi1111w>** whether local client or some mymonero type
**\<m2049r[m]>** signing would be on device for example - how large are the messages to be signed / verified?
**\<luigi1111w>** it does need to be able to hash some KBs yes
**\<luigi1111w>** 50 max, maybe
**\<luigi1111w>** theoretically more, but shouldn't really happen anymore, in most cases
**\<m2049r[m]>** the cec1702 has 24k of "cryptographic ram" which seems to be the ram where cryptomagic happens.
**\<m2049r[m]>** "in most cases" - one case is enough to break it though - so for such cases we would need a software solution to kick in and have the hardware do 99% of cases.
**\<m2049r[m]>** (this is not a problem)
**\<m2049r[m]>** do you have a particular testcase i could run just to see how slow the current device is performing?
**\<luigi1111w>** no I mean you can just disallow
**\<luigi1111w>** would need some research to really know how annoying that would be though
**\<luigi1111w>** (problem comes from having many inputs)
**\<luigi1111w>** ((I guess mining to the wallet could cause it))
**\<luigi1111w>** m2049r[m] well if you have ed25519 code working on it
**\<m2049r[m]>** i do
**\<luigi1111w>** a simple scalarmult
**\<m2049r[m]>** regardless of parameters?
**\<luigi1111w>** random secret key
**\<luigi1111w>** public key needs to be valid at least
**\<luigi1111w>** or a simple scalarmult\_base if you have that
**\<m2049r[m]>** including convesion from/to 256-bit scalars or the mult by itself?
**\<luigi1111w>** including
**\<cslashm>** m2049r[m]: hotoatmeal: Yes All secret value are passed encrypted from device to PC. When PC need perform operation with those values, there are retransmitted to the device
**\<luigi1111w>** you can use any valid point for the pubkey param
**\<luigi1111w>** I can give you one in hex if you want
**\<luigi1111w>** or you can just gen one from the above function
**\<m2049r[m]>** will pm you for more details
**\<m2049r[m]>** cslashm: what encryption is used for the transmission of the keys over usb?
**\<cslashm>** It will be AES128
**\<cslashm>** the key will new at each app usage and dedicated to session when transfer is performed
**\<cslashm>** But I try to send even encrypted the view and spend key
**\<cslashm>** *not send*
**\<m2049r[m]>** and the key exchange is DH?
**\<cslashm>** which DH? The AES key never leave the device
**\<m2049r[m]>** maybe i dont understand aes. isnt that symmetric? how does the pc decode the ciphertext?
**\<cslashm>** PC never decode, I try to explain
**\<luigi1111w>** he's using the pc for encrypted cache only it sounds like
**\<luigi1111w>** but I don't think you need to send spend key ever
**\<luigi1111w>** device has enough memory for that, surely
**\<cslashm>** voila. PC is just a encrypted holder
**\<cslashm>** The advantage is that it keep the secret at the right place
**\<m2049r[m]>** a storage.
**\<cslashm>** for exemple in RCT, it request n secret key, store in the right vector place, and when it use it, it resend the encrypted secret key to device, which decrypt and do the op
**\<cslashm>** @luigi1111w: yes spend/view key never leave the device
**\<cslashm>** I use special value 00..00 and FF...FF for them on PC side
**\<m2049r[m]>** ok, gotta go - it's been great :)
**\<cslashm>** basic idea is to hav no memory restriction, on easly follow the PC code evolution with minimal code device modification
**\<cslashm>** *and easly* (end of day in FR :) )
**\<dEBRUYNE>** cslashm: I've been wondering. Did you run any performance tests? For example, how long does it take to scan / refresh 10k blocks?
**\<cslashm>** for now it's a OMG part
**\<cslashm>**I start some perf test yes but didnot remenber
**\<dEBRUYNE>** Approximately? :p
**\<cslashm>** It is just impossible to rescan the whole blockchain
**\<cslashm>** holdon, deep search in paper on my desk
**\<dEBRUYNE>** Yeah, but that won't be necessary for 99% of the users :P
**\<cslashm>** 10 min for 20 000 block, but app in -0O and level 4 log
**\<cslashm>** wallet cli also in O0
**\<dEBRUYNE>** I see, that doesn't seem too bad tbh
**\<luigi1111w>** that is scanning by cli, not ledger, right?
**\<cslashm>** Its acceptable if you dont move in vacation for 1 month without refresh :D
**\<cslashm>** no wallet cli scan the bc but delegate all keyderivation/keyimage computation to ledger to no disclose the view key
**\<dEBRUYNE>** well, 1 month is 22k blocks give or take
**\<cslashm>** So for each block, device compute some scalmul and hash
**\<dEBRUYNE>** So that'd be 10 minutes wait
**\<luigi1111w>** you can't really use blocks
**\<luigi1111w>** you have to use txs
**\<luigi1111w>** are those current numbers
**\<luigi1111w>** what will it look like if usage goes up (which it historically has)
**\<luigi1111w>** I personally don't really see a lot of benefit for disclosing the viewkey
**\<cslashm>** yes for each txes. basically scan involves get\_key\_derivation and generate\_key\_image, those two op are done by the device. The rest is done by the PC as usual
**\<cslashm>** view key is so never disclose
**\<cslashm>** So, I need to leave. Be back on monday. you can mail, PM reddit or put githib issue if you need long tech desc
