08:39:48 <lagoon93> hello
08:58:48 <rbrunner> Ah, early Friday again! How are the view tags going?
09:03:33 <lagoon93> no success until now
09:09:42 <moneromooo> Aren't they... done ?
09:10:20 <lagoon93> no
09:14:05 <lagoon93> http://paste.debian.net/1245827/  here are the logs but smth is not working
09:17:27 <lagoon93> when i has derivation like this  keccak_256("766965775f746167"+"6dc87b9d2438452118e4e5578131ed7a42e6d10144cb0a5d275389d4d16b2c2c"+"1")
09:17:42 <lagoon93> i have wrong output d908105a16f7aa8d9c61c6d3ccdcc39416f69e646774d576352bd5775dbdf09d
09:35:07 <lagoon93> any suggestion on why hashing of derivation is wrong
09:40:12 <rbrunner> Did you already check your keccak_256 implementation alone? Without anything Monero specific, just checking whether your hashes quite in general come out right?
09:43:40 <lagoon93> yes keccak_256 is keccak_256 monero code
09:43:45 <lagoon93> nothing different
09:43:50 <lagoon93> monero implementation
09:44:23 <lagoon93> i think that the issue come from wrong inputs
09:46:23 <lagoon93> "766965775f746167"  is view_tag in hex
09:59:39 <rbrunner> I checked your input with https://keccak-256.cloxy.net/, and it indeed gives d908105a16f7aa8d9c61c6d3ccdcc39416f69e646774d576352bd5775dbdf09d
09:59:57 <rbrunner> So yeah, looks like the hashing is correct, but you into it with something that you shouldn't
10:00:15 <rbrunner> *go into it
10:02:36 <rbrunner> 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?
10:11:16 <rbrunner> 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?
10:36:49 <lagoon93> the order of which bytes
10:36:58 <lagoon93> of all derivation
10:37:03 <lagoon93> which input
10:42:25 <rbrunner> Take for example this here, 766965775f746167: That's 8 bytes, right? With 76 first and 67 last.
10:42:45 <rbrunner> Are you sure that's the right way round? Maybe byte 76 has to come last, and byte 67 first?
10:43:26 <rbrunner> 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?
10:44:42 <rbrunner> (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.)
11:54:19 <sech1> You don't just keccak_256("766965775f746167"+"6dc87b9d2438452118e4e5578131ed7a42e6d10144cb0a5d275389d4d16b2c2c"+"1") - this is a hex string, you must calculate the hash of binary data
13:50:43 <lagoon93> back again
13:50:59 <lagoon93> sech1 which "binary data" u mean
13:51:03 <lagoon93> which input
13:52:02 <sech1> you pass hex string to keccak_256
13:52:14 <sech1> are you sure it's converted to binary before the hash is actually calculated?
13:52:30 <lagoon93> no im not
13:56:35 <lagoon93> any suggestion?
13:58:34 <sech1> keccak_256(766965775f7461676dc87b9d2438452118e4e5578131ed7a42e6d10144cb0a5d275389d4d16b2c2c01) is c5d8d49b9c81e6aef355862eea65eeed77a0b828441c4a17119807ef09435db2
13:59:05 <rbrunner> With input in binary, right?
13:59:05 <sech1> was the view tag "c5"?
13:59:26 <sech1> rbrunner yes, switch to hex here: https://onlinecodeformatters.com/keccak-256-hash and enter the data
13:59:52 <lagoon93> sech1 no c5 was not view_tag
13:59:56 <lagoon93> i test it
14:00:41 <rbrunner> sech1: Exactly. With hex instead of bytes it's no wonder it does not yet run :)
14:01:03 <lagoon93> im confused
14:03:24 <rbrunner> No problem. Can happen.
14:03:41 <lagoon93>  i took from here var d http://paste.debian.net/1245850/  and hashed but c5 was not the view_tag
14:04:00 <sech1> wait, but c5d8d49b9c81e6aef355862eea65eeed77a0b828441c4a17119807ef09435db2 can be found in your own paste https://paste.debian.net/1245827/
14:04:19 <sech1> so c5 is the correct view tag
14:04:46 <lagoon93> that log is from monerod working without my intervention!
14:04:56 <sech1> which means it's correct
14:05:09 <lagoon93> http://paste.debian.net/1245850/   this one is that im trying manually to create a view_tag
14:05:22 <lagoon93> yes sech1
14:05:36 <lagoon93> and failing manually!
14:07:04 <sech1> derivation D = 7b0a76d852af2beffda86cc575622a0c4f89382cc878d8f19b71b730aaded019 in your paste, so, for output index 0: keccak_256(766965775f7461677b0a76d852af2beffda86cc575622a0c4f89382cc878d8f19b71b730aaded01900) = 3107be1cb24d830c6e57dc440d7fbe13847a93726a1a91dd4781339a7c294b4a
14:07:10 <sech1> view tag "31"
14:07:28 <sech1> and aed584fb42499c69c00002a5dfaae784811a9b145f0b68e0258b2eb93d1eef8b for output index 1, view tag "ae"
14:08:00 <lagoon93> i insert both "ae" and "31" and didnt work!
14:08:12 <lagoon93> i test this view_tag
14:09:24 <sech1> maybe you need to take "f". keccak_256(766965775f746167266020a292487e9cd62d0f8de7e08aa3f81c2426c16f1f25ff55b56506c03b0200) = 0ea272b731c9902d40aca9b60eff082b04133a37ba45e4032be92e41b8118332, did you try "0e"?
14:09:39 <lagoon93> this one no wait to give atry
14:09:57 <sech1> is output index 0 in your test?
14:10:13 <lagoon93> yes
14:13:01 <sech1> actually no, var D = generate_key_derivation(A, r);  "7b0a76d852af2beffda86cc575622a0c4f89382cc878d8f19b71b730aaded019" is what you must use when calculating view tags
14:13:55 <sech1> so keccak_256(766965775f7461677b0a76d852af2beffda86cc575622a0c4f89382cc878d8f19b71b730aaded01900) = 31... must be correct, view tag "31"
14:14:20 <lagoon93> well i insert "31" and was not recognized
14:14:35 <sech1> well search for bug in another place
14:14:39 <lagoon93> was ok for monerod but not for wallet2
14:15:37 <lagoon93> u can c view_tag "31" on daemon but is not recognized from wallet-cli
14:16:05 <lagoon93> anyway in monerod what ever u insert as view tag is recognized
14:16:49 <sech1> 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
14:24:28 <lagoon93> again 0e was not recognized
14:25:35 <lagoon93> how to be sure that 31 is the right view_tag
14:25:41 <lagoon93> and smth else is happening
14:32:50 <gingeropolous> 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. 
14:32:55 <gingeropolous> i need a fresh OS install.
14:35:20 <sech1> 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?
14:50:03 <lagoon93> is new chain and block 0 is not recognized
14:50:27 <lagoon93> if i insert old version 14 without view_tag everything work
14:56:45 <sech1> then add logging to wallet-cli to see what derivation and view tag it calculates
17:10:43 <zluoq> 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
17:11:52 <zluoq> I have `refresh-from-block-height = 1140000`, which is lower than some transactions I would expect, and I am using `monero-wallet-cli`
17:12:22 <zluoq> I see now that `bc_height` is slowly increasing, everytime I run it again it is a bit bigger
17:12:53 <zluoq> 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`
17:21:33 <Majesticbank> nope, once wallet is synced it's synced to that point
17:25:56 <zluoq> yep, just found out the issue: I was using the wrong, mistakenly created wallet :facepalm: