So you’re saying that for now it might be best to charge a higher transaction fee, since the majority of people are currently using NuBits to transfer larger sums of money. Therefore, they wouldn’t even notice the $0.10 cent fee in comparison to the amount of money they’re putting into their transactions?
If that is true, it would buy us some time to develop other services or ways of earning profit for the network. As our liquidity operations become sustained more and more through these other income sources, we could continuously lower the transaction fee until the point where we’re competitive with other cryptos for microtransactions. Is this what you have in mind @tomjoad?
Its more 20 cent we are talking about than 10 cent. This is already quite a sum and would bite me if I see it on the bill of my $1.10 coffee order. On the other hand, the current design won’t ever allow such microtransactions with Nu, so maybe we also should try to target other groups like @Sentinelrv suggests, i.e. people who want to store value in a decentralized way with a stable value and only to transfer it in “exceptional” cases. A bit like a savings account.
For those people 20 cent per transaction are surely fine. The problem however is, that I made my calculations with the current transaction volume. What effect would a 20x tx fee have on this? And if sending NBT around is our revenue, how do we encourage that? The daytrader who keeps all NBT on the exchange will never pay this fee.
More accurate data is probably required, which I am not able to produce right now. How long will it probably take until we have the tx fee as voting parameter? Since this involves a hard fork, I assume it needs to wait for the other protocol changes to be implemented as well…
I wasn’t suggesting anything. I was only trying to interpret what @tomjoad was saying. I believe he means our current user base is using NuBits to transfer larger sums and that these people wouldn’t mind the larger transaction fee. They would only mind the larger fee if they were trying to transfer smaller sums of money, purchase a cup of coffee, or perform microtransactions.
I was trying to say that targeting people that transfer larger sums with a higher transaction fee would tide us over for a while, but it should only be a temporary rise in fee, not a permanent one. We should develop services and other ways of earning income for the network, which we could then use to pay liquidity costs. With the money to pay for liquidity coming from other sources of income, we could then gradually lower the transaction fee to the point where we’re once again targeting people who transfer smaller sums of money.
In order to continually lower the transaction fee back to normal, we would need to find enough alternate sources of income to completely cover our liquidity costs. The higher fee would not be needed anymore at this point.
Why not percentage fees, I really don’t understand.
In my opinion the .01 NBT is fine for a minimum fee to prevent blockchain spam. For the staking system, however, we should be voting on percentages not flat fees.
A fixed relative rate will discourage large transactions just as a fixed absolute rate discourages small transactions. I don’t see how the rate table shown by @Raythma, which is a similar approach like in parking, can be applied here. If Nu charges 5% for 100k but only 2.5% for 50k, well, then I just send two times 50k. Not sure why anyone would pay the larger fee if you can just split your transaction.
The current approach isn’t bad in my opinion. Note that the transaction fee we are voting on is not the fee someone has to pay for each transaction, but is a scaling factor of the size of the transaction. If you are sending large sums then it is very likely that you will need many UTXO’s for this transaction and therefore you will also pay a larger fee, even right now.
My question is more what a good value what look like. I think we kind of agree here that 0.01 NBT is too small. The very rough calculation showed that 0.20 NBT could be sufficient, but that’s a lot. So what is the best trade-off?
I agree he gave a bad example. What if it’s a smaller % for a bigger volume? Like 1% for 1 NBT, .5% for 10 NBT, .25% for 100 NBT, .125% for 1000NBT, and so on. .01 NBT for any transactions smaller than 1 NBT.
Honestly, I don’t think this needs to be variable, I think we just need to pick a good curve. The equation for this example, by the way, is:
Fee = 1% / [log(Volume)+1]
It just depends on user behavior. If the user is continually depositing and withdrawing NBT from exchanges the transaction fees are relevant. If they leave NBT on the exchange then yes it’s probably not as relevant. Although, if a trader is doing this behavior then I assume USD would be be preferred over NBT?
Perhaps, but it is easier to (conceptually) deal with 11,000 NBT in an account versus $11,000. Many exchanges don’t apply KYC/AML protocols to crypto <> crypto trading.
I like @Nagalim’s approach very much, but I’d vouch for a different lower cap for the fee.
I’m not sure whether that will disincentivize small transactions too much (interfering with what the mobile wallet tries to accomplish), but as the block chain can’t deal with huge amounts of micro transactions any way, it might at least be suitable for the far future of Nu.
Right now @Nagalim’s fee approach might suit the situation of the Nu network better.
Paying a fee that is derived from the transmitted amount and not from the size of the transaction seems like a fair approach in terms of paying a price for a service, but what would that mean for the protocol?
As I’m no developer I think deriving a tx fee from the transferred value and not from the tx size is no big deal - I might be horribly wrong with that…
With the release of Nu 2.0, this seems like a good time to revive discussions about transaction fees. I’m currently voting for a 0.10 NBT fee. I believe this amount would be reasonable even on a 1.79 purchase of a cup of coffee with NuDroid, and is still very cheap for those users who are using NBT to hedge against BTC in large amounts.
I think it’s important for shareholders to realize just how important our ability to set the transaction fee is. We provide a transaction service to people in the form of a secure and price stable cryptocurrency. Keeping the peg stable costs shareholders effort and money. Our business model consists of our ability to continually increase demand and sell newly created NuBits to people that have use for a dollar equivalent cryptocurrency.
Variable transaction fees give shareholders the ability to charge for the peg service we provide our users. As we raise transaction fees, NuBits are destroyed, which naturally reduces the overall supply. Decreasing the supply allows us to create and sell more NuBits to people when needed, thus bringing in profit to the network. This ability to charge for the peg service we’ve been providing for free has been missing since launch, but now we’ll finally have access to it. In a way it’s similar to BlockCredits being consumed in B&C, except with the added complexity of the peg and the fact that NuBits have more use cases.
Now, it’s also important that we don’t abuse this feature. What we need to do is find a transaction fee rate which is acceptable and doesn’t discourage the flow of transactions too much. To find this rate, it would be great if we had access to some data from the blockchain, such as the number of transactions every day, that way we could measure the effect our fees have on users of the network. I imagine stage 3 of the website was supposed to give us access to historical data like this, but it appears that it has been reprioritized in favor of parametric order books…
[quote=Jordan Lee]I asked desrever to prioritize implementation of parametric order books over the data service ChicagoSchooler is asking about. Parametric order books are needed to bring NuBit liquidity to pairs other than BTC and fiat (USD, EUR, etc). This feature will be important to the success of B&C Exchange as well as Nu.
In my mind it is questionable whether it should be funded at this time. It is estimated to cost around $10,000. The decision to fund that or not is ultimately up to shareholders. They can fund it directly with a custodial grant if they wish.
[/quote]
What I’m saying here is that we shouldn’t set transaction fee rates blind. Shareholders should have access to some way of easily viewing historical data from the blockchain, so that we can make better and more informed decisions.
I made a python script that looks at Tx history when I was doing the variable Tx fee analysis. It’s not super efficient (takes half a day to analyze the whole blockchain) but it should be usable for some estimates. I’ll upload it tonight.
As for what I’m setting for tx fees, I’m a fan of 0.02 nbt fee and 10 nsr fee. That way we more accurately represent the 2:1000 ratio of the nsr price.
Every time you use your credit card to make a purchase, the merchant pays what is called the “merchant discount fee.” The merchant discount fee is calculated as a percentage of the good or service purchased. It can range from 1.5 per cent to 3 per cent. On a $100 item, for example, the merchant could pay a fee of between $1.50 and $3. The merchant discount fee covers a number of things, such as terminal rentals, fraud protection and transaction slips. But the biggest component of it is based on the interchange rate, which is set by the credit card companies. In a complicated twist, the credit card companies don’t make any money from the interchange rate. The banks do.
This 0.11% average fee would be low as compared to 1.5% - 3% for a credit card. Retailers would find that attractive, and would perhaps offer discounts for NBT payment. An argument could be made that we could charge 1.00 NBT per transaction and still be competitive. Of course, given that we cannot currently charge a percentage Tx fee (only a static Tx fee), it makes sense to set the Tx fee low enough to capture the majority of consumers, even if it means leaving money on the table. I view 0.02 NBT as far too low given the economics of how our users are likely using NBT. With the absence of major retail use (so far, at least), the average NBT transaction might be much higher than $88. I’m interested to see what @Nagalim’s charts dig up.
The last point of my rationale comes from my prior work experience in pricing. It is very, very easy to reduce prices without consumer complaint. It is very, very difficult to raise prices without consumer complaint. Let’s take this opportunity to set the transaction fee at a fair level; this may be the only time in the Nu network’s history where just about everyone would agree that a transaction fee increase is fair. Nu allows the transfer of a stable amount of value anywhere in the world in a minute or two on your phone. That is an amazing innovation that is worth something.
EDIT: Another example would be to imagine 0.10 NBT on a 5.00 NBT purchase. It’s only 2%. How much do we want to encourage purchases and NBT use below 5.00 NBT per transaction?
I’ve put up what I did for the volume dependent fee stuff. I’ll work on simplifying it for the basic variable fee and maybe make a few excel plots.
Edit: Uploaded code, running now. It’ll take all night. If anyone wants to run a specific subset, just change the first few parameters to adjust the start, end, and spacing of the data points.
An interesting thing to note that I’m seeing here is that people move Tx after minting for a while, and so all their Tx are broken up into 10,000 NSR sizes. When sending from an address like this, users often pay as much as 10x the Tx fee. Steeply increasing the NSR fee will punish people for moving large amounts of NSR from an address that used to mint, and could conceivably generate a reasonable revenue, at least in the beginning phases where everyone mintss NSR and no one transacts with it.
We’ll have to see with the full blockchain tomorrow. I think we’ll see NSR fees on a different order of magnitude than NBT.
Well I would argue that at the end only the votes matter.
So it does not matter so much if not everybody agrees on tx fee’s increase provided there is a fair distribution of NSRs.
Anyway, I think the layered model is better than just setting 0.1 NBT for any tx.
For example, what happens with micro transactions?
If the tx’s amount is 0.1NBT, paying 0.1NBT is obviously too high.
I think this debate has been done already somewhere.
Or perhaps we should consider a typical tx range (from 1 NBT to 100 NBT) and set typical tx fees for that range.
So I opened it up in excel to take a quick look and that write-protected the file and caused the program to crash, so I’m having to run it again. If y’all got any idea of what specifics I’m looking for, please speak up, I am analyzing the whole blockchain and getting 1 or 2 additional variables would be quite easy.
The NBT slope during the linear part is ~9 NBT/100,000 blocks. A year contains ~500,000 blocks, so we are making something like 45 NBT/year from the 0.01 NBT fee.
My method here was to take all inputs and subtract all outputs of any Tx with type ‘pubkeyhash’, specifying NSR or NBT by looking at the first letter of the first receiving address (B for NBT and S for NSR). The result is the fee. Fees are summed per block and blocks are summed to get the graphs above.
To do this we would need a way of detecting volume for the transaction. I argue that if we are modifying the protocol to detect Tx volume, we should go all the way and make a full mathematical relationship involving a logarithm.
