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.
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.
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.
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.
“Avatar” mode already exists in Nu and does exactly what you are talking about.
1 Like
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.
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.
3 Likes
Could we use Bitcoin’s blockchain history to approximate cost at scale?
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.
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.
1 Like
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.
Does the transactions data size still affect the price paid if fees (per kB per output)?
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