summaryrefslogtreecommitdiff
path: root/3a/02fc2958ff5aa1f6c6a7153aa448c428efce2c
blob: 93f4f08922340b0247f31618a0205aa7a52dd189 (plain)
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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
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 DBC3B267
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 01:21:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
	[209.85.212.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B0FF214E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 01:21:09 +0000 (UTC)
Received: by wicgb10 with SMTP id gb10so13222364wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 18:21:08 -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
	:content-transfer-encoding;
	bh=99Sin8tJQEhS8WZJb4JlJqmjsmyprkmOB4uZMkFkKXQ=;
	b=ElkEYddum2BzBel3Jz8qCwBw/bt9RYArerpjBZjpxIsq+yV21ul2fT7pMWniTwHCdF
	7BV+HuyOgDOu7iDkhQApg63MOaEw3o0fOQQTsG/Sim4/j7hUV2gDnggD70JCuq4EYHz4
	wvO4lW4h16ZG8LlxliKpbeu2SrdRc49NMKIDGA4bXPGDRdlQcEG5+cuYTG1YXV+aKaky
	iFDHOLMFZIVYnQJJJJ47SkSjD7Caq4K18b5jcWG1KCqjjctGO4RWjJJtLfiPwu6qd9ic
	kFAA85llN5rwb9cXZQaXv3uqaBBa4gGvL9RGUe0QRdOqoJVWBirItZhX4/33CzeKku87
	fbgA==
X-Gm-Message-State: ALoCoQnfYxv963gFdhS87pUy4n6WL0UtoqShDGwaMpJl98ZxUKbBkSynh0TIp+gEiBBbpbQH9m8g
MIME-Version: 1.0
X-Received: by 10.194.120.198 with SMTP id le6mr307459wjb.133.1438305667939;
	Thu, 30 Jul 2015 18:21:07 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 18:21:07 -0700 (PDT)
In-Reply-To: <55BA8ED0.4080600@thinlink.com>
References: <CADZB0_ZgDMhVgCUh2PTAPDL7k_W8QGt_HLYdkwv_qQ5xEMn8HA@mail.gmail.com>
	<543015348.4948849.1438178962054.JavaMail.yahoo@mail.yahoo.com>
	<COL131-DS3F7339BCCA36BEFD1755ACD8C0@phx.gbl>
	<55B959A2.9020402@sky-ip.org>
	<CAF_2MyVAXg9788gatEQ-t4=8rJxXdkf9DA45uF5_gksDUM6b=A@mail.gmail.com>
	<CALqxMTHEknuwPW-uG3W9Fv1sQC54ud3zk4aLQaFGTTjAt7ghfA@mail.gmail.com>
	<CAF_2MyXhhZyHSekOR0uTKndt8onEHqTJGnZwWFXoHw6xngidPA@mail.gmail.com>
	<55BA2329.1080700@thinlink.com>
	<CABm2gDoh69a0335uLhwVndwwLiYtZEVdCvNsrCtHiRAVrSqkaQ@mail.gmail.com>
	<55BA8ED0.4080600@thinlink.com>
Date: Fri, 31 Jul 2015 03:21:07 +0200
Message-ID: <CABm2gDqCdrVvEzOfUZMBTbEfw5-nfNjBpDcWS-zmNey+_n-qMQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Tom Harding <tomh@thinlink.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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]
	=?utf-8?q?R=C4=83spuns=3A_Personal_opinion_on_the_f?=
	=?utf-8?q?ee_market_from_a_worried_local_trader?=
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: Fri, 31 Jul 2015 01:21:11 -0000

On Thu, Jul 30, 2015 at 10:53 PM, Tom Harding <tomh@thinlink.com> wrote:
> On 7/30/2015 11:14 AM, Jorge Tim=C3=B3n wrote:
>> The blocksize limit (your "production quota") is necessary for
>> decentralization, not for having a functioning fee market.
>
>> If we can agree that hitting the limit will JUST cause higher fees and
>> not bitcoin to fail, puppies to die or the sky to turn purple I think
>> that's a great step forward in this debate.
>
> It's interesting how people see things differently.  I think your first
> statement above represents a great step forward in the debate.  Unlike
> Adam Back, you state that a block size limit is not necessary to create
> a functioning fee market.

Yes, Adam Back and I some times see things differently, and that's fine.
Many times, we realize later that we're saying the same thing with
different words and we're just discussing about terminology. That's
not an exclusive problem we have, it's a universal communication
problem. That's why math (which is nothing but a language) was
invented: to never discuss about terminology, to force any used
concept to be defined beforehand.
Sorry for the distraction, but I think this is one of those times.
Whether "hitting the limit" is "necessary" (I bet he never said
"strictly necessary") or just "helpful" is not very relevant. I think
Adam and I agree that hitting the limit wouldn't be bad, but actually
good for an young and immature market like bitcoin fees.
Apart from the dubious time-preference premium (dubious because in
most cases is just wallet's defaults and not users in a hurry),
transactions are basically free if you are willing to wait (and
apparently not that much).

If I was a miner and you want me to include your transaction for free,
you're asking me to give you money, which I would prefer to do
directly if you are a friend or a non-profit organization that I like
or whatever rather than giving you money through bitcoin fee
discounts.
By including your transaction, I'm increasing the probability of my
mined block being orphaned and you're not willing to give me even a
single satoshi in exchange.
Today, in practice, one satoshi fee and no fee at all are treated
exactly the same by most (maybe all?) miners, which if you ask me, I
find very ~~unfair~~ economically absurd.

Are all miners just stupid?
Not necessarily, they just don't care about fees or transactions at all.
Who is to blame? Certainly not the value chosen for the block size
limit, it's clearly the subsidy's fault: subsidy is all miners care
about (by the way, that's also the illness behind the SPV-mining
symptom). I am very worried about excessive mining subsidies (if you
knew how worried the freicoin community was [and still is] about this
problem, even if freicoin probably has one of the lowest mining
subsidies out there [currently and perpetually annual 5% of the
monetary base]...).
And I think that "hitting the limit" is not a catastrophe at all, but
rather an opportunity to motivate miners to start caring more about
transactions and fees (in proportion to what they care about).
And if the limit is increased later and fees fall again, that's fine,
because miners' will already be more prepared for the next time we
"hit the limit".
Anyway, maybe that hope is irrelevant, but what I'm convinced about is
that rising non-fast-confirmation mining fees above zero is not a bad
thing.

> As to your second statement, unfortunately for immediate harmonious
> relations, I was merely separating out the elevated fee market concern,
> not at all saying it is the only or even the biggest concern with
> limited capacity.  Alan Reiner, Ryan X. Charles and others have
> eloquently explained how restrictive a 1MB limit is, even with "layer 2".

To be honest, I've only followed those were assuming the worse case
for optimization: bitcoin global monetary monopoly.
If I remember correctly, they were aiming for something around 170 MB,
but in any case, any value for the constant is completely arbitrary to
me at this point, including 1 MB. I'm deeply offended when I feel
included in the "1MBers group" because I don't feel like that at all.
To be honest, I have no idea what the correct value should be, all I
know it's a trade-off in a monotonic function:

f(blocksize) =3D decentralization

> What's missing from the decentralization dialog is a quantitative
> measure of decentralization.

You are completely right: there's no defined measurable unit for
"decentralization" ("p2pness", whatever bitcoin has that wasn't
possible before pow-based distributed consensus).
And I'm afraid we will never have such a measurable unit. Maybe the
best definition of the property we're trying to capture is just "the
opposite of centralization", assuming centralization is easier to
define.
The best we have now are pool percentages, number of nodes,
subsidy/fee ratio (as said, this influences things like SPV mining)
How all that gets to...?

g(many unrelated matrics) =3D centralization

I don't really think anybody knows, but no matter what your
interpretation of some Japanese-named dude on the internet's words
(aka bitcoin sacred history) are, if you think 3 validating nodes is
enough for a "p2p" monetary network.
It is very possible that decentralization(blocksize) =3D
decentralization(blocksize+1) for many values of blocksize, but I
think the burden of the proof that decentralization(current_blocksize)
~=3D decentralization(current_blocksize+1) is on those who propose
++current_blocksize.
But I think ANY metric for centralization would be welcomed right now.
In fact, it doesn't need to be a function of blocksize, it can be a
function of maxBlockSigops or maybe even maxBlockInputs or
maxBlockOuputs.
But if we don't want to have any consensus limit to centralization
bitcoin has already fail (and doesn't need expensive proof of work).

> Why not slam users with higher fees now, if we accept that they may be
> necessary someday? For the same reasons you don't ask a child, age 5, to
> work in a factory.

It is a certainty that fees will be necessary someday: bitcoin's
seigniorage is limited to 21 M to subsidize mining, and we know that
won't last forever. Expensive proof of work (that centralized systems
lack) must be paid for somehow.
Who's child am I asking to work in a factory? I feel I'm missing
something there.