Good morning Zac, > Hi ZmnSCPxj, > > To me it seems that more space can be saved. > > The data-“transaction” need not specify any output. The network could > subtract the fee amount of the transaction directly from the specified UTXO.
That is not how UTXO systems like Bitcoin work. Either you consume the entire UTXO (take away the "U" from the "UTXO") completely and in full, or you do not touch the UTXO (and cannot get fees from it). > A fee also need not to be specified. Fees are never explicit in Bitcoin; it is always the difference between total input amount minus the total output amount. > It can be calculated in advance both by the network and the transaction > sender based on the size of the data. It is already implicitly calculated by the difference between the total input amount minus the total output amount. You seem to misunderstand as well. Fee rate is computed from the fee (computed from total input minus total output) divided by the transaction weight. Nodes do not compute fees from feerate and weight. > The calculation of the fee should be such that it only marginally cheaper to > use this new construct over using one or more transactions. For instance, > sending 81 bytes should cost as much as two OP_RETURN transactions (minus > some marginal discount to incentivize the use of this more efficient way to > store data). Do you want to change weight calculations? *reducing* weight calculations is a hardfork, increasing it is a softfork. > If the balance of the selected UTXO is insufficient to pay for the data then > the transaction will be invalid. > > I can’t judge whether this particular approach would require a hardfork, > sadly. See above note, if you want to somehow reduce the weight of the data so as to reduce the cost of data relative to `OP_RETURN`, that is a hardfork. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
