Hi there! I'm trying to make Monero node to log errors and these two categories: blockchain and daemon.rpc. When I set log-level="*:ERROR,daemon.rpc:INFO,blockchain:INFO" I dont get any blockchain logs, when I set log-level="*:ERROR,lockchain:INFO,daemon.rpc:INFO" then I don't get any RPC logs. Is there a way to solve my problem?

Hey

The log settings both appear correct (assuming lockchain is a typo just on IRC). You may want to add 0, first though, to not silence the usual output.

The log will include the new log level when it changes, check that it is what you expect, in case reading from the config file does not do what you think it does.

Seems like everything started to work fine when I removed quotes from config file

Now I use log-level=*:ERROR,daemon.rpc:INFO,blockchain:INFO and I get both RPC and blockchain logs, but when I bring quotes back the problem comes back again

<j​effro256:monero.social> Try using single quotes. The asterisk character might be globbing files in your local directory

When I use single quotes the problem comes back

A solution suggests itself... :D

Yes, thank you for your help!

<b​inarybaron:matrix.org> Suppose the following situation: I have two devices. Both have a Monero wallet with the same keys. The two devices share a magic merge-conflict free JSON like structure which they can both edit and which will eventually sync to be the same devices.

<b​inarybaron:matrix.org> The wallet is restored from block height 100. Device 1 syncs the wallet up to height 200 and discovers that the wallet has received 1 XMR. What’s the minimal data Device 1 needs to insert into the shared struct to allow Device 2 to continue syncing where Device 1 left off (without having to scan blocks 100-200)

<b​inarybaron:matrix.org> Suppose the following situation: I have two devices. Both have a Monero wallet with the same keys. The two devices share a magic merge-conflict free JSON like structure which they can both edit and which will eventually sync to be the same on both devices.

<b​inarybaron:matrix.org> The wallet is restored from block height 100. Device 1 syncs the wallet up to height 200 and discovers that the wallet has received 1 XMR. What’s the minimal data Device 1 needs to insert into the shared struct to allow Device 2 to continue syncing where Device 1 left off (without having to scan blocks 100-200)

<b​inarybaron:matrix.org> I‘m thinking Device 1 can simply:

<b​inarybaron:matrix.org> - export the transaction history (with the one incoming transfer), save the txid and block height of the transaction in the shared struct.

<b​inarybaron:matrix.org> - export the block checkpoint (?) and save it in the shared struct

<b​inarybaron:matrix.org> Device 2 can the import those transactions and set their checkpoint to the one of Device 1.

<b​inarybaron:matrix.org> Anything fundamentally flawed about this approach?

<b​inarybaron:matrix.org> Suppose the following situation: I have two devices. Both have a Monero wallet with the same keys. The two devices share a magic merge-conflict free JSON like structure which they can both edit and which will eventually sync to be the same on both devices.
The wallet is restored from block height 100. Device 1 syncs the wallet up to height 200 and discovers that the wallet has r<clipped message>

<b​inarybaron:matrix.org> eceived 1 XMR. What’s the minimal data Device 1 needs to insert into the shared struct to allow Device 2 to continue syncing where Device 1 left off (without having to scan blocks 100-200)

<b​inarybaron:matrix.org> I‘m thinking Device 1 can simply:

<b​inarybaron:matrix.org> • export the transaction history (with the one incoming transfer), save the txid and block height of the transaction in the shared struct.

<b​inarybaron:matrix.org> • export the block checkpoint (?) and save it in the shared struct

<b​inarybaron:matrix.org> Device 2 can go through those transactions. If a transaction is not present in the local wallet: manually fetch and scan the transaction and scan it. Then set their checkpoint to the one in shared struct.

<b​inarybaron:matrix.org> Anything fundamentally flawed about this approach?

<b​inarybaron:matrix.org> Suppose the following situation: I have two devices. Both have a Monero wallet with the same keys. The two devices share a magic merge-conflict free JSON like structure which they can both edit and which will eventually sync to be the same on both devices.

<b​inarybaron:matrix.org> 
The wallet is restored from block height 100. Device 1 syncs the wallet up to height 200 and discovers that the wallet has received 1 XMR.

<b​inarybaron:matrix.org> What’s the minimal data Device 1 needs to insert into the shared struct to allow Device 2 to continue syncing where Device 1 left off (without having to scan blocks 100-200)

<b​inarybaron:matrix.org> 
I‘m thinking Device 1 can simply:
• export the transaction history (with the one incoming transfer), save the txid and block height of the transaction in the shared struct.
• export the block checkpoint (?) and save it in the shared struct


<b​inarybaron:matrix.org> Device 2 can then go through those transactions. If a transaction is not present in the local wallet: manually fetch and scan the transaction. Then set their checkpoint to the one in shared struct.

<b​inarybaron:matrix.org> 
Anything fundamentally flawed about this approach?

<r​ucknium:monero.social> binarybaron: Don't edit messages in rooms relayed to IRC because it looks like this: libera.monerologs.net/monero-dev/20250519#c526590-c526611

<r​ucknium:monero.social> And you need the IRC side :)

<b​inarybaron:matrix.org> Oh god, sorry

<o​frnxmr:xmr.mx> "scan_tx"

<o​frnxmr:xmr.mx> or "restore_height" :D

<o​frnxmr:xmr.mx> xyproblem.info perhaps. Seems this is an issue that is solved by using scan_tx or setting restore height

<j​effro256:monero.social> It depends on what the trust assumptions between the wallets are. One problem that jumps to mind is that one of the devices can do a burning-bug attack on the other by including an output with the same onetime address but with a 0-amount, tell the wallet it scanned past a certain point, and omit the *real* output with a non-0 amount in the shared structure. Carrot fixes this, but<clipped message>

<j​effro256:monero.social> you would have to worry about it for spending pre-Carrot monero enotes

<j​effro256:monero.social> Also tbc, it doesn't *have* to be a 0-amount for a successful burning bug attack, in fact it's probably more likely to work if it's a very small amount, but still greater than a tx fee. That way the other device will actually spend it