RC4 issues, bugs & feature requests

Status
Not open for further replies.

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Yes i am speaking about latest stable version. I don't use closed-source RC at all.
I'm not sure what you mean about "closed-source RC". As I understand the only closed-source is Darksend. Did you download the stable v.0.9.12.32 from darkcoin.io? Check your version.
 

splawik21

Grizzled Member
Dash Core Team
Moderator
Foundation Member
Dash Support Group
Apr 8, 2014
1,917
1,274
1,283
I'm not sure what you mean about "closed-source RC". As I understand the only closed-source is Darksend. Did you download the stable v.0.9.12.32 from darkcoin.io? Check your version.
yes I think he is talking abount 9.12.32
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
I am.

moli Closed-source RC is the Darkcoin wallet version with Darksend. I don't have "hidden" processes. The CPU usage was strictly from darkcoin-qt.
I think you can trust Evan with his closed source Darksend. Not trying to be critical... but you trust windows :p ... Plus DS will be open source soon.
 

JGCMiner

Moderator
Moderator
Jun 8, 2014
360
211
113
Thanks Evan for closing out Jira-33.

Yeah, but we lost enforcement. That seems like it might be ok for now, but in the future leaving things to the pool's generosity could cause major problems if someone wants to do something malicious. Especially if they attempt such after DRK has gotten greater adoption and marketcap.

As it is many pools only pay 10%. I just have a bad feeling about his strategy...
 

DrkMiner

Member
Jun 7, 2014
204
63
88
We need enforcement!

In the last week (2 MN running) 3 pools didn't pay fee, 2 paid only 10%
Thats 4 DRK lost.

Whats stopping pools from using pre RC3 wallet and pay 0% fee?
 
  • Like
Reactions: mastermined

TaoOfSatoshi

Grizzled Member
Jul 15, 2014
2,796
2,614
1,183
Dash Nation
www.dashnation.com
We need enforcement!

In the last week (2 MN running) 3 pools didn't pay fee, 2 paid only 10%
Thats 4 DRK lost.

Whats stopping pools from using pre RC3 wallet and pay 0% fee?
This. The goal is to have more Masternodes to make things more anonymous with less chance of bad actors disrupting proceedings.

No enforcement = Less rewards = Less incentive to run MNs = Less MNs = Less security using DRK & more coins on exchanges!

Bad situation. I will keep an open mind until I hear what Evan has to say about this issue.

There are a lot of upset people about this.

Tao
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
I think you guys are too worried. It's a good thing that the MN system is over complicated, to discourage any copycats that want to replicate the same system.
 
  • Like
Reactions: stonehedge

DrkMiner

Member
Jun 7, 2014
204
63
88
I think you guys are too worried. It's a good thing that the MN system is over complicated, to discourage any copycats that want to replicate the same system.
Worried? we should... news/rummer like that need to be clarified ASAP. Its already caused some movement in the price.
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Worried? we should... news/rummer like that need to be clarified ASAP. Its already caused some movement in the price.
OKAY.. Let's read what Evan said again from site http://jira.darkcoin.qa/browse/DRK-33:

"It turns out the masternode voting system is over complicated and somewhat risky to the network, so I've removed it (i think he means the bug that was causing "payout code skips blocks and duplicates payments") and am using the RC3 masternode payment system. This means we won't have enforcement (but he doesn't say this is a permanent decision, right?), but it fixes all of these issues and removes the risk to the network."

Please, if you don't understand or don't know for sure, don't spread rumors and fears on BCT and wonder why the price falls. And please tell your friends not to. I am sure Evan will clarify his statement but right now it's night time in America and people do need to rest, you know?
 
Last edited by a moderator:

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Evan's answer posted in BCT a few minutes ago:

https://bitcointalk.org/index.php?topic=421615.msg8563225#msg8563225

"The RC4 system has inherent issues that were documented in Jira, plus it also has a systematic risk to the network (Sporking is less risky than a hard fork, but there's a risk the network forks wouldn't actually go away when the spork was turned off after a failure). These few issues combined with the fact that we've reached 80-90% payment efficiency tells me that it's not worth the risk to the network to move from the RC3 payment system.

Also, I have a separate plan I've been considering as an alternative that carries no risk and can be done at RC5's launch. Basically, I would set a minimum protocol version and boot anyone not running RC4 or later off the network. This should get us to 98%+ payments."
 

stonehedge

Well-known Member
Foundation Member
Jul 31, 2014
696
333
233
I have a question. I ask here because it isn't easy to find the answer elsewhere.

How does the RC3 payment system work? How are masternodes being paid now? Totally randomly?
 

fredairbex

New Member
Aug 28, 2014
2
2
3
Actually, on macosx, the wallet is crashing at startup when it tries to open the log file, which contains a space in it.
Anyone else tried on macosx ?
 

darkwing

Active Member
Apr 8, 2014
149
110
103
Actually, on macosx, the wallet is crashing at startup when it tries to open the log file, which contains a space in it.
Anyone else tried on macosx ?
Working fine for me.

I made a new wallet and let it sync then sent all coins to it.
 

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,287
2,406
1,183
Germany
I have a question. I ask here because it isn't easy to find the answer elsewhere.

How does the RC3 payment system work? How are masternodes being paid now? Totally randomly?
RC3 payment system was live for 1.5 month and was working 95% good all the time - and beside some network propagation problems, where in rare occasions the masternode list was different on certain miner nodes, we saw a good random distribution of payments.

Evan hoped to fix the network propagation issue by switching the payment system to a "Top 20 rank approach", but it seems this introduced more flaws, which led to

http://jira.darkcoin.qa/browse/DRK-33 and
http://jira.darkcoin.qa/browse/DRK-24

So the rollback to RC3 payment system is very logical for me, as it worked most of the time.

As for me, i am still searching for a new approach to make the payments more network intrinsic - MNs should actually mine their coins by proof of service, not rely on good acting miners to share their mined coins.

If we can somehow create a model where miners (PoW) and masternodes (PoSVC) mine independently from eachother, we will even have a solution for further payments for "DarkTor" relays and exit nodes. The current approach (divide PoW reward) seems not flexible enough to achieve this.
 

stonehedge

Well-known Member
Foundation Member
Jul 31, 2014
696
333
233
Seems like sound logic to me. Cheers flare. Masternode owners do need to know precisely how payments are being run currently though. I'm assuming total random selection which is fair enough.
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
I'm guessing the current MN payment is still based on this system that Evan explained here:

https://darkcointalk.org/threads/masternode-payment-variance.1636/

It seems to me the MN system is needed for a very important task but at the same time the plan is not to encourage every darkcoin to be stashed away in a masternode, hence, the random selection for payment is implemented. A very smart financial thinking.
 
Last edited by a moderator:
  • Like
Reactions: fydel

Probe

New Member
May 28, 2014
25
3
3

Nothing is happening.
After 20 hours of waiting NOTHING .
Here is the debuglog
 

Attachments

Last edited by a moderator:

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
RC3 payment system was live for 1.5 month and was working 95% good all the time - and beside some

If we can somehow create a model where miners (PoW) and masternodes (PoSVC) mine independently from eachother, we will even have a solution for further payments for "DarkTor" relays and exit nodes. The current approach (divide PoW reward) seems not flexible enough to achieve this.
I had a similar notion earlier that I posted on BCT:

One possible solution that occurs to me would be a slight change to the X11 algo to go with the update for the rest of us, but that's a big undertaking. Or maybe it isn't, I don't know? If the algo changes then pools/p2pool would have to update for their mined blocks to be considered valid by the network, and the algo itself could include a MN fee check... but at this point I am speculating way above my pay grade...
 

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,287
2,406
1,183
Germany
I had a similar notion earlier that I posted on BCT:

One possible solution that occurs to me would be a slight change to the X11 algo to go with the update for the rest of us, but that's a big undertaking. Or maybe it isn't, I don't know? If the algo changes then pools/p2pool would have to update for their mined blocks to be considered valid by the network, and the algo itself could include a MN fee check... but at this point I am speculating way above my pay grade...
Yep, saw that - same idea: intrinsic masternode payouts.

During one of my long jogs i thought about something like your modified X11 algo, where miners are dependant on a token from the masternodes to finalize their Proof the Work. But i came to the conclusion that it would introduce another attack/spoof vector.

The current solution (miners share their reward) has the benefit to be simple, but is dependant on good actors. And as you wrote: Changing this is a big undertaking, regardess wether you change the algorithm, add another "Proof-of"-Layer or other changes to the Darkcoin blockchain logic.

I read the TorCoin/TorPath paper, and really like the approach for a Proof-of-Bandwidth algorithm for paying incentives to the exit nodes. The difference between TorCoin and Darkcoin is that Darkcoin is already live, and the coins are not mined by the masternodes, but the miners.

Nevertheless we will need to think about a model which enables us for more complex payout model when we turn to "DarkTor".

Lots of things to consider to find the right trade off between technically possible and economically necessary :)
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
Yep, saw that - same idea: intrinsic masternode payouts.

During one of my long jogs i thought about something like your modified X11 algo, where miners are dependant on a token from the masternodes to finalize their Proof the Work. But i came to the conclusion that it would introduce another attack/spoof vector.

The current solution (miners share their reward) has the benefit to be simple, but is dependant on good actors. And as you wrote: Changing this is a big undertaking, regardess wether you change the algorithm, add another "Proof-of"-Layer or other changes to the Darkcoin blockchain logic.

I read the TorCoin/TorPath paper, and really like the approach for a Proof-of-Bandwidth algorithm for paying incentives to the exit nodes. The difference between TorCoin and Darkcoin is that Darkcoin is already live, and the coins are not mined by the masternodes, but the miners.

Nevertheless we will need to think about a model which enables us for more complex payout model when we turn to "DarkTor".

Lots of things to consider to find the right trade off between technically possible and economically necessary :)
What about having some form of PoService p2pool running on the Masternodes, with each MN 'mining' on it?

edit: I have absolutely no idea how this might be integrated with regular mining. :eek:
 

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,287
2,406
1,183
Germany
What about having some form of PoService p2pool running on the Masternodes, with each MN 'mining' on it?

edit: I have absolutely no idea how this might be integrated with regular mining. :eek:
Yep, my first thought as well - will not satisfy our requirements:

a) ~ 20% of PoW coin supply distributed to active masternodes
b) independent of no. of masternodes
c) minor effect on maximum total coin supply
d) fork proof
 

crowning

Well-known Member
May 29, 2014
1,415
1,997
183
Alpha Centauri Bc
Yep, saw that - same idea: intrinsic masternode payouts.

During one of my long jogs i thought about something like your modified X11 algo, where miners are dependant on a token from the masternodes to finalize their Proof the Work. But i came to the conclusion that it would introduce another attack/spoof vector.
Proof of Stake for Masternodes.

POS is an existing and well tested technology used by dozens of cryptocurrencies.

Only Masternodes are allowed to do it with a fixed stake of 1000 DRK.

Define the interest percentage in such a way that each masternode gets 1 DRK (or whatever else seems reasonable) per day.
 
  • Like
Reactions: flare

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
Proof of Stake for Masternodes.

POS is an existing and well tested technology used by dozens of cryptocurrencies.

Only Masternodes are allowed to do it with a fixed stake of 1000 DRK.

Define the interest percentage in such a way that each masternode gets 1 DRK (or whatever else seems reasonable) per day.
I think the headache lies in the integration with the existing PoW scheme.

If the mining software (pools and p2pool) could be modified to require some MN stamp of approval before being committed to the blockchain that would do it, but I don't know enough to venture how that might be accomplished.

One (truly terrible) thought I had was that MNs could mine/stake/PoS a different coin altogether, perhaps MNDRK, which would be required to purchase services from the MN network. Set a 1:1 exchange rate somehow between MNDRK and DRK and require clients to pay in MNDRK for anonymisation of coins, messages, bandwidth, hosting etc.
 

innergy

Member
Jun 27, 2014
46
13
48
What if we split the MN voting system from mining. I mean, couldn't we use only one and the same address to collect every 20% block reward and then (and later) to send the funds from this address to selected MN on a regular time basis, randomly or by some algorithm? For example - every time when funds exceed 1DRK, we'll send exactly 1DRK to a MN. I don't know if there is a way to measure the masternode's provided proof-of service, but if there is, we can make a MN reward "waiting list" based on that.
 
Last edited by a moderator:

David

Well-known Member
Dash Support Group
Jun 21, 2014
618
628
163
What if we split the MN voting system from mining. I mean, couldn't we use only one and the same address to collect every 20% block reward and then (and later) to send the funds from this address to selected MN on a regular time basis, randomly or by some algorithm? For example - every time when funds exceed 1DRK, we'll send exactly 1DRK to a MN. I don't know if there is a way to measure the masternode's provided proof-of service, but if there is, we can make a MN reward "waiting list" based on that.
That would require centralization--one single point of failure.
 
Status
Not open for further replies.