Same wallet, but listening on two different machines

[smooth.tent6298]

I’m trying to wrap my head around wallet listening. I believe I understand the basics:

Use the listen subcommand to create a tor hidden service at an onion address that is derived from your wallet’s public key. The receiver plugs in your grin address on their end, which internally is mapped to your tor hidden service address and the slatepack is built and exchanged a few times.

First off - is that right?

Second - I started two wallet listeners on two different machines. Both started hidden services at the same onion address. Is this expected? which wallet listener will respond to a send request?

[TrieDemon]

The first part is correct. I too would like to know the second part. Had this exact issue yesterday. Started up the same wallet on two machines, now neither of them seem to receive connections, even though one worked before

[Anynomous]

@smooth.tent6298

Second - I started two wallet listeners on two different machines. Both started hidden services at the same onion address. Is this expected? which wallet listener will respond to a send request?

A SlatepackAddress is a bech32 encoded ed25519 public key and when shared with other parties is used to represent the ability to receive Grin transactions.
grin-wallet already handles ed25519 keys for the v3 onion addresses in Tor transactions. These keys can be extended to be a general SlatepackAddress to allow a universal key format for both transport and encryption that is error-checked, QR friendly and easily human identifiable.
Slatepack - Grin Documentation

So in other words, a slatepack address is a public key wrapped as a onion address. Since two wallets with same mnemonic have the same public key, they also share their slate-pack address. I am not sure if running two wallets with the same address leads to routing issues/a conflict. I can imagine it might. With the Grin CC wallet we also use two instances, and indeed I often lose my peers for reasons unknown to me. If such a problem occurs might also depends on whether you use Grin++ (gives me some issues when running multiple instances of the same wallet), or grin-wallet (rust).

Edit: Grin++ is introducing the option to generate a new slatepack address in the yet to be release version 1.2.8. Grin++ achieves this by generating a wrapped private-key derived with another account from the same mnemonic. In case you encounter issues with running multiple instances of a wallet with Grin++, you can generate a new adress for one of them once Grin++ 1.2.8 gets released.

@davidtavarez Progress Update thread (August-December 2022)

Time for showcase and asking for feedback here. Now it is more clear to setup the number of outbounds and inbounds preferred connections. [001] I added more endpoints and settings: Preferred, Allowed and blocked peers. [002] Bridges! I added snowflake support, in order to enable the Bridges, you can just either turn on the switch or add the Obfs4 bridges inside the textbox. Obfs4 support it is also new in Grin++ [003] I added a new button to generate a new address on demand. [004] […

[smooth.tent6298]

Ah thanks for clarifying about the public key actually being a SlatepackAddress. That was helpful!

[TrieDemon]

@Anynomous

Edit: Grin++ is introducing the option to generate a new slatepack address in the yet to be release version 1.2.8.

Great news! I wonder if this should also be designed for the reference wallet? It seems necessary for privacy too. I wouldnt want to share the same address to different groups of people (e.g. I’d want to give a different address to my prostitute than the address I gave to my church )