--- Log opened Wed Jan 11 00:00:14 2023
02:45 < josie> Murch1: the light client would still need 32 bytes per potential transaction to do the tweaking, but these could be requested from anyone. The flow I'm envisioning is a light client restores from a master seed backup, and then starts requesting 32 bytes per eligible transaction, where an eligible transaction is any transaction with at least one taproot unspent output and the unspent output
02:45 < josie> was created after the wallet birthday. the light client performs the tweaks using the requested data and then uses client-side block filters to determine if any of the scriptPubKeys appear in a block. 
05:26 < Murch1> Uh, but it requests 32 B for specific transactions?
05:27 < Murch1> For basically any transaction that has a P2TR output?
06:06 < josie> yep, in the simplest case, the Bob creates an output in the following way: `A' = hash(hash(txid, vout)*B*A))*G + A`, where B is the pubkey of the input Bob is using to fund the tx to Alice and txid,vout are the txid and vout for the prevout B. Alice detects this by computing `A' = hash(hash(txid,vout)*(B*a))*G + A`. So if Alice is a light client (e.g doesn't have access to the full
06:06 < josie> blockchain), she needs to get `hash(txid,vout)*I` (32 bytes per tx) for all transactions which she thinks might be a silent payment to her. In the current proposal, this would be any transaction with at least one P2TR output AND the output is also unspent. 
06:11 < josie> assuming every single tx has at least one unspent p2tr output, this would be roughly 10mb per day sent to the light client (2,000 txs per block * 144 blocks per day * 32 bytes per tx). in reality, p2tr outputs are currently 1%, so the scanning requirement today for a light client would be roughly 1% of 10mb
06:11 < josie> s/1%/1% of all outputs per day/
06:47 < Murch1> Just asking for all transactions with unspent P2TR outputs would be a privacy leak, though, and I would not expect to be able to determine from the block filter whether outputs are P2TR and especially whether they remain unspent. So would privacy sensitivity not relegate the light client to essentially parse all blocks after the wallet's birthdate for recovery?
07:43 < josie> Murch1: just to be clear, the tweak data is not requested via block filters (though it maybe be possible?). How a light client requests the tweak data still needs to be defined. After the light client has requested the tweak data and computed the tweaks, then the light client uses block filters to determine if any of the computed tweaks are present in a block as an output.
07:45 < josie> regarding privacy, the client will have already revealed they are likely scanning for silent payments just by asking for the tweak data and since, in the current scheme, silent payment outputs are p2tr, there would be no additional loss of privacy to only request the tweak data for txs with an unspent p2tr output
07:52 < Murch1> My point is that requesting the tweak data is a privacy leak
07:52 < Murch1> Yes, you do not reveal what addresses you are interested in, but you do reveal that you participate in Silent Payments.
07:54 < josie> Murch1: we agree here. because the tweak data is specific to silent payments, it necessarily reveals you are scanning for silent payments, unless we can find a way to hide it or derive it from another source that is also used for other things
08:13 < josie> the more I think about the privacy leak, I think this is acceptable. I can't think of a reason to hide the fact that you participate in silent payments, especially considering that one of the main benefits of silent payments scheme is that you can post your silent payments address in a public place for others to discover it without interacting with you.
08:15 < josie> the only damaging info we'd be leaking as a light client would be a wallet fingerprint if there are only one or two mobile wallets which support silent payments
08:18 < Murch1> Uh, doesn't that make it even worse? There is likely a tiny subset of users that participate in Silent Payments, especially when it first comes out. Some of these users post their identifier publicly, and now you can tie any light client that asks for tweak information to be part of this small user base some of which are publicly identifiable.
08:20 < Murch1> TBH, identifying that your light client participates in Silent Payments is pretty terrible, unless it rolls out with plausible deniability such as a lot of wallet software always requesting this data even if they do not actively participate in Silent Payments.
08:21 < Murch1> If I were running a light client that can use Silent Payments, I think I'd rather download and parse all blocks whenever my phone is connected to power and on WIFI than reveal that I'm interested in Silent Payments.
08:22 < Murch1> * parse all remaining blocks whenever
08:50 < josie> Murch1: downloading all blocks would certainly be an option, although I think this would make you more of a "pruned full node on a phone," which at that point I think it would be better to just run a full node and connect your phone directly to it (something like FullyNoded).
08:52 < josie> I also agree with the concern of putting yourself into a small anonymity set if you are an early adopter. The part I am not convinced of is that revealing you participate in silent payments is any worse than revealing you use bitcoin
--- Log closed Thu Jan 12 00:00:13 2023