public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@monetize.io>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Plans to separate wallet from core
Date: Tue, 24 Jun 2014 13:29:28 +0200	[thread overview]
Message-ID: <CAC1+kJMn3p5H6A8GGiuF56d411zC4qsTomuy7A5e0+OQT78FGQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP1bNs4ahMzd7AfSH3P39Cx1rkmCkjnOMOM9T2Anr5wVOw@mail.gmail.com>

On 6/24/14, Mike Hearn <mike@plan99.net> wrote:
> bitcoind already supports SPV mode, that's how bitcoinj clients work.
> However the current wallet code doesn't use it, it integrates directly with
> the full mode main loop and doesn't talk P2P internally. Which is the fine
> and obvious way to implement the wallet feature. I'm not totally convinced
> it should become an SPV wallet given the complexity of doing that. But if
> you did want to separate the wallet code from the full node then that'd be
> the way to do it.
>
> The question is; what does this buy us, and is it worth the potentially
> huge amount of time it could take? My gut feeling is we have bigger fish to
> fry. There's plenty of work to do just on the core consensus code, making
> Bitcoin Core into a competitive wallet as well would be an additional
> burden.

Exactly, this is part of my point, the qt-wallet does not support SPV
operation at this point, and that complex work should be done after
the wallet is separated. Thus the first version of the separated
wallet should be functionally equivalent to today's wallet, that is, a
full node wallet (even though I understand Wladimir's arguments
against full-node wallets).

>> I'm sorry, but I still don't know what Electrum has to do with all this.
>>
>
> People use Electrum as shorthand to mean "something a bit like the P2P
> network, but with trusted remote servers which build additional databases
> and thus support additional commands".

Ok, thanks. So a bitcoin core node which maintains and serves
additional indexes (say, an utxo index via rpc or something else) is
referred to as "an electrum" even though it doesn't use
electrum-server. Strange, but now I get it.

So in summary:

1) I accept the library approach over the "core-wallet protocol".

2) That doesn't necessarily mean that optionally maintaining
additional indexes in the core is not interesting for some use cases
(interesting for bitcoind, I don't care much if electrum-server
currently does this and more [with more dependencies]). Although
Pieter thinks that should also be separated into an "index node" too,
but I think that's another discussion.

3) The wallet doesn't currently operate as SPV and that work should be
done (if there's enough interest) only after the wallet is separated
from the core.



  parent reply	other threads:[~2014-06-24 11:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23  9:50 [Bitcoin-development] Plans to separate wallet from core 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 [this message]
2014-06-24 11:48         ` Tamas Blummer
2014-06-24 13:26           ` Jorge Timón
2014-06-24 13:37             ` Pieter Wuille
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=CAC1+kJMn3p5H6A8GGiuF56d411zC4qsTomuy7A5e0+OQT78FGQ@mail.gmail.com \
    --to=jtimon@monetize.io \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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