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:
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%.
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.
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.
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.
what is this notion log(V,10) ?
Is it log10(V) ?
The formula I used in my model, that @tomjoad referenced:
=MAX(0.01, 0.01 * $P * $VOL / (LOG($VOL)+1))
Log is Base 10.
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.
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
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.
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.
@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?
At first look, this will probably be true. As I am finding with my fee analysis, the difference is approx. an order of magnitude (10x). However, though certain things are hard to quantify, I will attempt to argue that volume-based fees will be different than NSR chunking.
The crux of the argument is that volume-based chunking will be done so as to reduce the number of inputs to Txns. Inputs are by far the more space-intensive part, outweighing the space outputs take by 5x (~200KB/input, ~40KB/output). A chunking event takes 1 input to many outputs, so is not an event that takes a huge amount of space on the blockchain. It is the spending of the chunks that we need to observe more carefully.
When a chunked NSR address decides to send NSR to market, those Txns typically look like 100 inputs > 1 output. These Txns are really huge from the blockchain perspective, and we charge an event like that something like 20 NSR for the privileged. However, NBT chunking is done specifically with the spend event in mind: breaking big chunks down into manageable smaller chunks so that when spending we can get as close to exact-change as we can. We should have an incentive to keep people from chunking too often or into too many chunks.
Which brings me to my biggest question, point, whatever you want to call it. How do we deal with a standard transaction that is over 1KB in the volume-based fee model? This is my thought process:
A wants to send 10 NBT to B. A and B both sign a transaction that sends 10 NBT from A and 1 NBT from B > 1 NBT to A and 10 NBT to B. They pay only the 0.01 NBT/KB fee.
However, two people who do not trust each other will not do this. It is something akin to giving someone an address with money in it: it’s not safe if 2 people have access to the private key.
An easy way to fix this would be to add a line to the motion about how a chunking output cannot have more volume than the chunking input. In that case, the above event would not register B as part of the chunking process and would charge the volume-based fee on the 10 NBT in addition to the 0.01 NBT/KB fee for the change to A. With implementation, you would need to sum all the output volumes and all the input volumes for a particular address and if the out>in, charge the volume-based fee; otherwise, charge the chunking fee.
Then vote on a p (volume-based profit driven fee) and a q (chunking/change fee, cost/KB).
