v13.0 Testing

[strophy]

I see, I thought you were referring to the documentation, not the actual design and implementation of DIP3. I have a brief response, but will let others tackle most of your concerns.

How do you register a collateral address on a hardware wallet, while paying from denominated funds which, by current definition, cannot exist in a hardware wallet? You have to use two different wallets. Can the rest of the protocol comprehend this?

Yes, this is possible. When preparing your registration transaction, specify the collateralHash and collateralIndex on the Trezor as usual. Specify any payoutAddress you like - hardware wallet, mobile wallet, exchange - it doesn't matter. Then use an address in the Dash Core wallet holding mixed funds for feeSourceAddress. I'm not 100% sure how the change address is selected, but it can also go straight back into mixing.

 

[camosoul]

Then use an address in the Dash Core wallet holding mixed funds for feeSourceAddress. I'm not 100% sure how the change address is selected, but it can also go straight back into mixing.

It used to be that only the network traffic was involved to launch a masternode. Now that it's printed on the blockchain, too, there's a whole new web of mess one has to consider for OpSec. It doesn't seem much thought was given to this. Of course, that wasn't really on the to do list...

I'm worried that a lot of people are going to end up compromised without knowing that this exposure vector was created by DIP3. Without having a solid explanation of how it works in the documentation, it's hard to audit it or know what's going on. The documentation reads more like a how-to, just "do this and it'll turn on" but telling the user nothing about what's happening or how it gets done. Proper OpSec requires more than the power button, but that's all the documentation tells us, because it's not really documentation, it's just a "guide." When I read it I'm left with more questions than answers, and no context to even know how to ask it properly... This is why I hate "guides." I realize that the objective is simply to get people online with as little knowledge and effort as possible, but that's dangerously foolish.

When you live under Stasi 2.0 in East Germany 2.0, it matters. A lot. Especially when you're someone (me) who openly and loudly opposes their evil agenda. Since most people involved in Crypto agree with said agenda, it doesn't bother them to see someone like me get smashed by it. In fact, its exactly what they hope for. Crypto has become a worse version of the very monster is was supposedly created to oppose. It's become a life-risking endeavor for anyone that isn't politically extreme-left to be involved in crypto, because people like me don't get a pass like the SJW/snowflakes do. "Laws for thee but not for me." Most of the people posting on this forum can break any laws they want, and never pay any taxes. Nothing will ever be done to them because they are fellow extreme leftists... I'm not afforded the same luxuries. Most of the people on this forum are happily working lockstep with the Stasi 2.0 to make people like me extinct. If they can misrepresent 400+ MNs as mine because this TX isn't isolated, I'll be fraudulently accused of tax evasion at the soonest opportunity. There's no way I'm going to prove my innocence. Show me the judge that would care to listen to the technical complexities of DASH, and how the evidence presented doesn't actually prove anything... All that matters is that I dare to practice wrongthink, and a plausible excuse to make me disappear has been presented. That's how it's done in East Germany 2.0 these days. The only option is to keep everything concealed from, or at least un-provable to, these predatory, sociopathic, lying, commie bastards... Anything they know about WILL be weaponized. Unless you're a fellow leftist, then it'll be ignored and you can do whatever you want. But, I digress... The point is, OpSec matters. Please take it more seriously... Some of us can/will literally be killed for this.

did it
and
did it properly, securely and safely so I don't get murdered in my sleep by Stasi 2.0
Not the same thing.

All we previously had to do was make sure we use tor, and force a different connection every broadcast. We knew everything that might be leaked in network traffic, and how to mitigate it. TCP/IP has been around for a while, so we know what to do... Even if you screw this up, network traffic isn't preserved in a blockchain for all eternity. Oh and never touch your dust, because it'll wreck you. blockchain. eternity.

Since a TX has been added to the MN launch process, we need to know absolutely everything about how that is done and any and all information that might be leaked on the blockchain, so that we might mitigate that leakage. This was just recently invented, and the previous iteration conditioned us to not worry about it and not even ask the question because this vector didn't exist. If you screw up even one time, it will be recorded in the blockchain until the end of time... OpSec matters. DIP3's mode of operation has opened a huge can of worms, and it seems to have gone laregely unnoticed and unmentioned.

I think I'm seeing a work around of using feeSourceAddress.

Create a new wallet. don't use HD. getnewaddress. Send something that had been DS mixed to this address. Specify that as the feeSourceAddress.
Clean up by allowing the change to mix, and accept all dust as a loss because you can't touch it without compromising the previous TXes.
Send what mixes back to original wallet.
srm wallet.dat
or
Somehow identify an existing x16 VIN and it's unique address. Specify this as the feeSourceAddress.
Write off all dust generated as a loss because you can't touch it without compromising all previous TXes.
Since it's not in the Trezor, how does DMT handle this?

There may be some other permutations...

How do I know if a denom is big enough? How big is this fee? What happens if the VIN balance on the specified feeSourceAddress is insufficient? Will it fail? Will there be any feedback to that effect? Or will it seek out unsafe funds elsewhere and use them without telling me? Is the only way to find out, the process of blindly doing it and hoping I don't die? Other failure modes, and what the result will be?

How do I minimize the dust losses I'll accrue as a result of this? Doing this over 400 times... Dust collection superblocks/superTXes, please! Add proper MN blinding or tor-like tunneling of the messages and you've got the basis for a rolling blockchain completely transparent to the user...

This is a lot of damn work for something I don't get paid to do, coupled to the risk to my life that's involved. I may decide not to do it because its just too much of a cumbersome time suck. One mistake and I'm dead. Simplify! I was hoping for a simple "useDSfunds" option to make it more manageable, but I understand why not...

It could be as simple as DMT learning how to select DS mixed VINs as the fee payment source on it's own, checkbox in the UX. Hell, why wouldn't it be the default option? DMT can do the hunting and managing of the feeSourceAddress variable, it knows how to crawl HD... It can parse dash.conf to see the specified mix depth, crawl VINs to see if anything is sufficiently mixed and automatically select what it finds. If it finds nothing, warn the user and disable the "do stuff" button until the option is unchecked (warning the user again of the consequences), or mix depth is achieved. Poll DS balance every 10 minutes? Of course, that's all predicated upon using one's own local RPC... How would DMT know that? The current model doesn't make such a distinction in the server config, maybe a hardcoded "localhost RPC" option? Radio buttons? Localhost RPC or remote?

Sure, the SJWs giggle at the thought of me being dead, but I'm hoping there's still a few people working on DASH that aren't sick communist freaks... If I have to stop this, that's a lot of MNOs that are just going to drop their nodes and cash out. Most of the people I've onboarded to running MNs have already expressed that they wouldn't do it without my help.

This doesn't benefit me alone. I'm just an example... The world in which the most powerful governments really are this evil isn't coming. It's here. Help me live in it?

I thought DAPI was coming a lot sooner, or I would have taken that DMT .onion service more seriously... Never did get dashd to run on the Pi 0...

 

[qwizzie]

If your private key for the payout address is in a separate wallet and you do not specify a feeSourceAddress, you will not be able to submit the transaction since Dash Core will attempt to pay the fee from an address it does not control. Specifying a feeSourceAddress is therefore needed to cover the transaction fee when you submit the transaction.
I have reviewed all DIP3 documentation again today and appreciate any further comments and testing, particularly from hardware wallets using DMT.

I assume we can specify the feeSourceAddress in the v0.13 upgrade procedure Masternode Registration for Dash Core, step : Prepare a ProRegTx transaction ?
Currently in that procedure the "Prepare a ProRegTx transaction" step only shows :

Can we add the feeSourceAddress to it and emphasize this should only be used when the payoutAddress is located on a separate wallet (hardware wallet / exchange wallet, any address not under direct control of the Dash Core wallet).

Maybe even add it as pure text to the v0.13 upgrade guide ("Prepare a ProRegTx transaction" step) here too as last step :

First, we need to get a new, unused address from the wallet to serve as the owner address. This is different to the collateral address. It must also be used as the voting address if Spork 15 is not yet active. Generate a new address as follows:

getnewaddress

yc98KR6YQRo1qZVBhp2ZwuiNM7hcrMfGfz

Then either generate or choose an existing second address to receive the owner’s masternode payouts:

getnewaddress

ycBFJGv7V95aSs6XvMewFyp1AMngeRHBwy

Lastly ... feeSourceAddress .. generate or choose .. etc etc.

getnewaddress

* make sure it has funds (a few duffs) before further proceeding *

Also we need to make sure this works as intended, so we need to test this before release...

 

[f8192]

Excuse me, is PrivateSend supposed to work with integer numbers only? When i type anything with lower denomination it throws an error

 

[camosoul]

You should be able to use numbers down to a single duff, breaking a 0.001 for unmixable change...

Excuse me, is PrivateSend supposed to work with integer numbers only? When i type anything with lower denomination it throws an error

Hmm... UX seem confusing since it shows a balance, but not a DS balance. From that screenshot, we have no way of knowing if you have a sufficient DS balance... Maybe the error is totally appropriate. There's no way you or I can tell... What's going on?

If I type

 ~/.dashcore/dash-cli getwalletinfo

I get

{
  "walletversion": 120200,
  "balance": [redacted],
  "privatesend_balance": [redacted],
  "unconfirmed_balance": [redacted],
  "immature_balance": [redacted],
  ...
}

Very succinct. Exactly what I needed.

...just pointing out why I don't use the QT anymore. It's a pain. Instead of being user friendly, it's annoying and subverts the user's interest. How did DASH end up with a CLI that is an improvement over the GUI?

I had a lot of annoying errors with the QT. All of which seemed to be contradicting itself. When I switched to the CLI I could actually see what was happening and it made a lot more sense. Turns out I wasn't crazy, QT is is crazy.

Would be nice if the GUI showed users what they need to know...

I ran into two conditions where this "insufficient balance" would happen to me, even when I'm not using DS.

1) Not long after having sent a new, very large VIN. Say, 75,000 DASH. The cleint willbreak this into denominations, then start mixing. During the initial denomination process, you can't touch it. The QT won't tell you what's going on. It shows you the balance, but then it tell you you have nothing. You can try to send 0.00000001 DASH and it'll tell you that your balance is insufficient. If you're rolling a "tail -f debug.log" you'll eventually realize that you can't touch your duffs during the denomination process. Nobody will tell you this. It's not documented. The QT won't tell you why. Just wait about half an hour and it'll work. It does not instill confidence. Especially when it seems like the thing has gone haywire by giving you conflicting information about your very large pile of money you can't seem to touch anymore...

2) The QT selects source funds very stupidly. Again, a DS related issue. The QT loves to select VINs that are pending from a mix submission. Nobody will tell you this. It's not documented. The QT won't tell you why. But, when it tries to generate/sign the message, it'll tell you that your balance is insufficient because it picks VINs that are pending. It's dumb.

It'll do this whether you use DS or not, but it a condition caused by not reporting or not noticing that DS is in mid-mixing operation. Again, if you watch tail -f debug.log, and try to hit the command right after a new block lands (grep for "new best" lines), and before DS can accomplish anything or reset it's state after the new block, it'll work perfectly... But, once DS starts doing it's thing, you get dumb, self-contradicting errors that leave you wondering if this thing can be trusted, if you're about to lose everything, or already lost everything... The sane person will try to restart the software, but that just exacerbates the problem... You can end up with a bunch of wallet TXes that never broadcast and need to be zapped... At no point is there any outward indication what's going on or why. It's actually perfectly normal. Just wait. It'll get it's head out of it's butt in about half an hour...

When dealing with the large numbers I do, this crap gives me a heart attack. When I discovered that the CLI doesn't suffer from these problems, I quit using the QT. I don't need this stress in my life.

I also force a restart of the deamon in cron every so often. It used to be my lame way of dealing with the constant crashes. But ever since the malformed block update imported from Bitcoin core, the client runs solid and never crashes anymore. I mean never. Now the cron restarts are there strictly to deliberately re-index and zap all TXes every once in a while. Paranoid habit... Not sure if it's helping not, but I don't have any of these weird problems anymore. Can't wait to go DAPI/light...

One thing that does sometimes happen with using DS from the command line, is that it will pick tons of tiny VINs that result in a "transaction too large" failure. If you're trying to create 1000 DASH outputs from a wallet containing very large amounts of DASH, you'll run into this. You may successfully get a a few dozen 1000 DASH outputs. But, then the next one keeps throwing "transaction too large." What, I'm too big of a whale? No, it actually means the physical size of the transaction is too big, not the amount of DASH. What happened is that the previous 1000 DASH increments were created using all the large VINs. 10s and 1s. All you've got left is a giant heap of .01s. Blocksize limitations being lifted resulted in a condition where each transaction had to be limited in size to prevent a problem. DS doesn't pick what it throws into a TX very wisely. You end up with, say, 1200 DASH worth of .01 that exceeds the TX KB limit if you try a 1000 DASH TX on it. Send to self in a smaller amount. Keep trying smaller numbers until it works. That new VIN will re-denominate with new 10s and 1s. Eventually, it'll all re-mix and you'll be able to make a TX out of it with the new, larger denominations... This definitely bones your privacy... DASH doesn't handle "seismic events" well. and why should it? It's an edge case that almost never happens...

Sadly, it can be said that XMR doesn't have these problems... All of these have been nagging issues for years, which will all be fixed in Evolution... Or so we were told years ago... Here's 0.13 on testnet... 0.13.0.0-RC11 looks like our girl... Evolution is here. I really hope it gets fixed... Only one of the people currently working on DASH was actually around way back then... These loose ends have been left untied for waayyy too long. Most of the team is a bunch of new guys who may not even be aware of it... It may seem like getting blindsided out of left field when a bunch of people start saying "Uhm, what about X, Y, and Z that you promised? Evolution doesn't at all resemble what Evan said it would back in 2015, and all these problems are still problems..." Saying "It's not ready yet, wait for Evolution, it'll all be fixed in Evolution." isn't going to work anymore, because this is Evolution... The rest of the marketplace has "DASH promise fatigue" to the point that nobody takes it seriously anymore... [fingers crossed]

 

[qwizzie]

Excuse me, is PrivateSend supposed to work with integer numbers only? When i type anything with lower denomination it throws an error

I came across these sort of errors too, while trying to PrivateSend certain transactions, i dont think it has anything to do with integer numbers.
What i normally do with PrivateSend transactions these days is :

* Mix to at least 9 rounds (provides pretty strong privacy)
* Try to send a PrivateSend transaction, if your mentioned error occurs you then have two options :

1 : Lower your number of rounds with one round (in this case to 8 rounds) and try to send that PrivateSend transaction again ( this seems to work most of the times as it frees up some input amounts and you still have strong privacy)
2 : Do more mixing by setting your number of rounds higher (in this case to 10 rounds), hit the Start mixing button and when done mixing try to send that PrivateSend transaction again

Setting higher or lower number of rounds to mix can be done through Settings --> Wallet --> PrivateSend rounds to use (which can be set all the way to 16).
Personally i prefer to set the number of rounds to mix a bit higher then strictly necessary, so i can just lower the number of rounds if that PrivateSend error pops up and still have strong privacy.

 

[strophy]

I assume we can specify the feeSourceAddress in the v0.13 upgrade procedure Masternode Registration for Dash Core, step : Prepare a ProRegTx transaction ?

Thanks @qwizzie good catch! I added feeSourceAddress three days ago to the setup guide but forgot it also needed to be added to the upgrade guide. That is now done, together with a short note on what this argument could be used for.

Proper OpSec requires more than the power button, but that's all the documentation tells us, because it's not really documentation, it's just a "guide."

I completely agree and also live in a county where this level of OpSec is a concern. But DCG is responsible for developing and documenting software, not OpSec. It is simply beyond scope of the documentation, which must be written from a neutral perspective and kept as simple as possible so the broadest possible audience (and translators) can comprehend it and complete the task. The DIP on which both the software and documentation are based contains sufficient detail for users needing to take additional security measures.

Never did get dashd to run on the Pi 0...

What errors did you encounter? The official cross-compiled release should run fine under arm-linux-gnu. I recently submitted a PR to fix compilation under armv7l, but it is probably not going to make it into the 0.13 release.

 

[camosoul]

I completely agree and also live in a county where this level of OpSec is a concern. But DCG is responsible for developing and documenting software, not OpSec. It is simply beyond scope of the documentation, which must be written from a neutral perspective and kept as simple as possible so the broadest possible audience (and translators) can comprehend it and complete the task. The DIP on which both the software and documentation are based contains sufficient detail for users needing to take additional security measures.

The point is that what is being called documentation is actually a guide, and no actual documentation exists. This makes finding the needed facts to perform proper OpSec due diligence is next to impossible.

Documentation is exhaustive. A guide covers just barely enough to get from A to B with no details or options. We've got a guide. Not documentation.

I'd gladly RTFM, but there is no FM. Not that I can find...

man dashd

Or at least a well commented config file with commented syntactical examples...

torrc is a good example of how to do this properly with minimal effort... Or course, this wouldn't cover the actual process... Which is why both a guide and proper documentation are both needed.

In fairness, it's not like it's been around for 15 years... Making it go has been the focus, not writing an exhaustive man page...

What errors did you encounter? The official cross-compiled release should run fine under arm-linux-gnu. I recently submitted a PR to fix compilation under armv7l, but it is probably not going to make it into the 0.13 release.

Linux hostname 4.14.9+ #1159 Sun Nov 4 17:28:08 GMT 2018 armv6l

This seems like it would matter...

user@host:~/.dashcore $ ./dashd
Segmentation fault
user@host:~/.dashcore $

No obvious readme about dependencies or some such...

 

[strophy]

man dashd

This exists, but likely doesn't work because Dash is generally installed from a direct download rather than a package manager. If you are using Fedora, @t0dd has packages which should result in man dashd working. I have tried to get similar packages working under Debian/Ubuntu but I just don't have the necessary skill/understanding. Any help here would be welcome. The contents of the manpage are likely similar to the argument/RPC documentation located here: https://docs.dash.org/en/latest/wallets/dashcore/cmd-rpc.html

Linux hostname 4.14.9+ #1159 Sun Nov 4 17:28:08 GMT 2018 armv6l
This seems like it would matter...

Yes, that is likely the problem. I only have an armv7l platform for testing, and I think most devs don't even have that. Devs might respond here to help you troubleshoot what is causing the segfault, but I recommend you open an issue on Github to follow up on this.

 

[t0dd]

This exists, but likely doesn't work because Dash is generally installed from a direct download rather than a package manager. If you are using Fedora, @t0dd has packages which should result in man dashd working. I have tried to get similar packages working under Debian/Ubuntu but I just don't have the necessary skill/understanding. Any help here would be welcome. The contents of the manpage are likely similar to the argument/RPC documentation located here: https://docs.dash.org/en/latest/wallets/dashcore/cmd-rpc.html

Access to Fedora packages can be found here: https://github.com/taw00/dashcore-rpm

man dashd gives me...

DASHD(1)                                                              User Commands                                                             DASHD(1)

NAME
       dashd - manual page for dashd v0.13.0.0

DESCRIPTION
       Dash Core Daemon version v0.13.0.0

   Usage:
       dashd [options]
              Start Dash Core Daemon

OPTIONS
       -?
              Print this help message and exit
...etc...

 

[camosoul]

Well, it's raspbian lite on a pi zero, and that's pretty much the only fully functional distro for it...

I could keep a pi 3, 2, and 0 active and available for fooling around pretty easilly, for any who would, but don't for lack of one, or simply not wanting the clutter...

A pi 0 is what I intended for running a .onion RPC for DMT, but it no workie... I've had the basic system set up for a while, but putting out too many fires to deal with this on the side...

 

[camosoul]

New DMT version notified me that Trezor T Firmware was out of date and tasks could not be performed.

Updated.

New Trezor T Firmware has problems...

When using HD paths of this form:

m/44'/5'/[random9digit]'/0/[random9digit]

Trezor T displays error of:

Path m/44'/5'/[random9digit]'/0/[random9digit] is unknown

with Red X and Green Checkmark
Tapping Green Checkmark results in it proceeding, aparently, properly and as normal.
No explanation. No confirmation that it's working properly or not.
My guess is that some new form of caching/chasing mechanism has been introduced and it's validation process is a bit retarded.

 

[camosoul]

@Bertrand256

Send ProRegTX button often displays error:

Could not generate BLS private key

Keep clicking, eventually it works.

Could not? No mention of why? So diagnostic...

Same error message occurs, seemingly at random, whenever the "Generate New" button for Operator Key is clicked. Click again, it might work, click again, it might throw the very same error.

I occasionally encounter when clicking "Continue":

Invalid operator private key: Key data too large, must be smaller than group order

Whatever the fugg that means... At least it's diagnostic to someone who knows what that means...

This occurs much less frequently, but still appears to be completely random. If new Owner and Operator Keys are successfully generated (without creating any of the previous errors, which happen a lot), trying again is often successful.

Seems to be something wrong with the generation process. The validation mechanism seems to be catching invalid data that should never have been generated? Or the validation mechanism is finding false positives and disliking valid data? I suggest the former due to the can't create it in the first place error wording occurring far more frequently... The second error suggests invalid data is slipping through the validation mechanism, and causes an error in the next step when it does... So, maybe the generation and sanity checking both need a look? False positives? Is it still using testnet methodologies?

Have not encountered these errors by other means, or any other errors, so far...

Concern that sanity checking and keygeneration may not be working fully/properly, and may pass derp to network broadcast... Also makes me question OpSec data leakage.

 

[garysen]

If anyone can spare some tDash for testnet (Dash Core 0.14.0.0) to yMJyv7THUv6nYGKmkvo7ZnMowiYfSarn21, I would be grateful. Thanks!