public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "René Pickhardt" <r.pickhardt@googlemail.com>
To: Michael Fuhrmann <fuhmic@web.de>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
Date: Sun, 16 May 2021 00:14:13 +0200	[thread overview]
Message-ID: <CAJ5H3Z5C_Rjszb1QgGqhJa5F2_ts4CoT=1c0=efBcK8D96Svdw@mail.gmail.com> (raw)
In-Reply-To: <d35dee03-2d19-e80a-c577-2151938f9203@web.de>

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

Hey Michael,

First I think the idea of "do nothing in the first 9 minutes" will
unfortunately not be useful as the computed work is mainly there to prevent
miners from altering the history of previous blocks. Thus following your
suggesting would probably drastically decease the security of the network
as less work protects previously mined blocks allowing for lower cost to
compute a reorg.


Let us assume the aforementioned point could somehow be resolved there
would be another practical issue. It is hard / impossible to sync clocks in
a distributed network which I think would be necessary for a system that
you propose. (actually Bitcoin is one way of introducing a temporal
ordering of events in a distributed network)

Finally even if that was also resolved: How would you prevent miners to
already compute the simpler difficulty problem directly after the block was
found and publish their solution directly after minute 9? We would always
have many people with a finished / competing solution.

So while I appreciate the idea I have the feeling it would be impractical
but maybe I missed something.

Best Rene

Michael Fuhrmann via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
schrieb am Sa., 15. Mai 2021, 23:57:

> Hello,
>
> Bitcoin should create blocks every 10 minutes in average. So why do
> miners need to mine the 9 minutes after the last block was found? It's
> not necessary.
>
> Problem: How to prevent "pre-mining" in the 9 minutes time window?
>
> Possible ideas for discussion:
>
> - (maybe most difficult) global network timer sending a salted hash time
> code after 9 minutes. this enables validation by nodes.
>
> - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just
> high enough) times higher difficulty. so everyone can mine any time but
> before to 9 minutes are up there will be a too high downside. It is more
> efficient to wait then paying high bills. The bitcoin will get a "puls".
>
>
> I dont think I see all problems behind these ideas but if there is a
> working solution to do so then the energy fud will find it's end. Saving
> energy without loosing rosbustness.
>
>
>
> :)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3217 bytes --]

  reply	other threads:[~2021-05-15 22:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 21:41 [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy Michael Fuhrmann
2021-05-15 22:14 ` René Pickhardt [this message]
2021-05-15 22:19 ` Pavol Rusnak
2021-05-16 15:30 ` Zac Greenwood
2021-05-16 18:10 ` Karl
2021-05-16 20:31   ` Anton Ragin
2021-05-16 22:06     ` Eric Voskuil
2021-05-16 23:29       ` Karl
2021-05-16 21:15   ` Zac Greenwood
2021-05-16 22:05     ` Karl
2021-05-17  9:34       ` Zac Greenwood
2021-05-17  2:58 ` Luke Dashjr
2021-05-17 12:39   ` Anton Ragin
2021-05-18  7:46     ` ZmnSCPxj
2021-05-17 19:17   ` Michael Fuhrmann
2021-05-18  8:04     ` ZmnSCPxj
2021-05-17  5:17 ` yanmaani
2021-05-17 13:14 befreeandopen
2021-05-17 13:53 ` Anton Ragin
2021-05-17 17:28   ` Keagan McClelland
2021-05-17 23:02     ` Anton Ragin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ5H3Z5C_Rjszb1QgGqhJa5F2_ts4CoT=1c0=efBcK8D96Svdw@mail.gmail.com' \
    --to=r.pickhardt@googlemail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=fuhmic@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox