00:37:48 <hyc> ^ it's patched but we think we can do a better solution given some more time
08:28:30 <yrt> 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.
08:31:58 <yrt> Is anyone here.???
08:33:47 <yrt> 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
08:33:55 <rbrunner> Yes, but maybe again nobody competent yet ...
08:34:14 <yrt> Wht
08:34:45 <rbrunner> 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?
08:36:37 <yrt> 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
08:37:30 <yrt> 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
08:38:32 <rbrunner> 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.
08:40:00 <yrt> 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
08:41:19 <yrt> 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.
08:43:04 <rbrunner> Maybe paste your source somewhere, e.g. on https://paste.debian.net/, so somebody in the know (probably not me) can have a look when they come online later
08:43:32 <yrt> Ohk i will try it
08:43:46 <rbrunner> Only the relevant snippets of course :)
08:44:24 <yrt> But it's monero maths will  debian folks understand it.
08:44:42 <yrt> But wht goes in trying
08:46:01 <rbrunner> 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
08:46:28 <rbrunner> Debian folks just offer the paste service
09:02:51 <Guest36> How how these debian people will answer me
09:05:24 <ofrnxmr[m]> Post the link to the paste here
09:06:29 <moneromooo> You're posting on libera.chat IRC, and it's not the libera people answering. Same deal here.
09:07:04 <moneromooo> Like when you use your phone to call a friend. It's not the phone company that answers, they're just a conduit. 
09:07:57 <moneromooo> A better comparison is imgur. You put stuff there for others to see, not for the imgur people to see.
09:08:14 <Guest36> 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
09:08:24 <moneromooo> As a generic tip, I suggest using ASAN with your test code. Helps find bugs even when not looking.
09:09:08 <moneromooo> People who reply will presumably reply in this channel.
09:09:15 <moneromooo> So... stay around and read.
09:09:33 <moneromooo> It might also be nobody will know or care to spend time on it if it needs work.
09:10:27 <moneromooo> (ASAN or valgrind, the latter's speed doesn't matter on trivial test code).
09:15:21 <rbrunner> 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: https://paste.debian.net/1248710/
09:16:01 <rbrunner> 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
09:16:21 <rbrunner> And if they do they answer *here* :)
09:16:26 <Guest36> moneromoo: Are you that same moneromoo that checks and verify vulnerability found by bounty hunters on hackerone.
09:17:04 <moneromooo> Used to. I barely go there anymore.
09:17:06 <rbrunner> With 3 o's for added emphasis, not only 2 :)
09:17:48 <Guest36> rbrunner: Thanks a lot
09:18:04 <Guest36> moneromoo: okay
09:19:23 <Guest36> https://paste.debian.net/1248710
09:19:54 <Guest36> that's your's
09:20:17 <rbrunner> Yep.
09:20:50 <Guest36> So now this is mine: https://paste.debian.net/1248709
09:24:27 <rbrunner> I guess the relevant part is "main" at the very end, because the other code is just copied over from Monero source, right?
09:25:17 <Guest36> Yes
09:25:48 <rbrunner> Alright, I think now everything is ready for people who know such stuff can have a look, and maybe see something about a problem.
09:25:48 <Guest36> There is nothing wrong than also it output only zeroes
09:26:11 <Guest36> Okay
09:31:44 <moneromooo> %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.
09:37:33 <yrt> 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.
09:43:06 <moneromooo> Did you try asan or valgrind ?
09:44:18 <yrt> No
09:47:20 <moneromooo> Well, I compiled it. You did not use -Wall -W, right ?
09:48:03 <yrt> So did it gave any answer other than 0
09:48:41 <moneromooo> Anyway, I ran it, and I do not get only zeroes.
09:48:54 <yrt> I also compiled with -Wall but got only zeroes
09:48:59 <moneromooo> I case the values your print to unsigned char too, they're signed otherwise. 
09:49:38 <moneromooo> valgrind moans. Compile with debug info, run with valgrind, fix.
09:50:02 <yrt> Okay i will try that too did it worked for you
09:51:03 <moneromooo> Nice. A warning with O2 tells me fe is 10, not 40, long.
09:51:20 <moneromooo> You probably used 40 due to sizeof, but they're int32_t fields.
09:51:37 <yrt> Asan is showing many errors of overflow in int32_t  but i not used any they were all of monero sc
09:52:07 <moneromooo> Probably the 10/40 mixup ?
09:52:30 <yrt> No fe is int32_t fe[] as in monero sc i not touched anything
09:52:54 <yrt> Fe is array of 10 int32_t
09:54:29 <yrt> But i not touched any values only used crypto-ops.c and crypto-ops.h from monero sc
09:56:40 <moneromooo> 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]);...
09:57:38 <moneromooo> And valgrind moans no more.
10:02:25 <Guest36> Wht about the key stored in key hell that's what stores the end input
10:02:31 <Guest36> *output
10:03:37 <moneromooo> Not zeroes here either.
10:04:47 <Guest36> I applied the suggestion but zeroes are here while printing hell.bytes it outputs only zero
10:05:28 <Guest36> And now everything is zero
10:06:23 <Guest36> Could you past your code and compiled command and compiled result on paste.debian
10:12:41 <Guest36> https://paste.debian.net/1248719
10:13:46 <Guest36> 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
10:16:47 <moneromooo> https://paste.debian.net/hidden/9e6215d8/
10:17:15 <moneromooo> I get 8c5a513f9c6933ecbfcc8a3cbad226b8d40cf12c78b1a15a815bbd0e3fe845ce for that last key.
10:17:23 <Guest36> The compiled result i get is https://paste.debian.net/1248724
10:18:07 <Guest36> Okay wait a minute i am trying wht you tried
10:18:11 <moneromooo> The huge gobs of ubsan warnigns are known for that cod. 
10:18:45 <moneromooo> For me it's "don't touch or you'll break it" :D
10:22:11 <Guest36> Don't touch or break it 🤣 it
10:22:21 <Guest36> But it gave me zeroes again
10:29:42 <Guest36> I copy paste you main code and than compiled the result is https://paste.debian.net/hidden/685a3114/
10:36:41 <Guest36> 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
10:36:42 <Guest36> That it gave result.
10:37:53 <Guest36> 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
10:39:03 <Guest36> The only odd thing i not included was that libcncrypt.a but why including it gave results.
10:49:24 * willshu[m] uploaded an image: (62KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/fIbAaEgtldhDIKiQFzPlvbwn/Screen%20Shot%202022-07-29%20at%2018.49.11.png >
10:50:46 <willshu[m]> Hello all, I use monero-javascript to sign keyImages offline. But this line throws an error: ` exportKeyImages Error: TypeError: (intermediate value) is not iterable`.
10:51:10 * willshu[m] uploaded an image: (167KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/SiurGsCxUBjLdVfwtlqpaMIY/Screen%20Shot%202022-07-29%20at%2018.17.29.png >
10:52:12 <willshu[m]> 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.`
10:52:53 <moneromooo> yrt: I don't know...
10:53:14 <yrt> But you did it so how
10:53:20 <moneromooo> Maybe your copy of the cncrypto functions is somehow different from the one generated in libcncrypto for some reason.
10:53:23 <willshu[m]> Since this js function actually calls a `c++` function, I tried to `log/print` it.
10:53:38 * willshu[m] uploaded an image: (194KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/MoAciZFIfCyDKzuQOGtYczvQ/Screen%20Shot%202022-07-29%20at%2018.52.41.png >
10:54:29 <yrt> But the file crypto-ops was self sufficient it not needed anything except it header file
10:55:18 <willshu[m]> 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? 
10:55:56 <yrt> There should have been any errors whole exporting key images i think so
10:56:02 <moneromooo> Your copy does not include some constants. Maybe your linker just links a dummy copy full of zeroes...
10:56:48 <moneromooo> I needed to link the lib in for those. Like fe_ma, etc. Thy're in crypto-ops-data.c
12:07:26 <Guest75> Which is best private way to first time buy monero or send monero into wallet compiled by source code
12:08:06 <Guest75> Or exchange your country money into monero and send it to wallet
12:16:37 <moneromooo> People in #monero or #monero-markets should know.
12:27:32 <rbrunner> I checked a bit how much memory `monero-wallet-rpc` uses, on Linux using pmap which seems to work.
12:27:46 <rbrunner> With a wallet open with maybe 50 outputs, it used 452796K
12:28:16 <rbrunner> As soon as I mined a few blocks to it, and it made a refresh, memory usage jumped to 1168116K
12:29:11 <rbrunner> 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?
12:30:36 <rbrunner> The block themselves are empty blocks from an offline daemon
12:31:28 <plowsof> the other day i had 30 rpc wallets syncing , each using 2 GB of ram 
12:31:48 <rbrunner> Sporty!
12:32:54 <rbrunner> 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
12:33:07 <rbrunner> *other things than
13:15:59 <Guest52> 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
13:16:57 <gingeropolous> 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.
16:02:55 <Guest35> 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
16:07:57 <rbrunner> Basically start a daemon with the option --offline, make it mine blocks, and direct wallet, RPC etc. to that daemon
16:09:11 <rbrunner> You can influence mining using the startup option --fixed-difficulty
16:10:24 <rbrunner> I use to take the current testnet blockchain as a starting point for any such experiments
16:53:43 <jordanunstoppabl> Hey everyone
16:54:23 <jordanunstoppabl> who can I speak with about monero wallet partnerships?
16:54:32 <jordanunstoppabl> reaching out from Unstoppable Domains
16:56:00 <ofrnxmr[m]> Are you actually from UD?
16:56:03 <ofrnxmr[m]> Its already implemented in cake and monerujo
16:56:45 <ofrnxmr[m]> (I think it works in monerujo.. might only be openalias)
16:57:08 <jordanunstoppabl> yes actually from UD, will check cake and monerujo, thank you
16:57:35 <ofrnxmr[m]> Ok. #monero-gui:monero.social  for official gui channel 
16:57:52 <jordanunstoppabl> ok yeah I think that's what im looking for, thanks
16:58:42 <Rucknium[m]> jordan.unstoppable.domains:  Ask in #monero-community-dev:monero.social too
16:58:45 <ofrnxmr[m]> #feather:monero.social for feather wallet
17:49:28 <gingeropolous> 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
17:51:16 <rbrunner> Easily winning the contest of "the most stupid thing in Monero July 2022"
17:53:53 <hyc> was that serious? I didn't look at the site
17:54:05 <rbrunner> Sadly, yes.
17:54:14 <BusyBoredom[m]> Hilarious way to prove his point though. 
17:54:33 <UkoeHB> there is no real way to stop that kind of thing except massively increasing fees
17:54:44 <rbrunner> Yeah, bonus point for creativity.
17:55:10 <selsta> is it possible to prune tx_extra (unless it's a paymentid) ?
17:55:18 <gingeropolous> i thought tx_extra had a limit on size
17:55:42 <rbrunner> Even if, you don't write 5000 character lines in #MRL, do you?
17:55:50 <UkoeHB> gingeropolous: like 100kB or something?
17:56:45 <rbrunner> I wonder how long it will take until they take this channel instead.
17:57:03 <rbrunner> Or in addition.
17:58:03 <hyc> if he's logging from the IRC side and not the matrix side, it's gonna be spammed with all the re-edits
17:59:56 <merope> I kicked it from the matrix side, someone on IRC please check if it's there too
17:59:56 <kayabanerve[m]> <rbrunner> "Easily winning the contest of "..." <- Yep
18:00:04 <kayabanerve[m]> <BusyBoredom[m]> "Hilarious way to prove his point..." <- Except we can't act on it until the next hf
18:00:25 <hyc> still have 2 days left in July
18:00:28 <kayabanerve[m]> We could change relay policy in 0.18.0.1?
18:00:30 <UkoeHB> 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)
18:01:16 <kayabanerve[m]> If we can ban relaying > 255 bytes and charge a 2x fee, great
18:01:30 <kayabanerve[m]> That may be possible as solely fee policy
18:01:38 <moneromooo> 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.
18:02:03 <UkoeHB> 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
18:02:08 <kayabanerve[m]> moneromooo: And there's the whole negotiating with terrorists thing
18:02:09 <moneromooo> So allowing spam via tx_extra is actually a good thing (unless we prevent spam via txes, and I don't think we can).
18:02:18 <moneromooo> er... wat
18:02:24 <kayabanerve[m]> Like I didn't mind them joining and pointing out the bee movie script lol. It was great
18:02:35 <kayabanerve[m]> But we shouldn't rush dev decisions based on harassment
18:02:42 <rbrunner> Exactly.
18:02:55 <rbrunner> That would be a much too easy win.
18:03:05 <UkoeHB> 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
18:03:14 <kayabanerve[m]> 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.
18:03:40 <kayabanerve[m]> Which is agreeing with you mooo in a practical sense, and highlighting how this is bs
18:04:33 <kayabanerve[m]> 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
18:05:27 <kayabanerve[m]> 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
18:05:33 <UkoeHB> I disagree about a byte limit, but do think a tx weighting that amplifies memos and any steganography space would be worthwhile
18:05:56 <kayabanerve[m]> Though considering we're not at capacity, we don't really have a fee market. This doesn't prove anything .-.
18:06:17 <kayabanerve[m]> UkoeHB: I don't think we have legitimate use for anything greater and I do agree we shouldn't be an arbitrary file host
18:06:54 <kayabanerve[m]> If we did allow it uncapped, I wonder if we should consider exponential fees. The issue is when we encourage steg :/
18:07:12 <blackpenguin> 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
18:07:42 <kayabanerve[m]> 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 
18:07:55 <moneromooo> binaryFate: ^
18:09:09 <UkoeHB> amplifying memo byte weighting is equivalent to a byte limit, without adding any design constraints to the API
18:10:04 <selsta> blackpenguin: which hash do you get?
18:10:04 <UkoeHB> as I have said many times, the memo field is important wiggle room that reduces long-term dependency on the core team
18:11:29 <kayabanerve[m]> UkoeHB: How so?
18:11:42 <kayabanerve[m]> Sorry, pointless reply, I apologize to irc
18:12:23 <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
18:13:08 <UkoeHB> adding a byte limit means core suddenly has the power to assess proposed uses of monero (a certain subset)
18:14:55 <rbrunner> 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."
18:14:57 <UkoeHB> 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)
18:15:00 <kayabanerve[m]> ... wait, I'm sorry, I also continually forget we have wallet data when I make these suggestions
18:15:10 <kayabanerve[m]> I'm the idiot who almost just banned us to only 8 out txs
18:15:27 <kayabanerve[m]> Seraphis will make it truly arb yet it isn't arb yet
18:15:42 <moneromooo> ...Architecture review board ?
18:16:17 <kayabanerve[m]> 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
18:16:28 <blackpenguin> selsta: ad4b4be60548cddcade3cf8874579256805559d61a68e6102e4dde71284a2039 monero-monero-gui-linux-x64-v0.17.3.2.tar.bz2   
18:17:05 <UkoeHB> kayabanerve[m]: exponential fee would ultimately encourage tx spam, which has a verification and scanning cost
18:17:11 <moneromooo> re exponential: must be done via integer math (or very well thought out bit exact floating point).
18:17:13 <kayabanerve[m]> 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
18:17:14 <kayabanerve[m]> *255
18:17:39 <selsta> blackpenguin: hash matches with v0.17.3.2 gui
18:17:40 <moneromooo> I guess it can be a LUT if the max is 255 bytes.
18:17:43 <kayabanerve[m]> UkoeHB: Right, to steg, yet there's a computational cost and time delay, with the inefficiencies create higher fees already
18:19:06 <kayabanerve[m]> 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 
18:19:40 <blackpenguin> 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
18:20:02 <selsta> are you sure you didn't confuse CLI with GUI?
18:20:09 <ofrnxmr[m]> selsta:  I can confirm hashes match
18:20:09 <ofrnxmr[m]> But
18:20:09 <ofrnxmr[m]> The downloads all point to 17.3.2 and the source code zip 404's
18:20:44 <ofrnxmr[m]> http://monerotoruzizulg5ttgat2emf4d6fbmiea25detrmmy7erypseyteyd.onion/downloads/
18:21:10 <UkoeHB> 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'`
18:21:20 <UkoeHB> ratio*
18:21:55 <UkoeHB> er it would be base weight not base bytes *
18:23:39 <kayabanerve[m]> We can't determine steg bytes :/
18:23:59 <kayabanerve[m]> We can only determine extra included data which isn't steg
18:24:36 <kayabanerve[m]> Unless you assume all additional outputs are steg but that's also problematic
18:24:56 <UkoeHB> it doesn't have to be precise
18:27:28 <UkoeHB> * 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
18:28:50 <UkoeHB> that way the base tx cost doesn't change (which is how the fee system is calibrated)
18:33:02 <UkoeHB> the ratio might be only 2x tbh, since you can use all of the CLSAG decoy responses for steganography
18:57:25 <gingeropolous> "<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  
19:03:12 <rbrunner> 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
19:06:17 <gingeropolous> u can tie data in the header to a tx maybe? then it just becomes a matter of relay rules
19:10:24 <rbrunner> 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 :)
21:32:12 <ArticMine> 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. 
21:33:54 <ArticMine> 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
21:34:12 <ArticMine> So this is a way to price the verification time. 
21:36:37 <ArticMine> The weight was calculated by adding back 80% of the size savings for multiple outputs. This is the "claw back"
21:37:42 <ArticMine> Once could apply an additional weight to tx-extra / memo fields
21:38:38 <ArticMine> 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
21:39:01 <Guest68> hey
21:39:23 <Guest68> can I send a tx with the payment id being regular string ie not hexadecimal?
21:41:14 <ArticMine> I am more inclined to restrict or eliminate altogether tx-extra / memo fields for no coinbase transactions
21:42:24 <ArticMine> I would really like to see the arguments for keeping tx_extra / memo fields.
21:43:57 <ArticMine> I understand there is a case for coinbase transaction for merged mining, but for non coinbase transactions what is the use case?
21:45:57 <tevador> I think everything has been said in issue 6668. People want to put their stuff in tx_extra.
22:35:01 <ArticMine> I will comment further on this in issue 6668