It's a Dash Central's bug - it says "Completed payments: no payments occurred yet (3 month remaining)" even though "Payment start/end: 2019-11-15 / 2020-02-12" (i.e. this proposal will disappear in a couple of days).
EDIT: but thanks for keeping an eye on POs anyway ;)
You can use HW wallets (Trezor, Ledger, Keepkey), they don't require you to have the blockchain locally. Can also use Dash Electrum (http://electrum.dash.org/) to access funds if you don't like official wallets from HW wallet manufacturers for some reason. Storing MN collaterals in a software...
1. Most of the money go to proposals of course. You can calculate miner reward as "coinbasevalue - sum(superblock[amount]) - sum(masternode[amount])". See https://github.com/unomp/node-merged-pool/blob/master/lib/transactions.js#L134-L197 as an example.
2. It's probably going to be hard to...
These blocks with 6k+ DASH supply are so called superblocks - blocks in which proposals are paid.
When next block to be mined is a superblock `getblocktemplate` should have `superblock` array filled with items you must include in coinbase tx outputs, just like you must include...
Thanks for letting us know! Do you have the same issue with Bitcoin-Qt too? If not, could you reply to them that miner in Dash-Qt is basically the same thing but for another chain and that it's a legit software? They can verify that there are no hidden things by checking...
That's incorrect. Block supply does not depend on the number of masternodes. The number of masternodes basically represent the length of the payment queue, so the more there are masternodes the less frequent each of them is paid. For example, with 50% less masternodes remaining ones might expect...
Glad you solved it! No need for a payout, I'm happy to help keeping mining space as much decentralized/diversified as possible. We all as a community depend on this after all ;)
PS. Thanks for your kind words :)
Hmmm... Well, let's see:
1. Does this happen for every block? Have you mined at least one block successfully?
2. How often do you query daemon for a new block template?
3. Does your pool use "-blocknotify" or "-zmqpubhashblock"/"-zmqpubrawblock" to stop working on an old block and query for a...
DIP3 coinbase txes should be of a version 3 https://github.com/dashpay/dips/blob/master/dip-0002.md#special-transactions and type 5 https://github.com/dashpay/dips/blob/master/dip-0004.md#coinbase-special-transaction i.e. this
should actually look like this
Hence full tx would be:
You can check if it's a valid key by comparing it to the one in https://github.com/dashpay/dash/tree/master/contrib/gitian-keys
To clarify key ID difference: 6102E091 is his primary key, EC105D04 is a subkey, but both are valid.
Yes, you should start it via usual "masternode start-<smth>" command only for now and wait for DIP0003 to register it as a deterministic one. This post above https://www.dash.org/forum/threads/dash-core-v0-13-on-mainnet.43130/#post-205630 outlines the migration process pretty good.
There is no special rules for this case, will require 101 confirmations like any other coinbase outputs. That's a network-wide rule and I believe all exchanges and wallets handle this properly (they don't even have to care if this is a MN payment or a miner reward, what matters is that it's...
Let me correct this ^^^ a bit. These entries are derived from pubKeyMasternode which is a part of masternode announcement message (mnb). But yes, they are not used until spork15, so you can ignore them for now.
You can use "getblockchaininfo" which should produce output like
"A" has actually 2 phases for 0.13 masternodes:
A1. Before DIP3 activation: Start MN as usual via "start". You won't be able to send ProRegTx yet.
A2. After DIP3 activation: Start MN as usual via "start" if you haven't already, if it's already started, skip to...
Make sure "Options -> Network -> Allow incoming connections" checkbox is on.
Number of outgoing connections going above 8 and down again is ok - it's your wallet asking some masternodes to confirm the state of some another masternode, nothing to worry about.
Only the Owner can set the percentage. I don't see an issue with that because even now operators can charge in Dash. IF it's not what the Operator wants, he can simply charge as usual (i.e. the Owner gets 100% and pays X USD at the end of the month or in any other way the Owner and the Operator...
There is no additional trust in operator, that's not the case - the only special tx operator can sign to update any mn data is ProUpServTx.
i.e. operator can only update node IP and an address he would like to get his share of the reward to and that's it.
2018-12-01 08:01:39 ERROR: ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=39907952)
2018-12-01 08:01:39 *** Failed to read block
i.e. the last block data file is broken. Since you already tried to disable/remove AVs I guess it could be some disk or file system issue...
Yep, this is expected - IS locks are held for 6 blocks on testnet https://github.com/dashpay/dash/blob/master/src/chainparams.cpp#L283 (24 on mainnet https://github.com/dashpay/dash/blob/master/src/chainparams.cpp#L130).
Translations should be fixed by https://github.com/dashpay/dash/pull/2451
Re sync issues: there are a lot of different versions on testnet, things will get better once we rebuild our testnet mn cluster.
To answer every your question specifically:
No. No. No.
In general, DIP3 was modified recently https://github.com/dashpay/dips/pull/21 and @codablock already implemented these changes in https://github.com/dashpay/dash/pull/2412 and https://github.com/dashpay/dash/pull/2427 exactly to...
Dash Core 0.12.3.3 is a critical bugfix release of the Dash Core 0.12.3.x series.
There was a serious vulnerability discovered in Bitcoin Core's codebase recently which
can cause node receiving a specially crafted block to crash https://github.com/bitcoin/bitcoin/pull/14247
We encourage all...
FYI: Moved this thread out of Dash Foundation subforum, not sure why we had it there in the first place...
Maybe it's not the best place for this thread either but I can't find a better one, any suggestions are welcome.
OOM Killer usually kills dashd when it eats way too much memory. Make sure you have enough RAM or you have swap configured. On 1gb VPS for example, a swap file is a must. You can add one this way:
# create 4gb swap file
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
Masternode quorum for InstantSend is determined for each individual input separately, it's not like one single quorum for all txes in one block, not the case. So yes, _some_ txes might fail to lock if there is pretty high percentage of `lazy` masternodes but even in this case failed txes will...