<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

<t​hegoodlabel:matrix.org> tx_extra.h "struct tx_extra_mysterious_minergate"

<t​hegoodlabel:matrix.org> ????

<t​hegoodlabel:matrix.org> why is this in the code please pardon my ignorance

<j​effro256:monero.social> Do 'git blame' and follow the links

<j​effro256:monero.social> Looks to be a patch to support custom minergate tx extra payloads

<j​effro256:monero.social> Were they refreshed to different points ?

home server issues, he thinks nobody answered already

<p​lowsof:matrix.org> TheGoodLabel: some replies under your initial comment @ libera.monerologs.net/monero-dev/20240613#c386122 , messages arrive to matrix dot org accounts day(s) later

<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.

<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.

<h​ardhatter:monero.social> Doing this refresh still results in the same outcome

<h​ardhatter:monero.social> “refresh the rpc to a height of 0”

<h​ardhatter:monero.social> *

<j​effro256:monero.social> What does get_height() on RPC return ? What does the "status" command return on the CLI?

IIRC it's current blockchain height (not mined by miners yet)

so the height of the latest block + 1

I just checked the code - yes, it is +1

and the same for "status" command

<h​ardhatter:monero.social> get_height returns 3170997

<h​ardhatter:monero.social> Cli status returns 3170997/3170997

<h​ardhatter:monero.social> Also worth mentioning that the

<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

<h​ardhatter:monero.social> on the rpc

<j​effro256:monero.social> Weird ...

<h​ardhatter:monero.social> Welp I’m stuck until this gets fixed. I’ll try recompiling the rpc.

<h​ardhatter:monero.social> I wonder if this is supposed to be even possible within the rpc’s source code

<h​ardhatter:monero.social> Knowing that would help me figure out if I did something to cause this.

<h​ardhatter:monero.social> Btw this prevents me from making payments with the rpc since the rpc thinks there’s a 0 unlocked funds

<j​effro256:monero.social> Might be worth making a Github issue

<j​effro256:monero.social> I will look into it

<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

<h​ardhatter:monero.social> The response from the rpc is still weird though

<j​effro256:monero.social> Hmmm

<j​effro256:monero.social> Could you use something like wireshark and inspect the actual difference between the requests that these clients are sending ?

<j​effro256:monero.social> There is a "strict" request field that might change the result somewhat

<j​effro256:monero.social> Also are all funds on one account within the wallet ?

<h​ardhatter:monero.social> Okay so even weirder.. curl actually does produce the problem just inconsistently.

<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

<h​ardhatter:monero.social> While with the https client library it does it every time

<h​ardhatter:monero.social> Yes

<h​ardhatter:monero.social> I’ll try

<h​ardhatter:monero.social> Is this like a bool eg (“strict”: true) ?

<h​ardhatter:monero.social> While with the http client library it does it every time

<h​ardhatter:monero.social> Also when I say sometimes it doesn’t and sometimes it doesnt. I’m sending identical requests

<h​ardhatter:monero.social> with curl

<h​ardhatter:monero.social> And the consistency of the error independent of the time lapsed between requests

<h​ardhatter:monero.social> Also the monero node and rpc is on localhost

<h​ardhatter:monero.social> And the consistency of the error seems independent of the time lapsed between requests

<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.

<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

<h​ardhatter:monero.social> Also using curl to get_balance

<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

<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.

<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?

<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.

<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

<h​ardhatter:monero.social> Also I just checked, I have 1 unspent output.

<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.

<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

<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.

<r​ucknium:monero.social> They are double spends of the same output

<h​ardhatter:monero.social> I just tried that again with refresh commands inbetween and it still didn’t lock the ouputs

<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.

<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.

<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

<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

<h​ardhatter:monero.social> Okay I’ll go that channel