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.
Sounds good, that keeps in place the existing rules that minimize a network DDoS via a “dust” attack.
1 Like
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.
1 Like
Are you sure it’s Min( , )? That would mean the fee would never exceed p * 0.01
1 Like
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.
1 Like
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.
4 Likes
Very cool. I noticed you are doing:
Max( 0.01 , pfunction)
Rather than:
pMax( 0.1 , function)
Which do you think is a better formula?
Also, end users often see a % fee when transferring fiat.
Without anything other than a hunch, a low-end transaction fee of $0.01 seems sensible and explainable. I can’t see cases of charging people $0.10 for a transaction fee for a cup of coffee being well-received, nor do I think explaining “fractions of a penny” to the mass market is an easy effort.
As such, I think using ‘p’ to scale the log function portion has merit. I may have read the formula wrong, but there may be some upside.
Nu for sure can have many uses – currency transfer, store of wealth, and transaction settlement.
The way I see it is that consumer adoption for “day to day” activities is the larger barrier for global adoption. Merchants have shown it to be relatively straightforward to integrate blockchain-like at the POS; it’s the consumers who are not showing up with crypto in-hand.
I see 4 use cases for Nu, probably 3 of which we want:
1- day-to-day transactions (consumer goods and services, including the cup of coffee analogy)
2- larger transactions – mostly business, but some consumer: buying a vacation, a car, a house, a company, paying salaries **
3- microtransactions – buying digital property (in-game purchases, music)
4- dust / spam transactions
Transaction sizes by consumers for credit cards and debit cards are approximately $75 and $40, based on data from 2012, so I’d put a line between ‘day-to-day’ and ‘large-scale’ somewhere in that range.
With the p=0.1 model, the transaction fee increases beyond $0.01 somewhere in that ‘average transaction’ range, at probably somewhere around $50 or so. From a consumer standpoint I think this is easy to understand: your average day-to-day transactions are essentially flat rate at or near $0.01, and anything beyond that will have additional fee.
Large-scale transactions would likely be viewed thru the lens of percentage-of-transaction fee, and benefit from “volume discounts”.
Or, in other words: consumers are probably looking at the $ value of the transaction fee (like tax on a dinner), whereas businesses and large-scale transactors looking at the percent.
Microtransactions may be something to ignore / avoid for the time being. With a 1-minute block-time, at-scale, Nu will already have to store and manage 10x the design volume of Bitcoin, which would easily push the project into yet another plane of uncharted territory.
And of course dust and spam transactions have generally been controlled with the $0.01 threshold.
** footnote: product idea: some sort of mixing / splitting service would probably be of benefit (if not required) if Nu is used to pay salaries.
3 Likes
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?)
3 Likes
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.
1 Like
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.
2 Likes
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.
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.
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?
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’m confused how to refer to development priority. Nubot and marketing have roadmaps, but NuDev doesn’t really have an explicit roadmap does it?
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.
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.
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.
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”?
How much extra revenue Volume-dependent fee will bring to Nu at current rate? How long will it take to break even with $10k ?
1 Like
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.
Thanks for reminding. By default f(V), p=1 basically means charging a 1% fee, right?
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.