Hi, I was away for 2.5 weeks due to RL issues. I'm in the process of creating automated Valgrind reports right now.

so thanks for merging my Valgrind script.

Hello, is the commitment public key same as a stealth address?

"vout": [ {

      "amount": 0,

      "target": {

        "key": "45ee17f65852f68ad73ce200dd16be92a5878cb4d86ecc740b02828664c2510e"

      }

    }, {

      "amount": 0,

      "target": {

        "key": "9cf4c81578791734b2a1a311ac4798db040330d22e5bc9b6c8519eb47056cdaf"

      }

    }

  ],

and is it the "key" field of "vout"?

What you pasted are the output public keys.

Okay.

And are those the One-time addresses (section 4.2) :drive.google.com/viewerng/viewer?ur…rg/library/Zero-to-Monero-2-0-0.pdf ?

They're sometimes called one time addresses, yes

But since they're not addresses, I think it's a bad name,

So, i contacted the guy who maintains the monero package on debian and he answered today. He is having a bug in 0.17.1.9 that it's blocking the situation. He says that any help would be appreciated: bugs.debian.org/cgi-bin/bugreport.cgi?bug=973196

note that it's very important to have this bug fixed asap so that the debain package can be upgraded to 0.17.1.9

this is necessary if we want monero to be included in debian bullseye and tails

for reference: monero-project/monero #2395#issuecomment-762833504

We have until February 11

Anybody that could help with that?

I have time

<ErCiccione[m]> : I will take it up today and let you know in a couple of hours if I can handle it.

exit

mj-xmr: Awesome, thanks :)

Just worked on deban 10 fwiw.

moneromooo could you please take a look at this:

And are those the One-time addresses (section 4.2) :drive.google.com/viewerng/viewer?ur…ro.org/library/Zero-to-Monero-2-0-0.... ?

Please rephrase.

I mean, clarify your question. I'm not sure what you're asking.

"ErCiccione[m]: for reference: monero-project/monero #2395#issuecomment-762833504"

^ we need to provide basic_stream operator << implementation for wipeable_string, paste.debian.net/plain/1182806 should work

^ mj-xmr

Not sure we should. It kinda defeats the point of wipeable_string.

<< will leave traces in random places.

well, then we should just fix the tests

so they don't try to print the string

moneromooo you said that the "key" is the output public key.

"vout": [ {

      "amount": 0,

      "target": {

        "key": "45ee17f65852f68ad73ce200dd16be92a5878cb4d86ecc740b02828664c2510e"

      }

    }, {

      "amount": 0,

      "target": {

        "key": "9cf4c81578791734b2a1a311ac4798db040330d22e5bc9b6c8519eb47056cdaf"

      }

    }

  ],

It is.

And the recipient can recover the associated secret key when spending.

should i wait or should i tell them to try the patch?

Alright.

and the document zero to monero has no section on the keyword "output public key". Its talks about "one-time addresses".

So my question is, are they the same?

Yes, two names for the same thing.

But as I said they're not actually addresses so it's a misnomer really.

oh okay. Thank you so much :)

"<ErCiccione[m]> should i wait or should i tell them to try the patch?" < wait, althogh the patch might fix the issue, is most probably not the way we want to fix it :)

got it

and could you please point me to some C++ or JS implementation of deriving this output public key from pub_key and rand_scalar?

You can start from cryptonote_tx_utils.cpp, construct_...with_key

Yea I was roaming about this file. I'll dig deeper then

thank you!

I just looked, it seems to be the call to hwdev.generate_output_ephemeral_keys from the function above.

I will try to reproduce the Debian problem now.

Then we can discuss various solutions.

The solution is likely to have custom messages on those asserts, the default is to print the args IIRC.

thank you moneromooo, would have taken me a lot longer to figure this out.

i would do paste.debian.net/plain/1182819

It builds on Debian 10 here as well. Perhaps the problem lies in their version of boost. Will recheck.

Buster uses 1.67.0.1

(boost)

... building boost 1.67...

Get: 140 127.0.0.1:3142/debian sid/main amd64

It's SID, not Buster

OK. I'll need to build it via Docker.

OK. Building.

It builds OK under current unstable. I'll try sid explicitly.

Then I'll take a closer look at the packages, that they used.

It builds under sid as well. I'll use the same list of packages, that they use, but looking at their logs, I start to think that the culprit lies in one of the many patches, that they apply. It makes me wonder why they apply them, since it builds ok without them.

Reproduced :)

They're most probably missing one package. I'll try to bisect this.

The patches with 6934 in the name sound like a likely culprit fwiw.

Their package list is missing libboost-dev. This package contains boost::optional (and no other package does). Trying with the package now.

Look on the bright side. At least you don't need to obsess over signs of life from FUK now.

I got distracted by my wife. I will now write a pragmatic solution to the package maintainer.

<ErCiccione[m]>: Here's my reply. Closing the shop for today.