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
194
195
196
197
198
|
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 503851BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 01:29:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com
[209.85.212.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33E50B0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 01:29:23 +0000 (UTC)
Received: by wibud3 with SMTP id ud3so40442880wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 18:29:21 -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=De9Q7NOOKFariI1jOmiauF0MzXpFk3s6Vw6dm10fJmc=;
b=XmxmqqBkp9Mm/FveyLWJ58Q8ps17/lZ9DVCLlrk95aMIJ/b+W5rRDzUSWx/bjC8yWa
MhOmnhPER6GeIvCcMxQNncbE2rvEJlvYuq5owALmOpm/Elw6zcm3bfHefKwtVDPvcSdp
//ijKCRDrDx/BNlUyupQT7L/DJ9TljvvAfb1gdzlsCoXrzTpUlsO+2t5C1m/FIWkOU0D
XsMZXt1uR7lWO6BUW3L70f/NYFDROunOjOw5OxdGblRH8tvuG5+cL0/DqtRJ84PSaj45
Kdwo46VApf06boLeXK3jNHGrX9E8za5i2kasDkS09Xjs8798/dHZ2QaZZ4DH67XSyqHa
bD9Q==
X-Gm-Message-State: ALoCoQmJ+s3CajCoUdHmQJNFwX1y9KNQIG6Rf1SjP3o9wXk9LFjh3TF+ipOnPXG5naTELviI9cM+
MIME-Version: 1.0
X-Received: by 10.180.21.175 with SMTP id w15mr1173105wie.58.1438306161586;
Thu, 30 Jul 2015 18:29:21 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 18:29:21 -0700 (PDT)
In-Reply-To: <CABm2gDqCdrVvEzOfUZMBTbEfw5-nfNjBpDcWS-zmNey+_n-qMQ@mail.gmail.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>
<CABm2gDqCdrVvEzOfUZMBTbEfw5-nfNjBpDcWS-zmNey+_n-qMQ@mail.gmail.com>
Date: Fri, 31 Jul 2015 03:29:21 +0200
Message-ID: <CABm2gDopoEgMOPWfqH1Jqk4HktodkhWhYZYmqb2edgi9N7+mXA@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:29:24 -0000
I'm re-reading and I have many spelling errors, sorry.
On Fri, Jul 31, 2015 at 3:21 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> 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.
|
