• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Proposal: Hardware Wallets For Build And Test

Ryan Taylor

Ryan Taylor

Well-known member
Foundation Member
This is a cross-post from https://www.dashwhale.org/p/HW-wallet-build-test

This proposal is to purchase three hardware wallets for our soon-to-be-released Electrum masternode functionality integration. We need the wallets for @flare to build and test the software from Mazaclub. The Trezor-functional wallet is now ready for acceptance testing, but we need to provide him with these devices to test each release as they are completed. We will also need them over the coming months / years for maintenace releases as Dash functionality is added to future Electrum releases.

The costs below include shipping.

Requested funding is as follows for the July 6th budget cycle:
  • 17.22 Dash for a KeepKey hardware wallet (125.00 EUR @ 0.89407 EUR per USD and $8.12 / Dash based on June 3rd average rate at https://bitinfocharts.com/comparison/price-dash.html)
  • 15.96 Dash for a Trezor hardware wallet (115.90 EUR)
  • 5.50 Dash for a Ledger Nano hardware wallet (39.90 EUR)
  • 5.00 Dash reimbursement for the proposal cost
Total: 43.68 Dash

Exchange rate risk is carried by flare and not by the network. However, any changes in the actual fiat cost associated with the purchase (e.g., unaccounted for customs fees) may result in additional reimbursements owed to flare.

Manually vote YES on this proposal:
dash-cli mnbudget vote-many e06c3e6488899e3c3407eb515c769112f1565dd5d1ecf6e4807c0fa9a13792d6 yes
OR from the qt console:
mnbudget vote-many e06c3e6488899e3c3407eb515c769112f1565dd5d1ecf6e4807c0fa9a13792d6 yes

Manually vote NO on this proposal:
dash-cli mnbudget vote-many e06c3e6488899e3c3407eb515c769112f1565dd5d1ecf6e4807c0fa9a13792d6 no
OR from the qt console:
mnbudget vote-many e06c3e6488899e3c3407eb515c769112f1565dd5d1ecf6e4807c0fa9a13792d6 no
 
Last edited:
Good idea, but I would have doubled the proposal (Hardware Wallets for 2 Dash developers, the rest budget allows it)
 
I just voted yes; but I kindda feel like including all wallets is overkill no? It just adds maintenance and labor overhead, Trezor is number one, should be more than enough?

Pablo.
 
fible1 said:
I just voted yes; but I kindda feel like including all wallets is overkill no? It just adds maintenance and labor overhead, Trezor is number one, should be more than enough?

Pablo.
Click to expand...
I have the Trezor too. It is the go-to hardware wallet. But the KeepKey sure does look sexy.
 
fible1 said:
I just voted yes; but I kindda feel like including all wallets is overkill no? It just adds maintenance and labor overhead, Trezor is number one, should be more than enough?

Pablo.
Click to expand...
I think it's important to give end users as much choice as possible if we want to encourage adoption. I voted yes as well.
 
The other things to consider here that I probably should have included in the OP...
1) We get "free marketing" with every integration when these companies email their registered users and / or previous orders mailing lists with the announcement of Dash support. These are potentially new users who are already cryptocurrency users.
2) We get news-worthy event we can approach publications with
3) We get something for our PR firm to highlight
4) We build our network of partners in the Bitcoin ecosystem, not only the companies themselves, but they can facilitate introductions, or simply create higher awareness of Dash among their partners, investors, employees (who change jobs within the industry by the way), and management teams
5) We demonstrate the value of working with Dash to our other developing relationships and gain a reputation in the industry of being great to work with.

Is one or two wallet providers "enough" in terms of providing a product to our users? Sure. But when you consider the full value of these relationships, it's a "no-brainer" to me. I encourage everyone to start thinking very strategically about these opportunities, instead of just evaluating the immediately obvious benefits.
 
Thanks for voting :)

Some crypto porn:

upload_2016-6-8_11-55-33.png
 
@flare: What was the bug that you found with the KeepKey version? Glad it is working... can't wait for the formal release! I have my Trezor waiting.
 
I might have to go to Prague. Trezor and CZ... Bucket list, approved.

Wanted: waterproof trezor, because sailboat.
 
Last edited:
I've had a bug in my brain that I couldn't quite identify ever since I started researching these hardware wallets... A few minutes ago, it reached out from my unconscious mind and woke me up as it entered my conscious mind. As things my brain thinks of without my permission often do...

The only real weakness I see in devices like this, is the deterministic seed itself.

Take Trezor, for example.

I noticed this when I saw how they were touting the keyspace math for 24 dictionary words compared to keyspace of a single password with letters, numbers, and symbols.

It's not a true comparison because we know that dictionary words are being used, and we can even discover which ones simply by going through the setup process, or, duh, looking at the code. It's open source.

Since the process is deterministic, and the source is pseudo-random, at best, given that it's dictionary... We don't have to attack a given device. We don't have to possess a device, or have a target in mind.

All we have to do is possess a blockchain, and keep comparing addresses deriven from the same pile of dictionary words until we get a hit on an address that has been used somewhere in blockchain history.

The space we actually have to search, we ignore. We don't give one flying fuck about the mathematical keyspace. We simply generate seeds in the same manner as the code shows us, as fast as we can, and see if the first 10 deriven addresses appear in the blockchain. If so, we have a valid seed. Automate sends to own address. Owner no longer has any money.

The key is deterministic. The pseudo-random soucre can be thought of as pseudo-deterministic, because it's pattern is defined. Too many known rule sets...

The more products are sold, the more we divide the search... We're not attacking a certain target, we're just jamming numbers until we hit a seed whose addresses show up in the blockchain. Just like mining, except the "block" is someone else's wallet, and the "validation proof" is the ledger... Sure, the seller of this device really hasn't got any fear of his customers ever deriving the same seed. But a fuckton of GPUs that are no longer good for mining, following the same pattern outlined in the source code...

This indefinite pattern won't work on FPGAs or ASICs. All those GPU mining rigs tho...

Perhaps building and comparing seeds is the new black hat GPU mining? Even if we were searching raw keyspace, that much firepower would work... If you're just looking for a single random address, that's not worth it. But if you strike a seed that's got some money on it, you could just sit and wait for it to show some serious balance and then send it to yourself. We already know how to run mining pools... The collective power of every GPU mining rig ever made, following known dictionary patterns, generating the keys in the same way as the device does... Divided by the number of buyers... Compare the outcome of address to the blockchain history for use... How could you NOT find the same seeds twice? It's not merely possible, it's inevitable.

The antiquated crunching power that crypto depends upon could be the very thing that undoes the idea of deterministic wallets. And these hardware wallet devices use deterministic keys, invariably...
 
Last edited:
@camosoul
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#security i.e. breaking seed itself is like breaking EC-curve - there is no way you can do this other than bruteforce and for breaking a single pair would take million of years afaik
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#from-mnemonic-to-seed - note that the salt includes passphrase so you can't generate all possible seeds - their number is infinite
EDIT: unless user ignored passphrase and kept it "" but that's his own fault
 
UdjinM6 said:
@camosoul
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#security i.e. breaking seed itself is like breaking EC-curve - there is no way you can do this other than bruteforce and for breaking a single pair would take million of years afaik
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#from-mnemonic-to-seed - note that the salt includes passphrase so you can't generate all possible seeds - their number is infinite
EDIT: unless user ignored passphrase and kept it "" but that's his own fault
Click to expand...
Ah, so their consumer-friendly description was overly dumbed-down to the point of being untrue.

I think this still fails to account for several properties.

1) The raw computing firepower available in GPU mining rigs. This is not inconsequential.
2) The fact that we're not merely brute-forcing. We're brute-forcing with a known pattern.
3) We don't actually have a keyspace target. This means the more people who use it, the more the keyspace is divided.
4) Those rigs really have nothing better to do, so why not? Maybe you roll the dice and land on Bitcoin Jesus? What's the down side?

Essentially, there are lots of needles in the haystack, we don't care which one we find, we have a magnet, and there is no penalty.

Keyspace is still cosmically huge, but it's not utterly out of reach, as viewed from the perspective of attacking a specific key with an i3....

Maybe this analogy isn't quite right, but it's almost a quantum concept... Why try to brute-force the password to my SSH server, when you can just try every password on every SSH server, and if one of them works, then you know which one after the fact.
 
camosoul said:
Ah, so their consumer-friendly description was overly dumbed-down to the point of being untrue.

I think this still fails to account for several properties.

1) The raw computing firepower available in GPU mining rigs. This is not inconsequential.
2) The fact that we're not merely brute-forcing. We're brute-forcing with a known pattern.
3) We don't actually have a keyspace target. This means the more people who use it, the more the keyspace is divided.
4) Those rigs really have nothing better to do, so why not? Maybe you roll the dice and land on Bitcoin Jesus? What's the down side?

Essentially, there are lots of needles in the haystack, we don't care which one we find, we have a magnet, and there is no penalty.

Keyspace is still cosmically huge, but it's not utterly out of reach, as viewed from the perspective of attacking a specific key with an i3....

Maybe this analogy isn't quite right, but it's almost a quantum concept... Why try to brute-force the password to my SSH server, when you can just try every password on every SSH server, and if one of them works, then you know which one after the fact.
Click to expand...
I'm not sure which pattern you are referring to...
 
Good proposal. However, if any manufacturer out there is reading this thread, I wish that they make something without a USB or whatsoever connection to a PC. The USB firmware malware could be a concern. Without any connection, it would be nice to have a tiny camera to read a QR code from PC/phone to update the ledger and has a screen to show QR code for sending coins or importing key to a wallet on PC. And, 4-digit PIN sounds really easy to break in if one can open up the hardware and fiddle with it.
 
You must log in or register to reply here.
Back
Top