Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-09 📝 Original message:On Wed, Apr 9, 2014 at ...
📅 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).
📝 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).