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 89A96B0B for ; Fri, 31 Mar 2017 04:15:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0EB7DFC for ; Fri, 31 Mar 2017 04:15:18 +0000 (UTC) Received: by mail-yw0-f171.google.com with SMTP id i203so33466570ywc.3 for ; Thu, 30 Mar 2017 21:15:18 -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=kxGf0DTI6M408Trbh6l8oEyOt6GYS0NBdNWtWpf4rLk=; b=lrTd1p1avzVLDLNa44U/bKdGRBqhpVFvqswwWgzXLXFm2cZVWeLQrbzfIpBthY+lwU X+jn0fCSUEIrBckT0PJJ8L7sfOyIEdBg+SrFV1Bdcr8TQYhsCp0YAPKdiAZqPqMHGvrJ LpB6w5IZ+YtP/tcyemzxeHWZx1+/Dq9p6b4sqCCbvrlQL5yNPfdcj/Hs1CAMRl0sQyQe 2Bi1uRf246lxw7Xi27y9fu60PXq59bbpX8dP5nMdIhDG/oVINAvpfCZkdEct9tVGLDzA a7SuNJqUOIWY7YkiWo0Yb6mvGUfkoYaec8h9WdQ3HjLGPfxFaAFRstYkeQkgof6ML7ey gtmA== 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=kxGf0DTI6M408Trbh6l8oEyOt6GYS0NBdNWtWpf4rLk=; b=jD7bJaYZl6xVxwTm04q3HZOgxHi3RDF4QhAuKKzrZaLhx55FsJMin1EC/jHEWkvzno tDIhTaP8fQQAIrwZZZzjJiWW4lCJ1KV3mCTP1MiWQluqlI+jLni+PRjFpgkKBhfh06sY HV6ddYRkvP9Rm/gdO37Zj8xlC1qU9WzHhmiXWNxQM4CdTEhOBykGcA9TCyiK18TAnN6f l4bv+HfLukiJiohCEmPsjyPQftm84OU8VpogE6hwTeeHDLWHd/2uJHpXS+qyCGlHtiYp ZnvJsM1vss8QVqM+kgvGQEkbGQ/X8XoufbP3Iezx2rncdZCJt3wghMxkESQe9nH1WM5g vIKA== X-Gm-Message-State: AFeK/H1qmCidWNlMqqe8Uy42GUFgfqXWZ6HdiI/Y2sz0TJs/z+hm69HkxpKxeLiNfztHDiJjxarTEIL1dfmg6A== X-Received: by 10.13.221.19 with SMTP id g19mr597998ywe.21.1490933718010; Thu, 30 Mar 2017 21:15:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.123.135 with HTTP; Thu, 30 Mar 2017 21:15:17 -0700 (PDT) Received: by 10.37.123.135 with HTTP; Thu, 30 Mar 2017 21:15:17 -0700 (PDT) In-Reply-To: References: From: Natanael Date: Fri, 31 Mar 2017 06:15:17 +0200 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=94eb2c064ed2a582d9054bff0e45 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: Fri, 31 Mar 2017 04:15:19 -0000 --94eb2c064ed2a582d9054bff0e45 Content-Type: text/plain; charset=UTF-8 Sorry for sending a double, hit the wrong button... Den 31 mars 2017 06:14 skrev "Natanael" : > > > 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. > --94eb2c064ed2a582d9054bff0e45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for sending a double, hit the wrong button...=C2=A0=

Den 31 mars= 2017 06:14 skrev "Natanael" <natanael.l@gmail.com>:


Den 30= mars 2017 11:34 skrev "Natanael" <natanael.l@gmail.com>:
=
Block size dependent difficulty scaling= . Hardfork required.=C2=A0

Larger blocks means greater difficulty - but it doesn't scale linear= ly, rather a little less than linearly. That means miners can take a penalt= y in difficulty to claim a greater number of high fee transactions in the s= ame 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).=C2=A0

This ca= n 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 subsi= dy until it approximately reaches parity with average total fees.=C2=A0

We don't need to alter = difficulty calculation.
Instead we alter the percent= age of the fees that the miner gets to claim VS what he have to donate to t= he pool based on the size of the block he generated.=C2=A0
Larger block =3D smaller percentage of fees. This is another way to = pay for blocksize. The effect of this is that on average, miners that gener= ate smaller blocks takes a share of what otherwise would be part of the min= ing profits of those generating larger blocks.=C2=A0

We would need to keep pieces of the section fr= om above on expected blocksize calculation. Because the closer you are to t= he expected blocksize, the more you keep. And thus we need to adjust it acc= ording to usage.=C2=A0
<= /div>
--94eb2c064ed2a582d9054bff0e45--