[ZIP 1001] Final: ZIP proposal Keep the block distribution as initally defined. 90% to miners

Thank you for you comment,

You made me realise something important.

I am representing not just my voice with this zip, but others too.

I will continue to champion it. So even if I am wasting my time I am still doing the right thing for other people.

Thank you again.

3 Likes

I wouldn’t abandon the default setting.

Its what will happen if things remain as they are, that makes it an important baseline which should be explored and considered.

3 Likes

Keep the block distribution as inital defined, that is 90% to minner is not bad. I maybe vote for it.

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.


There is no contract. It would be reasonable to say “implied social contract”, as this is then a matter of opinion.

It’s not a neutral point of view to imply that the rules in place at launch were immutable. From this blog post before Zcash launched:

Upgrade Strategy

[…]

At some point, a proposed upgrade may not be so clearly desired by all participants. Even in this scenario, a proposed upgrade may still provide benefits that outweight the drawbacks (e.g. confusion caused by diverging blockchains). If that’s the case, we may still advocate for the upgrade and release software for it. Or, we may decide the risk of a blockchain divergence outweighs the benefit.

[…]

Potentially Surprising Upgrades

[…] The following examples are not comprehensive, nor are they the coolest or most exciting upgrades on our radar. Rather they are a selection of upgrades we expect will surprise some fraction of potential users, and are thus the most important to communicate before Zcash launches.

[…]

…and More

As mentioned earlier, this list is not comprehensive. We may advocate for other upgrades which may surprise some users, which aren’t listed here.

ZIPs aren’t required to maintain a neutral point of view. However, they should indicate which things are not neutral facts.

This is misleading, per the first bullet under “Raised objections” and the discussion down-thread. It would need to be expanded, given an appropriate caveat, or removed.

This is unenforceable, and also inaccurate (ECC does not have access to the full FR, only to the portion that the FR recipients allocate to it). Suggested alteration:

The ECC SHOULD use its portion of the FR funding […]

Additional comment from @daira: “It is philosophically objectionable to try to enforce that anyone MUST continue a specific job.”

In order to reflect the intent of the proposal (which appears to be that there should be no issuance-based funding beyond the first halving), the specification should additionally place restrictions on any issuance-based funding for Halving(height) >= 1, possibly only for some limited period. (It’s debatable whether a ZIP should tie the hands of anyone involved in the decisions about protocol design for all time.)

No, because they were part of the consensus rules up to the first halving, and thus need to be present in order to validate previous blocks (until such time as the entire history of the chain up to the first halving can be assumed immutable).

2 Likes

Amazing.

Thank you so much. @str4d and @daira.

I will adjust this. I agree on quite a few of the points. I probably remove the NU5 funding rather than heavily caveat it.

I can see where my wording is causing problems now, and whilst I don’t expect much movement on this zip I will bring it inline with the current suggestions.

For clarification I was not trying to force people to do things, I was trying to force a company to make a commitment to spending already raised funds, on what I considered to be a contract - so in a contractually obliged way. If this aspect isn’t actually a contract then yes, this needs a lot of rewording.

Thanks again!

2 Likes

Just re going through this, and I was wondering about this

@daira

tl:dr - I will adjust it to be a no work no money rather than we have paid you must work.

it was just the philosophical aspect I was interested in. I know you are busy so as and when you get time, if you get time.

That was not the intent. the intent is that if I pay someone to build me a house, they build me a house, get someone else to build me a house or give me my money back. - or was I never promised a house, I was promised I would pay to for someone to build me a house, they may or may not do that. after all, its opt-in, eh! :wink:

This is what the FR was for. (amongst other things) and has already been paid. That line is to stop the ECC pivoting/winding down before NU4/NU5. So they cannot still receive a portion of the FR and not work on zcash tech.

2 Likes

I know it reads like that, but I really is not the intent, hence the spirit section (which isn’t really part of a zip I know, but it helps me) This zip may seem a bit superfluous but for the very reasons you mention it should not prevent funding. if people really think block distribution is the way forward. this zip should not stop them. Like you say, it is not productive to tie peoples hands.

It is literally, stop the FR. and use funds raised for the FR for zcash technology/adoption/etc - don’t use them to piviot. use them to slow down, sure. that can be seen to be continued development or at least enabling continued development. - this zip for example wouldn’t stop the ECC from dropping half the staff working on zcash technology and using them to pivot, as long as the funds for the pivoting do not come from their share for the FR that should be used to extend the slowdown period.

I am actually trying to simplify a lot of my proposals so they can be tacked on or adapted to other proposals and at the same time not stopped by something not too relevant to the proposal. yeah, I know this is a bit late in the day.

1 Like

@sonya

Seeing as you are about at the mo, can you please give the new proposal a sanity check to make sure I have got things in the right places (i.e. requirements and spec, etc) I would really appreciate it.

Thought I would ask on the simplest one before I post others. please and thank you

If you are about for a bit, I am about to post a whole lot more of them. :smiley:

1 Like

I think it looks fine to submit. “Technical implementation” section can just be “No consensus changes needed.”

3 Likes

[In this comment, I am not speaking officially as ZIP Editor, or for ECC, but am speaking as an FR recipient.]

I’m confused by your comment, because the draft makes no such imposition on ECC, and I think a ZIP that purported to do that would be unlikely to be accepted.

The FR funding up to the first halving belongs to the FR recipients. Specifying what they (including me) can do with it is not within the scope of the ZIP process. The ZIP process can set goals that should be met with respect to the Zcash protocol and governance, and it can set constraints on what is done with new money associated with any dev fund if there is one, but it can’t purport to specify what ECC does with its existing money (including its share of the FR).

The FR, with its current distribution, ends at the first halving no matter what, and no-one has proposed otherwise.

1 Like

It has been a while since I saw the initial FR setup. I will need to double check it, but I thought their was effectively (after investors) 3/4 groups who got some of the FR

1 - The ECC as a Company
2 - Individuals named as recipients (such as yourself)
3 - The foundation
4 - Employees receiving funds indirectly through the ECC’s portion.

All this is trying to do is address 1 and indirectly 4. I am now thinking I must be misremembering it, and it is structured differently. I will reread it and remove the additions. as they probably don’t fit and especially they would jeopardise the zip.

I think (i could be wrong of course) the following is more accurate:

Everything goes to the founders.
Than the founders “donate” to the ECC, Foundation, whomever.

@moderators

A little help please. It seems I can no longer edit my initial post to reflect some changes - its is also making it cut n pasting into my md/bbcode to rst convertor a bit tricky.

The GitHub proposal is not going to be the same as this. I have removed quite a bit. can I get the ability to edit my posts back please? just for a day or two, or could I pastebin the contents of the new post and you can change it? idk. that seems a lot more work.

It looks like the post editing is restricted to a 2 month time period. We can bump this to be longer, until then @mistfpga feel free to copy/pasta it anywhere in this thread and I will update the OP for you.

I was able to test edit it, and it now shows orange pencil for me, can you edit now?

1 Like

Thanks for the quick response. :slight_smile:

I can only edit the title.

it does help with my script though because yours is the only difference (however I am noticing lots of typos as I manually convert it, heh.)

I will rewrite them in rst, then make a bbcode convertor so you can just paste over the OP with it. A lot of the fixes are small grammar and spelling errors. Can you comment on my other proposal please. I should be fine for kek’s and lex’s, that cant have been 2 months ago.

From what I have worked out it is more like the ECC is a holding company, with the only obligation to distribute the FR to the recipients.

It is really confusing me the way the company is structured. so I am just following @daira’s advice and cutting all mention of it - takes a bit away from the proposal and “all in zec” but it is not right to say what people can and cant do with their money.

And effectively by saying the ECC must do something with the funds it has raised from the FR that is not directly paying the allotted amounts to the allotted addresses is directly interfering with someones money. I would have structured it how you outlined, and I thought that is what they did with the rebrand. I think I got it wrong tho.

1 Like

It’s actually more than confusing in my opinion as the whole money flow is more than strange if you think more about it:

For both, the Foundation and the ECC i think it’s correct that the following describes it best in short:

=> Founders only distribute some % of the FR to the ECC, Foundation. The rest is for the founders from start.

=> ECC and Foundation than pays the very same founders again some compensation, wage, bonuses or whatever it’s called. I have no idea how much this is as there seems to be no disclose or transparency.

=> Additionally it seems that some (or all?) founders are as well share sholders in the ECC. This might apply as well to some (many/all?) employees. Without disclose it’s again not clear if there are bonuses or interest paid to share holders.

Again, i could be wrong, but that’s what i get out how the founder parts are “implented” in the money/ZEC flow. Without more transparency and clarification it’s hard to say if this is 100% true or if i’am missing something. And don’t expect transparency or answers here, that’s not a point that seems to get included into transparency, but more a hot potatao that is avoided to be touched at all costs for whatever reason.

Pull request done

@daira does this remove the right parts that you thought to be contentious? Thanks.

1 Like

Can someone from the ECC please comment if the second round of reviews were done on the Initial post in this thread or from the GitHub pull requests. They are not the same proposal, I could not update the OP with the GitHub

All this does is stop the FR. which is going to happen. The GitHub version is a lot more trimmed down and has a lot of contentious points removed. However this one still remains and may be seen as part of the problem?

  • Enforcing some kind of mandatory donation via whatever mechanism would be seen as continuation of the FR.

This is badly worded. It does state later that protocol based donations are possible. The spirit also changed.

Thanks.

3 Likes

This proposal has been published as ZIP 1001. To answer @mistfpga’s question, the published ZIP is based on the GitHub PR.

2 Likes