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 ) 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 ; 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: References: Date: Tue, 24 Jun 2014 15:37:59 +0200 Message-ID: From: Pieter Wuille To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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