--- Log opened Mon May 13 00:00:54 2024
03:01 < josie> setavenger: my concern with the electrum over tor approach is that you are revealing interest in a particular UTXO, whereas with filter based approaches you only revealing interest in a block 
03:03 < josie> its certainly a viable approach to use electrum as a backend, but I wouldn't recommend it for a wallet focused on privacy. Adding tor doesn't really solve the privacy problems but does degrade the user experience
04:22 < setavenger> josie: that's a fair point, I understand where you are coming from. This reopens the question how one can track the spent_unconfirmed outputs across instances (full rescan/recover or same wallet on more than one device). Is there any existing concept for tracking the mempool without showing a particular interest in a UTXO/txid?
04:27 < setavenger> Getting the final spent_confirmed state via filters and 8byte hash comparisons seems very feasible. Just not sure about the spent_unconfirmed tracking options
05:26 < josie> if im following, the problem is you have wallets A and B, wallet A spends utxo a, but until confirmed wallet B might also try to spend utxo a?
05:28 < josie> i think this is a general problem for all light clients, and the only solution would be having a way to privately query a nodes mempool or have the light client run their own mempool, which doesn't seem feasible for a mobile phone
05:32 < josie> im also not sure its a problem that needs to be solved? lets say someone does create a tx in wallet A, then try to spend the same utxo in wallet B: nodes would reject the tx when wallet B tries to broadcast, or eventually one of the 2 txs will confirm
05:33 < setavenger> yes that's the problem I'm seeing. One could even just say for now we only allow one device (I think that's a thing with lightning as well). but then recovering the wallet is still not covered. If a UTXO is stuck in the mempool it will be shown as unspent until confirmed which could be in a far future.
05:34 < josie> yeah, i dont think it even makes sense to recommend running the same wallet on multiple devices as a light client. for recovering, i still think this okay: a utxo is in fact unspent until it is confirmed :) 
05:35 < josie> imagine i send a tx1 with too low of a fee in device A, and then need to recover this wallet on device B while tx1 is still unspent: seems better to allow wallet B to try and spend that UTXO with a higher fee
05:39 < josie> i think this is a lot less scary in a full-rbf world: if tx1 is stuck from wallet A, i can RBF it from wallet B so long as im paying a higher fee 
05:40 < josie> granted everything im saying is under the assumption that this is an edgecase and the user is not actively managing two wallets with the same seed phrases / key info. i think we should be clear that light clients should never do this.
05:44 < setavenger> yeah so this would require Full RBF or that the wallet enables RBF by default. I think that's a good solution. Having multiple instances complicates things by a lot, quite unnecessarily as well. I will mark that in the light client specification notes I'm currently drafting up.
06:07 < josie> awesome! perhaps worth mentioning that if someone does have a usecase where they want to run multiple instances of the same wallet, the solution is for them to run their own fullnode. that way, they can manage state across multiple clients easily since privacy against the full node is no longer a concern
06:38 < setavenger> Yup, once you are in a trusted environment those restrictions become obsolete. I guess once you run a full node you are not a real light client anymore. This probably applies more to trusted setups I think.
15:09 -!- S3RK_ [~S3RK@user/s3rk] has quit [Ping timeout: 268 seconds]
15:10 -!- S3RK [~S3RK@user/s3rk] has joined #silentpayments
15:45 -!- S3RK [~S3RK@user/s3rk] has quit [Ping timeout: 260 seconds]
15:46 -!- S3RK [~S3RK@user/s3rk] has joined #silentpayments
--- Log closed Tue May 14 00:00:55 2024