Discussion about the transaction fees

NuBits
#49

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:

  1. 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.”
  2. Do not charge anything additional if a Tx is paying volume-based fees for all outputs and it exceeds 1KB.
  3. 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
#50

We could also charge based on inputs instead of outputs. Then our set of problems is completely different.

#51

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
#52

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.

#53

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).

#54

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
#55

Perhaps we should charge either a space based fee or a volume based fee, which ever is greater.

#56

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).

#57

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?

#58

Thanks for elaborating why you think it never will & and the level it could reach.

#59

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.

#60

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
#61

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?

#62

The current transaction fee can be displayed by selecting Help…Debug window and then typing getinfo in the Debug window. It looks like this:

“paytxfee” : 0.01,

There isn’t an RPC to get transaction fee votes. I propose including a getfeevotes RPC that takes a block height and block quantity as optional parameters. I would like to have that in the next release. I expect the 2.1 release to have few features so we should have it relatively soon.

4 Likes
#63

The NBT transaction fee is still being voted for at 0.01 NBT. Those of you who are still voting for this amount, what is your rationale? Why not 0.02 NBT, 0.05 NBT, 0.10 NBT, or 0.99 NBT? At 0.01 NBT we are not yet properly transferring the costs of doing business onto NuBits users.

#64

I’m voting 0.02 nbt. I don’t think we should spike this too quickly because it could do irrevocable damage to our brand.

#65

I think the data feeds of @cryptog and @cybnate are still voting for 0.01, right?

#66

Is there a way to tell how many people are following these feeds? I wonder how much impact they’re having on things like this.

#67

Mh. Analysing httpd logs?
It’s http traffic after all, but I’m not sure the two can analyse such things on github, which is hosting their data feed files.

#68

Actually, there is a way to track this. If each data feed provider inputted a unique motion hash into their voting (such as 0B5AB73448AFDF1080598ED9A083DF4EE94925F2 for “This is Cybnate’s data feed.”) we could track in real time the level of support each data feed provider has. This motion hash would be unique to an individual data feed provider. This approach would guard against voter centralization because the network would be aware when a particular data feed provider is being used by too many users on the network.

2 Likes