MIME-Version: 1.0
In-Reply-To: <CAAt2M1-3R7rY55=QgkP8xUs=SDHxyNQV_fshbi89a9KzcwWfLQ@mail.gmail.com>
References: <CAAt2M1_x8zbN-vmgDEUQQvzrtonEKydb+B-P53ibCimVfnd-CA@mail.gmail.com>
	<CAAt2M1-LZQ1yE1CezFA+hr+=de-RVJ7wzkq-t969BC7OL6dWwg@mail.gmail.com>
	<CAAt2M18Fx9LwKU385id0_gHunLa=uQUmCO+jGkvSqb_2uLeCyg@mail.gmail.com>
	<201703301004.06489.luke@dashjr.org>
	<CAAt2M1-57SMT4WT-4_pdkTPyybQgr2ZuQZW_KW2ZwhTQ7HEnqg@mail.gmail.com>
	<CAAt2M1-3R7rY55=QgkP8xUs=SDHxyNQV_fshbi89a9KzcwWfLQ@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 30 Mar 2017 12:19:33 +0200
Message-ID: <CAAt2M18E5pYRFJtKsNMME9kESQQGwmRpuciWgWVg4y8g=RUamA@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=94eb2c064ed287a5f5054bf00764
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size adjustment idea - expedience fees +
 difficulty scaling proportional to block size (+ fee pool)
Precedence: list

--94eb2c064ed287a5f5054bf00764
Content-Type: text/plain; charset=UTF-8

Den 30 mars 2017 12:04 skrev "Luke Dashjr" <luke@dashjr.org>:


I don't see a purpose to this proposal. Miners always mine as if it's their
*only* chance to get the fee, because if they don't, another miner will. Ie,
after 1 block, the fee effectively drops to 0 already.


I believe that with correctly configured incentives, you can make it more
profitable to delay some transactions with lower fees but still include
them in the next block then to include them all at once. This would smooth
out the inclusion of transactions.

This may require changing the difficulty scaling from using a simple
logarithm to a function that first behaves like a logarithm up to some
multiple of the standard block size, after which difficulty starts
increasing faster and reaches a greater-than-linear ratio in expected
required hash per mined bit. Perhaps tipping over at around a blocksize 3x
the standard blocksize. Since the standard blocksize increases with
continous load after retargeting, the blocksize at which this happens also
increases.

Also, together with the above the fee pool does slightly counteract what
you say, as they'll get a share via the pool when there's less transactions
available the next time they create a block (like insurance).

For a user, what's the incentive to pay an individual miner the fee
directly?

--94eb2c064ed287a5f5054bf00764
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><br><div data-smartmail=3D"gmail_signature" dir=3D"auto">=
<br></div><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_q=
uote">Den 30 mars 2017 12:04 skrev &quot;Luke Dashjr&quot; &lt;<a href=3D"m=
ailto:luke@dashjr.org">luke@dashjr.org</a>&gt;:<br type=3D"attribution"><bl=
ockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div class=3D"quoted-text"><br></div>
I don&#39;t see a purpose to this proposal. Miners always mine as if it&#39=
;s their<br>
*only* chance to get the fee, because if they don&#39;t, another miner will=
. Ie,<br>
after 1 block, the fee effectively drops to 0 already.</blockquote></div></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">I believe that with corre=
ctly configured incentives, you can make it more profitable to delay some t=
ransactions with lower fees but still include them in the next block then t=
o include them all at once. This would smooth out the inclusion of transact=
ions.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">This may req=
uire changing the difficulty scaling from using a simple logarithm to a fun=
ction that first behaves like a logarithm up to some multiple of the standa=
rd block size, after which difficulty starts increasing faster and reaches =
a greater-than-linear ratio in expected required hash per mined bit. Perhap=
s tipping over at around a blocksize 3x the standard blocksize. Since the s=
tandard blocksize increases with continous load after retargeting, the bloc=
ksize at which this happens also increases.=C2=A0</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Also, together with the above the fee pool does s=
lightly counteract what you say, as they&#39;ll get a share via the pool wh=
en there&#39;s less transactions available the next time they create a bloc=
k (like insurance).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">For a user, what&#39;s the incentive to pay an individual miner the fee d=
irectly?=C2=A0</div><div class=3D"gmail_extra" dir=3D"auto"></div></div>

--94eb2c064ed287a5f5054bf00764--