Discussion about the transaction fees

[tomjoad]

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.

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?

[Nagalim]

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.

Nagalim/NuTxFeeAnalysis

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.

[Nagalim]

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.

[cryptog]

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

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.

[Nagalim]

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.

[Nagalim]

the layered model

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.

[Draft] Volume-dependent Transaction Fees

Motion RIPEMD160 hash: tbc =##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##= The variable transaction fees, implemented as per motion 7283C71D2BDDC3B71E2EB7CD0693E28E3665BF66, will be replaced with variable, volume dependent transaction fees. Where shareholders would previously be voting on the flat fee, they will instead vote on a proportionality constant for the fee (labeled 'p'). Every output to a transaction with a target address that is different from any source ad…

[tomjoad]

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.

https://discuss.nubits.com/uploads/default/optimized/1X/a56aef3b7f40419bc811f52f69b1ddd28265bd03_1_170x500.PNG

[Nagalim]

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%.
NBT calculation
% calculation

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.

[tomjoad]

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.

[Nagalim]

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:

% Fee Calculation
NBT Fee Calculation

[tomjoad]

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.

[Nagalim]

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.

[Nagalim]

By the way, I want to be super clear that implementing any kind of volume-dependent fee is not a trivial accomplishment, it has never been done before in the crypto world to my knowledge (someone please prove me wrong). We will need to pay a good bit for it in NSR or NBT, but I think the long term benefits of a volume-dependent fee far outway any coder costs.

The reason I say this is because of the changeaddress problem. There is no way to tell which address in a transaction on the blockchain is the change address. To appease this, we need to create a chunking service, like NSR does for votes, to break up NBT outputs into manageable chunks, like a bank teller giving different bills for change. This service will not be needed at all by someone who uses avatar mode.

It’s pretty complicated and won’t happen for some time. We should experience voting on the flat fee before we transition to any kind of volume-dependent fee. However, I think that shareholders will soon become frustrated with how little revenue the flat fee generates.

[mhps]

what is this notion log(V,10) ?
Is it log₁₀(V) ?

[woodstockmerkle]

The formula I used in my model, that @tomjoad referenced:

=MAX(0.01, 0.01 * $P * $VOL / (LOG($VOL)+1))

Log is Base 10.

[Nagalim]

=MAX(0.01, 0.01 * $P * $VOL / (LOG($VOL)+1))

I can confirm the table now, I was reading it wrong. This is the fee that is currently written in the motion, even though it was not my original intent. I would be happy to go along with this algorithm, it is smooth and has a good range, as @tomjoad pointed out. Also, my analysis is valid for this fee: 10-30 kNBT/year at p=1.

The intuitive way to understand this fee is that with p=1 a Tx volume that is a multiple of 10 will have a fee that is [ 1/(number of digits) ] % of the transaction volume.

[mhps]

Is it log10(V) ?

then isn’t 2^-log(V,10) just a powerlaw relation that equals V^-1/log(10,2) , which is easier to understand as V^-0.301

[Nagalim]

V-0.301

True! I can confirm both the math and experimentally it is a good approximation.

1/[log(v)+1] cannot be simplified further, however. I could make arguments for either algorithm honestly:

The power fee is nice because every decade the fee halves. It is somewhat simple and the fee drops off quickly with high volume, allowing for an easy transition from a flat fee.

The log fee is probably a more robust algorithm, it provides a good range of profit at all levels, yet it gives the user a sense of a discount for high volume Tx.

[JordanLee]

No doubt additional transaction fees could be charged without excessive pain on the part of users by varying fees by the amount of value transferred. @Nagalim is correct that there is the issue that change and the output actually transferred to another party cannot be distinguished. He is also correct that dividing an address balance into separate outputs does much to mitigate this problem. Doing so might slightly reduce privacy in the network by giving more clues about which output is the change and which has been transferred to another party, because the smaller output would be much more likely to be the change if addresses are broken up into smaller size chunks as we do with NSR. There are a number of techniques to mitigate this, such as intentionally making the change output larger using coin control or using privacy enhancing services that sit above the protocol, such as Blockchain.info’s shared send. My guess is the enhanced transaction fees would be more important than the small degradation of privacy.

Another consideration is that the chunking we currently do with NSR does take quite a bit more space on the blockchain. This means that charging volume based fees will take more blockchain space. Chunks might be anywhere from 100 NBT to 1000 NBT. 1000 NBT chunks would be much more compact in the blockchain but would give less precision when charging volume based fees. Another issue is that chunking size may need to managed separately for each currency, to take into account vastly different values. Japanese Yen probably need a different chunking size than NuBits, for instance.

In regard to blockchain space, I believe as our network grows and gets more funding, most minting clients will not keep the full blockchain, but rather only relatively recent blocks combined with a database of balances. This would be a variation of what has already been done with Cryptonite, the first mini-blockchain implementation. So, blockchain space will become cheaper.

[Sentinelrv]

@JordanLee, I have a question. This has to do with the fee discussion, but I’ll get to that at the end. Those from the Peercoin community know that our 0.01 PPC/kb transaction fee was designed by Sunny King to prevent transaction spam. It protects Peercoin’s blockchain and keeps it as small as possible. The unfortunate side effect is that it makes microtransactions impossible.

Many (including myself) have pointed to Sunny’s previous interviews where he says that off-chain networks (centralized or less decentralized networks) would provide micropayments and instantaneous transactions, letting users bypass the fee. This would allow the Peercoin blockchain itself to be used more as a secure and decentralized store of value, rather than a transaction platform. The blockchain itself would act more as a backbone settlement network, while the majority of transactions would take place off-chain. I imagine Peercoin and off-chain networks working together may be the only way to truly compete with the transaction processing capabilities of Visa and MasterCard while still remaining decentralized. Bitcoin seems to be trying to compete, but sacrificing its decentralization as a result.

My question is will Nu eventually need to take the same approach as Peercoin by working together with off-chain networks in order to scale to the level of transactions possible with Visa and MasterCard? Nu would effectively also become a settlement network, with the majority of transactions taking place off-chain. The problem with this though is that it would allow people to avoid paying the transaction fee set by shareholders, which would prevent us from being able to use the fee to naturally cut down on the supply of NuBits. Peercoin doesn’t have this problem, because they’re not trying to maintain a peg. With Peercoin there is no urgency to use the fee as a tool to reduce the supply, however with Nu there is. If Nu will eventually need off-chain networks to scale the amount of transactions possible, then how will shareholders be able to cope if these networks allow our users to bypass the fees we set?

Maybe I’m missing or simply misunderstanding something. Would you care to elaborate on this?