Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 59689C0001 for ; Sun, 23 May 2021 19:44:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 32F48402C4 for ; Sun, 23 May 2021 19:44:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJPmGM_vX3JS for ; Sun, 23 May 2021 19:44:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by smtp4.osuosl.org (Postfix) with ESMTPS id 190B740337 for ; Sun, 23 May 2021 19:44:21 +0000 (UTC) Received: by mail-lf1-x130.google.com with SMTP id v8so32516000lft.8 for ; Sun, 23 May 2021 12:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7ek2WkluB4p33kYEO9zdIm9Ua3TG6sMo71KPVNJgHFQ=; b=lxiP/IMr2egdqYuZkCqgH+vDP603w9SO7WzT2neSYRj2ln3cSz1rVbPAJhw2LLT/PC Q3ZcXRDtbQ98Lbxty14QqNSKzgEZvIRtDphJzz4UIzxVL0n/OTaBwRfkcouTK//8WMOo iiR1fzSomgl3xxCcqNcTWWuphAS+u7icOIDa6nRZj3bclB4u/CK5zLK2hOFcvveSFrwc zJ3fa1lzHJk2h/I9eXe07VdE1bPqHGihwO3wZREDVpZqqoy1+Q9B+l1opJtI8M5oyjyH Io5rcKzPdOvGFntWKRGZqXmc71xfDGMEvu2AGJlYRllbIymMF/DKt6Hma+5sH4l4IELQ RENw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7ek2WkluB4p33kYEO9zdIm9Ua3TG6sMo71KPVNJgHFQ=; b=SnrxLPybJorn6eWhdObZ0a96khifa+zXJWvaRJsCeWDZXSbwDCuNTrXHuIByxitDbm JfMazjdyaqwzyiHaqd9kYGNZ9Jg/OFf/SpELIqlV/UwpMNuc5A1uvjEFTR+qdmI1a4RJ y0RHfqtNRavJYpGwFRl2HNWrMgxHXkn+TZ47ed1FHt4yZ+kkj5aSUKAF3/ERhqE+uYQM lo2ADlNa/4NRoi1P98dYJF7ISoPwpJ1fGHVNxMf2LdCvIaty2ubRqe+Iji/DJidhIU20 DFnjhlmHsyMgno0epNFcNc8q9gMTnvJBJIJtWsDatBfMXjYwkl2WBxtSmcd6eu+ZGsXY s3Lw== X-Gm-Message-State: AOAM532ZU/9ML+4cZ4XsN09n174m534Oqsuv0AhIEBcCftsJhbmMDRH2 R+3IGD6wzewT2HoliKMbZRPWC67GjJfFaXP5E/U= X-Google-Smtp-Source: ABdhPJxhjRRQMm2DavVbej02UsdqxhDGR7L/BTooyYCcwDaa9khDIEYX4Rf4/rImks+8xXKeeyq+Z7xmYywBB853dkU= X-Received: by 2002:a05:6512:3592:: with SMTP id m18mr9061550lfr.454.1621799059064; Sun, 23 May 2021 12:44:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:651c:2109:0:0:0:0 with HTTP; Sun, 23 May 2021 12:44:18 -0700 (PDT) In-Reply-To: References: From: Karl Date: Sun, 23 May 2021 15:44:18 -0400 Message-ID: To: ZmnSCPxj Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sun, 23 May 2021 19:52:32 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Reducing block reward via soft fork 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: Sun, 23 May 2021 19:44:22 -0000 >> The turn-around time for that takes a population of both users and >> miners to cause. Increasing popularity of bitcoin has a far bigger >> impact here, and it is already raising fees and energy use at an >> established rate. >> >> If it becomes an issue, as bandwidth increases block size could be >> raised to lower fees. >> > > Which increases block rewards somewhat (at least to some level that matches > the overall security of the network) and you still have the same amount of > energy consumed. If you mean to implicitly propose that even if halved all the way with very large blocks, block rewards would just increase to the same level, meaning that any attempt to decrease them has no effect, I disagree. I expect that if you raise the block size, eventually there is so much supply for transactions that there are no fees at all (nor security). The numbers are all things the devs, miners, and users can together control. > How to prove this is not happening? > The best you can do is to have some number of authorities sign off on > whether or not they are doing this. > The problem is that authorities are bribeable. You could make the proof of work be a proof of environmental kindness by coding incentives for people to place and verify proof on the chain, and then rewarding people for acting on it as desired. You could code the chain to pay people to investigate and prove miners' business practices, for example. You could define the main chain as one where everyone consents the proofs are valid. There are a lot of issues to resolve and it would be a very different chain. There is not a single solution here. There are innumerable possible solutions, any one of which could be made to work with enough brains working on it. To use one, we need to agree on what kinds of solutions are acceptable. > Alternately, other entities in the locality can use force to require the > polluting entity to clean up or suffer significant consequences. > This at least is better incentive-wise, as they others in the same locality > are the ones most affected, but the ability to enforce may be difficult due > to various political constructions; the miners could be in such deep cahoots > with the local government that the local government would willingly hurt > other local entities in the vicinity of the polluting entity. As bitcoin grows, if people ask some locality to enforce behavior, they may need to be willing to enforce it themselves, too, or they might outcompete the locality.