RC3 Soft Fork

MykelSIlver said:
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?
Click to expand...
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...
 
darkzero said:
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...
Click to expand...
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?
 
MykelSIlver said:
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?
Click to expand...
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. ...?
 
MykelSIlver said:
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. ...?
Click to expand...
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.
 
Lariondos said:
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.
Click to expand...
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?
 
MykelSIlver said:
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?
Click to expand...
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.
 
Lariondos said:
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.
Click to expand...
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?
 
MykelSIlver said:
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.
Click to expand...
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:
Lariondos said:
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.
Click to expand...
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?
 
MykelSIlver said:
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?
Click to expand...
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.
 
Lariondos said:
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.
Click to expand...
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?
 
chaeplin said:
fixed.
Click to expand...
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~!
 
flare said:
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 :)
Click to expand...
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).
 
rango said:
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).
Click to expand...

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.
 
flare said:
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.
Click to expand...

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:
You must log in or register to reply here.
Back
Top