I'm proposing an instant sync protocol for Jamtis, which is almost as good as Monero-PSK but without the disadvantages.

<jberman> Once the wallet is restored, I would think the wallet should always need to scan the chain from then on since otherwise it would miss payments. And I'd think restoring a wallet is a pretty common thing people do, to the point that many would end up just reverting to just always scanning and the feature would end up not widely used / beneficial

It's the best that can be done with Jamtis. It has basically zero cost, so I don't see a reason not to keep in the specs.

Just like the IPP, not all people will use it, but some people can benefit from it if they want.

<jberman> do you think this would be worth an additional pubkey for every output on chain to make all txs look the same?

What additional pubkey? This protocol doesn't need any on chain changes.

<jberman> The ephemeral key attached to the enote isn't additional?

No, it's in every Jamtis enote.

<jberman> Ah, I see, neat

See: gist.github.com/tevador/639d083c994…832c08e2b7832#6-addressing-protocol

This is inherited from Carrot, which has the exact same rules: github.com/jeffro256/carrot/blob/ma…carrot.md#712-ephemeral-public-keys

Quote: "Every 2-output transaction has one ephemeral public key D_e. Transactions with N > 2 outputs have N ephemeral public keys (one for each output)."

<jberman> Ya I see, I misunderstood and thought this was an additional key being added just for this protocol

I added a clarification in C.3.1.

<jberman> > <@jberman> Once the wallet is restored, I would think the wallet should always need to scan the chain from then on since otherwise it would miss payments. And I'd think restoring a wallet is a pretty common thing people do, to the point that many would end up just reverting to just always scanning and the feature would end up not widely used / beneficial

<jberman> It feels like something that maybe could be worked in some way that has a good UX but it's kinda hard to see. I can only see it working well for newly generated wallets never restored. But anyone you've interacted with also can't restore their wallets to retain the UX (because if they do, then you'd need a new setup phase with [... too long, see mrelay.p2pool.observer/e/nLrD2YoLd2NiQmM2 ]

<jberman> I see your argument for including it in the spec because it's no cost

<jberman> Just trying to think about it in practice and it's hard to see

<jberman> I see how the latter is possible, but in practice I would think you'd need a perfect set of conditions for Bob to reliably retain instant sync. I'd imagine it would cause more headache than benefit

<jberman> E.g. what if Alice doesn't remember which address Bob gave him because Alice is using a new wallet too, or if Bob interacted with even 1 other person and he can't recover the old shared secret from that 1 other person

<jberman> Bob has to remember every single other account he interacted with, and if he forgets, he might miss out on payments

Yes, restoring the wallet likely breaks instant sync for that person (not everyone else). But I don't see it as a regression. People already have to scan.

And restored wallets already have some UX issues, for example the recipient info is lost (the addresses you paid to).

Also instant sync inherently can't work if you just publish an address online somewhere without binding it to a specific payment channel.

But it's still better than Monero-PSK, which can't do static addresses at all and also breaks after restoring a wallet.

<jberman> tevador: True I didn't think about this part too

<jberman> So basically when you create a new wallet, the wallet wouldn't expose "receive addresses" to you in the same way as wallets do today. If they were to, then users might think it's fine to publish the address somewhere and then they won't see any payments coming to it

<jberman> And you have to do it an interactive protocol with everyone you wanna receive money from

Yes, it would have to be a special wallet mode only available when creating a new wallet. The wallet would fall back to the normal behavior when restored from the seed or if a static address is ever generated.

<boog900> We seem to have lost some spy nodes recently: xmrnetscan.redteam.cash

<ravfx:xmr.mx> The new one left... Or are relocating or something

<ravfx:xmr.mx> mrelay.p2pool.observer/m/xmr.mx/GnSBUqXozLrRxSfXFlLesoTI.png (clipboard.png)

<ravfx:xmr.mx> Look like they brought new nodes online first then removed the old one after the migration... Just by looking at the graph, did not compare the IPs