From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 053C91177 for ; Mon, 15 Jan 2018 22:47:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 937FC47C for ; Mon, 15 Jan 2018 22:47:55 +0000 (UTC) Received: by mail-it0-f51.google.com with SMTP id 196so2612087iti.5 for ; Mon, 15 Jan 2018 14:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TcVe8fTxnpSnNS9csuIliaU77Z/6HNLjSl3tcWTXoWk=; b=FthVwRgvZGe2SofyGCo93Ss88X/9kZplKhdtrzhqox+RB+McukMenctVHpmp73Gv3b aAp/zOB6GWpUtVOq/00TE1IxOwUy4vYV+xjbSS+2nHmRLhSX9zb9WznL5O8THNbf9FJR owVbijyLp4q+/wBp8O3uDs41BrZAOBQxayniosDH4RRp3HuScC8pAwLxJgUUbdGf38Ab XL64v5FDGKXyQIVohenpMx4LLWfD+bLP8ItmKFXovMs0l5h0IxM2QCyCR2EyVLwFuMq+ uKeg6kJm71/G7SJd6VVGBMlR42cgabawgVyHislF8k2pN1DHWsNTJddOZo0SW64ulcNk rrQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TcVe8fTxnpSnNS9csuIliaU77Z/6HNLjSl3tcWTXoWk=; b=BWl9DMqt3t3a7UR23QbiH/TdtTtYUWR40BSa/SunXAKG7ksQG04jAzsmpiQJ809TDu 2VMjFCWhJsRqzBQt9ZOmHn/r2uptnPfyM7MRTnMfS7BJaYX+SLUu76UDqOxasmXOuJ1c gxk7hX6yAwQLf/xmQWt31VjAo07bjcVqZ9c+QDQiaiUWgN68oOfZkkkbj37X4367fQeS zz6AAMZSvsITwOqrOCEOOQT0BGahLW2nNb3oNGOjiDNLKQHCLqM8GyCfBPuyUyZkkwau 6qSsjGGCSm1fEYY9YWkFiArdTs/6TMO/5WYfeFCMQo1wyNoCPKpgV/Wb6Qdeaj4M64oa AsAA== X-Gm-Message-State: AKwxyteQqPX4FoRLkeZC0tIvDGihlYUzEtUE/3DGRkhHHYnURTMyGecT yH653HvdEUUqyl+kcoSUmd0/uIZ4z2xMlT2D+sDutQ== X-Google-Smtp-Source: ACJfBosQYfQtJKjwr14KijJpVJgCfeyd/52o/expOX9JpegnC0e8Jy6Chta1wumh060cJZJVgHQfyLrGqUODO7buyhQ= X-Received: by 10.36.104.210 with SMTP id v201mr14776611itb.64.1516056474725; Mon, 15 Jan 2018 14:47:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.73.69 with HTTP; Mon, 15 Jan 2018 14:47:54 -0800 (PST) From: =?UTF-8?Q?Enrique_Ariz=C3=B3n_Benito?= Date: Mon, 15 Jan 2018 23:47:54 +0100 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="001a1143ab62a2b2520562d8670d" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 15 Jan 2018 22:49:44 +0000 Subject: [bitcoin-dev] Proposal to reduce mining power bill X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 22:47:56 -0000 --001a1143ab62a2b2520562d8670d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, just new to the list and curious to know if next proposal (or similar) for reducing mining-power consumption has already been discussed. The objective is to reduce the power consumption required while keeping the network safe and the miners "motivated" and cooperative to continue mining: The global idea is to introduce the concept of "next-coinbase" for miners. This will work something like as follow: - Any miner submitting a block will submit the "next-coinbase" for any new block mined by itself. (This address can be the same one or different from the just mined block). The miner keeps the private key associated with the "next-coinbase" secret. - The consensus algorithm will add next checks: A hash from, for example, the just mined block and the previous one, will have to match up to N bits for the next "next-coinbase" from the next block to be valid. That means that for the next block only 1/2^N bitcoin addresses will be accepted from the previously submitted "next-coinbase" list. Since the last previous block hash can be considered random, miners know in advance whether they will be able to participate or not in the next block depending on the just submited "next-coinbase". And since the "punishment" is distributed uniformely random to all miners no one has any advantage over the other. But the global miner netwok will consume much less power. A detail rest: New miners are not allowed in such scheme so next addition is needed: - A miner with no previous "next-coinbase" will need to first mine an special block, "new-miner-block", that instead of normal transactions will register the new miner and submit a "next-coinbase". This special block will not be rewarded with new bitcoins. The only reward will be the permission to mine in following blocks. No reward is applied so only new miners wanting to "enter" the mining network are expected to create such block. Best Regards, E. Ariz=C3=B3n Benito --001a1143ab62a2b2520562d8670d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

just new = to the list and curious to know if next proposal (or similar) for reducing = mining-power consumption has already been discussed.

The objective is to reduce the power consumption required while keeping = the network safe and the miners "motivated" and cooperative to co= ntinue mining:

The global idea is to introduce= the concept of "next-coinbase" for miners. This will work someth= ing like as follow:

- Any miner sub= mitting a block will submit the "next-coinbase" for any new block= mined by itself. (This address can be the same one or different from the j= ust mined block). The miner keeps the private key associated with the "= ;next-coinbase" secret.

- The = consensus algorithm will add next checks:
=C2=A0A hash from, = for example, the just mined block and the previous one, will have to match = up to N bits for the next "next-coinbase" from the next block to = be valid.

=C2=A0That means that for the next = block only 1/2^N bitcoin addresses will be accepted from the previously sub= mitted "next-coinbase" list.

Since the l= ast previous block hash can be considered random, miners know in advance whether they will be able to participate or not in the next blo= ck depending on the just submited "next-coinbase". And since the = "punishment" is distributed uniformely random to all miners no on= e has any advantage over the other. But the global miner netwok will consum= e much less power.

A detail rest: New miners = are not allowed in such scheme so next addition is needed:

- A miner with no previous "next-coinbase" will need to first m= ine an special block, "new-miner-block", that instead of normal t= ransactions will register the new miner and submit a "next-coinbase&qu= ot;. This special block will not be rewarded with new bitcoins. The only re= ward will be the permission to mine in following blocks. No reward is appli= ed so only new miners wanting to "enter" the mining network are e= xpected to create such block.

Best Regards,
<= div>
E. Ariz=C3=B3n Benito

--001a1143ab62a2b2520562d8670d--