00:23:57 <cryptogrampy[m]> is it possible to sign/verify strings using subaddresses or different accounts? ideally i'd like to verify a string using the signature and a provided subaddress
00:44:31 <UkoeHB> cryptogrampy[m]: afaik you'd have to implement it
00:45:37 <UkoeHB> this does something similar to what you want (as an example): https://github.com/monero-project/monero/blob/master/src/multisig/multisig_kex_msg.h
06:36:28 <moneromooo> cryptogrampy[m]: yes
06:39:55 <ErCiccione> I thought we already decided to disable multisig by default and merge 8149, because it's better than what we have now. Dropping multisig entirely (meaning people have to recompile if they want it) would be disruptive for all the people/entities currently relying on it and would create them possibly big problems. I agree with arnuschky 
10:08:26 <HenryHollingwort> does anyone have experience editing/debugging the monero source code using clion? I am wanting to add two features to the monero-wallet-rpc (support for `address one-off <account> <subaddress>` and `transfer index=N1,...` to the `get_address` and `transfer` RPC commands respectively). I'm just a simple python/.net/js trying to add support for that.
10:08:26 <HenryHollingwort> Ideally I'd like to be able to build/rebuild and debug the monero-wallet-rpc executable somehow (i am on windows). I have built monero from source fine on msys2 and am really looking for a good debugging (step through) experience
10:11:42 <HenryHollingwort> i have attempted to setup clion w/ msys2 but keep getting problems about file too big (src/rpc/CMakeFiles/obj_rpc.dir/instanciations.cpp.obj: file too big) or a whole bunch on randomx related errors (undefined reference to `randomx::JitCompilerX86::~JitCompilerX86()') collect2.exe: error: ld returned 1 exit status
10:12:13 <HenryHollingwort> any advice would be greatly appreciated
10:34:10 <HenryHollingwort> disregard ^ above regarding transfer - it already does that
11:15:47 <woodser[m]> despite not being officially supported in monero-project, are integrated addresses theoretically safe to use?
11:15:53 <woodser[m]> spirobel is arguing strongly in their favor to accommodate their application use case: https://github.com/monero-ecosystem/monero-javascript/issues/90#issuecomment-1148729137
11:16:05 <woodser[m]> they claim the public and spend keys are the same, so the wallet can't tell the difference. to be fair, transactions do work sending to integrated subaddresses, although there's an error if sending to self with an integrated subaddress
11:16:29 <woodser[m]> I want to check if it's safe to "unofficially support" generating integrated subaddresses without risking user funds from a malformed address, in order to accommodate their use case
11:18:04 <woodser[m]> s/addresses/subaddresses/
11:18:39 <moneromooo> It would just fuck up the efforts people made to improve things, but it'd work.
11:21:25 <moneromooo> If one wanted to avoid being an jerk about it, one might make their own custom address format that's obviously not monero, ie "custommagicstringHEREGOESPUBKEYS". That would go a long way towards making people realize those aren't monero addresses, just identifiers for whatever code uses them.
11:23:40 <woodser[m]> it sounds like they need the payment id for external viewing, but also need to send to subaddresses
11:30:40 <moneromooo> Or even something like moneroaddress+64bitnumber
11:31:12 <moneromooo> Then it'd be obvious the addresses are the same when the extra payment id is removed.
11:31:28 <moneromooo> In fact, monero:ADDRESS&payment_id=x
11:31:40 <moneromooo> I knoew it'd come in handy at some point :D
11:32:34 <moneromooo> Thought ought to be given to how to make it not dumb on chain. I'm not sure a dummy payment is added when all outs are subaddresses atm. If this is not the case, those txes would stick out.
11:33:09 <moneromooo> But then I suppose the goal isn't to blend in if trying to ram a feature through on the side :/
11:34:33 <moneromooo> There are two things really (that I remmeber off the top of my head). The user confusion and the on-chain distinguishibility.
11:37:10 <woodser[m]> yeah. the issue of not generating a dummy payment id when all outs are subaddresses could be addressed separately
12:04:14 <spirobel[m]> <moneromooo> "There are two things really (..." <- on chain distinguishibility also applies to "normal integrated addresses". They are currently supported, right?
12:11:05 <TrasherDK[m]> I seem to remember something about "If not specified, a dummy will be added, making integrated addresses blend in. Or was that just a suggestion?
12:12:30 <TrasherDK[m]> Anyway. How is my unlock time more than 10 blocks? (58 block(s) to unlock)
12:12:53 <moneromooo> They are supported currently.
12:13:04 <moneromooo> A dummy payment id is added if none is used.
12:13:19 <moneromooo> A chain oberver cannot tell whether one is a dummy or not.
12:13:45 <moneromooo> Coinbases are locked for 60 blocks. People can also set an arbitrary extra lock time.
12:15:45 <TrasherDK[m]> Ah, got it. "Mining at 98 H/s with 1 threads, Expected: 34.485174054337 monero daily" 😎
12:19:50 <spirobel[m]> <moneromooo> "A dummy payment id is added if..." <- I like this one. Super smart thing. If we added this to every transaction nobody could even tell the difference between "normal transactions" and these ones. So on chain indistinguishably would be even better. But it is a pretty good solution as is. 🙂👍️ 
12:20:58 <moneromooo> It would not be better. It would merely remain unharmed by this attempt.
12:21:54 <moneromooo> An observer can tell whether a tx goes to a standard address or a subaddress. Or at least whether at least one output goes to a subaddress. I forget exactly.
12:22:06 <spirobel[m]> <woodser[m]> "spirobel is arguing strongly..." <- I updated the title of the issue. When I first started out to debug this I thought this was a much bigger issue than it actually was. The crash just came from one minor edge case that normal users should never face. We can catch this situation in or above the library.
12:27:43 <spirobel[m]> <moneromooo> "An observer can tell whether a..." <- okay this is interesting. I looked at one of these integrated addresses that was generated from a subaddress with rbrunners tool. The links are in this comment: https://github.com/monero-ecosystem/monero-javascript/issues/90#issuecomment-1148729137 it seems like under the hood the only difference between a subaddress and a standard address (aka a primary address) is the prefix.  Is
12:27:43 <spirobel[m]> there something different about the transactions and the keys? would be interested to read more on this. Is there a part of the codebase that you can recommend I should look at?
12:35:37 <moneromooo> The cryto is a bit different based on whether it's going to a standard address or a subaddress. I'd read the github discussion for the PR which addde subaddresses, IIRC it's got a lot of background info.
12:37:50 <UkoeHB> spirobel[m]: ztm2 section 4.4
13:38:03 <ooo123ooo1234567> <rbrunner> "ooo123ooo1234567, how about..." <- this request is similar to this: would you like to review few placebo patches on top of your own code that was resubmitted by someone else, it would save us some time; facepalm
13:39:35 <ooo123ooo1234567> <rbrunner> "ooo123ooo1234567, how about..." <- probably the worst example of hypocrisy so far, from someone who even suggested me to leave
14:08:24 <sech1> moneromooo any ideas why submit_block RPC would take more than 14 seconds to complete? https://paste.debian.net/hidden/1f432890/
14:08:43 <sech1> that block was full (> 300 kb, 106 transactions)
14:09:00 <sech1> usually it takes 0.2-0.5 seconds on that server
14:23:28 <ooo123ooo1234567> <sech1> "moneromooo any ideas why..." <- is it the only such case ?
14:24:30 <moneromooo> If the blockchain lock was taken maybe.
14:24:47 <moneromooo> Though that shouldn't take too long unless syncing a set of 20.
14:25:20 <moneromooo> If you can repro, you'd have to break in the process and see what threads are doing.
14:26:11 <ooo123ooo1234567> <sech1> "usually it takes 0.2-0.5 seconds..." <- usually mempool isn't 4MB of txs
14:27:25 <ooo123ooo1234567> <sech1> "moneromooo any ideas why..." <- the same reason as many months ago on your server
14:27:52 <moneromooo> Any chance it might be at a random boundary ?
14:27:57 <moneromooo> randomx
14:28:30 <sech1> ooo123ooo1234567 I don't see any such delays in the log, except for this one occasion: https://paste.debian.net/hidden/a29bf002/
14:29:21 <sech1> ah, 4 MB mempool
14:29:24 <sech1> that could be the case
14:29:29 <ooo123ooo1234567> sech1: even if you would know the reason it wouldn't help you, since it isn't easy thing to fix without redesign
14:30:14 <ooo123ooo1234567> it must be fixed from bottom to top, otherwise it's impossible to build complex protocol on top of unstable base
14:30:27 <moneromooo> 4 MB isn't really a lot. We actually got that spam problem a while back, and we sped things up. I remember a few hundred MB I think. So 4 MB ought not mean 14 second txpool processing. I hope.
14:30:27 <sech1> moneromooo no, randomx seed boundary is far away
14:31:00 <sech1> ooo123ooo1234567 I disagree. It looks more like some slow code processing the mempool - O(N^2) or something like that
14:31:04 <moneromooo> I suppose if you received it all at once in one message...
14:32:09 <ooo123ooo1234567> sech1: If it would centralized app then you would be right. But in decentralized code with a lot of ways to abuse, it isn't just unoptimized code
14:32:54 <ooo123ooo1234567> * it would be centralized app
14:33:04 <sech1> here's the log from main p2pool node: https://paste.debian.net/hidden/074af79c/
14:33:17 <sech1> slow submit_block started around the same time mempool got big
14:33:30 <sech1> 4 slow blocks so far
14:34:26 <ooo123ooo1234567> sech1: I reproduced this problem somewhere around Dec/Nov/Oct 2021 and checked under gdb what is going on
14:38:21 <moneromooo> Oh, repeatable -> break in gdb (if you can). Also, perf (eg, perf top).
14:39:14 <sech1> but ooo123 already knows what it is
14:39:42 <sech1> ooo123ooo1234567 just tell me, and I'll assess if it's easy to fix or not
14:40:05 <ooo123ooo1234567> sech1: connection patch firstly
14:40:05 <ooo123ooo1234567> hahahahaha
14:41:48 <sech1> Fine, I'll do it myself. It will just take some time for me to reproduce and debug which can all be avoided right here and now
14:42:23 <sech1> moneromooo pop_blocks into mempool until it's big enough, then starting in offline mode with fixed_diff should work to reproduce it, right?
14:43:12 <moneromooo> Yes, if the issue is txpool size.
14:45:35 <ooo123ooo1234567> sech1: So you've decided to take it as a challenge; interesting how much time it will take
14:47:49 <sech1> lol, have you started a timer already?
14:48:29 <ooo123ooo1234567> sech1: why ? there is already a timestamp associated with each msg
14:48:54 <sech1> because I haven't started looking into it and will not start for another hour or two
14:49:26 <ooo123ooo1234567> sech1: is it easier to debug than reviewing logic in connection patch ?
14:51:12 <sech1> you never know how easy is to debug a bug until you do it
14:52:12 <ooo123ooo1234567> sech1: in this particular case you just have more motivation to debug the problem and expose details about it into public, than verifying already submitted patch
14:54:29 <ooo123ooo1234567> <sech1> "because I haven't started..." <- have you started to review logic or not yet ?
14:57:31 <sech1> not yet
14:57:56 <ooo123ooo1234567> sech1: In general, do you have free time on regular basis to work on monero network ?
14:58:55 <sech1> more like on irregular basis
14:59:11 <ooo123ooo1234567> sech1: hmm, so jeffro256 has some advantage in this race for the first correctness review
15:00:17 <ooo123ooo1234567> sech1: have you finished with implementation of main features for p2pool or not yet ?
15:01:17 <sech1> there will always be things to change in p2pool
15:01:23 <sech1> the curl integration, this is done
15:01:35 <tmoravec[m]> There's 0.18 release planned for next week, correct? When do you expect the release branch to appear in Github?
15:02:13 <sech1> .merges
15:02:13 -xmr-pr- 8296 8356 8357 8358
15:02:21 <sech1> as soon as these 4 PRs are merged
15:03:08 <tmoravec[m]> Wonderful, thanks!
15:04:14 <ooo123ooo1234567> sech1: all those 4 PRs are irrelevant for release branch
15:04:38 <sech1> they are very relevant because if we branch before merging, they'll have to be duplicated
15:04:42 <sech1> more work for nothing
15:35:40 <sech1> well, there's definitely a performance problem with big mempool. Even just popping blocks and then syncing with bit mempool is much slower than syncing with empty mempool
15:36:45 <UkoeHB> syncing for balance check? or syncing for a new node?
15:37:11 <UkoeHB> oh, syncing the popped blocks?
15:37:38 <sech1> syncing monerod
15:37:52 <UkoeHB> is it fully re-validating the mempool after each block? instead of just re-checking key images
15:37:52 <sech1> 1) pop_blocks 100 in offline mode
15:38:00 <sech1> 2) start monerod in normal mode
15:38:03 <sech1> much slower
15:38:18 <sech1> and it's spitting lots of errors
15:38:25 <sech1> because "transaction spends too young inputs"
15:39:57 <UkoeHB> if you are popping into the mempool, a lot of the popped txs will reference other txs in the mempool
15:51:08 <ooo123ooo1234567> <sech1> "more like on irregular basis" <- How would you estimate it relatively to efforts spent on p2pool ? 0.001, 0.5, 0.1, 1.0 ?
15:53:52 <sech1> okay, reproduced the bug
15:53:59 <sech1> 13 seconds to submit_block on my notebook
15:54:23 <sech1> now I need to compile the latest master and run under gdb
15:55:31 <sech1> just did pop_blocks to height 2641278 and then submitted exactly the same blob that was in 2641278
15:55:40 <sech1> daemon accepted it, but after 13 seconds
16:07:53 <sech1> for reference: make debug-static-win64 is broken in MSYS2. Compiler chokes and complains that "file too big" in the end
16:22:10 <sech1> moneromooo stack traces of the relevant threads: https://paste.debian.net/hidden/915db49f/
16:24:17 <sech1> doesn't look good :D
16:24:33 <sech1> tx_memory_pool::get_block_template_backlog() is what needs to be fixed
16:25:29 <sech1> so it is miner notification that goes through the entire mempool and checks each transaction
16:25:43 <sech1> which is why my node has this problem (it runs with --zmq-pub)
16:26:27 <sech1> is_transaction_ready_to_go is 99% of CPU time
16:27:42 <sech1> so even though the mempool was only 4 MB, it had many transaction with 194 inputs, so it's A LOT of inputs to check
16:27:53 <UkoeHB> hmm, called it?
16:28:36 <moneromooo> OK. I forget what _backlog is now...
16:29:04 <moneromooo> CLSAGs do depend on inputs, but ought to be cacheable a lot of the time.
16:29:27 <sech1> caching the answers of verRctCLSAGSimple would help
16:29:42 <UkoeHB> once a tx is in the mempool, you should only need to check ring membership and key images (only fully revalidate when committing a new block)
16:29:50 <sech1> because it's already checked the first time tx is added to the mempool, right?
16:30:46 <sech1> yeah, if I run without --zmq-pub, send_miner_notifications is not called and it takes only 1.2 seconds
16:31:07 <moneromooo> Almost certainly. But IIRC there's already a cache for this. mumble mumble last_hash_check or so.
16:31:07 <moneromooo> from original CN even.
16:31:08 <sech1> *send_miner_notifications is called, but there are no miners to be notified
16:31:21 <hyc> debug builds in windows/MSYS being broken are not an easy thing to fix. must get symbol table below 32768 symbols because windows .obj format is braindead
16:31:39 <sech1> at least the release build gave good enough stack trace
16:31:40 <hyc> I succeeded once in the past by eliminating unneeded boost includes
16:31:46 <sech1> without line numbers, but still I can work with it
16:32:17 <hyc> this is yet another way using C++ cripples us...
16:32:32 <sech1> *boost
16:32:37 <sech1> Everyone hates boost
16:32:49 <hyc> but in reality boost is just early access to std::
16:32:56 <hyc> the situation doesn't really improve
16:33:03 <ooo123ooo1234567> sech1: not everyone
16:33:49 <sech1> ooo123ooo1234567 so is it the same issue that you found?
16:33:51 <sech1> tx_memory_pool::check_tx_inputs
16:34:20 <hyc> eliminating templates would help a lot. tons of redundant defs from epee network crap
16:35:49 <hyc> C++ is supposed to support modularity better than C. instead all of this codebase is tightly coupled to header files that have nothing to do with the source file being compiled
16:36:31 <sech1> hmm, tx_memory_pool already has m_input_cache
16:36:54 <UkoeHB> is that a C++ or a software engineering problem? or both? lol
16:37:44 <sech1> C++ over-templating problem
16:37:45 <UkoeHB> presumably modules will improve that issue
16:48:14 <ooo123ooo1234567> <sech1> "ooo123ooo1234567 so is it the..." <- I may pretend that it's that issue. Will it give enough motivation to check connection patch ?
16:48:15 <ooo123ooo1234567> * it give you enough motivation
16:48:49 <sech1> So it's a different issue. You probably wasn't testing it with --zmq-pub, 
16:50:29 <ooo123ooo1234567> sech1: I mean it isn't everything that can be found there.
16:50:42 <sech1> oh I'm sure
16:51:13 <sech1> check_tx_inputs can definitely be cached because it's already called when a tx enters mempool
16:51:18 <sech1> it's called again when a block is added
16:51:33 <sech1> but it must be done very carefully as it's a part of consensus
16:51:44 <sech1> I mean caching of this function
16:52:02 <sech1> need to identify all inputs for this function
16:52:50 <sech1> or I could just limit the mempool to 1 MB on my node and be done with it for now
16:53:20 <hyc> epee templating is bad s/w engineering, definitely. it already uses class inheritance to handle rpc vs p2p connections. it doesn't need templating to implement them
16:53:36 <ooo123ooo1234567> sech1: or even put node into offline node, no connections - no problems
16:54:13 <hyc> pretty much everything you need a network layer to do can be done by a single set of functions on the base class. specialization can be isolated easily
16:54:33 <hyc> templating means all of those base functions are implemented redundantly
16:54:39 <hyc> it's moronic
16:55:16 <sech1> hmm, I already run with --max-txpool-weight 10485760
16:55:19 <sech1> 10 MB
16:55:35 <UkoeHB> I suppose C++ makes it easier to write disgusting code
17:01:35 <ooo123ooo1234567> <sech1> "C++ over-templating problem" <- It depends
17:02:06 <sech1> please, this is not a channel for offtopic
17:16:39 <ooo123ooo1234567> <hyc> "epee templating is bad s/w..." <- it will be complex no matter what is being used to implement it. templates can be removed in places where they are not needed later
19:00:21 <sech1> moneromooo I have a plan how to fix this 14-second delay in submit_block. tx_memory_pool::get_block_template_backlog() is used only by p2pool now, and it send _all_ eligible mempool transactions. If mempool is big, it's slow. What it really needs to do is to send a bit more than 300 KB (median_weight) worth of transactions, starting from the best
19:00:21 <sech1> paying ones. This will put a cap on how much time it takes, independent of mempool size
19:01:31 <sech1> so something like median_weight * 1.1 will be enough to mine full blocks
19:11:54 <freedomf8ter[m]> Hi everyone. I'm looking to build a website that accepts XMR as a payment option. Is there anyone here that would like to collaborate / brainstorm? 
19:11:55 <freedomf8ter[m]> We already have a front end web app that is built with Vue, but I'm not sure about the best way to go about integrating with Monero. PM if this is something that is of any interest to you.
19:16:39 <ofrnxmr[m]> > <@freedomf8ter:matrix.org> Hi everyone. I'm looking to build a website that accepts XMR as a payment option. Is there anyone here that would like to collaborate / brainstorm? 
19:16:39 <ofrnxmr[m]> > 
19:16:40 <ofrnxmr[m]> > We already have a front end web app that is built with Vue, but I'm not sure about the best way to go about integrating with Monero. PM if this is something that is of any interest to you.
19:16:40 <ofrnxmr[m]> #monero-community-dev:monero.social 
19:16:46 <ofrnxmr[m]> and
19:16:46 <ofrnxmr[m]> #monero-community:monero.social 
19:17:59 * freedomf8ter[m] uploaded an image: (75KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/IkuUHjdngSOPtuDWmNIfsqtg/image.png >
19:18:04 <cryptogrampy[m]> > <@freedomf8ter:matrix.org> Hi everyone. I'm looking to build a website that accepts XMR as a payment option. Is there anyone here that would like to collaborate / brainstorm? 
19:18:04 <cryptogrampy[m]> > 
19:18:04 <cryptogrampy[m]> > We already have a front end web app that is built with Vue, but I'm not sure about the best way to go about integrating with Monero. PM if this is something that is of any interest to you.
19:18:04 <cryptogrampy[m]> check out hotshop.onrender.com/ :) 
19:18:55 * freedomf8ter[m] uploaded an image: (74KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/tmmVYKNDHhtHBbmCoVOrgKUj/image.png >
19:19:39 <freedomf8ter[m]> cryptogrampy[m]: Yes, I saw it. Very cool project, but would it work for an eCommerce website as is?
19:24:59 <cryptogrampy[m]> <ofrnxmr[m]> "> <@freedomf8ter:matrix.org..." <- this is probably the best option.  monero-dev is for core discussion.  pop in here and let's chat :) 
19:26:49 <freedomf8ter[m]> cryptogrampy[m]: Sorry, I didn't realize. Thank for bringing this to my attention. I joined the community dev channel.
20:59:36 <sech1> moneromooo ooo123ooo1234567 https://github.com/monero-project/monero/pull/8381
21:16:06 <sech1> Running the node on p2pool.io with this PR now, let's see how it goes
23:59:59 <hyc> sheesh. gdb eats 100% CPU just giving me a backtrace in core_tests