NOTE: I’m sorry to have created a proposal that caused everyone to get so heated up. This was not my intention in any way. This thread is now close and I don’t plan to pursue this idea any further. Thanks to everyone who provided constructive feedback!
Hey! So you may or may not know who I am. I’m a fellow member of the BitcoinZ community who’s been around since the first few days of this project. I’ve seen the community grow from nothing to what it is today. We’ve accomplished so much in this last year… We’ve grown to tens if not hundreds of thousands of people. We’ve built a great infrastructure beyond the blockchain – communication, wallets, sites, plugins and so much more. The best and most important thing about BitcoinZ is its community.
With that being said, there’s something about BitcoinZ that I’ve never really been a fan of – the immutable parameters. If you’re not familiar with them, they are:
- max supply
- inflation
- only POW algo - we may change Equihash algo to other POW algo to prevent ASIC miners
- new features are allowed to improve usage / scalability, but we will never change history (ETH/ETC case)
While I don’t necessarily hate all of them, I don’t like that they are immutable. Them being immutable means they can’t be changed. The primary problem with this for them to never be changed, they have to be perfect. They have to have been written with divine knowledge of the future – and I don’t think that’s the case.
The worst part of the immutable parameters is inflation. Because of how many coins we’re pumping into supply every day, it’s nearly impossible for the coin to gain value. From day one, BTCZ has been pumping out 12,500 coins every 2.5 minutes. That is a lot of coins being flooded into the market when the BitcoinZ community – as well as crypto as a whole still has so much growth to experience.
I’m writing this post to make a proposal. Before I do, please note the following – it’s extremely important.
- I am making this proposal as a fellow community member. This is not a declaration of what is to come, this is a request for voting. This proposal has the same weight as any other proposal. Please don’t think “a dev is making this proposal”, no. I’m just another member. The community will decide what happens.
- Please think about this. Don’t just blindly vote. Please put some thought into the decision and weigh all options. Don’t be afraid to veto this or better yet, voice any reservations you have about it. Maybe we can refine it to become better.
The Proposal
Due to the massive supply that is already out in the wild, I don’t think it’s possible for us to get the coin to where it needs to be in value. We want a cup of coffee to cost somewhere between 1-5 BTCZ and right now, it’s over 1,000 BTCZ. Even if we do a halving right now, we still have a supply of more than 2B coins out here which is a lot. To fix this problem, I’m proposing a few changes:
1. Create a new chain from a direct fork of zcash
The BTCZ chain is a fork of zcash from last year but the way it was forked was done in a way that inhibits the ability to allow github to track the changes between the two chains. For this reason, applying changes from upstream requires a lot of effort (and might introduce instability). I believe making a fresh fork and applying the BTCZ customizations on top of it is the simplest and most direct way of upgrading the chain while at the same time making the ability to stay up-to-date much easier.
2. No more immutable parameters
My policy is “The community decides what’s best”. Whether we do so through the forum or we work on voting through the chain, I think the community needs to have the power to determine what to implement. I believe some safeguards need to be put into place to ensure a small group of people don’t declare they’re the community and start making massive changes. What I mean by this is for example, requiring proposals to sit for 1-3 months on issues that affect supply, inflation, etc. This will allow the opposition to build support if needed.
3. New chain, new block reward, one-minute block time, one-megabyte blocks
I love the massive supply. I have no intention to change it – I wouldn’t even be opposed to increasing it. What I dislike however is the block reward.
With our switch to a new chain, I would like to propose we switch to one-minute block times, one-megabyte block size. Right now, our block time is 2.5 minutes with 2MB max block size. The switch to one-minute block times with one-megabyte blocks would keep things about the same. Please note this is maximum block size. The chain won’t grow by that much right now, but may in the future when the community is much larger.
With the decreased block time, we get faster confirmations. Instead of waiting 6 x 2.5 minutes, you wait 6 x 1 minute.
So what about the block reward?
I’d like to decrease the block reward dramatically to give the community time to grow without massive inflation. I’ve talked to several people smarter than myself and we came up with an idea that I think might work well:
- Anyone who has BTCZ before this fork will be able to swap their BTCZ from the old chain to the new chain with a 100:1 ratio. This means if you have 10,000 BTCZ right now, you’ll have 100 BTCZ on the new chain. If you have 1,000,000 BTCZ right now, you’ll have 10,000, etc. It will take our supply from around 2.4B coins to 24M coins. When you consider the size of the community, 24M coins is plenty for now.
- At launch, the new chain will have a block reward of 40 coins per block (remember: block time is one minute! If it were 2.5 minutes, it would be equal to 100 coins per 2.5 minutes)
- For the first five years, block reward decreases approximately yearly by 10% each year. This gives us five years to grow the community. We can do it!
- After the first five years, the block reward will increase by 16.1% each year until maximum supply is reached.
So what does this look like?
Block Reward | Yearly Supply | YEAR | SUPPLY |
---|---|---|---|
– | 1 | 30,000,000 | |
40 | 21,024,000 | 2 | 51,024,000 |
36 | 18,921,600 | 3 | 69,945,600 |
32 | 17,029,440 | 4 | 86,975,040 |
29 | 15,326,496 | 5 | 102,301,536 |
26 | 13,793,846 | 6 | 116,095,382 |
30 | 16,028,450 | 7 | 132,123,832 |
35 | 18,625,058 | 8 | 150,748,890 |
41 | 21,642,318 | 9 | 172,391,208 |
48 | 25,148,373 | 10 | 197,539,581 |
56 | 29,222,410 | 11 | 226,761,991 |
65 | 33,956,440 | 12 | 260,718,431 |
75 | 39,457,383 | 13 | 300,175,815 |
87 | 45,849,480 | 14 | 346,025,294 |
101 | 53,277,095 | 15 | 399,302,389 |
118 | 61,907,985 | 16 | 461,210,374 |
137 | 71,937,078 | 17 | 533,147,452 |
159 | 83,590,885 | 18 | 616,738,337 |
185 | 97,132,608 | 19 | 713,870,945 |
215 | 112,868,091 | 20 | 826,739,036 |
250 | 131,152,721 | 21 | 957,891,757 |
290 | 152,399,462 | 22 | 1,110,291,219 |
337 | 177,088,175 | 23 | 1,287,379,394 |
392 | 205,776,459 | 24 | 1,493,155,854 |
455 | 239,112,246 | 25 | 1,732,268,100 |
529 | 277,848,430 | 26 | 2,010,116,530 |
614 | 322,859,875 | 27 | 2,332,976,405 |
714 | 375,163,175 | 28 | 2,708,139,580 |
829 | 435,939,610 | 29 | 3,144,079,190 |
964 | 506,561,826 | 30 | 3,650,641,016 |
1,120 | 588,624,842 | 31 | 4,239,265,858 |
1,301 | 683,982,067 | 32 | 4,923,247,925 |
1,512 | 794,787,161 | 33 | 5,718,035,086 |
1,757 | 923,542,682 | 34 | 6,641,577,768 |
2,042 | 1,073,156,596 | 35 | 7,714,734,364 |
2,373 | 1,247,007,964 | 36 | 8,961,742,328 |
2,757 | 1,449,023,255 | 37 | 10,410,765,583 |
3,204 | 1,683,765,022 | 38 | 12,094,530,605 |
3,722 | 1,956,534,956 | 39 | 14,051,065,560 |
4,326 | 2,273,493,618 | 40 | 16,324,559,179 |
5,026 | 2,641,799,585 | 41 | 18,966,358,763 |
5,841 | 3,069,771,117 | 42 | 22,036,129,880 |
As you can see, the maximum supply is slated to be reached in 42 years. This may be a reference to the meaning of life.
If you’re a visual person like me, the following charts might help understand what this change looks like:
One key thing to remember is that there would be no immutable parameters. If inflation needs to be changed because the community has not grown like we anticipate or is growing faster than we anticipate, that is an option on the new chain! The community will be able to do what it needs to do, given enough support is available to pass the decision. The future is ours to decide with what it will be.
The goal isn’t to provide a perfect setup. The goal is to build a good initial outline to follow and leaving it to the future to decide what needs to change, if anything.
4. The coin swap
Anyone who mines before the swap will be able to mine more coins than what will be mined after the swap – for the first five years. With 100:1 swap, we anticipate to swap around 24M coins. We rounded the swap to 30M and plan to keep any unswapped coins in the community fund. This is not a dev fee, this is the community fund you know and have known for a year now. It will be placed in a multi signature wallet with as many signers as we can put into it to ensure maximum visibility and decentralization of the community funds. Anyone who has been with the community for a long time knows how hard it is to get donations. We’re hoping this gives us a boost to accomplish more from the start – pay people for various campaigns, etc. to get the word out and grow the community.
I’d like to make the new chain’s wallets incompatible with all others. By this, I mean instead of using t and z addresses which are compatible with multiple chains, I’d like to change them to boost the security of our chain. Functionally, they’ll be the same – we’ll have public and private addresses but using different prefixes and possibly using a different algorithm to generate the addresses for added security. To do the swap, we’ll build an automated site where you can go and do something along the following process:
- Generate an address on the old chain, to send your coins to.
- Send your coins to the address on the old chain
- The swap system will calculate the 100:1 value, generate a new address on the new chain and send you the coins.
- It will then provide you with the new address and private key. You will be able to import this private key into your wallet on the new chain and move the coins to your final address.
If that sounds complex, fear not! We’ll try to make it as seamless and simple as possible for end-users. We’ll give plenty of time to swap your coins from the old chain – maybe 3-6 months after the new chain goes live.
We’ll create a copy of the explorer at the final fork height and keep it available so people can easily see how many coins they had on the old chain, and how many they received on the new chain for maximum transparency.
5. Timeline
I would like to give a minimum of one month to vote on this, possibly up to three months.
For implementation, there is a lot of work to be done. We have to:
- Create a new fork from zcash
- Generate the genesis block
- Apply all BTCZ customizations to the chain
- Update the native wallets
- Update the mobile wallets
- Update the web wallets
- Update the explorers
- Update the website
- Notify all the exchanges
- Update all the pools
- Build an automated coin swap site
- Test everything 1000x times
- I bet I’m forgetting one or 1000 things.
I think an accurate timeline for implementation is approximately 3-6 months, depending on who steps up to help.
6. Community, community, community, community!
This is my proposal to the community. Please give feedback. Let me know what you think. Please be nice but don’t be afraid to be honest. I don’t want this to start any wars, I just want to propose we take control of everything with our chain, update it, decrease the supply to something that more closely resembles the size of our community and gets us all excited about BTCZ again. I want to keep this proposal up for at least one month, maybe even up to three months to allow as many community members to see and think about it as possible.
I don’t want to create a new coin. That is not what my goal is with this proposal. I want to “move” the BitcoinZ community to a new chain. If a small number of the community don’t want this but the majority do, I think it would be OK to split into two communities. If however this leads to an all-out war between two sides and the community split 50% 50% then I will retract this proposal and we’ll go back to business as usual.
Again: I do not want this to turn into a war. If most people agree with it, great! Let’s get started (after plenty of time to vote). Otherwise, consider this proposal as rantings of a mad man.
- I love the idea and fully support it.
- I like the idea but I don’t agree with some of the details (please leave a comment)
- I hate this idea. I don’t want to change anything.
0 voters
Credits: Thank you to @cryptorex and @rizzman1000 for helping with the math and overall ideas, @Zebra for the graphic, @renuzit, @NinjaPickle and @icsta for peer reviewing for errors.