Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-24 📝 Original message:On 6/24/14, Mike Hearn ...
📅 Original date posted:2014-06-24
📝 Original message:On 6/24/14, Mike Hearn <mike at 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.
📝 Original message:On 6/24/14, Mike Hearn <mike at 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.