[ZIP 1004] Dev fund proposal: Miner Directed Dev Fund (was: 20% to any combination of ECC, Zfnd, Parity, or "burn")

Keep in mind any extension would be implemented after the Halving, so the number of ZEC per month would be 50% less.

1 Like

The number of ZEC would indeed be 50% less, but many think the halving will lead to a price increase which could balance the “halving-funding-effect”…

Still doesn’t answer my question even if we count in the halving and take $2.5M at current exchange rate why someone would make a proposal after $1M are actually needed.

Just looking/asking for a rational explaination for this, nothing more, nothing less…

1 Like

No. The purpose of mining is to get transactions into blocks. Any political power that miners have is a side effect of that, and shouldn’t enable any veto over protocol changes (including alternative ways of getting transactions into blocks).

5 Likes

When Dev Funding ends October 2020, the ASIC miners will drive a centralized influence on Zcash. With only ASIC mining and No Dev fund coming off the top, Zcash will experience a more centralized nature than any time before.

Daniel Feher taught us at Zcon1 GPU mining encourages decentralization of wealth. ASIC Mining We learnt will increase resistance against a 51% attack. GPU.

I like the consensus idea for development funding in this proposal, but if I am not able to justify the Low Return of Investment on ASIC miners I will not be able to participate in that consensus for development.

Flaws I see here are the investor not having any say in the development funding first and foremost. 2nd is the current miners turning off their mining rigs if the profitability gets any lower and that will slow down mass adoption.

Thanks for the information

Could you follow my request on Proposal authors, please read: Help making ZIPs ?

That will help me and ZIP editors know which forum proposals we can help turn into ZIPs.

Thanks again for your contribution!

2 Likes

Re-posting this here after chatting with @mistfpga

I like the idea of opt-in & think there are ways that could be implemented to prevent/catch cheating pools - probably better than what I’ve come up with.

A miners default setting is greed. They’re in the business of chasing pennies so any choice they have should be limited to ‘send the funds elsewhere’ or ‘burn’, otherwise all will opt to keep their pennies.

How about a something like :-

  • A minimal amount (ie: keep the lights on) goes to a multisig controlled by ECC/ZFnd from block rewards
  • A different amount goes to ‘miners choice’ or ‘burn’ (ie: the miner can’t have it but can decide who does).
  • Balance goes to the miner

The pool code I’m playing with lets a miner supply data to the pool via their username, this goes into the nonce of any blocks they mine and can be used to generate appropriate outputs from the coinbase txn.

The miner can verify the pool is using their choices by looking at the work the pool sends - its not hard to produce a proxy the miner can use to monitor this.

As the nonce contains the miners preference its easy to confirm that the coinbase txn delivered what was requested and identify pools that cheat. Its after the fact & not enforcable but I doubt the pool would want to be caught doing that - its all recorded forever in the blocks so can be audited by anyone, anytime.

Here’s a link to a javascript widget that encodes the miners choice, with a little luck I’ll have a testnet pool working in the next couple of days.

https://chilebob.duckdns.org/minepoll

Hope that helps.

3 Likes

@amiller here’s an idea, since the choice thing you know I’m not too sure of maybe you give the miners the option to opt out of participating in that fee so basically they don’t hash 20% of the time
So this way you can choose to participate in this tax or not participate, in either case you earn no money for yourself so I think this more closely resembles an actual choice and therefore would actually constitute a charitable donation
Now we know the big miners are profit-driven and given the choice to essentially save that much electricity for that much time they probably would (maybe unless they actually cared about various projects but like Eran Tromer mentioned in the talk there would have to be some kind of a mechanism to determine that in a fair manner which certainly isn’t impossible)
There is a side effect possible benefit of the difficulty during this time decreasing which would allow miners who are participating in the tax to find that much more for whatever project it was that they decided to fund so more development in less time perhaps, idk
Thoughts?..

The more I think about it, the warmer I get on the idea of “fund or burn”.

The social contract of “90% to miners” is mainly important because it implies “the founder and his friends are entitled only to a certain slice of the pie, and no more”. 90% is important because it limits the other part to 10%.

And this mechanism would maintain that invariant without giving mine operators a perverse incentive to always tip zero. Instead, they get to choose between two intangible, difficult-to-measure goods: value appreciation through reduced supply, or value appreciation through better software.

I very much like the idea of a coinvote for deciding where a portion of the funds go, to avoid giving miners weird incentives, like what happened with that SegWit versus ASICBoost nonsense. But because this is zCash, any coinvote proposal would also have to let cloaked coins vote, which seems hard to do, on a basis formalized enough for the chain itself to respect, without leaking information?

Well, there’s four options. Divide them evenly and get $2.5M/4 = $625k, which is well under what is needed. Expecting them to get a 100% vote seems unreasonable; each miner (and possibly coinvoter?) will be making their own decision over whether development or deflation is the better move at any given time, and if development, by whom.

1 Like

How is that different from this proposal?

If you’re suggesting that the miners would opt out by literally not mining for the 20% of the time corresponding to the reward, I think it would only work if they could prove how much they decided not to mine. But isn’t that impossible, given that the way you prove your hashrate is by mining?

1 Like

It’s really not that different at all, that proposal just didn’t come to mind when I had the idea after the live stream
I posted here because my particular proposal was an offshoot of this one
And I’m not really sure yet about it because I haven’t had any response about the technical aspects and whether or not it’s even a good idea

Can you clarify a couple of points for me please.

  • Does burn impact transaction fees at all?
  • Does purposely taking coins out of circulation at the protocol level violate the 21million?
  • Does burn have to take the coins out of circulation?

could it for example be:

  • added to the mining fee,
  • put into the next block reward
  • in some crazy way extend the emission curve,
    • either via delaying the next halving buy however many coins worth of blocks have been burnt that halving cycle
    • or tacking it onto the end, a bit more monero style. so say 5000 zec get burnt, that gives x more blocks at the end, but not of standard sizes. but as long as coins are burnt it will keep giving out distribution ‘rewards’.

Im not sure of the inflation/deflation aspect of it, and it certainly has a lot of nuance when it comes to the details.

I know others don’t see it like this, but the coinbase block allocation (without fees) is meant to get zec into as many hands as possible. I could really get behind a proposal that does not take them out of circulation, and I feel it would fulfil the initial contract of 100% going to miners yet still allow block distribution to fund things, and blocks to be distributed.

It doesn’t break the overall total issuance. Technically (depending on how it is implemented) might not even break the emission curve either.

I think it avoids the double tax problem too because you can just keep burning. Again the devil is in the details. - I am not sure even half or all of my examples are technically feasible. I am just trying to find a way to stop coins from going out of circulation forever.

I know we have spoken via PM and this post doesn’t change anything I have said. if anything this helps me clarify your stance a bit more.

I would be really interested to hear yours, or anyone else’s thoughts on this.

1 Like

The question isn’t toward me, but it’s actually a more than interesting one.

From my knowledge “burning” could mean several things, but in this case i guess it’s refered to sending the coins to an invalid ZEC adress and “destroy” them that way, at least that’s my understanding.

This is a good resource: development - How to generate a valid bitcoin address for destroying bitcoins? - Bitcoin Stack Exchange

That’s an interesting fundamental question in my opinion and i’am pretty sure there is no real consensus if it’s yes or no as it could be seen either.

Actually thinking a bit more about it and going a bit more far having Burn or Donate would be actually no more a pure POW consensus but would be maybe a hybrid btw. POW (Proof of Work) and POB (Proof of Burn). At least i see a lot of similarity with some POB consensus details:

One of the Proof of Burn designs:

Burning Native Coins for Mining Rights: This POB model requires miners to burn a portion of their coins in order to acquire the rights to mine blocks. The ‘cost’ to mine in this case is the destruction of miners’ coins instead of paying for expensive mining equipment or electrical resources which is required in a POW model. Slimcoin implements such a system. Miners who successfully mine a block in this POB model will still get mining rewards for their efforts. This applies to coins that adopt Proof-of-Burn (POB) as their consensus mechanism. POB is a unique way of achieving consensus in a distributed network, requiring participants – miners and users – to burn a portion of coins. There are many variations of POB.

In our case it would be Burn or Donate for Mining rights. Interesting, i wasn’t thinking about that yet.

2 Likes

Shouldn’t, no

I don’t think it does - anyone who owns coins can take them out of circulation if they wish anyway, by sending them to an invalid key. This can happen in practice due to mistakes already.

All of these are good ideas, and definitely possible. And the motivation I find most compelling is that mining should put coins in the hands of as many people as possible. On balance though I’m preferring the simplicity of just burning for now. Maybe it could be revisited in the future even without violating the “no more than 21mm” rule.

This would work too - the simplest is just that the coins never get minted in the first place. To burn 1.25 ZEC (20%), the coinbase transaction would just only have 5 ZEC (80%) worth of outputs in total.

Interesting analogy but I think this is pretty different and it would not count as PoB. Only PoW determines who mines the next block, already owning some ZEC isn’t necessary and doesn’t help to mine.

3 Likes

Am I correct in phrasing it like this

  • Burnt coins MUST ONLY come from block distribution

I think this is what you are getting at. There might be a knock on effect to transaction fees, but that is out of scope.

I see your point and I agree to an extent, however I did emphasise the protocol level, your examples are at the user level.

If I am given 10 dollars an I misplace it, then it is my mistake.
If I get given 10 dollars, then I decide to set fire to them that is my choice.
If someone else says here is 10 dollars, you can look at it, then I can set fire to it or you can let someone else have it. It isn’t really the same choice.

In one situation it feels like I have agency in the other it doesn’t. - this is more commonly known in England as Hobsons choice.

Im raising this because as much as the protocol says it wont give more than 21 million it also says it wont give less than 21 million. So the coins would have to be issued then sent to an address without a privkey (this is what I have always understood burning to mean) - so technically it has issued the 21million but just not all of it is ever going to be spendable.

I, like you, want more zec out in more peoples hands.

I agree with the simplicity im just slightly (and only slightly) concerned about the knock on effect. Particularly about what the burn model does to the financial modelling that @sgp did. This is well outside my area of expertise.

I am particularly interested in at what point does burning become a weapon against the protocol (im guessing there will be various zec/btc/usd/dev fund allocation combinations that could make burning a realistic threat to the viability of development? idk.) - using the ‘reallocation burn’ might negate this? (see how out of my depth I am, heh)

No more and no less, right? sure its ~21million but it isn’t going to be ~18m or ~24m, which would mean the protocol has to at least create them, then send them somewhere they cannot be claimed.

I think it would not add that greater complexity to have that address perform a special function, like my examples. (I am hypothesising at this point.)

@str4d seems to be very knowledgeable in this area and would love to hear any feedback on the general implementation idea. Is this realistically achievable with what is currently out there? (burning to reuse at a later date rather than just destroying/not generating coins)

The first quote is quiet different in my opinion. It means the coins are minted/mined and than get burned The 21M emission would not get violated.

In the 2nd quote it’s quiete different, again in my opinon until i miss something. They do not even get mined/minted, means technically the 21M get violated.

I think this is exactly the reason why many burn design all refer to do something with the coins after they are released, be it buy back, sending to invalid wallet adress and whatever not other designs are there.

Sure only POW mines, correct, but i see the element of “Burning or Donation for Mining Rights”. Without burning or donating you can’t mine. It’s just another variation of the POB element, hence i would call it a hybrid POW/POB somehow. Just a thought of course as i see similarities, even if a bit abstract.

@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 is a reasonably well-defined idea. However, it is not yet a ZIP draft, and would need to be written up as such. In particular, there is content in the thread that needs to be pulled into the draft, and sections like Motivation and Rationale need to be written.

2 Likes

ACK, I’ll aim for a pre zip quality revision tonight

1 Like

Update: The original post is edited above to be more like a ZIP draft. Didn’t get as far along in this edit as I planned to tho, still could use work!

5 Likes

@daira and I made an initial review pass over this now-drafted 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 content should be in the Specification. The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.

Our understanding is that the intended semantics is an on-chain allocation (rather than directing the funds to a central address and then relying on off-chain governance for the split). This should be clarified.

The specification should also state the intended behaviour after the second halving if there is no subsequent relevant ZIP, so that it is clear what should be implemented in the consensus rules.

EDIT: We spotted after posting that this is specified in the “Open Issues / Raised objections” section. It should either be written as an open issue there, or moved here as a specification.

This should be part of the Requirements, not Motivation. The rest of Requirements should also be filled in.

This should say “The upper bound on the rate of newly minted coins […]”.

This is too vague, and the language is inconsistent between the earlier sentence (currently in the abstract) and this one. The design of this proposal does not necessarily require either an opt-in or opt-out - the mining software (or zcashd if this were implemented as part of getblocktemplate) could instead refuse to start until a percentage has been set. In any case, the specification should be clear about what is being configured by the user.

2 Likes