-
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.
-
selsta
Did we find the cause for this locale issue?
-
selsta
AFAIK hyc you looked into it but don’t remember further.
-
moneromooo
I need someone who can repro it to get me stack trace.
-
selsta
fluffypony: ^
-
moneromooo
fluffypony could repro it, but did not have libunbound compiled in.
-
fluffypony
I think I'd have to take a seed node down just to repro it
-
fluffypony
will see if I can repro it on a different box
-
moneromooo
I guess since it's at the start, gdb + catch throw should work.
-
hyc
the strace that fluffy posted before, showing attempt to open locale DBs, didn't match my own local run
-
hyc
in my own run those locale calls didn't happen
-
lh1008
Hello everyone :)
-
hyc
but maybe we can make this go away by just adding setlocale(LC_ALL, "C") at startup
-
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
-
lh1008
often (it stopped without reaching the credits), I had to restart it several times but it finally synced completely.
-
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.
-
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.
-
lh1008
Bye :)
-
moneromooo
I missed that strace log.
-
peach34
hi
-
peach34
Any Monero cryptographers about?
-
peach34
research team
-
moneromooo
Ask a monero related crypto question, and someone who knows will answer when they read.
-
peach34
ok
-
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'
-
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'
-
peach34
and spend the output
-
peach34
in full:
-
peach34
P = H(rA) + B
-
peach34
b' ---> A', B'
-
peach34
P - H(rA') = B'
-
peach34
spend via: xP where x = H(rA') + b'
-
peach34
(i forgot the G's in the first two lines)
-
Ymgve
isn't rA the receiver's public key
-
peach34
no it's the shared secret
-
peach34
rA=aR
-
Ymgve
I think B' doesn't match the recipient's public spend key B, so it's not their money
-
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)
-
peach34
Answer is not good enough sorry
-
Ymgve
what's the attack scenario though? how does this defraud someone with the keypair (A, B)
-
peach34
attack scenario: someone can spend a given output on the chain by manipulating the mathematics
-
Ymgve
your manipulation of mathematics creates a completely new keypair as far as I can tell
-
peach34
I'm looking for the mathematical reasoning. I'm not saying I have cracked Monero
-
peach34
I know it does, but one that satisfies P=H(rA)G+B
-
Ymgve
A and B is fixed, only r is variable
-
peach34
for which you know b' and can therefore spend P
-
peach34
But here's the thing
-
peach34
-
peach34
read page 79, the footnote
-
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
-
peach34
so why can't I instead take a b' of my choosing, derive A' and then do the same thing
-
Ymgve
then you created a new address
-
peach34
no
-
peach34
That's the whole point of the deception
-
peach34
There are many A and B such that P=H(rA)G+B
-
peach34
That's what the footnote is saying
-
Ymgve
yes, but there is only one pair of (A,B)
-
peach34
no
-
peach34
read the footnote
-
Ymgve
the footnote requires the _recipient_ to be in on it as far as I can tell
-
peach34
nope
-
Ymgve
"However, a prover and recipient could collaborate"
-
peach34
That is for the extra bit
-
Ymgve
you still haven't described a real attack scenario
-
peach34
please stop talking lol
-
peach34
Unless you are prepared to show me maths
-
Ymgve
maths: (A, B) != (A', B')
-
peach34
sorry please stop lol
-
peach34
5=1+4
-
peach34
5=3+2
-
peach34
Do you understand?
-
Ymgve
yes, but "1+4" is a different string than "3+2"
-
Ymgve
you are not sending to P, you are sending to the pair (A, B)
-
peach34
You don't understand the question
-
peach34
:')
-
Ymgve
yes, I don't, and you haven't explained why it could be used to steal anything
-
peach34
yes i have
-
peach34
someone will explain soon, thanks for trying
-
Ymgve
ok, my public key is (A, B), how do you defraud me
-
peach34
I don't have time to do this with you sorry
-
peach34
will wait for Surang
-
Ymgve
sure
-
moneromooo
sare.
-
Ymgve
peach34: looking closer at what you wrote, could you explain this step " b' ---> A', B' "
-
Ymgve
are you saying A' and B' are derived from b' in some way?
-
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`
-
UkoeHB__
in ZtM2 pg 79 footnote 7, the malicious prover does not know `k's`, he is just providing `K's` straight up
-
peach34
UkoeHB__ is that true though? If I pick an A' for which I already know the b'
-
peach34
yes UkoeHB__ i'm aware of that ... I'm talking about building on that idea
-
UkoeHB__
writing `P - H(rA')G = B'` is not enough; how do you know `B' == b'*G`?
-
peach34
you can readily derive a given A' from a b'
-
peach34
All keys can be derived from a private spendkey
-
peach34
So pick a b'
-
Ymgve
but A' is made from a' not b'
-
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'`
-
peach34
you can derive it though
-
peach34
so pick any b'
-
peach34
derive the corresponding A'
-
peach34
and B'
-
peach34
then you know an A' and B' which satisfy P
-
Ymgve
that's a different B' from the one you derived from b'
-
peach34
but you also have the b'
-
Ymgve
P - H(rA') != your calculated B'
-
Ymgve
P - H(rA') = B'' but how do you know B
-
Ymgve
P - H(rA') = B'' but how do you know B' == B''
-
UkoeHB__
yeah, your pre-computed `B'` won't show up from `P - H(rA')` just because you hope it will
-
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
-
peach34
UkoeHB__ understood so far. Can you explain why the precomputed B' does not show up
-
Ymgve
why _would_ it show up
-
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)
-
Ymgve
_a_ B'
-
Ymgve
not _your_ precomputed B'
-
peach34
yes.... bear with me
-
Ymgve
if you rename the variable and say P - H(rA') = X, what's your proof that X = your precomputed B'
-
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'
-
Ymgve
but then you get P' = H(rA') + B'
-
peach34
So what I'm trying to understand is, if you did that, and that A' was fed into P - H(rA'
-
Ymgve
there's nothing that says P == P'
-
peach34
why does your B' not come out the other side
-
Ymgve
because you changed A'
-
peach34
That's not an answer lol
-
Ymgve
if you rename the variable and say P - H(rA') = X, what's your proof that X = your precomputed B'
-
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
-
peach34
P - H(rA')G = public spend key is what is being done in the deception bit in the footnote right
-
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
-
peach34
P = H(rA')G = B'
-
peach34
sorry
-
Ymgve
that footnote is about a sender and receiver cooperating to decive a third party, if I'm reading it correctly
-
peach34
P - H(rA')G = B' is mentioned in footnote
-
peach34
correct
-
UkoeHB__
yes, but the deceiver doesn't know `b'`
-
UkoeHB__
he is just sending `B'` to the verifier directly
-
UkoeHB__
(or the verifier is deriving it directly)
-
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'
-
UkoeHB__
you have a circular dependency
-
UkoeHB__
and some other problems...
-
peach34
ok so where does the idea break down
-
peach34
I pick b', i derive A'
-
peach34
from b'
-
peach34
why does the B' that comes out of P-H(rA')G not correspond to the b' i chose
-
Ymgve
why would it
-
peach34
Ymgve please shut up lol
-
peach34
I'm not saying it does. I'm just trying to understand why it doesn't
-
Ymgve
because it is not a B' that comes out it is a X
-
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`
-
peach34
shh please
-
UkoeHB__
`b'G = B'` sorry
-
UkoeHB__
well if you just want to spend it then all you have to do is solve the DLP for `H(rA')
-
UkoeHB__
`a'` isn't really necessary
-
peach34
I was more talking about taking the A' corresponding to the b'
-
UkoeHB__
why does it have to correspond? that is just a convention with no deeper meaning
-
UkoeHB__
aside from convenience
-
peach34
Because if you loose all of your monero keys, you can derive them all from b'
-
UkoeHB__
sure... `a' = H(b')`
-
UkoeHB__
`a'` might as well be random
-
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'
-
Ymgve
because the result of P - H(rA')G is not actually B'
-
UkoeHB__
the relationship (if there is one) between `a'` and `b'` is completely irrelevant to `P`
-
peach34
so technically, two people can share the same view keypairs, but have different spend keypairs?
-
peach34
ie two monero addresses that have in them the same view key?
-
Ymgve
yes but that's not related to why your logic fails
-
peach34
Ymgve no it is... that solves my dilemma
-
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
-
peach34
because I was assuming that choosing a b' and feeding the corresponding A' in would give you the B' for b'
-
peach34
But it could be anything that pops out
-
peach34
Because A' isn't mutually exclusive to any one B'
-
peach34
I thought that there was a mapping of one A to one B
-
peach34
But there isn't. That is what I was missing
-
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
-
UkoeHB__
peach34: yes, although I wonder if you are missing some other aspects of elliptic curve cryptography that led to the misunderstanding
-
peach34
nah I do understand now
-
peach34
because when the deceiver is doing P - H(rA) , they are just geting an ec point, which they *present* as the public spendkey
-
UkoeHB__
glad we got it sorted
-
peach34
yeah thanks
-
UkoeHB__
peach34: also, for future reference, please direct cryptography questions to #monero-research-lab
-
sethsimmons
High DPI support for the 17.1.5 GUI is gorgeous, thanks for fixing that all
-
selsta
Now only Windows high DPI is missing
-
sethsimmons
I've never used it on 4k+, but 1440p looks great already
-
sech1
I've never used GUI, but I can test it on my 4K TV
-
selsta
should look fine if you use Linux
-
selsta
.merges
-
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
-
selsta
can we get these merged in the next week or so? :)
-
selsta
master and release branch are getting super out of sync and it is getting confusing
-
moneromooo
The PR should be merged in pairs. I used to give out numbers in pairs, but I gave up really :/
-
selsta
pair as in both master and release at the same time?
-
moneromooo
Yes...
-
selsta
yea will make sure to do that in the future
-
moneromooo
Pony actually did it mostly right.
-
moneromooo
And now since the bot is here, it'll get used instead of the paired list.
-
selsta
I'm working on getting master and branch in sync again
-
selsta
and in the future make sure to add pairs to the bot
-
moneromooo
Well, the bot won't give a toss really. It just stores numbers, not pairs.
-
moneromooo
Oh...
-
moneromooo
#merge+ 908600009088
-
moneromooo
.merge+ 908600009088
-
xmr-pr
Added
-
selsta
I mean I will make sure to always add both master and branch
-
moneromooo
.merges
-
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
-
moneromooo
Pairs work :D
-
moneromooo
#merge- 908600009088
-
moneromooo
.merge- 908600009088
-
xmr-pr
Removed
-
selsta
lol
-
luigi1111w
any idea how many prs to get them in sync (vs the whole list)?
-
sethsimmons
Where is the blocklist stored now?
-
sethsimmons
-
moneromooo
-
sethsimmons
ty
-
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
-
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