02:46:13 <willyijinin[m]> Sorry a typo above. If I got the private view key and the `stealth public key of the receiver`, how do I calculate if the output belongs to the owner of the private view key?
04:07:39 <maxwellsdemon[m]> can anyone point me to a detailed document regarding the development of the DAA?
04:08:01 <maxwellsdemon[m]> i read the section in zero to monero and it is about 3 paragraphs
04:08:45 <maxwellsdemon[m]> not a lot of work was done in this area from what i can tell with regards to looking at the system from a feedback perspective
06:40:56 <selsta> maxwellsdemon[m]: https://github.com/zawy12 has done work on DAA
06:41:23 <selsta> but monero has enough hashrate that a different DAA isn't too interesting
07:05:37 <maxwellsdemon[m]> i dont think there has ever been a rigorous feedback control analysis on a DAA
07:05:46 <maxwellsdemon[m]> from what ive seen its all heurisitcs
07:06:43 <maxwellsdemon[m]> id get into it more but its really late herr getting tired ill bring it up tonorrow
13:13:47 <willyijinin[m]> <moneromooo> "A full wallet can calculate it..." <- If I got the private view key and the stealth public key of the receiver, how do I calculate if the output belongs to the owner of the private view key?Is there a javascript method for it? or which line  in the `process_new_transaction` in wallet2.cpp does the calculation?
13:39:23 <sech1> willyijinin read https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf (4.2 One-time addresses)
13:39:46 <sech1> it even has names of cpp files and function names on the right
18:01:31 <maxwellsdemon[m]> so with regards to the DAA, I would argue it is not trivial because the entire system depends on the feedback of estimated block times
18:02:05 <maxwellsdemon[m]> the currwnt algorithm uses a truncated moving average - and it isnt clear to me what (if any) detailed analysis was carried out
18:02:52 <UkoeHB> maxwellsdemon[m]: you might as well start from scratch
18:03:34 <maxwellsdemon[m]> in this sense the monero network is a feedback system, we have a plant which is the miners and transactions, and we have the state estimator which is the truncated MA, and the feedback law is the difficulty adjustment
18:05:39 <Rucknium[m]> <maxwellsdemon[m]> "i dont think there has ever been..." <- The longer you spend in the cryptocurrency space, the more you are reminded that the field is only a decade old and there is a lot of low-hanging fruit on the research front.
18:06:39 <maxwellsdemon[m]> i found some minor incorrect statements, for example in the zero to monero book it is stated the delay of the estimate equals the number of timestamps truncated - this isnt true. It equals the midpoint of the moving average filter plus the truncated time stamps
18:07:17 <maxwellsdemon[m]> so if you have a MA over 10 seconds, the delay is 5 seconds
18:08:19 <maxwellsdemon[m]> in any event i think this could be good work and a big asset to the crypto community, but before i write a proposal i want to be 100% sure i read all relevant documentation
18:10:50 <maxwellsdemon[m]> which is why im asking for white papers or past work
18:11:49 <Rucknium[m]> Make sure you read what the BCH people have done with their DAA. Granted, Monero doesn't face the same "minority fork" issue that BCH does, but they are the only people I am aware of who have studied the issue in any depth.
18:16:48 <maxwellsdemon[m]> kk ii saved that link you sent me
18:17:05 <UkoeHB> "for example in the zero to monero book it is stated the delay of the estimate equals the number of timestamps truncated - this isnt true. " Not sure where I claimed this...
18:23:47 <sgp_> Is `sweep_single` basically `sweep_specific` at this point, because it appears one can sweep all from a specific account and even a specific subaddress? Or am I misreading monerodocs?
18:25:19 <hyc> what is sweep_specific? sweep_single is to move a single output
18:26:47 <sgp_> sweep_specific is just a name I made up. It appears from monerodocs at least that instead of passing a key image, I can pass an `account_index` and even `subaddr_indices`
18:27:06 <sgp_> for `sweep_single`
18:27:48 <maxwellsdemon[m]> first paragraph 7.2.4 unless i am misunderstanding your writing
18:28:45 <maxwellsdemon[m]> To make sure chain forks are on an even footing, we don’t sample the most recent blocks (for calculating new difficulties), instead lagging our bunch b by l. For example, if there are 29 blocks in the chain (blocks 1, ..., 29), b = 10, and l = 5, we sample blocks 15-24 in order to compute block 30’s difficulty.
18:29:33 <maxwellsdemon[m]> so you are correct that the measurements start at l, but the lag is actually this plus half the movinf average window size in time
18:29:42 <maxwellsdemon[m]> does that make sense?
18:31:02 <UkoeHB> the lag is a sampling lag... that's all I said there
18:39:43 <maxwellsdemon[m]> Yes the sampling lag is l, but this isnt equal to the estimate lag. This can be confusing to read when you jump to Rule 4. the sampling delay is L, but the measurement lag, call this m, is L+w/2 (w being MA window size). For the purposes of the DAA this is what you would care about most
18:40:42 <maxwellsdemon[m]> i understand what youre saying but the lamguage isnt precise, and maybe that is my view because i come from a control theory background and not a crypto background
18:52:07 <UkoeHB> Idk lol it’s just an algorithm description. I don’t even say ‘moving average’ or anything like that.
18:59:00 <maxwellsdemon[m]> yeah its not stated explicitally but average of last xxx blocks is the same thing, essentially.
19:10:56 <sech1> Monero's DAA has 15 block lag
19:11:26 <sech1> it samples block 15-734 (inclusive), if we count down from the latest block
19:12:19 <sech1> it also throws away top and bottom 60 blocks with highest/lowest timestamps to account for invalid clock or timestamp attacks
19:13:08 <sech1> so in the end it's 600 blocks somewhere in the middle that actually contribute to the next block's difficulty
19:17:32 <maxwellsdemon[m]> yep. thats also what is causing the oscillations in difficulty, its a tough trade off.
21:28:11 <maxwellsdemon[m]> <sech1> "it also throws away top and..." <- can you explain to me how this works?
21:28:59 <UkoeHB> dude, it is the `o` outliers in that ztm2 section
21:35:26 <sech1> maxwellsdemon I don't remember exactly, better look in the source code. IIRC it just sorts all blocks by timestamps and then cuts top and bottom 60
21:35:36 <sech1> all blocks in the 720 block window
22:59:44 <TheCharlatan> sgp_ the key_image is listed as a mandatory param in monerodocs, so not sure what you mean.
23:02:33 <sgp_> I'm confused then. Why is a key image required if an `account_index` and `subaddr_indicies` are allowed
23:11:59 <sgp_> I think the documentation may be slightly incorrect because it also says mixin is required, but the example doesn't send that parameter
23:53:02 <maxwellsdemon[m]> <sech1> "maxwellsdemon I don't remember..." <- yeah my question is more focused on why this would work over, say, filtering the 800ish blocks with a median filter of size 60 to 120, or how cutting out these blocks stops bad actors. I guess im not seeing how you would "know" the outlier blocks are necessarily bad
23:53:48 <maxwellsdemon[m]> does that make sense
23:56:53 <sech1> because timestamps are controlled by miners and they can manipulate them. Either up or down.
23:58:03 <sech1> DAA is not just about finding a good approximation of network hashrate, it's also about resisting malicious actors