<p>How would you define popularity? Any measure you make must be decentralised, and whatever you decide on can be arbitrarily faked. It's completely impossible in the terms of a trustless currency like Bitcoin. </p>

CC BY-SA 3.0
2013-12-10T12:46:02.830Z
Market price is a measure of popularity. Since there is no monopoly on exchanges anyone can run one. Then you probably want to count a VWAP (Volume-weighted average price) across the whole exchange market and you should be all set.
Kozuch
CC BY-SA 3.0
2013-12-10T16:52:17.160Z
@Kozuch And how would you *reliably* measure that? What about lying exchanges?
CodesInChaos
CC BY-SA 3.0
2013-12-10T22:49:41.170Z
@CodesInChaos: What exactly are you asking about measuring? I just proposed one way above (VWAP). There seem to be a real paranoia within the Bitcoin community in linking some "real world data" to the protocol - developers say it is a "vulnerability" and they will never do it - this is laughable. In the meantime, the only vulnerable thing here is Bitcoin itself... nobody knows whether it will be here tomorrow. Why an exchange doesnt want to lie? Because if people realized the exchanges would go out of business???
Kozuch
CC BY-SA 3.0
2013-12-11T08:26:26.237Z
@Kozuch You did not say how you measure the VWAP and feed it to the protocol in a secure fashion. What if I open "Honest Achmed's Bitcoin exchange" and report that I exchanged a billion bitcoins for a dollar each?
CodesInChaos
CC BY-SA 3.0
2013-12-11T09:54:40.663Z
Ok, I get what you mean now. Well each node would need to filter such exchanges out... If the exchange is new and nodes do not trust it, they simply would not use its prices within VWAP. In the end what we need is block reward height, so nodes have to calculate it somehow... maybe price is only one input for such calculation. Number of transactions (which also gives the economy value) could be another input. Actually the more inputs we have the less risky the final calculation should be...
Kozuch
CC BY-SA 3.0
2013-12-10T09:22:37.083Z
2013-12-10T09:22:37.083Z
Anonymous
<p>I've recently thought of pretty much the same thing.</p>

<p>@Anonymous: Popularity is not difficult to define. Call the new currency bitcoin'. A good measure is the price of a bitcoin' in terms of some broad index of consumer goods (like the CPI basket), commodities, or whatever else you want. Perhaps the best available measure of popularity is MtGox's current price in USD, or EUR, etc.</p>

<p>If the bitcoin' price is high, the mining reward rises, essentially quickly generating new bitcoin', thereby lowering their price. A falling bitcoin' price would trigger higher mining rewards to slow the supply expansion.</p>

<p>Practically, at present, I think the extra stabilization provided by such a system would be minimal. But my opinions on the matter are currently not too strong.</p>

<p>Note that the current mining system already works to stabilize the price of a bitcoin to some extent: as the price of a bitcoin rises, more miners enter, increasing the supply and helping to drive down prices. But how's that system working out? So far, not so great as far as stability goes.
And of course, when the ~21M bitcoin cap is hit, there will no longer be any stabilization mechanism available that links bitcoin supply with bitcoin price.</p>

<p><strong>UPDATE 1</strong> I forgot to mention the important question of how "popularity" is announced/communicated into the bitcoin' system. Very good question.  One could imagine a trusted entity with a well-known public key signing such announcements and system nodes verifying that particular entity's signature. </p>

<p>One nice aspect: the "popularity" measure could be relatively objective, e.g., latest publicly available quoted price from a popular exchange. This would at least allow anyone in the world to determine whether this trusted entity is really trustworthy (are they lying about publicly available quoted prices???). But admittedly, this is a real sticking point in the design, e.g., what if this trusted entity is hacked?</p>

<p><strong>UPDATE 2</strong> Another related idea: if one could reliably enforce bitcoin contracts that involve trades of other real-world commodities/assets, then it'd be easy to construct a decentralized system in which many anonymous entities publicly announce bitcoin's "popularity" (again, use bitcoin's current market price as a proxy) and these announcements would be very reliable. (To be clear: the entire point of these announcements is to tweak the block mining reward to stabilize the bitcoin' price. The basic idea: reliable announcements of current BTC' prices are announced into the BTC' network. The mining block reward is constantly fluctuating depending on the current BTC' price. If BTC' is relatively high, the block reward increases, attracting miners. If low, the reward is lowered.) Just make these announcements into the form of offers to buy and sell bitcoin' for the commodity/basket/asset against which it's stabilized. For example, if the current market price of a bitcoin' is 1 USD, then an announcer might announce "I'll sell 1000 bitcoin' for 1.1 USD each and buy 1000 for 0.9 USD each". If the announcement is <em>binding</em>, then you can bet that announcement is not going to be disadvantageous to the announcer! One can reliably deduce a current price bracket for bitcoin'. Again, though, one needs a reliable way to enforce bitcoin contracts exchanging real-world commodities like USD.</p>

CC BY-SA 3.0
2013-12-10T11:05:57.520Z
You can determine the price in a decentralised way. Which exchange, how much is it weighted, is this exchange real? Who decides? It can't possibly work the way you think.
Anonymous
CC BY-SA 3.0
2013-12-10T11:22:57.963Z
@Anonymous I don't understand your comment. And I don't know how to respond to "It can't possibly work the way you think." Why not? Of course, the systems I proposed are built on assumptions. In Update 1, I assume there is a centralized trusted entity that honestly announces price quotes. And in Update 2, I assume there is a way to enforce bitcoin contracts that trade the real world commodity(s) against which bitcoin' is stabilized. Outside these assumptions (which are, after all, assumptions), what is wrong with the proposals?
Will Nelson
CC BY-SA 3.0
2013-12-10T11:25:14.677Z
@Anonymous By the way, I believe that billions of USD worth of contracts are written and traded everyday whose payouts depend intimately on publicly available price quotes.
Will Nelson
CC BY-SA 3.0
2013-12-10T11:37:30.660Z
You assume there's a trusted entity, but there can't be one, that's literally the entire concept of Bitcoin. The rest is irrelevant. There's no way of having a decentralised Bitcoin "price", so we don't even need to consider anything outside of that.
Anonymous
CC BY-SA 3.0
2013-12-10T12:00:02.303Z
"There's no way of having a decentralized Bitcoin 'price'." I think you are wrong here. Do we have one "monopolistic" exchange for Bitcoin? The answer is "NO" - I know at least several exchanges... So the exchange system is already a decentralized one with each entity having its own (decentralized) price. I guess you can agree with this, right?
Kozuch
CC BY-SA 3.0
2013-12-10T12:02:11.660Z
@Anonymous I assume a trusted entity in Update 1, but not Update 2. And the entire concept of bitcoin is to remove the trusted entity *that prevents double spending*. Not all trusted entities are necessarily always bad. Personally, I'm open minded to their possibilities, though of course it's desirable to minimize their involvement for lots of reasons. Personally, though, I like my proposal in Update 2. But how to enforce bitcoin contracts for real-world goods? Gotta rely on "the man with the gun" for that, I'm afraid...
Will Nelson
CC BY-SA 3.0
2013-12-10T12:11:29.527Z
@Will Nelson: Why would you want to enforce the contracts? I think what you are talking about is more about "pegging" the bitcoin' to some "basket of goods" - do we really need that? I am happy with the idea of price showing popularity. I think the question is rather how to solve the variable block rewards technically within a network...
Kozuch
CC BY-SA 3.0
2013-12-10T12:17:39.690Z
@Kozuch, The announcement contracts are enforced to ensure the announcers are making trustworthy announcements. That way there is no single trusted entity announcing prices. Anyone can announce the current "price" by saying "I'll buy for X and sell for Y". If their announcement is *wrong*, they'll regret it because someone is going to take them up on their offer and buy/sell bitcoin for a disadvantageous price. Do you see? And with this mechanism, there is no single entity you need to trust to announce prices/popularity.
Will Nelson
CC BY-SA 3.0
2013-12-10T12:28:11.837Z
@Kozuch, Yes, I was thinking in terms of stabilizing the currency with respect to some basket of goods. I think that, fundamentally, any natural definition of stabilization must ultimately rely on some type of average price of real goods. (That average price may be very indirect, of course, perhaps some market mechanism "computes" the average.) Why does BCT look unstable right now? Because last year a pizza cost 100 BCT and now a pizza *restaurant* costs 100 BCT. It's all relative...
Will Nelson
CC BY-SA 3.0
2013-12-10T12:30:55.537Z
@Will Nelson (replying to your previous comment - not your very last one): Well I still can not get the point. You seem to contradict yourself (not meant to offend you). Well, with several exchanges (BTC China, Mt.Gox, Bitstamp etc.) we already have a decentralized prices and is such a price what you want to create with your enforcement? And I think the traded volume at a certain price point is what makes that price legitimate? So you basically would be looking for a price where the trading volume was rather high.
Kozuch
CC BY-SA 3.0
2013-12-10T12:34:53.843Z
@Will Nelson: Your 100 BTC for pizza or pizza restaurant is a volatility issue - variable block rewards should eliminate such volatility.
Kozuch
CC BY-SA 3.0
2013-12-10T12:42:56.533Z
@Kozuch Where's the contradiction? How do you eliminate the need for a centralized trusted entity to announce popularity? Make it so anyone can announce popularity. How can you trust a stranger's announcement of popularity? One way is to have the stranger make his announcement in the form of a legally binding contract: if he says, "I will buy 1 BCT for 1USD or sell for 2USD", you know the price of 1 BCT is likely between 1USD and 2 USD. No trust required. But I think your point is that this idea duplicates an exchange mechanism (e.g., Mt Gox). True. That's perhaps a shortcoming.
Will Nelson
CC BY-SA 3.0
2013-12-10T12:44:56.060Z
@Kozuch. Well, yes, you basically repeated my "pizza" point. If the price of BTC were constantly announced into the BTC network and the block reward constantly adjusted *in response* to these announcements, it would tend to stabilize BTC with respect to real world goods. The price of a pizza in BTC would be more stable. That's the whole point...
Will Nelson
CC BY-SA 3.0
2013-12-10T12:47:22.930Z
@Kozuch - I'd chat, but SE won't let me, it seems. Perhaps you misunderstood. See the paragraph of my response beginning, "If the bitcoin' price is high...". The whole idea of all this price announcement stuff is to tweak the block reward up or down to stabilize the bitcoin' price...
Will Nelson
CC BY-SA 3.0
2013-12-10T12:51:35.470Z
Yes so we can agree to have a (trusted) price announced somehow (I propose looking at exchanges - see my comment about VWAP). But I was told it is not so easy to make variable block reward work technically (in terms of software client). So I rather want to focus on the coding part since the theory seems to be cleared. Can you help with software engineering?
Kozuch
CC BY-SA 3.0
2013-12-10T12:56:00.303Z
So then we have a "trusted" central exchange which can be shut down to destroy the coin. That's exactly what the system is designed to stop, central control that can be disrupted. This has been proposed on `bitcoin-development` more times than I can remember, and it's consistently shot down, actually inducing mirth in the core team. See this similar idea http://sourceforge.net/mailarchive/forum.php?thread_name=CA%2Bs%2BGJDJA7_HOiJ-_jazXERSYfWvO-DHk89ih4pG8dEK5K9Z9A%40mail.gmail.com&forum_name=bitcoin-development
Anonymous
CC BY-SA 3.0
2013-12-10T13:00:50.843Z
@Kozuch I understand your concern now. I'm not a BTC code expert (quite yet), but the idea is currently completely technically feasible within the framework of BTC. Obviously, it would not be at all backward compatible, if that's what you're looking for. My guess: The block reward code is hardcoded and all nodes must perform precisely the same reward calculations or different nodes would be accept/reject blocks differently. No way it'd work with the current installed base.
Will Nelson
CC BY-SA 3.0
2013-12-10T13:03:44.040Z
@Anonymous: Well, I dont really care what the "core team" thinks. Sure they want to preserve status quo because these people hoard the most BTCs in existence and they want the price to rise and are naturally against any self-regulatory mechanism. The trend with exchanges is decentralization I think - you can not deny this fact. Yes, more time will be needed for even more exchanges to spring up and help build even more decentralized price. But we are heading that direction already.
Kozuch
CC BY-SA 3.0
2013-12-10T13:11:00.520Z
@Will Nelson: Yes, we are talking about new/forked coin (alternative chain) so compatibility with Bitcoin is a nonsense and is not wanted. I thought like this: every node would propose reward value. The node creating new block would read all proposals and choose median value. If it fails to obey this value, other nodes will not include its block into the block chain - effectively not giving it any reward at all. But I am not sure how (or if at all) this is technically doable. But you say it is doable?
Kozuch
CC BY-SA 3.0
2013-12-10T13:12:27.587Z
@Kozuch You would be greatly mistaken in thinking that.
Anonymous
CC BY-SA 3.0
2013-12-10T13:12:32.370Z
@Anonymous Thank you for the pointer to the mail archive. That was useful. I'm quite sure the developers are laughing because of course BTC can't be changed at this point. It would (I'm pretty sure) clearly kill the currency both technically (forking everywhere) and economically. As mentioned on the list, you'd be changing the rules of bitcoin midstream -- exactly the type of garbage many of us want to prevent. There's no way to implement this idea without creating a new currency from scratch.
Will Nelson
CC BY-SA 3.0
2013-12-10T13:14:24.853Z
PS. I asked about feasibility at #bitcoin-dev on Freenode... was probably a completely wrong place to get a positive answer because of reasons Anonymous stated above - they simply dont want to support anyone making such fork, because the new coin will bring Bitcoin to hell :).
Kozuch
CC BY-SA 3.0
2013-12-10T13:18:59.747Z
@Kozuch That protocol doesn't sound right to me. And that'd be a BIG change to the BTC codebase. How can you verify medians with nodes coming and going? And who's a "legitimate" node in the median calculation? And I'm not quite sure that solves the problem. Again, the problem of stability is, basically, one of relatively loose linkage with real world commodity prices. The idea I had in mind was: (1) special transactions announcing current price is broadcast to all nodes, (2) nodes "authenticate" price announcements by either looking at a signature with one of N well-known public keys or...
Will Nelson
CC BY-SA 3.0
2013-12-10T13:21:14.193Z
through the *binding contract* mechanism I described in  Update 2, then (3) block mining rewards are tweaked in response to latest price announcements. This seems like an easy modification to the BTC protocol and codebase (I think). But it's far from backward compatible.
Will Nelson
CC BY-SA 3.0
2013-12-10T13:26:31.977Z
@Anonymous: Greatly mistaken in thinking what?
Kozuch
CC BY-SA 3.0
2013-12-10T13:35:42.167Z
@Will Nelson: I am open to any SW solution, particularly simple and inexpensive one :). I like your protocol proposal very  much! Regarding point #2 - I would go with the public keys since you can not do binding contract easily in P2P. I guess the holder(s) of those public keys would (have to) be publicly known and real (not anonymous) persons? If so, that could bring some more trust to the network which would actually be good.
Kozuch
CC BY-SA 3.0
2013-12-10T13:54:25.907Z
@Kozuch Maybe you can ask the BTC core developers or some similar group how difficult it would be to fork the BTC code and implement. (Please let me know if you learn anything interesting!) More ideas just off the top of my head: each "coinbase" transaction could take one input (instead of current 0) that points to a special "price" announcement transaction that determines its block reward. And special public keys would be hardcoded into codebase distribution. (That's typically the way SSL works with its certificate authorities. Research that for more info.) Good luck!
Will Nelson
CC BY-SA 3.0
2013-12-10T14:03:38.867Z
@Will Nelson: Thanks for all your valuable contributions to the topic! I dont know how fast I will proceed, my resources are naturally limited. I will see. I rather try to spread the word, occasionally finding someone who does not like status quo too :).
Kozuch
CC BY-SA 3.0
2013-12-10T16:18:44.057Z
Howdy folks, this comment thread is getting pretty long - please consider moving this to [chat] if you've got more to discuss - a link to the transcript will be here so folks find the conversation.
Tim Post
CC BY-SA 3.0
2013-12-10T10:07:28.010Z
2013-12-10T14:11:50.167Z
2013-12-10T14:11:50.167Z
Will Nelson
<p>The block reward amount could be solved making it based at hash rate, this assumes that when you have bigger hash rate it means the coin have more value.</p>

<p>Imagine you have a coin with a block time of 8 minutes and 525960 coins.</p>

<p>First you would decide the amount of time you would want all coins to be mined assuming a hash rate of X. Lets assume you want 8 years, this means 525960 blocks assuming 8 minutes of block time.</p>

<p>This means that (with a hash rate of X) to get 525960 coins needing 525960 blocks to get it, you would need an reward of 1 coin per block.</p>

<p>Now that you made that math, you will have your default block reward value (1 coin with hash rate of X).</p>

<p>The real block reward of each block will be 1 / ((Hash rate) / X). </p>

<p>As some example with X being 10, if the hash rate become 2x times that, a hash rate of 20, the block reward become 1/(20/10) = 0.5 coins</p>

CC BY-SA 4.0
2020-05-19T15:01:15.223Z
2020-05-19T15:01:15.223Z
caninco
<p>I am thinking of an alternative mining scheme where block reward would grow (or decrease) with popularity of the coin. The rationale behind this idea is to make an exchange rate more stable since greater interest will not result in higher coin price.</p>

<p>The biggest question is probably how to technically solve such variable block reward because there seems to be no easy way of how to collectively decide on reward height.</p>

CC BY-SA 3.0
2013-12-10T11:50:46.163Z
To echo the sentiment of my answer below: Market prices are *exactly* measures of popularity and they are very efficiently and effectively decided all the time. If you are speculating on possible future scenarios, I suggest thinking about ways people will try to leverage the celebrated information processing capabilities of prices and markets.
Will Nelson
<exchange-rate><mining-reward><alternatives><altcoin-development>
Popularity based mining (variable block reward)
Kozuch
# Popularity based mining (variable block reward)

(Asked by: username_0 on 2013-12-10)

I am thinking of an alternative mining scheme where block reward would grow (or decrease) with popularity of the coin. The rationale behind this idea is to make an exchange rate more stable since greater interest username_1 not result in higher coin price.

The biggest question is probably how to technically solve such variable block reward because there seems to be no easy way of how to collectively decide on reward height.

**Tags:** exchange-rate, mining-reward, alternatives, altcoin-development

> **Comments:**
> **username_1**: To echo the sentiment of my answer below: Market prices are *exactly* measures of popularity and they are very efficiently and effectively decided all the time. If you are speculating on possible future scenarios, I suggest thinking about ways people username_1 try to leverage the celebrated information processing capabilities of prices and markets.  

---

## 3 answers

### Answer by username_2 on 2013-12-10. Score: 1

How would you define popularity? Any measure you make must be decentralised, and whatever you decide on can be arbitrarily faked. It's completely impossible in the terms of a trustless currency like Bitcoin.

> **Comments:**
> **username_0**: Market price is a measure of popularity. Since there is no monopoly on exchanges anyone can run one. Then you probably want to count a VWAP (Volume-weighted average price) across the whole exchange market and you should be all set.  
> **username_3**: @username_0 And how would you *reliably* measure that? What about lying exchanges?  
> **username_0**: @username_3: What exactly are you asking about measuring? I just proposed one way above (VWAP). There seem to be a real paranoia within the Bitcoin community in linking some "real world data" to the protocol - developers say it is a "vulnerability" and they username_1 never do it - this is laughable. In the meantime, the only vulnerable thing here is Bitcoin itself... nobody knows whether it username_1 be here tomorrow. Why an exchange doesnt want to lie? Because if people realized the exchanges would go out of business???  
> **username_3**: @username_0 You did not say how you measure the VWAP and feed it to the protocol in a secure fashion. What if I open "Honest Achmed's Bitcoin exchange" and report that I exchanged a billion bitcoins for a dollar each?  
> **username_0**: Ok, I get what you mean now. Well each node would need to filter such exchanges out... If the exchange is new and nodes do not trust it, they simply would not use its prices within VWAP. In the end what we need is block reward height, so nodes have to calculate it somehow... maybe price is only one input for such calculation. Number of transactions (which also gives the economy value) could be another input. Actually the more inputs we have the less risky the final calculation should be...  

---

### Answer by username_1 on 2013-12-10. Score: 0

I've recently thought of pretty much the same thing.

@username_2: Popularity is not difficult to define. Call the new currency bitcoin'. A good measure is the price of a bitcoin' in terms of some broad index of consumer goods (like the CPI basket), commodities, or whatever else you want. Perhaps the best available measure of popularity is MtGox's current price in USD, or EUR, etc.

If the bitcoin' price is high, the mining reward rises, essentially quickly generating new bitcoin', thereby lowering their price. A falling bitcoin' price would trigger higher mining rewards to slow the supply expansion.

Practically, at present, I think the extra stabilization provided by such a system would be minimal. But my opinions on the matter are currently not too strong.

Note that the current mining system already works to stabilize the price of a bitcoin to some extent: as the price of a bitcoin rises, more miners enter, increasing the supply and helping to drive down prices. But how's that system working out? So far, not so great as far as stability goes.
And of course, when the ~21M bitcoin cap is hit, there username_1 no longer be any stabilization mechanism available that links bitcoin supply with bitcoin price.

**UPDATE 1** I forgot to mention the important question of how "popularity" is announced/communicated into the bitcoin' system. Very good question. One could imagine a trusted entity with a well-known public key signing such announcements and system nodes verifying that particular entity's signature.

One nice aspect: the "popularity" measure could be relatively objective, e.g., latest publicly available quoted price from a popular exchange. This would at least allow anyone in the world to determine whether this trusted entity is really trustworthy (are they lying about publicly available quoted prices???). But admittedly, this is a real sticking point in the design, e.g., what if this trusted entity is hacked?

**UPDATE 2** Another related idea: if one could reliably enforce bitcoin contracts that involve trades of other real-world commodities/assets, then it'd be easy to construct a decentralized system in which many username_2 entities publicly announce bitcoin's "popularity" (again, use bitcoin's current market price as a proxy) and these announcements would be very reliable. (To be clear: the entire point of these announcements is to tweak the block mining reward to stabilize the bitcoin' price. The basic idea: reliable announcements of current BTC' prices are announced into the BTC' network. The mining block reward is constantly fluctuating depending on the current BTC' price. If BTC' is relatively high, the block reward increases, attracting miners. If low, the reward is lowered.) Just make these announcements into the form of offers to buy and sell bitcoin' for the commodity/basket/asset against which it's stabilized. For example, if the current market price of a bitcoin' is 1 USD, then an announcer might announce "I'll sell 1000 bitcoin' for 1.1 USD each and buy 1000 for 0.9 USD each". If the announcement is *binding*, then you can bet that announcement is not going to be disadvantageous to the announcer! One can reliably deduce a current price bracket for bitcoin'. Again, though, one needs a reliable way to enforce bitcoin contracts exchanging real-world commodities like USD.

> **Comments:**
> **username_2**: You can determine the price in a decentralised way. Which exchange, how much is it weighted, is this exchange real? Who decides? It can't possibly work the way you think.  
> **username_1**: @username_2 I don't understand your comment. And I don't know how to respond to "It can't possibly work the way you think." Why not? Of course, the systems I proposed are built on assumptions. In Update 1, I assume there is a centralized trusted entity that honestly announces price quotes. And in Update 2, I assume there is a way to enforce bitcoin contracts that trade the real world commodity(s) against which bitcoin' is stabilized. Outside these assumptions (which are, after all, assumptions), what is wrong with the proposals?  
> **username_1**: @username_2 By the way, I believe that billions of USD worth of contracts are written and traded everyday whose payouts depend intimately on publicly available price quotes.  
> **username_2**: You assume there's a trusted entity, but there can't be one, that's literally the entire concept of Bitcoin. The rest is irrelevant. There's no way of having a decentralised Bitcoin "price", so we don't even need to consider anything outside of that.  
> **username_0**: "There's no way of having a decentralized Bitcoin 'price'." I think you are wrong here. Do we have one "monopolistic" exchange for Bitcoin? The answer is "NO" - I know at least several exchanges... So the exchange system is already a decentralized one with each entity having its own (decentralized) price. I guess you can agree with this, right?  
> **username_1**: @username_2 I assume a trusted entity in Update 1, but not Update 2. And the entire concept of bitcoin is to remove the trusted entity *that prevents double spending*. Not all trusted entities are necessarily always bad. Personally, I'm open minded to their possibilities, though of course it's desirable to minimize their involvement for lots of reasons. Personally, though, I like my proposal in Update 2. But how to enforce bitcoin contracts for real-world goods? Gotta rely on "the man with the gun" for that, I'm afraid...  
> **username_0**: @username_1: Why would you want to enforce the contracts? I think what you are talking about is more about "pegging" the bitcoin' to some "basket of goods" - do we really need that? I am happy with the idea of price showing popularity. I think the question is rather how to solve the variable block rewards technically within a network...  
> **username_1**: @username_0, The announcement contracts are enforced to ensure the announcers are making trustworthy announcements. That way there is no single trusted entity announcing prices. Anyone can announce the current "price" by saying "I'll buy for X and sell for Y". If their announcement is *wrong*, they'll regret it because someone is going to take them up on their offer and buy/sell bitcoin for a disadvantageous price. Do you see? And with this mechanism, there is no single entity you need to trust to announce prices/popularity.  
> **username_1**: @username_0, Yes, I was thinking in terms of stabilizing the currency with respect to some basket of goods. I think that, fundamentally, any natural definition of stabilization must ultimately rely on some type of average price of real goods. (That average price may be very indirect, of course, perhaps some market mechanism "computes" the average.) Why does BCT look unstable right now? Because last year a pizza cost 100 BCT and now a pizza *restaurant* costs 100 BCT. It's all relative...  
> **username_0**: @username_1 (replying to your previous comment - not your very last one): Well I still can not get the point. You seem to contradict yourself (not meant to offend you). Well, with several exchanges (BTC China, Mt.Gox, Bitstamp etc.) we already have a decentralized prices and is such a price what you want to create with your enforcement? And I think the traded volume at a certain price point is what makes that price legitimate? So you basically would be looking for a price where the trading volume was rather high.  
> **username_0**: @username_1: Your 100 BTC for pizza or pizza restaurant is a volatility issue - variable block rewards should eliminate such volatility.  
> **username_1**: @username_0 Where's the contradiction? How do you eliminate the need for a centralized trusted entity to announce popularity? Make it so anyone can announce popularity. How can you trust a stranger's announcement of popularity? One way is to have the stranger make his announcement in the form of a legally binding contract: if he says, "I username_1 buy 1 BCT for 1USD or sell for 2USD", you know the price of 1 BCT is likely between 1USD and 2 USD. No trust required. But I think your point is that this idea duplicates an exchange mechanism (e.g., Mt Gox). True. That's perhaps a shortcoming.  
> **username_1**: @username_0. Well, yes, you basically repeated my "pizza" point. If the price of BTC were constantly announced into the BTC network and the block reward constantly adjusted *in response* to these announcements, it would tend to stabilize BTC with respect to real world goods. The price of a pizza in BTC would be more stable. That's the whole point...  
> **username_1**: @username_0 - I'd chat, but SE won't let me, it seems. Perhaps you misunderstood. See the paragraph of my response beginning, "If the bitcoin' price is high...". The whole idea of all this price announcement stuff is to tweak the block reward up or down to stabilize the bitcoin' price...  
> **username_0**: Yes so we can agree to have a (trusted) price announced somehow (I propose looking at exchanges - see my comment about VWAP). But I was told it is not so easy to make variable block reward work technically (in terms of software client). So I rather want to focus on the coding part since the theory seems to be cleared. Can you help with software engineering?  
> **username_2**: So then we have a "trusted" central exchange which can be shut down to destroy the coin. That's exactly what the system is designed to stop, central control that can be disrupted. This has been proposed on `bitcoin-development` more times than I can remember, and it's consistently shot down, actually inducing mirth in the core team. See this similar idea http://sourceforge.net/mailarchive/forum.php?thread_name=CA%2Bs%2BGJDJA7_HOiJ-_jazXERSYfWvO-DHk89ih4pG8dEK5K9Z9A%40mail.gmail.com&forum_name=bitcoin-development  
> **username_1**: @username_0 I understand your concern now. I'm not a BTC code expert (quite yet), but the idea is currently completely technically feasible within the framework of BTC. Obviously, it would not be at all backward compatible, if that's what you're looking for. My guess: The block reward code is hardcoded and all nodes must perform precisely the same reward calculations or different nodes would be accept/reject blocks differently. No way it'd work with the current installed base.  
> **username_0**: @username_2: Well, I dont really care what the "core team" thinks. Sure they want to preserve status quo because these people hoard the most BTCs in existence and they want the price to rise and are naturally against any self-regulatory mechanism. The trend with exchanges is decentralization I think - you can not deny this fact. Yes, more time username_1 be needed for even more exchanges to spring up and help build even more decentralized price. But we are heading that direction already.  
> **username_0**: @username_1: Yes, we are talking about new/forked coin (alternative chain) so compatibility with Bitcoin is a nonsense and is not wanted. I thought like this: every node would propose reward value. The node creating new block would read all proposals and choose median value. If it fails to obey this value, other nodes username_1 not include its block into the block chain - effectively not giving it any reward at all. But I am not sure how (or if at all) this is technically doable. But you say it is doable?  
> **username_2**: @username_0 You would be greatly mistaken in thinking that.  
> **username_1**: @username_2 Thank you for the pointer to the mail archive. That was useful. I'm quite sure the developers are laughing because of course BTC can't be changed at this point. It would (I'm pretty sure) clearly kill the currency both technically (forking everywhere) and economically. As mentioned on the list, you'd be changing the rules of bitcoin midstream -- exactly the type of garbage many of us want to prevent. There's no way to implement this idea without creating a new currency from scratch.  
> **username_0**: PS. I asked about feasibility at #bitcoin-dev on Freenode... was probably a completely wrong place to get a positive answer because of reasons username_2 stated above - they simply dont want to support anyone making such fork, because the new coin username_1 bring Bitcoin to hell :).  
> **username_1**: @username_0 That protocol doesn't sound right to me. And that'd be a BIG change to the BTC codebase. How can you verify medians with nodes coming and going? And who's a "legitimate" node in the median calculation? And I'm not quite sure that solves the problem. Again, the problem of stability is, basically, one of relatively loose linkage with real world commodity prices. The idea I had in mind was: (1) special transactions announcing current price is broadcast to all nodes, (2) nodes "authenticate" price announcements by either looking at a signature with one of N well-known public keys or...  
> **username_1**: through the *binding contract* mechanism I described in  Update 2, then (3) block mining rewards are tweaked in response to latest price announcements. This seems like an easy modification to the BTC protocol and codebase (I think). But it's far from backward compatible.  
> **username_0**: @username_2: Greatly mistaken in thinking what?  
> **username_0**: @username_1: I am open to any SW solution, particularly simple and inexpensive one :). I like your protocol proposal very  much! Regarding point #2 - I would go with the public keys since you can not do binding contract easily in P2P. I guess the holder(s) of those public keys would (have to) be publicly known and real (not username_2) persons? If so, that could bring some more trust to the network which would actually be good.  
> **username_1**: @username_0 Maybe you can ask the BTC core developers or some similar group how difficult it would be to fork the BTC code and implement. (Please let me know if you learn anything interesting!) More ideas just off the top of my head: each "coinbase" transaction could take one input (instead of current 0) that points to a special "price" announcement transaction that determines its block reward. And special public keys would be hardcoded into codebase distribution. (That's typically the way SSL works with its certificate authorities. Research that for more info.) Good luck!  
> **username_0**: @username_1: Thanks for all your valuable contributions to the topic! I dont know how fast I username_1 proceed, my resources are naturally limited. I username_1 see. I rather try to spread the word, occasionally finding someone who does not like status quo too :).  
> **username_4**: Howdy folks, this comment thread is getting pretty long - please consider moving this to [chat] if you've got more to discuss - a link to the transcript username_1 be here so folks find the conversation.  

---

### Answer by username_5 on 2020-05-19. Score: 0

The block reward amount could be solved making it based at hash rate, this assumes that when you have bigger hash rate it means the coin have more value.

Imagine you have a coin with a block time of 8 minutes and 525960 coins.

First you would decide the amount of time you would want all coins to be mined assuming a hash rate of X. Lets assume you want 8 years, this means 525960 blocks assuming 8 minutes of block time.

This means that (with a hash rate of X) to get 525960 coins needing 525960 blocks to get it, you would need an reward of 1 coin per block.

Now that you made that math, you username_1 have your default block reward value (1 coin with hash rate of X).

The real block reward of each block username_1 be 1 / ((Hash rate) / X).

As some example with X being 10, if the hash rate become 2x times that, a hash rate of 20, the block reward become 1/(20/10) = 0.5 coins


---

