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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 776F083D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 19:45:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com
[209.85.212.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D0E9017B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 19:45:36 +0000 (UTC)
Received: by wicne3 with SMTP id ne3so74422579wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 12:45:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=CpDCXaByHxZDAZ2le0hmtV7mFzARnKqP0Y6TcURSG9g=;
b=lUggw1qbfUVl9H938zx0Ee54twhX+Gu+8JwUX2ljYGYhoVZRgx0coIK6Q2wpFFl7/y
pTGm51wioQTTWCP584Xxk3gB3svA+a1/Giu026NXhQS2t6Nqh4zqhxErTSEfS+Zjjda2
OtYEi/Pqp/YcP6ATwrTOdpqvRQLIvfRgdocrteQBARGfFUlWNcXW0q2ernKhYo3DIueN
7FjPjc8xdL+crrO8t4ZxZFFALAG01FPBqc5w16JITFGFz5hkUnbFQqmR/en8gkS/oUEO
TIMO4/HdsDgBWMjwkZ3leiR96Lz8sWCDIJvIE3SrmyYo9xhx61WxLutt8RqljddWPaY6
tK5A==
X-Gm-Message-State: ALoCoQnKSLvUp++dw33wFWnjQNIXuYoZPH3q5mVN+0MVr+lGuLHCWx0d+mVwa5jTRKx8ZYPj3qLV
MIME-Version: 1.0
X-Received: by 10.180.37.74 with SMTP id w10mr37159855wij.92.1439322335590;
Tue, 11 Aug 2015 12:45:35 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Tue, 11 Aug 2015 12:45:35 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Tue, 11 Aug 2015 12:45:35 -0700 (PDT)
In-Reply-To: <CALgxB7sdUag_26rKbFYNyRxkS2G6sRZ_GOwPF5U8ri2pobNtcA@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CABm2gDpwMQzju+Gsoe3qMi60MPr7OAiSuigy3RdA1xh-SwFzbw@mail.gmail.com>
<CABm2gDoz4NMEQuQj6UHCYYCwihZrEC4Az8xDvTBwiZDf9eQ7-w@mail.gmail.com>
<8181630.GdAj0CPZYc@coldstorage>
<CABm2gDp2svO2G5bHs5AcjjN8dmP6P5nv0xriWez-pvzs2oBL5w@mail.gmail.com>
<CALgxB7sQM5ObxyxDiN_BOyJrgsgfQ6PAtJi52dJENfWCRKywWg@mail.gmail.com>
<CAOG=w-u61dDpa+QrPfku_TCUW7TJLmKekYPbJrF2onsKXAmWdA@mail.gmail.com>
<CALgxB7sdUag_26rKbFYNyRxkS2G6sRZ_GOwPF5U8ri2pobNtcA@mail.gmail.com>
Date: Tue, 11 Aug 2015 21:45:35 +0200
Message-ID: <CABm2gDpLNLp=SxfaR8vJUm1KMwBK0jZS1sABVOZw+N5v8t55eQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Michael Naber <mickeybob@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f64720f87f201051d0e5860
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW autolearn=ham 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] Fees and the block-finding process
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: Tue, 11 Aug 2015 19:45:37 -0000
--e89a8f64720f87f201051d0e5860
Content-Type: text/plain; charset=UTF-8
On Aug 11, 2015 8:55 PM, "Michael Naber" <mickeybob@gmail.com> wrote:
>
> It generally doesn't matter that every node validate your coffee
transaction, and those transactions can and will probably be moved onto
offchain solutions in order to avoid paying the cost of achieving global
consensus. But you still don't get to set the cost of global consensus
artificially. Market forces will ensure that supply will meet demand there,
so if there is demand for access to global consensus, and technology exists
to meet that demand at a cost of one cent per transaction -- or whatever
the technology-limited cost of global consensus happens to be -- then
that's what the market will supply.
Assuming we maintain any block size maximum consensus rule, the market will
adapt to whatever maximum size is imposed by the consensus rules.
For example, with the current demand and the current consensus block size
maximum, the market has settled on a minimum fee of zero satoshis per
transaction. That's why I cannot understand the urgency to rise the maximum
size.
In any case, yhe consensus maximum shouldn't be based on current or
projected demand, only on centralization concerns, which is what the
consensus rule serves for (to limit centralization).
For example, Gavin advocates for 20 MB because he is not worried about how
that could increase centralization because he believes it won't.
I can't agree with that because I believe 20 MB could make mining
centralization (and centralization in general) much worse.
But if I have to chose between 2 "centralization safe" sizes, sure, the
bigger the better, why not.
In my opinion the main source of disagreement is that one: how the maximum
block size limits centralization.
--e89a8f64720f87f201051d0e5860
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Aug 11, 2015 8:55 PM, "Michael Naber" <<a href=3D"mailto:mi=
ckeybob@gmail.com">mickeybob@gmail.com</a>> wrote:<br>
><br>
> It generally doesn't matter that every node validate your coffee t=
ransaction, and those transactions can and will probably be moved onto offc=
hain solutions in order to avoid paying the cost of achieving global consen=
sus. But you still don't get to set the cost of global consensus artifi=
cially. Market forces will ensure that supply will meet demand there, so if=
there is demand for access to global consensus, and technology exists to m=
eet that demand at a cost of one cent per transaction -- or whatever the te=
chnology-limited cost of global consensus happens to be -- then that's =
what the market will supply.</p>
<p dir=3D"ltr">Assuming we maintain any block size maximum consensus rule, =
the market will adapt to whatever maximum size is imposed by the consensus =
rules.<br>
For example, with the current demand and the current consensus block size m=
aximum, the market has settled on a minimum fee of zero satoshis per transa=
ction. That's why I cannot understand the urgency to rise the maximum s=
ize.</p>
<p dir=3D"ltr">In any case, yhe consensus maximum shouldn't be based on=
current or projected demand, only on centralization concerns, which is wha=
t the consensus rule serves for (to limit centralization).<br>
For example, Gavin advocates for 20 MB because he is not worried about how =
that could increase centralization because he believes it won't.<br>
I can't agree with that because I believe 20 MB could make mining centr=
alization (and centralization in general) much worse.</p>
<p dir=3D"ltr">But if I have to chose between 2 "centralization safe&q=
uot; sizes, sure, the bigger the better, why not.<br>
In my opinion the main source of disagreement is that one: how the maximum =
block size limits centralization.<br></p>
--e89a8f64720f87f201051d0e5860--
|
