v0.10.17 - Onyx v3

[flare]

Definitely wasn't attempting to trollmode start on you camo. I was pointing out that both Flare and Evan have said this code isn't robust so only use it at your own risk. I can't seem to find Flare's post but he had an experience where all the vin's got muddled up and had to rebuild manually.

I just don't want to see you have an experience where something goes wrong with an un-supported piece of code and that turns into Darkcoin is totally broken thread.

I repeat: start-many is alpha and does not work at the moment - it will select any 1000DRK vin it finds in your wallet, get a line from the masternode.conf and send out a dsee-message to the network. The selection is random and will mess up your setup on the next start-many command.

You may even end up with multiple vins associated with one IP, which is not supported by the masternode --> entries drop off the network.

Because of the above there is no official doc and i discourage usage of this feature at the moment. It does more harm and frustration than good...

Actually this is the only use case of start-many in its current version i can think of: Initial startup of many nodes. Never ever use the command twice on already running nodes.

I fu**** up my own setup that way and had a wonderful time, sorting what vin went to what IP - and ended up doing it from scratch with new IPs.

There is a cause why its not officially supported yet: Its utterly not ready for production!

 

[drkhouse]

It's not idiot-proof, but it's not a complicated bit of code... It works fine if you know it's limitations. It's not rocket surgery and all this hyperbole against using it is baseless. In same-session, it actually does check for in-use VINs already assigned... So far, that's 2 people trying to come out in troll mode who haven't even looked at the code...

It's tie-in to announcement was simply neglected. The feature is still there, it just uses a call for announcement that doesn't exist anymore, so it never broadcasts even though it's output suggests everything is fine. It's really a very small detail... I'd fix this little tidbit myself, but it ain't my place. In fact, if I get the time, I may edit the source and compile my own. It's like one freakin' word, not even a whole line of code... There has never been a lower-hanging fruit. It's hanging so low, even my dumb ass can do it...

I guess it's about priorities. They are already a few things to do on JIRA. It will be done... but DS and instantX is what make this coin epic and will free us from the slavery of inflation (hidden tax)...

 

[Aswan]

Hello everyone,

I haven't been around for quite some time but I am pleased to see there has been a solution implemented to the Dead change issue.

Thanks to everyone who joined the discussion and helped with the issue. Now let's see what other flaws I can find

 

[camosoul]

I just don't want to see you have an experience where something goes wrong with an un-supported piece of code and that turns into Darkcoin is totally broken thread.

Lol, it's not.

I'm just not going to juggle money in a tornado. This feature is more important than it's being treated. I'm trying to add emphasis. You can surge demand for denoms and ix, but if you don't get the MN count, you're going to be a victim of your own success by lack of infrastructure...

From that perspective, MNs are MORE important than denom and ix, because without them, denom and ix don't work... It wouldn't even be a major undertaking to flesh it out.

I understand where the priorities are. That's my point. The priorities need an adjustment or this is going to get top-heavy. Focusing on the flashy stuff, even if it is also fundamentally awesome, still requires the back end to support it and that is being neglected. We could double MN count without budging the market and discouraging entry, all for about 2 hours of work... So, uh, why not?

You may as well argue that we're marketing the trapeze act so well, that we don't need a net...

Splat.

I'm even willing to directly fund a priority adjustment. I know you guys can only afford to work so much for free. So don't. I'll pay someone to flesh out start-all, stop-all, start bymnprivkey stop bymnprivkey, or whatever it turns out to be. It's that damn important and if I'm the only one that can see it, well, those who can, must.

 

[Lukas_Jackson]

qt can't download blocks above 179942 which is 2 days ago. I have 6-8 connection at start. Restarted several times, peers removed. Getpeerinfo gives me all new peers I am connected to

 

[oblox]

qt can't download blocks above 179942 which is 2 days ago. I have 6-8 connection at start. Restarted several times, peers removed. Getpeerinfo gives me all new peers I am connected to

What version? Try -rescan and if not, -reindex if you are using 10.17.19 or 10.17.20.

 

[deusstultus]

Lol, it's not.

I'm just not going to juggle money in a tornado...

It's really down to feature use here. Naturally nodes are important, but optimizing rpc clients designed to this task using masternode start is a better path and seems to provide greater flexibility through ability to target more unique RPC calls.

 

[Lukas_Jackson]

What version? Try -rescan and if not, -reindex if you are using 10.17.19 or 10.17.20.

10.17.19
rescanned- nothing. reindexing now

-reindex is crashing, 3 times now

 

[coingun]

qt can't download blocks above 179942 which is 2 days ago. I have 6-8 connection at start. Restarted several times, peers removed. Getpeerinfo gives me all new peers I am connected to

I had a few of my wallets stall at different block levels when going up from 16.16. I was able to resolve by simply starting and stopping the daemon. I did it rather slowly. Stopped it waited two minutes. Restarted. Not sure if that had any effect.

 

[oblox]

You could always delete everything in the data folder (backup your wallet.dat file obviously) and download fresh from block 1. Then close out the qt client and swap your wallet.dat for the newly generated one there. I'd try what coingun suggests first as downloading the blockchain again will take a while.

 

[Lukas_Jackson]

I had a few of my wallets stall at different block levels when going up from 16.16. I was able to resolve by simply starting and stopping the daemon. I did it rather slowly. Stopped it waited two minutes. Restarted. Not sure if that had any effect.

I've been doing the same thing. Always helped after first restart. First time I have problem with it.
Downloading new blockchain. Will see

New blockchain...problem solved

 

[coingun]

Lol, it's not.

I'm just not going to juggle money in a tornado. This feature is more important than it's being treated. I'm trying to add emphasis. You can surge demand for denoms and ix, but if you don't get the MN count, you're going to be a victim of your own success by lack of infrastructure...

From that perspective, MNs are MORE important than denom and ix, because without them, denom and ix don't work... It wouldn't even be a major undertaking to flesh it out.

I understand where the priorities are. That's my point. The priorities need an adjustment or this is going to get top-heavy. Focusing on the flashy stuff, even if it is also fundamentally awesome, still requires the back end to support it and that is being neglected. We could double MN count without budging the market and discouraging entry, all for about 2 hours of work... So, uh, why not?

You may as well argue that we're marketing the trapeze act so well, that we don't need a net...

Splat.

I'm even willing to directly fund a priority adjustment. I know you guys can only afford to work so much for free. So don't. I'll pay someone to flesh out start-all, stop-all, start bymnprivkey stop bymnprivkey, or whatever it turns out to be. It's that damn important and if I'm the only one that can see it, well, those who can, must.

Point very well taken. I could see a lot of reason's why getting a few things fixed up might go along way with making ix and ds more rebust. We should probably break this discussion out into a seperate thread and elaborate there but for me a few things that would vastly improve the darkcoin noobies experience would be:

In wallet auto updating (we have to update enough this would make everyone's life a dream)
Making it easier for masternode operators to run more nodes (could be a set of utilities written or adjustments to start-many as you pointed out)

Those two things right there would make a lot of people's lives easier. I can see why you think we are putting the cart before the horse pushing too far into new ground but you and I also aren't looking at it through Evan's window pain either. He really truly understands all pieces of the code and thats why he's so eager to keep pushing forward is because those pieces seem robust enough. Perhaps it might be time to discuss a feature freeze after we finalize ix on testnet and it gets pushed out to mainnet. From what pieces of the ix code I've been able to see work in testnet that majority of its pieces are written and ready to roll. While it is hot on his mind we might as well let him finish off those pieces. Then after that we could look at revisiting some of other utilities in our drawers.

 

[oblox]

I do agree with trimming up the jira stuff but at the same time, I would hate further prolonging of masternode obfuscation and potentially secondary blockchain concept to phase out reference nodes.

 

[camosoul]

Making it easier for masternode operators to run more nodes (could be a set of utilities written or adjustments to start-many as you pointed out)

Those two things right there would make a lot of people's lives easier. I can see why you think we are putting the cart before the horse pushing too far into new ground but you and I also aren't looking at it through Evan's window pain either. He really truly understands all pieces of the code and thats why he's so eager to keep pushing forward is because those pieces seem robust enough. Perhaps it might be time to discuss a feature freeze after we finalize ix on testnet and it gets pushed out to mainnet. From what pieces of the ix code I've been able to see work in testnet that majority of its pieces are written and ready to roll. While it is hot on his mind we might as well let him finish off those pieces. Then after that we could look at revisiting some of other utilities in our drawers.

I'm not saying "drop what you're doing and obey my whims!!!"

I'm encouraging a feature that will shrink my own piece of the pie. I'm back to my only contribution to DRK being a stack of Neptunes on xpool at the very moment that I had driven all over the countryside collecting backups to throw about 40 more MNs up... Then, [stinky fart nosies] all over my parade. Yeah, I'm a bit miffed. But that's not the damn point. I don't matter. That's over 50 MNs that don't exist now because I'm sure as hell not going to juggle them.

I will not post on the topic in this thread any further, you're right, it is a bit OT. But, it really shouldn't be OT when a feature, even a barely working feature, goes from "meh sorta" to "completely dead," when it did so much good for the network... And when it's still there and working, it's just been cut off from the announcement call... Seriously, change one word and it's fixed and working again!

Might be able to use the .10.16 client to fire the announcement, but keep the nodes running .10.17... <-- that doesn't work, for reasons that should have been obvious before I tried it...

That debug output is ridicuflood...

Nodes down until polystart is re-plugged-in to the rest of the code.

It's merely syntactical, but maybe "polystart" "polystop" "monostart mnprivkey" "monostop mnprivkey" "somekindastart mnprivkeyA, mnprivkeyD, mnprivkeyZ"

I'll fuck off now.

 

[moli]

Trying to denominate on V3 but keep getting dseep msgs.

Is this normal?

2014-12-05 15:59:51 Submitted to masternode, waiting in queue .
2014-12-05 15:59:51 AcceptToMemoryPool (tx): 176.126.247.191:9999 /Satoshi:0.10.17.19/ : accepted 9b62cd34d743043073d3f1e1026d8b545f427dfeec4e1c45300eaf3518a564e2 (poolsz 9)
2014-12-05 15:59:51 dseep - Couldn't find masternode entry CTxIn(COutPoint(2408f5405306ec5e57853d32c2853ccf72849ef781ebe85bdb7d38e2297278fd, 1), scriptSig=)
2014-12-05 15:59:51 dseep - Couldn't find masternode entry CTxIn(COutPoint(cf32d891a3b8122e1bafc65bc841594d2e89d65893b8c27456a97bb83d603bb4, 0), scriptSig=)
2014-12-05 15:59:51 dseep - Asking source node for missing entry CTxIn(COutPoint(cf32d891a3b8122e1bafc65bc841594d2e89d65893b8c27456a97bb83d603bb4, 0), scriptSig=)
2014-12-05 15:59:51 dseep - Couldn't find masternode entry CTxIn(COutPoint(cf32d891a3b8122e1bafc65bc841594d2e89d65893b8c27456a97bb83d603bb4, 0), scriptSig=)
2014-12-05 15:59:51 dseep - Couldn't find masternode entry CTxIn(COutPoint(cf32d891a3b8122e1bafc65bc841594d2e89d65893b8c27456a97bb83d603bb4, 0), scriptSig=)
2014-12-05 15:59:52 dseep - Couldn't find masternode entry CTxIn(COutPoint(cf32d891a3b8122e1bafc65bc841594d2e89d65893b8c27456a97bb83d603bb4, 0), scriptSig=)
2014-12-05 15:59:52 dseep - Couldn't find masternode entry CTxIn(COutPoint(bd8c364673a8d7acbd8320ccc9598c6fd6b4036461b567e6203f1c6827dd5ee8, 1), scriptSig=)
2014-12-05 15:59:52 dseep - Asking source node for missing entry CTxIn(COutPoint(bd8c364673a8d7acbd8320ccc9598c6fd6b4036461b567e6203f1c6827dd5ee8, 1), scriptSig=)
2014-12-05 15:59:52 dseep - Couldn't find masternode entry CTxIn(COutPoint(bd8c364673a8d7acbd8320ccc9598c6fd6b4036461b567e6203f1c6827dd5ee8, 1), scriptSig=)
2014-12-05 15:59:52 dseep - Couldn't find masternode entry CTxIn(COutPoint(e1580a60dcaa038cc1fe6b8a8528a146ba7c66e5592ebeb1cdee047caa71aaf7, 1), scriptSig=)
2014-12-05 15:59:52 dseep - Asking source node for missing entry CTxIn(COutPoint(e1580a60dcaa038cc1fe6b8a8528a146ba7c66e5592ebeb1cdee047caa71aaf7, 1), scriptSig=)
2014-12-05 15:59:52 dseep - Couldn't find masternode entry CTxIn(COutPoint(bd8c364673a8d7acbd8320ccc9598c6fd6b4036461b567e6203f1c6827dd5ee8, 1), scriptSig=)
2014-12-05 15:59:52 dseep - Couldn't find masternode entry CTxIn(COutPoint(bd8c364673a8d7acbd8320ccc9598c6fd6b4036461b567e6203f1c6827dd5ee8, 1), scriptSig=)
2014-12-05 15:59:52 dseep - Couldn't find masternode entry CTxIn(COutPoint(e1580a60dcaa038cc1fe6b8a8528a146ba7c66e5592ebeb1cdee047caa71aaf7, 1), scriptSig=)
2014-12-05 15:59:52 dseep - Couldn't find masternode entry CTxIn(COutPoint(f87abb479826b9d6b4dd3046e6c4f85983fae510234d6b2d52a23b06880cab50, 0), scriptSig=)
2014-12-05 15:59:52 dseep - Asking source node for missing entry CTxIn(COutPoint(f87abb479826b9d6b4dd3046e6c4f85983fae510234d6b2d52a23b06880cab50, 0), scriptSig=)
2014-12-05 15:59:52 dseep - Couldn't find masternode entry CTxIn(COutPoint(f87abb479826b9d6b4dd3046e6c4f85983fae510234d6b2d52a23b06880cab50, 0), scriptSig=)

Are you on Testnet or Mainnet? And I guess you meant version 10.17.19?

 

[vertoe]

What about a new bounty fund where people can vote for the features which will be implemented by people who are willing to code for DRK?

I was thinking about this for a while. The Devs are so involved with the main features that smaller tasks could take ages otherwise. This could be a way to attact more developer power...

 

[Ignition75]

What about a new bounty fund where people can vote for the features which will be implemented by people who are willing to code for DRK?

I was thinking about this for a while. The Devs are so involved with the main features that smaller tasks could take ages otherwise. This could be a way to attact more developer power...

I believe the Darkcoin Foundation is trying to organise something along these lines. As another option we could bunch up a piece of work and crowd fund it.

 

[crowning]

What about a new bounty fund where people can vote for the features which will be implemented by people who are willing to code for DRK?

I was thinking about this for a while. The Devs are so involved with the main features that smaller tasks could take ages otherwise. This could be a way to attact more developer power...

I like this...and I don't.

On one side it would perhaps really get things done,

But the rich get there wishes implemented, the poor poor don't. Exactly like it is now with fiat money...

 

[yidakee]

I like this...and I don't.

On one side it would perhaps really get things done,

But the rich get there wishes implemented, the poor poor don't. Exactly like it is now with fiat money...

Its not like we're rowing in different directions. If people fund code for DRK, we all benefit, and the quicker the "poor's wishes" get done.

 

[Otoh]

With the latest update I find that the wallet auto locks after you send coins, so when setting up Masternodes it involves one extra step now of having to unlock the wallet between each 1,000 DRK sent, I preferred it to stay unlocked for the time that I'd set when working or until the wallet was closed, are there any advantages in having it lock after every send coin transaction?