hello

Ah, early Friday again! How are the view tags going?

no success until now

Aren't they... done ?

no

paste.debian.net/1245827  here are the logs but smth is not working

when i has derivation like this  keccak_256("766965775f746167"+"6dc87b9d2438452118e4e5578131ed7a42e6d10144cb0a5d275389d4d16b2c2c"+"1")

i have wrong output d908105a16f7aa8d9c61c6d3ccdcc39416f69e646774d576352bd5775dbdf09d

any suggestion on why hashing of derivation is wrong

Did you already check your keccak_256 implementation alone? Without anything Monero specific, just checking whether your hashes quite in general come out right?

yes keccak_256 is keccak_256 monero code

nothing different

monero implementation

i think that the issue come from wrong inputs

"766965775f746167"  is view_tag in hex

I checked your input with keccak-256.cloxy.net, and it indeed gives d908105a16f7aa8d9c61c6d3ccdcc39416f69e646774d576352bd5775dbdf09d

So yeah, looks like the hashing is correct, but you into it with something that you shouldn't

*go into it

Maybe stupid question, but I think I myself made that mistake at least once: If you reverse the order of the bytes, does it still not work?

And maybe even more stupid question: Are you sure you have to hex your bytes, and not go into the hashing function with the bytes itself?

the order of which bytes

of all derivation

which input

Take for example this here, 766965775f746167: That's 8 bytes, right? With 76 first and 67 last.

Are you sure that's the right way round? Maybe byte 76 has to come last, and byte 67 first?

And are you sure that you have to convert those 8 bytes into textual hex in the first place? And not go into keccak_256 directly with the 8 bytes itself?

(I am just guessing, by the way. I don't know the details myself, and also I don't know how you arrived at those strings.)

You don't just keccak_256("766965775f746167"+"6dc87b9d2438452118e4e5578131ed7a42e6d10144cb0a5d275389d4d16b2c2c"+"1") - this is a hex string, you must calculate the hash of binary data

back again

sech1 which "binary data" u mean

which input

you pass hex string to keccak_256

are you sure it's converted to binary before the hash is actually calculated?

no im not

any suggestion?

keccak_256(766965775f7461676dc87b9d2438452118e4e5578131ed7a42e6d10144cb0a5d275389d4d16b2c2c01) is c5d8d49b9c81e6aef355862eea65eeed77a0b828441c4a17119807ef09435db2

With input in binary, right?

was the view tag "c5"?

rbrunner yes, switch to hex here: onlinecodeformatters.com/keccak-256-hash and enter the data

sech1 no c5 was not view_tag

i test it

sech1: Exactly. With hex instead of bytes it's no wonder it does not yet run :)

im confused

No problem. Can happen.

 i took from here var d paste.debian.net/1245850  and hashed but c5 was not the view_tag

wait, but c5d8d49b9c81e6aef355862eea65eeed77a0b828441c4a17119807ef09435db2 can be found in your own paste paste.debian.net/1245827

so c5 is the correct view tag

that log is from monerod working without my intervention!

which means it's correct

paste.debian.net/1245850   this one is that im trying manually to create a view_tag

yes sech1

and failing manually!

derivation D = 7b0a76d852af2beffda86cc575622a0c4f89382cc878d8f19b71b730aaded019 in your paste, so, for output index 0: keccak_256(766965775f7461677b0a76d852af2beffda86cc575622a0c4f89382cc878d8f19b71b730aaded01900) = 3107be1cb24d830c6e57dc440d7fbe13847a93726a1a91dd4781339a7c294b4a

view tag "31"

and aed584fb42499c69c00002a5dfaae784811a9b145f0b68e0258b2eb93d1eef8b for output index 1, view tag "ae"

i insert both "ae" and "31" and didnt work!

i test this view_tag

maybe you need to take "f". keccak_256(766965775f746167266020a292487e9cd62d0f8de7e08aa3f81c2426c16f1f25ff55b56506c03b0200) = 0ea272b731c9902d40aca9b60eff082b04133a37ba45e4032be92e41b8118332, did you try "0e"?

this one no wait to give atry

is output index 0 in your test?

yes

actually no, var D = generate_key_derivation(A, r); "7b0a76d852af2beffda86cc575622a0c4f89382cc878d8f19b71b730aaded019" is what you must use when calculating view tags

so keccak_256(766965775f7461677b0a76d852af2beffda86cc575622a0c4f89382cc878d8f19b71b730aaded01900) = 31... must be correct, view tag "31"

well i insert "31" and was not recognized

well search for bug in another place

was ok for monerod but not for wallet2

u can c view_tag "31" on daemon but is not recognized from wallet-cli

anyway in monerod what ever u insert as view tag is recognized

where you insert it, monerod doesn't care about view tags. It doesn't have private view key to begin with, it can't check view tags

again 0e was not recognized

how to be sure that 31 is the right view_tag

and smth else is happening

man. my poor laptop has all these old versions of monero-gui on it and the one i just launched was like v0.13 and apparently it likes to keep monerod running even after u quit.

i need a fresh OS install.

what do you mean "not recognized from wallet-cli"? Where do you enter all data, did you modify the code? Or do you just scan the blockchain?

is new chain and block 0 is not recognized

if i insert old version 14 without view_tag everything work

then add logging to wallet-cli to see what derivation and view tag it calculates

I don't understand why I am not seeing my transactions an balance right, even though I have 130GB of the blockchain installed into ~/.bitmonero

I have `refresh-from-block-height = 1140000`, which is lower than some transactions I would expect, and I am using `monero-wallet-cli`

I see now that `bc_height` is slowly increasing, everytime I run it again it is a bit bigger

but I don't understand, if this is right I am supposed to wait a long time to see my balance every time I restart `monerod` or `monero-wallet-cli`

nope, once wallet is synced it's synced to that point

yep, just found out the issue: I was using the wrong, mistakenly created wallet :facepalm: