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

cryptogrampy[m]: afaik you'd have to implement it

this does something similar to what you want (as an example): github.com/monero-project/monero/bl…ter/src/multisig/multisig_kex_msg.h

cryptogrampy[m]: yes

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

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.

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

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

any advice would be greatly appreciated

disregard ^ above regarding transfer - it already does that

despite not being officially supported in monero-project, are integrated addresses theoretically safe to use?

spirobel is arguing strongly in their favor to accommodate their application use case: monero-ecosystem/monero-javascript #90#issuecomment-1148729137

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

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

s/addresses/subaddresses/

It would just fuck up the efforts people made to improve things, but it'd work.

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.

it sounds like they need the payment id for external viewing, but also need to send to subaddresses

Or even something like moneroaddress+64bitnumber

Then it'd be obvious the addresses are the same when the extra payment id is removed.

In fact, monero:ADDRESS&payment_id=x

I knoew it'd come in handy at some point :D

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.

But then I suppose the goal isn't to blend in if trying to ram a feature through on the side :/

There are two things really (that I remmeber off the top of my head). The user confusion and the on-chain distinguishibility.

yeah. the issue of not generating a dummy payment id when all outs are subaddresses could be addressed separately

<moneromooo> "There are two things really (..." <- on chain distinguishibility also applies to "normal integrated addresses". They are currently supported, right?

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?

Anyway. How is my unlock time more than 10 blocks? (58 block(s) to unlock)

They are supported currently.

A dummy payment id is added if none is used.

A chain oberver cannot tell whether one is a dummy or not.

Coinbases are locked for 60 blocks. People can also set an arbitrary extra lock time.

Ah, got it. "Mining at 98 H/s with 1 threads, Expected: 34.485174054337 monero daily" 😎

<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. 🙂👍️

It would not be better. It would merely remain unharmed by this attempt.

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.

<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.

<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: monero-ecosystem/monero-javascript #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

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?

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.

spirobel[m]: ztm2 section 4.4

<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

<rbrunner> "ooo123ooo1234567, how about..." <- probably the worst example of hypocrisy so far, from someone who even suggested me to leave

moneromooo any ideas why submit_block RPC would take more than 14 seconds to complete? paste.debian.net/hidden/1f432890

that block was full (> 300 kb, 106 transactions)

usually it takes 0.2-0.5 seconds on that server

<sech1> "moneromooo any ideas why..." <- is it the only such case ?

If the blockchain lock was taken maybe.

Though that shouldn't take too long unless syncing a set of 20.

If you can repro, you'd have to break in the process and see what threads are doing.

<sech1> "usually it takes 0.2-0.5 seconds..." <- usually mempool isn't 4MB of txs

<sech1> "moneromooo any ideas why..." <- the same reason as many months ago on your server

Any chance it might be at a random boundary ?

randomx

ooo123ooo1234567 I don't see any such delays in the log, except for this one occasion: paste.debian.net/hidden/a29bf002

ah, 4 MB mempool

that could be the case

sech1: even if you would know the reason it wouldn't help you, since it isn't easy thing to fix without redesign

it must be fixed from bottom to top, otherwise it's impossible to build complex protocol on top of unstable base

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.

moneromooo no, randomx seed boundary is far away

ooo123ooo1234567 I disagree. It looks more like some slow code processing the mempool - O(N^2) or something like that

I suppose if you received it all at once in one message...

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

* it would be centralized app

here's the log from main p2pool node: paste.debian.net/hidden/074af79c

slow submit_block started around the same time mempool got big

4 slow blocks so far

sech1: I reproduced this problem somewhere around Dec/Nov/Oct 2021 and checked under gdb what is going on

Oh, repeatable -> break in gdb (if you can). Also, perf (eg, perf top).

but ooo123 already knows what it is

ooo123ooo1234567 just tell me, and I'll assess if it's easy to fix or not

sech1: connection patch firstly

hahahahaha

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

moneromooo pop_blocks into mempool until it's big enough, then starting in offline mode with fixed_diff should work to reproduce it, right?

Yes, if the issue is txpool size.

sech1: So you've decided to take it as a challenge; interesting how much time it will take

lol, have you started a timer already?

sech1: why ? there is already a timestamp associated with each msg

because I haven't started looking into it and will not start for another hour or two

sech1: is it easier to debug than reviewing logic in connection patch ?

you never know how easy is to debug a bug until you do it

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

<sech1> "because I haven't started..." <- have you started to review logic or not yet ?

not yet

sech1: In general, do you have free time on regular basis to work on monero network ?

more like on irregular basis

sech1: hmm, so jeffro256 has some advantage in this race for the first correctness review

sech1: have you finished with implementation of main features for p2pool or not yet ?

there will always be things to change in p2pool

the curl integration, this is done

There's 0.18 release planned for next week, correct? When do you expect the release branch to appear in Github?

.merges

as soon as these 4 PRs are merged

Wonderful, thanks!

sech1: all those 4 PRs are irrelevant for release branch

they are very relevant because if we branch before merging, they'll have to be duplicated

more work for nothing

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

syncing for balance check? or syncing for a new node?

oh, syncing the popped blocks?

syncing monerod

is it fully re-validating the mempool after each block? instead of just re-checking key images

1) pop_blocks 100 in offline mode

2) start monerod in normal mode

much slower

and it's spitting lots of errors

because "transaction spends too young inputs"

if you are popping into the mempool, a lot of the popped txs will reference other txs in the mempool

<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 ?

okay, reproduced the bug

13 seconds to submit_block on my notebook

now I need to compile the latest master and run under gdb

just did pop_blocks to height 2641278 and then submitted exactly the same blob that was in 2641278

daemon accepted it, but after 13 seconds

for reference: make debug-static-win64 is broken in MSYS2. Compiler chokes and complains that "file too big" in the end

moneromooo stack traces of the relevant threads: paste.debian.net/hidden/915db49f

doesn't look good :D

tx_memory_pool::get_block_template_backlog() is what needs to be fixed

so it is miner notification that goes through the entire mempool and checks each transaction

which is why my node has this problem (it runs with --zmq-pub)

is_transaction_ready_to_go is 99% of CPU time

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

hmm, called it?

OK. I forget what _backlog is now...

CLSAGs do depend on inputs, but ought to be cacheable a lot of the time.

caching the answers of verRctCLSAGSimple would help

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)

because it's already checked the first time tx is added to the mempool, right?

yeah, if I run without --zmq-pub, send_miner_notifications is not called and it takes only 1.2 seconds

Almost certainly. But IIRC there's already a cache for this. mumble mumble last_hash_check or so.

from original CN even.

*send_miner_notifications is called, but there are no miners to be notified

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

at least the release build gave good enough stack trace

I succeeded once in the past by eliminating unneeded boost includes

without line numbers, but still I can work with it

this is yet another way using C++ cripples us...

*boost

Everyone hates boost

but in reality boost is just early access to std::

the situation doesn't really improve

sech1: not everyone

ooo123ooo1234567 so is it the same issue that you found?

tx_memory_pool::check_tx_inputs

eliminating templates would help a lot. tons of redundant defs from epee network crap

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

hmm, tx_memory_pool already has m_input_cache

is that a C++ or a software engineering problem? or both? lol

C++ over-templating problem

presumably modules will improve that issue

<sech1> "ooo123ooo1234567 so is it the..." <- I may pretend that it's that issue. Will it give enough motivation to check connection patch ?

* it give you enough motivation

So it's a different issue. You probably wasn't testing it with --zmq-pub,

sech1: I mean it isn't everything that can be found there.

oh I'm sure

check_tx_inputs can definitely be cached because it's already called when a tx enters mempool

it's called again when a block is added

but it must be done very carefully as it's a part of consensus

I mean caching of this function

need to identify all inputs for this function

or I could just limit the mempool to 1 MB on my node and be done with it for now

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

sech1: or even put node into offline node, no connections - no problems

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

templating means all of those base functions are implemented redundantly

it's moronic

hmm, I already run with --max-txpool-weight 10485760

10 MB

I suppose C++ makes it easier to write disgusting code

<sech1> "C++ over-templating problem" <- It depends

please, this is not a channel for offtopic

<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

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

paying ones. This will put a cap on how much time it takes, independent of mempool size

so something like median_weight * 1.1 will be enough to mine full blocks

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?

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.

> <@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?

>

> 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.

#monero-community-dev:monero.social

and

#monero-community:monero.social

> <@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?

>

> 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.

check out hotshop.onrender.com/ :)

cryptogrampy[m]: Yes, I saw it. Very cool project, but would it work for an eCommerce website as is?

<ofrnxmr[m]> "> <@freedomf8ter:matrix.org..." <- this is probably the best option. monero-dev is for core discussion. pop in here and let's chat :)

cryptogrampy[m]: Sorry, I didn't realize. Thank for bringing this to my attention. I joined the community dev channel.

moneromooo ooo123ooo1234567 monero-project/monero #8381

Running the node on p2pool.io with this PR now, let's see how it goes

sheesh. gdb eats 100% CPU just giving me a backtrace in core_tests