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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1WXudS-0005Jm-Is
for bitcoin-development@lists.sourceforge.net;
Wed, 09 Apr 2014 15:41:58 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.44 as permitted sender)
client-ip=74.125.82.44; envelope-from=natanael.l@gmail.com;
helo=mail-wg0-f44.google.com;
Received: from mail-wg0-f44.google.com ([74.125.82.44])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WXudR-0004pK-Mn
for bitcoin-development@lists.sourceforge.net;
Wed, 09 Apr 2014 15:41:58 +0000
Received: by mail-wg0-f44.google.com with SMTP id m15so2672240wgh.27
for <bitcoin-development@lists.sourceforge.net>;
Wed, 09 Apr 2014 08:41:51 -0700 (PDT)
X-Received: by 10.180.80.232 with SMTP id u8mr4771628wix.13.1397058111487;
Wed, 09 Apr 2014 08:41:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.54.34 with HTTP; Wed, 9 Apr 2014 08:41:31 -0700 (PDT)
In-Reply-To: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com>
References: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Wed, 9 Apr 2014 17:41:31 +0200
Message-ID: <CAAt2M18z_Qkqat1OETiXAz0QQey4+y5J6=pC7nkoJfyfrpj3=A@mail.gmail.com>
To: Wladimir <laanwj@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1WXudR-0004pK-Mn
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: Wed, 09 Apr 2014 15:41:58 -0000
This could probably be done fairly easily by bundling Stratum (it's
not just for pools!) and allowing SPV wallets to ask Bitcoind to start
it (if you don't use it, there's no need to waste the resources), and
then connect to it. The point of using Stratum is that it already is
being used by Electrum, and that it might be an easier way to support
SPV clients than creating a new API in bitcoind for it since Stratum
itself already relies on bitcoind to provide it's services.
On Wed, Apr 9, 2014 at 5:29 PM, Wladimir <laanwj@gmail.com> wrote:
> Hello,
>
> This is primarily aimed at developers of SPV wallets.
>
> The recently reported decrease in number of full nodes could have several
> reasons, one of them that less people are running Bitcoin Core for the
> wallet because the other wallets are getting ahead in both features and
> useability.
>
> It's great to see innovation in wallets, but it's worrying that the number
> of full nodes decreases.
>
> It may be that lots of people would support the network by running a full
> node, but don't want to go through the trouble of installing bitcoin core
> separately (and get confused because it's a wallet, too).
>
> Hence I'd like to explore the idea of adding an option to popular SPV
> wallets, to spin a bitcoind process in the background. This could be pretty
> much transparent to the user - it would sync in the background, the wallet
> could show statistics about the node, but is not dependent on it.
>
> In exchange the user would get increased (full node level) security, as the
> SPV wallet would have a local trusted node.
>
> Does this sound like a good idea?
>
> Is there any way that Bitcoin Core can help to accomedate this 'embedded'
> usage? Specific Interfaces, special builds - maybe add a walletless bitcoind
> build to gitian - bindings, dlls, etc?
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
