What is Nostr?
Eric Voskuil [ARCHIVE] /
npub1sgs…px3c
2023-06-07 15:42:43
in reply to nevent1q…4j0l

Eric Voskuil [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-22 📝 Original message:Hi Thomas, The scheme is ...

📅 Original date posted:2015-07-22
📝 Original message: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
> _______________________________________________

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/f06a04f6/attachment.sig>;
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c