V12.1 Testnet Launch Thread

[UdjinM6]

Can you explain

Can you explain what the keypool is?

To put it simply - keypool is a set of newly generated but yet unused addresses which are available for your even if your wallet is locked so 1) you can request 1000 "new" addresses without unlocking your wallet and 2) when you backup your wallet you already have 1000 change (or whatever you use them for) addresses and can recover them in case something goes wrong. So it also gives you some gap in time when you can feel more or less safe (wallet is making automatic backups on each (re)start by default).

 

[GNULinuxGuy]

Dedicated tMN updated to v0.12.1.0-ee31604. Looking pretty healthy from the tMN side, but I haven't had a chance to test mixing with this version yet.

I notice on the testnet tools post (https://www.dash.org/forum/threads/testnet-tools-resources.1768/) we're directing people to #darkcoin-test for IRC. This should probably be changed to #dashpay (or maybe #dashpay-dev, but it's been just the git bot and I in there for the longest time now). It would also be a good idea to mention it's on Freenode and maybe also provide a link like https://webchat.freenode.net/?channels=#dashpay for convenience.

 

[Comodore]

Dedicated tMN updated to v0.12.1.0-ee31604. Looking pretty healthy from the tMN side, but I haven't had a chance to test mixing with this version yet.

I notice on the testnet tools post (https://www.dash.org/forum/threads/testnet-tools-resources.1768/) we're directing people to #darkcoin-test for IRC. This should probably be changed to #dashpay (or maybe #dashpay-dev, but it's been just the git bot and I in there for the longest time now). It would also be a good idea to mention it's on Freenode and maybe also provide a link like https://webchat.freenode.net/?channels=#dashpay for convenience.

I think better place is dash_testnet channel on digital cash slack, isn't it?

 

[GNULinuxGuy]

I think better place is dash_testnet channel on digital cash slack, isn't it?

I think it's best to avoid encouraging people to rely on a proprietary service given the nature of this project. From what I hear Slack has some decent features, but those features do not provide enough utility for me to justify using it.

 

[camosoul]

Cant we make backup during mix process, i mean when new key is added?

Not sure about the first one but we could probably save keymap size on start in some tmp variable, show (sizeOnStart + keypoolSize - currentSize) and warn if it's very low (like 10%) or even stop mixing completely... smth like the way notebooks behave when they run out of battery... hmm...

This gave me an idea...

While it's possible for us nerds to mount a different block device, say, sshfs to be crude, to ~/.dash/backups/

Wouldn't it be nice to add on to that idea a little bit?

What if the client used a password or gpg key to transparently pass the backups through before it ever touches spinning rust? Kind of like the client's own loopback, the way transparent drive encryption is handled by the kernel... Maybe I just don't trust Trezor and would like to autobackup to a cloud and have nothing but ascii armor hit the disk, ever?

Instead of making a backup on startup/shutdown, make a schedule, and allow the client to stay active during the process. And to augment, or disable, the over-writing of old backups. Since the client knows itself so well, the creation of a new backup can be tied to the key creation rate... Pump the wallet.dat through the gpg onto remote storage every X keys... Maybe add a bit of 7z magic to it, too? Hell, If I can understand it and do something similar with "|" and ">" on cli, surely it's not a terribly difficult feature add? No, don't tell me about deterministic seeds. That's the opposite of the level of security I'm going for... It helps morons at the cost of security.

A more grown-up way to manage backups built right in, instead of having to get your nerd on to do it.

This probably belongs in a different thread, but it's where I found the breadcrumbs.

 

[flare]

Latest builds (git-4d4a9df) of v0.12.1.x branch

Linux --> https://dashpay.atlassian.net/builds/browse/DASHL-DEV-561/artifact/JOB1/gitian-linux-dash-dist/
Windows --> https://dashpay.atlassian.net/builds/browse/DASHW-DEV-508/artifact/JOB1/gitian-win-dash-dist/
MacOS X --> https://dashpay.atlassian.net/builds/browse/DASHM-DEV-517/artifact/JOB1/gitian-osx-dash-dist/
Raspberry --> https://dashpay.atlassian.net/builds/browse/DASHP-DEV-513/artifact/JOB1/gitian-RPi2-dash-dist/

Changelog:

Merge https://github.com/dashpay/dash/pull/866: [UI] Column alignement of Transaction-Tab adjusted
Merge https://github.com/dashpay/dash/pull/867: Implement an option to enable/disable advanced PrivateSend UI
Merge https://github.com/dashpay/dash/pull/868: checkbox image for wallet themes

Testnet tools (explorers, faucets, pools) --> https://www.dash.org/forum/threads/testnet-tools-resources.1768/

 

[TaoOfSatoshi]

Latest builds (git-4d4a9df) of v0.12.1.x branch

Linux --> https://dashpay.atlassian.net/builds/browse/DASHL-DEV-561/artifact/JOB1/gitian-linux-dash-dist/
Windows --> https://dashpay.atlassian.net/builds/browse/DASHW-DEV-508/artifact/JOB1/gitian-win-dash-dist/
MacOS X --> https://dashpay.atlassian.net/builds/browse/DASHM-DEV-517/artifact/JOB1/gitian-osx-dash-dist/
Raspberry --> https://dashpay.atlassian.net/builds/browse/DASHP-DEV-513/artifact/JOB1/gitian-RPi2-dash-dist/

Changelog:

Merge https://github.com/dashpay/dash/pull/866: [UI] Column alignement of Transaction-Tab adjusted
Merge https://github.com/dashpay/dash/pull/867: Implement an option to enable/disable advanced PrivateSend UI
Merge https://github.com/dashpay/dash/pull/868: checkbox image for wallet themes

Testnet tools (explorers, faucets, pools) --> https://www.dash.org/forum/threads/testnet-tools-resources.1768/

Sweet. Update when I get home.

 

[yidakee]

@flare @UdjinM6

Nice to see the keypool count happening Finally I get to have an idea of mine implemented hehe - I feel so proud

So again I pose this idea. Just like on wallet creation/password setting, where the wallet is forced to restart to accept changes, can't we have that same behaviour when one presses "Start Mixing"? The wallet could restart and refill itself with an absurd amount of keys. A pop-up warning about backups could show up, saying it's a one time thing and probably going to take a few minutes, and a new backup will be required. That way we could have multisession by default?

Crypto's are by default the responsibility of the user to do it right. This is not a toy, its real money. I once destroyed many darks because I almost forgot that there is no change address for paper wallets, and that is not the paper-wallet creator's fault. Many folk forget passwords. Crypto's are about giving power and thus responsibility to the end user. It's with Evo that we're changing this paradigm.

I much prefer to see on big warning sign pop-up explaining what is going to happen and make multisession default, than to keep PS crawling and stagnating because a legacy keypool size is a mere 1000.

.

 

[UdjinM6]

@flare @UdjinM6

Nice to see the keypool count happening Finally I get to have an idea of mine implemented hehe - I feel so proud

So again I pose this idea. Just like on wallet creation/password setting, where the wallet is forced to restart to accept changes, can't we have that same behaviour when one presses "Start Mixing"? The wallet could restart and refill itself with an absurd amount of keys. A pop-up warning about backups could show up, saying it's a one time thing and probably going to take a few minutes, and a new backup will be required. That way we could have multisession by default?

Crypto's are by default the responsibility of the user to do it right. This is not a toy, its real money. I once destroyed many darks because I almost forgot that there is no change address for paper wallets, and that is not the paper-wallet creator's fault. Many folk forget passwords. Crypto's are about giving power and thus responsibility to the end user. It's with Evo that we're changing this paradigm.

I much prefer to see on big warning sign pop-up explaining what is going to happen and make multisession default, than to keep PS crawling and stagnating because a legacy keypool size is a mere 1000.

.

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.

 

[crowning]

...(I would avoid messing up with wallet.dat file while wallet is running for now)...

Reminds me that you can do backups from within the wallet (via menu) for ages, it's a Bitcoin feature.
IIRC there's even a RPC call for that.

If we should decide to implement something we could just reuse that.

 

[UdjinM6]

Reminds me that you can do backups from within the wallet (via menu) for ages, it's a Bitcoin feature.
IIRC there's even a RPC call for that.

If we should decide to implement something we could just reuse that.

True! I completely missed that point, will have a look

 

[TanteStefana]

Latest builds (git-4d4a9df) of v0.12.1.x branch

Linux --> https://dashpay.atlassian.net/builds/browse/DASHL-DEV-561/artifact/JOB1/gitian-linux-dash-dist/
Windows --> https://dashpay.atlassian.net/builds/browse/DASHW-DEV-508/artifact/JOB1/gitian-win-dash-dist/
MacOS X --> https://dashpay.atlassian.net/builds/browse/DASHM-DEV-517/artifact/JOB1/gitian-osx-dash-dist/
Raspberry --> https://dashpay.atlassian.net/builds/browse/DASHP-DEV-513/artifact/JOB1/gitian-RPi2-dash-dist/

Changelog:

Merge https://github.com/dashpay/dash/pull/866: [UI] Column alignement of Transaction-Tab adjusted
Merge https://github.com/dashpay/dash/pull/867: Implement an option to enable/disable advanced PrivateSend UI
Merge https://github.com/dashpay/dash/pull/868: checkbox image for wallet themes

Testnet tools (explorers, faucets, pools) --> https://www.dash.org/forum/threads/testnet-tools-resources.1768/

Fingers crossed but my denominations and mixing seem to be working! If its still working a few hours from now, I'd say it's fixed Yaay!

 

[qwizzie]

v0.12.1.0-4d4a9df

Is the default wallet mode suppose to hide all PrivateSend mixing messages and completion status in the overview tab ?
Only flagging the "enable advanced privatesend interface" currently shows them..

Remark : now that we have an advanced PS interface option, we may consider connecting the "Try Mix" and "Reset" buttons to it ... to only get visible in the Overview tab when the advanced PS interface is flagged ?
(if thats technically possible to implement)

 

[UdjinM6]

v0.12.1.0-4d4a9df

Is the default wallet mode suppose to hide all PrivateSend mixing messages and completion status in the overview tab ?
Only flagging the "enable advanced privatesend interface" currently shows them..

Remark : now that we have an advanced PS interface option, we may consider connecting the "Try Mix" and "Reset" buttons to it ... to only get visible in the Overview tab when the advanced PS interface is flagged ?
(if thats technically possible to implement)

https://github.com/dashpay/dash/pull/867
Yes, default is "off" and, yes, it already hides "debug" buttons when it's off. Or... doesn't it hide buttons for you? Which OS?

 

[qwizzie]

https://github.com/dashpay/dash/pull/867
Yes, default is "off" and, yes, it already hides "debug" buttons when it's off. Or... doesn't it hide buttons for you? Which OS?

Damn, you are right, i didn't notice those two buttons (Try Mix & Reset) disappear when it was in default mode and appear again when advanced PS interface is flagged on.
Great job !! Its like you read my mind before i even thought about it
I also didn't read the actual pull, or it would have made perfect sense.
So i can hereby confirm it works well in Windows 10.

We do have a small problem with people mixing from default wallet mode and wanting to stop the mixing. They could be hit with collateral costs as the correct time to stop the mixing (when its idle)
is not shown to them... maybe the wallet could await an idle status before stopping ?

 

[TanteStefana]

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

 

[flare]

Latest builds (git-95ba715) of v0.12.1.x branch

Linux --> https://dashpay.atlassian.net/builds/browse/DASHL-DEV-562/artifact/JOB1/gitian-linux-dash-dist/
Windows --> https://dashpay.atlassian.net/builds/browse/DASHW-DEV-509/artifact/JOB1/gitian-win-dash-dist/
MacOS X --> https://dashpay.atlassian.net/builds/browse/DASHM-DEV-518/artifact/JOB1/gitian-osx-dash-dist/
Raspberry --> https://dashpay.atlassian.net/builds/browse/DASHP-DEV-514/artifact/JOB1/gitian-RPi2-dash-dist/

Changelog:

Merge https://github.com/dashpay/dash/pull/864: govobj sync

Testnet tools (explorers, faucets, pools) --> https://www.dash.org/forum/threads/testnet-tools-resources.1768/

 

[TanteStefana]

Latest builds (git-95ba715) of v0.12.1.x branch

Linux --> https://dashpay.atlassian.net/builds/browse/DASHL-DEV-562/artifact/JOB1/gitian-linux-dash-dist/
Windows --> https://dashpay.atlassian.net/builds/browse/DASHW-DEV-509/artifact/JOB1/gitian-win-dash-dist/
MacOS X --> https://dashpay.atlassian.net/builds/browse/DASHM-DEV-518/artifact/JOB1/gitian-osx-dash-dist/
Raspberry --> https://dashpay.atlassian.net/builds/browse/DASHP-DEV-514/artifact/JOB1/gitian-RPi2-dash-dist/

Changelog:

Merge https://github.com/dashpay/dash/pull/864: govobj sync

Testnet tools (explorers, faucets, pools) --> https://www.dash.org/forum/threads/testnet-tools-resources.1768/

Updated, what was new or fixed in this version? Never mind, it's all gibberish to me anyway, LOL. Can anyone explain how to use the new governance system? I'd think things are going smooth enough to try them out, unless you don't want us messing with anything yet?

 

[yidakee]

@flare @UdjinM6

Crazy idea, need to spit it out.

I was thinking about -multisession and @UdjinM6’s concern about backup issues for the user.
What if we could somehow lock a wallet.dat + deterministic wallet together?

wallet.dat spends 26 or so keys to sign and hash the HD wallet’s seed frase. At the same time, HD signs and hashes the wallet.dat’s password. One seed word per .dat key, one pw character per HD key. Crazy secure, and opens a world of possibilities! (I think). I imagine this is insane coding work, but please bear with me

Example, you could have full control of the HD wallet from a wallet.dat password, or in case of disaster be able to recover a wallet.dat to current state, using just an HD wallet seed. Just need to derive from a 1 of 2 multi-sig relationship for HD wallet to recover .dat’s keys, or vice versa. Both can extract and redeem script keys, right? Maybe this could open up some possibilities.

You could even give “special privileges” to either .dat or HD in some situations, creating a 2 of 3 relationship to balance usage of keys to certain funds, ex: Masternodes.

Since the wallet.dat “owns” the HD seed, it could eventually be used as a sort of HD keypool buffer. Potentially useful for mixing?

Specify one custom change addresses on the .dat redirecting to an HD key… so if .dat destroyed, from seed you could recover the mixing current state by spending all of the wallet.dat keys from that one HD custom change address with multisig privilidges.

On wallet creation QT “links” up and controls the seed, so it can use the HD keys as it pleases. In simpleton terms;

-> create new Wallet.dat

- “Introduce HD seed or Click Here to Generate new HD wallet”
-> = “Please Backup this new Seed phrase”
-> else

- “Introduce Wallet.dat password to confirm”
- “Introduce Seed to confirm”

Does this make any sense at all ?

In this case -multisession could be on by default. All the mix keys could be in the safe possession of a 1 of 2 multisig HD wallet key or seed.

 

[UdjinM6]

@yidakee I'm not not sure I understand... I think HD wallet itself would be enough actually, no need to build complicated schemes.

 

[flare]

Latest builds (git-de64f11) of v0.12.1.x branch

Linux --> https://dashpay.atlassian.net/builds/browse/DASHL-DEV-565/artifact/JOB1/gitian-linux-dash-dist/
Windows --> https://dashpay.atlassian.net/builds/browse/DASHW-DEV-512/artifact/JOB1/gitian-win-dash-dist/
MacOS X --> https://dashpay.atlassian.net/builds/browse/DASHM-DEV-521/artifact/JOB1/gitian-osx-dash-dist/
Raspberry --> https://dashpay.atlassian.net/builds/browse/DASHP-DEV-517/artifact/JOB1/gitian-RPi2-dash-dist/

Changelog:

Merge https://github.com/dashpay/dash/pull/875: Fix color for PS transaction labels
Merge https://github.com/dashpay/dash/pull/872: Dynamically adjust recent tx list item count
Merge https://github.com/dashpay/dash/pull/870: [UI] Masternode Icon Color Adjustment
Merge https://github.com/dashpay/dash/pull/869: [UI] Overviewpage digits and number of recent transactions changed

Testnet tools (explorers, faucets, pools) --> https://www.dash.org/forum/threads/testnet-tools-resources.1768/

 

[TanteStefana]

Ooops, I'm behind updating, but got my 2 tMN up and running, and downloading Windows wallet now

 

[TanteStefana]

I don't know what phase we are on (OP) but I'm assuming we should try phase 2 by now. I am at 99% fully denominated, however, the smaller denominations are taking a lot longer to complete. I can't PS an amount such as 156.456 but I can send 156 coins. Is there a way to either speed up the smaller denominations or else use a larger denom and give back change?

IS is working great

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)

If this ends up true on mainnet, that small denominations take longer, we're going to have frustrated users because everything requires small denominations, so they are the first denominations to be used and last to be created it seems. Is it possible that they are held back in getting mixed? Could they be given order preference?

Another thing is Dash, as it grows in value, will be using smaller denominations more often than large denoms in the future. It might be time to bring them down to the 0.01 or 0.001 range, unless it's easy to add in the future? Or have an "include the excess in transaction fee" option?


NOTE: when I tried to PS and IS 1000 coins to another address, it actually worked. Somehow, I think it decided that the "rounded up" fee of 0.01 was fine, however it won't do this for smaller amounts apparently??

Finally: When I spend a bunch of my PS balance, it immediately denominates fresh coins. This is great because I am having trouble with my main net wallet which doesn't seem to denominate new coins - though this could be because it wants to wait until it can make a larger denomination, and in Testnet, there are plenty of coins to fill the void (2000 coins / 8 rounds)

Hope I'm not doing too much TMI

 

[flare]

Latest builds (v0.12.1.0-b43381c) of v0.12.1.x branch

Linux --> https://dashpay.atlassian.net/builds/browse/DASHL-DEV-566/artifact/JOB1/gitian-linux-dash-dist/
Windows --> https://dashpay.atlassian.net/builds/browse/DASHW-DEV-513/artifact/JOB1/gitian-win-dash-dist/
MacOS X --> https://dashpay.atlassian.net/builds/browse/DASHM-DEV-522/artifact/JOB1/gitian-osx-dash-dist/
Raspberry --> https://dashpay.atlassian.net/builds/browse/DASHP-DEV-518/artifact/JOB1/gitian-RPi2-dash-dist/

Changelog:

Merge https://github.com/dashpay/dash/pull/878: governance propagation

Testnet tools (explorers, faucets, pools) --> https://www.dash.org/forum/threads/testnet-tools-resources.1768/

 

[TanteStefana]

Does this mean we can start playing with governance? Or is that only for developers to play with at the moment?

 

[flare]

Does this mean we can start playing with governance? Or is that only for developers to play with at the moment?

Good question

 

[HinnomTX]

@flare @UdjinM6

Crazy idea, need to spit it out.

I was thinking about -multisession and @UdjinM6’s concern about backup issues for the user.
What if we could somehow lock a wallet.dat + deterministic wallet together?

wallet.dat spends 26 or so keys to sign and hash the HD wallet’s seed frase. At the same time, HD signs and hashes the wallet.dat’s password. One seed word per .dat key, one pw character per HD key. Crazy secure, and opens a world of possibilities! (I think). I imagine this is insane coding work, but please bear with me

Example, you could have full control of the HD wallet from a wallet.dat password, or in case of disaster be able to recover a wallet.dat to current state, using just an HD wallet seed. Just need to derive from a 1 of 2 multi-sig relationship for HD wallet to recover .dat’s keys, or vice versa. Both can extract and redeem script keys, right? Maybe this could open up some possibilities.

You could even give “special privileges” to either .dat or HD in some situations, creating a 2 of 3 relationship to balance usage of keys to certain funds, ex: Masternodes.

Since the wallet.dat “owns” the HD seed, it could eventually be used as a sort of HD keypool buffer. Potentially useful for mixing?

Specify one custom change addresses on the .dat redirecting to an HD key… so if .dat destroyed, from seed you could recover the mixing current state by spending all of the wallet.dat keys from that one HD custom change address with multisig privilidges.

On wallet creation QT “links” up and controls the seed, so it can use the HD keys as it pleases. In simpleton terms;

-> create new Wallet.dat

- “Introduce HD seed or Click Here to Generate new HD wallet”
-> = “Please Backup this new Seed phrase”
-> else

- “Introduce Wallet.dat password to confirm”
- “Introduce Seed to confirm”

Does this make any sense at all ?

In this case -multisession could be on by default. All the mix keys could be in the safe possession of a 1 of 2 multisig HD wallet key or seed.

I'm witnessing a less complicated version of what you describing, right now. The Waves platform launched today. Their setup to receive ICO coins is rather cool. Using an HTML-based client, you enter a 12 word pass phrase of your choice (or they generate one for you). You can use a BIP39 nmemonic if you wish. This is used as the seed for the HD wallet. At the same time, you choose a user name and password. The user name is optional and is really just for convenience, but the password encrypts the local wallet.
From here forward you login to the web-based client using just user name and password. If the local wallet gets trashed or lost you can regenerate it from the HD seed.

To complete the ICO withdrawal process, you enter the receive address generated from the HD seed into their ICO website, and confirm it via email.

 

[qwizzie]

Niceeee

 

[MangledBlue]

Been out of the testing loop for a minute.....
Everything going okay I assume?

 

[TanteStefana]

That last 1% seems to take forever still. I think it's all small denominations too. Is there a theory on why that happens? I would presume everyone needs to mix tiny amounts more so than large amounts, so I don't understand why it's the last and slowest?

Though the lowest denominated sizes get the lowest priorities, which I'm not sure I understand the reasoning? Also, we don't have denominated amounts for 0.01 and I was wondering if maybe we should add that at this point? Our coin is worth almost 10 usd , so it may become useful soon?

There seems to be a trickle down economics in this space. People buy more BTC on a big rise, but instead of cashing out for fiat, they later buy into alt coins after a bit, so I expect to see some of that action in the next month or sooner Unless BTC continues to rise for another month