I took it to mean, they would consider implementing it if they had support for the development work to get it up and running, or a complete solution developed by the community and that they could subsequently implement.
Given the importance of this I would hope it would be something the Foundation and Company would be keen to support (also Trezor et al. too)
I dont know if old Trezor would be able to support it (it does need 40 MB for private transaction which i dont think old Trezor has). As for new one, maybe.
No, it’s using delegated proving - i.e. offloading the proving to a more powerful machine so it doesn’t need to conduct the proof on the device but merely sign it. This is one of those breakthrough fundamental improvements with Sapling in that there is now a “proof authorizing key” so say a Trezor can hand off the proof generation and yet never expose the spending key (there is a loss of privacy to the computer doing the proving but that could be your own PC for example)
Your comment has made me realize that our terminology is too ambiguous.
“Proof offloading” means that the proving doesn’t have to be done by the party that creates the transaction.
“Decoupled spend authority” is the feature that Trezor would be using, where the spend authority key ask can be held separately from the other keys and used to sign spend authorization signatures.
(These names don’t roll off the tongue; they might be renamed.)
“Delegated proving” is an older term used in GitHub tickets (and maybe in some blog posts?) that I’d like us to stop using because it doesn’t clearly distinguish between those two cases. The difference is that proof offloading says that you move just the proving to a separated component, whereas decoupled spend authority means that you move just the spend authorization signing to a separated component (which also has to ensure that it is signing the right thing). You can do both!
Anyway, there will be a ZIP 305 that defines the recommended protocol: [ZIP 305] Best practices for hardware wallets supporting Sapling · Issue #346 · zcash/zips · GitHub
As noted on issue #3038, Ledger uses a memory model that might be tricky to accommodate with the libraries we will write for Sapling support. We’re writing those libraries initially in Rust, for use in the Android reference wallet, but they will have minimal dependencies and be usable on other platforms. We might also write a version in C if that turns out to be necessary for h/w wallet support, but it would be much less work to just compile the Rust version to the relevant microcontroller platforms. (Also, that approach would offer higher assurance, because the Rust code is memory-safe and because auditing effort could be concentrated on a single library.)
However, code for the BOLOS applications used on Ledger’s microcontroller needs to follow a memory model that restricts the use of pointers. Despite the terminology used on that page, this model is not standard PIC (Position-Independent Code). As far as I can see, that means writing C code specifically for Ledger, which would be quite a bit more work. (Although it might be possible to share a C library between Trezor, KeepKey, and Ledger, I don’t see how we’d compile a Rust one to the Ledger model.)
[Edit: yes, this documentation seems to imply that you need to use a BOLOS-specific toolchain, which does not have Rust support. Maybe it’s possible to swap out clang for rustc in that toolchain, but I suspect not because BOLOS normally requires source-level modifications to the C code, which rustc wouldn’t know about.]
“We’d welcome pull requests sent by the community enabling them” - Ledger CTO
“I’d welcome completed homework assignments from others” - Tiago, College Student
so is anyone going to submit a pull request? how do we get this done?
Just to set expectations realistically, this would probably be about a month of full-time work by a programmer or team with extensive experience in both cryptography and embedded systems, and has a dependency on the draft of ZIP 305 having been written.