search

ZcashFoundation / GrantProposals-2018Q2

Submission site for 2018Q2 Zcash Foundation grant proposals.
26 stars 2 forks source link

Zcash 'Sapling' standalone hardware wallet #1

Closed flathashedtree closed 5 years ago

flathashedtree commented 6 years ago

At this time of writing, Bitcoin gains more widespread use for day-to-day payment. We can buy clothes, we can pay electricity bills, we can visit the nearby coffee shop and pay with it. However, as Bitcoin is the gold standard; it is also like gold: heavy to use. Most shops accept Bitcoin through payment processors with bad user experience, increased transaction costs and online wallet providers are not really in the spirit of decentralized blockchains.

Existing hardware devices like Trezor or Ledger are more kind of a vault. And because Bitcoin or almost all other coins are not private; Zcash comes into play. Especially shielded transactions.

The 'Sapling protocol', would make it possible to build a lowpower device wich can leverage shielded transactions.

That is why I propose a little creditcard-sized device for OverTheCounter, day to day, standalone payments.

Features:

Besides the hardware, this project will also contain a companion webapp to manage and sync the device with the network. The companion webapp can be seen as a software wallet with the big exception that nothing is stored on the device and its only purpose is to view/create transactions and synchronize the hardware wallet via low proximity sound ambient light.

User experience:

It would make sense to sell those in packs of three. One for daily usage, another for backup and the third could be stored in a secure place. The companion webapp would do all the onboarding/introduction and can be used on almost all devices with a loudspeaker, microphone camera and a recent webbrowser.

This is still a draft and open for discussion. Feedback greatly appreciated

Concept page https://arcula.bitbucket.io

Voluntary-zcash commented 6 years ago

What price range do you anticipate? How long will it take to perform a shielded transaction? What if there are multiple UXTOs that have to be gathered into the payment - won't that take significantly longer? Is this device supposed with-hold private key data like existing hardware wallets?

flathashedtree commented 6 years ago

Low volume price would be about ~120 Euros, but will drop almost 50% if we do manufacturing batches in 10k quantities. That means low volume pure hardware cost without case etc is 60 Euro. So I aim to produce quality hardware with real leather as enclosure. This has a whole better feeling than let's say; 80 Euro for a plastic 'thing' or 120 Euro with a leather enclosure.

My guess for proof generation is 2-3 seconds. About the same time as with debit card terminals on average. I am optimistic that we can get to ~1 second maybe for simple 1-in-1out transactions.

We will know more once the specifications for sapling are complete ;)

All data will be stored on the device (private keys, commitments etc, everyting belonging to the spending key). I will also design tamper/theft protection for the flash storage.

The onboarding/setup experience should include a way to secure the spending key on paper or maybe a little seperate eeprom tag included with every device.

acityinohio commented 6 years ago

This is really cool to see @flathashedtree, thanks for the early submission and solicitation of feedback.

I'm having trouble walking through the concept page—do you think you could do a video/screen share walking through a typical flow via https://arcula.bitbucket.io ? No worries if not; I may be alone here, but knowing what you intend for the flow (and in particular for switching cards) would help me understand it a bit more.

flathashedtree commented 6 years ago

@acityinohio Nice to hear that.

I will extend the concept page to be more interactive.

The stack of cards may be confusing at first, but is really easy once you get the 'aha' effect. At the moment, if you have stack of 9 cards (more or less; depending on screen 'real estate') you just swap the position of the current active card and the card you selected.

If you have more; say 50, the stack begins to work like these rotating business card holders. For example: Array of cards = [0, 1, 2, ......., 49] Active card = 1 If you select the third card from the stack (ActiveCard, firstStackCard, secondStackCard....) which would be number 1 + 3 = 4; 4 is now the active card and 3 new cards will be appended to the bottom (in order of that array).

That whole design is also just an experiment. I have no problems to change it to whatever we see fit.

flathashedtree commented 6 years ago

@acityinohio I updated the page a bit. Regarding the mention of 'scan/codes', they will be like 'streaming barcodes' on the hardwallet, and the companion app does communicate to the device via rapid changing colors to be implemented later in the interface.

Let's say we have a 'transmission card' with a rapid changing color field in the companion app, the hardwallet will have an ambient light sensor on its back. You would put the hardwallet on the smartphones screen and voila, data transmission from phone to hardwallet via the phones display.

That way of data transmission is just for metadata though; the effective datarate would be ~100 bytes per second.

For anything else; streaming barcodes(for image sensors(camera), optical scanners) and self aligning(magnets) metal pads on the hardwallet for high speed serial communication(hardwallet to hardwallet, USB cable) - something like the MagSafe adapter.

acityinohio commented 6 years ago

Thanks for the update and UX explanation @flathashedtree, that makes more sense to me now.

Did you see this open issue regarding Sapling hardware wallet best practices from the Zcash Co? Might want to check it out and make sure your eventual design is capable of the list of features mentioned there: https://github.com/zcash/zcash/issues/3038

flathashedtree commented 6 years ago

The hardware wallet will fully support sapling, incl. proving/verifying. And also thermal and light random sources. However, a privacy issue is that the hardware wallet has to transmit the viewing key/keys to the app; which in turn has to query a service for new transactions with the key(s). That means we disclose sapling notes .

A good tradeoff might be the following:

(Oh, I recall); the project also includes infrastructure development ;).

flathashedtree commented 6 years ago

Ops, the silicon has 24 free running oscillators which seems to be phase shifted; instead of thermal random properties

mineZcash commented 6 years ago

I think this is a very cool idea, I would be interested in seeing a working protoype.

flathashedtree commented 6 years ago

@mineZcash Me too ;)

At the moment I play with the sapling-crypto/bellman repo and ported a great amount to ECMAScript (bellman/Groth16 still to go) and just started to evaluate performance improvements in my spare time.

I also want to experiment with circuit-on-paper (EcoFriendly!) via CNC laser engraving, ideally for this project.

Because prototyping is time intensive, I need at least 3 weeks full-time; which I do not have at the moment.

Design question for navigation pops up:

flathashedtree commented 6 years ago

FYI, I plan to use: https://octavosystems.com/octavo_products/osd335x-sm/

; which is a good fit. But if someone has a better inside tip, let me know.

mineZcash commented 6 years ago

I'm a bit of a computer geek so small electronics are interesting me. As far as prototyping goes: for the circuit layout it's much easier/cheaper to etch a PCB than Laser CNC. https://youtu.be/IXKwkcgimZI

(Note: my opinions about the electronics of this project are independent of how/if the project fits within the scope of the Zcash Foundations Grant program)

flathashedtree commented 6 years ago

Yep. But with a pitch of 1.27mm and a pad landing size of 0.5mm, superior etching is required and is still a bit of a hassle; at least last time I checked, and that was ages ago ;).

Normally, if I want to prototype a specific design, I design a bigger breakout board and let it produce. Turnaround times are fast and price for double sided boards is not expensive these days. But also that was different 3 years ago.

It is nice to read that you are interested in these things, if you want to experiment with simpler circuits/or circuits on paper: http://gmwgroup.harvard.edu/pubs/pdf/1075.pdf

That paper has some good information.

autotunafish commented 6 years ago

This is a cool idea and I hope the recent EU mandatory KYC actions regarding cryptocurrencies dont stifle this plan too much (seriously, really cool) Has it affected your planning?

flathashedtree commented 6 years ago

@autotunafish

I don't know why KYC rules could affect this project at all. Do I miss something?

autotunafish commented 6 years ago

No, that's good news, wasnt sure so I asked

flathashedtree commented 6 years ago

Revision: 1

Zcash 'Sapling' standalone hardware wallet.

Open hardware & software reference design.

Why

At this time of writing, Bitcoin gains more widespread use for day-to-day payment. We can buy clothes, we can pay electricity bills, we can visit the nearby coffee shop and pay with it. However, as Bitcoin is the gold standard; it is also like gold: heavy to use. Most shops accept Bitcoin through payment processors with bad user experience, increased transaction costs and online wallet providers are not really in the spirit of decentralized blockchains.

Existing hardware devices like Trezor or Ledger are more kind of a vault, not a nice experience for day-to-day or shopping journeys ;). And because Bitcoin or almost all other coins are not private; Zcash comes into play. Especially shielded transactions.

The 'Sapling protocol', makes it possible to build a lowpower device wich can leverage shielded transactions.

That is why I propose a little (smaller than)creditcard-sized device for OverTheCounter, day to day, standalone payments.

Besides the hardware, this project will also contain a companion webapp and a service backend to manage and sync the device with the network. The companion webapp can be seen as a software wallet with the big exception that nothing is stored on the device and its only purpose is to view/create transactions, synchronize the hardware wallet and other supportive actions.

Feedback greatly appreciated.

Concept page https://arcula.bitbucket.io

How

Hardware

42x73mm-sized device with leather as enclosure, dimensions are not final.

Visible parts:

Horsepower: https://octavosystems.com/octavo_products/osd335x-sm/

Additionally to the hardware wallet:

Software

Side goal: I also have a app for merchants on my mind, to make it easier for them to accept Zcash with the hardware wallet.

User experience

Onboarding: By opening the companion app, the user can start the onboarding flow which walks them through these steps:

Payment(s): Payment 'requests' can be made from the companion app. (Seller) The buyer has to unlock his/her hardwallet wallet and can either 'scan' the request with the ambient light sensor (hold/put) on the sellers display - or if the seller has the USB adapter connected, buyer connects his/her wallet to the self-aligning(magnetic) USB adapter. Payment request pops up on the hardware wallet which has to be confirmed by the buyer. After confirmation wallet computes the transaction and transmit it over to the seller; the companion app validates and broadcast it to the network and additionally displays a guess when the transaction will be confirmed or displays an error if something is wrong.

Payment requests/payments can also work from hardware wallet to hardware wallet. The transaction will be broadcasted from either party on next synchronisation with the companion app.

Emergency situations: The companion app should include a flow to walk the owner through best practices if the wallet is lost, or move/recover funds from the backup tag or from the written down encrypted spending key. (Actions from the onboarding flow)

The hardware wallet could also display statistics of spending habits. For example, 'You spent 0.47 ZEC in the last 24 hours. Equivalent to x EUR. Keep going ;)'.

Also, the hardware wallet should be able to consolidate transaction inputs to avoid congestion, manually by the user or automatically.

Security

Stages

Workpower

I have almost 12 years of experience with all kinds of digital, analog and software - development. My primary specialty is embedded hardware and software design.

Along the way, I also would work together with friends/collegues/maybe other contractors on this project for enclosure and design-/user experience.

As I have a habit for switching pseudonyms, information about my identity and the persons involved are available via selective disclosure for the commitee/foundation.

Budget

A rounded down sum of 145k USD total. It is possible to disburse the sum in parts, according to progression.

Other things

flathashedtree commented 6 years ago

FYI; After some chatting with friends, it may be possible eradicate the 24k contractor budget, because I know one who is good at that and available if I plan it at least 7-9 weeks in advance. The security buffer would be adequate for that option.

tromer commented 6 years ago

Is there any meaningful work that can be done on a significantly smaller budget, that can be a first step towards full hardware production by you (or others)?

flathashedtree commented 6 years ago

Yes, we can develop the reference firmware and companion app only, for a open reference platform with hardware/interface guidelines.

This will cut 300-400 hours (about 30k) and the external contractors- and parts budget.

We can cut this proposal also into chunks. Let me know what is most important for you.

tromer commented 6 years ago

The Zcash Foundation Grant Review committee has reviewed your pre-proposal, including the above discussion, to evaluate its potential and competitiveness relative to other proposals. Every pre-proposal was evaluated by at least 4 committee members .

The committee's opinion is that your pre-proposal is not a leading candidate for funding in this round, and the committee therefore does not invite you to submit a full proposal. This decision is advisory, and you can still choose to submit a full proposal by June 15th, following the detailed structure described in the Call for Proposals. Note that if the full proposal is substantially the same as discussion so far reflects, then it's unlikely to be chosen for funding; and if it isn't, then we encourage you to post a draft (or at least answer any open questions) as early as possible, to allow for community feedback. Regardless of your choice, we thank you for participation thus far.

flathashedtree commented 6 years ago

One possibility for a meaningful project on the lowest budget I can think of is the implementation of the open firmware.

Goals:

I think it is feasible to do in round about ~320 hours; 27k USD.

flathashedtree commented 6 years ago

^Ping;

Any feedback on that matter?

I have to re-arrange my time and like to hear some final recommendations.

In any case, for questions or other things, contact me at protonmail.com

Thanks.

sonyamann commented 5 years ago

We're wrapping up this round of the Grants Program, and no further discussion is expected on this issue, so I'm closing it. Thank you!