1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 918D5B5F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 10:19:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com
[209.85.161.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 091B0D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 10:19:34 +0000 (UTC)
Received: by mail-yw0-f176.google.com with SMTP id v76so21957266ywg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 03:19:34 -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
:cc; bh=tCF7vxnCsa7xEjjq60D2HZ3y8ig2+qlu7TNPDA6EMvE=;
b=EnGX5Vl1w4tDxbdOmVspnSjNYTXTuT6JlE0WQqIm7lyR86u/CsZX5QA0urQK0qA7pR
0XCiie2ohsillbg38p+57n5UmNSWfD+oZ8TkcHRVA0bUU40RVo0Wy0monZZ8ZsLfRINC
GMhx+LCt5UgkEl85dhWg2ZfsTxbMQLkKM03aBKH+3XlSB8vvMeGPXYEt0F4o1WJ8Fph0
YiRhGlnTlFLh105HJEQCqK4bYTGKwz5RL+tzjBfpSsQWVTbR/wZga+h+Rdq8HiH6HCvx
VfNo1FjvfHmw1cA/wSbp/HVn+gwPDqLnq6VtWf+oUXI6wNejcx8ZF46d82W+yfzIM3be
rmMQ==
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:cc;
bh=tCF7vxnCsa7xEjjq60D2HZ3y8ig2+qlu7TNPDA6EMvE=;
b=ZLiIvn2eVfC6RW/5zzZBtOY66N5s0yYUgdz6JJdN9S3XYqC+v1o40WETV83gJB/sGV
FGRgBSJ1QPe/M6aiqlmJiphGZACEixsET2cfTPlgOCxmiQmx+QwP9XoKKjXi494je0hX
bMiEWRXOQrVNa2c29hDQvNJO8uCcHsr/TQpgb0TtgmMkjGcckcG6J2F+iV8LWGNxUiy4
/Pg67UlgdT5itPlzFODTTIaq0tQuhkMw+f++lXWkQcxeTUYAgKmEktehpK8nzh3ZrwgL
cNZxNgGFr8Y+fQrxUu2/s6H3+qejQM/bvYWldHJPpdikRsIqf5ukmjUUqnb3jnaNBpfD
MmFg==
X-Gm-Message-State: AFeK/H1wVjrPEw7jBlKqApL++BbrsJecmeAXr0DeeQXjYvvhwv0rFzUWKOdW8lJSXkwyVtpAlCOf9hXrHDcIEA==
X-Received: by 10.13.221.19 with SMTP id g19mr1597854ywe.21.1490869174114;
Thu, 30 Mar 2017 03:19:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.123.135 with HTTP; Thu, 30 Mar 2017 03:19:33 -0700 (PDT)
Received: by 10.37.123.135 with HTTP; Thu, 30 Mar 2017 03:19:33 -0700 (PDT)
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
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
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)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 10:19:35 -0000
--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 "Luke Dashjr" <<a href=3D"m=
ailto:luke@dashjr.org">luke@dashjr.org</a>>:<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't see a purpose to this proposal. Miners always mine as if it'=
;s their<br>
*only* chance to get the fee, because if they don'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'll get a share via the pool wh=
en there'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'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--
|
