07:23:37 <Halver[m]> <Inge> "check block height against..." <- Thanks. I may do that, but first I wanted to be sure that there the timestamp from _get_last_block_header_ is the more recent timestamp from all the available monerod RPCs ?
07:24:11 <Halver[m]> > <@Inge:libera.chat> check block height against some other nodes?
07:24:11 <Halver[m]>  * Thanks. 
07:24:11 <Halver[m]> I may do that, but first I wanted to be sure that the timestamp from _get_last_block_header_ is the more recent timestamp from all the available monerod RPCs (?)
09:37:55 <merope> Doesn't the node already check against all other nodes via the p2p protocol? But it does so through the block height, not the timestamp
09:39:10 <merope> If you really wanted to check timestamps, I'd just grab the latest one from the top block and check that it's no more than 30mins-1h behind the current time
09:42:53 <moneromooo> IIRC the max "jitter" is 2 hours.
09:47:15 <Halver[m]> Thanks for the informations.
09:48:20 <Halver[m]> I have noticed that the block height returned from get_last_block_header can be easily 4 or 5 blocks behind what status says in monerod.
09:49:10 <Halver[m]> I wonder what's the reason for this lag (?)
09:50:18 <Halver[m]> I'll check if the timestamp from the top block is better/more recent.
09:55:55 <moneromooo> Does get_info also show this same lag ?
09:57:03 <moneromooo> The one thing I can think of is that it might use a longer lived read txn that has a view of an older db state, but in theory it should also apply to status.
10:19:43 <Halver[m]> I'll check those RPCs and try to evaluate the lags which each.
11:07:53 <Halver[m]> s/which/for/
14:33:49 <Halver[m]> I didn't notice, but get_info has :
14:33:52 <Halver[m]> synchronized - boolean; States if the node is synchronized (true) or not (false).
18:41:21 <tusko> synchronized nodes are for squares
21:24:43 <lookaside[m]> Yesterday I asked in the monero room how I might send a transfer where the fee is deducted from the amount I want to send, i.e. make it so exactly some amount leaves the wallet. This is what I came up with using the monero-python library, wondering if it looks reasonable:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ce9f5817a178308048bad05bd387565f937efcee)
21:57:46 <lookaside[m]> I'm also curious under what conditions it could fail - I'm guessing that when I request the 2nd transfer there's a chance that the fee changes and I would have to recalculate everything
22:24:06 <selsta> .merges
22:24:06 -xmr-pr- 8041 8044 8101
23:54:42 <Elijah[m]> > <@lookaside:matrix.org> Yesterday I asked in the monero room how I might send a transfer where the fee is deducted from the amount I want to send, i.e. make it so exactly some amount leaves the wallet. This is what I came up with using the monero-python library, wondering if it looks reasonable:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/13fc1390baa519fe711d724ebf511dc99ccb7073)
23:54:53 <Elijah[m]> * 
23:54:53 <Elijah[m]> I'm going to presume you want to guarantee sending X monero post fees? If so you would want to add the transaction fee to the amount and not subtract it. That way sending X + T monero results in X monero being sent rather than sending X - T monero. 
23:55:05 <Elijah[m]> s/I'm going to presume you want to guarantee sending X monero post fees? If so you would want to add the transaction fee to the amount and not subtract it//
23:55:08 <Elijah[m]> I'm going to presume you want to guarantee sending X monero post fees? If so you would want to add the transaction fee to the amount and not subtract it. That way sending X + T monero results in X monero being sent rather than sending X - T monero. 
23:56:44 <Elijah[m]> s/and/rather/, s/not/than/, s/subtract/subtracting/