rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2014-04-09 📝 Original message:On Wed, Apr 9, 2014 at 8:41 AM, Natanael <natanael.l at gmail.com> wrote: > This could probably be done fairly easily by bundling Stratum (it's > not just for pools!) and allowing SPV wallets to ask Bitcoind to start > it (if you don't use it, there's no need to waste the resources), and > then connect to it. The point of using Stratum is that it already is > being used by Electrum, 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) > 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).