📅 Original date posted:2015-07-22
📝 Original message:I would recommend the following solution as a decent compromise between
complexity and privacy:
1) Encourage electrum server operators to have their servers reachable as
tor hidden services (.onion addresses)
2) Make sure server discovery works well with .onion addresses
3) Make the privacy a user configurable setting:
- None - Allows any server connection type
- SSL - Requires SSL at least, no plain text
- Tor - Requires tor, no direct TCP
- Multi-Tor - Uses a variety of tor paths to reach a variety of servers
(maybe configurable number of servers)
Default should be 'SSL' probably.
On Wed, Jul 22, 2015 at 3:20 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I should add that the obvious resolution to this set of problems is to
> use a distinct Tor route for each Bitcoin address, not to reinvent Tor
> and reproduce its community. So ultimately this is easy to implement,
> but the downside is performance.
>
> But it's important to keep in mind that poor-performing perfect privacy
> for address monitoring is trivial to achieve - just sync the full
> blockchain.
>
> Presumably if you don't trust a server to protect your privacy, you also
> don't trust it with your money. So any robust privacy optimization would
> at least be designed to support partial (SPV) chain clients. It would
> also need to support wallet restoration from backup.
>
> The level of privacy will always be a performance trade-off. The ideal
> solution would allow a client to balance privacy against performance.
>
> e
>
> On 07/22/2015 09:30 AM, Eric Voskuil wrote:
> > Hi Thomas,
> >
> > The scheme is essentially onion routing. The set of {M} are entry nodes
> > and the set of {S} are exit nodes. The weaknesses are as you would see
> > in an analogous TOR implementation:
> >
> > (1) The lack of relay nodes {R} make collaboration between any subset of
> > {M} and {S} trivial.
> >
> > (2) OR is a mixnet, so the size of the network matters a lot.
> >
> > (3) The directory is a perpetual weakness.
> >
> > (4) Content is visible to the exit node (or the final service). This
> > means each address must be passed via a distinct route to prevent
> > correlation.
> >
> > e
> >
> > On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:
> >> Hello,
> >>
> >> Although Electrum clients connect to several servers in order to fetch
> >> block headers, they typically request address balances and address
> >> histories from a single server. This means that the chosen server knows
> >> that a given set of addresses belong to the same wallet. That is true
> >> even if Electrum is used over TOR.
> >>
> >> There have been various proposals to improve on that, but none of them
> >> really convinced me so far. One recurrent proposal has been to create
> >> subsets of wallet addresses, and to send them to separate servers. In my
> >> opinion, this does not really improve anonymity, because it requires
> >> trusting more servers.
> >>
> >> Here is an idea, inspired by TOR, on which I would like to have some
> >> feedback: We create an anonymous routing layer between Electrum servers
> >> and clients.
> >>
> >> * Each server S publishes a RSA public key, KS
> >> * Each client receives a list of available servers and their pubkeys
> >> * For each wallet address, addr_i, a client chooses a server S_i, and a
> >> RSA keypair (K_addr_i, k_addr_i)
> >> * The client creates a list of encrypted requests. Each request contains
> >> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> >> * The client chooses a main server M, and sends the list of encrypted
> >> requests to M
> >> * M dispatches the client's requests to the corresponding servers S_i
> >> (without the client's IP address.)
> >> * Each server decrypts the requests it receives, performs the request,
> >> and encrypts the result with K_addr_i
> >> * M receives encrypted responses, and forwards them to the client.
> >> * The client decrypts the encrypted response with k_addr_i
> >>
> >> What do you think? What are the costs and benefits of such an approach?
> >>
> >> (Note: this will not work if all servers, or a large fraction of them,
> >> are controlled by the same entity that controls M)
> >>
> >>
> >> Thomas
> >> _______________________________________________
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/da02ff32/attachment.html>;
Joseph Gleason ⑈ [ARCHIVE] /
npub1qp…my8sw
2023-06-07 15:42:44
in reply to nevent1q…w8gs
Author Public Key
npub1qp59a7k7vxv0k8z277f50092ljk9mjg5du9lz8hlft37u4ggwqes5my8swPublished at
2023-06-07 15:42:44Event JSON
{
"id": "978f3cd86db3f1e06c82f6b2746b5bc6a2b3d7a6ad16a0f0843502a02c5d2702",
"pubkey": "00685efade6198fb1c4af79347bcaafcac5dc9146f0bf11eff4ae3ee55087033",
"created_at": 1686152564,
"kind": 1,
"tags": [
[
"e",
"118b9de54e189b18402c92d943ea538ff30d5f541b4aeaba9bb62ae15123b652",
"",
"root"
],
[
"e",
"14fe59b9d37ad3dda64a900e8d5befd7d02f9364edecd8a4a66be53882fbf2b8",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2015-07-22\n📝 Original message:I would recommend the following solution as a decent compromise between\ncomplexity and privacy:\n\n1) Encourage electrum server operators to have their servers reachable as\ntor hidden services (.onion addresses)\n2) Make sure server discovery works well with .onion addresses\n3) Make the privacy a user configurable setting:\n - None - Allows any server connection type\n - SSL - Requires SSL at least, no plain text\n - Tor - Requires tor, no direct TCP\n - Multi-Tor - Uses a variety of tor paths to reach a variety of servers\n(maybe configurable number of servers)\n\nDefault should be 'SSL' probably.\n\n\n\n\n\n\n\n\nOn Wed, Jul 22, 2015 at 3:20 PM Eric Voskuil via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I should add that the obvious resolution to this set of problems is to\n\u003e use a distinct Tor route for each Bitcoin address, not to reinvent Tor\n\u003e and reproduce its community. So ultimately this is easy to implement,\n\u003e but the downside is performance.\n\u003e\n\u003e But it's important to keep in mind that poor-performing perfect privacy\n\u003e for address monitoring is trivial to achieve - just sync the full\n\u003e blockchain.\n\u003e\n\u003e Presumably if you don't trust a server to protect your privacy, you also\n\u003e don't trust it with your money. So any robust privacy optimization would\n\u003e at least be designed to support partial (SPV) chain clients. It would\n\u003e also need to support wallet restoration from backup.\n\u003e\n\u003e The level of privacy will always be a performance trade-off. The ideal\n\u003e solution would allow a client to balance privacy against performance.\n\u003e\n\u003e e\n\u003e\n\u003e On 07/22/2015 09:30 AM, Eric Voskuil wrote:\n\u003e \u003e Hi Thomas,\n\u003e \u003e\n\u003e \u003e The scheme is essentially onion routing. The set of {M} are entry nodes\n\u003e \u003e and the set of {S} are exit nodes. The weaknesses are as you would see\n\u003e \u003e in an analogous TOR implementation:\n\u003e \u003e\n\u003e \u003e (1) The lack of relay nodes {R} make collaboration between any subset of\n\u003e \u003e {M} and {S} trivial.\n\u003e \u003e\n\u003e \u003e (2) OR is a mixnet, so the size of the network matters a lot.\n\u003e \u003e\n\u003e \u003e (3) The directory is a perpetual weakness.\n\u003e \u003e\n\u003e \u003e (4) Content is visible to the exit node (or the final service). This\n\u003e \u003e means each address must be passed via a distinct route to prevent\n\u003e \u003e correlation.\n\u003e \u003e\n\u003e \u003e e\n\u003e \u003e\n\u003e \u003e On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:\n\u003e \u003e\u003e Hello,\n\u003e \u003e\u003e\n\u003e \u003e\u003e Although Electrum clients connect to several servers in order to fetch\n\u003e \u003e\u003e block headers, they typically request address balances and address\n\u003e \u003e\u003e histories from a single server. This means that the chosen server knows\n\u003e \u003e\u003e that a given set of addresses belong to the same wallet. That is true\n\u003e \u003e\u003e even if Electrum is used over TOR.\n\u003e \u003e\u003e\n\u003e \u003e\u003e There have been various proposals to improve on that, but none of them\n\u003e \u003e\u003e really convinced me so far. One recurrent proposal has been to create\n\u003e \u003e\u003e subsets of wallet addresses, and to send them to separate servers. In my\n\u003e \u003e\u003e opinion, this does not really improve anonymity, because it requires\n\u003e \u003e\u003e trusting more servers.\n\u003e \u003e\u003e\n\u003e \u003e\u003e Here is an idea, inspired by TOR, on which I would like to have some\n\u003e \u003e\u003e feedback: We create an anonymous routing layer between Electrum servers\n\u003e \u003e\u003e and clients.\n\u003e \u003e\u003e\n\u003e \u003e\u003e * Each server S publishes a RSA public key, KS\n\u003e \u003e\u003e * Each client receives a list of available servers and their pubkeys\n\u003e \u003e\u003e * For each wallet address, addr_i, a client chooses a server S_i, and a\n\u003e \u003e\u003e RSA keypair (K_addr_i, k_addr_i)\n\u003e \u003e\u003e * The client creates a list of encrypted requests. Each request contains\n\u003e \u003e\u003e addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i\n\u003e \u003e\u003e * The client chooses a main server M, and sends the list of encrypted\n\u003e \u003e\u003e requests to M\n\u003e \u003e\u003e * M dispatches the client's requests to the corresponding servers S_i\n\u003e \u003e\u003e (without the client's IP address.)\n\u003e \u003e\u003e * Each server decrypts the requests it receives, performs the request,\n\u003e \u003e\u003e and encrypts the result with K_addr_i\n\u003e \u003e\u003e * M receives encrypted responses, and forwards them to the client.\n\u003e \u003e\u003e * The client decrypts the encrypted response with k_addr_i\n\u003e \u003e\u003e\n\u003e \u003e\u003e What do you think? What are the costs and benefits of such an approach?\n\u003e \u003e\u003e\n\u003e \u003e\u003e (Note: this will not work if all servers, or a large fraction of them,\n\u003e \u003e\u003e are controlled by the same entity that controls M)\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e Thomas\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/da02ff32/attachment.html\u003e",
"sig": "0a36d96a7698c6e8081848aafc3df63472da1de533093f52d365441eda392b711519de3a9dcf959580b7d94cea6dfa359951adcb001c32e00a33d9c6b0670989"
}