Any good idea about the NuShares fee to set?
I wanted to mess with the nsr fee until I realized we earn about 10x more from the nsr fee than we do from the nbt fee because of the 10 kNSR chunking system. If anything, I think we should lower it, but I’m actually of the opinion that it’s in a pretty good sweet spot as is.
By the way, since it is likely that the minimal amount of NSRs required to vote will be reduced to 1 (according to ), the standard NSR tx fee should be divided by 10,000 as well.
While adjustable transaction fees serve a number of purposes, my primary reason for promoting its implementation was as a protection against denial of service attacks and attempts to bloat our blockchain. Here is the question that is most important when selecting the optimal transaction fee:
If someone performed a denial of service attack against the network, would you be pleased with the revenue gained from transaction fees or would you feel the attacker took more value than they paid?
At 0.01 per KB, you can buy a block for $10. This means an attacker could dominate the network and delay many or most transactions for an entire day for around $14,400. A 24 hour attack would add up to 1.44 GB to the blockchain (which is currently around 700 MB). Would you be happy to have transactions disrupted for a day and have 1.44 GB of additional space used on your hard drive for $14,400 of revenue? If your answer is no, that means fees are too low.
At 0.05 per KB the cost of a 24 hour denial of service attack is $72,000. I would be quite pleased to see such an attack performed. If it happened repeatedly, we could use a small portion of the revenues to develop a method to trim the blockchain. Most of it could go to share buybacks and we would see the NSR price soar.
Our network is very open and provides access to untrusted parties by design. The simple truth is that we can’t prevent a denial of service attack, but we can decide how much it costs. We ought to charge enough for transactions that we would be pleased to see a denial of service attack. What is the minimum fee that would make you pleased to see a denial of service attack? At 0.01 per KB, I would be disappointed to see an attack. At 0.03 per KB, I’m not sure. At 0.05 per KB, I say bring it on!
6 Likes
It’s a good point, our response time to a type 1 spam attack (DDoS) is for sure lacking even with our pretty excellent voter participation. There are a disproportionate number of Txns below 0.1 NBT which a higher fee would surely kill. However, to some degree we should consider if that is a bad thing. Even without a DDoS attempt, type 2 spam (blockchain bloat) is still a considerable issue, especially in our early stages. Whether the data is loaded onto the blockchain in the period of an hour or the period of a month, we will suffer if we do not increase our fee eventually. How much are we willing to sell our blockchain space for? Are we really willing to double our blockchain for $10,000?
The people that are sending small transactions are most likely just trying things out, testing. If we force them to spend $0.05 instead of $0.01 to test, will it make that much of a difference? We are scared of losing customers, but do we even want customers that either a) are fretting over cents for a great service or b) are trying to do some form of micro transaction that will bloat the blockchain? I believe group a) is small and group b) we want to discourage (or make them pay their fair share).
The revenue from a 5x increase would likely be somewhere near $2.5/day, which is <1% of our expenditures. Still, @JordanLee is right that the spam protection of the fee is a very real concern and we need to prepare ourselves for both long range and short range attacks by keeping a consistently high bar for spam.
3 Likes
I neglected to point out that with the NuShare fee set at 1 per KB, we could see a full 24 hour attack performed for less than $3000. Because the NuShare fee is less than the NuBit fee, only raising the NuBit fee doesn’t provide any protection from a denial of service attack. The lowest fee is what matters.
I see the security benefit in a high fee and the economy benefit in a low fee. In order to compete with creditcards (2-3% fee) the tx amount would be above 2 NBT if the fee is 0.05
Just to clarify things. What is the definition of a tx fee? The amount of NBTs taken away per KB of data contained within a block?The amount of NSRs taken away per KB of data contained within a block?
It charges based on the number of inputs and outputs to the Tx. It has nothing to do with the actual amount of NBT being transferred. My rule of thumb is 5 outputs per KB and 20 inputs per KB, plus a little overhead. A Tx with just one input and one output still pays the minimum fee.
what about a changeable fee according to network load? is it possible?
then we can vote for its range.
Here I propose just such an automated ffe based on network load:
https://wiki.peercointalk.org/index.php?title=Preventing_Network_Spam
Following this thought (0.05 NBT per kB), the NSR fee would need to be adjusted to 27 NSR per kB1 to be economically on the same level, right?
Nu might be able to live with 25 NSR/kB instead 
Or is this assumption flawed, because the inputs and outputs of NSR require different sizes on the blockchain compared to NBT transactions?
1 0.05 NBT/kB / (0.000008 BTC/NSR * 230 NBT/BTC); brackets only for readability
The BKS equivalent for NSR would be ~25 nsr. The BKS fee is ~$0.05/KB and NSR is ~$0.002, so 25 nsr sounds about right to come out with the same fee as BKS.
But the BKS fee is paid per Byte in difference to Nu where started kB chunks need to be paid…
That means the fee for a “simple” transaction on the BCE blockchain might be way cheaper than the fee for a “simple” transaction on the Nu blockchain.
Might adjusting the Nu fee to a “per Byte” level be something Nu’s source code could pull from BCE’s source code once in the future?
Quintupling the fee per volume, but calculating it per Byte instead of kB would combine the powerful spam/DoS features of the fee with a cheap price for regular use.
1 Like
Yes, I think a per byte fee structure is better. The per kilobyte structure is something we inherited from Peercoin. If there are no or few objections, I’ll see that this is changed in Nu 3.0.
To be clear, Nu 3.0 will contain two distinct fee structures, one based on the number of bytes in the message and another based on the value being sent in the transaction. The actual fee required by protocol will be the greater of the two fees calculated. The per byte or per kilobyte method must be retained to protect against blockchain spam and denial of service attacks.
3 Likes
Interesting write up.
PoS coins also have a concept of coinage that allows minters to prioritize Tx with the same fee.
I think coinage was invented by bitcoin for this reason.
There can be two windows in a variable fee system, the length of moving average when measuring the filling factor, and the length of adjusted fee is in effect. These two don’t have to be the same. If the latter is set much longer, one DDoS attack block will trigger a higher fee for a long time, helping lower the frequency of repeated attack while keeping a quick reaction time.
the tramsaction fee has already changed to 0.03 ?
this is due to the fee voting in wallet and the change is automatic (dynamic)?
How do you come to that conclusion?
[...]
"version" : "v2.0.1-unk-beta",
"protocolversion" : 2000000,
"walletversion" : 1,
"walletunit" : "B",
"balance" : 0.0,
"newmint" : 0.0,
"stake" : 0.0,
"parked" : 0.0,
"blocks" : 542578,
[...]
"paytxfee" : 0.01,My client still displays 0.01 NBT (per started kB transaction size).
If you have created a transaction over 2 kB and below 3 kB size, the fee is 0.03 NBT, though.
very strange. I have sent 100 nbt before and never asked me for 0.03 fee!
i don’t understand!
for example:
Status: 11625 confirmations
Date: 17/9/2015 19:55
To: xxxxxx
Debit: -100.00 NBT
Transaction fee: -0.01 NBT
Net amount: -100.01 NBT
The fee scales with the size of your transaction that has to be recorded in the blockchain, which varies and is not exactly dependent on the value transferred, but is usually not much.
===============
To add to this discussion in general, I think it makes sense to have tiered fees tailored to different use cases and habits rather than a lumped measure. Here’s an example…
First, we have an expensive volume-dependent fee that charges at least 0.05 NBT and otherwise up to 0.5% of the total amount sent. A transaction that pays this fee can be included in any block.
Then we have a cheaper fee, at least 0.03 NBT per kb and otherwise up to 0.3% of total amount. A transaction that pays this fee is only included in 5 blocks every 10 blocks (e.g if block height is 0,1,2,3,4 modulo 10), so the user would expect some extra delay up to 5 blocks.
Then we have a cheapest fee (e.g. 0.01 per kb) for microtransactions that are only included for one in ten blocks. Something like this at least should be an intermediary measure while moving to volume-dependent fees.
Finally we can also do some acrobatics - we can use block-chain recorded “deferred transactions” that also reduces some fees. The transaction would look like a parking transaction, sent to a “parking” address and released to the final destination after a given amount of time. It costs two transactions just to do one, but offers some security to the recipient and allows us to observe and reduce the speed that money is moved around the network, somewhat offsetting the role of parking.
If well designed we would have more fine-grained control over the trade-offs in the effects of transaction fees.
1 Like