01:49:50 <m-relay> <h​ardhatter:monero.social> Does anyone know why my unlocked_balance returned from the wallet-rpc is 0 but the total balance is correct, While both the unlocked_balance and total balance from the wallet-cli are the same and the correct amounts? The unlocked balance shouldn’t be 0 as the rpc is showing
05:08:22 <m-relay> <t​hegoodlabel:matrix.org> tx_extra.h    "struct tx_extra_mysterious_minergate"
05:08:24 <m-relay> <t​hegoodlabel:matrix.org> ????
05:08:45 <m-relay> <t​hegoodlabel:matrix.org> why is this in the code please pardon my ignorance
05:21:04 <m-relay> <j​effro256:monero.social> Do 'git blame' and follow the links
05:21:36 <m-relay> <j​effro256:monero.social> Looks to be a patch to support custom minergate tx extra payloads
05:26:38 <m-relay> <j​effro256:monero.social> Were they refreshed to different points ?
07:21:48 <plowsof> home server issues, he thinks nobody answered already 
07:33:23 <m-relay> <p​lowsof:matrix.org> TheGoodLabel: some replies under your initial comment @ https://libera.monerologs.net/monero-dev/20240613#c386122 , messages arrive to matrix dot org accounts day(s) later
08:12:50 <m-relay> <h​ardhatter:monero.social> I’m not sure what the block the cli is refreshed to, but just now I tried to refresh the rpc to a 0 right after opening the wallet. 
08:12:52 <m-relay> <h​ardhatter:monero.social> From my understanding the rpc will refresh to the earliest block that hasn’t been scanned if you pass a height less than the earliest block that hasn’t been scanned.
08:12:54 <m-relay> <h​ardhatter:monero.social> Doing this refresh still results in the same outcome
08:13:50 <m-relay> <h​ardhatter:monero.social> “refresh the rpc to a height of 0”
08:14:01 <m-relay> <h​ardhatter:monero.social> *
09:23:36 <m-relay> <j​effro256:monero.social> What does get_height() on RPC return ? What does the "status" command return on the CLI?
09:26:10 <sech1> IIRC it's current blockchain height (not mined by miners yet)
09:26:17 <sech1> so the height of the latest block + 1
09:26:57 <sech1> I just checked the code - yes, it is +1
09:28:41 <sech1> and the same for "status" command
09:39:04 <m-relay> <h​ardhatter:monero.social> get_height returns 3170997
09:39:06 <m-relay> <h​ardhatter:monero.social> Cli status returns 3170997/3170997
09:41:41 <m-relay> <h​ardhatter:monero.social> Also worth mentioning that the 
09:41:42 <m-relay> <h​ardhatter:monero.social> get_balance command says the blocks_to_unlock is 0 despite the the total balance being positive and the unlocked_balance being 0
09:41:57 <m-relay> <h​ardhatter:monero.social> on the rpc
11:17:06 <m-relay> <j​effro256:monero.social> Weird ...
11:22:39 <m-relay> <h​ardhatter:monero.social> Welp I’m stuck until this gets fixed. I’ll try recompiling the rpc.
11:22:40 <m-relay> <h​ardhatter:monero.social> I wonder if this is supposed to be even possible within the rpc’s source code
11:23:26 <m-relay> <h​ardhatter:monero.social> Knowing that would help me figure out if I did something to cause this.
11:30:36 <m-relay> <h​ardhatter:monero.social> Btw this prevents me from making payments with the rpc since the rpc thinks there’s a 0 unlocked funds
12:04:35 <m-relay> <j​effro256:monero.social> Might be worth making a Github issue
12:04:48 <m-relay> <j​effro256:monero.social> I will look into it
12:36:19 <m-relay> <h​ardhatter:monero.social> It’s something on my end I think. When using the http client library I’m using I get the error but when using curl I don’t
12:36:57 <m-relay> <h​ardhatter:monero.social> The response from the rpc is still weird though
12:46:59 <m-relay> <j​effro256:monero.social> Hmmm
12:47:32 <m-relay> <j​effro256:monero.social> Could you use something like wireshark and inspect the actual difference between the requests that these clients are sending ?
12:48:11 <m-relay> <j​effro256:monero.social> There is a "strict" request field that might change the result somewhat
12:48:26 <m-relay> <j​effro256:monero.social> Also are all funds on one account within the wallet ?
12:50:59 <m-relay> <h​ardhatter:monero.social> Okay so even weirder.. curl actually does produce the problem just inconsistently. 
12:51:00 <m-relay> <h​ardhatter:monero.social> Sometimes it does the same error sometimes it doesn’t. And the txs I’m testing aren’t relayed so it wouldn’t make sense that they’d be locked
12:51:29 <m-relay> <h​ardhatter:monero.social> While with the https client library it does it every time
12:52:10 <m-relay> <h​ardhatter:monero.social> Yes
12:52:47 <m-relay> <h​ardhatter:monero.social> I’ll try
12:53:38 <m-relay> <h​ardhatter:monero.social> Is this like a bool eg (“strict”: true) ?
12:54:25 <m-relay> <h​ardhatter:monero.social> While with the http client library it does it every time
12:55:36 <m-relay> <h​ardhatter:monero.social> Also when I say sometimes it doesn’t and sometimes it doesnt. I’m sending identical requests
12:55:53 <m-relay> <h​ardhatter:monero.social> with curl
12:57:21 <m-relay> <h​ardhatter:monero.social> And the consistency of the error  independent of the time lapsed between requests
12:58:22 <m-relay> <h​ardhatter:monero.social> Also the monero node and rpc is on localhost
12:59:26 <m-relay> <h​ardhatter:monero.social> And the consistency of the error seems independent of the time lapsed between requests
13:01:00 <m-relay> <r​ucknium:monero.social> hardhatter: If you are creating multiple txs, that may be your problem. I don't know exactly how it works, but if the node has your txs but doesn't broadcast it, to the node the output is still being spent. It may be considered in the 10 block lock period, so your wallet thinks that there is zero unlocked funds.
13:06:44 <m-relay> <h​ardhatter:monero.social> That’s seems like a good explanation except the weird thing about when I was getting the error with curl was there were times where I would get the error when transferring (no relay) and then checking the balance immediately afterwards showing the the the balance was fully unlocked
13:07:36 <m-relay> <h​ardhatter:monero.social> Also using curl to get_balance
13:09:32 <m-relay> <h​ardhatter:monero.social> Also the amounts I’m transferring are much smaller than the balance but I gotta check the number of outputs I have
13:14:04 <m-relay> <r​ucknium:monero.social> If you spend 0.1 XMR of a 1 XMR output, the whole 1 XMR will be locked until 10 confirmations.
13:15:02 <m-relay> <h​ardhatter:monero.social> Rucknium: but somewhat tangentially. Is it possible to precompute a series of txs that aren’t relayed to get their tx metadata and tx key without locking their outputs?
13:16:28 <m-relay> <h​ardhatter:monero.social> I am aware of that. But I said I haven’t checked the number of outputs yet to see if that’s the explanation.
13:17:36 <m-relay> <h​ardhatter:monero.social> And the thing I mentioned about get_balance saying the funds were unlocked immediately after the transfer command said they weren’t was strange
13:39:06 <m-relay> <h​ardhatter:monero.social> Also I just checked, I have 1 unspent output. 
13:39:08 <m-relay> <h​ardhatter:monero.social> However I don’t think txs that aren’t relayed lock outputs because I just generated 15 txs in a row by transferring (no relay) 1 second apart. 
13:39:10 <m-relay> <h​ardhatter:monero.social> At random times, the rpc seems to decide that output is locked when I use curl. I could do many in a row with no problem. Walk away for 20 min and test it again and happen to get the problem on the first transfer
13:42:11 <m-relay> <r​ucknium:monero.social> Maybe your RPC wallet didn't `refresh` between the one-second tx construction. You are probably creating race conditions when you are doing this unrealistic behavior. You are creating multiple invalid txs. Every tx after the first one is invalid according to network rules.
13:42:51 <m-relay> <r​ucknium:monero.social> They are double spends of the same output
13:45:05 <m-relay> <h​ardhatter:monero.social> I just tried that again with refresh commands inbetween and it still didn’t lock the ouputs
13:47:14 <m-relay> <h​ardhatter:monero.social> But if you’re saying that unrelayed transfers still do have consequences under the hood I won’t do that in practice.
14:02:39 <m-relay> <h​ardhatter:monero.social> If the unrelayed txs, are predetermined spends of specific outputs then I get why that wouldn’t work to use in practice as a group of txs. Which would be unfortunate for me cause I wanted to use that to precompute the fees for a group of txs as well.
14:02:40 <m-relay> <h​ardhatter:monero.social> But anyway it doesn’t seem that generating these unrelayed txs is locking the outputs even though I wouldn’t be able to spend more than one of them if the spends on specific outputs determined in advance
14:08:10 <m-relay> <r​ucknium:monero.social> Start from the beginning: what are you trying to do? What's the use case? #monero-community-dev:monero.social  may be a better channel for this
14:09:37 <m-relay> <h​ardhatter:monero.social> Okay I’ll go that channel