v0.10.15 - Onyx Release

[crowning]

What does the mostly empty payee list mean?

% darkcoind masternode winners
{
"158167" : "",
"158168" : "",
"158169" : "",
"158170" : "",
"158171" : "",
"158172" : "Xh3BwpkVtkP7xTWTZZceVhq4AGur2Hkzhr",
"158173" : "",
"158174" : "",
"158175" : "",
"158176" : "",
"158177" : "",
"158178" : "",
"158179" : "",
"158180" : "",
"158181" : "XciSwTmxLFgrgAErwfCg1bUkM9gwgj3PsJ",
"158182" : "",
"158183" : "",
"158184" : "",
"158185" : "",
"158186" : "",
"158187" : "",
"158188" : "",
"158189" : "",
"158190" : "",
"158191" : "",
"158192" : "",
"158193" : "",
"158194" : "",
"158195" : "",
"158196" : ""
}

EDIT: masternode count goes down to 314! It happened around 22:00 UTC on Oct 24. The nodes were disconnected when checked with grep. The node cannot be restarted by "masternode start" command.

masternode count works normally here, it says 848 right now.

Empty winners happen here as well, but only for 2 or 3 entries.

The reason is that GetBlockPayee() did not find the payee what actually should not happen.

Looking into the code it looks as either the corresponding transaction could not be found, the output of the transaction could not be found, no out with 1000 DRK could be found or no pubkey of the payee could be found. But all are actually available...
eduffield?

Edit: just debugged this a bit, the winner is simply not found for those blocks.

But what's a bit odd:

"darkcoind getinfo":
...
"blocks" : 158523,
...

"darkcoind masternode winners":
...
"158530" : "Xj8h3aJ6JE8vYZ8ZJtJBgrueW456Drt2Jc",
"158531" : "Xxa9a1yMVsMV2rHcSPGoetHcxjXYTiifa6",
"158532" : "Xn43a8Ebd8nMBZweJUQML5cf6RhRLDdJu9",
"158533" : "XxKbjVqDTQBwy9QArZLu5oNpzfH3c2v1xC",
...

So we're at block 158523 and winners are shown for future blocks?

That's a killer application using /dev/timetravel

(Hint: offset is always 10)

 

[GilAlexander]

earlier if pools will be @ 80% compliance

For the last 394 blocks we have 195 with 25% payment, that is 49%.
Let's bet in darkcoins, ya ya.:grin:

 

[UdjinM6]

57.53%???
I'm starting to think that enforcement/softfork is actually worse then hardfork. If we had a hardfork there would be a lot of forks right now and (f/p)ools was loosing their time and money and that would force them to upgrade or degrade to stabilize network. And that would be the answer of what direction they prefer to move. No need to ask them. "You don't want to go forward? Fine! Masternoders will sell and you (pool) will get nothing but another shitcoin. Is it worse it?"
It's simply unbelievable how stubborn and foolish they are!

PS. Uffff...Sorry for that.
Ok, I feel a little better... (c)

 

[Light]

57.53%???
I'm starting to think that enforcement/softfork is actually worse then hardfork. If we had a hardfork there would be a lot of forks right now and (f/p)ools was loosing their time and money and that would force them to upgrade or degrade to stabilize network. And that would be the answer of what direction they prefer to move. No need to ask them. "You don't want to go forward? Fine! Masternoders will sell and you (pool) will get nothing but another shitcoin. Is it worse it?"
It's simply unbelievable how stubborn and foolish they are!

PS. Uffff...Sorry for that.
Ok, I feel a little better... (c)

Another forking of network would tank the price but hey, how worst can it get We are already less than 2$ a piece.

p.s. Joke aside, I still think we shouldn't rush. Evan knows way more about this system than most of us. If we rush and mess it up again, then it might be hard if not impossible to recover.

 

[crowning]

57.53%???
I'm starting to think that enforcement/softfork is actually worse then hardfork.

Enforcement is actually a (kind of, depends on the exact definition) hardfork.

I think Evan's philosophy to give some pools and Masternode operators some time is the best way to do it.

But I think one week is plenty, a pool operator who can't react in that timeframe has the wrong job.

And, as we see now, pools who don't comply in one week will NEVER comply because they either are greedy or try to trick the system, or both.

Ok, I feel a little better... (c)

Good :smile:

 

[UdjinM6]

Enforcement is actually a (kind of, depends on the exact definition) hardfork.

I think Evan's philosophy to give some pools and Masternode operators some time is the best way to do it.

But I think one week is plenty, a pool operator who can't react in that timeframe has the wrong job.

And, as we see now, pools who don't comply in one week will NEVER comply because they either are greedy or try to trick the system, or both.



Good :smile:

Yes, I know... Sad thing is how top4 is looking now: waffle and x11ltc1btccom get 25% of blocks just to sell DRK for btc/ltc and do not care at all... (I know that's the curse of all altcoins, even LTC suffers from it but...) At the same time coinminepl and suchpool get the 25% and actually taking losses now (comparing to that non-complying pools) and the more we do not enforce the more we "punish" those who comply... that's just something wrong with that situation...

EDIT: while I was writing it got just worse: XhBLSR1HhoaWrdGgrjCHxJkCWWiFFhveHs is #4 now :sad:

 

[splawik21]

How can we push pools to update if they don`t do it in polite way?

 

[feeleep]

Yes, I know... Sad thing is how top4 is looking now: waffle and x11ltc1btccom get 25% of blocks just to sell DRK for btc/ltc and do not care at all... (I know that's the curse of all altcoins, even LTC suffers from it but...) At the same time coinminepl and suchpool get the 25% and actually taking losses now (comparing to that non-complying pools) and the more we do not enforce the more we "punish" those who comply... that's just something wrong with that situation...

EDIT: while I was writing it got just worse: XhBLSR1HhoaWrdGgrjCHxJkCWWiFFhveHs is #4 now :sad:

Totally agree - if we continue in this way all compliant pools will loose. It is just not fair and forcing me to wait till the enforcement to upgrade or change payment schema...

 

[splawik21]

This is last update before instantX (confirmed by Evan) but we need to do them quick ...
Evan give us a shot a couple of days before the release of new wallet version so we can start contacting the pools faster...
splawik21 offers a bucker of vodka to all compliance pools

 

[moli]

This is last update before instantX (confirmed by Evan) but we need to do them quick ...
Evan give us a shot a couple of days before the release of new wallet version so we can start contacting the pools faster...
splawik21 offers a bucker of vodka to all compliance pools

I'm having coffee, too early to have vodka :tongue:
Do you have the pools' emails? Maybe I can help. If those pools' operators set up MNs with their cold drk wallets and participate in earning MNs payment they might have incentive to update their pools quicker?

EDIT: As a matter of fact, instead of being upset over the pools, let's have a campaign.. Let's ask the pools operators and all exchanges who have DRK in cold wallets to set up their own Masternodes, and if they don't know how, show them how or tell them about flare's service which they still can keep their drk in their wallets. I wonder if all these cold wallets can create 2000 MNs in a month, that would be nice.

 

[splawik21]

I'm having coffee, too early to have vodka :tongue:
Do you have the pools' emails? Maybe I can help. If those pools' operators set up MNs with their cold drk wallets and participate in earning MNs payment they might have incentive to update their pools quicker?

EDIT: As a matter of fact, instead of being upset over the pools, let's have a campaign.. Let's ask the pools operators and all exchanges who have DRK in cold wallets to set up their own Masternodes, and if they don't know how, show them how or tell them about flare's service which they still can keep their drk in their wallets. I wonder if all these cold wallets can create 2000 MNs in a month, that would be nice.

For sure they would have the interest to update ASAP

 

[UdjinM6]

Don't get me wrong but I'm trying to understand why do we need to wait for any %% of pools at all and can't find any reasonable answer. Let's assume that we hard forked at any %%. What will happen? Complying pools/qt-wallets/exchanges/masternodes will be on the right fork and all the others on some other fork. Right? Why can't we just do not accept their blocks so they will never get the longest chain? Didn't the problem with forks was only because clients could accept blocks from any fork?

 

[crowning]

What will happen? Complying pools/qt-wallets/exchanges/masternodes will be on the right fork and all the others on some other fork. Right? Why can't we just do not accept their blocks so they will never get the longest chain? Didn't the problem with forks was only because clients could accept blocks from any fork?

Of course you could switch right after you announce a fork, but you risk that the others(!) have the winning chain. The higher the percentage, the lower the risk.

 

[UdjinM6]

I'm having coffee, too early to have vodka :tongue:
Do you have the pools' emails? Maybe I can help. If those pools' operators set up MNs with their cold drk wallets and participate in earning MNs payment they might have incentive to update their pools quicker?

EDIT: As a matter of fact, instead of being upset over the pools, let's have a campaign.. Let's ask the pools operators and all exchanges who have DRK in cold wallets to set up their own Masternodes, and if they don't know how, show them how or tell them about flare's service which they still can keep their drk in their wallets. I wonder if all these cold wallets can create 2000 MNs in a month, that would be nice.

that's good idea but the problem is the non-complying pools only mine DRK to sell it so they do not care and do not have cold wallets

 

[UdjinM6]

Of course you could switch right after you announce a fork, but you risk that the others(!) have the winning chain. The higher the percentage, the lower the risk.

But wouldn't they have a winning chain for themselves only? I mean block should be accepted not only if it fits diff and so on but there must be a check for current MN payment so every other client would reject incorrect block. How can non-complying pools make the winning chain for them then?

 

[moli]

that's good idea but the problem is the non-complying pools only mine DRK to sell it so they do not care and do not have cold wallets

Some have cold wallets, some don't, and we don't know until we try. I've managed to get a pool owner to look into MN and he set up a few MNs, still can't get him to start a MN service though. People normally act on incentives, if there's no incentive for them there's no cooperation. And i'm sure we certainly want people to see darkcoin as something liberal, not like in a police state.

 

[UdjinM6]

Some have cold wallets, some don't, and we don't know until we try. I've managed to get a pool owner to look into MN and he set up a few MNs, still can't get him to start a MN service though. People normally act on incentives, if there's no incentive for them there's no cooperation. And i'm sure we certainly want people to see darkcoin as something liberal, not like in a police state.

well, maybe I was wrong

 

[UdjinM6]

Thinking of hardforking more:
Let's say 90% of exchanges / masternodes / any_other_clients are using correct version and only X% of pools are on correct version and the other (100-X)% of pools are trying to trick it in some way.
Can we make these 90% to only accept blocks from those X% of pools and reject blocks from other (100-X)% because of failed MN payments check? These (100-X)% non-complying pools will left with their chains and "wrong" DRKs that they can't move anywhere. And who cares how big is X then?... Or am I missing something?

 

[Light]

Two questions:

1. Why do we only see 48% and not the rest of the percentages. It used to add up to 100% before:

2. My impression is that this so called "unknown" pool/miner is not just one entity (see. point 3.) but a cluster of smaller miners. IF that's the case a) we need to update the chainz.cryptoid.info properly to avoid confusion and unnecessary panic/ black PR in the future (I can easily see how this can feed into the trolls' hands and be presented as +51% attack) b) what do we know about these miner(s)? Do we have a coping strategy in case 'it/they' decide to unite or increase their hash power etc.?

EDIT:

3. http://drk.poolhash.org/poolhash.html has better info:

 

[splawik21]

Can we using the tx and hash of these unknow blocks/pools to track down their IP so we can know what kids of pool is it?