summaryrefslogtreecommitdiff
path: root/3a/194689aa37c9c4124dac4f0caf66dcc4f8b863
blob: 455dbf0e5948892e8fc36f60de0831b70e35f3d3 (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1WcHFs-0005BZ-AW
	for bitcoin-development@lists.sourceforge.net;
	Mon, 21 Apr 2014 16:39:40 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.51 as permitted sender)
	client-ip=209.85.219.51; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f51.google.com; 
Received: from mail-oa0-f51.google.com ([209.85.219.51])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WcHFo-0002jy-UN
	for bitcoin-development@lists.sourceforge.net;
	Mon, 21 Apr 2014 16:39:40 +0000
Received: by mail-oa0-f51.google.com with SMTP id i4so4385080oah.24
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 21 Apr 2014 09:39:31 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.219.167 with SMTP id pp7mr577566obc.85.1398098371559;
	Mon, 21 Apr 2014 09:39:31 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Mon, 21 Apr 2014 09:39:31 -0700 (PDT)
In-Reply-To: <53554979.9020206@monetize.io>
References: <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
	<52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk>
	<CACh7GpFGEvR+_qArYCkgi7AW4coSeH741ob4hmBpj6G3MayNAQ@mail.gmail.com>
	<a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>
	<53554089.1010503@monetize.io>
	<BLU170-W757A725FD907FDC49BF9F2A55E0@phx.gbl>
	<53554979.9020206@monetize.io>
Date: Mon, 21 Apr 2014 18:39:31 +0200
X-Google-Sender-Auth: wbWsMouekcg0UmI5wgb6irP4IMI
Message-ID: <CANEZrP0GYFs64hXe1Yj4E++H+SrH9zoRyucYkZJjCtOfsa2=Tw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Mark Friedenbach <mark@monetize.io>
Content-Type: multipart/alternative; boundary=089e0141ab82cc46ef04f79024e2
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WcHFo-0002jy-UN
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>,
	Jonathan Levin <jonathan.levin@sant.ox.ac.uk>
Subject: Re: [Bitcoin-development] Economics of information propagation
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 21 Apr 2014 16:39:40 -0000

--089e0141ab82cc46ef04f79024e2
Content-Type: text/plain; charset=UTF-8

Pieter tried it already. If the two nodes views of each others mempools are
not exactly in alignment it ends up being slower than just sending the data
immediately and redundantly.


On Mon, Apr 21, 2014 at 6:38 PM, Mark Friedenbach <mark@monetize.io> wrote:

> Yes, it certainly can be improved in this way. You can even extend the
> idea to distribute partial proofs of work (block headers + Merkle lists
> which represent significant but not sufficient work), and 'prime' your
> memory pools with the transactions contained within.
>
> This is, btw, basically what p2pool does, which is why last time I
> calculated you get roughly 1% better return from p2pool than a zero-fee
> mining pool would get you, specifically because of the lower stale rate.
>
> On 04/21/2014 09:22 AM, Paul Lyon wrote:
> > I haven't done the math on this, so it may be a terrible idea. :)
> >
> > I've been wondering if block propagation times could also be improved by
> > allowing peers to request the list of transaction hashes that make up a
> > block, and then making a follow-up request to only download any
> > transactions not currently known. I'm not sure what percentage of
> > transactions a node will usually already have when it receives a new
> > block, but if it's high I figure this could be beneficial.
> >
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--089e0141ab82cc46ef04f79024e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Pieter tried it already. If the two nodes views of each ot=
hers mempools are not exactly in alignment it ends up being slower than jus=
t sending the data immediately and redundantly.</div><div class=3D"gmail_ex=
tra">
<br><br><div class=3D"gmail_quote">On Mon, Apr 21, 2014 at 6:38 PM, Mark Fr=
iedenbach <span dir=3D"ltr">&lt;<a href=3D"mailto:mark@monetize.io" target=
=3D"_blank">mark@monetize.io</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
Yes, it certainly can be improved in this way. You can even extend the<br>
idea to distribute partial proofs of work (block headers + Merkle lists<br>
which represent significant but not sufficient work), and &#39;prime&#39; y=
our<br>
memory pools with the transactions contained within.<br>
<br>
This is, btw, basically what p2pool does, which is why last time I<br>
calculated you get roughly 1% better return from p2pool than a zero-fee<br>
mining pool would get you, specifically because of the lower stale rate.<br=
>
<div class=3D"im HOEnZb"><br>
On 04/21/2014 09:22 AM, Paul Lyon wrote:<br>
&gt; I haven&#39;t done the math on this, so it may be a terrible idea. :)<=
br>
&gt;<br>
&gt; I&#39;ve been wondering if block propagation times could also be impro=
ved by<br>
&gt; allowing peers to request the list of transaction hashes that make up =
a<br>
&gt; block, and then making a follow-up request to only download any<br>
&gt; transactions not currently known. I&#39;m not sure what percentage of<=
br>
&gt; transactions a node will usually already have when it receives a new<b=
r>
&gt; block, but if it&#39;s high I figure this could be beneficial.<br>
&gt;<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">-----------------------------=
-------------------------------------------------<br>
Start Your Social Network Today - Download eXo Platform<br>
Build your Enterprise Intranet with eXo Platform Software<br>
Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
Get Started Now And Turn Your Intranet Into A Collaboration Platform<br>
<a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p.sf.n=
et/sfu/ExoPlatform</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>

--089e0141ab82cc46ef04f79024e2--