RC3 Soft Fork

yidakee

Well-known Member
Foundation Member
Apr 16, 2014
1,812
1,168
283
OK, i received a new matured MN payment and this time i used the QT coin control features to select the input to transfer, substracted the 0.001 fee - and it worked: The 1000DRK vin was not touched/changed, only the MN payment tx output was used as new tx input and the masternode is still active.

I guess the CLI does not have a convenient way of choosing the input for a transfer and you have to mess around with rawtransactions :rolleyes:
OMG !! I went though the thread and though "bummer, to offensive for me". Then I realised it was integrated with Bitcoin-QT. So I went in preferences on my Mac's QT and found the Coin Control featured and activated it. How cool!

Just to get it straight, as this starts to get too technical for me. We're payed to the 1k address. As I understand it, vin is tied to a raw tx hash, not an address. When you send funds out, the change is sent to new "hidden" address.

So lets say for example, without coin control, I have 1005 DRKs, and send 1DRK, I would break up the remaining 1004DRK to a new receiving change vin - this breaks the MN.

If you select the 1k deposit in Coin Control, it will send the change back to the same address, but that means a brand new tx hash anyways? In this case, I would receive back 1004k, and not the 1k deposit necessary keep the MN active.

I assume my reasoning is wrong... but do we have to "zero" out the 1000k deposit, or can I just move out 1 DRK, leaving 1004DRK in cold wallet and node active?
 
Last edited by a moderator:

yidakee

Well-known Member
Foundation Member
Apr 16, 2014
1,812
1,168
283
This.

8 of my 20 nodes didnt recieve any payments yet.
Patience, yes. Once it took me 44h on testnet to get first payout.

Node A = 0
Node B = 2
Node C = 1

My first payout was a fluke. 30 minutes in 10.11.4.
 

chaeplin

Active Member
Core Developer
Mar 29, 2014
749
356
133
I have found a bug in nm listing. Thank you.
My nod has 7, darkcoin.io has 7 with diffrent ip.
mynodes
Code:
   "211.99.224.163:9999" : 1,
    "211.99.224.164:9999" : 1,
    "211.99.224.165:9999" : 1,
    "211.99.224.167:9999" : 1,
    "211.99.224.168:9999" : 1,
    "211.99.224.169:9999" : 1,
    "211.99.224.198:9999" : 1,
darkcoin.io
Code:
   "211.99.224.163:9999" : 1,
    "211.99.224.165:9999" : 1,
    "211.99.224.167:9999" : 1,
    "211.99.224.168:9999" : 1,
    "211.99.224.169:9999" : 1,
    "211.99.224.196:9999" : 1,
    "211.99.224.198:9999" : 1,
Graph use ip of (poolhash + darkcoin.io).

NM list use pubkey as primary ip.

I will add darkcoin.io ip address with not matched pubkey.

Code:
Xco4rTXk79VLpiR6H5FSFH2ehpLuvD7hZZ      NET263 Group in China.  China   _._.224.165     +       +       +       +       +       +
XhqYLWmpAjsFUGEGeVwdtrRgjoat3qaNXk      NET263 Group in China.  China   _._.224.198     +       +       +       +       +       +
XjhT8zuFpZ51pgGffL9sWdo9YUKTRReTft      NET263 Group in China.  China   _._.224.163     +       +       +       +       +       +
XpGnXwusb3y8KwxqdRRqzRu7LzxRpYfTE9      NET263 Group in China.  China   _._.224.168     +       +       +       +       +       +
Xpad4FFXcXr1MferfHkQ4Jva5VcWt7qxNh      NET263 Group in China.  China   _._.224.169     +       +       +       +       +       +
XqUjrdjHzobNASyBaob6EsgiYfZtaoiymQ      NET263 Group in China.  China   _._.224.167     +       +       +       +       +       +
XuiyzXZTM8rcoAEBzXo5bN2D967cBAfnV2      NET263 Group in China.  China   _._.224.164     +       +       +       +       +       -
fixed.
Code:
XjhT8zuFpZ51pgGffL9sWdo9YUKTRReTft      NET263 Group in China.  China   _._.224.163     +       +       +       +       +       +
XuiyzXZTM8rcoAEBzXo5bN2D967cBAfnV2      NET263 Group in China.  China   _._.224.164     +       +       +       +       +       -
Xco4rTXk79VLpiR6H5FSFH2ehpLuvD7hZZ      NET263 Group in China.  China   _._.224.165     +       +       +       +       +       +
XqUjrdjHzobNASyBaob6EsgiYfZtaoiymQ      NET263 Group in China.  China   _._.224.167     +       +       +       +       +       +
XpGnXwusb3y8KwxqdRRqzRu7LzxRpYfTE9      NET263 Group in China.  China   _._.224.168     +       +       +       +       +       +
Xpad4FFXcXr1MferfHkQ4Jva5VcWt7qxNh      NET263 Group in China.  China   _._.224.169     +       +       +       +       +       +
-                                       NET263 Group in China.  China   _._.224.196     -       -       -       -       -       +
XhqYLWmpAjsFUGEGeVwdtrRgjoat3qaNXk      NET263 Group in China.  China   _._.224.198     +       +       +       +       +       +
 
  • Like
Reactions: Raico

MykelSIlver

New Member
Apr 25, 2014
28
2
3
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?
 
Last edited by a moderator:

yidakee

Well-known Member
Foundation Member
Apr 16, 2014
1,812
1,168
283
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?
Just like pools finding blocks in a row, and then hours or days without. Its variance. And yes, it can be a bitch.
 

Stray

Member
May 27, 2014
43
14
48
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?
It's the nature of a random voting system, it should even out over time but there will always be a bit of variance. Does your node appear online?
 

Stray

Member
May 27, 2014
43
14
48
I'd definitely give it a day or so and watch the distribution still - Sorry I personally can't be of more help yet, I've yet to set up my own masternode
 

darkzero

Member
Jun 6, 2014
44
35
58
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...
 
  • Like
Reactions: MykelSIlver

MykelSIlver

New Member
Apr 25, 2014
28
2
3
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?
 

darkzero

Member
Jun 6, 2014
44
35
58
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
 
  • Like
Reactions: MykelSIlver

MykelSIlver

New Member
Apr 25, 2014
28
2
3
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. ...?
 

Lariondos

Well-known Member
Foundation Member
Apr 8, 2014
89
61
158
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.
 

MykelSIlver

New Member
Apr 25, 2014
28
2
3
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?
 

Lariondos

Well-known Member
Foundation Member
Apr 8, 2014
89
61
158
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.
 
  • Like
Reactions: MykelSIlver

MykelSIlver

New Member
Apr 25, 2014
28
2
3
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?
 

Lariondos

Well-known Member
Foundation Member
Apr 8, 2014
89
61
158
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:

MykelSIlver

New Member
Apr 25, 2014
28
2
3
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?
 

Lariondos

Well-known Member
Foundation Member
Apr 8, 2014
89
61
158
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.
 

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,286
2,404
1,183
Germany
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 :)
 
  • Like
Reactions: ozziecoin

donho

Member
Masternode Owner/Operator
Apr 16, 2014
96
20
58
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?
 
  • Like
Reactions: jimbit and AjM

Raico

Well-known Member
Foundation Member
Dash Support Group
May 28, 2014
138
142
193
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~!
 
  • Like
Reactions: chaeplin

Lariondos

Well-known Member
Foundation Member
Apr 8, 2014
89
61
158
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:
  • Like
Reactions: ozziecoin

rango

Active Member
Jun 19, 2014
158
221
103
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).
 

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,286
2,404
1,183
Germany
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.
 

yidakee

Well-known Member
Foundation Member
Apr 16, 2014
1,812
1,168
283
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: