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.
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.
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.
When I vote for 0.02 NBT into the fee vote field in Nu QT client, I interpret that as follows: I want any NBT tx to pay a fee of 0.02 NBT and I do not need to have in mind the quantity of data (ROM) transferred actually encoded.
Still, I would like to know the exact connection betwwen transaction fee and data stored in ROM into the blockchain, if someone could care to clarify, that would be very helpful since I would like to decide with the right understanding.
isn’t the official NU wallet automatically add the fee in every transaction?
thus exchanges should be ok, i think. (bter has 0.1 nbt fee anyway)
edit: the last 3-4 days every nbt transaction is sent from my windows wallet added 0.4-0.6 nbt fee.
i don’t know the reason, amount was small.
poloniex and hitbtc have 0.01, southX is updated to 0.02 !
the back and forth of fee value doesn’t look good.
edit: my feel is that we should leave it as it is 0.02 and not changing it all the time!
There are shareholders voting for 0.05, and it is not clear whether there is consensus on any fee as we don’t have tools look at that like we have for motions and grants. So it could change back any time soon or just jumps to 0.03. No one knows and it could change any time without notice. Without some forewarning e.g. for exchanges this is not a good situation imo.
Providing a quick patch for NuDroid with a 0.02 fee can be done, but might be obsolete in another week or so, I don’t know what the best course of action is other than spending time on working on a sustainable solution which will take time. Until then don’t rely on NuDroid. it’s a shame that we invested a lot of marketing in this, first the issues with the nodes no longer working and being taken offline without notice and now this. Not a good look for people looking to actually use NuBits. Hope there are some lessons learnt in this.
Just fired up my Bitcoin wallet, to be able to pay for some items in Bitcoins…
But I do think that it is also one aspect of the job of the developer who is paid by the shareholders to keep one’s self updated about new features all the time although shareholders should be aware of the complications that some features may cause but seriously who had in mind that the variable tx fee would cause such an issue?
Personally, I assumed that upgrading to the latest version of Nu would get you in the safe zone.
So besides NuDroid, who else has the same issue?
(I suppose the issue is: not being able to broadcast NuBits transactions because of a mismatch between the actual tx fee decided by the network and the tx fee set in the program)
I feel your frustration. I understand the reasons for it well. NuBits is still young and if you are looking at the adoption or the number of installed NuDroids still in its infancy.
Better make now these mistakes than later.
But on the other hand…
Variable transaction fees are an integral part of NuBits.
They need to be handled automatically and properly by wallets.
Full stop.
I will look into the dynamic fee code when I get chance, but I do think the best way to go now in the meantime is to release an update with the 0.02nbt fee. I might be able to do that later today, though I am busy.
When Nu 2.0 was released, I had no warning beforehand. The primary concern at that time was to disable the bloom filtering to ensure the app was compatible. I did at first read about the dynamic fees, but considering the chaos at the time, I forgot about them and the present day problems did not occur to me.
To ensure NuDroid is compatible with future Nu versions, I should always be given advance warning and presented with all of the protocol changes so I have time to go through them and plan an update, with enough time to obtain the funds and develop the changes to the app, before any protocol changes come into force. This also applies to other developers, or project managers of Nu-related software.