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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 37DB0109A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 04:57:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com
[209.85.213.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6CB38155
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 04:57:37 +0000 (UTC)
Received: by igbuu8 with SMTP id uu8so10530496igb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 21:57:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=/iiamPSBUurmz9B2QTUMlOq7xI8ctuCxKRRQ1m01YKg=;
b=u1xHHJnDc7md0GCuSqKmgx1pvtYjAqnIHjNnzB3HhXrZNWUuwif6UeX7Qeh43e0MdQ
x6HzTpAU23eIsYVqyxrYE+aSy9Yh2ijNL9Fx2jUJBGURfMbVboY9OkqGbkUyhX497fT9
F8YIFMn/Bkl/6EBDIKhwhSi0KMXCZpdJW8XaeN1NYcaBLtPD2khSuB4WvAAx9h7d2Jkw
jEPr71w1fi4nXoTXfhDP2g2gb3Bvx4ExD/yzsoj+7fS9iz1+tiwXpA2L7zU/DWM2CLUB
W4h2fI4crSZco8mnBLjIxjkSj7W6cc+ei68xVTTH18bonF5NiTKRqZJinynd2OnkKr06
A57g==
MIME-Version: 1.0
X-Received: by 10.50.92.99 with SMTP id cl3mr8984099igb.48.1440910656870; Sat,
29 Aug 2015 21:57:36 -0700 (PDT)
Received: by 10.107.19.86 with HTTP; Sat, 29 Aug 2015 21:57:36 -0700 (PDT)
In-Reply-To: <5CC48639-11D0-4682-BF82-443286C8E58D@gmx.com>
References: <CAEgR2PFB3h_8fr=d8HegRSD0XdooimhFKtLR4vKr2QXv+EwBfQ@mail.gmail.com>
<AD284610-4F40-445C-A074-CC94EDFFCBA8@gmx.com>
<CAAS2fgRs5NVM2nHKNXbgMJa51tDq-6ZBc6XfaScyP45UPWTW_g@mail.gmail.com>
<5CC48639-11D0-4682-BF82-443286C8E58D@gmx.com>
Date: Sun, 30 Aug 2015 04:57:36 +0000
Message-ID: <CAAS2fgShF=2vtPrKtXmdA454s_xpJbxSB0SFBsstniHB8WtGzQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter R <peter_r@gmx.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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@lists.linuxfoundation.org Dev"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Your Gmaxwell exchange
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: Sun, 30 Aug 2015 04:57:38 -0000
On Sun, Aug 30, 2015 at 4:13 AM, Peter R <peter_r@gmx.com> wrote:
> I agree that miners may change their level of centralization. This neither
> affects the model nor the results presented in the paper.
It has tremdous significance to the real-world impact of your results.
If not for the other errors in your work, this point would make the
take away of your work not "a healthy transaction fee market exists
without a block size limit" but rather "a decenteralized bitcoin
cannot exist"-- as, accepting the other errors as fact your model
shows that centralizing mining is always strictly more profitable at
any level of fee demand; because your model equivilent shows that for
any level of fee demand and gamma miners could increase their income
by centeralizing further.
I absolutely agree that simplifications are useful and essential, but
it is critically important to call them out before someone mistakes
theoretical work as useful motivation for policy in the non-simplified
system.
> -- Instead the same information can be transmitted _in advance_, as
> has been previously proposed, and various techniques can make doing
> so arbitrarily efficient.
>
> I assume, very reasonably, that the block solutions contain information
> about the transactions included in the block. This is the case today, this
> is the case using the relay network, and this would be the case using any
> compression scheme I can personally imagine actually occurring in the
> future.
This assumption is unreasonable, and does not-- in fact-- accurately
reflect the situation today.
For example it does not reflect how hashers return work to pools
_today_ (and since 2011) as they so to only by referencing the merkel
root... the pool already knows the transaction set. In that
particular case it knows it because it selected it to begin with, but
the same behavior holds if the hasher selects the transaction set and
sends it first.
It only _very_ weakly reflects how the relay protocol works (only the
selection and permutation is communicated; not the transaction data
itself; for already known transactions). Even if you assume nothing
more than that (in spite of the existing reality) you have not shown
that the compressed data must be linear in the size of the block.
It does not reflect how P2Pool works (which also sends the
transactions in advance).
There is a simple, and intuitive understanding that does not require
any complex supposition: You argue that the information must be
transfered when a block is found, thus delaying it. I point out, no,
any required information (to the extent that there is any at all after
efficient encoding) can be sent in advance of the block.
I believe that you've allowed the fact that the specifc example block
relay protocol doesn't bother sending _all_ information in advance to
confuse it for mere compression.
> My public comments have been factual. I've even gone out of my way in
> several public threads to point out your objection that the coding gain
> could be zero (even though I think it is flawed "black-and-white thinking"
> about an academic scenario that will never unfold and might actually be
> physically impossible without Bitcoin already being centralized).
I believe my reponses are firmly grounded in the physical reality of
actually deployed systems and constructable protocols.
By comparison, even if I were to agree that the bound is not actually
exactly 0 proporionality you have already agreed that with
"compression" the amount sent could be arbritarily low. The result
being that the behavior you're describing would only be asymptoic and
have no relationship to the actual Bitcoin system that exists in a
finite universe.
But you continue to demand debate over this meaningless point.
> I'll end by saying that I am the one describing things as the presently are.
> You are talking about a hypothetical future that may or may not exist (and
> may not even be possible). The results of my paper logically follow from
> the assumptions made. You think the assumption that "block solutions contain
> information about the transactions included in the block" will not hold in
> the future. Can you show:
>
> (a) Under what assumptions/requirements your communication scheme is
> physically possible.
Pratically every block today is mined under a protocol which does not
need to communicate anything but constant data when a block is found.
I am getting a little tired of people suggesting things which are
widely deployed are not physically possible.
Yes, that particular example is not the most powerful form of that
idea-- but it has the benefit of _universal_ use.
> (b) That such a configuration is not equivalent to a single entity[1]
> controlling >50% of the hash power.
I find this a little amusing. Even in this messsage you defend
ignoring of centeralization considerations in your paper. But here ask
that I address concerns which you refused to suggest. Why do you
demand my correction use weaker assumptions than your work?
That said-- I already gave you a fairly concrete description of a
pratical protocol which would accomplish your requirement ( (a) reduce
the information transmitted in a latency critical way at block
discovery time to O(1) network wide, (b) without creating
centeralization in chain or transaction selection). I believe my
description in the messages was adequate that anyone working on
Bitcoin Core could go implement a version of it, at least. You appear
to have simply ignrored it.
If the actual technical details made your eyes glaze over I also
offered a simple intutive understanding: The no proportional
information need be transfered at the latency critical time, because
it can be transfered in _advance_. Everything beyond that is just
efficiency optimizations to reduce the cost of doing the advanced
transmission.
> (c) That the network moving into such a configuration is plausible.
That it already uses advanced information techniques in every widely
used mining protocol, that the relay protocol was rapidly adopted, and
that your own model would suggest significant profits from any such
improvement would seem to remove any doubt related to (c)... and again
here you hold me to a higher bar than your own work: as nowhere do you
show that the "limits" your model erroniously extracts are plausable
as limits, and in private you seemed to admit to me that they may well
not be.
|
