^ it's patched but we think we can do a better solution given some more time

I am bit confused i used the same function generations commitment for say producing two public key and adding them. That is ge_scalar.....() But when I am using it in my code it is giving zeroes nothing else.

Is anyone here.???

That function is ge_double_scalarmult_base_vartime and ge_tobytes to produce and convert coordinates into key. But the answer it is giving me is zeros

Yes, but maybe again nobody competent yet ...

Wht

Could you watch the effect in realtime in the debugger? Maybe something is not as you assume, so better to check variables in the debugger as they go in and out of methods?

I did it checking it at every step but it's maths is doing something else that it should not and i am not getting why

But everything is perfect than also it reacting in such a way i tested it for 2 days but now brain is not working and i am not getting why it is giving zeroes

Well, as a bug in those methods themselves can be ruled out almost for sure, it almost has to be something on your side - whatever it is.

Yes that's the thing I also thought as i compiled the whole function as it was in source code so it couldn't be wrong but than i checked mine too it also can't be wrong as i only supplied input a and b and nothing else

Sorry not compiled but copied i wanted to test how it worked underneath do i copied the code from sc that did the work and made a program which supplied input which are binding factor and another amount nothing more.

Maybe paste your source somewhere, e.g. on paste.debian.net, so somebody in the know (probably not me) can have a look when they come online later

Ohk i will try it

Only the relevant snippets of course :)

But it's monero maths will  debian folks understand it.

But wht goes in trying

No, paste your source there and then post a link to it here. That's the usual way to show any longer text here, because posting directly here does not turn out well

Debian folks just offer the paste service

How how these debian people will answer me

Post the link to the paste here

You're posting on libera.chat IRC, and it's not the libera people answering. Same deal here.

Like when you use your phone to call a friend. It's not the phone company that answers, they're just a conduit.

A better comparison is imgur. You put stuff there for others to see, not for the imgur people to see.

No i wanted to ask from where will I know anyone answered as on debian paste webpage i can't see anything related to that

As a generic tip, I suggest using ASAN with your test code. Helps find bugs even when not looking.

People who reply will presumably reply in this channel.

So... stay around and read.

It might also be nobody will know or care to spend time on it if it needs work.

(ASAN or valgrind, the latter's speed doesn't matter on trivial test code).

Like so: I pasted about 50 lines of this discussion on paste.debian.net, and now I give you the link so you can check: paste.debian.net/1248710

After you pasted the relevant parts of your source code there, and posted a link to it here, people *here* can have a look, and maybe see something

And if they do they answer *here* :)

moneromoo: Are you that same moneromoo that checks and verify vulnerability found by bounty hunters on hackerone.

Used to. I barely go there anymore.

With 3 o's for added emphasis, not only 2 :)

rbrunner: Thanks a lot

moneromoo: okay

that's your's

Yep.

So now this is mine: paste.debian.net/1248709

I guess the relevant part is "main" at the very end, because the other code is just copied over from Monero source, right?

Yes

Alright, I think now everything is ready for people who know such stuff can have a look, and maybe see something about a problem.

There is nothing wrong than also it output only zeroes

Okay

%p prints a pointer, you probably want %02x or something. Also, you use &sv8.bytes, I *think* it's OK but you mught want to try just sv8.bytes to make sure.

I tried it it not gave any compilation error but their is no difference between wht i wrote now also it's giving zeroes only, do something for those zeroes thanks %02x present the picture in much better way, but wht about zeroes they are here only.

Did you try asan or valgrind ?

No

Well, I compiled it. You did not use -Wall -W, right ?

So did it gave any answer other than 0

Anyway, I ran it, and I do not get only zeroes.

I also compiled with -Wall but got only zeroes

I case the values your print to unsigned char too, they're signed otherwise.

valgrind moans. Compile with debug info, run with valgrind, fix.

Okay i will try that too did it worked for you

Nice. A warning with O2 tells me fe is 10, not 40, long.

You probably used 40 due to sizeof, but they're int32_t fields.

Asan is showing many errors of overflow in int32_t  but i not used any they were all of monero sc

Probably the 10/40 mixup ?

No fe is int32_t fe[] as in monero sc i not touched anything

Fe is array of 10 int32_t

But i not touched any values only used crypto-ops.c and crypto-ops.h from monero sc

Well, as I said. I currently modified your code to read like this: for(int i=0;i<10;i++) { printf("X:%02x ",(unsigned char)rv.X[i]);...

And valgrind moans no more.

Wht about the key stored in key hell that's what stores the end input

*output

Not zeroes here either.

I applied the suggestion but zeroes are here while printing hell.bytes it outputs only zero

And now everything is zero

Could you past your code and compiled command and compiled result on paste.debian

At the end the loop printing a key why it is zero when it should be something as input gone through process of squaring and multiplication

I get 8c5a513f9c6933ecbfcc8a3cbad226b8d40cf12c78b1a15a815bbd0e3fe845ce for that last key.

The compiled result i get is paste.debian.net/1248724

Okay wait a minute i am trying wht you tried

The huge gobs of ubsan warnigns are known for that cod.

For me it's "don't touch or you'll break it" :D

Don't touch or break it 🤣 it

But it gave me zeroes again

I copy paste you main code and than compiled the result is paste.debian.net/hidden/685a3114

But when I copy pasted your command to compile it gave me result can you plz explain why was special in gcc -fsanitize=address -g -O2 -I contrib//epee/include/ -I src/crypto -W -Wall ~/QubesIncoming/disp4681/test-yrt.c build/Linux/cc/release/src/crypto/libcncrypto.a

That it gave result.

moneromooo: thanks a lot for giving your time and helping solve my doubt it gave result but i am not getting why was so special in you compiling command that it gave result

The only odd thing i not included was that libcncrypt.a but why including it gave results.

Hello all, I use monero-javascript to sign keyImages offline. But this line throws an error: ` exportKeyImages Error: TypeError: (intermediate value) is not iterable`.

I guess the error comes from the red box in the second image above, for ... of null will throw an error: `TypeError: (...) is not iterable.`

yrt: I don't know...

But you did it so how

Maybe your copy of the cncrypto functions is somehow different from the one generated in libcncrypto for some reason.

Since this js function actually calls a `c++` function, I tried to `log/print` it.

But the file crypto-ops was self sufficient it not needed anything except it header file

But it does not work. Where in the `monero-javascript` repo does `emscripten` translate c++ to javascript? I suppose the js function does not actually call `c++`, but instead calls js script translated from `c++`, right?

There should have been any errors whole exporting key images i think so

Your copy does not include some constants. Maybe your linker just links a dummy copy full of zeroes...

I needed to link the lib in for those. Like fe_ma, etc. Thy're in crypto-ops-data.c

Which is best private way to first time buy monero or send monero into wallet compiled by source code

Or exchange your country money into monero and send it to wallet

People in #monero or #monero-markets should know.

I checked a bit how much memory `monero-wallet-rpc` uses, on Linux using pmap which seems to work.

With a wallet open with maybe 50 outputs, it used 452796K

As soon as I mined a few blocks to it, and it made a refresh, memory usage jumped to 1168116K

Any idea why? And how would one approach to find out where 600 MB are needed to just scan a couple of blocks and receiving coinbase txs?

The block themselves are empty blocks from an offline daemon

the other day i had 30 rpc wallets syncing , each using 2 GB of ram

Sporty!

I never saw anything in Monero working with other things like dynamically growing std arrays, maps, vectors. Why this suddenly gobbles RAM like crazy is beyond me right now

*other things than

Hi, how are monero accounts saved? Will the accounts in my wallet be preserved when I upgrade versions to 0.18? Thank you in advance

Guest52, better for #monero, but yes. the account in your wallet will be preserved when you upgrade. Your wallet is a key. Your monero are on the blockchain. You use your key to access the monero on the blockchain.

I want to test monero source code and network how it works like it works in network but in private network like ethereum provides do i can do same in monero

Basically start a daemon with the option --offline, make it mine blocks, and direct wallet, RPC etc. to that daemon

You can influence mining using the startup option --fixed-difficulty

I use to take the current testnet blockchain as a starting point for any such experiments

Hey everyone

who can I speak with about monero wallet partnerships?

reaching out from Unstoppable Domains

Are you actually from UD?

Its already implemented in cake and monerujo

(I think it works in monerujo.. might only be openalias)

yes actually from UD, will check cake and monerujo, thank you

Ok. #monero-gui:monero.social for official gui channel

ok yeah I think that's what im looking for, thanks

jordan.unstoppable.domains: Ask in #monero-community-dev:monero.social too

#feather:monero.social for feather wallet

dunno if y'all see this in mrl, but someone is now spamming chain tx_extra with #mrl <tx_extra[m]> follow #monero-research-lab directly from your daemon or visit mrlonchain.net

Easily winning the contest of "the most stupid thing in Monero July 2022"

was that serious? I didn't look at the site

Sadly, yes.

Hilarious way to prove his point though.

there is no real way to stop that kind of thing except massively increasing fees

Yeah, bonus point for creativity.

is it possible to prune tx_extra (unless it's a paymentid) ?

i thought tx_extra had a limit on size

Even if, you don't write 5000 character lines in #MRL, do you?

gingeropolous: like 100kB or something?

I wonder how long it will take until they take this channel instead.

Or in addition.

if he's logging from the IRC side and not the matrix side, it's gonna be spammed with all the re-edits

I kicked it from the matrix side, someone on IRC please check if it's there too

<rbrunner> "Easily winning the contest of "..." <- Yep

<BusyBoredom[m]> "Hilarious way to prove his point..." <- Except we can't act on it until the next hf

still have 2 days left in July

We could change relay policy in 0.18.0.1?

it is possible to inflate the fee rate of memo bytes compared to tx bytes, since tx bytes are a kind of fixed cost to adding a memo (or steganography)

If we can ban relaying > 255 bytes and charge a 2x fee, great

That may be possible as solely fee policy

FWIW, for the people concerned with bloat, it is as cheap to spam with txes, and those incur extra verification time, while tx_extra is ~free there.

e.g. if the base tx has 10% space for steganography, that means the per-memo-byte cost is 10x the overall fee/byte; this can be extended to all other memo bytes so the weighting is 10x on each additional memo byte

moneromooo: And there's the whole negotiating with terrorists thing

So allowing spam via tx_extra is actually a good thing (unless we prevent spam via txes, and I don't think we can).

er... wat

Like I didn't mind them joining and pointing out the bee movie script lol. It was great

But we shouldn't rush dev decisions based on harassment

Exactly.

That would be a much too easy win.

in that way there is no additional incentive to make more txs for steganography vs adding more plain memo bytes, while maximizing per/byte cost on memo stuff

I'm saying that this isn't the end of the world regarding spam. This, as their attempt to say it can be used for spam, is a fear tactic.

Which is agreeing with you mooo in a practical sense, and highlighting how this is bs

2x relay fee with a 255 byte limit is my advocacy, both short term and long term, unless we want to encourage uniformity via steganography for the theoretical benefits

We can theoretically do that not as a hard fork, if it's solely applied on mempool relay. It's fee calculation and a bool

I disagree about a byte limit, but do think a tx weighting that amplifies memos and any steganography space would be worthwhile

Though considering we're not at capacity, we don't really have a fee market. This doesn't prove anything .-.

UkoeHB: I don't think we have legitimate use for anything greater and I do agree we shouldn't be an arbitrary file host

If we did allow it uncapped, I wonder if we should consider exponential fees. The issue is when we encourage steg :/

hello, just found the onion mirror still gives 0.17.3.2 on download link for linux64 - and it's even worse the file received doesn't even match checksum of 0.17.3.2 beside that it should be 0.18.0.0 - hope someone around knows where to forwards this info to get it fixed

And I'm saying 255 so it fits in a single byte. While we can't save a byte without a hard fork, we can set it as policy now so we can in the future without again changing the size limit

binaryFate: ^

amplifying memo byte weighting is equivalent to a byte limit, without adding any design constraints to the API

blackpenguin: which hash do you get?

as I have said many times, the memo field is important wiggle room that reduces long-term dependency on the core team

UkoeHB: How so?

Sorry, pointless reply, I apologize to irc

it's literally the 'anything goes' field i.e. anything we can't forsee or anything that a byte limit would require a hard fork to enable

adding a byte limit means core suddenly has the power to assess proposed uses of monero (a certain subset)

That is probably what infuriates me most with this stunt: The idea that the world is so incredibly simple: "Can be used for spam -> must go, period."

ArticMine: can you look at this idea of memo weighting? (we'd also need to include tx outputs in this bonus weighting, since those are the main vector for steganography)

... wait, I'm sorry, I also continually forget we have wallet data when I make these suggestions

I'm the idiot who almost just banned us to only 8 out txs

Seraphis will make it truly arb yet it isn't arb yet

...Architecture review board ?

My new proposal is a base byte size with the standard fee, a 256 byte 2x fee, and from there exponential, but I'm sure ArticMine can do better

selsta: ad4b4be60548cddcade3cf8874579256805559d61a68e6102e4dde71284a2039 monero-monero-gui-linux-x64-v0.17.3.2.tar.bz2

kayabanerve[m]: exponential fee would ultimately encourage tx spam, which has a verification and scanning cost

re exponential: must be done via integer math (or very well thought out bit exact floating point).

Basically, soft arbitrary limit of 256 bytes yet fully allowing larger data. I'm not going to comment on the exponent at this time though, as I'm sure a few curves can be argued for

*255

blackpenguin: hash matches with v0.17.3.2 gui

I guess it can be a LUT if the max is 255 bytes.

UkoeHB: Right, to steg, yet there's a computational cost and time delay, with the inefficiencies create higher fees already

The discussion has to be 255 on top of wallet data if we set a cap. While I don't completely understand koe, I respect their opinion. We'd either want a very low exponent so it's not encouraging steg or to keep it linear at 2x for anything over wallet data

selsta: ouch. guess that's bad news for me as it doesn't match an older download I had weeks ago. but good news as at least it's not a modified version then. still the onion mirror should provide 0.18.0.0 instead

are you sure you didn't confuse CLI with GUI?

selsta: I can confirm hashes match

But

The downloads all point to 17.3.2 and the source code zip 404's

kayabanerve[m]: I am saying, when you compute a tx weight, multiply the base weight of any memo + steganography bytes by the ration `'base non-memo/non-steganography bytes for a 2-in/2-out tx' / 'base memo/steganography bytes'`

ratio*

er it would be base weight not base bytes *

We can't determine steg bytes :/

We can only determine extra included data which isn't steg

Unless you assume all additional outputs are steg but that's also problematic

it doesn't have to be precise

* the weight would apply to any additional bytes added past the base amount; the goal is for the cost of 2 txs with steganography to be equal to the cost of 1 tx + adding the same amount of equivalent memo/steg bytes

that way the base tx cost doesn't change (which is how the fee system is calibrated)

the ratio might be only 2x tbh, since you can use all of the CLSAG decoy responses for steganography

"<UkoeHB> it's literally the 'anything goes' field i.e. anything we can't forsee or anything that a byte limit would require a hard fork to enable" >>> i thought this concern could be addressed by keeping an "anything goes field" in the block header. Also, i think we can refer to it as AGF

No, if we ever have a need to "fix" something in any way, or make a controversial extension, it may well be per tx, not merely per block

u can tie data in the header to a tx maybe? then it just becomes a matter of relay rules

Yeah, of course you can blow this up until it has the complexity of SegWit "tx parts that are not really tx parts, but still are" softfork :)

What we do now is use a a transaction and block weight for fee pricing, medians and penalty. This is higher than the actual transaction size when there is more than 2 outputs.

This was implemented because verification time scales as the number of outputs but actual transaction size scales as the log of the number of outputs

So this is a way to price the verification time.

The weight was calculated by adding back 80% of the size savings for multiple outputs. This is the "claw back"

Once could apply an additional weight to tx-extra / memo fields

I am however not sure that pricing is the way to deal with this since to an attacker there could be considerable value in adding toxic content to the blockchain

hey

can I send a tx with the payment id being regular string ie not hexadecimal?

I am more inclined to restrict or eliminate altogether tx-extra / memo fields for no coinbase transactions

I would really like to see the arguments for keeping tx_extra / memo fields.

I understand there is a case for coinbase transaction for merged mining, but for non coinbase transactions what is the use case?

I think everything has been said in issue 6668. People want to put their stuff in tx_extra.

I will comment further on this in issue 6668