RC3 Soft Fork

yidakee · Jun 27, 2014

flare said:
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

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?

yidakee · Jun 27, 2014

vertoe said:
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 · Jun 27, 2014

chaeplin said:

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     +       +       +       +       +       +

thelonecrouton · Jun 27, 2014

First payment received, woohoo!

MykelSIlver · Jun 27, 2014

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?

yidakee · Jun 27, 2014

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?

Just like pools finding blocks in a row, and then hours or days without. Its variance. And yes, it can be a bitch.

Stray · Jun 27, 2014

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?

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?

MykelSIlver · Jun 27, 2014

Stray said:
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?

On Every list. Look at https://www.darkcoin.io/masternodes.txt , https://elbzo.net/masternodes.html at address XrBXkgRuKUoJVVoWuPn75AHtSAFWSi7fED (ip 80.240.140.196 ). Online since the beginning of the masternodes idea

Stray · Jun 27, 2014

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

MykelSIlver · Jun 27, 2014

Stray said:
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

Good luck.
I have set it up from http://planetcrypton.com/install-darkcoin-daemon ...But maybe that is the reason it does not work...

darkzero · Jun 27, 2014

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?

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...

MykelSIlver · Jun 27, 2014

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...

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 · Jun 27, 2014

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?

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

MykelSIlver · Jun 27, 2014

Anyone knows where I can download an older client binaries (Linux)? On this location (http://www.darkcoin.io/getstarted.html) only the lastest (v0.10.11.5) can be downloaded.
I need version (v0.10.11.4)... Anyone?

MykelSIlver · Jun 27, 2014

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 · Jun 27, 2014

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. ...?

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 · Jun 27, 2014

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.

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 · Jun 27, 2014

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?

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.

MykelSIlver · Jun 27, 2014

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.

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 · Jun 27, 2014

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.

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.

MykelSIlver · Jun 27, 2014

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.

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 · Jun 27, 2014

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?

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.

HashEngineering · Jun 27, 2014

I have a question regarding updating the code for the Android Wallet to work with the current darkcoin network.
https://darkcointalk.org/threads/android-wallet.383/page-3

flare · Jun 27, 2014

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.

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

donho · Jun 27, 2014

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?

Raico · Jun 27, 2014

chaeplin said:
fixed.

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~!

Lariondos · Jun 27, 2014

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

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.

rango · Jun 28, 2014

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 · Jun 28, 2014

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).

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 · Jun 28, 2014

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.

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.

RC3 Soft Fork

Well-known Member

Well-known Member

Active Member

Well-known Member

New Member

Well-known Member

Member

New Member

Member

New Member

Member

New Member

Member

New Member

New Member

Well-known Member

New Member

Well-known Member

New Member

Well-known Member

New Member

Well-known Member

Active Member

Grizzled Member

Member

Well-known Member

Well-known Member

Active Member

Grizzled Member

Well-known Member