08:50:55 why is MINED_MONEY_UNLOCK_WINDOW larger than DEFAULT_TX_SPENDABLE_AGE? is there any security reason behind this choice? 09:09:15 xfedex, I guess that you want to mature newly created outputs more (for safety and reorgs) than the ones that are already known and been spent before? 09:35:49 The reason is that normal reorg will mine reorged normal transactions in 99% of cases, so 10 blocks lock time is enough for them. But if a mined block is reorged, that output disappears completely, which is why it's set to larger value (60 blocks) 11:54:49 Ok, thank you 13:42:13 xfedex: https://github.com/monero-project/research-lab/issues/104#issuecomment-1186552665 17:20:45 reminder to please run release-v0.18 branch if you want to test the new release 17:21:00 there were a lot of changes so multiple testers would be good 18:21:02 hello everyone 18:21:16 are any of the monero-rs maintainers around? 20:57:39 Is there a method on the monero wallet rpc I can call to check if the daemon is connected to really is avaliable without having to create a wallet? 21:02:18 Looking at it, refresh might throw an error if it fails to refresh (typically due to no daemon). 22:07:31 Does getheight on the monero-wallet-rpc return get current blockchain height or the height to which the monero-wallet-rpc has scanned the blockchain for transactions? I want to effectively call refresh without actually scanning any new blocks (start scanning from current blockchain height) 22:11:08 Does getheight on the monero-wallet-rpc return get current blockchain height or the height to which the monero-wallet-rpc has scanned the blockchain for transactions? I want to effectively call refresh without actually scanning any new blocks (start scanning from current blockchain height to skip any new blocks) because my wallet exists solely to check if we can connect to the daemon