--- Log opened Thu Apr 25 00:00:37 2024
00:42 < josie> setavenger: the transaction should be scanned as long as it has at least one unspent output, but when scanning a transaction you have to include *all* taproot outputs (spent or unspent). glad you mentioned this, because in the BIP it says "Let outputs_to_check be the taproot output keys from all unspent taproot outputs in the transaction"
00:43 < josie> this should instead say something like "Let outputs_to_check be the taproot keys from all taproot outputs in the transaction"
00:44 < josie> regarding labels, if you aren't using the subtraction technique (which requires access to the outputs), then you have to check every label you might have handed out. for the change label, this is fine because you know there is only one to check. but for mobile, this is why i recommend not using labels beyond just the change label because as soon as the phone starts handing out a large
00:44 < josie> number of labels, they have to check every single one on each transaction
00:56 < setavenger> josie: thanks for the clarification, I'll adjust the indexing server accordingly. 
00:59 < setavenger> Re: labels. I think one has to scan all labels regardless of which method one uses or at least check for a match. But I guess subtraction and matching is not as intensive as producing all possible label combinations beforehand. Currently also working on a desktop extendable cli wallet as well, so this is not limited to mobile.
01:06 < josie> the optimization using the subtraction technique is that you can first get what the label might be (i.e. tx_output - P) and then check if that potential label is in your list of labels you've handed out
01:06 < josie> so if you have millions of labels, you do one subtraction and then a lookup in a labels cache, which is faster than checking 1M labels 
01:39 < setavenger> yeah, that is a lot more efficient. Although it does mean that you have to scan every block. I'm still on the fence which general flow is more efficient. Using taproot-only filters or just scanning. I guess it depends on the number of labels one has and the number of expected payments.
05:04 < josie> setavenger: yeah, i feel pretty comfortable saying that if you are not running a full node, you probably shouldn't be using labels. or if you do use them, max 3 or something like that
05:31 < setavenger> josie: I would definitely agree if it comes to periodic scanning, on weaker devices. I'm currently working on a daemon which acts like a light client but could run in the background on a desktop or server. Not 100% sure but in that case the issue with precomputing many labels for filters would not be as big (as long as we are not talking about 1M labels). 
05:31 < setavenger> Thinking more about it, one could even skip the filters, try every block and just match labels with subtraction.
06:34 < setavenger> josie: may I suggest a modification to one of the test vectors? The vector "Simple send: two inputs from the same transaction" is probably there to check whether the correct smallest outpoint is used. I noticed that it does not matter whether one looks at the byte serialisation or just the number itself (e.g. `0x03000000 < 0x07000000 == 3 < 7`). 
06:34 < setavenger> Looking at some actual data there are also cases like this one: `0x7f010000 < 0x88000000 != 383 < 136`. Modifying the vouts in that test vector could help developers avoid a mistake. One might accidentally order by txid:vout_as_int and would get passing vectors.
07:57 < josie> setavenger: good suggestion, if you have some outpoint data i can use id be happy to add it in a test. i can also look at modifying one of the tests where only sorting by the lexicographical byte order will yield the correct result 
08:08 < setavenger> josie: I'll have a poke at a test vector, unless there was a specific reason for the vout numbers in "Simple send: two inputs from the same transaction", I would just change that vector to use the vout numbers above and recompute the vector
08:09 < setavenger> or actually create a variation of that test vector
08:34 < setavenger> josie: I think the reference implementation might need a change as well. Seems like here https://github.com/josibake/bips/blob/57c89ae162b4dab971dc6061ba6acf7d676781ea/bip-0352/reference.py#L85 it does (txid, vout) instead of (txid || vout)
09:28 -!- Netsplit *.net <-> *.split quits: harding
09:30 < setavenger> https://github.com/josibake/bips/pull/12 I adjusted the reference implementation to sort lexicographically and added the new test vector that will fail if this is not done according to the BIP.
09:32 -!- harding [quassel@newmail.dtrt.org] has joined #silentpayments
09:35 < josie> setavenger: thanks! will take a look and try to get this merged in tomorrow. also thanks again for helping test, really great to be finding these edge cases 
09:36 < josie> iiuc, this was causing the different between yours and sjor's indexers? 
09:48 < setavenger> josie: Happy to help! 
09:48 < setavenger> It was yeah, making that change should give him the same result.
--- Log closed Fri Apr 26 00:00:38 2024