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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
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 1WYDBF-0006Gq-Pj
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Apr 2014 11:30:05 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WYDBE-0006Xl-W7
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Apr 2014 11:30:05 +0000
Received: by mail-ob0-f179.google.com with SMTP id va2so4262628obc.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 10 Apr 2014 04:29:59 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.233.201 with SMTP id ty9mr13647699obc.29.1397129399422;
Thu, 10 Apr 2014 04:29:59 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Thu, 10 Apr 2014 04:29:59 -0700 (PDT)
In-Reply-To: <CA+s+GJCQSCUyq7Ajv0EgZ8Vbcv4Xt7G-y_8D12fsoKjyFjnhwg@mail.gmail.com>
References: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com>
<CAAt2M18z_Qkqat1OETiXAz0QQey4+y5J6=pC7nkoJfyfrpj3=A@mail.gmail.com>
<CAAS2fgScWkentFy7Ak0bpYVLsOFL+xkwPm5QRu9ENeX9oCtPug@mail.gmail.com>
<534570A2.9090502@gmx.de>
<CA+s+GJAXu3SEXFDDwi85dNFjO2rfPXJrg-aKHYwbogAHfu3vfQ@mail.gmail.com>
<0B038624-8861-438E-B7B1-566B4A8E126B@bitsofproof.com>
<CA+s+GJCQSCUyq7Ajv0EgZ8Vbcv4Xt7G-y_8D12fsoKjyFjnhwg@mail.gmail.com>
Date: Thu, 10 Apr 2014 13:29:59 +0200
X-Google-Sender-Auth: TgnIPudutjaxGcBxXUv5wXciWN8
Message-ID: <CANEZrP1aa8AWvpgiQbnGF+DHEhBwCoNL4V-REH06NJ2iKNv0hw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Wladimir <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c1c5088ed66904f6ae8978
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: 1WYDBE-0006Xl-W7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV
wallets
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: Thu, 10 Apr 2014 11:30:05 -0000
--001a11c1c5088ed66904f6ae8978
Content-Type: text/plain; charset=UTF-8
>
> What would this involve?
>
> Do you know of any previous work towards this?
>
Chain pruning is a fairly complicated project, partly because it spans
codebases. For instance if you try and implement it *just* by changing
Bitcoin Core, you will break all the SPV clients based on bitcoinj (i.e.
all of them). Big changes to the P2P network like this require upgrading
both codebases simultaneously.
I think things like this may be why Gavin is now just "chief scientist"
instead of Core maintainer - in future, the changes people need will span
projects and require fairly significant planning.
From a technical perspective, it means extending addr broadcasts so nodes
broadcast how much of the chain they have, and teaching both Core and
bitcoinj how to search for nodes that have enough of the chain for them to
use. Currently bitcoinj still doesn't use addr broadcasts at all, there's
an incomplete patch available but it was never finished or merged. So that
has to be fixed first. And that probably implies improving Bitcoin Core so
the results of getaddr are more usable, ideally as high quality as what the
DNS seeds provide, because if lots of bad addresses are returned this will
slow down initial connect time, which is an important performance metric.
--001a11c1c5088ed66904f6ae8978
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote">
<div>What would this involve?<br></div><div><br>Do you know of any previous=
work towards this?</div></div></div></div></blockquote><div><br></div><div=
>Chain pruning is a fairly complicated project, partly because it spans cod=
ebases. For instance if you try and implement it <i>just</i>=C2=A0by changi=
ng Bitcoin Core, you will break all the SPV clients based on bitcoinj (i.e.=
all of them). Big changes to the P2P network like this require upgrading b=
oth codebases simultaneously.</div>
<div><br></div><div>I think things like this may be why Gavin is now just &=
quot;chief scientist" instead of Core maintainer - in future, the chan=
ges people need will span projects and require fairly significant planning.=
</div>
<div><br></div><div>From a technical perspective, it means extending addr b=
roadcasts so nodes broadcast how much of the chain they have, and teaching =
both Core and bitcoinj how to search for nodes that have enough of the chai=
n for them to use. Currently bitcoinj still doesn't use addr broadcasts=
at all, there's an incomplete patch available but it was never finishe=
d or merged. So that has to be fixed first. And that probably implies impro=
ving Bitcoin Core so the results of getaddr are more usable, ideally as hig=
h quality as what the DNS seeds provide, because if lots of bad addresses a=
re returned this will slow down initial connect time, which is an important=
performance metric.</div>
<div><br></div><div><br></div></div></div></div>
--001a11c1c5088ed66904f6ae8978--
|
