The client should come with reasonable default fees as you suggest. Would it be possible to change these via the config file or only via compilation?
Currently, only by compiling it. But it can be added as command line options like in bitcoin.
Compiling to go below a minimum seems better to me.
Does the dust filter have an influence on relaying?
Yes, it is applied after that the free mechanism reduces fees to 0. However, not all miners may use it (old version of namecoind).
Fees on size are applied before the free mechanism, and it hinders me a bit.
If we agree that what is expensive for the network is data storage/signature checks, then, the fees applied on size/txOut should be after applied the free mechanism, like the dust one.
Current steps :
1. fees = size x baseFee
2. fees = 0 if (priority & size < 1k / block < 9k)
3. fees = + dust
I would like something like :
1. fess = baseFee
2. fees = 0 if (priority & size < 1k / block < 9k)
3. fees = size x baseFee
4. fees = + dust
5. fees = + split
Hmm, what is the point of 1. and 2. if they get overwritten in 3. ? IMHO 3. to 5. would be enough.
Miners are not bound by priority. Eleuthria said himself BTCGuild was experimenting with completely ignoring priority, could be they already use it for production by now (for Bitcoin).
So by the very small advantage of occasionally saving a small fee you make fee calculation unpredictable voodoo, make things more complicated for pool ops and have a good chance of delaying your txs in the future. I have a strong opinion on this issue: priority is bad at this point.
(It would be good if miners would still prefer high priority txs as long as they pay reasonable fees because that makes block flooding more difficult).
I agree the relay base fee should be increased. Not sure about the change of the base tx fee - all in all is that a decrease in fees compared to what we run now?
Splitting is more expensive, dust less (due to reduced threshold) & more (due to 10x the fees), size less (due to reduced fees); standard tx less (due to reduced fees).
Im' not sure about reducing fees too, but we must plan things as if 1NMC = 10 x current value => 10$. Is the current fee value of 0.005 still adapted to this ?
ok
[Edit: I didn't add fees for txIn on my previous post, maybe we could do it too for each txIn above 2, which would increase fees for those tx]
? I thought txIns would decrease the fee?
Free txs
There is no way to force miners to include these, so I would prefer all MY txs to include fees by default. Also I don't see what the problem is to pay a tiny fee once every year.
Tx priority can be helpful should someone try to flood the network with txs so I would keep priority for miners that want to use it but have all txs pay normal fees by default. Hopefully this can simplify things, too.
The easier the fee system the better this works so it would sure be nice if there was a single base fee as khal suggests that can be adjusted.
Ok, so no change in priority/free mechanism for miners, but fees for everybody on the client side ? Keeping this part as it is already is the most simple choice :p
But as I propose to remove free tx for miners if size > 1k... I would like to let the
choice for miners to include free tx, but only if txSize < 1k, and apply fees for size in other cases (even if the blockSize is mall).
Miners change this to maximize profit anyway...
Name op fees
IMHO it would be best if there were length staggered name op fees that would be network enforced and go to the miners (now or later does not matter). I guess it would be quite an effort, though.
If it is going to miners now, it may be more simple for users (nothing to do). In the other case, that would require to check for each name_tx if the name is expired and if the coins can be selected + force it to go to fees. Or add a name_refund/release rpc command.
Both choices (miner fees or locked funds until expirations) will need some effort.
Just realized there is a problem with giving name_op fees to the miner that solves the block: miners can make a business of selling name registration much cheaper. It is profitable for them down to about 2% of the fee (orphaned blocks being the limit). So fees should be distributed to several miners... which might still give weird incentives.
Binding/locking a deposit contradicts the point of the fee. Until distribution to miners can be done in a proper way I vote for locking indefinitely / destroying.
This is an issue with high fees in general, also with the XYZ fees. The moral of the story being that miners have the last word.
Output size >! tx fee ?
Enforcing this would help making txs spendable thus reduce chainsize. It would also make name_ops a little more expensive. What is the point of all these dust tx?
What is currently considered as dust are txOut below 0.01NMC, which seems to be quite frequent in the chain (but still > 0.001NMC). Mining ? Gambling ?
// If you'd pay more than 1/3 in fees
// to spend something, then we consider it dust.
+1 Whatever goes against dust.
Sidenote: why does Bitcoin code have to be so... weird...
I'm for a stacked fee system : each characteristic of a tx can require a small amount of fees that are added to each other => less way to cheat the system as a "bad" tx will fall in at least one case, while allowing standard tx to remain cheap.
Sounds good
[...]
c) If you name_update before anybody else does a name_new, the expiry field resets to 36,000.
[...]
Does this really work? I thought I tried and it did not... Would be nice if it did.
@snailbrain: Awesome, will try to find the time to compile on win and test on the weekend.
