02:05:08 UkoeHB: is this a good way of approaching a different idea. I sought there could be possibility in such idea...but never said which way to approach it...but you instead block the whole idea. I think, if not for lack of understanding in our conversation, there should a felexibility...this is all about it..not to remain static in the things that are possible... and I think a dev I presume should lead in creating such a platform where the 02:05:08 posssibility of ideas could have a space..but in such instance I see no lead. 02:14:14 the means to an end don't matter much if the end can be rejected 12:32:20 monero is flexible regarding the specific technologies and techniques used to achieve its goals. it is not flexible about its goals. 13:03:30 greetings, I'm using a regtest network in my development with several nodes, and today upgraded nodes from 0.18.1.0 to 0.18.1.2. It gives me the following errors: 2022-10-15 13:01:10.261 E wallet_is_outdated || daemon_is_outdated. THROW EXCEPTION: error::incorrect_fork_version 13:03:30 2022-10-15T13:01:10.262072011Z 2022-10-15 13:01:10.262 E Exception at while refreshing, what=Unexpected hard fork version v16 at height 1. Make sure the node you are connected to is running the latest version 13:03:39 same for 0.18.1.1 13:04:46 all nodes are dockerized and the monerod command I'm throwing is monerod --regtest --non-interactive --no-igd --hide-my-port --data-dir /stagenet/"${daemon_user}" --p2p-bind-ip 0.0.0.0 --log-level 0 --rpc-bind-ip 0.0.0.0 ${exc_all[*]} --confirm-external-bind --fixed-difficulty 1 --p2p-bind-port "${p2p}" --rpc-bind-port "$(("${p2p}" + 1))" --zmq-rpc-bind-port "$(("${p2p}" + 2))" --rpc-login="${daemon_user}:${daemon_ 13:04:46 password}" 13:05:20 v16 at 1 is as expected, regtest starts off the most recent known fork. 13:05:49 What program gives you this error ? 13:06:20 I don't remember this message, but it sounds like wallet side. Is this some third party wallet ? 13:06:23 I think its monero-wallet-rpc my container runs both monerod and the rpc 13:06:35 euri10: there is a flag for it 13:06:41 Maye it's new then, but the wallet doesn't check forks AFAIK. 13:07:02 ok this is a new flag on monero-wallet-rpc you mean 13:07:04 ? 13:07:06 allow-mismatched-daemon-version 13:07:13 oO 13:07:20 ok will try that !! 13:07:36 moneromooo: yes we added it after the hardfork after so many people kept connecting to outdated nodes 13:07:38 not sure I'm following what's happening but 13:08:28 might make sense to set --allow-mismatched-daemon-version by default when running regtest 13:14:55 selsta: it's working fine now thanks a lot 13:16:22 just for my understanding, did it happen because the monero-wallet-rpc is "constrained" on using a daemon version and having a regtest then it considers I'm not using the correct fork ? 13:18:26 regtest is mainnet with a few hacks really. 13:20:25 euri10: https://github.com/monero-project/monero/pull/8544 13:23:12 much appreciated selsta 15:42:53 I think not, but is there an easy way to get the transaction which spends a key image? monerod has `get_key_image_spent_status`, but I'd like to get the spending tx to know when it confirmed 16:10:17 mm key images aren't indexed afaik so it's be pretty inefficient to search 16:10:42 actually not bad nvm they are by height 16:36:30 seraphis plug: the balance recovery process I built includes context for spent and received enotes, like tx id, block height, and ‘status’ (onchain, unconfirmed, offchain, unspent for spent statuses)