From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 38657C0001 for ; Sat, 15 May 2021 22:14:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 278E2401CD for ; Sat, 15 May 2021 22:14:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQsMddL2oyKU for ; Sat, 15 May 2021 22:14:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by smtp2.osuosl.org (Postfix) with ESMTPS id F1268400E2 for ; Sat, 15 May 2021 22:14:25 +0000 (UTC) Received: by mail-wr1-x42f.google.com with SMTP id r12so2594579wrp.1 for ; Sat, 15 May 2021 15:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+JKkUMzw9rpGPFvFBabvj77Qf2UhSdzuL9nfyUoyc6k=; b=M1hsxgrcRjnEli0i88FtEiKJR0oRlwkGsXlI7/3u2syZ11Gp4t7YuOzoBOHnxti1jK 2NXTnnAwYb3tKzZWY9cRQBbHN2cOH3lBHFqyBKGSQaFQyaBGnFqEUfpNJSdSiViNtPS4 EoJj3Shqlkgw1LIetPWOj1eNCX1kn2YjMGVGDICx5TPRMxjIIUevFOndKGCYCJ2HaVoL UmAx7EyKWqznefJVH21HfshA0afouTi78FqM/iDk1VxLMLTS0WV6KA096TyKXYRtwVbW K6GZuTECVEagZVdRVr/ZS7YU41Looo5lnZ9zcFyk2DQ8XcPrkx+l9kXkkB4wHveK4OoM acew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+JKkUMzw9rpGPFvFBabvj77Qf2UhSdzuL9nfyUoyc6k=; b=kZZiuSP2VtqU/MfCciS2DNivrC959YxZqxpgrpF3vHCsGzVglO8269YDz/WHxeUKJR 4OPZrSt1/QKe9UdyZEwk9lRVdznhLEJNcvUtXOIAGfIyEZxvcUOX1AF7ihvfEhv2kNVj 1j9+FH4Z4n5Vg3QJT0RTV2QYh7ooB0jWFOImUnFpTtwSW/qBVwl8zYocfKK33hlo6Sn7 Vk5td3ByKhDcrnhD0r5BlMRBMJD32J+cjIHFIO+slj4UxlbeKr5BaWwULNrfl1hb8WH/ /epeZN+EQ0xqTFWswUN9lu9/wl2EpdXZHu+PTiOhJsiQ+EkRRuJBhI/oZZuThTy/2iTj 9Igw== X-Gm-Message-State: AOAM530td9B1bnfxPeTod9FrVuH8bz7grEZ6GD7SoUFpWW7gFgIxpT2M beVGxr3Jw1xr3sm1IW8GoXCQ3/E1NzzmLwx9E6U= X-Google-Smtp-Source: ABdhPJzxmYbIh6D4CTVFd5I85CoXwCzlRB/yzvycUF1ymwOwiuVMS1uTXKMj2+autIhAcPnB3WbHjhSV/AYZq/a7SjQ= X-Received: by 2002:a5d:6248:: with SMTP id m8mr66204742wrv.42.1621116864202; Sat, 15 May 2021 15:14:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Ren=C3=A9_Pickhardt?= Date: Sun, 16 May 2021 00:14:13 +0200 Message-ID: To: Michael Fuhrmann , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000d4885c05c265aecd" X-Mailman-Approved-At: Sat, 15 May 2021 22:28:49 +0000 Subject: Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2021 22:14:27 -0000 --000000000000d4885c05c265aecd Content-Type: text/plain; charset="UTF-8" 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 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 > --000000000000d4885c05c265aecd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Michael,

First I think the idea of "do nothing in the first 9 minutes" wi= ll unfortunately not be useful as the computed work is mainly there to prev= ent miners from altering the history of previous blocks. Thus following you= r suggesting would probably drastically decease the security of the network= as less work protects previously mined blocks allowing for lower cost to c= ompute a reorg.=C2=A0

Let us assume the aforementioned point could some= how be resolved there would be another practical issue. It is hard / imposs= ible to sync clocks in a distributed network which I think would be necessa= ry for a system that you propose. (actually Bitcoin is one way of introduci= ng a temporal ordering of events in a distributed network)=C2=A0

Finally even if that was also reso= lved: How would you prevent miners to already compute the simpler difficult= y problem directly after the block was found and publish their solution dir= ectly after minute 9? We would always have many people with a finished / co= mpeting solution.

So whi= le I appreciate the idea I have the feeling it would be impractical but may= be I missed something.

B= est 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<= br> 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. Savin= g
energy without loosing rosbustness.



:)
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000d4885c05c265aecd--