Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VqQ5U-0006JV-TI for bitcoin-development@lists.sourceforge.net; Tue, 10 Dec 2013 16:23:08 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.54 as permitted sender) client-ip=209.85.215.54; envelope-from=kozuch82@gmail.com; helo=mail-la0-f54.google.com; Received: from mail-la0-f54.google.com ([209.85.215.54]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VqQ5T-0006Kw-UD for bitcoin-development@lists.sourceforge.net; Tue, 10 Dec 2013 16:23:08 +0000 Received: by mail-la0-f54.google.com with SMTP id b8so2824071lan.41 for ; Tue, 10 Dec 2013 08:23:01 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.225.161 with SMTP id rl1mr8569620lac.5.1386692581195; Tue, 10 Dec 2013 08:23:01 -0800 (PST) Received: by 10.114.184.143 with HTTP; Tue, 10 Dec 2013 08:23:01 -0800 (PST) Date: Tue, 10 Dec 2013 17:23:01 +0100 Message-ID: From: =?ISO-8859-2?Q?Jan_Ku=E8era?= To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=001a113490fab702b804ed30861e X-Spam-Score: -0.3 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (kozuch82[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (kozuch82[at]gmail.com) 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VqQ5T-0006Kw-UD Subject: [Bitcoin-development] Popularity based mining (variable block reward) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:23:09 -0000 --001a113490fab702b804ed30861e Content-Type: text/plain; charset=ISO-8859-1 Hi there, I am not sure this wont be considered as off-topic here, but I did not find a better place to ask. My question is - has anybody here thought about the idea of variable block rewards where mining would essentially be popularity based? I mean in terms either improving Bitcoin's protocol or forking a completely new coin? I think elasticity of money supply could bring more exchange rate stability to the hypothetical new coin (say there'd be a demand for such a coin). 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. Evidence clearly shows Bitcoin lacks some basic features of money and thus behaves more like a commodity (read gold). I have been watching the exchange rate for several months and the volatility simply does not seem to go away... so it seems like something has to change in order to get a more stable currency. I am not telling I want Bitcoin to implement this, I fully understand that a philosophy of "one coin = never changing features" can be present that is why I also speak about a fork. Basically there would be no reliance on external data as the network itself would decide on reward height and everybody node would be free to do so. Each network node would determine the popularity on its own depending on various factors (coin valuation/exchange rate, number of transactions and many others) and basically come up with its own block reward value. It would then want to see a new block being mined with such reward value. In case such a block is mined, it will include it in its own chain. There'd be some %s of tolerance for block reward value so that the system would not collapse. I may be completely wrong with my idea but am asking it this was spoken before and what opinions do developers have. Regards, Jan --001a113490fab702b804ed30861e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi there,

I am not sure this wont be considered as = off-topic here, but I did not find a better place to ask. My question is - = has anybody here thought about the idea of variable block rewards where min= ing would essentially be popularity based? I mean in terms either improving= Bitcoin's protocol or forking a completely new coin? I think elasticit= y of money supply could bring more exchange rate stability to the hypotheti= cal new coin (say there'd be a demand for such a coin). I am thinking o= f 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 e= xchange rate more stable since greater interest will not result in higher c= oin price.

Evidence clearly shows Bitcoin lacks some basic features of money and t= hus behaves more like a commodity (read gold). I have been watching the exc= hange rate for several months and the volatility simply does not seem to go= away... so it seems like something has to change in order to get a more st= able currency. I am not telling I want Bitcoin to implement this, I fully u= nderstand that a philosophy of "one coin =3D never changing features&q= uot; can be present that is why I also speak about a fork.

Basically there would be no reliance on external data as the network it= self would decide on reward height and everybody node would be free to do s= o. Each network node would determine the popularity on its own depending on= various factors (coin valuation/exchange rate, number of transactions and = many others) and basically come up with its own block reward value. It woul= d then want to see a new block being mined with such reward value. In case = such a block is mined, it will include it in its own chain. There'd be = some %s of tolerance for block reward value so that the system would not co= llapse.

I may be completely wrong with my idea but am asking it= this was spoken before and what opinions do developers have.
Regards,
Jan
--001a113490fab702b804ed30861e--