what is this notion log(V,10) ?
Is it log10(V) ?
1 Like
The formula I used in my model, that @tomjoad referenced:
=MAX(0.01, 0.01 * $P * $VOL / (LOG($VOL)+1))
Log is Base 10.
2 Likes
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
1 Like
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.
4 Likes
@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?
3 Likes
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:
- Change the second to last line of the motion to read: “If any output has a target address that is equal to its source address, the transaction will be charged an additional 0.01 NBT/KB fee.”
- Do not charge anything additional if a Tx is paying volume-based fees for all outputs and it exceeds 1KB.
- People can get around the volume-based fee by signing the same Txn as someone else so that the network is tricked into seeing it as a chunking event. For example:
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).
1 Like
We could also charge based on inputs instead of outputs. Then our set of problems is completely different.
I am not a fan of the notion of using the blockchain as a backbone settlement network. That is basically an admission that your network can’t scale. There isn’t much profit potential in microtransactions, so I don’t think we should target that market. However, the highest minimum transaction fee I have seen proposed is 0.1 NBT. Even that makes transactions of a NuBit or two practical, so the blockchain can handle transactions down to that size.
With some iterative development like implementing delegates and a mini-blockchain like that used in Cryptonite, our blockchain can scale quite well. It will never scale to the level of Visa, but I suspect we can get closer to that scale than most people think.
With around 60 transactions per day currently, scalability is not near the top of our list of concerns. People should know that scalability can be developed, but there is no reason to do so now.
3 Likes
I think the concern here is not about scalability but rather the effectiveness of transaction fees as a method of decreasing the Nubits supply, which is commonly viewed as the main source of profit and sustaining the peg!
No one will use the network if there is secure enough off-chain alternative.
One of the major questions emerging from this discussion is whether it creates an acceptable user experience to charge a volume based fee on all outputs, including the change. My guess is that it will create a limited amount of confusion, but is manageable. A related question is what is the optimum chunking size. I would like to know what others think about these two issues (optimum chunking size and how users will feel about paying a fee for their change).
I have seen this perspective articulated often, but I strongly disagree with the viewpoint. I detailed my own perspective about the source of profits (or more properly reduced network liabilities) in this recent post. In it, fees are presented as a minor source of profits. Volume based fees would make fees more important, but they would still be only one of several important ways network liabilities are reduced.
1 Like
Perhaps we should charge either a space based fee or a volume based fee, which ever is greater.
Well, all the currently proposed volume-based fees are strictly greater than the space-based fee because they are charged per output and no output is >1KB. I’m proposing we charge the volume based fee for each individual non-change output and the space based fee if any change outputs are present. A chunking event is a transaction where every output is a change output. A change output is determined by whether or not the output volume for an address (sum of all outputs for the address) is less than the input volume for that address, and the input volume for that address is non-zero (i.e. that address signed the Txn).
A change address when not in avatar mode is of course treated as a non-change address.
Also, the chunking should be a fibonnacci chunking.
Dividing a 100 NBT output would take 0.2 KB for the input +0.04/output across 9 outputs so the whole transaction would be under 1 KB and would cost just the minimum change fee (0.01 NBT). Then, buying that 25 NBT cab ride we would use the 1,3, and 21 NBT outputs again remaining under 1 KB and paying just the volume-based fee on the 25 NBT (0.095 NBT).
Doing this in avatar mode would entail paying the volume-based fee on the 25 NBT and then 0.01 NBT additionally for the space (up to 1 KB) because of the change output. The result is actually that you end up paying the same as without avatar mode because either you are paying for a chunking event or change. Of course, you could also chunk your change output into fibonacci chunks, thus filling up the rest of the 1 KB that you bought and avoiding having to pay the space fee on the next transaction (Txns where all outputs are unique from all inputs do not have to pay the space fee because the volume fee is more than that anyway).
The underlying premise here relies on the concept that all inputs are signed and thus if an output goes to the same address as an input but with less volume, it is by definition a change address (in avatar mode).
Funding is an essential part of any venture - I was just watching Vitalik’s last video interview on Ethereum and he mentioned they created the foundation essentially to manage funds to keep asking for more money to finance their research - He alluded to the fact that new ETH sales could be repeated in the future and he was even open to donations.
Do you have already concrete plan on how and when you will get more funding?
Do shareholders have any strict methodology on how and when to get more funding?
Thanks for elaborating why you think it never will & and the level it could reach.
Hey, I’m having problems with blocks like this:
http://blockexplorer.nu/blocks/258477/1
Is this a burn event, or what is this? Someone paid 57 kNBT in fees.
Yes this was a burn by @jmiller: [Passed] Motion to end LPC operations of KTm, Jamie and NSR sales of Jordan
If someone could please look at this breakdown and verify that there are no obvious errors in calculation, I will proceed with the burn of 57199.5803 NBT to this address: BMdEGVo9oSmsFHDKiL39CYhaSD3AmCv4s4
1 Like
We should increase the fee by an order of magnitude to become 0.02%. The B&C fee is too high for Nu, but what we have now is just giving away blockchain space.
Can we get a website or a client update with displayed Tx fee votes?