On Tue, Jun 24, 2014 at 6:40 PM, Jorge Timón wrote:
>
> I think he means that the wallet shouldn't be running as much as it is
> currently doing.
> But yes, I think you're right about wallets and GUIs not necessarily
> mapping 1:1.
I haven't been talking about the GUI at all in this entire
conver
On 6/24/14, Justus Ranvier wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/24/2014 09:07 AM, Wladimir wrote:
>> My main argument for the split is that full nodes and wallets have
>> completely different usage scenarios:
>>
>> - A wallet should be online as little as possible, id
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/24/2014 09:07 AM, Wladimir wrote:
> My main argument for the split is that full nodes and wallets have
> completely different usage scenarios:
>
> - A wallet should be online as little as possible, ideally only
> when you do transactions or wan
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
bina
On 6/24/14, Tamas Blummer wrote:
> 3. Services e.g. exchange, payment processor This is where core +
> indexing server talking SPV to core is the right choice
I think this is my main question, what's the advantage of having the
processes talking via the p2p protocol instead of something more
Le 24/06/2014 11:44, Wladimir a écrit :
>> But IMO this is a passed stage. SPV wallets w/ Bloom filtering can
>> work without any special servers, so why require a 'close binding' to
>> a trusted bitcoin core?
>
> To clarify (and not piss off ThomasV :-): I do not think the idea of
> having serv
On Tue, Jun 24, 2014 at 2:16 PM, Mike Hearn wrote:
> priority. So a single unified program that just figures it out automatically
> rather than expecting users to assemble a bag of parts seems a goal worth
> striving for.
As I've said before -- and I think we disagree here - I like moving
towards
>
> Although Pieter and I disagree with regard to issue #4351, we agree on
> wanting to keep (or at least making) bitcoind as lean as possible.
> Maintaining extra indices for others doesn't fit in there - that's
> also why the address index patch was not merged. An 'index node' could
> be a differ
I think there are three typical uses:
1. Building consensus on the block chain. This is what the core is for.
2. Single user wallets. This is where SPV alone is good.
3. Services e.g. exchange, payment processor This is where core + indexing
server talking SPV to core is the right choice
Re
On Tue, Jun 24, 2014 at 1:29 PM, Jorge Timón wrote:
> On 6/24/14, Mike Hearn wrote:
ou did want to separate the wallet code from the full node then that'd be
>> the way to do it.
>
> Exactly, this is part of my point, the qt-wallet does not support SPV
> operation at this point, and that complex
On 6/24/14, Mike Hearn 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
>
> From my experience the main thing people are missing with BitcoinJ is
> a quick and easy way to set up a wallet as a daemon, to use the
> functionality from non-java through RPC.
Yes. I'd love to have a mostly Core compatible JSON-RPC frontend. Most of
my current users are happy using it as a
> But IMO this is a passed stage. SPV wallets w/ Bloom filtering can
> work without any special servers, so why require a 'close binding' to
> a trusted bitcoin core?
To clarify (and not piss off ThomasV :-): I do not think the idea of
having servers with a reputation of their own is a passed stag
> 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
>
> So first bitcoind will support SPV mode then we separate the wallet?
> Are the core and the wallet share any code (say, the p2p messages via
> a sub-repo or something)?
>
bitcoind already supports SPV mode, that's how bitcoinj clients work.
However the current wallet code doesn't use it, it in
On Mon, Jun 23, 2014 at 10:15 PM, Jorge Timón wrote:
> On 6/23/14, Wladimir wrote:
>> It's least surprising if the wallet works as a SPV client by default.
>> Then, users can use it without first setting up a core. Thus the idea
>> would be to use P2P primarily.
>
> So first bitcoind will support
On 6/23/14, Wladimir wrote:
> It's least surprising if the wallet works as a SPV client by default.
> Then, users can use it without first setting up a core. Thus the idea
> would be to use P2P primarily.
So first bitcoind will support SPV mode then we separate the wallet?
Are the core and the wa
On Mon, Jun 23, 2014 at 11:50 AM, Jorge Timón wrote:
> I know there are plans to separate the wallet from the core code and I
> think it's a great idea that will result in cleaner and more modular
> software.
> But it seems like my assumptions on how this would be done may be incorrect.
>
> I was
I know there are plans to separate the wallet from the core code and I
think it's a great idea that will result in cleaner and more modular
software.
But it seems like my assumptions on how this would be done may be incorrect.
I was assuming that the wallet would consume data from a trusted
bitcoi
19 matches
Mail list logo
