Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DC71FDB8 for ; Mon, 17 Sep 2018 15:40:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30CF6102 for ; Mon, 17 Sep 2018 15:40:32 +0000 (UTC) Received: by mail-pl1-f194.google.com with SMTP id f6-v6so7615778plo.1 for ; Mon, 17 Sep 2018 08:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DLghNHwWbcFQyp9cq/TleNuxQFR3jEg60VmiRgIi33c=; b=MWfiecFSJvtxfFO2AtA0O52evGjSkqEfzwrg7yx+TCy+ejEcoFW+t7HkTN8nmUw5La WrmPNtqvDRBzjbN9M9EDk0vLsEmoNOKyFe5yJawxu/AJQ0AYCcLfWQNj8feyk3r8K8T1 bb+Q7LDdomckxA5SAhDTOo67JMOisJ0XYPAdHt2cZXciepylwCpoTzrigPg6L6Eow1An eqlXGHQ51C382DZiJl46IfnAt3o6wQmyf68pBEt4eWEqEwhj4wNHi9O0diOPctU+v3et JbPBstkwnt4ixdYUjb1BEpDWd4rUSPRWDa3p09B2m5aXAvPIPVyX5miwP3nLoGlK2SZv oLFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DLghNHwWbcFQyp9cq/TleNuxQFR3jEg60VmiRgIi33c=; b=Q97UI+EE0TUVbXOCQ7wnUHgJvNSuppr6Eo6fq/37ZFd0mRcD9zIG0Z3OepnBIzwx0H m6nPNjykFigLzz+mHHuza4/4bKrhJWHd6c6rU2jT4jg3AuMishB3tEK88YZjdZ6n93io b5OHrzBirG88o7cQpPLIjnG5CytJvUeBO4rrTdSCB8KntZ27TYvwhT2UY2IZj3GsbgeR Ml5nY2avOmQ6ubi2Ua2dPmulQpX/O441+CPt/KjpL02Y1CU3r/L5dBRyJOJQUaV8ArR3 0g/Vq3VAI4IU/FnLqPXwuDWKcr7Lg4RqFMS+lW3StdBThjewjDV0tZfIAnVKnVj6jry7 m4Dw== X-Gm-Message-State: APzg51C5oQyMHq0PgiE7AvzGFOJBij5MRA5DbEFgHLURW2D+ve+aTUE0 ti/OOgiYPvZiO/CxdDzbL4zQOw== X-Google-Smtp-Source: ANB0Vdb52jvX+0mPtAVqURdgzs6FH2nbD9X045+uBJQ2Z1sScvOkDYamcC3mGQ7GMnKwBLOhf+Zj0A== X-Received: by 2002:a17:902:6501:: with SMTP id b1-v6mr25683056plk.31.1537198831623; Mon, 17 Sep 2018 08:40:31 -0700 (PDT) Received: from ?IPv6:2601:600:a080:16bb:107:5da0:8d4:886e? ([2601:600:a080:16bb:107:5da0:8d4:886e]) by smtp.gmail.com with ESMTPSA id g7-v6sm20361970pfi.175.2018.09.17.08.40.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Sep 2018 08:40:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-91325BF3-CD92-46DC-87B1-1970AE8AA93C Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Mon, 17 Sep 2018 08:40:30 -0700 Content-Transfer-Encoding: 7bit Message-Id: <978F6B0E-C5E4-42FA-B91C-49903A37652B@voskuil.org> References: To: Andrew X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE, 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: Tue, 18 Sep 2018 04:32:04 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Selfish Mining Prevention 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, 17 Sep 2018 15:40:33 -0000 --Apple-Mail-91325BF3-CD92-46DC-87B1-1970AE8AA93C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > Also with merge mining and proof of space we can be quite efficient in the= future. Proof of memory (space) is just proof of work with extra steps. It does not r= educe energy consumption. https://github.com/libbitcoin/libbitcoin/wiki/Proof-of-Memory-Facade Merge mining is non-dedicated cost, so also does not improve energy efficien= cy. The irreducible *cost* is what matters. https://github.com/libbitcoin/libbitcoin/wiki/Dedicated-Cost-Principle e On Sep 17, 2018, at 06:18, Andrew wrote: >> I see what you say, however, since the proposal as I have read it says "A= nd this will keep happening as long as hashrate keeps rising," - what actual= ly happens in the case hashrate stagnates or falls? >=20 > In general, a target hashrate can be set by users (can be less or more > than the peak hashrate). As long as hashrate is rising and still > didn't reach the target, miners will incrementally get the reserve > fees. Once the "contract" times out, the remaining part can be used as > fees by the users who created the reserve fee "contract". So if > hashrate remains the same or falls, then users get the reserve fees > back. >=20 > I agree that we can't stop people from being greedy. If they are not > Bitcoin mining, they will try to put their energy to earn in some > other way...The hashrate is related the demand for Bitcoin (price) and > the amount of fees/subsidies the miners will get paid. For every level > of mining rewards (based on demand) there exists a limit on the > hashrate. Once hashrate gets large enough, no new miners (additional > hashrate) will want to join since their share of the hashrate is too > small to make a profit. >=20 > Also with merge mining and proof of space we can be quite efficient in > the future. But of course I sympathize with the "don't be greedy" > philosophy, and it can be good to educate people to use less resources > than they need, just I think it's a bit outside of the scope of what > the Bitcoin software protocol does. --Apple-Mail-91325BF3-CD92-46DC-87B1-1970AE8AA93C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
> Also with merge mining and proof of spac= e we can be quite efficient in the future.

Proof of memory (space) i= s just proof of work with extra steps. It does not reduce energy consumption= .


Merge mining is non-dedicated cost, s= o also does not improve energy efficiency. The irreducible *cost* is what ma= tters.


e
<= br>On Sep 17, 2018, at 06:18, Andrew <onelineproof@gmail.com> wrote:

I see what you say, however, sin= ce the proposal as I have read it says "And this will keep happening as long= as hashrate keeps rising," - what actually happens in the case hashrate sta= gnates or falls?

In general, a= target hashrate can be set by users (can be less or more
th= an the peak hashrate). As long as hashrate is rising and still
didn't reach the target, miners will incrementally get the reserve=
fees. Once the "contract" times out, the remaining part can be use= d as
fees by the users who created the reserve fee "contract= ". So if
hashrate remains the same or falls, then users get t= he reserve fees
back.

I agr= ee that we can't stop people from being greedy. If they are not
Bitcoin mining, they will try to put their energy to earn in some=
other way...The hashrate is related the demand for Bitcoin (price)= and
the amount of fees/subsidies the miners will get paid. = For every level
of mining rewards (based on demand) there ex= ists a limit on the
hashrate. Once hashrate gets large enoug= h, no new miners (additional
hashrate) will want to join sin= ce their share of the hashrate is too
small to make a profit= .

Also with merge mining and proof of space= we can be quite efficient in
the future. But of course I sy= mpathize with the "don't be greedy"
philosophy, and it can b= e good to educate people to use less resources
than they nee= d, just I think it's a bit outside of the scope of what
the B= itcoin software protocol does.
= --Apple-Mail-91325BF3-CD92-46DC-87B1-1970AE8AA93C--