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