Wladimir [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-24 📝 Original message:On Mon, Jun 23, 2014 at ...
📅 Original date posted:2014-06-24
📝 Original message:On Mon, Jun 23, 2014 at 10:15 PM, Jorge Timón <jtimon at monetize.io> wrote:
> On 6/23/14, Wladimir <laanwj at gmail.com> 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 wallet share any code (say, the p2p messages via
> a sub-repo or something)?
Yes, they will share code. At least the basic data structures and
serialization and deserialization. Probably also part of the network
code and utilities like argument parsing (although that's not a hard
requirement - it may be an opportunity to do things better).
So part of Bitcoin Core will have to be turned into a library or
libraries. Movement toward this is already in progress for a while.
>> There could be a mode to use a trusted core by RPC for
>> mempool/conflicted transaction validation and such. But I'm not sure
>> about this - as we've seen, pure-SPV wallets work pretty well. If you
>> want it to act as an edge router you can point a SPV wallet at your
>> trusted core as well.
>
> I thought we would first separate wallet from core (maintaining the
> full-node wallet status) and then implement an optional SPV mode for
> the core (and transitively for "qt-wallet", which would support both
> full and SPV mode).
We want to move away from "full node wallets". In the beginning it
made some sense to jump-start the network, but the more the chain
grows the less unwieldy they become.
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 want to check for them.
- A full node should be online 24/7 or it is virtually useless to the network.
>> There are no plans for adding Electrum-like functionality to bitcoind.
>> There is already Electrum. Let's not reinvent any wheels.
>
> I'm sorry, but I still don't know what Electrum has to do with all this.
I suggest you look at the interface for Electrum. It probably does
exactly what you expected the interface between the Bitcoin Core
wallet and Bitcoin Core to become. Electrum server keeps some extra
indices that can be queried by the wallets. It already exists!
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?
(As said - I'm fine with optional close binding to a core using RPC
with slight security benefits like utxo queries and conflicted
transaction checking, and to get the dynamic fee data, but it should
not be required)
>> It does not need to keep a full chain database. But it needs its own
>> record of the chain, headers-only + what concerns the keys in the
>> wallet.
>
> Why cannot consume that data from a bitcoind node that always run alongside it?
To not require having a bitcoind node always running alongside it.
Wladimir
Published at
2023-06-07 15:23:11Event JSON
{
"id": "96659c2140afd19e023049adb5b462ac2356483698c01471220a3d6fa73c7793",
"pubkey": "30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722",
"created_at": 1686151391,
"kind": 1,
"tags": [
[
"e",
"70c0fbbfb361e1a5e33121959a54368ef9bf960fb4424bf0b260b1c5f505777b",
"",
"root"
],
[
"e",
"8ad7d301289a8ddc962874d33abed71e82a1ce5ff755424a53776f038caef914",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2014-06-24\n📝 Original message:On Mon, Jun 23, 2014 at 10:15 PM, Jorge Timón \u003cjtimon at monetize.io\u003e wrote:\n\u003e On 6/23/14, Wladimir \u003claanwj at gmail.com\u003e wrote:\n\u003e\u003e It's least surprising if the wallet works as a SPV client by default.\n\u003e\u003e Then, users can use it without first setting up a core. Thus the idea\n\u003e\u003e would be to use P2P primarily.\n\u003e\n\u003e So first bitcoind will support SPV mode then we separate the wallet?\n\u003e Are the core and the wallet share any code (say, the p2p messages via\n\u003e a sub-repo or something)?\n\nYes, they will share code. At least the basic data structures and\nserialization and deserialization. Probably also part of the network\ncode and utilities like argument parsing (although that's not a hard\nrequirement - it may be an opportunity to do things better).\n\nSo part of Bitcoin Core will have to be turned into a library or\nlibraries. Movement toward this is already in progress for a while.\n\n\u003e\u003e There could be a mode to use a trusted core by RPC for\n\u003e\u003e mempool/conflicted transaction validation and such. But I'm not sure\n\u003e\u003e about this - as we've seen, pure-SPV wallets work pretty well. If you\n\u003e\u003e want it to act as an edge router you can point a SPV wallet at your\n\u003e\u003e trusted core as well.\n\u003e\n\u003e I thought we would first separate wallet from core (maintaining the\n\u003e full-node wallet status) and then implement an optional SPV mode for\n\u003e the core (and transitively for \"qt-wallet\", which would support both\n\u003e full and SPV mode).\n\nWe want to move away from \"full node wallets\". In the beginning it\nmade some sense to jump-start the network, but the more the chain\ngrows the less unwieldy they become.\n\nMy main argument for the split is that full nodes and wallets have\ncompletely different usage scenarios:\n\n- A wallet should be online as little as possible, ideally only when\nyou do transactions or want to check for them.\n\n- A full node should be online 24/7 or it is virtually useless to the network.\n\n\u003e\u003e There are no plans for adding Electrum-like functionality to bitcoind.\n\u003e\u003e There is already Electrum. Let's not reinvent any wheels.\n\u003e\n\u003e I'm sorry, but I still don't know what Electrum has to do with all this.\n\nI suggest you look at the interface for Electrum. It probably does\nexactly what you expected the interface between the Bitcoin Core\nwallet and Bitcoin Core to become. Electrum server keeps some extra\nindices that can be queried by the wallets. It already exists!\n\nBut IMO this is a passed stage. SPV wallets w/ Bloom filtering can\nwork without any special servers, so why require a 'close binding' to\na trusted bitcoin core?\n\n(As said - I'm fine with optional close binding to a core using RPC\nwith slight security benefits like utxo queries and conflicted\ntransaction checking, and to get the dynamic fee data, but it should\nnot be required)\n\n\u003e\u003e It does not need to keep a full chain database. But it needs its own\n\u003e\u003e record of the chain, headers-only + what concerns the keys in the\n\u003e\u003e wallet.\n\u003e\n\u003e Why cannot consume that data from a bitcoind node that always run alongside it?\n\nTo not require having a bitcoind node always running alongside it.\n\nWladimir",
"sig": "52d9adc14d5ee291ed4aa79c96a11e2c195b770f4397707c697c641657500e34ab94a2b74a2d8db596f546eb2c7ebb428bec58c06e7487fd5efa7c4e7d4954aa"
}