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

V12.1 Testnet Launch Thread

Status
Not open for further replies.
Well, probably... My main concern about 10000 keys is that it gives kind of false feeling of safety imo. If file gets corrupted in a bad and unpredictable way due to some combination of disk and power failure then much more funds could be potentially lost there without a proper backup. I would prefer to have 1000 keys (which is already 10 times more than Bitcoin Core wallet has by default btw) and to actually force general user to backup more often. At least by restarting his wallet time to time (I would avoid messing up with wallet.dat file while wallet is running for now). Power user can refill keypool with whatever amount of keys he wants via keypoolrefill but he would need to explicitly do this via RPC so at least we can assume that he is more or less aware of such action consequences.
This displays the idea that a static number of keys is too clumsy for the task at hand.

It makes more sense to set a rate of backup frequency based on key use. A scan of keys used compared to unused already occurs... Hell, it's a primary function of being able to tell the balance...
True! I completely missed that point, will have a look :)
Most of what you need is already there. The option to use a password or GPG key could be added on.

Since mixing is unpredictable and continuous, it's only user-definable settings should be where to put the backup (default to the folder/directory already being used), and key frequency.

It already makes backups at initialization. Just change that to the user-definable stats, add password/gpg passthrough, all done. Wouldn't want it to hit a cloud drive unencrypted... Wallet password and backup password/gpg should not be shared... I prefer to run my wallet unencrypted for recovery reasons. But I'd like my cloud backups to be crazy encrypted. Because duh.

You might want something in the first use popup to talk about setting your backup frequency and location... Not merely disclaimer, but "do this or don't blame us."
 
Last edited:
Report: My windows 10 machine doesn't like my wifi dongle and keeps dropping off the network, however it seems to be working. I got a conflicted transaction for a privatesend denominate and yet, the wallet moved on. No hang ups it seems :)

Because of the intensive nature of mixing, it might do well to have -zaplocaltxes (I forget the flag) as default action? OR some way to scan for these conflicted things and autofix them for derp users. If it happened by default at wallet launch, then you could just tell them to restart the qt instead of asking them to command line, type stuff, because having a brain is scary to these people...

Obviously something is detecting these conflicted attempts, or else it wouldn't be calling it that... Why not have it take useful action instead of merely saying so?

It's like a really dumb employee....

"Hey, I found this busted thing!"

Well, ok, dumbass, do something about it then... Aren't you a real fancy computer and shit? There;s really only one cause, one mode of failure, and one way to fix it, so... Why not just do it instead of notify about it?
 
Last edited:
"found unconfirmed denominated outputs...." generally shouldn't be a problem for -privatesendmultisession mode, wallet should just use other available outputs.
The objective of testing multisession mixing, is to make it into default behavior, right?
 
If I combine the two, IS and PS, I think the fees add up to something that causes my transaction to fail because it can't find enough smaller PS funds (due to smaller denoms not being mixed enough) to pay the fees (the denomination included fees are not enough)
Maybe there should be a display of spendable funds depending on the boxes checked, with a tooltip saying why the number is smaller than the balance number?

Tooltip: PS fee deducted X.XX DASH, IS fee deducted X.XX DASH.
 
Camo, I think all the issues I had have been fixed. Or no longer occur as of this last version. It allows me to send instantly with private send, any amount down to the lowest 8 decimals. Very nice :)

Speaking of key backups, this isn't a problem with predetermined wallet keys, is it? I mean the kind you get in an electrum wallet. This begs me to ask the question: why don't we have deterministic wallets as a default? We're going there anyway with Evolution, why don't we scrap the regular old fashioned wallets that hash out a number from who knows where (I'm actually not sure how they work, LOL)
 
Camo, I think all the issues I had have been fixed. Or no longer occur as of this last version. It allows me to send instantly with private send, any amount down to the lowest 8 decimals. Very nice :)

Speaking of key backups, this isn't a problem with predetermined wallet keys, is it? I mean the kind you get in an electrum wallet. This begs me to ask the question: why don't we have deterministic wallets as a default? We're going there anyway with Evolution, why don't we scrap the regular old fashioned wallets that hash out a number from who knows where (I'm actually not sure how they work, LOL)
No, it has no effect on a deterministic seed (unless you forget it), but a deterministic seed is less secure from non-user-generated vectors...

To say it in a more camosoul-esque way...

The deterministic seed is good for people who are so stupid that they present a bigger threat to themselves than any other threat against them. For people who understand and take extreme measures, like I do, deterministic seeds are actually less secure.

You can make a backup of keys regardless of the seed being deterministic or /dev/urandom

dumpprivkey, cp wallet.dat ~/backups/wallet.dat.bak, or gpg -ea ~/.dash/wallet.dat [magic] wallet.dat.asc can all be done no matter where the seeds come from.

But if someone gets your seed... they don't just have your money. They have all the money you will ever get... Even if they only get your public seed, they can spy on every transaction you ever perform. No one can do that with mine, an it's why even Satoshi didn't make it part of the original BitClone wallet, even though it could have easily been included from day one. It's a bad idea to put all your money in one password and then use windows or an iPhone and get keylogged... Keylogging isn't for malware anymore, and they don't even need a warrant, You gave the keys to the mansion to a giant corporate butler, beholden to the guv...

It's a lot harder to get my keys than it is to get just one seed/password. Which is why I question Trezor... It seems like a good idea with the random pin... but it only takes one slip up, one government peek granted by microsoft because they don't want to get leaned on and consumers have demanded their OSes be backdoored for conveniences and laziness....

Huxley's Brave New World is in full effect. You have to keep that in mind when considering what is secure and what isn't.

...I now return you to your regularly scheduled testing...
 
Last edited:
Wait, I'm trying to understand. Somehow I got it in my minuscule little brain that Evolution wallets were going to be deterministic. Does this mean we will introduce security issues here? I mean, I know that we can always use a regular wallet with evolution, without all the features Evolution will bring, but I thought deterministic wallets were just as secure - though I do see your point :)

Frankly, yes, the population isn't so much stupid, but so many people will find this unnerving if they hear they could lose everything if they don't back up before they run out of keys, etc... which is a hard learning curve for most people not so inclined. So, even so people are "stupid" we still want their business, and if a deterministic wallet option makes life feel more secure to people, then I'd be for a choice.

I know how you feel camo, but we gotta go for the whole bell curve, not just your right-hand tip :) Or at least for the fat center :)
 
Wait, I'm trying to understand. Somehow I got it in my minuscule little brain that Evolution wallets were going to be deterministic. Does this mean we will introduce security issues here? I mean, I know that we can always use a regular wallet with evolution, without all the features Evolution will bring, but I thought deterministic wallets were just as secure - though I do see your point :)

Frankly, yes, the population isn't so much stupid, but so many people will find this unnerving if they hear they could lose everything if they don't back up before they run out of keys, etc... which is a hard learning curve for most people not so inclined. So, even so people are "stupid" we still want their business, and if a deterministic wallet option makes life feel more secure to people, then I'd be for a choice.

I know how you feel camo, but we gotta go for the whole bell curve, not just your right-hand tip :) Or at least for the fat center :)
It is more secure for those who are a greater threat to themselves, by being irresponsible and stupid, than the threat posed by any external force(s).

Which is most people. Especially the millennials... Dumbest. People. Ever.

I'm not arguing against the deterministic option. As long as it's an option. Even if it's the default option.

I'm not against dumbing things down, as long as it's explained, and there exists the option to un-dumb it. I don't want to be forced to give up superior security in favor of catering to irresponsible jacktards. Kinda like everything else in my life...

@moocowmoo has a good plan for making sure your deterministic seed is not compromised. Use a LiveCD of your choice, RAM install, generate, reboot. No chance of technological compromise, as long as your BIOS isn't already... I like to do it on retail demo computers at places like Best Buy or Wal Mart, hundreds of miles from home.

This really is off topic...
 
@camosoul, I just said to my hubby, John, that you and he were so much alike, AKA tolerating people. He quipped that you were both excellent at tolerating people, "'cause just look, all those stupid people are still alive!"
 
Anybody know if the SPECs for MN's will be changing on the next release?
As in Server requirements?
 
@camosoul, I just said to my hubby, John, that you and he were so much alike, AKA tolerating people. He quipped that you were both excellent at tolerating people, "'cause just look, all those stupid people are still alive!"
Bingo. If I really were a terrible, evil, ammosexual everything-o-phobe; there wouldn't be anyone around to say so and complain about how bad I make them look by being so much better than they are at everything forever... :p
Anybody know if the SPECs for MN's will be changing on the next release?
As in Server requirements?
I can't see a reason for them to change... Due to the multisession mixing, there may be an increase in CPU use and maybe RAM and bandwidth, but probably not a lot. Mixing still uses the same resources, but in much more rapid bursts. The parallelism in the clients will be reflected in the hosts doing the jobs. So, a bit more RAM and CPU usage. My 8core Xeons probably won't notice. But slow ARMs will be noticeable. Nothing critical. Think of it like, 8core Xeon has a ceiling so tall you can't see it. ARMs, well, you can just barely see it... You'll be using more, but still not enough to worry about.

My containers get 1x full clocked core, 512 RAM, and 256 Swap. I don't anticipate that changing for 12.1. They barely touch my available bandwidth. Even if they increased by an order of magnitude, it still wouldn't be a problem.

We're still not storing any info beyond the chain, so storage space, which will be the biggest future change, is still not in play.

My virtualization host is still pulling roughly 3% to 5% of it's bandwidth. CPUs are a smidge above idle. RAM is maxed out... That's the only thing I can see being an issue, but it's a longshot maybe. If you run like I do, with cron simply trying to restart the client every 5 minutes, low RAM crashes should manifest as proof of service strikes that never quite get bad enough to kick you off (until traffic increases, then it will), as a first symptom. I know it's crude, and there are much more graceful watchdog scripts, but this method comes with crude diag....

Watch swap.

An upgraded virtual host will also have upgrade hard drive space, so those two problems should solve each other at the same time.

These are things MN operators should be learning about and preparing for months ago... 12.1 will show us a small increase in CPU/RAM and possible bandwidth. But full-blown Evolution will have as significantly higher demand, though still, probably not critical. Anyone running very minimal nodes is going to start crying, just like CPU miners did when GPU mining became a thing... Then FPGAs and ASICs...

@ all MN operators; If you're not planning ahead, you're doing DASH a dis-service. Irresponsible retards should not be running masternodes. If you run an MN and aren't watching the testing thread, you're a dick. It shouldn't be hard to deduce the resource needs from the feature changes. Hell, run a testnet MN... Or a dozen. 1000 tDASH costs nothing. 3 faucets... Actually DO it and you'll know...

Also, ESXI is gay because VMWare is fighting hard to become the Lotus Notes of Virtualization. Use Proxmox.

Independent operators with only 1 to a few nodes, should consider pooling resources for their own pizza boxes, instead of playing with middle man VPSes. It's going to make more sense that way.

If you've got affordable statics on Pis, sufficient pipe at home, you should be good for the foreseeable future, even Evolution.

I don't know if the MN protocol can support compression, but it might be a consideration for large spews of data, like lists, chain to new nodes, etc... Bandwidth will be a problem long before CPU. Might as well use it to lighten the load.

Certain forms of encryption provide natural compression on larger datablocks... If my node finds itself pumping 27gigs of chain to a new node in 2025... It'd be nice if that only used 10gigs of pipe to do it, or a version of bit torrent to draw from the whole network in conjunction with compression, too... Especially any transition to a 500DASH node split. That'll be a lot of pipe... Think of it now, not when it's too late... A node split may even be considered simply to diversify the data shards, not necessarily service-related.
 
Last edited:
It seems like a good idea with the random pin... but it only takes one slip up, one government peek granted by microsoft because they don't want to get leaned on and consumers have demanded their OSes be backdoored for conveniences and laziness....
I know it's off topic but this is technically incorrect. There's no way an OS backdoor/malware/virus can snoop the Trezor's PIN. Passphrases, yes because they are entered in plaintext via the host computer's keyboard (which renders the passphrase option mostly useless, except for the $5 wrench countermeasure). Apart from very ambitious hardware attacks (such as voltage monitoring during seed calculation, electron microscope tricks, etc.), it seems the only real vulnerability is from Satoshilabs itself. They would need to sell all of the necessary firmware signing keys to the highest bidder, and then mr. malicious moneybags would have to go through the process of getting people to install the wallet-stealing firmware and cash in as much as possible before anyone starts screaming. I think slush has set up some protections against malicious firmware attacks, such as distributing the singing keys among multiple trusted entities so that no one person can be compromised.

To all Trezor users: ALWAYS cover your Trezor's scrambled number PIN screen with your hand so that no camera or person in in the vicinity can see it and the mouse positions you click
 
There's no way an OS backdoor/malware/virus can snoop the Trezor's PIN.
And? What's that got to do with anything? I'm not so stupid that I need to be saved from myself... I'm talking about real attack vectors. Not this "help the idiots save themselves from themselves" crapola.

It's not entirely off topic, as DASH is being added to trezor...

The entire setup process uses an account you set up on their website, and a browser plugin, which passes all of that information through their website! Are you effing kidding me? And we WANT this? Gee, thanks for storing my seed on your server, Trezor, so everyone who works there, and anyone who breaks in, can restore my addresses onto their own devices at will.... Much secure! Wow!

Give me source code for a program I can compile myself, and run entirely offline, or Trezor is a scam. Maybe idiots who have no clue how horrible this setup process is think it's great, but I have a brain. "Oh look at my cool, so totally secure Bitcoin key fob, I'm so special" is the opposite of security expert.

This really should be discussed in that proposal's thread. But it's crickets...

Browser plugin via their website? Are you fucking kidding me? Sure, easy. Cross-platform. About as secure as handing your wallet to a crackhead stripper who keeps scratching herself all over for no apparent reason...

In what universe would I generate a seed by any means other than a livecd on a computer that is not connected to any network? Are you on crack? And meth and heroin and stupid all at the same time? Fuck me...

Disagree all you want, you're absolutely dead wrong. If you have to log into a website, install a browser plugin, and pass everything through that system; it can't even be mentioned in the same planetary hemisphere with the word "security."

Anyways, lets test some shit. I can't even get the 12.1 QT to load in Winblows7... It hourgasses for about 2 seconds, then nothing...
 
Last edited:
You're being ironic right? Because that is not how Trezor works at all, seed never leaves the device and is self-generated so there is nothing to steal on the SatoshiLabs servers. The SatoshiLabs servers and the Electrum wallet only provide an interface for trezor to sign tx's. Think of armory with Trezor as the permanent offline comp. And just to compliment it cant be reprogrammed from a host computer or virus.

Pablo.
 
You're being ironic right? Because that is not how Trezor works at all, seed never leaves the device and is self-generated so there is nothing to steal on the SatoshiLabs servers.
Prove it. If I have to perform this entire process via their website, with an account, and a browser plugin; prove it's not betraying this trust model.

Not to mention, that's just the most outrageously stupid thing, ever... Only people who don't understand, who desperately want to look cool, will skip over that like it's no big deal.

Why bother generating a trust model? They could easily create a trustless model, where I don't have to "believe" in them.

This is crypto.

The only reason to say "trust me" is so that you can steal someone's coins.

Is this the 5th time I've tried to steer the thread back on topic...
 
Last edited:
The entire setup process can be done offline, no account necessary. The chrome extension can be built and installed on an offline computer (https://github.com/trezor/trezor-chrome-extension) if you want to use Chromium to setup the Trezor.

It is also possible to setup the Trezor with an offline computer by installing python-trezor and Electrum. I've personally never even used the mytrezor wallet for any money. I've connected to it once before only to download firmware, for which the Trezor restricts itself to accept only validly-signed versions (from the multiple keys I mentioned in my earlier post). I am very conscious of external attack vectors too, and I even use my Trezor with Electrum's watch-only hot + offline sign configuration (which is already super secure in itself), but with the addition of a conveniently pin protected seed that is not even stored on the offline computer.

I think I read that @flare is looking into the ability to setup a new Trezor (i.e. initiating Trezor's PIN selection and mnemonic generation process) for an upcoming Dash release, which is great.
 
As far as trusting the Trezor hardware itself goes, there are hundreds of pages on bitcointalk dedicated to just that. There is nothing secret about the Trezor and its history from idea to final product is well known and documented. Granted, when you use any peice of mass-manufactured hardware, there is risk. Slush's reputation is probably one of the best in crypto (you have to trust SOMEONE if you cant build it all from scratch, right?) Everything about it from software to hardware is open source, with a more community-documented history than any other hardware wallet, I would say. Slush's reputation speaks for itself. And honestly, once you really understand how the Trezor works, there really is not too much to trust anyway.
 
Status
Not open for further replies.
Back
Top