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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1WY8pD-0002lx-EN
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Apr 2014 06:51:03 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.178 as permitted sender)
client-ip=209.85.213.178; envelope-from=laanwj@gmail.com;
helo=mail-ig0-f178.google.com;
Received: from mail-ig0-f178.google.com ([209.85.213.178])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WY8pB-0003p3-F0
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Apr 2014 06:51:03 +0000
Received: by mail-ig0-f178.google.com with SMTP id hn18so3404265igb.11
for <bitcoin-development@lists.sourceforge.net>;
Wed, 09 Apr 2014 23:50:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.122.8 with SMTP id lo8mr8824831igb.31.1397112656103; Wed,
09 Apr 2014 23:50:56 -0700 (PDT)
Received: by 10.64.70.131 with HTTP; Wed, 9 Apr 2014 23:50:55 -0700 (PDT)
In-Reply-To: <CANEZrP2w2b28qnYd7q=fo=VL0FzVE1R15s5Entuy+fK9x+V8Kg@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>
<CANEZrP2w2b28qnYd7q=fo=VL0FzVE1R15s5Entuy+fK9x+V8Kg@mail.gmail.com>
Date: Thu, 10 Apr 2014 08:50:55 +0200
Message-ID: <CA+s+GJDcGxa_ARPFAbsd54cFhgBn8WcqNrRs00TZJBrNmvq5jQ@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e015384fe94116b04f6aaa354
X-Spam-Score: -0.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
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1WY8pB-0003p3-F0
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 06:51:03 -0000
--089e015384fe94116b04f6aaa354
Content-Type: text/plain; charset=UTF-8
On Thu, Apr 10, 2014 at 8:38 AM, Mike Hearn <mike@plan99.net> wrote:
> I tend to agree with slush here - counting the IPs in addr broadcasts
> often gives a number like 100,000 vs just 10,000 for actually reachable
> nodes (or less). It seems like optimising the NAT tunneling code would
> help. Starting by adding more diagnostic stuff to the GUI. STUN support may
> also help.
>
> The main constraint with home devices is not IMHO their actual power but
> rather that a lot of people no longer keep computers switched on all the
> time. If you don't do that then spv with bundled Core can't help your
> security because the spv wallet would always be syncing from the p2p
> network for performance reasons.
>
I agree that there is a fundamental incompatibility in usage between
wallets and nodes. Wallets need to be online as little as possible, nodes
need to online as much as possible.
However, a full node background process could also be running if the wallet
is not open itself. Ffor example - by running as a system service.
Bitcoin Core's own wallet is also moving to SPV, so this means a general
solution is needed to get people to run a node when the wallet is not
running.
Maybe the node shouldn't be controlled from the wallet at all, it could be
a 'node control' user interface on its own (this is what -disablewallet
does currently). In this case, there is no need for packaging it with a
wallet The only drawback would be that initially, people wouldn't know why
or when to install this, hence my suggestion to pack it with wallets...
Wladimir
--089e015384fe94116b04f6aaa354
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">On T=
hu, Apr 10, 2014 at 8:38 AM, Mike Hearn <span dir=3D"ltr"><<a href=3D"ma=
ilto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir=3D"ltr">I tend to agree with slush here - counting the IPs in addr b=
roadcasts often gives a number like 100,000 vs just 10,000 for actually rea=
chable nodes (or less). It seems like optimising the NAT tunneling code wou=
ld help. Starting by adding more diagnostic stuff to the GUI. STUN support =
may also help.</p>
<p dir=3D"ltr">The main constraint with home devices is not IMHO their actu=
al power but rather that a lot of people no longer keep computers switched =
on all the time. If you don't do that then spv with bundled Core can=
9;t help your security because the spv wallet would always be syncing from =
the p2p network for performance reasons.</p>
</blockquote><div>I agree that there is a fundamental incompatibility in us=
age between wallets and nodes. Wallets need to be online as little as possi=
ble, nodes need to online as much as possible.<br><br>However, a full node =
background process could also be running if the wallet is not open itself. =
Ffor example - by running as a system service.<br>
=C2=A0<br></div><div>Bitcoin Core's own wallet is also moving to SPV, s=
o this means a general solution is needed to get people to run a node when =
the wallet is not running.<br><br></div><div>Maybe the node shouldn't b=
e controlled from the wallet at all, it could be a 'node control' u=
ser interface on its own (this is what -disablewallet does currently). In t=
his case, there is no need for packaging it with a wallet The only drawback=
would be that initially, people wouldn't know why or when to install t=
his, hence my suggestion to pack it with wallets...<br>
</div><div><br>Wladimir<br></div></div><br></div></div>
--089e015384fe94116b04f6aaa354--
|
