• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

RC3 Soft Fork

Is it possible that with the current voting system some nodes never get paid? And some will get paid twice in a row?

EDIT: I see some nodes has already paid twice (today and yesterday) while my node isn't paid yet... Again: No errrors, appear in every list. Still patience or can there be something wrong?
Correct me if i'm wrong but i noticed this:

if you look at "masternode votes" you may see your address has been selected for payout, but if the solver of the block has an old client (hasn't updated yet) you simply won't get the payout!!
Check for instance this list

{
"92576" : "OP_DUP OP_HASH160 bfc7ad176d4cc9d57d80886902ae101a2778a34d OP_EQUALVERIFY OP_CHECKSIG",
"92577" : "OP_DUP OP_HASH160 d103945d6df7985c180f7c2aaab410a412d5099f OP_EQUALVERIFY OP_CHECKSIG",
"92578" : "OP_DUP OP_HASH160 79c98af1ede7745cf8a1048fcfc363b4e6d310ac OP_EQUALVERIFY OP_CHECKSIG",
"92579" : "OP_DUP OP_HASH160 6301f588f54a451321acd1edb84f2a493fedfeb1 OP_EQUALVERIFY OP_CHECKSIG",
"92580" : "OP_DUP OP_HASH160 af35565feb70581e03598874ba80dc07d27efe0d OP_EQUALVERIFY OP_CHECKSIG",
"92581" : "OP_DUP OP_HASH160 a40805b52d5e7fa339114ce831d74873bafc8d59 OP_EQUALVERIFY OP_CHECKSIG",
"92582" : "OP_DUP OP_HASH160 bee6a08aed6715506935a06f2ffea658954892ae OP_EQUALVERIFY OP_CHECKSIG",
"92583" : "OP_DUP OP_HASH160 a394877c9fa57eec644b7402dcdb969a3b3a4548 OP_EQUALVERIFY OP_CHECKSIG",
"92584" : "OP_DUP OP_HASH160 5ca7c8a124c6c655ac14623cc28e35dd8a77f6e7 OP_EQUALVERIFY OP_CHECKSIG",
"92585" : "OP_DUP OP_HASH160 52f37ed89ea9a4e0bfd5d8d2ed90e52f692b378c OP_EQUALVERIFY OP_CHECKSIG"
}

2 minutes ago 06/27 15:30:15 92584 [1][2] 3890.267 5 pool_unknown_116 -
4 minutes ago 06/27 15:28:20 92583 [1][2] 3942.899 5 wafflepool XqbmuWojT5bxbJgTizUsACykzds8GY4fCv 1.000200
6 minutes ago 06/27 15:26:06 92582 [1][2] 3954.389 5 suchpool Xt6EVxK2tEXVuqokqAKXhkiEWdeCGaaZkB 1.001200

Check on the blockchain these addresses:

for 92584 5ca7c8a124c6c655ac14623cc28e35dd8a77f6e7 no payout -> pool not updated
for 92583 a394877c9fa57eec644b7402dcdb969a3b3a4548 payout txid c97d1943bdbf84829782d414bd62587b56bbbeea51df369aecdc2f39b4a20d52

and so on...
Variance or not, the votes you may have received are gone...
 
Correct me if i'm wrong but i noticed this:

if you look at "masternode votes" you may see your address has been selected for payout, but if the solver of the block has an old client (hasn't updated yet) you simply won't get the payout!!
Check for instance this list

{
"92576" : "OP_DUP OP_HASH160 bfc7ad176d4cc9d57d80886902ae101a2778a34d OP_EQUALVERIFY OP_CHECKSIG",
"92577" : "OP_DUP OP_HASH160 d103945d6df7985c180f7c2aaab410a412d5099f OP_EQUALVERIFY OP_CHECKSIG",
"92578" : "OP_DUP OP_HASH160 79c98af1ede7745cf8a1048fcfc363b4e6d310ac OP_EQUALVERIFY OP_CHECKSIG",
"92579" : "OP_DUP OP_HASH160 6301f588f54a451321acd1edb84f2a493fedfeb1 OP_EQUALVERIFY OP_CHECKSIG",
"92580" : "OP_DUP OP_HASH160 af35565feb70581e03598874ba80dc07d27efe0d OP_EQUALVERIFY OP_CHECKSIG",
"92581" : "OP_DUP OP_HASH160 a40805b52d5e7fa339114ce831d74873bafc8d59 OP_EQUALVERIFY OP_CHECKSIG",
"92582" : "OP_DUP OP_HASH160 bee6a08aed6715506935a06f2ffea658954892ae OP_EQUALVERIFY OP_CHECKSIG",
"92583" : "OP_DUP OP_HASH160 a394877c9fa57eec644b7402dcdb969a3b3a4548 OP_EQUALVERIFY OP_CHECKSIG",
"92584" : "OP_DUP OP_HASH160 5ca7c8a124c6c655ac14623cc28e35dd8a77f6e7 OP_EQUALVERIFY OP_CHECKSIG",
"92585" : "OP_DUP OP_HASH160 52f37ed89ea9a4e0bfd5d8d2ed90e52f692b378c OP_EQUALVERIFY OP_CHECKSIG"
}

2 minutes ago 06/27 15:30:15 92584 [1][2] 3890.267 5 pool_unknown_116 -
4 minutes ago 06/27 15:28:20 92583 [1][2] 3942.899 5 wafflepool XqbmuWojT5bxbJgTizUsACykzds8GY4fCv 1.000200
6 minutes ago 06/27 15:26:06 92582 [1][2] 3954.389 5 suchpool Xt6EVxK2tEXVuqokqAKXhkiEWdeCGaaZkB 1.001200

Check on the blockchain these addresses:

for 92584 5ca7c8a124c6c655ac14623cc28e35dd8a77f6e7 no payout -> pool not updated
for 92583 a394877c9fa57eec644b7402dcdb969a3b3a4548 payout txid c97d1943bdbf84829782d414bd62587b56bbbeea51df369aecdc2f39b4a20d52

and so on...
Variance or not, the votes you may have received are gone...
Hmmm, the solver of the block........ I know I have the latest version, but you say, that the one who solved the block must have also the same version (=latest version) ? Is that what you mean. So It is safer for me to have an older version? Because that is compatible with older clients?
 
Hmmm, the solver of the block........ I know I have the latest version, but you say, that the one who solved the block must have also the same version (=latest version) ? Is that what you mean. So It is safer for me to have an older version? Because that is compatible with older clients?
I actually meant the the pool that can be found in the column "Who" of page http://drk.poolhash.org/
and i only noticed that if it's not updated there is no payout
 
It would also be handy when the pool updates his client, this pool also process the payments which did succeed because of the older client of the pool. ...?
 
It would also be handy when the pool updates his client, this pool also process the payments which did succeed because of the older client of the pool. ...?
No need to downgrade. If your node is selected, you get a payout if the pool's client version is on 0.10.11.4 or above.
 
No need to downgrade. If your node is selected, you get a payout if the pool's client version is on 0.10.11.4 or above.
But I have version 0.10.11.5. The Pool has 0.10.11.4. That caused that I haven't been paid yet.... So I need to downgrade to 0.10.11.4, because the pool does currently not support 0.10.11.5.

Correct?
Or when the pool upgrade to 0.10.11.5, the failed payments because of this, will occur automatically?
 
But I have version 0.10.11.5. The Pool has 0.10.11.4. That caused that I haven't been paid yet.... So I need to downgrade to 0.10.11.4, because the pool does currently not support 0.10.11.5.

Correct?
Or when the pool upgrade to 0.10.11.5, the failed payments because of this, will occur automatically?
Not correct. The versions don't have to be equal, they must be compatible. This is the case. The pool doesn't know your client's or MN's version but just writes the block to the right chain.
 
Not correct. The versions don't have to be equal, they must be compatible. This is the case. The pool doesn't know your client's or MN's version but just writes the block to the right chain.
If you re-read the discussion of the failed payments on the top in this thread(https://darkcointalk.org/threads/rc3-soft-fork.1576/page-6). How do you explain the failed payments mentioned by darkzero? Thanks in advance.

EDIT: Is it also worth a shot for me to rebuild the chain by executing the client with the rebuild option?
 
If you re-read the discussion of the failed payments on the top in this thread(https://darkcointalk.org/threads/rc3-soft-fork.1576/page-6). How do you explain the failed payments mentioned by darkzero? Thanks in advance.
I think you misinterpreted the part about not paying pools. MN payments are enabled as soft fork since version 0.10.11.4. Only miners who are on this version or above (or an older version which previously enabled 10% payments) can generate the MN payment. There is no direct connection to your own version. If your node is elected an a miner with a lower version finds the next block, you get nothing.
 
Last edited by a moderator:
I think you misinterpreted the part about not paying pools. MN payments are enabled as soft fork since version 0.10.11.4. Only miners who are on this version or above (or an older version witch previously enabled 10% payments) can generate the MN payment. There is no direct connection to your own version.
Thanks. Any idea who could be the case in my situation? The only thing I can do is to be patient? All looks well at my side (no errors, appear in lists, have 0.10.11.5...). Anything to add to this discussion?
 
Thanks. Any idea who could be the case in my situation? The only thing I can do is to be patient? All looks well at my side (no errors, appear in lists, have 0.10.11.5...). Anything to add to this discussion?
If your MN is on the list and ok, you can't do much. 50% of my nodes didn't receive anything since yesterday, but one single node alone received 6 payments. So be prepared for the first time a payment hits you.
 
If your MN is on the list and ok, you can't do much. 50% of my nodes didn't receive anything since yesterday, but one single node alone received 6 payments. So be prepared for the first time a payment hits you.
Same for me, only one out of four nodes received payments, but this one received six payments so far. So in average it levels out for me :)
 
I don't know if someone has already suggested this. But I think a really nice feature for the next RC would be the option to set a payout address for the MN payments in the cold wallet.
So one has the option to set an address of a hot or another cold wallet to get the masternode payments send to.
To change the address one would obviously need to unlock the cold wallet with the 1000DRK once and then put in a payment address.
Once this is done you would only have to access the cold MN wallet if you want to access the 1000DRK. And you could manage the payments on another wallet.
Thoughts?
 
Thank you~ chaeplin~for what you've done to the community.

Although one of my Masternode's IP should be *.166 which showed *.198 on the list. i'm very glade that info may help you fix a bug.
i will keep that "strange" Masternode running this weekend and see what will happen~.

eduffield flare chaeplin or dev team for not mentioned by my limited
if you want any information like debug.log, just let me know.

Hat off for everyone, Great work~!
 
Same for me, only one out of four nodes received payments, but this one received six payments so far. So in average it levels out for me :)
So far the variation seems to work as expected. I had mentioned differences a few days ago on testnet (25 against 55 payments for 24 hours). Now, a few days later, there are only small differences between the nodes.
On mainnet it will need not days, but weeks until the distribution might look fair. The fact that not all pools pay the MN share makes this ride even bumpier. I have the feeling that with just one node you could wait a week and are still covered by the variation to be expected.
 
Last edited by a moderator:
If network is fine, it might be a good idea to enable "enforcing".

All pools/miners who updated to masternode payment, suffer from a competetive disadvantage. 40% of the market players in DRK mining seem to refuse to update for their own profit (profit of 20% per block vs. pools who updated).
 
If network is fine, it might be a good idea to enable "enforcing".

All pools/miners who updated to masternode payment, suffer from a competetive disadvantage. 40% of the market players in DRK mining seem to refuse to update for their own profit (profit of 20% per block vs. pools who updated).

Network has to gain "payout adoption rate" first - if 40% of overall network hash still belongs to bad players, enabling the enforcement now would put the network at risk of forks.
 
Network has to gain "payout adoption rate" first - if 40% of overall network hash still belongs to bad players, enabling the enforcement now would put the network at risk of forks.

That will be a problem as the majority is "pool_unknown". I was under the impression that now with the "spork" option Evan can switch on/off the enforcement without risk of forks. And with enforcement, block would just be orphaned with the new hashing algo. Last time we didnt really fork, and the network was reaching consensus, just out of block-time.

How about short bursts of enforcement? At first sign of trouble revert back and check logs?
Bad players are either daft & greedy for the extra 20%, or just dont care, or do not check up on the Dark-news.

We cant really depend on "bad players" to start playing nice, for us to get going.
 
Last edited by a moderator:
Back
Top