Topic: Electrum Server Gateways (Read 575 times)
Is it possible to use EPS as a lightning watchtower?
If you use Electrum Personal Server and send transactions, please help test the new Tor broadcasting feature which improves privacy
https://github.com/chris-belcher/electrum-personal-server/issues/130
https://github.com/chris-belcher/electrum-personal-server/issues/130
Beta version released: https://github.com/chris-belcher/electrum-personal-server
Includes all the features required for this to be used practically: Merkle proofs, deterministic wallets, bech32 addresses, SSL, Core's multi-wallet support.
I've been using this with my mainnet wallets and its very very lightweight. A small python script that's nothing compared to the full node it connects to.
Includes all the features required for this to be used practically: Merkle proofs, deterministic wallets, bech32 addresses, SSL, Core's multi-wallet support.
I've been using this with my mainnet wallets and its very very lightweight. A small python script that's nothing compared to the full node it connects to.
Nice concept. I don't like storing the wallet on the server tho. Also in some ways wouldn't this reduce anonymity? Transactions correlate wallets with a certain IP address every time...
It's called "server" only because it implements the Electrum server protocol. In practice you'd run it on your own hardware, generally in the same place where your full node runs so the anonymity would not be harmed in this respect.
OK, but then you're back to leaking your IP address again.
I don't see how. If you connect to something on localhost you don't leak the IP of your Electrum wallet.
But the IP of the "private server" is the same as the IP of the wallet if you're connecting to localhost?!
Yes, but the electrum personal server is connected to a full node so you get the same privacy as if you were using Bitcoin-Qt. Bitcoin-Qt can have very strong privacy properties in terms of IP addresses.
Nice concept. I don't like storing the wallet on the server tho. Also in some ways wouldn't this reduce anonymity? Transactions correlate wallets with a certain IP address every time...
It's called "server" only because it implements the Electrum server protocol. In practice you'd run it on your own hardware, generally in the same place where your full node runs so the anonymity would not be harmed in this respect.
OK, but then you're back to leaking your IP address again.
I don't see how. If you connect to something on localhost you don't leak the IP of your Electrum wallet.
But the IP of the "private server" is the same as the IP of the wallet if you're connecting to localhost?!
Nice concept. I don't like storing the wallet on the server tho. Also in some ways wouldn't this reduce anonymity? Transactions correlate wallets with a certain IP address every time...
It's called "server" only because it implements the Electrum server protocol. In practice you'd run it on your own hardware, generally in the same place where your full node runs so the anonymity would not be harmed in this respect.
OK, but then you're back to leaking your IP address again.
I don't see how. If you connect to something on localhost you don't leak the IP of your Electrum wallet.
Nice concept. I don't like storing the wallet on the server tho. Also in some ways wouldn't this reduce anonymity? Transactions correlate wallets with a certain IP address every time...
It's called "server" only because it implements the Electrum server protocol. In practice you'd run it on your own hardware, generally in the same place where your full node runs so the anonymity would not be harmed in this respect.
OK, but then you're back to leaking your IP address again.
Also from the README:
Electrum wallet must be configured to connect to the server. SSL must be disabled
Electrum wallet must be configured to connect to the server. SSL must be disabled
Pull requests welcome ¯\_(ツ)_/¯
All you have to do is read this page and figure out how to make the server socket be SSL. Since you're generally only connecting to localhost when using Electrum Personal Server, there's no privacy or security difference between SSL and non-SSL.
I agree there is no point in using SSL to connect with localhost.
Nice concept. I don't like storing the wallet on the server tho. Also in some ways wouldn't this reduce anonymity? Transactions correlate wallets with a certain IP address every time...
It's called "server" only because it implements the Electrum server protocol. In practice you'd run it on your own hardware, generally in the same place where your full node runs so the anonymity would not be harmed in this respect.
Also from the README:
Electrum wallet must be configured to connect to the server. SSL must be disabled
Electrum wallet must be configured to connect to the server. SSL must be disabled
Pull requests welcome ¯\_(ツ)_/¯
All you have to do is read this page and figure out how to make the server socket be SSL. Since you're generally only connecting to localhost when using Electrum Personal Server, there's no privacy or security difference between SSL and non-SSL.
This is regarding the concerns raised in the first post:
- Electrum downloads block headers from multiple servers to prevent any one server from tricking you.
- Electrum downloads block headers from multiple servers to prevent any one server from tricking you.
This doesn't remove the need for trust, it only spreads it out. As the saying goes: don't trust, verify.
- What you're calling a gateway is actually a proxy. There is one built into tails called tor proxy which routes your electrum connections over the high anonymity tor network. The Electrum that comes with tails is pre-configured to use that. If you install an updated version on Tails you can configure it to use tor proxy too (i believe you have to use tor proxy on tails). Go to tools > network > connection tab, check ssl, choose socks 5 as the proxy, enter localhost as the host and 9050 as the port.
Tails with tor only stops your IP address being revealed, but the bitcoin addresses in your wallet are still linked together, and so the spying Electrum server can see still everything you do.
Using a full node solves this privacy break because it downloads the entire blockchain and scans it locally for your own addresses, so any external observer watching your connections can't tell which bitcoin addresses are yours.
This is regarding the concerns raised in the first post:
- Electrum downloads block headers from multiple servers to prevent any one server from tricking you.
- What you're calling a gateway is actually a proxy. There is one built into tails called tor proxy which routes your electrum connections over the high anonymity tor network. The Electrum that comes with tails is pre-configured to use that. If you install an updated version on Tails you can configure it to use tor proxy too (i believe you have to use tor proxy on tails). Go to tools > network > connection tab, check ssl, choose socks 5 as the proxy, enter localhost as the host and 9050 as the port.
- Electrum downloads block headers from multiple servers to prevent any one server from tricking you.
- What you're calling a gateway is actually a proxy. There is one built into tails called tor proxy which routes your electrum connections over the high anonymity tor network. The Electrum that comes with tails is pre-configured to use that. If you install an updated version on Tails you can configure it to use tor proxy too (i believe you have to use tor proxy on tails). Go to tools > network > connection tab, check ssl, choose socks 5 as the proxy, enter localhost as the host and 9050 as the port.
Nice concept. I don't like storing the wallet on the server tho. Also in some ways wouldn't this reduce anonymity? Transactions correlate wallets with a certain IP address every time... Also from the README:
Electrum wallet must be configured to connect to the server. SSL must be disabled
Electrum wallet must be configured to connect to the server. SSL must be disabled
I just uploaded some code to a github repository (https://github.com/chris-belcher/electrum-personal-server) and sent this email to the bitcoin dev mailing list.
edit: link to email https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015707.html
Subject: Electrum Personal Server alpha release
Electrum is a popular bitcoin wallet, but it is not a full node wallet as it synchronizes itself using third-party Electrum servers. The servers must be trusted to verify the rules of bitcoin, they can trick Electrum wallets into accepting fake bitcoin transactions which, for example, print infinite money. Bitcoin's security model requires that most economic activity is backed by full nodes. The Electrum servers must also be trusted with the user's privacy, as wallets send all their bitcoin addresses to the server. Spying on wallets is not much more complicated than simply grepping the server logs. Electrum wallets by default also connect to servers using their own IP address, linking it further to their revealed bitcoin addresses.
A way to avoid these problems is for users to run their own Electrum server and connect their wallets only to it. But this requires significant resource usage: the full unpruned blockchain, transaction index and an extra address index, as well as more RAM and CPU usage compared to just a full node. Servers are not well suited to being shut down and started up again, they are typically always online.
Electrum servers store a database of every bitcoin address ever used, which is inherently not scalable. This is resource-intensive and therefore pushes users towards centralized solutions. An alternative way would be to store only your own addresses and transactions.
Introducing Electrum Personal Server; an implementation of the Electrum server protocol which fulfills the specific need of using the Electrum UI with full node verification and privacy, but without the heavyweight server backend, for a single user. It allows the user to benefit from all of Bitcoin Core's resource-saving features like pruning, blocksonly and disabled txindex. All of Electrum's feature-richness like hardware wallet integration, multisignature wallets, offline signing, mnemonic recovery phrases and so on can still be used, but backed by the user's own full node.
An alpha version of Electrum Personal Server can be found on the repository: https://github.com/chris-belcher/electrum-personal-server
Before using, the wallet user must configure Electrum Personal Server with their master public key and those addresses are imported into Bitcoin Core as watch-only. If the wallet contains historical transactions then it must be rescanned. One of Electrum's motivating features is "instant on", which is therefore traded away when using Electrum Personal Server in return for full node verification and privacy. Although if a brand new empty wallet is created there is no need to rescan. A script like Electrum Personal Server is also well suited to use private transaction broadcasting tech like dandelion or broadcasting through tor.
Using Electrum with Electrum Personal Server is probably the most resource-efficient way right now to use a hardware wallet connected to your own full node. People who make use of Blockstream Satellite could use it to have an off-the-grid node connected to Electrum if that is their preferred wallet. In the situation of a traveller staying a cheap hostels, they could sync their node every couple of days to download recent blocks and use Electrum. Hopefully this software can be part of the plan to get full node wallets into the hands of as many people as possible.
The same kind of ideas could be applied to other lightweight wallets. For example a full nodes can run on smartphones with pruning and blocksonly, then a similar script would allow the user to connect their Samourai Wallet, Breadwallet or GreenAddress app to their own full node.
Further Reading:
* https://bitcointalksearch.org/topic/m.27179198
* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html
* https://bitcointalk.org/index.php?topic=1634967.0;all
edit: link to email https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015707.html
Subject: Electrum Personal Server alpha release
Electrum is a popular bitcoin wallet, but it is not a full node wallet as it synchronizes itself using third-party Electrum servers. The servers must be trusted to verify the rules of bitcoin, they can trick Electrum wallets into accepting fake bitcoin transactions which, for example, print infinite money. Bitcoin's security model requires that most economic activity is backed by full nodes. The Electrum servers must also be trusted with the user's privacy, as wallets send all their bitcoin addresses to the server. Spying on wallets is not much more complicated than simply grepping the server logs. Electrum wallets by default also connect to servers using their own IP address, linking it further to their revealed bitcoin addresses.
A way to avoid these problems is for users to run their own Electrum server and connect their wallets only to it. But this requires significant resource usage: the full unpruned blockchain, transaction index and an extra address index, as well as more RAM and CPU usage compared to just a full node. Servers are not well suited to being shut down and started up again, they are typically always online.
Electrum servers store a database of every bitcoin address ever used, which is inherently not scalable. This is resource-intensive and therefore pushes users towards centralized solutions. An alternative way would be to store only your own addresses and transactions.
Introducing Electrum Personal Server; an implementation of the Electrum server protocol which fulfills the specific need of using the Electrum UI with full node verification and privacy, but without the heavyweight server backend, for a single user. It allows the user to benefit from all of Bitcoin Core's resource-saving features like pruning, blocksonly and disabled txindex. All of Electrum's feature-richness like hardware wallet integration, multisignature wallets, offline signing, mnemonic recovery phrases and so on can still be used, but backed by the user's own full node.
An alpha version of Electrum Personal Server can be found on the repository: https://github.com/chris-belcher/electrum-personal-server
Before using, the wallet user must configure Electrum Personal Server with their master public key and those addresses are imported into Bitcoin Core as watch-only. If the wallet contains historical transactions then it must be rescanned. One of Electrum's motivating features is "instant on", which is therefore traded away when using Electrum Personal Server in return for full node verification and privacy. Although if a brand new empty wallet is created there is no need to rescan. A script like Electrum Personal Server is also well suited to use private transaction broadcasting tech like dandelion or broadcasting through tor.
Using Electrum with Electrum Personal Server is probably the most resource-efficient way right now to use a hardware wallet connected to your own full node. People who make use of Blockstream Satellite could use it to have an off-the-grid node connected to Electrum if that is their preferred wallet. In the situation of a traveller staying a cheap hostels, they could sync their node every couple of days to download recent blocks and use Electrum. Hopefully this software can be part of the plan to get full node wallets into the hands of as many people as possible.
The same kind of ideas could be applied to other lightweight wallets. For example a full nodes can run on smartphones with pruning and blocksonly, then a similar script would allow the user to connect their Samourai Wallet, Breadwallet or GreenAddress app to their own full node.
Further Reading:
* https://bitcointalksearch.org/topic/m.27179198
* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html
* https://bitcointalk.org/index.php?topic=1634967.0;all
I was reading this article https://www.coindesk.com/jonas-schnelli-wants-run-bitcoin-full-node/
In it Jonas Schnelli talks about running full nodes on smartphones.
I realize you could create a similar gateway script for other SPV wallets. For example you run a full node on your phone with a gateway, and then point your Breadwallet/Greenaddress/Samuraiwallet software to connect only to your own full node via gateway. This would be good in situations where people want to use those wallet UIs.
edit: Also these gateways can have private transaction broadcasting over tor built-in.
In it Jonas Schnelli talks about running full nodes on smartphones.
I realize you could create a similar gateway script for other SPV wallets. For example you run a full node on your phone with a gateway, and then point your Breadwallet/Greenaddress/Samuraiwallet software to connect only to your own full node via gateway. This would be good in situations where people want to use those wallet UIs.
edit: Also these gateways can have private transaction broadcasting over tor built-in.
Here is a conversation with nopara73, waxwing, aruk and I.
@belcher There is something I don't understand. Why not just run an Electrum server on your own machine and point the Electrum client to localhost?
ill write an FAQ with that since that question has come up a few times
I get it that pruning and stuff doesn't work like that.
the answer is because a normal electrum server needs lots of disk space and memory
yeah thats it
an regular electrum server has a database of every bitcoin address that was ever used
this gateway thing only has your own addresses, and they are stored in bitcoin core's wallet.dat
However instead of building a completely new system, for me it seems like the first reasonable approach would be try to tweak the existing system into being more space effective.
theres tweaking and then theres trying different approaches
storing every address ever used is inherently not scalable, storing only your own addresses is better for some things
the tradeoff is you have to -rescan if you import addresses that have historical transactions
I see, makes sense.
thats why this probably wont be added to electrum itself because it has "instant on" as one important value
this isnt "instant on", it trades away that in return for full node verification and less resource usage
Oh, there's something else in my mind.
What do you think of the future of on-chain transactions?
It seems like they are going to the roof.
And the situation will not get better.
they'll be limited
my view is basically the same as bitcoin cores/UASFs
block space is a scarce resource and we'll have to learn to use it efficently
This may comes with a trend of people who are using Bitcoin on-chain will also be easily able to afford to run a fullnode.
for privacy specifically i wrote this https://www.reddit.com/r/joinmarket/comments/7m422w/some_updates_on_joinmarketclientserver/drtzm84/
privacy will have to happen off-chain, because buying lots of block space with coinjoin/whatever will be expensive
reading it again now, i should put chaumian ecash servers as another off-chain tech and link your blog post
Recently I was wondering if building a nice UI on top of fully validating Core is a strategically smarter decision than trying to tweak with light clients.
yes i think so, i really like electrum's UI so my gateway idea is about having both electrum's nice UI and core's full verification
in your bitcointalk reply you say "Building a nice UI would be less of an effort then building this gateway." which is... not true... building a nice UI means re-doing all the work that the electrum devs have done
yes agreed, it's not really even quite "nice UI" that electrum client has got so right, it's feature-richness imo.
anyway if its okay with you id like to copypaste this conversation into that bitcointalk thread
feel free to repeat anything i said.
@belcher My point was building a UI is just putting one thing on top of another, while building a gateway requires actual engineering and logic. Maybe building a UI would be more work, but it would be an easier work, where you don't have to be anxious about if your algo fails, people can lose money.
@nopara73 that's true, but he doesn't want to change the UI, he wants to change how easily you can replicate the electrum server functionality backend as a single user with one node
you can do it now but it's too expensive (txindex and so on)
Ok, but that's just a personal engineering boner, not an actual, "what's the most effective way to fix that problem I have: decision:)
you think so? i don't. if you scroll up you'll see i made the same point as you about reusing existing arch; but he intends to create a far lighter-weight version of it, which would address a specific need: to use electrum UI without a heavyweight server backend, for a single user.
Indeed. I didn't understand what you were talking about, because when I read your comments I didn't yet read the bitcointalk post.
It would actually be very useful as using electrum server with your full node is basically the only way to validate your hardware wallet transactions with a full node
I wonder why this is not a more wanted feature
aruk yes that is one big motivation, i realized we talk up hardware wallets as a great way to store privkeys, but bitcoin security also requires using a full node wallet and hardware wallets dont work well with those (yet)
for engineering vs UI, i dont like UI that much (personally)
it does but it's extremely cumbersome
i actually liked reading cs textbooks with all those graphs and heaps and tree diagrams
creating UI i mean 
using it is obviously nice
only thing is, like with JM, if you go with a non-indexed approach, you have problems in recovery.
yep, tradeoffs :\
its required for scalability i think, transactions come in blocks, you have to scan them
@waxwing My point is you get the same result if you replicate the Electrum GUI for, Core, or let's say @jonasschnelli’s fullspv PR here: https://github.com/bitcoin/bitcoin/pull/9483 then it's an easier way to get to where he wants to get, than writing the gateway.
you could make a database of every address every used... but that will be big and probably centralized because of that (i.e. people will use bc.i's API instead of scanning their own blocks)
nopara73 jonasschnelli’s PR doesnt support (for example) mnemonic phrases
or any other of electrum's nice features
yeah it isn't just GUI, like i said above, it's feature-richness.
yes, UI is the wrong word
HW wallet integration mentioned above is a very good point too.
several other things, but i don't want to be unfair to Core's GUI since i never used it :laughing:
features are a part of UI i guess... /me looks up how "UI" is actually defined
What? Why doesn't it? I support it in HiddenWallet. It's just the user must specify a date when the wallet was created.
At recovery
if you want consensus to be enforced, you need people validating high value transactions. Nobody is doing it because they all use a hw wallet that does not depend on a local node
Core's GUI doesnt support lots of stuff, i think most core developers are interested in the super-important scalability stuff
there's a huge amount of work gone into scalability in bitcoin core, without which bitcoin would likely die
IMO the best application in Core is bitcoind not bitcoin-qt
the way i run things is an old always-on laptop with bitcoind running (and other stuff like joinmarket and irc)
Quote
using it is obviously nice
> Electrum wallets may be tricked into accepting transactions of BitcoinXT or some other hostile hard fork.
I think this is not true. Don't they use redundancy to mitigate this issue?
> Another way to synchronize a wallet would be to download full blocks and/or point the wallet to your own full node.
Maybe we can add Neutrino from Lightning Labs? I didn't do much research on it myself, but from what I heard it's sufficiently private and can be added to Electrum? Nevertheless it's a lot of coding.
> I've heard a story of a tourist travelling through rural South America with a laptop, every couple of days at the cheap hostels they stayed they would run Bitcoin with -blocksonly to catch up.
Completely workable. I'm doing the same for years all over the World.
> This is basically a proposal for an improved lightweightness of Electrum server, the goal is to
> keep all the nice UI
Building a nice UI would be less of an effort then building this gateway.
> usability
The improved useability derived from the nice UI goal, so the same comment applies. However the useability will be drastically worse, because the user has to run a full node gateway or a full spv node gateway.
> hardware wallets, multisignature, offline signing, etc features of Electrum but with better privacy
Valid.
> and reduced resource requirement.
The resource requirements go to the roof, because the user would have to run a fullnode gateway or a fullspv gateway.
About Type 2: fullspv gateway
There is no need for custom coding if one can push through fullspv mode into Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/9483
Because I built it myself into HiddenWallet, I would highly discourage anyone from trying it. It turns out competing with the performance of Bitcoin Core is a dead case. There are way too many microoptimizations there, I found running a fullnode more convenient than running my fullspv node. (500MB memory usage vs 2GB memory usage, plus CPU spikes.)
I think this is not true. Don't they use redundancy to mitigate this issue?
> Another way to synchronize a wallet would be to download full blocks and/or point the wallet to your own full node.
Maybe we can add Neutrino from Lightning Labs? I didn't do much research on it myself, but from what I heard it's sufficiently private and can be added to Electrum? Nevertheless it's a lot of coding.
> I've heard a story of a tourist travelling through rural South America with a laptop, every couple of days at the cheap hostels they stayed they would run Bitcoin with -blocksonly to catch up.
Completely workable. I'm doing the same for years all over the World.
> This is basically a proposal for an improved lightweightness of Electrum server, the goal is to
> keep all the nice UI
Building a nice UI would be less of an effort then building this gateway.
> usability
The improved useability derived from the nice UI goal, so the same comment applies. However the useability will be drastically worse, because the user has to run a full node gateway or a full spv node gateway.
> hardware wallets, multisignature, offline signing, etc features of Electrum but with better privacy
Valid.
> and reduced resource requirement.
The resource requirements go to the roof, because the user would have to run a fullnode gateway or a fullspv gateway.About Type 2: fullspv gateway
There is no need for custom coding if one can push through fullspv mode into Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/9483
Because I built it myself into HiddenWallet, I would highly discourage anyone from trying it. It turns out competing with the performance of Bitcoin Core is a dead case. There are way too many microoptimizations there, I found running a fullnode more convenient than running my fullspv node. (500MB memory usage vs 2GB memory usage, plus CPU spikes.)
Sounds good.
Electrum uses Electrum servers which can spy on or lie to wallet users. Electrum wallets may be tricked into accepting transactions of BitcoinXT or some other hostile hard fork proposal. And the servers have a list of all the user's bitcoin addresses which is harmful to privacy. Right now Electrum comes packaged with Tails OS which has the tagline "Privacy for anyone anywhere", which is simply not true when using Electrum with default servers.
Another way to synchronize a wallet would be to download full blocks and/or point the wallet to your own full node. One of Electrum's values is "instant on" so those methods will probably never be added to Electrum itself.
Probably a better way would be to create a gateway, a script that behaves like an Electrum server but which obtains bitcoin network information in another way. To use it you would just run the gateway script and point your Electrum wallet to localhost. The script would be separate from the Electrum software itself so Electrum's raison d'etre which includes "instant on" would be preserved.
This is basically a proposal for an improved lightweightness of Electrum server. The goal is to keep all of Electrum's feature-richness of hardware wallet integration, multisignature, offline signing, coin control, etc but with better privacy, full node verification and minimal resource requirement compared to a full server.
Here are some gateway script ideas:
Type 1
The gateway script adds watch-only addresses to Bitcoin Core's wallet via the RPC protocol. Updates to the wallet.dat are transmitted to Electrum via the gateway.
Features: Full verification, security and privacy from a full node. Works with pruning and blocksonly. Reasonably simple to code.
Downsides: Adding wallets with historical transaction being added will require rescanning. Users must configure the gateway script with their Electrum master public keys before using.
Type 1 would be combining Bitcoin Core with Electrum. All of Bitcoin's configuration tuning like -blocksonly and -pruning can be used and txindex can be switched off. It would provide a way to use Electrum wallet with as low resource usage as possible while still being a full node. It would also be reasonably simple to code, only requiring Electrum's protocol and Bitcoin's RPC to be implemented and have them connected together.
I've heard a story of a tourist travelling through rural South America with a laptop, every couple of days at the cheap hostels they stayed they would run Bitcoin with -blocksonly to catch up. The type 1 gateway script would allow them to use Electrum if that was their preferred wallet.
Regarding rescanning. The user should have all their Electrum wallets imported into Bitcoin Core's wallet.dat file, so then they can switch between them without rescanning. If a brand new empty wallet with no transactions is created, there is also no need to rescan. The only time a rescan is needed is if new wallets are added which have historical transactions.
Type 2
The gateway script connects to the bitcoin p2p network and downloads full blocks (possibly with committed block bloom filters).
Features: Excellent privacy, almost as good as full node. SPV security just like Electrum today. Doesn't require any setup.
Downsides: Uses (much) more initial bandwidth than an Electrum server. Slower startup. Fairly complicated to code. Requires using new technology (committed bloom filters) before it can be practical.
Type 2 would be trading off bandwidth and speed for privacy. The wallet downloads some full blocks which takes longer, but in return it gets much better privacy. This script could be added to Tails OS as a pre-installed pre-configured script. Note that scanning blocks only needs to start from the wallet creation date, so if the user creates their wallet right now then the gateway script won't need to scan any old blocks.
Thoughts?
Another way to synchronize a wallet would be to download full blocks and/or point the wallet to your own full node. One of Electrum's values is "instant on" so those methods will probably never be added to Electrum itself.
Probably a better way would be to create a gateway, a script that behaves like an Electrum server but which obtains bitcoin network information in another way. To use it you would just run the gateway script and point your Electrum wallet to localhost. The script would be separate from the Electrum software itself so Electrum's raison d'etre which includes "instant on" would be preserved.
This is basically a proposal for an improved lightweightness of Electrum server. The goal is to keep all of Electrum's feature-richness of hardware wallet integration, multisignature, offline signing, coin control, etc but with better privacy, full node verification and minimal resource requirement compared to a full server.
Here are some gateway script ideas:
Type 1
The gateway script adds watch-only addresses to Bitcoin Core's wallet via the RPC protocol. Updates to the wallet.dat are transmitted to Electrum via the gateway.
Features: Full verification, security and privacy from a full node. Works with pruning and blocksonly. Reasonably simple to code.
Downsides: Adding wallets with historical transaction being added will require rescanning. Users must configure the gateway script with their Electrum master public keys before using.
Type 1 would be combining Bitcoin Core with Electrum. All of Bitcoin's configuration tuning like -blocksonly and -pruning can be used and txindex can be switched off. It would provide a way to use Electrum wallet with as low resource usage as possible while still being a full node. It would also be reasonably simple to code, only requiring Electrum's protocol and Bitcoin's RPC to be implemented and have them connected together.
I've heard a story of a tourist travelling through rural South America with a laptop, every couple of days at the cheap hostels they stayed they would run Bitcoin with -blocksonly to catch up. The type 1 gateway script would allow them to use Electrum if that was their preferred wallet.
Regarding rescanning. The user should have all their Electrum wallets imported into Bitcoin Core's wallet.dat file, so then they can switch between them without rescanning. If a brand new empty wallet with no transactions is created, there is also no need to rescan. The only time a rescan is needed is if new wallets are added which have historical transactions.
Type 2
The gateway script connects to the bitcoin p2p network and downloads full blocks (possibly with committed block bloom filters).
Features: Excellent privacy, almost as good as full node. SPV security just like Electrum today. Doesn't require any setup.
Downsides: Uses (much) more initial bandwidth than an Electrum server. Slower startup. Fairly complicated to code. Requires using new technology (committed bloom filters) before it can be practical.
Type 2 would be trading off bandwidth and speed for privacy. The wallet downloads some full blocks which takes longer, but in return it gets much better privacy. This script could be added to Tails OS as a pre-installed pre-configured script. Note that scanning blocks only needs to start from the wallet creation date, so if the user creates their wallet right now then the gateway script won't need to scan any old blocks.
Thoughts?
Jump to: