From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5ADECC0177 for ; Tue, 24 Mar 2020 07:43:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 47CD6203DA for ; Tue, 24 Mar 2020 07:43:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjyO5PiR0G+p for ; Tue, 24 Mar 2020 07:43:01 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by silver.osuosl.org (Postfix) with ESMTPS id 3B35C203A7 for ; Tue, 24 Mar 2020 07:43:01 +0000 (UTC) Date: Tue, 24 Mar 2020 07:42:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1585035778; bh=SaHCwkkq5qAt3ykwMUsVL6ZM0N9ceE9BKh9yKj9vDrM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=EC/gvBdzEVMQBnk/Jz3Re6bGU31eqbIw3FHb6u4y6Uw8EcVxMiPT+xtN67IpYykE8 e4fXHILPw/LeVP5qTWApcU4ItSwU7QxdeViMFdr0IyYA/9EaIEX/05N/FLXDSpokfh aYTnKTGE81FERarBwSUe8biTm4yDricOr4eZh6dg= To: Dave Scotese , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <20200323125922.GA29881@canndrew.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Block solving slowdown question/poll 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: Tue, 24 Mar 2020 07:43:03 -0000 Good morning Andrew, > > Hi, noob question here: Is there a long-term plan for if the block rewa= rd drops > > too low to ensure the security of the network? > > > > IIUC miners only make profit from block rewards and transaction fees, a= nd once > > the block reward drop to zero we're merely hoping that transaction fees= will > > keep mining expensive enough to stop a state actor or someone from buyi= ng > > enough hash power to attack the network. If that's the case, should we = start > > making plans now to change the protocol to allow an adjustable block re= ward? > > > > Here's a half-baked idea I had of how that could work: Since the block = reward > > dilutes the value of the currency bitcoin holders have an incentive to = keep the > > reward low. However, since the block reward is also (partly) what incen= tivizes > > mining, bitcoin holders also have an incentive to keep the reward high = enough > > to keep the network secure. So if bitcoin holders were able to vote to = decide > > the block reward they "should", hypothetically, reliably choose a value= that > > balances these two concerns. They already do so, via an implicit "field", known as the transaction fee. This is "implicit" since it is only the difference of the sum of all inputs= with the sum of all outputs, but any Bitcoin HODLer spending their coins a= lways need to make this decision. This makes the vote for how much security is needed to be costly to the vot= er, which is appropriate: you pay for your security. This mechanism is the same mechanism as well that is the long-term plan for= the lowered block rewards in the future, and is already the best known ide= a to tackle this problem as well. Regards, ZmnSCPxj