11:35:36 <rbrunner> Can I see somehow in the CLI wallet or over wallet-RPC in an easy way which of my outputs were "consumed" to build a certain outgoing tx? After checking I would guess not, but maybe I overlook something.
12:04:14 <selsta> Did we find the cause for this locale issue?
12:04:33 <selsta> AFAIK hyc you looked into it but don’t remember further.
12:29:02 <moneromooo> I need someone who can repro it to get me stack trace.
12:30:10 <selsta> fluffypony: ^
12:30:41 <moneromooo> fluffypony could repro it, but did not have libunbound compiled in.
12:30:45 <fluffypony> I think I'd have to take a seed node down just to repro it
12:30:47 <fluffypony> will see if I can repro it on a different box
12:31:25 <moneromooo> I guess since it's at the start, gdb + catch throw should work.
14:11:59 <hyc> the strace that fluffy posted before, showing attempt to open locale DBs, didn't match my own local run
14:12:17 <hyc> in my own run those locale calls didn't happen
14:12:35 <lh1008> Hello everyone :)
14:14:36 <hyc> but maybe we can make this go away by just adding setlocale(LC_ALL, "C") at startup
14:16:40 <lh1008> Giving an update about the issue we had using the monero-wallet-cli for the RPC-pay node. The errors has removed. Like selsta and moneromooo pointed out. The wallet and the daemon had to be executed with the `--log-level 2` option. I created a new wallet and synced from scratch. It did took more time and the `start_mining_for_rpc` clutched very
14:16:41 <lh1008> often (it stopped without reaching the credits), I had to restart it several times but it finally synced completely.
14:18:56 <lh1008> When I finally reached the last block I added the options that were sending me the error (`inactivity-lock-timeout 0` and `persistent-rpc-client-id 1`) and it was okay, no error.
14:20:54 <lh1008> Thank you for your support and help, very pleased :). I'll be closing the issue but leaving a side note about the `--log-level 2` daemon and wallet execution. Another day I'll come and ask about --log-level 2, have to go.
14:20:58 <lh1008> Bye :)
14:34:01 <moneromooo> I missed that strace log.
15:57:49 <peach34> hi
15:58:12 <peach34> Any Monero cryptographers about?
15:58:21 <peach34> research team
16:02:09 <moneromooo> Ask a monero related crypto question, and someone who knows will answer when they read.
16:02:18 <peach34> ok
16:03:03 <peach34> Stealth adresses are computed : P=H(rA)G+B, we may fake an outproof by choosing a fake A' and rearranging P-H(rA') = B'
16:03:36 <peach34> Why can't we pick a fake private spend key b' and derive A' from it such that we can later compute the output private key with the said b'
16:03:47 <peach34> and spend the output
16:13:56 <peach34> in full:
16:14:28 <peach34> P = H(rA) + B
16:15:14 <peach34> b' ---> A', B'
16:15:28 <peach34> P - H(rA') = B'
16:16:10 <peach34> spend via: xP where x = H(rA') + b'
16:16:57 <peach34> (i forgot the G's in the first two lines)
16:19:56 <Ymgve> isn't rA the receiver's public key
16:20:07 <peach34> no it's the shared secret
16:23:15 <peach34> rA=aR
16:25:57 <Ymgve> I think B' doesn't match the recipient's public spend key B, so it's not their money
16:28:08 <Ymgve> if your goal is to defraud someone with the public keypair (A, B), it is kinda a requirement that you send the money to (A, B)
16:28:25 <peach34> Answer is not good enough sorry
16:29:00 <Ymgve> what's the attack scenario though? how does this defraud someone with the keypair (A, B)
16:30:14 <peach34> attack scenario: someone can spend a given output on the chain by manipulating the mathematics
16:30:53 <Ymgve> your manipulation of mathematics creates a completely new keypair as far as I can tell
16:30:59 <peach34> I'm looking for the mathematical reasoning. I'm not saying I have cracked Monero
16:31:26 <peach34> I know it does, but one that satisfies P=H(rA)G+B
16:31:43 <Ymgve> A and B is fixed, only r is variable
16:31:43 <peach34> for which you know b'  and can therefore spend P
16:32:00 <peach34> But here's the thing
16:32:10 <peach34> https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf
16:32:19 <peach34> read page 79, the footnote
16:33:11 <peach34> You can deceive somebody by choosing a fake A' and B'. So that when you pass them A' and B', they can recover P via P=H(rA)G+B
16:33:57 <peach34> so why can't I instead take a b' of my choosing, derive A' and then do the same thing
16:34:43 <Ymgve> then you created a new address
16:34:52 <peach34> no
16:35:02 <peach34> That's the whole point of the deception
16:35:18 <peach34> There are many A and B such that P=H(rA)G+B
16:35:25 <peach34> That's what the footnote is saying
16:35:36 <Ymgve> yes, but there is only one pair of (A,B)
16:35:38 <peach34> no
16:36:01 <peach34> read the footnote
16:36:18 <Ymgve> the footnote requires the _recipient_ to be in on it as far as I can tell
16:36:22 <peach34> nope
16:37:09 <Ymgve> "However, a prover and recipient could collaborate"
16:37:25 <peach34> That is for the extra bit
16:37:26 <Ymgve> you still haven't described a real attack scenario
16:37:33 <peach34> please stop talking lol
16:37:46 <peach34> Unless you are prepared to show me maths
16:38:18 <Ymgve> maths: (A, B) != (A', B')
16:38:44 <peach34> sorry please stop lol
16:38:51 <peach34> 5=1+4
16:38:55 <peach34> 5=3+2
16:39:00 <peach34> Do you understand?
16:39:17 <Ymgve> yes, but "1+4" is a different string than "3+2"
16:39:34 <Ymgve> you are not sending to P, you are sending to the pair (A, B)
16:39:36 <peach34> You don't understand the question
16:39:54 <peach34> :')
16:40:21 <Ymgve> yes, I don't, and you haven't explained why it could be used to steal anything
16:40:28 <peach34> yes i have
16:40:35 <peach34> someone will explain soon, thanks for trying
16:40:47 <Ymgve> ok, my public key is (A, B), how do you defraud me
16:41:25 <peach34> I don't have time to do this with you sorry
16:41:42 <peach34> will wait for Surang
16:41:58 <Ymgve> sure
16:42:06 <moneromooo> sare.
17:27:14 <Ymgve> peach34: looking closer at what you wrote, could you explain this step " b' ---> A', B' "
17:28:10 <Ymgve> are you saying A' and B' are derived from b' in some way?
17:29:47 <UkoeHB__> peach34: #monero-research-lab is more appropriate; however, `P = H(rA)G + B` to `P - H(rA')G = B'`... you won't know `b'` unless you know `b`, but if you know `b` then you can spend the output anyway; in the first place, `rA` is just a helpful tool for recipients to identify owned output; the one-time address private key `ko` is agnostic to how it is computed (whether by `H(rA') + b'` or `H(rA) + b`
17:32:05 <UkoeHB__> in ZtM2 pg 79 footnote 7, the malicious prover does not know `k's`, he is just providing `K's` straight up
17:32:18 <peach34> UkoeHB__ is that true though? If I pick an A' for which I already know the b'
17:32:52 <peach34> yes UkoeHB__ i'm aware of that ... I'm talking about building on that idea
17:32:55 <UkoeHB__> writing `P - H(rA')G = B'` is not enough; how do you know `B' == b'*G`?
17:33:31 <peach34> you can readily derive a given A' from a b'
17:33:46 <peach34> All keys can be derived from a private spendkey
17:33:54 <peach34> So pick a b'
17:34:46 <Ymgve> but A' is made from a' not b'
17:34:48 <UkoeHB__> instead, `B' = (H(rA)G + B) - (H(rA')G)` implying `b' = H(rA) + b - H(rA')`; however you don't know `b` so `b' != your b'`
17:34:57 <peach34> you can derive it though
17:35:01 <peach34> so pick any b'
17:35:06 <peach34> derive the corresponding A'
17:35:48 <peach34> and B'
17:36:01 <peach34> then you know an A' and B' which satisfy P
17:36:21 <Ymgve> that's a different B' from the one you derived from b'
17:36:23 <peach34> but you also have the b'
17:36:24 <Ymgve> P - H(rA') != your calculated B'
17:36:41 <Ymgve> P - H(rA') = B'' but how do you know B
17:36:48 <Ymgve> P - H(rA') = B'' but how do you know B' == B''
17:38:13 <UkoeHB__> yeah, your pre-computed `B'` won't show up from `P - H(rA')` just because you hope it will
17:39:35 <UkoeHB__> instead it will be 'some point' `B''`, whose private key is `H(rA) + b - H(rA')`, but `b` is unknown so `b''` is also unknown
17:43:22 <peach34> UkoeHB__ understood so far. Can you explain why the precomputed B' does not show up
17:43:33 <Ymgve> why _would_ it show up
17:44:57 <peach34> when you choose an A' to deceive someone of the dest address, you feed it into P - H(rA') to get a B'  (ie a corresponding view and spend key)
17:45:24 <Ymgve> _a_ B'
17:45:33 <Ymgve> not _your_ precomputed B'
17:45:44 <peach34> yes.... bear with me
17:45:53 <Ymgve> if you rename the variable and say P - H(rA') = X, what's your proof that X = your precomputed B'
17:47:32 <peach34> Keys are linked and you can derive all of the keys from a single b' of your choice .... if you choose a b' randomly, you get a corresponding A' , a' and B'
17:48:11 <Ymgve> but then you get P' = H(rA') + B'
17:48:18 <peach34> So what I'm trying to understand is, if you did that, and that A' was fed into P - H(rA'
17:48:20 <Ymgve> there's nothing that says P == P'
17:49:12 <peach34> why does your B' not come out the other side
17:49:21 <Ymgve> because you changed A'
17:50:54 <peach34> That's not an answer lol
17:52:00 <Ymgve> if you rename the variable and say P - H(rA') = X, what's your proof that X = your precomputed B'
17:52:02 <UkoeHB__> `P` is just some point, and `H(rA')G` is another point unrelated to `P`, so `P - H(rA')G` will be just another point; I'm confused why you expect `B' + H(rA')G` to equal `P`, when `B'` and `A'` are unrelated to P
17:56:29 <peach34> P - H(rA')G = public spend key        is what is being done in the deception bit in the footnote right
17:56:38 <UkoeHB__> it's easier to think in terms of private keys; `P = p*G`,  `p = b + H(rA)`, `p - H(rA`) = x`, `x = b + H(rA) - H(rA')`, so if you want `b'` to equal `x` then you need to know `b` somehow
17:57:06 <peach34> P = H(rA')G = B'
17:57:11 <peach34> sorry
17:57:29 <Ymgve> that footnote is about a sender and receiver cooperating to decive a third party, if I'm reading it correctly
17:57:31 <peach34> P - H(rA')G = B'     is mentioned in footnote
17:57:41 <peach34> correct
17:57:46 <UkoeHB__> yes, but the deceiver doesn't know `b'`
17:57:58 <UkoeHB__> he is just sending `B'` to the verifier directly
17:58:15 <UkoeHB__> (or the verifier is deriving it directly)
17:58:40 <peach34> UkoeHB__ understood, but I'm saying what if the fake A' he fed into P - H(rA')G = B' had been derived from a chosen b'
17:58:54 <UkoeHB__> you have a circular dependency
17:59:26 <UkoeHB__> and some other problems...
17:59:41 <peach34> ok so where does the idea break down
17:59:46 <peach34> I pick b', i derive A'
17:59:51 <peach34> from b'
18:00:28 <peach34> why does the B' that comes out of P-H(rA')G not correspond to the b' i chose
18:00:50 <Ymgve> why would it
18:01:00 <peach34> Ymgve please shut up lol
18:01:09 <peach34> I'm not saying it does. I'm just trying to understand why it doesn't
18:01:30 <Ymgve> because it is not a B' that comes out it is a X
18:01:37 <UkoeHB__> `P - H(rA')G = B'`: assume you have `b' = B` and `P`, you need an `A'` that works; how do you even start? `P - B' = H(rA')G`, then somehow solve the DLP for `H(rA')`, then perform a preimage attack on the hash function, then solve the DLP for `ra'G`, then solve the DLP for the transaction public key `rG` to get `a' = ra'/r`
18:01:40 <peach34> shh please
18:02:36 <UkoeHB__> `b'G = B'` sorry
18:03:42 <UkoeHB__> well if you just want to spend it then all you have to do is solve the DLP for `H(rA')
18:03:53 <UkoeHB__> `a'` isn't really necessary
18:06:37 <peach34> I was more talking about taking the A' corresponding to the b'
18:06:54 <UkoeHB__> why does it have to correspond? that is just a convention with no deeper meaning
18:07:18 <UkoeHB__> aside from convenience
18:07:32 <peach34> Because if you loose all of your monero keys, you can derive them all from b'
18:07:54 <UkoeHB__> sure... `a' = H(b')`
18:08:25 <UkoeHB__> `a'` might as well be random
18:08:39 <Ymgve> in really simple terms, let's say the derivation function is A = b*5 and B = b*4, then someone has A=30 and B=24 and P = A+B => 54 = 30 + 24      - you pick b' = 2 get A' = 10 and B' = 8 and plug in P - A' = B'' and you get 54 - 10 = 44  and you have B'' != B'
18:09:34 <Ymgve> because the result of P - H(rA')G is not actually B'
18:11:36 <UkoeHB__> the relationship (if there is one) between `a'` and `b'` is completely irrelevant to `P`
18:14:05 <peach34> so technically, two people can share the same view keypairs, but have different spend keypairs?
18:14:39 <peach34> ie two monero addresses that have in them the same view key?
18:14:52 <Ymgve> yes but that's not related to why your logic fails
18:16:45 <peach34> Ymgve no it is... that solves my dilemma
18:17:21 <Ymgve> there isn't anything in the protocol that says that a thus A has to be derived from b either, the two private keys can be completely separate
18:17:24 <peach34> because I was assuming that choosing a b' and feeding the corresponding A' in would give you the B' for b'
18:17:33 <peach34> But it could be anything that pops out
18:17:49 <peach34> Because A' isn't mutually exclusive to any one B'
18:18:23 <peach34> I thought that there was a mapping of one A to one B
18:18:35 <peach34> But there isn't. That is what I was missing
18:18:42 <Ymgve> you still don't understand, the thing that comes out is only B' because you called it that, it is not true even IF there was a 1:1 correspondence
18:20:08 <UkoeHB__> peach34: yes, although I wonder if you are missing some other aspects of elliptic curve cryptography that led to the misunderstanding
18:21:43 <peach34> nah I do understand now
18:22:27 <peach34> because when the deceiver is doing P - H(rA) , they are just geting an ec point, which they *present* as the public spendkey
18:23:45 <UkoeHB__> glad we got it sorted
18:24:51 <peach34> yeah thanks
18:50:30 <UkoeHB__> peach34: also, for future reference, please direct cryptography questions to #monero-research-lab
19:32:47 <sethsimmons> High DPI support for the 17.1.5 GUI is gorgeous, thanks for fixing that all
19:36:01 <selsta> Now only Windows high DPI is missing
19:36:20 <sethsimmons> I've never used it on 4k+, but 1440p looks great already
19:50:42 <sech1> I've never used GUI, but I can test it on my 4K TV
19:52:11 <selsta> should look fine if you use Linux
20:41:32 <selsta> .merges
20:41:32 -xmr-pr- 6747 6826 6829 6830 6849 6856 6858 6873 6892 6895 6897 6898 6903 6913 6915 6920 6921 6922 6924 6933 6937 6939 6943 6949 6954 6960 6971 6973 6995 6999 7008 7018 7020 7021
20:41:46 <selsta> can we get these merged in the next week or so? :)
20:42:25 <selsta> master and release branch are getting super out of sync and it is getting confusing
20:47:01 <moneromooo> The PR should be merged in pairs. I used to give out numbers in pairs, but I gave up really :/
20:47:52 <selsta> pair as in both master and release at the same time?
20:48:01 <moneromooo> Yes...
20:48:23 <selsta> yea will make sure to do that in the future
20:49:15 <moneromooo> Pony actually did it mostly right.
20:49:37 <moneromooo> And now since the bot is here, it'll get used instead of the paired list.
20:51:00 <selsta> I'm working on getting master and branch in sync again
20:51:13 <selsta> and in the future make sure to add pairs to the bot
20:52:15 <moneromooo> Well, the bot won't give a toss really. It just stores numbers, not pairs.
20:52:27 <moneromooo> Oh...
20:52:43 <moneromooo> #merge+ 908600009088
20:52:51 <moneromooo> .merge+ 908600009088
20:52:51 <xmr-pr> Added
20:52:53 <selsta> I mean I will make sure to always add both master and branch
20:52:57 <moneromooo> .merges
20:52:57 -xmr-pr- 6747 6826 6829 6830 6849 6856 6858 6873 6892 6895 6897 6898 6903 6913 6915 6920 6921 6922 6924 6933 6937 6939 6943 6949 6954 6960 6971 6973 6995 6999 7008 7018 7020 7021 908600009088
20:53:04 <moneromooo> Pairs work :D
20:53:07 <moneromooo> #merge- 908600009088
20:53:11 <moneromooo> .merge- 908600009088
20:53:11 <xmr-pr> Removed
20:53:15 <selsta> lol
22:37:38 <luigi1111w> any idea how many prs to get them in sync (vs the whole list)?
23:29:05 <sethsimmons> Where is the blocklist stored now?
23:29:07 <sethsimmons> https://gui.xmr.pm/block.txt 404s
23:30:57 <moneromooo> https://gui.xmr.pm/files/block.txt
23:31:04 <sethsimmons> ty
23:50:09 <Mmmmmmmmmm> Am I muted? What's the best way to be notified by the Monero Wallet Json Rpc when a new transfer arrives? Is it best to probe the state of incoming_transfers? Curious as to how people usually do this when they build application on Monero that require them to do XYZ action when a new transaction arrives
23:51:08 <Mmmmmmmmmm> I want to save a transaction in my database when my wallet gets a new transfer. Not sure what the best way to poll for it is