I don’t see how this is relevant. The vast majority of “transactions” that matter to hedgers are handled off-blockchain on the individual exchanges.
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.
a bit a la paypal.
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.
Tx Volume (NBT) ....Fee(NBT)........ Fee(%) 0.01............... 0.05.............500% 0.1................ 0.05.............50% 1.0................ 0.05.............5% 10................. 0.05.............0.5% 100................ 0.25.............0.25% 1,000.............. 1.25.............0.125% 10,000............. 6.25.............0.0625% 100,000........... 31.25.............0.03125% 1,000,000........ 156.25.............0.015625%
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.
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.
Equally as important is forecasting what payment mechanisms NuBits will be used to replace. In 2011, the average transaction on a credit card was $88.00 in the United States. If NuDroid was being used like a credit card, 0.10 NBT is only a 0.11% transaction fee on an $88.00 purchase. Relevant to this number is the “merchant discount fee”:
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.
Edit2: I don’t think the nsr bit is working right. Also, http://blockexplorer.nu is down.
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.
This is what I have so far:
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.
I agree more flexibility would be desirable to better price discriminate against transactions of different sizes. I quite liked the p=1 transaction fees in @woodstockmerkle’s post here: [Draft] Volume-dependent Transaction Fees
It would be anywhere from 0.1%-1% of a transaction. At each transaction size level, the fee feels very reasonable.
I’m trying to replicate his numbers and having a hard time, but that is very similar to what I am proposing. Both of our numbers start out at 1% (and all the way to 100% for Tx that are at the dust limit, as is currently the case). However, at his biggest number my calculations give 6817.68 NBT and 0.06%.
Anyway, as far as I understood, wsm was attempting to replicate the proposed algorithm and I am unsure how to derive the algorithm used to generate those tables.
I would definitely support your proposal if it was determined that it could be incorporated in the blockchain by Jordan Lee or a core developer. Perhaps you could create a similar table to woodstockmerkle with your revenue projections? It is much easier to read for casual observers than the equations.
The simulation was all wrong. There are other reasons why it was invalid anyway. I got the equation totally wrong for what I was trying to do. This is the first correct appearance of the equation I believe is ideal:
Is there a way to bump up the Tx fee percentage past Tx Amount = 1000 NBT? I don’t think our fee should ever go below 0.1%. It’s leaving money on the table since it would still likely be below any other competitor.
This fee is designed to be aggressive to people spamming the blockchain and lenient to people using it to send around large amounts. There are definately other algorithms, and we should talk about some possibilities, but this here is an intreguing one to me.
We are competing mostly with the crypto world for now, though I agree fiat is really our true competitor. Preventing blockchain spam is an important use of the fee, think about what this fee looks like when we increase to p=10.