From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5AA48A88 for ; Thu, 30 Mar 2017 18:41:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.161.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 706D1227 for ; Thu, 30 Mar 2017 18:41:21 +0000 (UTC) Received: by mail-yw0-f173.google.com with SMTP id i203so28614562ywc.3 for ; Thu, 30 Mar 2017 11:41:21 -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; bh=8ZN657SfZ0j7Eri04cbJXN6Pc7cGShlAeow4AQcvjsI=; b=OmiqGGLYNH+vgnyyeFOItJkc5+IIhrrzCpJMx1Uc2QwVSKvPDL1+fFmjHnLDWFAJ/e syYtcLLcbY2VXwzitM7dwD0DY85WBZkWmRMcfohn8lEblZbf9P8sHKKgLmIaIs8+QDhh ujx5HfDvGc129K8hzB2VZdcov2lnbwYxPnZ2D/x1clw/nhoBUsXdez0WX4LpbNRNFJfN 0TCC+OLCZiNt+aeZ4E63j4bmqZaY96eppsU4kq4vWsmVkmJ98euTfZa/vifJaRB0Ks1C BlgMK+9jdegfdsNjTx8nDBispn9uPJqJGuA2B1BbnbElc6Lb3Dx5BkKR6Okm8T6HZb+U +ypQ== 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; bh=8ZN657SfZ0j7Eri04cbJXN6Pc7cGShlAeow4AQcvjsI=; b=do6cx1wW97NucwjqifyQg5WJA9IYPRYpfMzsi7DRaJJyvWgWA3XKp0vXcw8r224i1X glzLAR+rUnYeUWxCpUCK4KkhkOOB2h3D3xDJSqBL6ww+PHo8SzgtiL6j2VRY88kfHGpF jusmSGZTVXQz7eVprhlTkmF8aAMPBlNJbI2B9dw/IkzlUV9HF0cErTzccN+++jhj90YR 2RTgwXWnEEZMA2Psd1Q/R90TL2hmF843dpmSSnLkNj9BAAm2yheUj2ZWAotSyC0/xB6G c9MIiP0FZ9x5kzFYi4L3ULj1v6YUGjUwANd89P5pHWV6mrS5L4L+li4GrCHIkchNNFnX PCCw== X-Gm-Message-State: AFeK/H17uct3Pdmux8Yrgq1c+bUBBU5rNB5VQwipIpKluaO5ZSUrx38wnwu6MApmzYxKR2b9sE+jpz5KDnfXUQ== X-Received: by 10.129.55.129 with SMTP id e123mr934368ywa.251.1490899280414; Thu, 30 Mar 2017 11:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.123.135 with HTTP; Thu, 30 Mar 2017 11:41:19 -0700 (PDT) Received: by 10.37.123.135 with HTTP; Thu, 30 Mar 2017 11:41:19 -0700 (PDT) In-Reply-To: References: From: Natanael Date: Thu, 30 Mar 2017 20:41:19 +0200 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1149d3d8015628054bf70ab2 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) 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: Thu, 30 Mar 2017 18:41:23 -0000 --001a1149d3d8015628054bf70ab2 Content-Type: text/plain; charset=UTF-8 Den 30 mars 2017 11:34 skrev "Natanael" : Block size dependent difficulty scaling. Hardfork required. Larger blocks means greater difficulty - but it doesn't scale linearly, rather a little less than linearly. That means miners can take a penalty in difficulty to claim a greater number of high fee transactions in the same amount of time (effectively increasing "block size bitrate"), increasing their profits. When such profitable fees aren't available, they have to reduce block size. In other words, the users literally pay miners to increase block size (or don't pay, which reduces it). This can be simplified if we do get a fee pool (less hardfork code, more softfork code), except that the effect will be partially reduced by the mining subsidy until it approximately reaches parity with average total fees. We don't need to alter difficulty calculation. Instead we alter the percentage of the fees that the miner gets to claim VS what he have to donate to the pool based on the size of the block he generated. Larger block = smaller percentage of fees. This is another way to pay for blocksize. The effect of this is that on average, miners that generate smaller blocks takes a share of what otherwise would be part of the mining profits of those generating larger blocks. We would need to keep pieces of the section from above on expected blocksize calculation. Because the closer you are to the expected blocksize, the more you keep. And thus we need to adjust it according to usage. --001a1149d3d8015628054bf70ab2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=

Den 30 mars 2017 11:34 skrev "Natanael" <natanael.l@gmail.com>:
Block size depend= ent difficulty scaling. Hardfork required.=C2=A0
Larger blocks means greater difficulty - but it do= esn't scale linearly, rather a little less than linearly. That means mi= ners can take a penalty in difficulty to claim a greater number of high fee= transactions in the same amount of time (effectively increasing "bloc= k size bitrate"), increasing their profits. When such profitable fees = aren't available, they have to reduce block size.

In other words, the users literally pay miner= s to increase block size (or don't pay, which reduces it).=C2=A0
<= /div>

This can be simplified if we do get a fee pool (less hardfork code, = more softfork code), except that the effect will be partially reduced by th= e mining subsidy until it approximately reaches parity with average total f= ees.=C2=A0

We don't = need to alter difficulty calculation.
Instead we alt= er the percentage of the fees that the miner gets to claim VS what he have = to donate to the pool based on the size of the block he generated.=C2=A0
Larger block =3D smaller percentage of fees. This is a= nother way to pay for blocksize. The effect of this is that on average, min= ers that generate smaller blocks takes a share of what otherwise would be p= art of the mining profits of those generating larger blocks.=C2=A0

We would need to keep pieces of = the section from above on expected blocksize calculation. Because the close= r you are to the expected blocksize, the more you keep. And thus we need to= adjust it according to usage.=C2=A0
--001a1149d3d8015628054bf70ab2--