Topic: Fee policy proposal: charge for outputs, not inputs (Read 1141 times)

Exactly. Block should consist of: header,Merkle tree&coinbase transaction. All the remaining transactions should be transferred before the block. This "array of transactions" appended to the block is just an artefact of the awkward implementation and from the information-theoretic sense serves no purpose.

Well, not exactly. 200 is a wrong arbitrary number, 64 is better. And not multiplied by the number of transactions but by the size of the merkle tree of transactions.

Finally it is possible that the Merkle tree is just like a Christmas tree: a decoration. Plain old array of transaction hashes could be sufficient.

That is one benefit, though my understanding is that there is some benefit to reducing the UTXO set even for nodes that keep the full history, because the UTXO set must be kept quickly accessible for transaction verification.

The other benefit is more understandable fees for users.  How many times have we seen users confused about why their transaction requires a high fee?  Usability is important for adoption.

What for ? To compact them ?
Still sounds like a good thing to me

I think the main premise supporting an output-based fee is the idea (which I believe is reasonably likely) that eventually we will be moving to clients that only maintain the UTXO set and recent blocks, and only those choosing to be "historians" carry the entire block chain.  If such a scenario were to exist, then space in the UTXO set would be a more costly resource than transaction size, since transactions would be discarded by all but the historians.

Whether or not such a scenario will ever happen is debatable, but this would make more sense in the future if the scenario did happen.

I should clarify that the point is not that inputs are free, but rather that inputs are paid for by the outputs they redeem.  My description was focused on the general principle, but I believe it can be implemented in a way that addresses many of the concerns raised.

Here is a strawman concrete implementation proposal:

Currently the reference client makes fee decisions based on the size of a transaction, which is simply the number of bytes in the transaction.  All of that logic remains the same, except that the size of a transaction is redefined as follows:

• the number of bytes in all outputs (serialized CTxOut objects), plus
• 200 bytes per output (intended to pay for the input that will eventually redeem each output), plus
• the number of excess bytes beyond the first 200 bytes in all inputs (serialized CTxIn objects).

The value of 200 bytes is somewhat arbitrary.  It is more than enough to redeem a payment to address with an uncompressed key (180 bytes if I calculated correctly).  It could be set lower, e.g. just enough to redeem a payment to address with a compressed key (148 bytes), or higher, e.g. enough to cover some interesting P2SH use cases like 2-of-3 multisig.

These rules could be rolled out now, but there is the problem that if the block size limit is reached, it will be more profitable for miners to use the original definition of transaction size instead of the adjusted definition.  That problem could be fixed by redefining the block size limit so that instead of being based on the number of bytes in the block, it is based on the total size of transactions in the block, where transaction size is defined as above.  Of course that is a hard fork.

Some responses:


As described above, all inputs are fully paid for.  All that changes is who pays.


No change is proposed to the behavior of using rounded transaction sizes for fee computations.  The alternate definition of transaction size would still be rounded.


As described above, all inputs are fully paid for.  Typical inputs are paid for by the output they redeem, but oversized inputs require an extra charge.


Inputs cannot simply be invented -- they must redeem an existing output.  Yes, you can create a huge transaction that redeems every output you have available to you, but then you have used up all your unspent outputs, and to do it again you would have to create more outputs.  Creating those outputs requires a fee which covers those outputs plus the redeeming inputs.  Every byte is fully paid for.

Maybe one could buy wallets full of dust from gamblers to obtain a large supply of dust outs?

-MarkM-

I really haven't given this topic that much thought, so I don't really have an opinion.
The idea of giving an incentive to compact outputs is sounds pretty good to me though, but clearly, it should not be the only thing to consider.

I don't think your example really adds up, correct me if I'm wrong but in order to be able to "repeat" like you say, you need to be able to re-create a lot of outs, and if the fee increases by the number of outs, you'll end up paying a lot in fees. So unless you have access to an unlimited number of unspent outs the process you describe simply does not work.

Thoughts ?

Not when it's being done to game the system. You could create a tx close to a megabyte with a fee of only 0.005 and force it to be relayed, then create a new tx the same way, and repeat.

Transaction fees MUST be priced per-byte, with an allowance made for aged coins.

Well, isn't compacting the amount of unspent outputs a good thing ?

You forget that inputs have scripts of different lengths.

For example, in case with P2SH output script is short, but input script is long.

Change you're proposing will subsidize multi-signature P2SH transactions.

What if I want to use 10 signatures for one input? Who cares, inputs are free!

there are obviously downsides to this per deepceleron's post, but i do like the idea that generating excessive dust would be more expensive.

The possibility of evaluating transaction fees based on input/output quantity crossed my mind earlier this week with my evaluation of fee structure that led me to one change, removing all free transactions. Upon reflection, the current system is adequate and perfectly charges for the resources used. It is possible to make very large inputs, so inputs must also be taxed on a basis of size, not on a per-input basis, and especially must not be free. In fact, it is the inputs that take CPU work, it's the digital signatures in them that must be verified. In addition, sorting out and programming what part of any possible script is the "input" or "output" that should be evaluated is quite a task.

Secondly, while generally only the number of outputs are under a user's control when creating a transaction, it is also within a user's control to not fill up their wallet with satoshis.

If you want to reward efficient transactions, one could consider a .0000005 BTC per byte fee. However this makes nearly every transaction have a different minimum fee, making it nearly impossible to predict what amount to send to empty a wallet, to estimate or educate on the standard fee, and would punish the user who's wallet merely selects one extra input or sends change. This optimization I also discount.

Many services would be impacted by any fee change - consider dozens of pools, exchanges, merchant sites, etc that would have to re-code their sending logic and algorithms after a fee change breaks their site. There must be a net benefit to the entire network.

Transactions with lots of inputs are actually good to have, as these lead to better pruning.

It's nice that you're putting some thought and analysis but unfortunately the choice of how to charge for the fee must be restricted to the fee per kilobyte, since it is the free space within the block that is the limit resource which fees attempt to ration. Not charging for inputs only creates an incentive to make the biggest possible transaction with as many inputs as possible and few outputs.

Summary:

Fees are typically per KB of transaction size.  The size of a transaction is mostly determined by its inputs and outputs.  I propose that fees should be based only on the outputs.

The intuition is that every output is eventually intended to be redeemed by an input.  It serves no purpose to penalize those inputs.  Rather, the transaction that created the output should include a fee sufficient to pay for both the output and the input that we know will eventually be needed to redeem it.

Advantages:

• Currently, users are sometimes prompted to include a large fee because their transaction combines many inputs, resulting in confusion.  Charging only for outputs would eliminate that confusion.  Large fees will still be required for transactions with many outputs, but in that case the reason for the fee is clear.
• Currently, outputs below a certain value can be uneconomical to redeem, resulting in a permanently inflated set of unspent outputs.  Charging only for outputs would allow small outputs to be redeemed.

Difficulties:

• Fee policies are supposedly in the hands of miners, but that is not quite true in the presence of a block size limit.  Assuming there are enough fee-paying transactions to fill the block, a profit maximizing miner must charge fees based on the size of the entire transaction.  If the block size limit is changed in the future, it is worth considering making the limit apply only to outputs.  (For safety, a separate limit could apply to inputs, set high enough that it is unlikely to be reached in practice.)
• Ideally fees should be based on the total size of outputs and their redeeming inputs, but in general it is not possible to know the size of those inputs ahead of time.  P2SH outputs can require arbitrary scripts to redeem.  Even an ordinary output that pays an address may require a compressed or uncompressed public key to redeem.  One approach is to charge all outputs for a fixed additional number of bytes, and charge inputs if they exceed that size.  Another is to ignore inputs entirely, which may make sense if they are typically pruned anyway.  In practice, the policy may be determined by the block size limit.  If the limit applies only to outputs, the profit maximizing behavior will be to charge per KB of outputs and ignore inputs.

This is just a sketch of an idea.  It could be turned into a concrete proposal if people think it has merit.  Perhaps it should be considered at the time that the block size limit is addressed, though it could also be attempted as a default fee policy before that.