summaryrefslogtreecommitdiff
path: root/ab/d3fcdc96695c71a132d7380100599518a9a549
blob: b942e40647830781437a7937f5d2e420fab5ee60 (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
194
195
196
197
198
199
200
201
202
203
204
Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 60ED2DD8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 30 Aug 2015 02:00:05 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A12D5176
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 30 Aug 2015 02:00:04 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx001)
	with ESMTPSA (Nemesis) id 0M0y8F-1YiAuN24eV-00vC5e;
	Sun, 30 Aug 2015 04:00:01 +0200
From: Peter R <peter_r@gmx.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5C3FA3B5-06DC-4E74-BD41-9EBB07B21A3B"
Message-Id: <B5E339E4-10F1-4252-9F40-F19E5609ECE7@gmx.com>
Date: Sat, 29 Aug 2015 18:59:58 -0700
To: "bitcoin-dev@lists.linuxfoundation.org Dev"
	<bitcoin-dev@lists.linuxfoundation.org>, 
	Gregory Maxwell <gmaxwell@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V03:K0:tHiktMLcHXu3YcKmBtBRM/j3mnonnp0seferOEXohUWKKteGYCb
	pCD+RVQi76WUXqh+ltAfhNGZH5vcoJgQjdjvhptHPcgXt+WYgRiSHTp/XkeMAFJmNM/2R/P
	muY0lKgZcEvcIdpJTdJ0WdsAO0EXeBMzRernob2HdG1QnHF9NFSJNjtEtNzOASbYG38kMog
	U0/NC2uYn1toFspz39sJA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:g+ln88W7qls=:uB2zjuYMa86zJVbfitBZB8
	z+PpC94oP3ol23JF6hKLziejn2wFJS4AxbtyEENp23WfaZ3udo4ZoKqGnCUuKnDrOv41BQbQl
	lBf9kZphpptsvcpC1+7ZVZYITx4CI7u/Vj0CPvUc3prtX1XZZ+zDZhi5fSlIdcqts0MOSDacB
	TvI5xVSeGyJ+M6JUUjXt24EHYEWqTK+k52jze9+uQv3rtK8tQwVsqX1T3fJ/ABEImeIn0y4W3
	4xE/aWUA2qdllG7BLQwvIgmk0KTO5KDseqB2QEUJneDCCYrxepV8RPc9N5RsyM+WygJiQcEUe
	rT4a1mWlA9HU1aFirS4o9gfo+Qt+uJX+oZjh5s+GiPuDHQVA3XIy5L3JKhcC/ILpV5/ccXjZp
	DNCKOZs06ZB9PUvA+zu/5BbJKER/cP+5GQXjLLRKRxhAvSMUjPQvKCIHUOT7tGCOsFRAgSOPL
	CCt6FCdlPINsWx4zJkMpbdJpObFSiqUDgs6z4dtczD8ZpASOe8TeVjuYszU74Gd15E/mkii0H
	5Kyn0xRIc9uA4RRVB03y1/mSdK8nElZnF9qQJF15ZliPruCsc9Nj3KzVZEaJ2DH4I2PzdXIAS
	TS8FHUJe5zoQf9mOPtNW6hvkmwPSyCT+LMdTsC3dCekLVFS0/lfzDnpzDNp8IbDGjQOMprjNo
	DhbRTmdmhVdCTXD7A/zl2u8xMWhmQmi82oTDWUk5D2i+8IagCxVCyHRhmveU3RhhHqW0dmk3q
	/IY+FgdcMIG2s4XjHByWYEoeNOJBRFviTkkGCw==
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	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
Subject: [bitcoin-dev] Fwd: 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 02:00:05 -0000


--Apple-Mail=_5C3FA3B5-06DC-4E74-BD41-9EBB07B21A3B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Dear Greg,

I am moving our conversation into public as I've recently learned that =
you've been forwarding our private email conversation verbatim without =
my permission [I received permission from dpinna to share the email that =
proves this fact: http://pastebin.com/jFgkk8M3].
> Greg wrote to Peter R:  "You know that your "proof" of this =
problematic-- outright false under the discussion we had, or at least =
likely of little pratical relevance under reasonable, pratical =
assumptions.  But you respond to dpinna agreeing with him and not =
cautioning him on relying on these
>=20
The proof is not "problematic."  Right now you're providing an example =
of what Mike Hearn refers to as "black-and-white" thinking.  Just =
because the proof makes simplifying assumptions, doesn't mean it's not =
useful in helping us to understand the dynamics of the transaction fee =
market.  Proofs about physical systems need to make simplifying =
assumptions because the physical world is messy (unlike the world of =
pure math). =20

My proof assumes very reasonably that block solutions contain =
information (i.e., Shannon Entropy) about the transactions included in a =
block.  As long as this is true, and as long as miners act rationally to =
maximize their profit, then the fee market will remain "healthy" =
according to the definitions given in my paper.  This is the case right =
now, this is the case with the Relay Network, and this would be the case =
using any implementation of IBLTs that I can imagine, so long as miners =
retain the ability to construct blocks according to their own volition.  =
The "healthy fee market" result follows from the Shannon-Hartley =
theorem; the SH-theorem describes the maximum rate at which information =
(Shannon Entropy) can be transmitted over a physical communication =
channel.  =20

You are imagining an academic scenario (to use your own words: "perhaps =
of little practical relevance") where all of the block solutions =
announcements contain no information at all about the transactions =
included in the blocks.  Although I agree that the fee market would not =
be healthy in such a scenario, it is my feeling that this also requires =
miners to relinquish their ability to construct blocks according to =
their own volition (i.e., the system would already be centralized).  I =
look forward to reading a white paper where you show:

(a) Under what assumptions/requirements such a communication scheme is =
physically possible.

(b) That such a configuration is not equivalent to a single entity[1] =
controlling >50% of the hash power.

(c) That the network moving into such a configuration is plausible.

Lastly, I'd like to conclude by saying that we are all here trying to =
learn about this new amazing thing called Bitcoin.  Please go ahead and =
write a paper that shows under what network configuration my results =
don't hold.  I'd love to read it!  This is how we make progress in =
science!!

Sincerely,=20
Peter

[1] For example, if--in order to achieve such a configuration with =
infinite coding gain--miners can no longer choose how to structure their =
blocks according to their own volition, then I would classify those =
miners as slaves rather than as peers, and the network as already =
centralized.


Link to forwarded email pastebin: http://pastebin.com/jFgkk8M3


--Apple-Mail=_5C3FA3B5-06DC-4E74-BD41-9EBB07B21A3B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>Dear Greg,</div><div><br></div><div>I am moving our =
conversation into public as I've recently learned that you've been =
forwarding our private email conversation verbatim without my permission =
[I received permission from dpinna to share the email that proves this =
fact:&nbsp;<a =
href=3D"http://pastebin.com/jFgkk8M3">http://pastebin.com/jFgkk8M3</a>].</=
div><div><blockquote type=3D"cite"><p dir=3D"ltr">Greg wrote to Peter R: =
&nbsp;<i>"You know that your "proof" of this problematic-- outright =
false under&nbsp;</i><i>the discussion we had, or at least likely of =
little pratical relevance&nbsp;</i><i>under reasonable, pratical =
assumptions.&nbsp; But you respond to dpinna&nbsp;</i><i>agreeing with =
him and not cautioning him on relying on =
these</i></p></blockquote><div>The proof is not "problematic." =
&nbsp;Right now you're providing an example of what Mike Hearn refers to =
as "black-and-white" thinking. &nbsp;Just because the proof makes =
simplifying assumptions, doesn't mean it's not useful in helping us to =
understand the dynamics of the transaction fee market. &nbsp;Proofs =
about&nbsp;<i>physical systems</i>&nbsp;need to make simplifying =
assumptions because the physical world is messy (unlike the world of =
pure math). &nbsp;</div><div><br></div><div>My proof assumes very =
reasonably that block solutions contain information (i.e., Shannon =
Entropy) about the transactions included in a block. &nbsp;As long as =
this is true, and as long as miners act rationally to maximize their =
profit, then the fee market will remain "healthy" according to the =
definitions given in my paper. &nbsp;<b>This is the case right now, this =
is the case with the Relay Network, and this would be the case using any =
implementation of IBLTs that I can imagine, so long as miners retain the =
ability to construct blocks according to their own =
volition.</b>&nbsp;&nbsp;The "healthy fee market" result follows from =
the Shannon-Hartley theorem; the SH-theorem describes the maximum rate =
at which information (Shannon Entropy) can be transmitted over a =
physical communication channel. =
&nbsp;&nbsp;</div></div><div><br></div><div>You are imagining an =
academic scenario (to use your own words: "perhaps of little practical =
relevance") where all of the block solutions announcements =
contain&nbsp;<b>no information at all</b>&nbsp;about the transactions =
included in the blocks. &nbsp;Although I agree that the fee market would =
not be healthy in such a scenario, it is my feeling that this also =
requires miners to relinquish their ability to construct blocks =
according to their own volition (i.e., the system would already be =
centralized). &nbsp;I look forward to reading a white paper where you =
show:</div><div><br></div><div>(a) Under what assumptions/requirements =
such a communication scheme is physically =
possible.</div><div><br></div><div>(b) That such a configuration is not =
equivalent to a single entity[1] controlling &gt;50% of the hash =
power.</div><div><br></div><div>(c) That the network moving into such a =
configuration is plausible.</div><div><br></div><div>Lastly, I'd like to =
conclude by saying that we are all here trying to learn about this new =
amazing thing called Bitcoin. &nbsp;Please go ahead and write a paper =
that shows under what network configuration my results don't hold. =
&nbsp;I'd love to read it! &nbsp;This is how we make progress in =
science!!</div><div><br></div><div>Sincerely,&nbsp;</div><div>Peter</div><=
div><br></div><div>[1] For example, if--in order to achieve such a =
configuration with infinite coding gain--miners can no longer choose how =
to structure their blocks according to their own volition, then I would =
classify those miners as slaves rather than as peers, and the network as =
already centralized.</div></div><div><br></div><div><br></div><div>Link =
to forwarded email pastebin:&nbsp;<a =
href=3D"http://pastebin.com/jFgkk8M3">http://pastebin.com/jFgkk8M3</a></di=
v><div><br></div></body></html>=

--Apple-Mail=_5C3FA3B5-06DC-4E74-BD41-9EBB07B21A3B--