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

[joshs]

@Autotunafish

While this is a fixed portion, the individual miner has the option to participate in the dev fee round or not at their own discretion

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

[boxalex]

@joshs

@Autotunafish

While this is a fixed portion, the individual miner has the option to participate in the dev fee round or not at their own discretion

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

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?

[Autotunafish]

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

[joshs]

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.

[Autotunafish]

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

[str4d]

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

@Autotunafish

While this is a fixed portion, the individual miner has the option to participate in the dev fee round or not at their own discretion

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

@Autotunafish

The motivation for this proposal

This would be the Motivation section.

@Autotunafish

Argument:

This would be the Rationale section.

[Autotunafish]

@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

[Autotunafish]

I assume it would be much easier to handle it at the mining software level, the code already exists to do it, it would just have to become the standard with ample time for providers to prepare for it, fewer changes means fewer things that can go wrong
The even odd blocks thing certainly isn’t a bad idea but that is a lot more work, what do you think @ChileBob?

[ChileBob]

The odd/even was an experiment to explore how things could work poolside so miners could use existing gear.

It sort of worked, the pool would kick the miners when it started an even block so they could work on a failover pool instead.

The problem is the failover pool may not kick the miners off - mainly as they’d want them to stay on the other coin, but also as the other coin would not get mined in sync with zcash blocks. Faster blocktimes with Blossom would make that worse.

We’d need a better idea, changing code on all miners would be disruptive so a risky option. It would need changes poolside so the pool can tell the miner which block its working on (right now they dont), plus changes to the miners so they can react to that.

There would have to be a very compelling reason (ie: profitable) for them to set up ‘block hopping’.

Its an interesting idea, but really hard to do & riskier than I thought.

[Autotunafish]

Its the responsibility of the manufacturer to provide firmware and it would be probably in their interest to stay up-to-date, GPU software is a little bit deprecated but would probably be even easier (a --devfee = 0 pre configuration)

The riskiness of firmware upgrades is a benefit here because some people may not find it more beneficial to escape a development fee vs risking the rig
(my little z9 has been running it’s best overclock for almost 2 years straight and I’m not going to upgrade anything!)
The runway for upgrades like that around here are usually along the lines of a year to six months which I think is more than ample time to allow providers to create an upgrade and for miners to choose to upgrade if they would do so, those who don’t would carry on as usual like they do now

[str4d]

@Autotunafish

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

How this gets implemented at a miner level is irrelevant (though it should be part of the final ZIP). What matters is the functionality of the proposal, which currently is only mentioned obliquely:

@Autotunafish

While this is a fixed portion, the individual miner has the option to participate in the dev fee round or not at their own discretion

Reading the thread for context, it seems that the core idea is that miners who don’t want to contribute to the dev fund don’t mine blocks containing it. This implies two points:

• The consensus protocol must be aware that there are two kinds of blocks, in order to correctly enforce the presence or non-presence of the dev fund outputs.
• It is possible for there to be vastly-different mining power applied to one kind of block compared to the other.

The second point is our main concern. In order to understand the effect of this proposal on the network’s behaviour and security (and the kind of analysis necessary), the specification needs to include enough details of how the potential imbalance is addressed. The proposal as-is doesn’t mention either of these points, or that e.g. the difficulty adjustment algorithm may need altering.

The key takeaway is that while an initial ZIP draft doesn’t need to have a full specification and security analysis, it does need to contain sufficient detail that a reader understands what effect the ZIP would have on the network, and the remaining work that would be necessary to finish the ZIP draft.

[Autotunafish]

I would assume they would do it the way they do it now, by using software that allows them to escape the founders reward round which already exists and implies the software already knows how to differentiate
(and I apologize for the difficulty in understanding it, you’re not alone!)

[str4d]

Could you clarify what you are referring to? There should be no way to avoid mining a Zcash block with an FR output except for not mining Zcash at all, as the consensus rules require every block prior to the first halving to contain one (this also means that “FR round” doesn’t make sense, at least the way I’m reading it).

[Autotunafish]

Hmm, perhaps there is something Im misinterpreting (likely), Ill try to reconcile and get back to you, thx
( however, presumably that probably isn’t going to happen before Sat, thank you for your follow up assessment : )
I was under a mistaken presumption that I had postulated up above, sry

[Mimblewimble4]

You guys are hilarious! These are entirely theoretical issues though, I’m sure this would never happen