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
|
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 588A2F42
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 18:29:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com
[209.85.212.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8B9E6203
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 18:29:13 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so7874978wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 03 Sep 2015 11:29:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type:content-transfer-encoding;
bh=eTmkc9jRTUvL3UF6uAP2i+sxyNZ33n9f0ooFZX5Z03w=;
b=ihQqhKAQVMzO/qG9QN8H4ZY6TzdLE9/mq7kmKFP7gejryTvWCMRWvc4iltO43LDyWM
hO+5z+M0qiMzJTEzAz9rJCi91zTgy9xTzwIsBQ+tXyGocDNqWnMsRjlKXP5RQGJGoHzf
PwJ3lKZ8BSBYeBz9uzOo/EvK9k+ACEa5y0o9bzoCY/ggJWNxbgjWd9Q2WM38SA/4styZ
5Tz7cpJEu6BcsjNb6UbCL7nyfbl8UR6zOHrzvJuwZEW8AnYEzXLQLW8AQU2JYG8PJW3j
thTsR3cFRhtHkKwHU2+cKJ8wIfccavhrdpP7ZPL0F2Bx0QZ+vL2SOMDeQyy7/26ZnAsA
gxEg==
X-Received: by 10.194.121.131 with SMTP id lk3mr51642578wjb.77.1441304952075;
Thu, 03 Sep 2015 11:29:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.211.16 with HTTP; Thu, 3 Sep 2015 11:28:52 -0700 (PDT)
In-Reply-To: <CABm2gDof7evMp0HM1m1NdBPkR02kAcWp9Y3U=T1AvJxLCgNz6Q@mail.gmail.com>
References: <CADm_Wcb+5Xo3HS-FNUYtCapVpYfVvUS_fxpU0Q=TZHJW1=iAFQ@mail.gmail.com>
<CAAS2fgQOi0amBnPK8Ac3iGDN9CP-mLW6o0ncYdSAOAaqSboejg@mail.gmail.com>
<CADm_WcYS-zbNFQJ5EPqqkQ5NhgoQNQAgs-SaF_ZZr0QCNFA3_w@mail.gmail.com>
<CADm_WcYwErO1Av_DkMecATQEMFKL7TNZc1Nbs88k-yEKN2vbsQ@mail.gmail.com>
<CAAS2fgS=sBYscxa+xzi6d2h61HxgeRfdaTj55ospc3oKYgKOXg@mail.gmail.com>
<CABm2gDof7evMp0HM1m1NdBPkR02kAcWp9Y3U=T1AvJxLCgNz6Q@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Thu, 3 Sep 2015 19:28:52 +0100
Message-ID: <CADJgMzuHJ=sf_ztmaEimN=p=tr-YCkSVa=NvbeqS_mUG34E-vA@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
HK_RANDOM_FROM, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] block size - pay with difficulty
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 03 Sep 2015 18:29:14 -0000
Maybe Jeff can clarify but my communications with him seemed to imply
he didn't think any kind of difficulty penalty scheme is workable. I
strongly dispute that assertion.
On Thu, Sep 3, 2015 at 7:23 PM, Jorge Tim=C3=B3n
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Greg, I believe Jeff is focusing on BtcDrak's proposal (
> https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the
> increased nBits are used to vote for the block size to raise
> permanently ( or until it gets voted down).
> His arguments don't seem to apply to your original proposal (where the
> size is only increased for that block).
>
>
> On Thu, Sep 3, 2015 at 7:57 PM, Gregory Maxwell via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik <jgarzik@gmail.com> wrote:
>>> Expanding on pay-with-diff and volatility (closing comment),
>>>
>>> Users and miners will have significant difficulty creating and/or predi=
cting
>>> a stable block size (and fee environment) with pay-with-diff across the
>>> months. The ability of businesses to plan is low. Chaos and
>>> unpredictability are bad in general for markets and systems. Thus the
>>> binary conclusion of "not get used" or "volatility"
>>
>> Sorry, I'm still not following. I agree that predictability is importan=
t.
>>
>> I don't follow where unpredictability is coming from here. Most (all?)
>> of the difficulty based adjustments had small limits on the difficulty
>> change that wouldn't have substantially changed the interblock times
>> relative to orphaning.
>>
>>> It's written as 'a' and/or 'b'. If you don't have idle hashpower, then=
paying with difficulty requires some amount of collusion ('a')
>>> Any miner paying with a higher difficulty either needs idle hashpower, =
or self-increase their own difficulty at the possible opportunity cost of l=
osing an entire block's income to another miner who doesn't care about chan=
ging the block size. The potential loss does not economically compensate f=
or size increase gains in most cases, when you consider the variability of =
blocks (they come in bursts and pauses) and the fee income that would be as=
sociated
>>
>> What the schemes propose is blocksize that increases fast with
>> difficulty over a narrow window. The result is that your odds of
>> producing a block are slightly reduced but the block you produce if
>> you do is more profitable: but only if there is a good supply of
>> transactions which pay real fees compariable to the ones you're
>> already taking. The same trade-off exists at the moment with respect
>> to orphaning risk and miners still produce large blocks, producing a
>> larger block means a greater chance you're not successful (due to
>> orphaning) but you have a greater utility. The orphing mediated risk
>> is fragile and can be traded off for centeralization advantage or by
>> miners bypassing validation, issues which at least so far we have no
>> reason to believe exist for size mediated schemes.
>>
>> As you know, mining is not a race (ignoring edge effects with
>> orphaning/propagation time). Increasing difficulty does not put you at
>> an expected return disavantage compared to other miners so long as the
>> income increases at least proportionally (otherwise pooling with low
>> diff shares would be an astronomically losing proposition :)!).
>>
>> Pay-for-size schemes have been successfully used in some altcoins
>> without the effects you're suggesting.
>> _______________________________________________
>> 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
|
