---
layout: post
title: Logs for the Hardware Firmware Meeting Held on 2018-01-12
summary: Discussion of the firmware for the dedicated hardware wallet and a discussion of Ledger's approach
tags: [dev diaries, crypto]
author: dEBRUYNE / fluffypony
---

# Logs  

**\<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 :)  
**\<hotoatmeal>** jbdatko: https://github.com/monero-project/monero/pull/3095  
**\<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.  
**\<i-a>** https://www.microchip.com/wwwproducts/en/CEC1702  
**\<i-a>** this is it \^  
**\<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>** https://github.com/monero-project/monero/blob/master/src/crypto/crypto.cpp#L127  
**\<luigi1111w>** if you can match that  
**\<m2049r[m]>** ok - like the operation need to make a public key out of a secret key (eg. viewkey)?  
**\<luigi1111w>** yes  
**\<luigi1111w>** that includes a conversion from fe to bytes at the end  
**\<m2049r[m]>** i can do that. need to add time measuring stuff.  
**\<m2049r[m]>** will do that tomorrow and get back with results.  
**\<luigi1111w>** cool  
**\<luigi1111w>** might as well do arbitrary base too if it's not much more work  
**\<luigi1111w>** https://github.com/monero-project/monero/blob/master/src/crypto/crypto.cpp#L127  
**\<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