[Draft] Volume-dependent Transaction Fees

[Nagalim]

Motion RIPEMD160 hash: tbc

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=
The variable transaction fees, implemented as per motion 7283C71D2BDDC3B71E2EB7CD0693E28E3665BF66, will be replaced with variable, volume dependent transaction fees. Where shareholders would previously be voting on the flat fee, they will instead vote on a proportionality constant for the fee (labeled ‘p’). Every output to a transaction with a target address that is different from any source address will be summed (sum labeled ‘V’) and the transaction will be charged the following fee:

Fee = p * Maximum{ 0.01 NBT / KB, f(V) }

f(V) is a volume dependent function to be determined by future motions. In the event that no additional motion is passed before implementation, the following function % function will be used:

f(V) = V * 0.01 NBT

If any output has a target address that is equal to its source address, the transaction will be charged an additional p * 0.01 NBT / KB fee.

A chunking service will be added to the standard wallet software such that incoming transactions can be divided into fibbonacci chunks. When avatar mode is turned off and the chunking service is not turned off, the wallet will divide any incoming transaction from an outside account that is 10 NBT or larger into several outputs relating to the fibbonacci numbers. For example, a 100.13 NBT output would divide into outputs of size: 1, 2, 3, 5, 8, 13, 21, 34, 13.13 NBT. When sending outside of avatar mode, the wallet will seek to minimize change outputs

A reward of 10,000 NBT will be offered for the successful implementation of this fee and the wallet upgrade.
=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

[creon]

Fee = Volume / (100 * [log(Volume) + 1])

So you want to forever hard code that? I thought we still would be voting on a transaction fee, but only as a scaling factor of above curve, i.e.

fee(V) = max(0.01, p * V / (100 * [log(V) + 1]))

where p is a shareholder voted scaling factor.

[Nagalim]

I’d be down with that if it’s practical to implement. I was thinking static would be easy and sufficient, but I also was considering exactly what you are referring to. Possibly voting on both minimum and scale factor.
@creon you would know better than I what can easily be implemented and what cannot.

[creon]

Hard coding it would be easier and less complex. Every voting parameter is blockchain bloat. Its just, that if any future circumstances let shareholders decide to modify this value, then it will only be possible through a hard fork, which is much more easy now than when many people depend on it.

Compared to our current attempt, i.e. voting for the fee directly, this will lead to the same bloat as voting for a scaling factor. The logarithmic dependency is very intuitive in my opinion.

Maybe, before releasing the draft for voting, we could just make some simple simulations on the current blockchain data to get an idea of the numbers we are talking about.

[Nagalim]

Sure, sorry if I jumped the gun some. Let’s use f(v,p) = p * min( .01 , v / (100*[log(v)+1]) ) for the simulations.

[Nagalim]

Volume-dependent fees have a fundamental issue. There is no way to tell which receiving address is the change address.

One way I can see around this is by requiring the change address to be the same as the sending address. As far as I can tell this only comes at some minor loss of security, but allows things like paper wallets to avoid becoming obsolete. We inherited the separate change address from BTC, and I’m not sure it’s such a wonderful thing anyway. If you want the added security benefits of having a fresh change address, you could always pay the extra fee.

This is not something that has been done before with blockchains, as far as I can tell.

[Ben]

If you want the added security benefits of having a fresh change address, you could always pay the extra fee.

“Avatar” mode already exists in Nu and does exactly what you are talking about.

[Nagalim]

Does nubits wallet put change in the same address by default?

I know nushares wallet does this.

Awesome, basic research necessary.

The fee is only paid once either way right? So the volume-dependent thing still has a problem because you don’t want to have to pay to keep moving your big addresses around, but they need the most security.

What will happen if we charge all outputs based on their individual volumes the sender will want to send the transaction in one big lump to reduce fees. For the change address, however, they would do well to split it up into many small outputs (depending on the minimum fee) so that they won’t have much change for those outputs in the future. The effect of this is to double down on the fee by charging once for the transaction and again for generating change. This system rewards those who spend outputs of similar size as the transaction and those who use avatar mode.

The optimal size to break change up into would be § NBT, or 1 NBT for a .01 minimum. This means a transaction with thousands in change would generate thousands of new addresses, so I’m not sure if that’s an issue or not. However, such a transaction would burn 10’s of nbt for change in addition to the transaction fee, so that’s nice. It’s a weird business model though.

[Nagalim]

I have updated the draft. The implementation of the volume-dependent fee will involve an interesting new function of the wallet:

Because transactions will be charged for any change they have, large outputs will need to be divided into Fibonacci chunks. This means that if someone sends you 100 NBT (all in one output because it’s cheaper) your wallet will first accept it as is. Then, it will generate a new transaction where it divides the 100 NBT into chunks: 1, 2, 3, 5, 8, 13, 21, 34 and 13 NBT. It does this by sending those chunks to its own address and paying the 0.01 NBT fee. This way, when you go to pay for a 25 NBT cab ride with the 100 NBT address, you can use the 21 and the 5 NBT outputs such that you will only need to pay the fee for the 25 NBT cab ride and the 1 NBT change. If p=1, the total fee paid by you is 0.124 NBT (.01 NBT for the chunking, .01 NBT for the change, and .104 NBT for the volume-dependent fee) all of which gets burned.

Edit: It would actually take the 21, 3, and 1 NBT outputs and avoid having change at all. The chunking (only .01 NBT) could be seen as a fee for recieving a large output, in which case the only fee for the cab ride is the 0.104 NBT volume-dependent fee, as intended.

The consumer should not notice this much, other than paying a few extra cents here and there. The constant of proportionality will be tuned anyway, so the total quantity of fees paid will ultimately be controllable by share holders.

Simulations are not easily done for this because of the lack of Fibonacci chunking in our blockchain’s history.

[Ben]

Simulations are not easily done for this because of the lack of Fibonacci chunking in our blockchain’s history.

Could we use Bitcoin’s blockchain history to approximate cost at scale?

[Nagalim]

approximate cost

We could pretend every output was a real transaction, but we would be overcharging, vastly in some cases. If someone used a 100 NBT output (in btc or whatever crypto) to buy a coffee, that would calculate as $.25 instead of $.01 like it should.

[Ben]

After I wrote that question it dawned on me why it would be difficult. Your response confirmed it.

It’s impossible to know which part of the transaction was change and which was the actual transfer.

[Nagalim]

Yah, this motion actually intends on charging for providing change. That’s why it introduces the Fibonacci chunking, to minimize change. It’s like an ATM providing an array of bills.

Avatar mode gets charged 0.01 NBT (regardless of p) for change.

[Ben]

Avatar mode gets charged 0.01 NBT (regardless of p) for change.

Does the transactions data size still affect the price paid if fees (per kB per output)?

[Nagalim]

per kB

Yes, it multiplies the fee like it normally does. Not /output though, that’s being defined. It’s just /KB that gets multiplied. A fibinacci chunking has many outputs but only gets charged once unless it has a whole lot of outputs and exceeds 1 kB.

[Ben]

Sounds good, that keeps in place the existing rules that minimize a network DDoS via a “dust” attack.

[Nagalim]

Taking a linear approx. above block 25000, we get ~2.6 cents of profit each block. That translates into ~$13,600/year. This is at a minimum assuming block chain usage is not reduced by the implementation of the fee. This also uses p=1, does not include coinbase transactions, and the total profit is in addition to the current 0.01 NBT fee.

Here we get ~5.8 cents of profit per block, translating into $30,500/year.

If Nu exists at its current state for longer than a year, this project should be worth more than $10,000 to us. To put this in perspective, the current flat tx fee gives 0.01 NBT/tx; with 50 tx/day we’re getting something like $150/year. That means this proposal would give about a 10,000% increase to the effectiveness of our fees as a revenue source.

If anyone wants my code or for me to run a different simulation just let me know. It runs through the whole blockchain, so it takes many hours for a single run all the way through.

[dysconnect]

Are you sure it’s Min( , )? That would mean the fee would never exceed p * 0.01

[Nagalim]

Are you sure it’s Min( , )? That would mean the fee would never exceed p * 0.01

Right, it should be max, I changed it. I caught that when I wrote the code to analyze the blockchain, I just forgot to update it, thanks for the catch.

The minimum and maximum profit graphs have to do with whether we assume the bigger or the smaller address is the change address.

Also, this doesn’t include the demurrage-like profit from the wallet chunking, as that can be avoided using avatar mode.

edit: these graphs are difficult because of the way the coins propagated out of the initial coinbase transactions. I neglected the fact that coinbase transactions before block 25,000 had a transaction hash, so those are counted, but even if they weren’t the next few transactions as the coins propagated out from the initial distribution would, and they are not representative of reality. That said, my predictions used the slope after block 25,000 and so are perfectly valid:

Profit from this model = 13.6 - 30.5 thousand nubits per year assuming usage does not fundamentally change.

[woodstockmerkle]

The challenge may be in end-user perception – consumers rarely see transaction fees, even if they do end up paying for it in some way.

Just to get a sense as to the fees, I ran some data on the model with p=1, p=0.1, and p=0.05 to get a sense as to how this would feel to users.

My understanding is that credit card transaction fees are typically like 1.5% or higher, with Square charging 2.75%.

In either of the runs model, Nu would be a fraction of that.

To get the transaction volume, it makes sense to have low transaction fees. However I think it is only fair for the end users to get a sense as to where Nu will set these rates. I think it should be some amount less than p=1; closer to p=0.1.

Perhaps we can encourage merchants to standardize on a ‘1%’ discount on payments settled with Nu. Both the merchant and consumer would come out ahead.