Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 69635409 for ; Fri, 14 Aug 2015 22:12:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC593E2 for ; Fri, 14 Aug 2015 22:12:54 +0000 (UTC) Received: by pdbfa8 with SMTP id fa8so35114444pdb.1 for ; Fri, 14 Aug 2015 15:12:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=+Rzjzvnv9ZIVsmEgLZbngbsQuXzC6gZvjf+8oAYHq6Q=; b=A+ul7XHUOzrl15VlDmUYJu1foKW1+dPzMdl3uoq7fFgwWNq4sKn/TpiVxaBC+pxim8 zcp+m2gA81WsqRdk9XM2w//ogbfAkcH9tdhlrhn2kf+jYJHuEQ8TJC0RH7p7xvXiDGQi ME5aQetpwKBBqiFvNMviEGcj5sphAtkeqn8dPuf/HuUaIUcJ3NYJTROolLCjvKLTfQGN pLJ9blCLnEoZdnV/9pAgxOvF+7v9lEmC42UeLANNCAyGRO2RQSfvZZwR75Ek/VmNTMcN p9VZm2qiiiFidHLDayb8yS90R+y/eWnI9NotEax7bMmpJJDXoIGNojaYTxnm8LW/4s8V 63zw== X-Gm-Message-State: ALoCoQl3XqmA1DDjIoTQ4fV0a4/+FG7tEQpH9Pl01u07gFWEsfiLSgQqPhr2yaKsBFChwQYevT7b X-Received: by 10.70.90.161 with SMTP id bx1mr92444860pdb.10.1439590374497; Fri, 14 Aug 2015 15:12:54 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by smtp.googlemail.com with ESMTPSA id hh3sm7112164pbc.8.2015.08.14.15.12.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Aug 2015 15:12:53 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com> <116B26BD-D8E8-4AFD-A619-2EAC348DA5E6@me.com> From: Tom Harding X-Enigmail-Draft-Status: N1110 Message-ID: <55CE67E6.3020905@thinlink.com> Date: Fri, 14 Aug 2015 15:12:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Subject: Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize 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: Fri, 14 Aug 2015 22:12:55 -0000 Nobody mentioned exchange rates. Those matter to miners too. Does it make sense for George Soros and every other rich person / institution to have the power to move difficulty, even pin it to min or max, just by buying or selling piles of BTC to swing the exchange rate? On 8/14/2015 8:03 AM, Adam Back via bitcoin-dev wrote: > There is a proposal that relates to this, see the flexcap proposal by > Greg Maxwell & Mark Friedenbach, it was discussed on the list back in > May: > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html > > and http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.html > > Adam > > On 14 August 2015 at 15:48, Jakob Rönnbäck > wrote: >> 14 aug 2015 kl. 16:20 skrev Anthony Towns : >> >> On 14 August 2015 at 11:59, Jakob Rönnbäck >> wrote: >>> What if one were to adjust the difficulty (for individual blocks) >>> depending on the relative size to the average block size of the previous >>> difficulty period? (I apologize if i’m not using the correct terms, I’m not >>> a real programmer, and I’ve only recently started to subscribe to the >>> mailing list) >> >> That would mean that as usage grew, blocksize could increase, but >> confirmation times would also increase (though presumably less than >> linearly). That seems like a loss? >> >> >> Would that really be the case though? If it takes 5% to find a block, but it >> contains 5% more transactions would that not mean it’s the same? That would >> argue against the change if not for the fact that the blocks will be bigger >> for the next difficulty period. >> >> If you also let the increase in confirmation time (due to miners finding >> harder blocks rather than a reduction in hashpower) then get reflected back >> as decreased difficulty, it'd probably be simpler to just dynamically adjust >> the max blocksize wouldn't it? >> >> >> I guess that could make the difficulty fluctuate a bit depending on the >> amount of transactions and the fees being paid. Would it really matter in >> the long run though? Since it’s the same amount of miners, doesn’t that just >> mean it’s just the number that is lower, not the actual investment needed to >> mine the blocks? Not sure if this would open up some forms of attacks on the >> system for someone willing to lose money though… >> >> >> Very good feedback though, thanks a lot :) >> >> /jakob >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev