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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1WzQvH-0003zU-4f
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Jun 2014 13:38:07 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.171 as permitted sender)
client-ip=209.85.213.171; envelope-from=pieter.wuille@gmail.com;
helo=mail-ig0-f171.google.com;
Received: from mail-ig0-f171.google.com ([209.85.213.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WzQvF-00027j-F6
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Jun 2014 13:38:07 +0000
Received: by mail-ig0-f171.google.com with SMTP id h18so4719790igc.16
for <bitcoin-development@lists.sourceforge.net>;
Tue, 24 Jun 2014 06:37:59 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.66.208 with SMTP id h16mr2072645igt.19.1403617079616;
Tue, 24 Jun 2014 06:37:59 -0700 (PDT)
Received: by 10.50.161.137 with HTTP; Tue, 24 Jun 2014 06:37:59 -0700 (PDT)
In-Reply-To: <CAC1+kJPJKwS+ydKO-HTNg8bb93mXEs8Hexycw9E9Fbv_sAQXoA@mail.gmail.com>
References: <CAC1+kJNjcPkaHiR8mzofwXE4+4UX5nmxX5Q3rZv37v-K40p1Tw@mail.gmail.com>
<CA+s+GJDVBQVu8yH9jLu_rQmk=dsJuMUctT-iK0zzOJRYgE8k9w@mail.gmail.com>
<CAC1+kJOQ2uBo2peYKZJyPSQL6qzk6Yu-cF-tPs3GzVS6cAc53w@mail.gmail.com>
<CANEZrP1bNs4ahMzd7AfSH3P39Cx1rkmCkjnOMOM9T2Anr5wVOw@mail.gmail.com>
<CAC1+kJMn3p5H6A8GGiuF56d411zC4qsTomuy7A5e0+OQT78FGQ@mail.gmail.com>
<F8592D15-B751-4DD9-A573-6373934C8D44@bitsofproof.com>
<CAC1+kJPJKwS+ydKO-HTNg8bb93mXEs8Hexycw9E9Fbv_sAQXoA@mail.gmail.com>
Date: Tue, 24 Jun 2014 15:37:59 +0200
Message-ID: <CAPg+sBh_5nF3mxgb72bVtS4Ua=jq+fN_uRv+s=Vmmweo4ohR1w@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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
(pieter.wuille[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: 1WzQvF-00027j-F6
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Plans to separate wallet from core
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: Tue, 24 Jun 2014 13:38:07 -0000
I'd like to point out that there is quite a difference between "what
core nodes should be like" and "what the codebase core nodes are built
from must support".
Given sufficiently modularized code (which I think everyone seems to
be in favor of, regardless of the goals), you can likely build a
binary that does full verification and maintains some indexes of some
sort.
I still believe that what we push for to run as the core nodes of the
network should aim for purely verification and relay, and nothing
else, but people can and will do things differently if the source code
allows it. And that's fine.
On Tue, Jun 24, 2014 at 3:26 PM, Jorge Tim=F3n <jtimon@monetize.io> wrote:
> I think this is my main question, what's the advantage of having the
> processes talking via the p2p protocol instead of something more
> direct when you control both processes?
IMHO, maintaining a correct view of the current state of the chain
(excluding blocks, just headers) is already sufficiently hard (I hope
that everyone who ever implemented an SPV wallet can agree). You
simplify things a bit by not needing to verify what the peer claims if
you trust them, but not much. You still need to support
reorganizations, counting confirmations, making sure you stay
up-to-date. These are functions the (SPV) P2P protocol has already
shown to do well, and there are several codebases out there that
implement it. No need to reinvent the wheel with a marginally more
efficient protocol, if it means starting over everything else.
--=20
Pieter
|
