CLI Wallet Transfer - Understanding "Change" & "Spent"


#1

Could somebody who categorically knows what Change and Spent means logistically speaking in the CLI wallet.

Testing the CLI wallet to better understand it - I sent a 5 ETN payment with lowest priority to my main wallet…

From a Show Transfer command, amongst other things I see
txid: …
Height: …
Timestamp: …
Amount: 5.00
Payment ID: 000000000…
Change: 14.90
Fee: 0.10
Destination: …

After I agreed the proposed transaction I created, a few seconds later 4 output appeared on screen…

Height … … <…> received 0.90
Height … … <…> received 4.00
Height … … <…> received 10.00
Height … … <…> spent 20.00

Checking my CLI wallet balance I see 20.00 was deducted from my balance (temporarily)… A little while later the 14.90 change was returned and the wallet balance is as expected.

X (pre tx balance) - 5.00 (intended payment) - 0.10 (fee) = Y (and the math for Y is correct after tx+fee deducted).

On a basic level the math all works out and everything is fine - no issue understanding that.

But can someone explain the logistics behind temporarily deducting the 20 ETN (on a 5.10 transaction) to later return the additional 14.90 change ?

I think many of us could learn from an informed explanation. Thanks.


#2

If I was to guess I might imagine the 15.00 was temporarily held to cover fee costs.

Then it deducts the 0.10 fee and returns the 14.90 change.

This is odd though as before I agreed the transaction (y / n), I was advised the 0.10 fee… So the fee was known before the tx was authorised.


#4

@cuddlesquid (deleted post)
Ahhhhh… I’ve been wondering why apples seemed so expensive.

Of course I know what change is in regular terms.

No offence but I did clarify Could somebody who categorically knows what Change and Spent means logistically speaking in the CLI wallet.


#5

@BegaMutex can you help , thanks


#9

@cuddlesquid No you didn’t give a logistical answer. You gave me a conceptual answer - an answer that would be appropriate to fixed amounts of money, like a $20 bill.

Your conceptual answer is not appropriate for a crypto that is divisible at the point of transaction - and it is the logistics of this that I am trying to ascertain.


#17

@Jo_Boo
To categorically know you’ll need to understand the complex monero code, and very few in in this community have a deep understanding of it’s inner workings

Here is how I interpret it:
A transaction fee is dynamic and is actually based on transaction size i kilobytes (rounded up)

A transaction is also split up into several smaller ones, because monero is trying to obfuscate transactions to make it a anonymous coin.

The size of one transaction has something called a base transaction size, but there are several other factors affecting the final size of it, like adding anonymising “RingCT” and other “random stuff”.

I do not know the exact formula, but I guess if you decide to transfer a small amount like 5 ETN, the code actually needs to put aside (Spent) 20 ETN to make sure there is enough to cover the real (&fake) transactions and fees on the network.

Rabbit Hole

https://raw.githubusercontent.com/electroneum/electroneum/master/src/wallet/wallet2.cpp

If you really want to dig down into the code and know more, I would suggest asking in the monero forums.
Word of advice: be polite, or they will bite your f head off (or most likely ignore you)


#19

Thank you for your response, although it doesn’t really clear anything up and I’m sure an explanation exists without knowing the details of the monero code.


#20

The answer is in the code, I LOL’ed hard (being a nerd) when I once found print_money in the code

void wallet2::set_spent(size_t idx, uint64_t height)
{
transfer_details &td = m_transfers[idx];
LOG_PRINT_L2("Setting SPENT at " << height << ": ki " << td.m_key_image << ", amount " << print_money(td.m_amount));
td.m_spent = true;
td.m_spent_height = height;
}


#21

Code can explain technically how, not logistically why…

The temporary over-spend (and later refund) seems a redundant hangover of the monero obfuscation. Of course I’m not an expert and may be wrong.

The above example (opening post) I have given would be akin to a 5.10 Debit Card charge where they temporarily deduct 20.00 and later refund 14.90.

It wouldn’t make sense.


#22

WHY isn’t this your TOPIC ?

I totally agree (!), but at the moment we are still using old monero-code with only 1 RingCT

If you have suggestions how to clean this us, please submit your code to github

@andrepatta


#23

That’s a rather arguementative reply… Should only blockchain coders ask questions or make observations ?

I am not criticising the above, I’m merely trying to understand why as I outlined in the opening post.

To elaborate further my thinking is if someone in (let’s say) a developing nation only had 19 ETN in wallet and wished to spend 4.50 + 0.20 fee (I don’t know what they’re buying) - will they be denied because while they have sufficient funds for cost (4.70 this example), they don’t have enough for the mysterious (20.00 OP example) over-charge / refund.


#24

You are free to make an observation too, please add it to github ! (if not, I could do it for you)
I agree with you


#25

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)