<j​effro256:monero.social> Are you sure that they are actually connected to each other?

<j​effro256:monero.social> Because if not, a node that is supposed to be online but has 0 connections, and hasn't yet connected to a node will return "busy" errors

<s​arg22:matrix.org> yes. when I type "status" in both they show 1 in and 1 out

Is is a mode which has any checkpoints ? If so, that will happen and you need to remove checkpoints.

You said testnet so unlikely if you mean actual testnet, but I've seen that happen before.

Oh, testnet does seem to have checkpoints (src/checkpoints).

not sure if related: checkpoints for fast sync in testnet require this change spackle-xmr/monero #35/files#diff-3dcea545b20bc1145f2766e64ca91d4e547d6072462970fd67830e1be6cdf793

<p​hqfgtvy:matrix.org> how can i check the balance of a subaddress of monero publicly if i have the view key?

<s​arg22:matrix.org> I have removed checkpoints from src/checkpoints. Is the "SYNCHRONIZED OK" suppossed to appear after 100/100 synced? I'm not seeing the OK.

<o​frnxmr:monero.social> Setup a third node

<o​frnxmr:monero.social> A > B, B > C, C > A

<o​frnxmr:monero.social> make sure `--allow-local-ip --max-connections-per-ip=3` is set

<s​arg22:matrix.org> Testing now..

and you're following this guide? github.com/moneroexamples/private-testnet

Yes, it is supposed to appear.

I've seen it fail to show up from time to time, there is likely a bug somewhere.

does subaddress-lookahead not do what it's supposed to?

<p​lowsof:matrix.org> open source their backend and someone can take a look or offer a bounty for help

<o​frnxmr:monero.social> Or tell them to fix their matrix or come here

<o​frnxmr:monero.social> Twitter is the best support platform

<p​lowsof:matrix.org> or is this the related issue: monero-project/monero #8980

<o​frnxmr:monero.social> pretty sure they are using the command wrong

yeah I was wondering if it isn't related to an open issue

my expectation is that they've created a ton of subaddresses - one for every new invoice

and so they have to lookahead past unpaid invoices

which might number in the thousands

Given that they are a merchant, 1000 seems a bit little?

Especially if they use one address per invoice/payment

I mean they know internally how many are unpaid, no clue

<o​frnxmr:monero.social> Are they using cli or rpc?

definitely RPC - their payments are automated

<o​frnxmr:monero.social> Twit says cli, but that seems strange

<r​ucknium:monero.social> If they are looking for a specific payment, then maybe they would have to re-scan the blockchain after resetting the lookahead value. Also, should subaccount lookahead really be zero? Probably it is ok, but a non-zero value could rule out more problems.

<o​frnxmr:monero.social> They should try tunning it with startup flags instead of `set` and see if that has any diff behavior

<o​frnxmr:monero.social> Meantime ill see abt getting the interactive flag fixed / investigated

<o​frnxmr:monero.social> By default there are 50x200 address lookahead. Thats 10000 addresses. Probably easier to use 200 then switch accounts

<o​frnxmr:monero.social> They should try tunning it with startup flags instead of `set` and see if that has any diff behavior << nvm this doesnt work with an existing wallet

<o​frnxmr:monero.social> When i create a wallet with --subaddress-lookahead 50:500, it works

<o​frnxmr:monero.social> Seems that the `set` method may be broken. Will try that now

<o​frnxmr:monero.social> Yeah. `set` method is bogus

<s​arg22:matrix.org> Tried 3 nodes, no difference

<s​arg22:matrix.org> There are no errors connecting nodes to each other, they sync, the OK message doesn't appear but that's it.

<s​arg22:matrix.org> Connecting CLI wallet to one of the nodes gives:

<s​arg22:matrix.org> ```[127.0.0.1:59276 cb82f094-f991-4e67-bdf6-ebca88add4fd INC] NEW CONNECTION

<s​arg22:matrix.org> 2024-09-09 15:24:15.288 D connection type 2 127.0.0.1:1235 <--> 127.0.0.1:59276 (via 127.0.0.1:59276)

<s​arg22:matrix.org> 2024-09-09 15:24:15.349 E [127.0.0.1:59276 INC] Signature mismatch, connection will be closed```

<s​arg22:matrix.org> There are no errors connecting nodes to each other, they sync, the OK message doesn't appear but that's it.

<s​arg22:matrix.org> Connecting CLI wallet to one of the nodes gives:

<s​arg22:matrix.org> `[127.0.0.1:59276 cb82f094-f991-4e67-bdf6-ebca88add4fd INC] NEW CONNECTION

<s​arg22:matrix.org> 2024-09-09 15:24:15.288 D connection type 2 127.0.0.1:1235 <--> 127.0.0.1:59276 (via 127.0.0.1:59276)

<s​arg22:matrix.org> 2024-09-09 15:24:15.349 E [127.0.0.1:59276 INC] Signature mismatch, connection will be closed`

<s​arg22:matrix.org> start_mining still doesn't work because daemon is "busy"

<o​frnxmr:monero.social> delete lmdb and try again?

<s​arg22:matrix.org> Doesn't fix it

<s​arg22:matrix.org> SYNCHRONIZATION started

<s​arg22:matrix.org> Synced 99/99

<s​arg22:matrix.org> SYNCHRONIZATION started

<s​arg22:matrix.org> Synced 99/99

<s​arg22:matrix.org> Daemon is busy can't use start_mining

<s​arg22:matrix.org> no idea why

<o​frnxmr:monero.social> How did you sync to 99 without mining

<s​arg22:matrix.org> I mined on one node using --offline then the other nodes synced the offline mined blocks when added as exclusive peers

<o​frnxmr:monero.social> Why --offline?

<o​frnxmr:monero.social> github.com/moneroexamples/private-testnet

<o​frnxmr:monero.social> follow guide here for "start first node"

hello friends

hello, john_alan

<w​oodser:monero.social> I can build v0.18.3.4 on macos by applying PR 9462, but I'm still getting this error building monero-cpp, when importing cryptonote_basic/account.h:

<w​oodser:monero.social> In file included from /Users/woodser/git/monero-ts/external/monero-cpp/src/wallet/monero_wallet_keys.h:56:

<w​oodser:monero.social> In file included from /Users/woodser/git/monero-ts/external/monero-cpp/external/monero-project/src/cryptonote_basic/account.h:33:

<w​oodser:monero.social> In file included from /Users/woodser/git/monero-ts/external/monero-cpp/external/monero-project/src/cryptonote_basic/cryptonote_basic.h:41:

<w​oodser:monero.social> In file included from /Users/woodser/git/monero-ts/external/monero-cpp/external/monero-project/src/serialization/binary_archive.h:43:

<w​oodser:monero.social> /Users/woodser/git/monero-ts/external/monero-cpp/external/monero-project/contrib/epee/include/span.h:165:5: error: static assertion failed due to requirement 'std::is_trivially_copyable<epee::mlocked<tools::scrubbed<crypto::ec_scalar>>>()': type must be trivially copyable

<w​oodser:monero.social> static_assert(std::is_trivially_copyable<T>(), "type must be trivially copyable");

<w​oodser:monero.social> any ideas?

<w​oodser:monero.social> found by fix, by adding `rct::sk2rct` around keys

<s​arg22:matrix.org> because i can't mine any other way, offline worked but when connecting nodes to each other mining says daemon is busy error

<s​arg22:matrix.org> I followed the guide you linked but it doesn't work. Thats how i got the daemon busy error

<o​frnxmr:monero.social> Did you follow the guide exactly as written?

<o​frnxmr:monero.social> Ill try to reproduce

<s​arg22:matrix.org> Do it with a new private chain and mine some blocks with peers connected see if it works or regtest

<o​frnxmr:monero.social> Working fine here..

<o​frnxmr:monero.social> Monero Support

<s​arg22:matrix.org> Have you tried with an empty chain and mine a few blocks?

<o​frnxmr:monero.social> Yes

<o​frnxmr:monero.social> Thats exactly what im doing atm

<s​arg22:matrix.org> In offline or not?

<o​frnxmr:monero.social> No

<o​frnxmr:monero.social> Monero Support

<s​arg22:matrix.org> Have you removed checkpoints?

<o​frnxmr:monero.social> Monero Support please

<o​frnxmr:monero.social> Passing this off to my associate ofrnxmr:xmr.mx