Access to Fedora packages can be found here: https://github.com/taw00/dashcore-rpm man dashd gives me... Code: 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...
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...
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: Code: m/44'/5'/[random9digit]'/0/[random9digit] Trezor T displays error of: Code: 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.
@Bertrand256 Send ProRegTX button often displays error: Code: 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": Code: 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.
