📅 Original date posted:2014-06-24
📝 Original message:On Tue, Jun 24, 2014 at 1:29 PM, Jorge Timón <jtimon at monetize.io> wrote:
> On 6/24/14, Mike Hearn <mike at plan99.net> 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 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).
Do mind that some of the steps on the path of bitcoind towards SPV are
also useful in general. For example, headers-first allows parallel
block download, which would solve a lot of sync issues people are
having - a much higher priority than the wallet.
But anyhow I'm describing how I would do it. If you're going to do it,
you can do it in any order that you want. As we're talking about a
separate project here it's not even clear who will be maintainer.
> 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.
I don't understand your argument against Electrum here. Dependencies?
Come on, that's a matter of software distribution. If that really
bothers you I suppose you could contribute to Electrum server so that
it has less deps. It doesn't make the protocol worth any less.
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 different animal.
Wladimir
Wladimir [ARCHIVE] /
npub1xq…ymc2p
2023-06-07 15:23:14
in reply to nevent1q…kzsk
Author Public Key
npub1xqshkqv2g7uea4xzqwvmgjcz7u8vfavw6aazs999v0azsv3w7u3qpymc2pPublished at
2023-06-07 15:23:14Event JSON
{
"id": "0675733a5ef428c6a05a43ba54cacdec515c7daaac9ef2c8fda16ed4a7e2252b",
"pubkey": "30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722",
"created_at": 1686151394,
"kind": 1,
"tags": [
[
"e",
"70c0fbbfb361e1a5e33121959a54368ef9bf960fb4424bf0b260b1c5f505777b",
"",
"root"
],
[
"e",
"13d2bedb8c3fd69266971c2140f017799be6d2235bf2e6d4e142fe19d3318361",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2014-06-24\n📝 Original message:On Tue, Jun 24, 2014 at 1:29 PM, Jorge Timón \u003cjtimon at monetize.io\u003e wrote:\n\u003e On 6/24/14, Mike Hearn \u003cmike at plan99.net\u003e wrote:\nou did want to separate the wallet code from the full node then that'd be\n\u003e\u003e the way to do it.\n\u003e\n\u003e Exactly, this is part of my point, the qt-wallet does not support SPV\n\u003e operation at this point, and that complex work should be done after\n\u003e the wallet is separated. Thus the first version of the separated\n\u003e wallet should be functionally equivalent to today's wallet, that is, a\n\u003e full node wallet (even though I understand Wladimir's arguments\n\u003e against full-node wallets).\n\nDo mind that some of the steps on the path of bitcoind towards SPV are\nalso useful in general. For example, headers-first allows parallel\nblock download, which would solve a lot of sync issues people are\nhaving - a much higher priority than the wallet.\n\nBut anyhow I'm describing how I would do it. If you're going to do it,\nyou can do it in any order that you want. As we're talking about a\nseparate project here it's not even clear who will be maintainer.\n\n\u003e 2) That doesn't necessarily mean that optionally maintaining\n\u003e additional indexes in the core is not interesting for some use cases\n\u003e (interesting for bitcoind, I don't care much if electrum-server\n\u003e currently does this and more [with more dependencies]). Although\n\u003e Pieter thinks that should also be separated into an \"index node\" too,\n\u003e but I think that's another discussion.\n\nI don't understand your argument against Electrum here. Dependencies?\nCome on, that's a matter of software distribution. If that really\nbothers you I suppose you could contribute to Electrum server so that\nit has less deps. It doesn't make the protocol worth any less.\n\nAlthough Pieter and I disagree with regard to issue #4351, we agree on\nwanting to keep (or at least making) bitcoind as lean as possible.\nMaintaining extra indices for others doesn't fit in there - that's\nalso why the address index patch was not merged. An 'index node' could\nbe a different animal.\n\nWladimir",
"sig": "591c5c62c27d9b5cda0c3bba97d6901c0f806cd7e2ca793b59b165641226e03e914829d24146951192a4d0749368dadaca315637d1d0dd6ff2184e6fcc302d1c"
}