📅 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.
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 15:23:13
in reply to nevent1q…0mch
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 15:23:13Event JSON
{
"id": "c0c3f4a1d4da58515a067c733d6f3849cc37a15b30283a6dad72fc552743fc14",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686151393,
"kind": 1,
"tags": [
[
"e",
"70c0fbbfb361e1a5e33121959a54368ef9bf960fb4424bf0b260b1c5f505777b",
"",
"root"
],
[
"e",
"72295838111e3df35e545acc3bda61a8f0ba603682981550133d4c058d0f3936",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-06-24\n📝 Original message:On 6/24/14, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e bitcoind already supports SPV mode, that's how bitcoinj clients work.\n\u003e However the current wallet code doesn't use it, it integrates directly with\n\u003e the full mode main loop and doesn't talk P2P internally. Which is the fine\n\u003e and obvious way to implement the wallet feature. I'm not totally convinced\n\u003e it should become an SPV wallet given the complexity of doing that. But if\n\u003e you did want to separate the wallet code from the full node then that'd be\n\u003e the way to do it.\n\u003e\n\u003e The question is; what does this buy us, and is it worth the potentially\n\u003e huge amount of time it could take? My gut feeling is we have bigger fish to\n\u003e fry. There's plenty of work to do just on the core consensus code, making\n\u003e Bitcoin Core into a competitive wallet as well would be an additional\n\u003e burden.\n\nExactly, this is part of my point, the qt-wallet does not support SPV\noperation at this point, and that complex work should be done after\nthe wallet is separated. Thus the first version of the separated\nwallet should be functionally equivalent to today's wallet, that is, a\nfull node wallet (even though I understand Wladimir's arguments\nagainst full-node wallets).\n\n\u003e\u003e I'm sorry, but I still don't know what Electrum has to do with all this.\n\u003e\u003e\n\u003e\n\u003e People use Electrum as shorthand to mean \"something a bit like the P2P\n\u003e network, but with trusted remote servers which build additional databases\n\u003e and thus support additional commands\".\n\nOk, thanks. So a bitcoin core node which maintains and serves\nadditional indexes (say, an utxo index via rpc or something else) is\nreferred to as \"an electrum\" even though it doesn't use\nelectrum-server. Strange, but now I get it.\n\nSo in summary:\n\n1) I accept the library approach over the \"core-wallet protocol\".\n\n2) That doesn't necessarily mean that optionally maintaining\nadditional indexes in the core is not interesting for some use cases\n(interesting for bitcoind, I don't care much if electrum-server\ncurrently does this and more [with more dependencies]). Although\nPieter thinks that should also be separated into an \"index node\" too,\nbut I think that's another discussion.\n\n3) The wallet doesn't currently operate as SPV and that work should be\ndone (if there's enough interest) only after the wallet is separated\nfrom the core.",
"sig": "e5211270152805c60d2b6fc2f1351471252fd0b9d8a9a0822d849984d40bd056829d81c48a2b19d8fe56665728c390757c5ea3094026f6d948bf1f501030dcae"
}