The dollar result was correct, but the satoshi number was not (lost my “m”!).
I’ve edited the referenced line to now read:
30,000,000 BTCZ per month, or 300m satoshis of BTC per month, or $19200 per month.
Thank you for pointing this out.
1 Like
My friend , in this proposal you cannot consider as anchorer solution the 5% percentage .
The 4 could be considerer so , because it is exactly in the middle as we have the choices : 3,4,5 , even lower than 3 and even higher than 5.
We must always have in mind that the chosen percentage should be balanced in order to keep everyone happy and not lose much hash power in the network.
Let’s see what the Community will decide.
Anyway , the most important thing is the fact that we agreed for the need of a new fair and equal for all funding mechanism.
5 Likes
Ah, but how many people have stated here that a Community Fund rate higher than 5% will cause them to stop mining the coin?
So far, no one!
I’m a miner, and I don’t intend to leave.
So how about it miners? What rate would make you leave? ( be honest! )
1 Like
Nor has anyone argued that 5% or less would
a) lower daily supply-to-market (lowering total so-called “dumping”) enough to at least assist a rise in price from the supply/demand POV
b) provide a Community Fund of substantial enough size to get the following done:
Design
Marketing
Advertising
Development
Infrastructure
Things not even yet forseen
Who wants to make that argument? Anyone?
1 Like
This is not just about you sj1. And it is wrong to associate the now (at which this change has not yet implemented) with the future. The assumption that no miner has left the network yet does not mean that this will continue to be the case in the future.
Also, if this vote is biased over something, this is over the “even higher than 5%” choice, because the under 5% outcome is split into 4 other choices decreasing the strength of the voters that picked something under 5%.
In order for this to be totally unbiased there should be a vote of different percentiles at start and then another one with the exact percentages of the firstly chosen percentile.
For example the 1st voting could have as choices different percentiles as these: 0-5%, >5-10%, >10-15% till lets say 50%. And then there should be another vote with the exact percentages of the previously chosen percentile.
By following this, the procedure would have been totally unbiashed. But we are good as it is today also.
1 Like
Also sj1 and as referring to a:
this proposal is not about lowering the supply. We have come out of this at previous proposal.
As referring to b:
It is not an argument that 5% will not be enough. Our community already does all these with zero community fee.
1 Like
I would also set a hard stop to the fee at some point in the distant future - perhaps within 5 years at block height XXXXX, the community fund fee disables, and is no longer - This may make it more palatable to the naysayers who are against a fee
4 Likes
I like the idea of some sort of horizon being established from the beginning, and I think the horizon could be related to any of: time passed, block height, market price.
Offhand I wouldn’t think the horizon would be an automatic trigger for the fee to disappear (i.e. a pre-programmed sunset), but rather a trigger for the fee to be revisited by the community. Revisitation might mean elimination, but could also mean adjustment up or down.
The idea here is to go from stability to stability in an orderly fashion, while allowing for changed circumstances to be addressed by a changed set of participants.
Between the beginning and the first revisitation, the issue would be considered as temporarily settled and allowed to work out it’s results as it will.
1 Like
To assume the price will stay static after making this change is to assume that this change would do no good. A small fee will make a difference and if it doesn’t then it can be adjusted upward as necessary. When a small fee does make a difference it will turn into a lot of money. A lot of money makes people do really strange things that they would have never considered doing before and may even create a hacking target that heretofore hasn’t existed. I am made uneasy by anyone who would claim this not to be so. A small fee. A diminishing fee as value goes up or a sunset of any fee to adjust at regular intervals so as to preclude someone’s greed. Not a too distant future, sunset. And, at this point I don’t see any real negative in losing a few miners who might just be mining and dumping each day. When the fee begins to pay off and price rises as a result there will be plenty of miners hanging around. Thanks for reading.
5 Likes
All Equihash coins(Zec,zcl,zen etc) currently being mined at a loss even at 0.06$ kWh. BTCZ is in the green at the same cost 
1 Like
Why this Community Fee is so important when the source code of the project has not been modified in more than three months?
By the way, can somebody please help me to find in the source code of the project the unique algorithm for BitcoinZ (the one making it different from ZCash) and the ZHash ASIC Resistant algorithm? I just need to know the name of the file/files holding them.
The Zhash is an equihash variant like many other ASIC resistant versions as those used in BTG , Zel , SAFE etc
The vaultZ is covering other need than this of a general code update btw.
Thanks for your answer! Let me know if I’m wrong. If it is an equihash variant, then I guess the innovation for the ZHash algorithm regarding to ZCash was to set a new entry for the template Equihash<N,K> (lines 786 to 795 in the equihash.cpp file), with N=144 and K=5, but besides that, is there something else really relevant to this algorithm I’m not paying attention to?
Welcome! Your post is not relevant to this topic, but let me answer.
@renuzit and other awesome coders worked for more then a month to rewrite the whole Equihash 144,5 variant to make it Asic resistant, from the base. So Zhash isnt really 144,5 or just barealy. We had previously the Zcash core base of Equihash 209 variant, but it wasnt a fork.
Edit: thats why we had to make the first miner for the first unique asic resistant algo (Zhasher) and the other new EFWB and lolminer is just based up on that.
1 Like
Let me disagree, but it is relevant to this topic. Your are asking for funds to pay to the programmers and If the coin is driven by an open community, I think we should know what this funds are used for. By the time being, the project is stucked for more than 3 months, so there’s no one programmer working on it.
Please, don’t get me wrong. I’m very interested in the proposal of this project too, but today I can’t see any relevant progress respect to the ZCash project (I would like someone telling me, for example, look at the files <some_file1>.cpp, <some_file2>.cpp, etc. and you will find the unique and distinctive source code from BitcoinZ) and I don’t get what this funds will be used for.
ZHasher seems to be a BitcoinZ project but it’s obsolete. I can’t say anything about EWBF and lolMiner because they don’t seem to be open source and I don’t know whether or not they are related to the BitcoinZ project.
1 Like
The VaultZ proposal is describing many examples/cases for those funds’ spending and the most of them were not related with code development, so I cannot find any relation between the question of your post and the VaultZ proposal.
Please read the first part which has been already approved by the 94% of the Community.
Maybe never again we had so many voters and so big win for one side.
1 Like
My vote of the first part was positive too, it’s necesary to have liquidity to do some improvements, but it doesn’t mean I can’t disagree with some things.
Cases for which a strong Community Fund is needed :
“External cooperations with certain freelancers / developers” and “Partnership or funding the development or redesign of a specific app” involve code development.
“Marketing / Promoting BTCZ” and “Entering new exchanges” is necesary, of course, but if you don’t have an unique base code nobody will take it seriously. All the days I’m seeing new messages in my Twitter account describing how wonderful BitcoinZ is, but I can’t see the same resolution to improve the base code, and I think that my claim has a lot to do with the VaultZ proposal.
A major core code update would require a new hard fork, something that in this phase would not help us for a certain direction.
We run the safest/bug free version of Zec , with the right equihash alternative choice in order to stay ASIC resistant.
If we see that a newer zec core is bug-free , or if we need a new asic shielding alternative or if we take a decision for reducing the block time for a speed upgrade , we could discuss a major upgrade for those cases.
However in this phase is not a must-have. Maybe in a couple of months / btw the VaultZ could contribute in keeping a better pace in such major upgrades.
PS : we should not underestimate the power of the social media.
The most coins out there are open source copies of each other. Their differences are 1)the extra features built around them by their members (variety of wallets , extra apps etc) , 2)their extra deals with exchanges /sellers accepting them and of course their 3)fundamental rules and philosophy (rewarding structure PoW or PoS , premine or not etc).
BtcZ has a very special character and has made an excellent job in (1) and (3) but it needs more push in the (2) imho.
And this can be achieved only by making known the (1)&(3) to the people in order to make the coin recognizable and well adopted.
So yes , twitter/fb/reddit etc can make the difference and every other promo action as well.
2 Likes
I hope I am wrong, but unfortunately I can’t say so today.
