At first look, this will probably be true. As I am finding with my fee analysis, the difference is approx. an order of magnitude (10x). However, though certain things are hard to quantify, I will attempt to argue that volume-based fees will be different than NSR chunking.
The crux of the argument is that volume-based chunking will be done so as to reduce the number of inputs to Txns. Inputs are by far the more space-intensive part, outweighing the space outputs take by 5x (~200KB/input, ~40KB/output). A chunking event takes 1 input to many outputs, so is not an event that takes a huge amount of space on the blockchain. It is the spending of the chunks that we need to observe more carefully.
When a chunked NSR address decides to send NSR to market, those Txns typically look like 100 inputs > 1 output. These Txns are really huge from the blockchain perspective, and we charge an event like that something like 20 NSR for the privileged. However, NBT chunking is done specifically with the spend event in mind: breaking big chunks down into manageable smaller chunks so that when spending we can get as close to exact-change as we can. We should have an incentive to keep people from chunking too often or into too many chunks.
Which brings me to my biggest question, point, whatever you want to call it. How do we deal with a standard transaction that is over 1KB in the volume-based fee model? This is my thought process:
- Change the second to last line of the motion to read: “If any output has a target address that is equal to its source address, the transaction will be charged an additional 0.01 NBT/KB fee.”
- Do not charge anything additional if a Tx is paying volume-based fees for all outputs and it exceeds 1KB.
- People can get around the volume-based fee by signing the same Txn as someone else so that the network is tricked into seeing it as a chunking event. For example:
A wants to send 10 NBT to B. A and B both sign a transaction that sends 10 NBT from A and 1 NBT from B > 1 NBT to A and 10 NBT to B. They pay only the 0.01 NBT/KB fee.
However, two people who do not trust each other will not do this. It is something akin to giving someone an address with money in it: it’s not safe if 2 people have access to the private key.
An easy way to fix this would be to add a line to the motion about how a chunking output cannot have more volume than the chunking input. In that case, the above event would not register B as part of the chunking process and would charge the volume-based fee on the 10 NBT in addition to the 0.01 NBT/KB fee for the change to A. With implementation, you would need to sum all the output volumes and all the input volumes for a particular address and if the out>in, charge the volume-based fee; otherwise, charge the chunking fee.
Then vote on a p (volume-based profit driven fee) and a q (chunking/change fee, cost/KB).