From: Pieter Wuille <pieter.wuille@gmail•com>
To: "Jorge Timón" <jtimon@monetize•io>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Plans to separate wallet from core
Date: Tue, 24 Jun 2014 15:37:59 +0200 [thread overview]
Message-ID: <CAPg+sBh_5nF3mxgb72bVtS4Ua=jq+fN_uRv+s=Vmmweo4ohR1w@mail.gmail.com> (raw)
In-Reply-To: <CAC1+kJPJKwS+ydKO-HTNg8bb93mXEs8Hexycw9E9Fbv_sAQXoA@mail.gmail.com>
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ón <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.
--
Pieter
next prev parent reply other threads:[~2014-06-24 13:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-23 9:50 Jorge Timón
2014-06-23 10:32 ` Wladimir
2014-06-23 20:15 ` Jorge Timón
2014-06-24 9:07 ` Wladimir
2014-06-24 9:44 ` Wladimir
2014-06-24 13:24 ` Thomas Voegtlin
2014-06-24 15:33 ` Justus Ranvier
2014-06-24 16:40 ` Jorge Timón
2014-06-25 5:43 ` Wladimir
2014-06-24 9:11 ` Mike Hearn
2014-06-24 9:40 ` Wladimir
2014-06-24 10:12 ` Mike Hearn
2014-06-24 11:29 ` Jorge Timón
2014-06-24 11:48 ` Tamas Blummer
2014-06-24 13:26 ` Jorge Timón
2014-06-24 13:37 ` Pieter Wuille [this message]
2014-06-24 11:58 ` Wladimir
2014-06-24 12:16 ` Mike Hearn
2014-06-24 12:41 ` Wladimir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPg+sBh_5nF3mxgb72bVtS4Ua=jq+fN_uRv+s=Vmmweo4ohR1w@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jtimon@monetize$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox