It’s a UTxO standard. “Fee” is just a sugar name for difference between sum inputs and sum outputs, and all of it becomes a reward (burned in this case). In this case fee is the calculated required minimum, but anyone is free to “donate” more fees at any time
This looks weird tho, agree. Any change is usually set manually as outputs. I will need to look into CLI api more thoroughly
I do not think that there is an issue. It seems to me work as expected as it processes each of the inputs. But, I am going to check it.
UPDATE: Yep that part is OK, as it processes all inputs. Yep, (output_value - input_value - estimated_fee) seems misleading, but it’s not. Check the for loop which starts at line 184
What I can suspect is that if the user specifies the change address then it will add all the fees into the change address (probably IOHK’s burn address). I will have a look at the code in more detail as this change address vs. automatically generated multiple outputs (if there is no any change address is specified) can be a bit confusing for the users.
Also, it can lead to hijack the fee system if the users can specify their own change address, means all transaction fees can land on their specified address. But, if the change address currently derivated from the IOHK’s fee address, then that 's fine as it will be burnt. So, I need to dig a bit more into the code to fully understand, but currently do not have time to this.
So, it does not seem to be a BUG at all, but a normal behaviour (feature), it wil lbe a bug if the users can specify their own change address, which does not seem to me the case (but, as I mentioned, I need to dig a bit more to fully understand this)
But there’s no such thing as a “burn address”, tho All fees for now just go nowhere. Which is exactly why they are “burned”. They just disappear.
No it shouldn’t be a bug, since there’s no such thing as “change” in UTxO, strictly speaking. All tx outputs have the same “rights” and are indistinguishable from the protocol POV. So user may specify any number of inputs and any number of outputs, and any of those outputs may be the “change” logically, or even multiple of them. “Change” is just a sugar word for an output that sends coins back to the same wallet (not necessarily the same address), that’s it )
Thx, it makes sense. I have not checked that part of the code, therefore I just assumed that there is some change address, as it was applied in the command that @HisMajesty’s applied, but have not checked the transaction to be sure.
Yep, I know, I just thought that specified “change address” by @HisMajesty will be the output where the change goes (as he specified an output and a change address (means second output for change).
But, are you sure there is no some specified/generated address to burn? I would say there must be, as money cannot disappear from the system at all, what can I expect, that they have some automatically generated address (derivated from some wallet address) and they send the transaction fees there.
But, I have not checked this part of the protocol, but I will when I have some free time.
There is no address, and coins DO disappear. This is the definition of “burning”. Strictly speaking, total supply of ADA coins is quite liquid in time, with new coins being added into supply as someone redeems their ICO certificate and as fees are disappearing.
From protocol POV there’s nothing wrong in disappearing coins, tho, think of it that way: a transaction is just an event that spends some UTxO and creates new UTxO. There’s absolutely nowhere in the protocol a validation that sum inputs and sum outputs are required to be equal. Therefore if your transaction spends two UTxO of 50 coins each and creates a single new UTxO of 90 coins - 10 coins are just no more )