Dev fund proposal: fixed 20%, opt in/out measure, minimal disrupt

The no fee flag appears to work, the Miner is still running which makes me wonder if it could be just that simple and that all of the coding is already done pretty much (currently the miner incurs a performance penalty for this flag, should the proposal go forward the miner should not be penalized or this)
It’s still times out but there are a lot of posts online about people complaining about Claymore doing this so I don’t know if you can do anything about it particularly, this is an old version 12.6 so ya know!

1 Like

Try it with EWBF (0.3.3b), its not that fast & kinda old but works reliably for me.

Unfortunately it does not work on my machine, if you recall a certain Ycash Windows 10 debacle in which only LOL Miner would work!
I really think it could work in the Linux subsystem but I’m going to have to read more into about properly marrying the hardware

1 Like

The pool survivied the night, not bad for a quick & ugly hack :slight_smile:

I have to point my GPU at a different project today so the testnet hash will have to come from elsewhere - only one spare left now. I’ll leave the pool running so you can experiment.

2 Likes

I disconnected last night before I went to bed, ran smooth
Ill reconnect when I get home later this afternoon

This Thread is obviously still open to any questions comments concerns pertaining to the proposal, don’t mind the mining up there!

Are you guys still using this test pool? I’ll need to turn it off at some point, let me know.

1 Like

No I haven’t connected since the last time, seems like it worked how we would want it with the miner being diverted to an alternate port for that period of time
(Like I mentioned above I think the big change is that the “default” should just be the opposite)

1 Like

OK. I’ll shut it down & keep the code handy in case you want to experiment some more.

4 Likes

2nd edit, apparently system didn’t like me quoting your whole post. kinda needs the end bit or it looks like im thanking you for shutting it down, heh.

Thanks, I haven’t had time to do anything but I would really like to test a couple of things on it, specifically rolling burn. where the burn goes to an address that can be spent.

I don’t have time at the moment. but would really appreciate it if you could help me in a few days. I am in UTC+1 timezone, so I don’t know how that fits with you. Will probably continue this over PM when I get the time, if that is okay.

2 Likes

Sure, just let me know what you need.

Its UTC-4 here, will be mixing concrete next week somewhere with dodgy internet but available in the evenings.

3 Likes

Thank you to the ECC for their assessments but pertaining to this one I do have a question
Since my proposal doesn’t give special interest groups direction over the protocol (I dont it think it does anyways) nor does it mention burning or changing the monetary supply, why is it grouped with the assessment of Professor Miller’s proposal?
(I get the no part, I don’t get the see number 3 for details part because those things don’t apply)

2 Likes

Don’t worry mate, my opt-in proposal got the same answer, see number 3, needless to say that with opt-in their is no burning affilated.

1 Like

In this model, could miners, for example, decide not to fund any further development in order to keep the community from moving to PoS?

1 Like

Uhm, i guess they could not opt-in or opt-out which would be as intended in an opt-in/opt-out feature.
But on the other side they couldn’t prevent the ECC going POS the next day if there is consensus to do so, or change the algo or whatever. What’s the argument? That on opt-in/opt-out someone could choose another option than the funding option?

1 Like

That is interesting I’ll have to think about it more,
Presumably, the idea is the miner could save the resources that would have otherwise been used
I don’t think it’s realistic to assume every miner would opt out (The proposal implies that greater than 50% of the hashing power of the network will basically drop every time the development fee occurs anyways and I believe that there are more miners than just I who would mine it)
And this is an assumption but that would apply to a consensus model shift within the funding time period, I think given a current Runway to that specific venue which is still quite long it would be responsible to coordinate such a shift with the funding timeframes if it were to cause such a problem

2 Likes

Thank you. Let us know if you have any adjustments and/or would like us to look at it again. The core concern is miner capture.

2 Likes

With GPU software for mining like the one up above the use of the no Dev fee flag incurs a loss in performance, described as certain optimizations are not used it appears to be the will of the software provider and not intrinsic to the state of the device or what have you and incentivizes not using it
It’s complicated with Asic manufacturers and Legacy firmware upgrades and whether or not they would play ball (given historical events I do not believe cooperation would be off the table but who knows)
Legacy powered devices that do not have a “no Dev fee option” would be captured, the Miner may like to upgrade if it’s available but then again he may not

The second idea I have is recognition, it’s a very simple thing and it means a lot to people, perhaps recognizing these miners in some simple fashion, if they choose to be, could suffice
The adjustment in difficulty is designed to compensate for a gain or reduction in mining power, a preemptive difficulty adjustment based on x previous rounds could help smooth things out

1 Like

@daira and I made an initial review pass over this PreZIP. This is not a formal part of the proposal process (in particular, @daira is not acting in hir role as ZIP editor); this is just a joint comment between @daira and myself on the current state of the PreZIP.


This needs to be formatted as a ZIP. See the ZIP Guide for details.

The actual proposed way to achieve this (the even/odd blocks discussed down-thread) needs to be specified as part of the ZIP, along with a rationale for why it is proposed this way.

Additionally, there needs to be a Security Considerations section that would contain an analysis of the effect of this on the difficulty adjustment algorithm. There might be significantly different solution rates for even and odd blocks. The proposed method is effectively a dual-PoW system, and those are hard :slight_smile: The analysis itself doesn’t need to be completed by the draft due date, but it needs to be clear that this analysis would have to happen before the proposal could be accepted.

This would be the Motivation section.

This would be the Rationale section.

3 Likes

@str4d The reason we didn’t come to a conclusion about the even and odd blocks is that we didn’t know if it would be better to handle it like that or at the mining software level which we established is feasible as well
I suppose that may be considered optimization but they are two completely different scenarios
The latter scenario would require very little change to the existing protocol and given that third-party firmware that allows miners to escape current Founders reward exists, I wonder how many of them already do it and how closely the current situation resembles the one modeled
Whereas the “even and odd blocks” is totally different

1 Like