It appears that Ledger is confused by Dash special transactions (like the coinbase tx) and just interprets the entire tx as a fee in that case. Thankfully that is not the case :).
Always best to go directly to the source and not rely on indirectly getting information from Discord bots: https://github.com/dashpay/dash/pulse/monthly
And so the fact that Core commits to the develop branch rather than directly to the default branch doesn't cause confusion, see the recent...
We're excited to announce the release of DIP 29, which introduces and describes the protocol changes necessary to use a randomness beacon for quorum member selection. By transferring finality of the randomness creation from Proof of Work to this randomness beacon, an attacker with high hash...
The Core RPCs used by sentinel were updated in the PR below so they will no longer interact with sentinel. Core will effectively ignore sentinel so governance won't be affected if someone doesn't explicitly disable sentinel. Disabling the cronjob would definitely make sense though...
But conversely, if someone has a large percentage of MNs, they could simply run custom-compiled code to disable whatever MN-provided services they didn't like or lock only blocks/transactions they preferred - without breaking consensus rules. Ultimately I doubt a state-level actor would attack...
You could try checking a tool like https://github.com/primal100/pybitcointools for this. I can't vouch for the security of it, but it claims to have Dash support and can probably at least put you on the right track.
I agree - an increase in decentralization of masternode hosting is desirable.
Regarding the fork, the rules are the same as for all recent hard forks (some previous responses here and here), so the threshold for lock-in/activation was 80% of miner signaling (although it appears that 100% of...
The Dash Core v19 hard fork status has changed to "locked in" today due to miner signalling! 🚀
This means the hard fork height will be block 1899072 in approximately one week (late in the day UTC time on July 5) . As previously mentioned, nodes and miners are that have not updated by that time...
There is a spork related to PoSe, but for this release it was not changed. So no action is needed by DCG. Masternodes just need to upgrade to get PoSe rolling. The 80% is simply the point at which DKG sessions are able to form in a way that enables PoSe to begin working really well (I believe it...
Masternodes don't really put the activation at risk. Based on miner signaling, the network _will_ hard fork once the activation is locked in. Masternodes not upgraded by that time will stop following the chain that the miners are creating and be forked off.
Of course, it would not be ideal for...
I should mention also that PoSe scores will ramp up especially as MN adoption of v19 gets up to 80%. Once we hit that, v18 nodes should start getting scored/banned regularly.
As xkcd mentioned, it only scores the nodes that were determined to not be participating correctly (by consensus during DKG). There is a minimum number of MNs required to form each quorum type, so there is a floor to how many MNs could be scored in a particular session. For example, the quorum...
Yeah, somewhere around 3 days from now is when we will see what miners have upgraded so far. I recommend looking at https://www.dashninja.pl/blocks.html. Once miners start signaling there will be a second Block Version that shows up in the "Per Version Statistics (last 24h)" section. The owner...
I'm assuming you already have been looking at these pages, but I'll link to them in case you haven't and for the benefit of anyone else that stumbles onto this post.
https://docs.dash.org/en/stable/docs/user/introduction/features.html#coinjoin...
My understanding is that it's similar to the BLS operator key pair used in Core, but it will be used by Platform (Tenderdash IIRC). Ivan or Łukasz could explain more fully what will be signed with that key.
We're excited to announce the release of DIP 28, which introduces and describes the protocol changes necessary for implementing High-Performance Masternodes. High-Performance masternodes will be responsible for hosting Dash Platform services and existing features like ChainLocks and InstantSend...
Also, under the current system, everyone in the system (miners, masternodes, full nodes) needs to be able to verify that each block pays the correct masternode. If that is known, payouts are linkable to the receiving party irrespective of address re-use or some other scheme that doesn't re-use...
According to https://dashcore.readme.io/docs/core-api-ref-remote-procedure-calls-network#getnetworkinfo, it is:
"The number of incoming connections during the uptime of this node that have used this address in their version message."
Normally you can check what fields are by running the "help...