stacksgov / sips

Community-submitted Stacks Improvement Proposals (SIPs)
133 stars 80 forks source link

SIP: Modify Coinbase Reward per Block & Halving Schedule #68

Closed xanbots closed 2 years ago

xanbots commented 2 years ago

Proposing a new SIP: SIP-019, which would increase the coinbase reward and as a result modify the future halving schedule of the Stacks token.

jcnelson commented 2 years ago

Edited the title since this SIP does not yet have an assigned number.

philiphacks commented 2 years ago

My thoughts below... but please correct me if I'm wrong. I'm not experienced enough with mining.

Most miners will turn their STX into BTC again at some point to keep their bids going, so the STX/BTC ratio matters. If you raise the STX subsidy per block (+60%), miners become more profitable in the short term. In theory, this would mean they can bid more sats per block, and thus stackers get higher PoX yields. Since miner profitability would go up in the short term, more miners could (not a certainty) enter the Stacks mining space. But either way, if miners become more competitive and bid more sats per block, miner profitability would balance again after being up (since your btc costs simply go up). PoX yields would go up though. I don't see how this change would bring more miners to the space or improve miner profitability.

A higher PoX yield would be great, but it comes at the cost of diluting your STX stack. So the question becomes: does a higher PoX yield offset the dilution in your STX stack? For me, a higher PoX yield is a win, since it can attract more people to the space and protocols (e.g. Arkadiko) can offer higher yields.

I think the STX/BTC price is the leading indicator here and perhaps miners aren't profitable currently at a ratio below 2000 sats per STX (since the winning bids are usually over 400K sats and the win ratio is too low to make this sustainable?).

All things considered: I like this change since it can help with higher PoX yields, which is the greatest marketing tool for Stacks currently (perhaps that will change with Bitcoin write ability).

guidoprakoso commented 2 years ago

I'll write this to the point, I'm sorry this might hurt a bit

This will lead us into centralized crypto Whale can accumulate faster with mining, we have little liquidity at the market, which mean only retail buying on exchange and also whale "pumping" to attract ppl If it's accepted, the only risk is on retail investor either short term or long term basis, whale still win

And 2 years from now is the capitulation of crypto, about 2 years from now BTC halving

Pretty clever move, i'll have a lot of gain with this, but no I don't support this

Cmiiw

xanbots commented 2 years ago

Hey everyone, first of all THANK YOU to those who have engaged and offered their thoughts and criticisms, and to those who will in the future. The goal of publishing this SIP was to start a discourse, and I'm glad it's doing that. I'll put my 2 cents below, but the one thing I absolutely agree on is this SIP requires a lot more debate and consideration, and given it's something that would affect all STX holders, we may want to commission an economic study on second and third order of magnitude effects it would have on the STX tokenomics.

First on selling pressure and miners exchanging STX back into BTC. From what Daemon has seen, there is little data to support this. The strategy of exchanging back to BTC to keep refilling the miner doesn't work, as it's inevitably unprofitable, sometimes quickly very unprofitable. This is because mining is already a marginally profitable activity. Then when fees of exchanging are taken into account, it almost cancels this out. In addition, miners take an extreme degree of price risk with this strategy. I say this as experience as Daemon was mining with this strategy for about 6 months and had to stop, as we were loosing too much. In general if you look at the mining market right now, and how miners continue to spend a high amount of BTC, it appears more likely that miners are using the activity as a way to accumulate STX in the long term. Also, when mining rewards were 2000+ STX per block during the first 10K blocks, we saw no evidence of this increased selling pressure. This is something that we can dig into more with data though.

For dilution/inflation, I share these concerns and drafted this SIP with them in mind. Looking at the numbers, we tried to find a middle ground that kept the 2050 supply under 2B circulating STX. At least at this initial phase, we don't consider the inflation here to have a meaningful long term effect on STX holders, but this is probably the place in most need of some sort of economic study by outside experts.

Re: centralization - I don't know if I buy that this increases those chances. If this were to do that, then the current situation would as well. 1000 STX vs. 1600 STX for a whale is marginal, especially given how competitive the mining market currently is and has been. If concerns over centralization are real, then I think that's a conversation to have regardless of whether this SIP is adopted or not, as the present situation isn't much different IMO.

The purpose of this SIP isn't to be clever. To be clear, Daemon has mined consistently over the past year not to profit (although we certainly try to be profitable) but to support the network, which is why we have continued to mine even during prolonged periods where it has been unprofitable. The goal is twofold: (1) increase activity on the Stacks network, and (2) create more room in the mining market for when pools come online later this year (an initiative we are working hard on, and I can share links to the Github conversations and designs we are working on there).

Again, thanks to everyone for engaging, and please keep the criticisms and conversation coming. There is nothing to be "sorry" about when expressing criticism - that is the point of the SIP process.

xanbots commented 2 years ago

Also, thanks Jude for correcting all my formatting/process errors in the SIP, still getting the hang of this.

Hero-Gamer commented 2 years ago

Hi all,

1) Would like to understand if above proposal is currently just a discussion, or is it already a formal proposal?

2) I wonder if this conversation can be at some point be taken out to the wider community outside Github? (If so when might be a good timing?) Such as Discord, Telegram and Twitter etc.? Perhaps a Blog post will help. Twitter Space live Q&A will help.

Thanks all and thanks Xan :)

xanbots commented 2 years ago

I think you bring up an incredible point that applies not just to this SIP, but to the SIP process in general. There needs to be a forum that is easier to make proposals on and for discourse to happen for those that aren't developers. The biggest challenge for creating this proposal for me was actually the Github part.

It would be cool if the SIP process asked for proposals to be made via something like the old forum we used to have, and then when it moved to the ratification stage, someone who is good with Github could deal with the process of including it as a PR. It seems pointlessly complicated to require all SIPs both start AND end on Github. Just my thoughts.

This is a formal proposal, but one where there needs to be a lot of discussion before any sort of vote.

muneeb-ali commented 2 years ago

@xanbots thanks for proposing the SIP!

I think the main motivation for such a SIP would be increased miner incentives in the early days of the ecosystem before gas fees become more significant. Miner incentives = block rewards + gas fees. We know that in early stages of ecosystems (which could be several years) the network activity and the corresponding gas fees are typically not the main driver of mining incentives, the block rewards are typically the primary incentive and the halving events gradually reduce block rewards with the hope that gas fees become more significant as the network grows.

So, for me, the key question here is do we think the Stacks ecosystem can reach escape velocity i.e., enough network traction that gas fees become a significant portion of mining incentives within ~2 years or could it take longer? If we think that it might take longer or we just want to be careful and give the ecosystem more time/runway to mature then the proposed changes would increase mining incentives for the next ~6 years or so. This can give a healthy cushion of additional time for the network to attract users/apps/devs and increase the mining incentives through gas fees over time.

The potential downside is higher inflation which is sort of a double edged sword in my view. On one side yes higher inflation means more dilution for existing holders but it also means higher Bitcoin earnings during those years e.g., the BTC yield can go up by approx 60% with this SIP, which could potentially attract more users and help them learn about the ecosystem and use the various apps etc.

The second point (about higher BTC rewards) is less important to me. For me the primary question to think about is about mining incentives and gas fees. Do we think gas fees can become meaningful within ~2 years or should the community be looking at proposals like this one right now to address the potential issue of miner incentives early on?

It'd be great to see more discussion about this!

blocks8 commented 2 years ago

Given the impact to future Token Economics, I would like to see an economic study on the potential impacts in the short and long term that adding inflation could have. You could apply for a Grant through the Stacks Foundation to support economic research.

It would be useful to see updates to the 2019 Token Economic Paper as part of that: https://uploads-ssl.webflow.com/5e7b1a27d160ce49af1c24e1/5f1596b2f7b9a32ffb25797c_tokenpaper.pdf

jcnelson commented 2 years ago

I was just going to suggest that @blocks8 :)


The central argument for this SIP is that it will increase the number of miners, and by extension, the PoX payouts for the network. I do not believe this by itself is sufficient justification for changing the coinbase, because (a) you can do this by other less-disruptive means and (b) this change is somewhat disruptive for questionable gain. I will present my thoughts below in detail, but the TL;DR is as follows:

Without compelling arguments from the SIP authors and community members that support it, I don't think this SIP will achieve what it sets out to achieve.

On to the meat of the arguments:

The number of miners is a vanity metric

The reason that the number of miners seems important is because it's a proxy measurement of how resilient the network is to malicious actors who would create both liveness and safety failures in the blockchain. A liveness failure is a failure that causes the canonical chain to stop accepting new blocks. A safety failure is a failure that causes a assumed-finalized transaction or block to be reverted. A blockchain is "decentralized" if it can maintain both safety and liveness in the presence of powerful and sophisticated adversaries who want to trigger these failures.

The reason that the number of miners is a vanity metric is because it doesn't tell you anything about how resilient the blockchain actually is. Right now, Stacks has 5 miners according to https://app.onstacks.com/. By comparison, Ethereum has at least 50: https://etherchain.org/miner. However, in both blockchains, the top 3 miners control over 50% of the mining power. Is Ethereum really more resilient, as measured by number of miners? I'd say no -- they're equally resilient, and not very much so at that. In both chains, if the top 3 miners banded together, they could monopolize their respective chains and trigger any liveness or safety failure they wanted.

Just considering the number and power of miners, the metric that actually matters here is the minimum number of miners required to break the chain. We need to make this number bigger in Stacks.

Also, the number of miners isn't the only important metric in quantifying a blockchain's decentralization. Other things like number of full nodes, the diversity of the networks that link the nodes, the diversity of the political jurisdictions in which the nodes run, the number of exchanges that support the token, the distribution of those exchanges across the world's financial rails, and so on have an significant impact on the chain's resiliency. For example, a blockchain with 50,000 nodes that all run in the same datacenter is far less resilient than one with 1,000 nodes running in 1,000 different houses spread across 100 countries. However, this SIP is concerned only with increasing the number of miners, so I won't belabor this further. The point is, the total number of miners doesn't tell you much, and it seems inappropriate to me to execute a breaking change that will be felt by every STX holder that serves only to improve a vanity metric.

PoX mining pools improve the blockchain's resiliency

The last monthly miner conversation @xanbots and I had talked a lot about what it means to be a miner, in the context of mining pools. The whole conversation is here: https://youtu.be/jcwQGQmiHdY. There are a few points there that I think are relevant to this SIP.

In this conversation, I argued that in the context of Stacks mining pools, each pool participant is an independent decision-making entity. This is different from Bitcoin and Ethereum mining pool participants, because unlike PoW mining pools, PoX mining pools (a) do not need a centralized operator and (b) are not constrained by how expensive electricity is in each participant's locale (i.e. the cost of Bitcoin is the same everywhere on Earth). This means that the set of PoX pool participants can run any sort of software-defined fault-tolerant distributed agreement protocol (e.g. BFT Paxos or whatever), weighted by their BTC contributions, to both decide on the set of transactions in the block and decide on the block-commit transaction to spend. PoX miners aren't constrained by the availability of mining hardware and cheap electricity.

What this means is that PoX pool participants have a lot more power over the chain than PoW pool participants. Because anyone can start a pool, and because each participant's role in the pool is software-defined (not hardware-defined), each pool participant is functionally indistinguishable from a solo miner for the purposes of measuring the number of independent points of control over the blockchain.

Consider this example. Suppose there are two mining pools, A and B, and suppose there are no other miners. Suppose that A and B each start out with 50 participants, meaning that the chain has 100 total mining participants. For simplicity, suppose that each participant has an equal vote on the blocks the pool produces (e.g. each participant spends the same amount of BTC), so that A and B both have 50% of the mining power. Now, suppose that just over 1/3 of A's participants -- i.e. 17 participants -- caused A's agreement protocol to stall (N.B. Leslie Lamport showed that no agreement algorithm can maintain liveness if over 1/3 of its processes are corrupt).

Because A and B are pools, the chain does not lose 50% of its mining power. Instead, the remaining 33 participants in A join pool B, so the chain's mining power is only reduced by 17%. This is a far better outcome for the chain than had A and B been solo miners. Lesson: pools reduce the impact of miner failures.

Now suppose that the pool participants in B, having 83% of the original mining power and 100% of the current mining power, fail to come to agreement on what blocks to mine. Does the chain stall? No -- instead, the disagreeing members of B split the pool into B and C (and D, E, F, etc.), and these new pools compete to mine blocks. Lesson: pool participants reorganize themselves into new pools to avert liveness failures.

Now, suppose that C gains 51% of the mining power, and it achieves quorum on a decision to revert transactions. Does C get to execute a 51% attack? Not necessarily. If enough of C's pool members disagree with the attack, they instead join B, and deprive C of its mining power. By voting weight, only 1% of the mining power has to defect from C to B. Lesson: pool participants defect from malicious pools to avert safety failures.

If the goal here is to make it so that the chain is better able to resist malicious mining power, then this end is best served by distributing mining power across as many diverse points of control as possible. This can be achieved without altering the coinbase by instead working on better pool software. We could make it so the Stacks node can pay its block reward to a smart contract, and make it so that a taproot address can be used to mine blocks. The latter is already doable today (but could be improved with a hard fork), and the former is already slated for inclusion in Stacks 2.1.

Increasing the block reward will likely only increase the cost of stacking

Full disclaimer here: I'm not an economist, and do not have an economics background. I'm in full agreement with @blocks8 that we should get SIPs like this audited by professional economists via the economics CAB if this SIP gets to an Accepted state, and if we can agree on activation criteria.

Right now, stacking gets 7-8% APY. If more tokens are introduced into the system, where will they go? What systems or protocols exist (or could exist) that will sustainably offer a better ROI when given the volume of potentially-liquid STX to work with, and why don't they work today with the existing liquidity? If we don't have an answer to this, then I think it's safe to conclude that the additional tokens will just get stacked, thereby driving up the minimum stacking threshold. So while PoX rewards could increase, your STX could also afford you a lesser share of them. This is to say nothing about the potential impact on the STX price with the introduction of more STX. I think this SIP really needs to speak to this more.

Fundamentally, mining is a negative feedback loop with an expected ROI of 0 over time. As a miner, you commit as much resources (BTC) to mining as you can afford, and in the absence of other income, the amount you can afford is dependent on the resale value of your block rewards. Whatever profit you make is profit you (or your competition) could have invested in mining, so in the absence of external revenue, miners that keep more profit will eventually be out-mined by miners that keep less.

If we believe that the PoX yield will increase at all by increasing the coinbase, then we also necessarily believe that the market will continue to value STX as it does today. I don't think this SIP provides a convincing argument for this happening, beyond speculators buying the additional STX in the hopes that a future unspecified application is found that makes it worth more than it is now in some fundamental way. But, we don't know what the speculators' budgets are, so it's hard to know how much additional STX can be injected into the market before the price and PoX rewards are significantly impacted. After all, if the market was perfectly efficient, then STX would lose value due to the increase of supply. If this SIP argues for increasing the coinbase in order to increase PoX, then it needs a compelling argument as to why we should expect this to happen.


As the chair of the SIP steering committee, it is my job to facilitate activating SIPs the community wants, regardless of how I personally feel about them. So please do not take the above argument as a personal stance. My goal for right now is to make sure the SIP is good enough to pass technical, governance, and economic muster so it can be recommended to the various CABs.

velocity303 commented 2 years ago

I'll preface by saying that I'm not an expert but just a community member. With that being said, it doesn't seem clear to me that additional miners will be incentivized to join just because of the increased coinbase. It seems like this is an assumption that additional miners will join while there may be other issues that are preventing more widespread participation in mining (easy tooling for pools, awareness, general network adoption).

Changing the issuance should be a last resort sort of measure that should only be used if we do not see another path to getting more participation by solving other areas of friction that may be causing poor participation. In addition to the economics review by an expert, we need a better way of widely polling the community for their thoughts on the issue. I would assume not many know how to find this GitHub issue and voice their opinions here. There will be a potential loss of trust if a change is made in the background without many realizing they missed their opportunity to voice their concerns.

muneeb-ali commented 2 years ago

@velocity303 this is just an initial discussion and the SIP process is very rigorous that gives ample time for everyone in the community to chime in, there is also explicit voting and miner adoption etc so there is no no way that any change can be made in the background. Great to have your input! We should open the discussion on a more user-friendly place like reddit (r/stacks) or the forum as well.

@blocks8 do you have any relevant folks in mind that can perform such a study? My previous experience on economic studies has been fairly disappointing. It'd be great to identify folks whose input can be valuable. My personal preference would be to get people who have crypto experience in addition to an economics background. Just theoretical input from someone who doesn't understand crypto networks and their dynamics might not be very useful.

@jcnelson thanks for the input. I'll comment on some aspects below:

1) When I'm bringing up mining incentives I'm mostly concerned with total security budget of the network. Miner decentralization is a secondary concern for me. The total security budget for the network has gone down recently and can go down further if markets continue to drop and/or we don't see significant growth in apps/users in the next 1-2 years. I think we're in an early stage of the ecosystem where gas fees are not significant and the total security budget is mostly derived from block rewards. The SIP, if adopted, clearly increases the total security budget for the coming years by 60%. Further, it incentivizes new users and developers because a higher BTC yield attracts more users and more developers to the ecosystem. We've actually experienced this first-hand in the initial two months after mainnet launch. The higher BTC yield at that time directly resulted in a lot of excitement and enthusiasm from users and developers and there was week-over-week and month-over-month growth. Such periods of growth/excitement are very important in the early days before the ecosystem can mature and gas fees can start playing a significant role both in the total security budget and the BTC yield. On the flip side, you don't want to be in a scenario where the total security budget goes down and then certain parties/actors start exiting the ecosystem because they start perceiving the network as less secure. That can lead to negative spirals (opposite of growth and increase in security budget over time).

2) The PoX mining pool proposal looks interesting and is largely independent of this SIP. We should work towards it regardless of this SIP. With a higher total BTC bidding bandwidth, there will only be more opportunity for independent players to participate in pools (not less opportunity). So this SIP can only help the PoX mining pools work. The number of active miners is not a vanity metric. Ten independent miners on the network are clearly better than 5 independent miners e.g., for liveness if the 5 miners are knocked out (for whatever reason) the other miners can continue to mine blocks. Also, the perception of small number of miners is harmful to the ecosystem. I've had direct conversations with several startups and developers who were interested in building on Stacks but were hesitant that the mining numbers look very low. I see the arguments that you are trying to make RE liveness and safety but the market reality is that no matter how you try to describe the current situation, the current numbers will be perceived as extremely low and a cause for concern by the developers and other market actors. And it's not just about perception, the network is less resilient when the no. of miners is low because it's only a handful of parties that are responsible for liveness. We should be able to tolerate the exit/failure of many independent miners and a higher number of independent miners helps with that.

3) The concern about increased Stacking minimum is largely irrelevant. Let me explain by running through some numbers. The SIP proposal introduces approx 65M additional STX in the approx two years before halving (in reality it's going to be less because it'll take a while for the SIP to be accepted, implemented, adopted by miners etc). Currently, out of the 1.35B STX approx 483M are stacked for this cycle. This gives us a rate of 35% STX locked. Let's say following the same 35% number, an additional 35% of 65M = 22M additional STX that can get locked up. This 22M STX is within the normal fluctuation that we've seen in STX locked e.g., STX locked dropped more than 30M STX just last cycle. So the additional 22M may or may not change the stacking minimum at all for the next two years: it's within the cycle to cycle variance that we're seeing already. Also, a broader point here is that more STX locked is generally a healthy thing for the network. There are other networks with up to 70% of the supply is locked and that is typically a healthy sign: more tokens locked means there are more long-term believers and supporters who want to contribute to the security of the network--a healthy sign for the ecosystem and its future growth. Users also don't care as much about stacking minimum (they can use pools) but they care about the BTC yield rate. The SIP increases the yield rate and may or may not change the stacking minimum. A Stacking minimum discussion is sort of irrelevant for this SIP because the Stacking minimum will likely be controlled by factors outside of this SIP. The stacking minimum can go up a lot more outside of this SIP (we can expect 50-70% of supply locked down the road, especially if Stacks is very successful and there is a lot of interest), and I'd argue that more STX locked is a healthy thing and not something we need to worry about; we also can't stop it from happening. It is one of those things that will play out in the market based on how interested people are in Stacks. More interest is good, not bad 😄

In summary, I agree that the SIP needs better motivation e.g., the arguments around increasing total security budget of the network need to be spelled out in the SIP. We also need to articulate how the coming years (with relatively less gas fees) have different dynamics from a time when the network has reached escape velocity and significant gas fees can contribute to the total security budget. I'd also argue that more weight should be given to the economic dynamics for the coming 2-3 years as these years are more critical for the success of the ecosystem.

jcnelson commented 2 years ago
  1. When I'm bringing up mining incentives I'm mostly concerned with total security budget of the network

This entire argument assumes that if you mint more STX per block, the STX will have the same valuation as if you had not done so.

The security budget of the Stacks blockchain depends on both the amount of BTC spent per block, and the number of block races an attacker must win to reorg the chain. The number of tokens emitted per Stacks block is orthogonal to this. If you want the amount of BTC spent per block to increase, then the aggregate value of the Stacks block rewards must increase first. Simply sub-dividing the aggregate worth of the block into more units would not achieve this by itself.

Put another way, why should I believe that e.g. 2x-ing the coinbase will 2x the amount of BTC spent on it, when basic economics would suggest otherwise? If you believe that there is a linear relationship here, then why not increase it a billion-fold? ;)

  1. The number of active miners is not a vanity metric.

Sure it is. If there are 10 independent miners, and one of them has 51% of the mining power, then there might as well only be one miner insofar as determining how many entities must agree on which blocks get produced. You might remember that Namecoin supposedly had lots of miners too, but one Bitcoin miner had de-facto control of the chain through merged-mining.

  1. perception of small number of miners is harmful to the ecosystem. I've had direct conversations with several startups and developers who were interested in building on Stacks but were hesitant that the mining numbers look very low.

Suppose that pools existed, and chain explorers correctly counted individual pool participants as independent entities contributing their decision-making power to block creation. Suppose there were 100 such entities (this is achievable). Suppose there were 1,000 (also achievable). Would that assuage their concerns?

Also, I can't help but shake the feeling that this argument boils down to "I can't convince people of something that is true, therefore we should hard-fork the chain to convince them." That would not be a compelling argument for advancing this SIP.

  1. And it's not just about perception, the network is less resilient when the no. of miners is low because it's only a handful of parties that are responsible for liveness. We should be able to tolerate the exit/failure of many independent miners and a higher number of independent miners helps with that.

While I agree that keeping the chain alive in the presence of node churn is a worthy goal, doing so does not require increasing the coinbase. As argued earlier, pools achieve this on their own.

  1. The concern about increased Stacking minimum is largely irrelevant.

I think this is something you want an economist to look at, as well as a UX researcher. Your argument boils down to "if we increase inflation, nothing else will happen as a consequence besides the BTC yield going up." I think this is very optimistic. First, we don't know that the new STX will be stacked at same rate as the existing STX. Second, we don't know that the price of STX won't decrease accordingly (which is what a rational market would do). Third, we don't know the UX fall-out of trying to deliberately increase inflation -- something the crypto community generally frowns upon.

Also, neither the SIP nor you in this thread have presented any alternative approaches to your goals (i.e. increasing the total security budget of the network, increasing the number of miners) besides this change. Why is this the right and best thing to do, despite the downsides?

jcnelson commented 2 years ago

@velocity303 In addition to the economics review by an expert, we need a better way of widely polling the community for their thoughts on the issue. I would assume not many know how to find this GitHub issue and voice their opinions here. There will be a potential loss of trust if a change is made in the background without many realizing they missed their opportunity to voice their concerns.

Your point is well-taken. In a general sense, one thing the governance process needs to become better at is broadcasting any new SIPs and any governance decisions taken on them. If this SIP in particular gets reviewed and is up for activation, the Activation section will require a very large degree of measurable (falsifiable) community buy-in. There is no way the steering committee would permit something as wide-reaching as this to get activated under the radar.

314159265359879 commented 2 years ago
  1. I am not convinced we need this or the goal will be achieved because of the basic economics argument given by others: increased inflation is likely to result in decreased value of the coinbase. The so called UX "fall-out" is what I am more worried about though. There are users invested in the project but definitely not as aware of all the current events/talks etc. Even if this takes half a year to discuss and implement you'll still surprise users who simply missed the whole dialogue in the first place. And how deliberately increasing inflation could be bad for Stacks' is image.

  2. If the high rewards in the first 10k blocks was the reason for the high yield, attention and growth at that time it is still no argument to expect the same when you increase the yield for the next 14 years. Because for those first 10k blocks everyone knew they were extra valuable compared to the rest. If you want to mimic those first 10k blocks it should have a short burst of additional issuance's and not increase all block rewards for the next 14 years. image

What about only increasing the block rewards for just 2 years? Additionally what about shifting block rewards to the first 2-6 years, at the cost of lowering following years, leaving the Marketcap by 2050 untouched/the same? That is more in line with the idea of helping the network in the early days?

An economic modeller could consider those options as well as the one proposed by Xan (and shown in the screenshot above)?

  1. As for involving a broader audience, a link to this discussion was posted/pinned shortly after it was started in the StacksTrade channel on Telegram with an explicit request to users to involve themselves in the conversation. Here directly or on Telegram.
larrysalibra commented 2 years ago

My thoughts are here: https://forum.stacks.org/t/proposed-sip-modify-coinbase-reward-per-block-and-halving-schedule/13182/6?u=larry

xanbots commented 2 years ago

Thanks to everyone who commented. I'm going to close this PR, and open another one with a redrafted SIP. The main reasons being I feel this SIP has gotten dragged into the conversation about how to get more miners on the network. That was never the purpose. The purpose was to create a better bootstrapped environment for the Stacks network during the early days, or put another way to raise APY and security budget of the network.

In addition to clarifying what this SIP is meant to accomplish in the redraft, I also want to address some of the great feedback and include a number of the suggestions that have surfaced in this conversation with the community. One big example is I'm going to remodel the SIP to create 0% inflation in the Stacks token supply, and rather it will just accelerate the coinbase reward schedule to be more front loaded.