📅 Original date posted:2014-04-09
📝 Original message:Le 09/04/2014 17:54, Gregory Maxwell a écrit :
> Sadly today Electrum requires more than a full node, it requires a
> number of large additional indexes over what a full node has and
> pruning is precluded. I don't think that increasing the resource
> utilization of the node is a good way to go there for the purposes
> expressed here. (not that electrum couldn't be used here, but not
> unmodified without the resource usage increasing route)
>
Electrum uses two large indexes:
address -> utxo
(patricia tree, aka "ultimate blockchain compression", see thread
started by Alan Reiner in the bitcointalk forum)
address -> spent history
The first index is not going to grow larger than what bitcoind already
needs to store, because bitcoind will always need to store utxos.
The second index threatens to become large. However, Electrum servers do
not keep the full histories, they prune older entries. Without adapting
Electrum clients, it would even be possible to keep only one bit per
address (to know whether that address has been used or not), and that
information is only used to restore wallets from seed, not during normal
operations.
If the first index (patricia tree) was implemented in bitcoind, that
would obviously be a big relief for electrum servers.
>> and that it might be an easier way to support
>> SPV clients than creating a new API in bitcoind for it since Stratum
>> itself already relies on bitcoind to provide it's services.
>
> Bitcoin's own P2P protocol is already the API for a ordinary SPV
> client. So I don't believe any new API would be require, except
> perhaps for some process management stuff (which also isn't provided
> for Electrum).
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
Thomas Voegtlin [ARCHIVE] /
npub10f…7ej47
2023-06-07 15:18:10
in reply to nevent1q…078s
Author Public Key
npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47Published at
2023-06-07 15:18:10Event JSON
{
"id": "24f1cbdcfd7da569377c84a2487edb0db262a25d9929f506b231448a1ccb4b7a",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686151090,
"kind": 1,
"tags": [
[
"e",
"ed99a8ad47eb2c18db74cd3bd79e8fcc6fa95e61654848c6ab9c5bb9f7a7e8bf",
"",
"root"
],
[
"e",
"0ad4502f23cf052c512a8cec3855dbac1a6a28008c2122b4c29713ee22f41967",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-04-09\n📝 Original message:Le 09/04/2014 17:54, Gregory Maxwell a écrit :\n\n\u003e Sadly today Electrum requires more than a full node, it requires a\n\u003e number of large additional indexes over what a full node has and\n\u003e pruning is precluded. I don't think that increasing the resource\n\u003e utilization of the node is a good way to go there for the purposes\n\u003e expressed here. (not that electrum couldn't be used here, but not\n\u003e unmodified without the resource usage increasing route)\n\u003e\n\nElectrum uses two large indexes:\n\n address -\u003e utxo\n\n(patricia tree, aka \"ultimate blockchain compression\", see thread \nstarted by Alan Reiner in the bitcointalk forum)\n\n address -\u003e spent history\n\nThe first index is not going to grow larger than what bitcoind already \nneeds to store, because bitcoind will always need to store utxos.\n\nThe second index threatens to become large. However, Electrum servers do \nnot keep the full histories, they prune older entries. Without adapting \nElectrum clients, it would even be possible to keep only one bit per \naddress (to know whether that address has been used or not), and that \ninformation is only used to restore wallets from seed, not during normal \noperations.\n\nIf the first index (patricia tree) was implemented in bitcoind, that \nwould obviously be a big relief for electrum servers.\n\n\n\n\u003e\u003e and that it might be an easier way to support\n\u003e\u003e SPV clients than creating a new API in bitcoind for it since Stratum\n\u003e\u003e itself already relies on bitcoind to provide it's services.\n\u003e\n\u003e Bitcoin's own P2P protocol is already the API for a ordinary SPV\n\u003e client. So I don't believe any new API would be require, except\n\u003e perhaps for some process management stuff (which also isn't provided\n\u003e for Electrum).\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Put Bad Developers to Shame\n\u003e Dominate Development with Jenkins Continuous Integration\n\u003e Continuously Automate Build, Test \u0026 Deployment\n\u003e Start a new project now. Try Jenkins in the cloud.\n\u003e http://p.sf.net/sfu/13600_Cloudbees\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e",
"sig": "a37f7c6d6d887dd4ffd86d7befc0c07dde2c2155f05e2ef42d5532688e487ee2c9cc87319a164cf05a8a12db5bbc348734e69733a61cd3db2a0585d8595578c7"
}