[Draft] Volume-dependent Transaction Fees

[dysconnect]

There can be mixing services, wallet migration, and some possible blockchain mechanisms that bounce money back and forth (such as a satoshidice-type operations). It is unwise to penalize those transactions.

Banks offer fixed inter-bank transfer fees and free intra-bank transfers in many cases, and we don’t want to look more expensive than a bank.

I guess it is very important in discriminating different use cases, possibly using a good overall mechanism that is simple enough for the user. Again we can consider how park rates could help mitigating the perceived drawbacks of this transaction fee for users.

If we combine some ideas with demurrage/wallet fees, perhaps it is reasonable to charge a transaction fee that scales with the average coinage in a wallet. Say we let p to be proportional to the average coinage and capped at 0.1.

Or we can do it backwards where the transaction fee is reduced for higher coinage. We can even offer a choice of “deferred transfers” that is just parking in disguise - the NBT is sent to a parking address and then “returned” to the intended destination, and the parking interest would incidentally offset the fee (which prompts me a question: does parking circumvent this fee?)

[Nagalim]

Great questions, love the discussion.
Yah, we can really do this however we want. We can exclude certain addresses, parking or burns or coinbase tx, we can exclude tx within an account and only charge the .01 nbt exclusion fee to avoid dust txns.
I like the coinage concept. I think going up for coinage rather than volume is a good idea. If we use log(coinage)=log(volume)+log(time) we can just add the volume part and the time part to get the total fee. The time part can be the number of blocks since moved and we can normalize it with q. The voters could then vote separately on the volume and the time part of the fee. We would have to impose the block chain cutoff as you explained because people will end up with bits that cost more to move than the balance of the address.
If the time part is negative, we would end up subsidizing hording, which is super similar to parking, perhaps even more elegant than parking. I think it’s very interesting to consider.

[Nagalim]

I have attempted to make the motion as general as possible to allow shareholders room to implement a function as they see fit. Good choices seem to be:

@woodstockmerkle’s charts:
f(V) = V / (100 * [log(V) + 1])

Layered:
f(V) = {0.01 NBT for V < 10 NBT, 0.1 NBT for V < 500 NBT, 5 NBT for V >= 500 NBT}

If no additional function motion is voted in, it will default to:
f(V) = V * 0.01 NBT

Is 10,000 NBT appropriate payment for this implementation?

Edit: I added a paragraph about the chunking software. I hope I didn’t go too technical for it to appeal to shareholders, but as far as I understand a large portion of the community supports a volume-dependent fee. I’m hoping we can settle on something and pass it, despite the developers not having time currently. If a motion is needed to secure priority, we can do that, but I think just offering the standing reward should be enough to get the NuTeam on it eventually.

Also, note that the standard micro Txn gets double charged for having two different types of outputs (the send Txn and the change). An attacker ends up paying p * 0.02 NBT for a simple Txn. A microTxn sendmany rpc command when done in avatar mode (like our pools) would end up paying 0.01 NBT / smallOutput + 0.01 NBT / KB scaled by p.

[Nagalim]

Would it be preferable for me to simplify the motion to just say “Shareholders will pay 10,000 NBT for protocol and wallet enhancements necessary to securely implement a volume dependent fee. The volume dependence will be 1% unless specified further in another motion.” or would the devs prefer I spell it out?

[tomjoad]

Would it be preferable for me to simplify the motion to just say “Shareholders will pay 10,000 NBT for protocol and wallet enhancements necessary to securely implement a volume dependent fee. The volume dependence will be 1% unless specified further in another motion.” or would the devs prefer I spell it out?

I would prefer seeing the motion split into two parts - one to declare volume-dependent transaction fees as a priority for development, and then a second to negotiate compensation with the developers. I don’t see how you came up with 10,000 NBT and that number could be very inaccurate.

I hope I didn’t go too technical for it to appeal to shareholders, but as far as I understand a large portion of the community supports a volume-dependent fee.

You might consider adding “exhibits” to your motion, such as “Exhibit A - Sample of volume-dependent transaction fees as proposed by woodstockmerkle”, that are a link to an image like this one. This will help shareholders understand what is being proposed without having to interpret math equations.

[Nagalim]

You may consider adding “exhibits” to your motion

Do you mean in the hash itself? I’ve never seen anyone use an image in a hash. Or do you just mean reference the images outside of the hash in the OP?

a second to negotiate compensation with the developers

Can you explain how I would go about writing a motion to negotiate compensation? Are you just proposing that I pass the first and let the NuTeam pass the second? I can do that, no problem.

priority for development

I’m confused how to refer to development priority. Nubot and marketing have roadmaps, but NuDev doesn’t really have an explicit roadmap does it?

[tomjoad]

Do you mean in the hash itself? I’ve never seen anyone use an image in a hash. Or do you just mean reference the images?

The text of a link to the image (like “https://discuss.nubits.com/uploads/default/original/1X/a56aef3b7f40419bc811f52f69b1ddd28265bd03.PNG”) could be added to the motion text itself and then hashed as usual afterwards. I think having that sample table of transaction fees makes your case much more compelling to ordinary shareholders versus only providing a formula.

Can you explain how I would go about writing a motion to negotiate compensation? Are you just proposing that I pass the first and let the NuTeam pass the second? I can do that, no problem.

I think the first motion will pass much easier without compensation attached, as we are only declaring it to be a development priority. As far as the second motion goes, you could take two approaches. You could either put up a draft motion regarding compensation with no estimate, and instead ask for public comment from a developer, or else you could privately PM sigmike, Giannis or Jordan to figure out a rough estimate of cost before proposing it publicly.

I’m confused how to refer to development priority. Nubot and marketing have roadmaps, but NuDev doesn’t really have an explicit roadmap does it?

That’s a good question. I think an absolute statement like “Volume-dependent transaction fees should be the Nu development team’s highest priority” would make clear that it should be prioritized above all else, but I’m not sure how you would slate it in between other priorities without a concrete roadmap. Others might have to answer that one.

[Nagalim]

highest priority

That’s intense, I’m not sure I want to go that far. I definitely think it’s important, can I just say “Volume-dependent transaction fees should a high priority for the Nu Development team”?

[mhps]

Shareholders will pay 10,000 NBT for protocol and wallet enhancements necessary to securely implement a volume dependent fee.

How much extra revenue Volume-dependent fee will bring to Nu at current rate? How long will it take to break even with $10k ?

[Nagalim]

Taking a linear approx. above block 250000, 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.

So we should be able to make between 10 and 30 kNBT/year without even weighing down too heavily on the network (p=1). So I would expect we could break even on $10k within a year using relatively conservative parameters.

[mhps]

Thanks for reminding. By default f(V), p=1 basically means charging a 1% fee, right?

[Nagalim]

So, it depends on how we end up doing things. The estimations I made were months ago and were based on the log fee (woodstock’s chart). The 1% default fee would only be if the shareholders fail to converge on a volume-based function. I’m currently struggling to write this motion in an acceptable manner to shareholders and devs alike, so it’s still somewhat in flux.

In all cases, p is a multiplier. It is simultaneously a multiplier for the Size based fee as well as the volume based fee. Therefore, any gains at p=2 are always exactly double that made at p=1 assuming the userbase is unnaffected.

[Nagalim]

Motion RIPEMD160 hash: tbc

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=
Volume dependent transaction fees, being a clear and long term source of profit for the network, are a high development priority.
=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

[Raythma]

Sorry for buzzing an old topic but the Coinage dependant fees sounds so great!

It may be the solution to the situation when 99% of transactions are off the chain, Coinage dependant Fee will reward Shareholders reasonably once the money moves through the chain no matter how long we waited, no?

But if the future of Nubits is mostly off the chain and most of the users never touch the client, would either parking Or negative Coinage fee Be able to decrease the supply at all? Or would it benefit the off chain services more than helping Nu?

[Nagalim]

Coinage dependent will make it so that we can make it cost money to hold your bits for too long. However, a somewhat unfortunate side effect is that the money is not paid until a txn happens. So shareholders will naively lower the time component in an attempt to get people to hold nbt, and it will actually have the opposite effect, causing long time hoarders to finally move their coins who have been waiting a long time for shareholders to lower the time component.

There are a lot of things to talk about here. I’m very happy to keep spit balling.

[Raythma]

Quick answer:
The Code could use the time factor (not of the last block) but instead in the block which the output was created in, this will make it just like parking except that user would have the ability to dynamicly choose their unpark date, which means the discouraging fear of not having liquidity when they really need it will be eliminated.

May be the mean of values of q through the blocks hiegher than the output block could be useful.
But this is a quick thought, I will investigate it later.

[backpacker]

I didn’t realise this coinage dependent fee idea is such an old idea, how come we didn’t make it real, there seemed to be good support for it.

[Sentinelrv]

B&C development became a higher priority.

[creon]

Also seemed to have missed the last part of this thread. Very good calculations in here. Interesting how all this was so deep into construction but never came to realization, although it would have meant real money for shareholders.

@dysconnect proposed exactly what is proposed right now and even asked the right question in the end:

Or we can do it backwards where the transaction fee is reduced for higher coinage. We can even offer a choice of “deferred transfers” that is just parking in disguise - the NBT is sent to a parking address and then “returned” to the intended destination, and the parking interest would incidentally offset the fee (which prompts me a question: does parking circumvent this fee?)

(which is the case). A cap on the fee would of course also be possible, and also a logarithmic fee curve, however, aside from even more degrees of freedom that somehow have to be determined by shareholders, you also lose one very nice property: linearity.

If you just scale the fee linearly with coin age, two transactions at time T1 and T2 with the same outputs will cost the same (+ regular transaction fee) like the same transaction at time T2, in other words, you don’t need to worry about output selection. A logarithmic curve doesn’t offer this ( log(a+b) != log(a) + log(b) ), and we would need to provide users with a routine that calculates the outputs in a cost minimizing way, which is NP complete but could be approximated with dynamic programming (backpacking problem). But that will be effort.

So TLDR: I think a linear coinage dependency is better in terms of simplicity for both the customers and the shareholders.

[mhps]

Interesting how all this was so deep into construction but never came to realization, although it would have meant real money for shareholders.

Let’s not waste the opportunity this crisis brings and get it implemented.