summaryrefslogtreecommitdiff
path: root/42/aa951bdc71ea39a7ad627310358c74754b706e
blob: b4d594b57a65dcc120e694b193728e56c39878bd (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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <marek@palatinus.cz>) id 1WXzSH-0004Yt-Eb
	for bitcoin-development@lists.sourceforge.net;
	Wed, 09 Apr 2014 20:50:45 +0000
X-ACL-Warn: 
Received: from mail-ve0-f171.google.com ([209.85.128.171])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WXzSG-0003rX-Ds
	for bitcoin-development@lists.sourceforge.net;
	Wed, 09 Apr 2014 20:50:45 +0000
Received: by mail-ve0-f171.google.com with SMTP id jy13so2556683veb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 09 Apr 2014 13:50:38 -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:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc:content-type;
	bh=5o54QI6yamSPPrwWqG3TVkasjVpgfZwFZym1F9oloDc=;
	b=ZUUf2yBpturiDw7Pl2mtQy/W7/Pu+tne2QjSlnq59A37Pfoq1fm2DlbnKNX9/I5LFG
	u3CG5gpXMTBlmOHTM6Ya4Xr7elcArU/K+bcNy0422bAexNFzzw/OcRypJpQsCCd8Er9Q
	JYwYRo3/OripH4Y6JYvIcFkln3FTfd/sP/672qC+HsKvy3XmmH8HtNmkiG9uNWmOGejW
	qOKNFo7I1lKiDd1Crf0afESXhdt/LhSEMIM2MIH0G1VWKOIY/zw4fokovZlMyxHuquLw
	6v7SpynHcNNYXtlkBue5SHC9952ZAW0sdhgVPNx6s7S7n9kWCVDdgZu5h4x4gEbQj4UM
	3XOQ==
X-Gm-Message-State: ALoCoQl7T+p+gGND9hnorCn/mKwkvipRLRZs+Baerc/LL76S56Rghs8XEyZ8DdEGsM7HAchNOlu/
X-Received: by 10.58.230.103 with SMTP id sx7mr2423528vec.28.1397076638694;
	Wed, 09 Apr 2014 13:50:38 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.58.234.100 with HTTP; Wed, 9 Apr 2014 13:50:08 -0700 (PDT)
In-Reply-To: <CA+s+GJA0EqvZB3Bi75W+-Pfkjg=3=-wafjSBPMCnd_vbi2F-0w@mail.gmail.com>
References: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com>
	<CAADm4BCEFCiOpNzUThPPHUamP2256izU8pwD3nerLCxks0wENA@mail.gmail.com>
	<CAAS2fgTx40XSLhiygnJMrSbOC=iJ2YMVLNK7-AMt3ifvAHDZUA@mail.gmail.com>
	<E9BAD633-3B6A-4A2C-AA06-DB591973DF66@bitsofproof.com>
	<53456B99.9010207@monetize.io>
	<B2FEC170-7214-4E46-8830-153995870B62@bitsofproof.com>
	<00b77560-d7ed-4ed4-a4e5-eb1f00467a06@email.android.com>
	<0509477C-89F9-47C7-8820-29ACAD4A4A8E@bitsofproof.com>
	<CANEZrP2Q=TG+jejEVFFh5FhjzDDkySHNSTfwtKueLcHu=pB6Kw@mail.gmail.com>
	<CA+s+GJBRvDFgktTgW2sCvAVahrjxcGqfgHw0BVNPvwUupotVrg@mail.gmail.com>
	<534592E2.7040800@gmail.com>
	<CAAS2fgS3q6N9go-NSKdjLwgU_5bFwa8YE88DcjNYHQTwzPCn3Q@mail.gmail.com>
	<5345986C.3040901@gmail.com>
	<CAAS2fgQyXHNnBDKoUMd_=-=1irGJ6cFKwi59enLJvFJiWBv50A@mail.gmail.com>
	<CAJna-Hj1U5cQ22bSXoNB-4ck_urCuS9xCk+iEHsbh+yv17MP7A@mail.gmail.com>
	<CA+s+GJA0EqvZB3Bi75W+-Pfkjg=3=-wafjSBPMCnd_vbi2F-0w@mail.gmail.com>
From: slush <slush@centrum.cz>
Date: Wed, 9 Apr 2014 22:50:08 +0200
X-Google-Sender-Auth: v3EevFhAn-GPI_fRuolk3udVmmw
Message-ID: <CAJna-HjyFbCdQjVZJSJ2AYx10EJd-ZJa=zmdJqveMP+ASgwygA@mail.gmail.com>
To: Wladimir <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bea3606c727ac04f6a24082
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(slush[at]centrum.cz)
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1WXzSG-0003rX-Ds
Cc: Bitcoin Development <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: Wed, 09 Apr 2014 20:50:45 -0000

--047d7bea3606c727ac04f6a24082
Content-Type: text/plain; charset=ISO-8859-1

We definitely *need* lightweight bitcoin router / "core" which can be
easily deployed anywhere. No disagreement here.

I just wanted to remind that there're actually much more running nodes
*already* and maybe converting those hidden nodes to publicly reachable
nodes may be way easier than attracting fresh instances.

To the idea of bundled core with SPV clients - it won't improve anything,
in my opinion. SPV wallets are not running long-term (maybe Multibit team
has any better stats) so blockchain catching will turn the computer to be
unusable everytime user starts the wallet; that's exactly the reason why
people choose SPV wallets over full blockchain wallets.

Not saying that SPV clients usually aren't reachable from outside, which
turns the topic back to my ideas about motivating users to expose their
existing instances over Internet.

Marek

On Wed, Apr 9, 2014 at 10:35 PM, Wladimir <laanwj@gmail.com> wrote:

>
>
> On Wed, Apr 9, 2014 at 10:12 PM, slush <slush@centrum.cz> wrote:
>
>> Maybe there're other ideas how to improve current situation without needs
>> of reworking the architecture.
>>
>
> Nothing I've proposed here would require larger changes to the
> architecture then were already planned. After SPV lands we are going to
> split off the wallet, and that will need an interface to an bitcoind to
> allow 'running with full node'. If that can be generalized to be useful for
> other (SPV) clients as well, that would be useful, hence I asked for input.
>
> It of course doesn't preclude also looking for other solutions.
>
> Wladimir
>
>

--047d7bea3606c727ac04f6a24082
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We definitely *need* lightweight bitcoin router / &quot;co=
re&quot; which can be easily deployed anywhere. No disagreement here.<div><=
br></div><div>I just wanted to remind that there&#39;re actually much more =
running nodes *already* and maybe converting those hidden nodes to publicly=
 reachable nodes may be way easier than attracting fresh instances.</div>

<div><br></div><div>To the idea of bundled core with SPV clients - it won&#=
39;t improve anything, in my opinion. SPV wallets are not running long-term=
 (maybe Multibit team has any better stats) so blockchain catching will tur=
n the computer to be unusable everytime user starts the wallet; that&#39;s =
exactly the reason why people choose SPV wallets over full blockchain walle=
ts.</div>

<div><br></div><div>Not saying that SPV clients usually aren&#39;t reachabl=
e from outside, which turns the topic back to my ideas about motivating use=
rs to expose their existing instances over Internet.</div><div><br></div>

<div>Marek</div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Wed, Apr 9, 2014 at 10:35 PM, Wladimir <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:laanwj@gmail.com" target=3D"_blank">laanwj@gmail.com</a>&gt=
;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote"><div class=3D"">On Wed, Apr 9, 2014 at 1=
0:12 PM, slush <span dir=3D"ltr">&lt;<a href=3D"mailto:slush@centrum.cz" ta=
rget=3D"_blank">slush@centrum.cz</a>&gt;</span> wrote:<br>


</div><div class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Maybe=
 there&#39;re other ideas how to improve current situation without needs of=
 reworking the architecture.</div>


</blockquote><div><br></div></div><div>Nothing I&#39;ve proposed here would=
 require larger changes to the architecture then were already planned. Afte=
r SPV lands we are going to split off the wallet, and that will need an int=
erface to an bitcoind to allow &#39;running with full node&#39;. If that ca=
n be generalized to be useful for other (SPV) clients as well, that would b=
e useful, hence I asked for input. <br>


<br></div><div>It of course doesn&#39;t preclude also looking for other sol=
utions.<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></d=
iv><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Wladi=
mir<br>

<br></div></font></span></div></div></div>
</blockquote></div><br></div></div></div></div>

--047d7bea3606c727ac04f6a24082--