While I realize you just meant it as a light "fun fact", I think it's worth pointing out that walletexplorer is very primitive and semi? unmaintained -- and you won't be able to trick any serious analysis tool with a coinjoin like that. [Although coinjoins can do an amazing job at tricking them! But you really need the coinjoin to look like a normal transaction for that]

But the IP of the "private server" is the same as the IP of the wallet if you're connecting to localhost?!

OK, but then you're back to leaking your IP address again.

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
 

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.

<nopara73> @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?
<belcher> ill write an FAQ with that since that question has come up a few times
<nopara73> I get it that pruning and stuff doesn't work like that.
<belcher> the answer is because a normal electrum server needs lots of disk space and memory
<belcher> yeah thats it
<belcher> an regular electrum server has a database of every bitcoin address that was ever used
<belcher> this gateway thing only has your own addresses, and they are stored in bitcoin core's wallet.dat
<nopara73> 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.
<belcher> theres tweaking and then theres trying different approaches
<belcher> storing every address ever used is inherently not scalable, storing only your own addresses is better for some things
<belcher> the tradeoff is you have to -rescan if you import addresses that have historical transactions
<nopara73> I see, makes sense.
<belcher> thats why this probably wont be added to electrum itself because it has "instant on" as one important value
<belcher> this isnt "instant on", it trades away that in return for full node verification and less resource usage
<nopara73> Oh, there's something else in my mind.
<nopara73> What do you think of the future of on-chain transactions?
<nopara73> It seems like they are going to the roof.
<nopara73> And the situation will not get better.
<belcher> they'll be limited
<belcher> my view is basically the same as bitcoin cores/UASFs
<belcher> block space is a scarce resource and we'll have to learn to use it efficently
<nopara73> 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.
<belcher> for privacy specifically i wrote this https://www.reddit.com/r/joinmarket/comments/7m422w/some_updates_on_joinmarketclientserver/drtzm84/
<belcher> privacy will have to happen off-chain, because buying lots of block space with coinjoin/whatever will be expensive
<belcher> reading it again now, i should put chaumian ecash servers as another off-chain tech and link your blog post
<nopara73> 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.
<belcher> 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
<belcher> 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
<waxwing> yes agreed, it's not really even quite "nice UI" that electrum client has got so right, it's feature-richness imo.
<belcher> anyway if its okay with you id like to copypaste this conversation into that bitcointalk thread
<waxwing> feel free to repeat anything i said.
<nopara73> @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.
<waxwing> @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
<waxwing> you can do it now but it's too expensive (txindex and so on)
<nopara73> 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:)
<waxwing> 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.
<nopara73> Indeed. I didn't understand what you were talking about, because when I read your comments I didn't yet read the bitcointalk post.
<aruk> 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
<aruk> I wonder why this is not a more wanted feature
<belcher> 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)
<belcher> for engineering vs UI, i dont like UI that much (personally)
<aruk> it does but it's extremely cumbersome
<belcher> i actually liked reading cs textbooks with all those graphs and heaps and tree diagrams
<belcher> creating UI i mean using it is obviously nice
<waxwing> only thing is, like with JM, if you go with a non-indexed approach, you have problems in recovery.
<belcher> yep, tradeoffs :\
<belcher> its required for scalability i think, transactions come in blocks, you have to scan them
<nopara73> @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.
<belcher> 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)
<belcher> nopara73 jonasschnelli’s PR doesnt support (for example) mnemonic phrases
<belcher> or any other of electrum's nice features
<waxwing> yeah it isn't just GUI, like i said above, it's feature-richness.
<belcher> yes, UI is the wrong word
<waxwing> HW wallet integration mentioned above is a very good point too.
<waxwing> several other things, but i don't want to be unfair to Core's GUI since i never used it :laughing:
<belcher> features are a part of UI i guess... /me looks up how "UI" is actually defined
<nopara73> What? Why doesn't it? I support it in HiddenWallet. It's just the user must specify a date when the wallet was created.
<nopara73> At recovery
<aruk> 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
<belcher> Core's GUI doesnt support lots of stuff, i think most core developers are interested in the super-important scalability stuff
<belcher> there's a huge amount of work gone into scalability in bitcoin core, without which bitcoin would likely die
<belcher> IMO the best application in Core is bitcoind not bitcoin-qt
<belcher> the way i run things is an old always-on laptop with bitcoind running (and other stuff like joinmarket and irc)

Estimated fee per kB greater than absurd value: 350000, quitting.

Can't do it. That breaks the decentralized concept and ruins the system. Yes, there are many people that have at least one issue and lose coins within their crypto lifetime. This can only be controlled by their knowledge. Some sites provide things like escrow, but that is not within the coin code and can never be.