Proposal description
The following description is a shortened version of the full project proposal. Click the link to see the full proposal as PDF:
https://www.haenel.me/files/dash-wallet/proposal-the-dash-hardware-wallet.pdf
Summary
Dear Dash community and masternode owners! My name is Roland Hänel, and the proposal I’m putting forward today is about creating a hardware wallet for the Dash ecosystem.
(design prototype, not finished product)
Hardware wallets available today (products like Trezor, Ledger and Keepkey) do their job mostly well, but I believe the Dash community should own the best hardware wallet. So, I propose to create a new hardware wallet, specifically designed for and branded for Dash: the Dash Hardware Wallet.
The Dash Hardware Wallet will support Bluetooth LE and thus be compatible with not only any current PC/Laptop (as the other products on the market), but also with wallet software on smartphones and tablets. It’ll be the first solution on the market that allows the safe storage of Dash on a mobile device. In my view, this feature alone justifies the development effort. But there are numerous other features as well…
Who am I / Who is the team
My name is Roland Hänel, I’m the VP of R&D at Q-loud GmbH in Germany, a company that designs, builds and operates “full stack solutions” in the IoT space. My team and myself design and implement embedded hardware, gateway nodes and cloud software stacks. I studied Electrical Engineering and Information Technology and received my MEng degree from the University of Technology in Aachen in 2001.
On the day I defended my thesis I also sold my startup company to QSC AG, Germany’s biggest DSL network operator at that time. I eventually stayed with QSC and helped building the nationwide DSL network, later the all-IP and VoIP networks as the head of the Network Design department. When QSC later decided to move into the Cloud and IoT business, I took over responsibility for development activities in this area, which is now Q-loud GmbH (https://q-loud.de).
As an individual, I have followed the blockchain technology area with growing interest over the last years. However, I have to admit that I learned about Dash only a couple of months ago. But what I learned is definitely what sparked my interest, because in my opinion the goals of Dash are exactly the key points of what matters: create an instant, private, secure money that everyone can use. Just as simple as that. Don’t focus on whether your signatures are put in the first, middle or last part of the block. Don’t focus on scripting stuff to help people build thousands of other coins on top of the system. Just put a decentralized, digital cash in the hands of the people!
Why is a hardware wallet needed?
At the core of any reasonable crypto currency, so with Dash, you hold the money you own, not a bank holds the money. This is done through your ownership of your private keys. These we have to guard like the banks guard the money given to them right now. We can argue whether the effort that the banks put into this task is appropriate, but I think we can agree that with crypto currencies right now, just putting the private keys on your smartphone is not really the appropriate way if it is more than a couple of Dash.
A hardware wallet stores the private keys and will never give them away (except for backup purposes, typically to be written on a piece of paper by the user in form of a recovery sentence). All processes that need to be performed using the private keys (e.g., sending Dash to someone else) happen on the hardware wallet itself, and the user needs to confirm these transactions on the hardware wallet.
Why do we need another hardware wallet?
There are products on the market already!
A hardware wallet is – in theory – the perfect solution for a reasonably secure storage of your private keys. However, the hardware wallets available today are mostly complicated to use or technically inadequate for the task. They are primarily designed for those who hold 10’s to 1000’s of BTC and use a PC to manage their funds occasionally.
What about a hardware wallet suitable for everyday use with your smartphone, tablet and PC? Maybe a device that can even be used at Point-of-Sale installations without any smartphone? Hardware wallets available today feature a PC connection via a USB cable. This is nice for stationary use at home, but useless on your iPhone because it doesn’t have a USB port.
The Dash Hardware Wallet will be based on Bluetooth, and thus practically be compatible with any modern device sold on the market. Bluetooth is ubiquitous today, every smartphone, tablet, notebook and even most desktop PCs have this technology built-in.
With the Dash Hardware Wallet, you don’t need to carry cables any more: Just use your Dash wallet on the smartphone (like today without a hardware wallet), and if you need to send out a transaction, you perform the final “confirmation button press” on the hardware wallet instead of your smartphone display. That’s it. All communication between the smartphone app and the hardware wallet happens in the background.
The Dash Hardware Wallet aims to be
- the only hardware wallet on the market which is really compatible with smartphone and tablet use cases, due to the use of Bluetooth LE
- a specifically branded hardware wallet for Dash, with support for the unique Dash features (PrivateSend, InstantSend, new Evolution features). Not just another hardware wallet where Dash is integrated as “some altcoin”
- properly designed for mass market manufacture, so it will hit a retail price point below the competitors even though being a technically more complex solution (Bluetooth)
What does Dash get with this proposal? What do we deliver?
I propose the development and mass production of a new, specific hardware device: The Dash Hardware Wallet.
The hardware features:
- physical size roughly 45mm x 25mm x 90mm, see picture for size comparison with a 2€ coin (nearly the same size as a US Quarter coin)
- rugged,spill-proof (at least), yet nice-looking ABS housing/enclosure, possibly with a decorative TPU (“rubber”) sealing)
- powered by house hold type batteries (current planning is 3 * AAA). Design goal is to offer 1-2 years (!) of battery lifetime
- communications interface: Bluetooth Low Energy (BLE)
- reasonably sized TFT or OLED display (prototype has an PMOLED type display)
- PIN pad to unlock / authorize transactions
The software (firmware) features:
- a hierarchical deterministic (HD) wallet, compliant to BIP32/39/44
- the very first implementation of a Bluetooth LE profile for crypto hardware wallets (“GATT profile”)
- support for specific Dash features (PrivateSend, InstantSend, Evolution features)
Basically, imagine the following use case together with the Dash smartphone app: Just launch the app and watch your funds as usual. If you just receive funds, no need to even take the hardware wallet out of your pocket. If you send funds, do everything in the app as you’re used to. Then, as a last step, take out the hardware wallet, verify the destination address and amount on the screen. Enter the PIN on the hardware wallet’s keypad, press the Dash button: done.
Bluetooth will enable a much, much better user experience than all solutions based on USB connectivity. It furthermore allows the device to be hermetically sealed and thus more rugged and less susceptible to all types of “electrical attacks”. Bluetooth might even enable further use cases, such as connecting the hardware wallet directly with a Point-of-Sales terminal. Imagine you want to pay your coffee at Starbucks, just take out your hardware wallet, the screen shows the merchant’s address and amount, you enter your PIN and that’s it. Sure, the same thing you could already do on your phone today, but this will never be really secure!
The proposal includes a 3-phase project, including professional hardware design (“design for manufacture”, not some breadboard-style prototype), certification/testing, production setup and a first mass-market production batch. After some research and discussion on the Dash forum with a pre-proposal, I decided to split the project into 3 phases to increase accountability on our side, while still preserving the chance to bring this product to mass market success.
Enough talking, do we have prototypes?
After some discussion with the pre-proposal (to be found here: https://www.dash.org/forum/threads/pre-proposal-the-dash-hardware-wallet.16609/) we created a first hardware prototype. Thisprototype comprises a custom hardware design (PCB Rev1) with a Bluetooth LE SoC (system-on-chip), a ABS housing with TPU rubber seal (prototype 3D printed derived from an existing product, no injection mold tool was created for the prototype). Basic software (firmware) integration was done to verify the hardware and all essential functions work (display, keypad, BLE communication, power circuitry).
(PCB prototype (3D model), battery holder. Note: finished product will most likely have 3 * AAA cells.)
(PCB prototype built + assembled. This still uses an off-the-shelf keypad (final product will use a custom designed keypad). 1.3-inch PMOLED display, the black bar is an artifact of the PMOLED display scan and the photo camera shutter, not visible to the human eye.)
(3D model of the printed circuit board (PCB) fitting into the housing. Housing is still a derivative from another product, will be further customized/improved for the final product. Dark grey parts are high-quality ABS plastic, the blue part is a TPU rubber holster (also serves as a seal).)
(Actual housing (partly 3D printed), take the hand as a size reference. Front plate (display, keypad) still a mock-up in this prototype version.)
(PCB assembled into the prototype housing. Again, imperfections in the display due to the PMOLED line scanning (not visible in the real product). Front plate still a mockup, but hardware is fully functional in this form factor. For the keypad, a custom tool needs to be made.)
For more prototype pictures, see the full PDF version of this project proposal:
https://www.haenel.me/files/dash-wallet/proposal-the-dash-hardware-wallet.pdf
Technical details (what will we do with the funding)
As already mentioned, this project comprises 3 phases, each of which will be applied for in a separate proposal.
Phase 1 includes hardware and firmware development activities:
- Hardware design (schematics, PCB, BOM, ...), testing & verification
- Build of various prototypes (for development only)
- Define+ Verify Bluetooth LE API for relevant crypto function (wallet initialization, receive, send, …)
- Implementation of the Bluetooth LE API for crypto functions on the target (KW41Z)
- Generic firmware development, including secure update feature (via Bluetooth LE)
- Hardware design verification (FIT, MTTF, also including EMC pre-testing conducted in house)
- Prototype implementation of device within the Dash Wallet for Android and/or Evolution wallet
- Projectmanagement, documentation, status reports
- Design of enclosure (3D modelling), verificationusing 3D prototypes (STL, vacuum casting)
After phase 1, we will have a fully functional product in both hardware and software (firmware). Hardware will be verified and tested in-house, software will be tested and verified against at least one existing software wallet (i.e., Dash Wallet for Android or Evolution Wallet if that’s available by the time we are in Phase 1). The enclosure/housing will be polished looking, but still be made from prototype tools.
This proposal is for phase 1. Phase 2 and 3 have already been planned, for details of the work packages of these phases, refer to the PDF:
https://www.haenel.me/files/dash-wallet/proposal-the-dash-hardware-wallet.pdf
Financial details
Phase 1 applies for a funding of a total of 1,029 DASH, over a period of 3 months (343 DASH per month).
For a detailled table of how the funds are allocated to the work packages, please refer to the PDF:
https://www.haenel.me/files/dash-wallet/proposal-the-dash-hardware-wallet.pdf
Timeline
We estimate thefollowing timeline for the project
- Phase 1: starts 3-4 weeks after project funding (we need some setup time to make sure enough team members are available to schedule work efficiently), will take about 3-4 months
- Phase 2: 2-3 months (mainly depends on injection molding tools)
- Phase 3: 2-3 months, but first devices available after 2-4 weeks
Each project phase will individually apply for funding through the Dash treasury. We will only apply for funding of the next phase when we’re 100% sure that we have met all goals of the previous phase.
How we’ll document project progress and handle status updates
During the project, we will release regular status updates and project information, at least monthly. We will do this through a web site / blog specifically created for this purpose.
We do this because we believe we must be transparent to the Dash community who funds our work. At the end, we also want to continue with the next phase(s) of the projects, so we need not only to deliver results, but also spread the word about them.
How we’ll handle overfunding and/or underfunding
Given the volatility of the DASH/USD exchange rate, it is very difficult to plan a big effort like this project and apply for “just enough” funding. We have taken a 120-day average price for the Dash in USD (see financial table).
We will convert the Dash received from the network to USD as needed to cover our expenses throughout the project. Any excess funds (or any insufficient funds) will be carried over to project phase 3 and we’ll adjust the amount of Dash we apply for in phase 3. If excess funds of insufficient funds happen in phase 3, we’ll try to adjust the number of devices in the production run to match the funds that are available to us.
Why do we go for 10,000 devices in the first production run?
Isn’t that too much? Or isn’t it too risky?
Hardware design projects are comparable to software design projects in many aspects. However, they also have some aspects to them that are not obvious if you look at them for the first time. Software can be replicated practically without any cost associated to it, so if we develop a smartphone app, rolling this out to any number of users is easily and instantly possible.
With hardware on the other side, we’re designing for a specific production quantity from the start. You design completely differently whether you expect to produce some hundreds or some ten thousands of your products. This includes the selection of tools for the housing (3D printing vs. machining vs. injection molding) as well as the selection of manufacturing sites (US/Europe vs. Far East), choosing off-the-shelf vs. specific components, etc. pp.
We think that it makes sense to create a product that fits the mass market. 10,000 devices are generally considered the “start of mass production” for consumer-like devices. This quantity is desirable and necessary to get the price down in manufacturing.
We aim at a retail price of $45 (plus tax) of the finished device. This is below all relevant competitor products on the market right now, even though the Dash Hardware Wallet has more complicated hardware to it. However, this goal is perfectly achievable.
It is self-evident that we won’t start a 10k production run in phase 3 without making sure beforehand that this will run smoothly, or at least with minimal issues that can be fixed along the way. The work and expenses necessary to ensure this are included in phase 2 of the project. My team and myself have created complex industrial control solutions that only run in batches of 100 pieces as well as consumer electronics devices that run in batches of 100,000 units. We have successfully dealt with European (RED directive) and American regulatory bodies (FCC, IC). We know what to source in Far East and what to source in Europe or the US. We are certain that we can pull this project off as we have successfully completed many similar projects.
Phase 3 yields 10,000 devices, to whom do they belong?
They belong to the Dash network, because – given that phase 3 was funded by the network – they were paid for by the network. Since we can’t send a bunch of pallets with boxes to a decentralized network, we have to come up with an idea how to distribute the devices.
We will provide devices free of charge (*) to
- any developer that is working on some sort of wallet (smartphone app, desktop software, …) that wants to integrate Dash and use the Dash Hardware Wallet. Applies to a couple (5-25 devices) depending on the needs of the project, number of developers/testers etc.
- any DASH event (e.g. trade show, conference, meetup, hackathon, …) that was wholly or partly funded through the Dash treasury and intends to use Dash Hardware Wallets as giveaways during the event. They should apply for a reasonable amount, which ensures that one person doesn’t receive more than one device as a giveaway.
- any creator of an approved (funded) Dash proposal who clearly includes a statement like “I want to receive XXX amount of Dash Hardware Wallet devices” in the proposal.
- if we’re unable to clear out the stock until 1 year after production, we will ask the Dash Core Team to take over the remaining devices. If they don’t want them, we might decide to do whatever we deem most appropriate (e.g., sell the devices on Amazon and donate the profit for charity, …). This point is only to make sure we’re not forced to sit on a stockpile of hardware forever.
The above terms were invented to enable others to get the devices, not to put us into a position where we have to judge who is “worthy” to get some. Any request will be handled on a first-come-first-served basis.
We will actively encourage the use of the firstproduction batch devices as giveaways, for example by reminding Dash event proposal makers that we have these devices and they can get them for free, as outlined above.
How does this fit into Dash Evolution?
Taken straight from the Evolution web page: “Evolution’s mission is to make digital cash easy to use and access for all users, even those who aren’t technologically savvy.”.
The Dash Hardware Wallet fits perfectly into this vision. Today (October 2017) it is difficult for us to assess what Evolution is in technical detail because the Alpha isn’t released yet. But we certainly plan our make our best effort to make the Dash Hardware Wallet fit into the Evolution framework.
Besides from release our code as open sourcewhen the project is finished, we’ll disclose anything as soon as it is created to the Dash Core Team to enable integration of the Dash Hardware Wallet as soon as possible.
Will the Dash Hardware Wallet support other coins?
Will we make the project open source?
During the discussion of the pre-proposal, it became obvious that this point is somewhat controversial. Some end-users obviously prefer hardware wallets that can store whatever coins they have. On the other hand, since we apply for funding by the Dash network, it seems unfair to funnel money into activities that will might mainly benefit to BTC or ETH holders.
In addition, we have to recognize that as with most (or all) of security-related products, being open source is generally considered to increase overall security, because it’s easier to be audited, verified, criticized (in a positive sense) when the code is freely available. While this was not the standard in the Hardware industry, I strongly believe that we should adopt this approach.
In respect of all the different aspects, we have decided to go with the following procedure:
- We will open source all the major development results, especially the hardware schematics (“circuit design”) and the software/firmware source code, preferably under the MIT license. If this is not possible due to copyleft effects of some GPL component/library, we will use the GPL license.
- Release of the schematics / code will happen after the project is completely finished (after phase 3). This will ensure that all the results are open to the public while still giving the Dash community a “head start” over potential “copy-and-paste” solutions.
Note however that even though all construction designs will be open source, it still won’t be trivial to “copy” the product, because the production setup and tooling required for the Hardware side requires significant time and effort, even if one has all the plans at hand. - In the (hopefully very unlikely) case that the project must stop because a subsequent phase is not funded, we will release all results created so far immediately.
- The hardware will be branded as Dash, similar as outlined in the pictures in this document. We will use a Dash color scheme, and the “OK” button will carry the Dash symbol.
- I myself as well as the Q-loud team will not implement support for other coins into this product, not within the project (or the funds allocated to the project), and also not in form of some “side project” during the project.
- As soon as we release the construction designs as Open Source, obviously anyone is free to whatever they like as outlined in the applied license (MIT, possibly GPL).
- We will not use the tooling (injection molding tools, production test tools, …) created within the project to produce any other product. This is independent of the Open Source issue, because the tooling is a physical thing not governed by Open Source licenses.
What are the short-term benefits?
Short-term benefit is that we have 10,000 devices, nice and shiny at our hands. They will serve as perfect giveaways and marketing material at any “physical attendance” type of event. Experience has shown that if you give away hardware, this really engages users. Press coverage is also much easier to get if one has a new gadget instead of “just a new app”.
The Dash treasury has funded several expensive advertising campaigns in the past, we think it’s also time to take a fresh approach here. Imagine giving away such devices at a Bitcoin conference: guess what all people will be talking about in the coffee breaks?
What are the long-term benefits?
We envision that the Dash Hardware Wallet will play its role in the evolution of the Dash network towards a user-friendly, easy-to-use digital cash.
The use of Bluetooth technology, which is ubiquitous in embedded devices today will enable more use cases in the future. In addition to the “smartphone companion device” which the Dash Hardware Wallet will be when first launched, it’s perfectly possible for the wallet to communicate directly with a point-of-sale (PoS) terminal, possibly verifying and signing a transaction completely without a smartphone involved (and thus without the need for Wi-Fi or cellular network connectivity on the smartphone). We hope that once the hardware is available, other developers might be encouraged to look into these kind of use cases which would otherwise be difficult to assess for them. We will support these efforts by providing them with the information needed to effectively use the hardware platform for their development needs.
Closing words
It is obvious that the nature of this proposal is somewhat different from the majority of other proposals currently funded through the Dash treasury. Instead of directly funding advertising or marketing activities, this proposal contains significant development efforts. As an engineer and engineering manager by heart, I hope that a proposal like this gets funded, because in the end, this is a chance to create technical innovation and really make the Dash ecosystem better.
I am fully committed to make this product a success, and I hope it has become obvious for the reader of this document that significant effort was put into the preparation, prototyping and planning of this project. Please support this proposal and give my team and me the chance to make this a success. If you have any questions, feel free to comment this proposal here, or send me an email.
Thank you,
Roland Hänel
roland@haenel.me
The above description is a shortened version of the full project proposal. Click the link to see the full proposal as PDF:
https://www.haenel.me/files/dash-wallet/proposal-the-dash-hardware-wallet.pdf
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
2) It's to big, the should be more portable
3) 10.000 for a first batch is way to large, make a 100 or so as prototypes or something first
4) These units still cost 90 dollar a pop, not something we should give away for free
*sidenote, maybe dash-labs, can focus on for much cheaper price, or another DAO could set this up spend 1,2 mil on just the first 10.000 units is allot of money, maybe keep it in house ?!?
You might want to read the section "Why do we go for 10,000 devices in the first production run? Isn’t that too much? Or isn’t it too risky?" in the proposal which addresses our thoughts why we think it doesn't make much sense to run a professional development for small-scale prototypes.
It's not my or my team's core competence to organize such a giveaway. But if someone would decide to do that, it's possible: that's why we included the rule "we give away the devices to anyone who gets a proposal approved by the Dash network". So just create a proposal (small amount just to cover your costs, could be some 10 Dash), if this passes, we'll hand out the devices.
But I fear that it doesn't look that great for this proposal in the first place. Anyway, not it's up for the vote, I don't call it a day until the voting is finished.
For details, you might want to read the section "Why do we need another hardware wallet?
There are products on the market already!" of the proposal.
Okay, my point is that you may be right that the product you're proposing doesn't exactly exist right now, but there is a long-established, tried and true product, that is quite close. If we wait six months I bet it'll be available, and the Dash Treasury won't be light $1.25 million. Just my assessment.
You asked where I'm located on the Q-loud site, I fear I'm just not located there. I'm the guy in charge of R&D, I try to stay away from the pure marketing stuff. However to ensure you that this is legit, you might wan to have a look at the German "Handelsregister", which is the official register of companies. I'm listed there as a registered general manager (German PPA = "Prokurist", officer with statutory authority)
https://www.northdata.de/Q-loud+GmbH,+K%C3%B6ln/HRB+88029
If it does not work out, maybe you could consider making a smaller batch for those that want to participate
and create a donation campaign for it....
I will only propose what me and my team can do best. There are other guys in the industry that can probably deliver some 100 "very polished prototypes" for some $100k. But that's not the game I'm in, because I think this only creates shiny things without long-term benefit. Yes, big companies like Apple do such things because they can and their follow-up business is so large that it justifies near to anything in terms of prototype development cost. But for Dash that doesn't make sense in my opinion.
The only thing that I really didn't like is us being double charged, both a high rate for work. And then also charged for the product. Normally it's one or the other.
Unfortunately, what you would like to have is $500k for the complete development, certification, test, production and shipping of 10k devices. This means $50 per device including all costs for a more or less from-scratch development effort. As someone who has managed numerous similar projects, my answer to that is very straight: completely illusional, there's no way to do that.
I could write down a couple of good reasons why, but I think the arguments been exchanged enough.
For me, my reputation as a professional product designer who can deliver on what he proposes is much, much more important than to push a project to the door that later falls short of its objectives.
The company here in this proposal is charging 1150$/day. These might well be close to costs in Germany but in my opinion it's not fair for many hard working developers doing 12 hour days for a small fraction of that. A lot of us are either working at reduced rates and some even for free because we really believe in the projects we do and want to take as little as possible while giving back as most as possible.
I also find it's very deceptive that the proposal owner makes a multi-month plan that comes to ~1000 DASH and fails to mention that we get nothing without phase 2 and 3 (and value dash at only 244$, who uses 120 day averages?).
Hence the total project will cost 4198!!!! DASH or 1.25Million dollars. This is plainly ridiculous. To add insult to injury they say each device will cost about 18 euros to make, but after we have funded everything they also sell back each device to the masternode network for 45 euros.
Because of all of this, I'm not even sure the software could even be trusted. I know I wouldn't use it.
However, parts of your answer sounded somewhat unfair, maybe even insulting to me. But I've calmed down somewhat, and will try to answer as short and concise as possible, and also without and intention to offend you.
The daily rate you cite is correct. And yes, that's a very common rate for a professional design team in countries like Germany (and also the U.S.). Yes I know that costs in other part of the world are different. I accept that, but I can only offer the setting that I'm in, and that is top-quality professional work for this rate.
Calling my proposal a deception is not acceptable to me. The proposal repeats over and over again that the project has 3 phases. Costs are clearly structured. Tasks and results of all phases are clearly described. This proposal is clearly marked as "phase 1". The proposal description clearly says that there will be one proposal for each phase. Sorry, I had a look again myself and I don't see where I could have done better.
Your claim that "we get nothing without phase 2 and 3" is just plain wrong. The opposite is true. The proposal clearly states that "In the (hopefully very unlikely) case that the project must stop because a subsequent phase is not funded, we will release all results created so far immediately". From the context of this sentence, it is clear that "release" means that we will release all the results as open source to the public. Furthermore, I have stated that all toolwork which might exist will not be re-used for any other purpose. What more can you expect?
It is not correct that "each device will cost about 18 euros to make". If you look at the financial details (which you did, thanks again for doing that), I stated that COGS (cost of goods sold) is planned to be $18. Then you have to add final assembly, packing, shipping of parts, shipping to country of destination, import taxes, loss/damages, ..., ... In the end, the company producing the product will make an absolutely normal retail cut on the product. This is not something you should blame them for, it's the usual thing. Please ask someone who has experience in hardware business. retail price = COGS * 2.5 is not "plainly ridiculous".
In the end, I admit, this proposal does not include "working for free" (well, except al the work we did creating the proposal). If that's what you expect, I'm sorry. But I dearly ask you to not call my proposal and my work a "blatent cash grab" or "plainly ridiculous". I don't think I deserve that.
Anyways let me go over your points: 3 Phases -> Yes you said so very clearly in text. However I doubt many people read the actual pdf. You are asking for 3 months of payout, and say there are 3 phases. Many people might think that each month is 1 phase and think the whole thing would cost 1000 DASH. Remember that 90% of MNOs are very busy (me incl) and don't have time to analyze proposals. I did it because I originally voted yes and then people that I trust were giving bad feedback.
Open sourcing the project isn't good enough after 300K usd is payed out as that will do very little for us. Only if someone else decides to take things over. There are so many variables that could go wrong here and if they do then the masternode network is left with practically nothing.
Ok 1150$/day + 19.6% tax. That's really a lot, I would say about 30% more than I would expect. We are living in a world economy here on the governance system. I don't care where you are. I do care about your level of professionalism and work ethic, that I can see in the work you have done so far but it's not enough for me.
"Then you have to add final assembly, packing, shipping of parts, shipping to country of destination, import taxes, loss/damages" Seriously... in this proposal you also say that recipient may pay for shipping. You can't pay import taxes either, unless you are going to refund people who pay at the border, and I can inly imagine the nightmare that would become. Loss/damages -> reship another one, we have 10K. And final assembly means what? Putting it in a bag? To me COGS includes cost of assembly.
Retail price -> Yes retail price should be COGS * 2.5 (or even a little higher). However here you are basically on contract from the masternode network and getting paid 1370Euros/day, you are not working as a company trying to sell a product and make money off that product. If anyone should make money off the actual product it's the people who contracted the work. This is why it's ridiculous.
I'm not asking you to work for free. But to me there is a spectrum. Working for Free <-> Working at reduced rate <-> Working at normal rate <-> Working at slightly elevated rate <-> Trying to find loopholes to charge excessive rates. You are really in the last category in my opinion, if you were asking money from a fellow German company maybe they would go with it, or maybe they wouldn't but I don't think they would tell you their reasoning. I really hate having to write my reasoning like this as it comes off as insulting, and I can tell you have already spent a good deal of time on this, and I feel bad about that.
I was initially rooting for this proposal as well but changed my mind. I could change it again but I'd have to understand your cost justification better.
Apparantely i am one of those many people, because i indeed overlooked the combined costs for all three phases. Which means i also have to reconsider this budget proposal.
Probably it's simply not possible to write a proposal like this without any potential of misunderstanding if one only spends 15 minutes reading through it. But this is just due to the complexity of the matter, not because this is a carefully crafted proposal to fool you into something bad. I didn't design phase 1 to last 3 months only just to create a confusion between this 3 months and three phases. Phase 1 lasts 3 months because the development time is estimated 3 months as written in the proposal.
I won't argue about wages or daily rates, my point is that this is adequate payment for a professional result, if you come to the conclusion that this is not the case in your opinion, that's fine for me. To help you with your final decision, let's squeeze this into 3 numbers: for $1M, you get 10k professional Bluetooth hardware wallets, developed, tested, certified, produced, delivered. That's $100 per device including everything. After that, $45 (retail) per device. If you think that's ridiculous bad value, vote no. If you think that's great, vote yes. I have respect for any decision.
I think that within phase 1 you should provide:
- a client application (for making transactions) for: Mac OS, Windows and Linux
- a well documented API libraries for Python (2 and 3), JavaScript (must have) and C ++ (nice to have), to help external software creators implementing support of your device in their software. I think you should include this in your budget as the costs will be rather substantial.
As for the Bluetooth Low Energy interface, I'm afraid, that unlike USB this interface is not a standard equipment yet in both mobile phones and computers (especially desktops). To avoid cutting off a large group of potential users, you might want to consider adding a USB interface to your device, otherwise your device will be dedicated mostly to mid/high-level smartphones and laptops.
In fact, standardisation on the API layer *is* part of the proposal. Since this device is a Bluetooth LE device, the layer used for defining the API is the "GATT profile". Essentially, this is a tree of "key/value" pairs (very simply put) that you can read from the host (smartphone/tablet/PC). With an Android or iOS device, you have all the APIs from the operating system to directly access the attributes within the GATT tree, so you don't need any other layer of software in between. This is the usual way to expose an "API" on a Bluetooth LE device.
As for the client application, we included a "reference implementation" within phase 1 (see detailled proposal). But yes, this is more intended to be a reference (and validation point). We do not intend to produce client software for any operating systems out there. This would add much additional work to the project (as you already stated). We believe that we need adoption from the software clients out there ultimately. Yes, it is a risk that this might take some time, but in the end, it doesn't make sense to reinvent the whole wheel here.
I think adding a USB port to the wallet doesn't make sense. Yes, some desktop computer and even a very, very small percentage of notebooks might not have Bluetooth. But then, there' good products out there (Trezor et. al.) that work for these end devices. In this respect, I agree with tungfa, as a USB product, the differentiation point to existing products isn't big enough to justify the effort.
If you want to encourage creators of external apps to support your device (and not provide excuses for them), you'll need to provide a high-level API that expose the most important features from the device's purpose perspective, that hide all lower level stuff. In this case it would be functions: get_address, sign_message, prepare_transaction, etc.
As for limiting communication methods to BLE without a USB interface or Bluetooth 3 - I think that it could seriously narrow down the group of potential users.
This is a bit expensive project, so it deserves to take care of the details, which in the end result decide whether the device will be useful or will end up on the shelf covered with dust, but it's just my subjective opinion and I may be wrong.
1) This guy named Roland in the forum seems to have a better idea about the hardware. Maybe they should collaborate? To echo my previous comments, I think this is a solution chasing a problem which equals startup failure? My question is:
Q) Are the stakes high enough yet, to warrant our own proprietary hardware solution? If not, then at what market cap does that make sense 1.5T?
2) I think there are cheaper solutions that might offer the same level of security beyond devices like trezor? I like what Fuzo and Rivetz are doing with sim cards and Intel's trusted execution environments.
3) I like the idea and I like having a plan already in place. However, I am not an expert on formally verified hardware and maybe I need more education on where the Trezor falls short.
1) This guy named Roland in the form an me, the proposal owner, are one and the same person. So unless I have a split personality, which I hope I don't have, we collaborate just fine.
2) The target of the proposal is to have a $45 device. I think that's pretty attractive. However whether a $45 device is worth the money is of course to the judgement of the user, not mine.
3) Only to make this clear: this is not formally verified hardware. Nor is it possible to create a product like this which is in itself formally verified. Formal verification is something you can apply to gates in an IC (like some VHDL or Verilog design). Not something you can easily apply to a whole product in a carton box. Neither is the Trezor or any other existing wallet formally verified, nor do I propose such a thing.
But... Is there any way to make it smaller? Your dimensions (45mm x 25mm x 90mm) seem HUGE... that's almost 10x bigger than a trezor (60mm x 30mm x 6mm). Also no offense but the prototype looks very ugly... almost ugly enough for me to vote no.
But still voted yes, not just for this project (which looks good except for being ugly so far and too big), but to incentivize more open source hardware-like projects like this in future.
We'll try our best to improve the prototype enclosure. However we really want to stick with the full keypad, I know a keypad isn't the most beautiful piece of art, but it's just so much more convenient to use a full keypad to enter a PIN compared to playing some find-my-mouse-pointer game.
What puts a challenge to us is we have to fit batteries in the product (which USB devices don't have). And I don't want to charge the battery every other week, I really want it to last (> 1 year).
But as I said, we'll try our very best.
We apply for funding with the Dash treasury because at the moment, it just doesn't seem economically feasible to run such a project on our own. Eventually someone will do a Bluetooth wallet, no question. With funding from the Dash network it will have specific Dash branding and features. If funded by someone else, it will have Bitcoin and Ethereum support in the first version (because if you're looking for sales figures, guess where you go first).
I have a weird and ignorant question. I am wondering how you as a manufacturer and we as consumers can verify no recording / spying abilities are added to the device. This is an ignorant question I have of Trezor as well. What if there is a keylogger or something in there, can you tell? Can "normal" people check the security of the device? The board looks simple, and I assume you can trace / see the circuits and verify they're per design and I hope you will know, but how do outsiders verify that your work is on the up and up? LOL. Sorry, but this question keeps coming into my head re: trezor. I'd rather trust you than not, so this is out of curiosity.
Also, what happens when the first 10,000 are sold, do you start production and sell for yourselves? Make improvements and support the device? I would hope so, and I wouldn't care if after the first 10,000 are finished if the device upgrades to support other coins. I suspect you will sell out pretty fast.
It would especially be great if MNOs could manage which inputs are spent, basically, if the wallet could have all the functions of the core wallet and if it would be upgraded to Evolution functions as needed. This will undoubtedly require support. Will there be support and/or a guarantee for the product for a minimum amount of time?
And finally, I sure hope that when you have to change the battery that all the information is in non-volatile memory!!! If not, we're going to have a lot of panicky users! LOL
For your question: I'll answer this straight away without any marketing bullshit. Both for the device proposed here and for the Trezor - and probably all hardware wallets out there by now - the security model is as follows: the private keys are stored on the device and never leave the device. Given the fact that you can't retrieve the private keys through the formal API of the device (and assuming that there are no flaws in its implementation), there are two possible attack vectors to the device left: an attacker could try to read out the flash memory of the chip (which contains the firmware as well as the keys), or an attacker could try to load a modified software on the device which in turn will read out the keys from the flash. Typically, the chip itself offers protection from attack #1 by "locking" the flash memory access by the JTAG/SWD (hardware debug) interface once it has been flashed. This lock can be revoked, but a complete erase of the flash will result making this useless for the attacker. Attack #2 is what you describe: you could try to put a modified software that "spies" on the keys. Since JTAG/SWD access is locked, the modified software would have to be put on the device via the firmware upgrade process. And this way is blocked by signing firmware upgrades with a manufacturer key, and an old firmware will only install an upgrade if the signature is OK.
In parts, this strategy collides with open source: wouldn't it be great if you could put any software on the device? Yes, but not great if this is spyware. So the way we'll choose is the following: Our firmware will be open source, but it will be signed with our private key (which isn't open source, neither is it on the device, only the public key). Our firmware will only install upgrade which are again signed by this key. But: the device won't be completely locked. An advanced user that wants to play with the device might install custom firmware (which is not signed by us). But you can't do that without wiping the device.
The only thing you shouldn't do is to install some "unchecked firmware from the Internet", and later enter your recovery passphrase to the device (which is essentially the path to your private keys). I hope I could make this a little bit clear. Difficult to explain this in short words.
If it's just pre-installed malware on an (otherwise correctly designed) USB flash drive, yes, you might detect that using a special program (that examines the flash drive prior to mounting it as a drive on the computer).
If its a rogue hardware device, your chances are pretty bad. Because the device could behave differently towards the PC depending on how it's accessed. It could pretend to be a keyboard, or a mouse. Or both at the same time... Things like this can't happen with Bluetooth because the pairing process requires interaction with the user.
Well, technically, we won't "sell" the first 10,000, at least not sell them for a profit as the word might imply. We will give the first 10,000 away to anyone who qualifies for free (see the detailed proposal for how we will do this)!
After that, yes, we hope we can sustain the product on the market by selling it for the retail price we have planned ($45). And yes, this price will have a retail profit for us (fair enough I think). I think this is mutual benefit, because the Dash community also profits from someone selling these devices.
Last comment: of course the private keys are in flash. Dead or removed batteries will not delete your private keys. ;-)
i think this is a bad idea
why reinvent the wheel when 2-3 working / verified solutions are out there ?
TREZOR is a 100% solid - so are keepass and ledger (depending on taste and style).
well maintained , trusted and verified by communities across the crypto space ! (Tested for YEARS)
to invest time and money into a new solution ... because why ?
to have Dash sticker on it ? any available HW wallet can be “Dashified†or changed in appearance (if people are really worried about being stopped by a boarder guard with their Trezor in pocket)
Yes you are perfectly right, you can put a sticker telling "Blue Energy" on your gasoline car. So why invest time and money into building an elecric car? Which will in effect only move us from A to B, right? Gasoline cars are 100% solid, well maintained, trusted and verified by millions of customers. No need for some silicon valley company to try to disrupt that space, right?
OK, back to being serious. These are the key points that none of the current solutions have:
* compatible with smartphone and tablet use cases, due to the use of Bluetooth LE
* support for the unique Dash features (PrivateSend, InstantSend, new Evolution features).
* branded for Dash in the first place, marketed with and for Dash in the first place
* designed for a retail price point of less than $50
Just like the first Dash ASIC miner gave a clear advantage to Dash miners, i think an opensourced Dash specific hardware wallet could provide a clear advantage to Dash users and open up a new Dash oriented market in the process.
There is the question of trust, but then again OP did provide full details about himself and his company.
strophy made a good point about bluetooth security, so i like to see the reponse to that question as well.
But lets keep in mind that even the use of USB has security issues (https://www.howtogeek.com/203061/don%E2%80%99t-panic-but-all-usb-devices-have-a-massive-security-problem/)
You nailed it. That's exactly what the proposed device is all about.
I do have a question though : can Dash masternode owners put their masternode collateral on this wallet and have control over specific input amounts, so we can select and transfer masternode payments out ?
My concern with this proposal is security. Bluetooth is just a little bit too much networking and closed-source proprietary networking stacks for my taste. Why is this technology necessary? How will updates in the event of a serious attack (see link below) against all known Bluetooth devices be implemented? Will the Bluetooth chip mentioned be updateable, and will the manufacturer ship such updates quickly?
https://www.armis.com/blueborne/
As for security, strophy, you are basically right. Full Bluetooth in itself is a pretty bloated networking stack. However, one has to look at the details
* we're only using Bluetooth LE (low energy), not the full Bluetooth suite. That in itself eliminates some 80-90% of the complexity
* we selected the NXP KW41Z line of devices also for the reason that NXP (formerly Freescale) open sourced the majority of their Bluetooth stack driver (in contrast to others like TI, Nordic).
* we investigated the Blueborne attack together with NXP at the day it came out, Two findings in this case: KW41Z is not affected, and the NXP guys really knew what they were doing there. No 100% insurance for the future, but a good sign.
Yes the device will be software-upgradable. NXP/Freescale is one of the market leaders in this space, no doubt updates will become available if necessary. Our final design has not been made yet, but it'll probably be necessary to wipe the device (delete all private keys) before an upgrade and to recover it from the passphrase later on. I know it's inconvenient, but the security of your private keys have topmost priority.
So while Bluetooth has its issues, this technology really has matured in the last years and is now ready for such use cases.
In the end, compare it to USB, which is also a security nightmare. Any USB device plugged to your PC could simulate a "rogue keyboard and mouse" and pretty much to everything to your computer. And there's nothing today in any major operating system that might stop this. In this respect, Bluetooth is already way better.