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.
- Hobson's choice - Wikipedia just with zebras rather than horses.
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
Thank you for the feedback. I made a few improvements and edits to address each of the suggestions you made
2 Likes
Made my PR Create miner-directed-devfund.rst by amiller ¡ Pull Request #273 ¡ zcash/zips ¡ GitHub
1 Like
This proposal has been published as ZIP 1004.
2 Likes