Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 86C04C66 for ; Wed, 2 Mar 2016 20:44:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 573E915E for ; Wed, 2 Mar 2016 20:44:04 +0000 (UTC) Received: by mail-pf0-f175.google.com with SMTP id 63so441610pfe.3 for ; Wed, 02 Mar 2016 12:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to; bh=rbdAjV1FVLwYlJItD09ez37AfbSgP+bmr2NalXsD0Fg=; b=eIadYu/0fw3ddKIYAlh/B8tHTcToO0CxrB958rZHyjF/4rd0ZPSzU1HiXr+6w3XSrC QVfhSbKh5MOoP7NeqkNOLma1KdIzZgfJTEe3sF0UjjoX5KDszWFyM/tiSjX4znzj3kf/ wnNf9i3CRegap0IRLCD7Sq/JlTc2YlkfurXrmftQCHdMf486yoZr5Uza676AOo5najqa 3s2XHJaVzqKsr90Nymx3mKJzjYL3zWFiCzrlSnxiiiZP+DHMp+ghjSGQK9H3XW+Eu/Yh 9jEeMBQW6vdMzdidY2H9zEMWXg5vacyuXWo+SX0ZzSwoxy7reFoAjFxiHVw9Uwox8Zio H1NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to; bh=rbdAjV1FVLwYlJItD09ez37AfbSgP+bmr2NalXsD0Fg=; b=V8Fp8tJOAZFQ7XaYRZgPaYWwmrZGASjuvALzepTb9a/k/JnKRnGU2EH8ekSC8lrWaW cBOYzAKSewQ6OzKp40up3UPbEUHue+Zpahjo+PeKsrvwx8dcJe50UyhIwTmfJiAfSath pBAG18PkZs1gpMfIP+qvsTsKipiPzP7dekgt8STR1gw4jI1a+ybkags//FrXT0YjuNiN m7Sns+sDu+oGT45acHf5ixVupXC6CgIjcmhlxOSgiPKaMSavyumejK4rsX9kjXCHGGmS 9xwm3Lm/FxzGACjcGj/m5lnn3jISmyphjp6UJGKMQDT3n3zSpGcy5nwEJ7uins9x36ru oyMA== X-Gm-Message-State: AD7BkJK077k1ytfPlagm+dntZKuaSwihgMePG+4pT7MYaMxySZHDMgkXzSPxiM9e6fHJmQ== X-Received: by 10.98.14.156 with SMTP id 28mr32622670pfo.1.1456951444002; Wed, 02 Mar 2016 12:44:04 -0800 (PST) Received: from ?IPv6:2601:600:9001:8060:bd51:62fa:f57b:462a? ([2601:600:9001:8060:bd51:62fa:f57b:462a]) by smtp.googlemail.com with ESMTPSA id o7sm14799275pfa.37.2016.03.02.12.44.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2016 12:44:03 -0800 (PST) Message-ID: <56D75097.2070609@voskuil.org> Date: Wed, 02 Mar 2016 12:44:07 -0800 From: Eric Voskuil User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Paul Sztorc , bitcoin-dev@lists.linuxfoundation.org References: <201603021456.15820.luke@dashjr.org> <201603021542.29609.luke@dashjr.org> <56D71488.4080607@gmail.com> <00e101d174b5$f2659060$d730b120$@voskuil.org> <56D74859.3090609@gmail.com> In-Reply-To: <56D74859.3090609@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Hh6F2ALjiahjEbG6vTlpbo612b9700OO4" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW 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: Wed, 02 Mar 2016 21:39:22 +0000 Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 20:44:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Hh6F2ALjiahjEbG6vTlpbo612b9700OO4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/02/2016 12:08 PM, Paul Sztorc wrote: > On 3/2/2016 2:01 PM, Eric Voskuil via bitcoin-dev wrote: >>> A 6 month investment with 3 months on the high subsidy and 3 months o= n >> low subsidy would not be made=85 >> >> Yes, this is the essential point. All capital investments are made bas= ed >> on expectations of future returns. To the extent that futures are >> perfectly knowable, they can be perfectly factored in. This is why >> inflation in Bitcoin is not a tax, it=92s a cost. These step functions= are >> made continuous by their predictability, removing that predictability >> will make them -- unpredictable. >=20 > The Ministry of Truth is taking job applications in the doublespeak > department... Not sure how you interpret a tautology as doublespeak. >> Changing these futures punishes those who have planned properly and >> favors those who have not. Sort of like a Bitcoin bail-in; are some >> miners are too big to fail? It also creates the expectation that it ma= y >> happen again. This infects the money with the sort of uncertainty that= >> Bitcoin is designed to prevent. >=20 > Coinbase-smoothing can be done via soft fork (soft forks typically only= > move "one way" toward stability). I'm addressing the hard fork proposal (see subject line). > Moreover, the effect *costs* miners, > it does not benefit them. Finally, it can be done so that the economic > impact on miners is minimized. Changes to consensus rules change the value of coins, which are property of their owners. Nobody owes a miner a promise of consistent revenue for future work. Cost or benefit to miners is relevant only to the extent that those who hold money believe it will affect their value and therefore consider it in their decision to consent. > You'll just have to weigh the risks -- some vague, tiny effect on > expectations today, vs the need for a small group of experts to > emergency hard fork once every four years. How is the small group of experts today different from the small group of experts tomorrow? > I'm sure those experts are completely reliable, and won't get threatene= d > or assassinated! This is precisely the issue. The precedent of hard-forking to "fix" the money is a precedent for establishing authority over the money. >> A 6 month investment with 3 months on the high subsidy and 3 months on= >> low subsidy would not be made if it only generated a small profit for >> the first 3 and then massive losses for the 2nd period of 3 months. F= or >> it to be made, there needs to be large profit during the first period = to >> compensate for the losses in the 2nd period. >=20 > The word "loss" is of utmost importance here...if they are operational > losses, it should be obvious to everyone that the best "compensation fo= r > losses in the 2nd period" is to just shut them off (thus reducing losse= s > to zero). But of course the losses would not be entirely operational, since hardware (at a minimum) does not depreciate to zero because of a halving. The ability to plan does not change this fact. There are certainly similar considerations for labor, bandwidth, space and even electrical/cooling costs (contracts). To the extent that these costs are sunk (as Tier said) *any* earnings are better than none. > So you must be arguing that miners have made an investment 3 months > prior, knowing that it would pay for itself despite the reward halving.= Of course, how could they not? > That's nice, but it ignores the fact that, if that investment is made > everyone, by all miners, the *difficulty* will have increased 2 weeks > afterward...such that operating profits are tending *immediately* towar= d > zero, and will be zero by the time the first set of 3 months is over. =2E.. which also ignores fees. e --Hh6F2ALjiahjEbG6vTlpbo612b9700OO4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJW11CXAAoJEDzYwH8LXOFOyZAH/iLkbNrD5qgEerXmoPAI2QkE WK6sEUvl/9/vpgHqCK1llhkM8hZqc5eMbCPr3xWPzOfdBW/FamTGm+92mTr0jEvJ kLpqbQ+RP3LEPLTT5buTRPSBrScEfiDfEwwyR+UkhqTOQXSobHNtvlpTghs6eH2N i8fePMsq8guhcFZLa/jQdzauribj/EeAF6ayPE80n296rrUHtKzo/078dVCPztCz 1vFPhJlzTGhwnZkpxVmeYGh+nSQ0baDbGkda1IHkpDTl1n5tmK1FtCNyMF9lWTKw MwR0cLO5mSLe6ZUdld9dVP94uhRFQnXP3ljgiUOpobNZcWpeDx5w66GpBOW8kWA= =nwxX -----END PGP SIGNATURE----- --Hh6F2ALjiahjEbG6vTlpbo612b9700OO4--