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?

can anyone point me to a detailed document regarding the development of the DAA?

i read the section in zero to monero and it is about 3 paragraphs

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

maxwellsdemon[m]: github.com/zawy12 has done work on DAA

but monero has enough hashrate that a different DAA isn't too interesting

i dont think there has ever been a rigorous feedback control analysis on a DAA

from what ive seen its all heurisitcs

id get into it more but its really late herr getting tired ill bring it up tonorrow

<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?

willyijinin read getmonero.org/library/Zero-to-Monero-2-0-0.pdf (4.2 One-time addresses)

it even has names of cpp files and function names on the right

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

the currwnt algorithm uses a truncated moving average - and it isnt clear to me what (if any) detailed analysis was carried out

maxwellsdemon[m]: you might as well start from scratch

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

<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.

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

so if you have a MA over 10 seconds, the delay is 5 seconds

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

which is why im asking for white papers or past work

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.

kk ii saved that link you sent me

"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...

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?

what is sweep_specific? sweep_single is to move a single output

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`

for `sweep_single`

first paragraph 7.2.4 unless i am misunderstanding your writing

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.

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

does that make sense?

the lag is a sampling lag... that's all I said there

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

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

Idk lol it’s just an algorithm description. I don’t even say ‘moving average’ or anything like that.

yeah its not stated explicitally but average of last xxx blocks is the same thing, essentially.

Monero's DAA has 15 block lag

it samples block 15-734 (inclusive), if we count down from the latest block

it also throws away top and bottom 60 blocks with highest/lowest timestamps to account for invalid clock or timestamp attacks

so in the end it's 600 blocks somewhere in the middle that actually contribute to the next block's difficulty

yep. thats also what is causing the oscillations in difficulty, its a tough trade off.

<sech1> "it also throws away top and..." <- can you explain to me how this works?

dude, it is the `o` outliers in that ztm2 section

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

all blocks in the 720 block window

sgp_ the key_image is listed as a mandatory param in monerodocs, so not sure what you mean.

I'm confused then. Why is a key image required if an `account_index` and `subaddr_indicies` are allowed

I think the documentation may be slightly incorrect because it also says mixin is required, but the example doesn't send that parameter

<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

does that make sense

because timestamps are controlled by miners and they can manipulate them. Either up or down.

DAA is not just about finding a good approximation of network hashrate, it's also about resisting malicious actors