Vinced has disappear a long time ago like Satoshi (it was his intent). I hope he would have replied to some of my messages, but it was not the case anymore quite shortly :p
I'm not a communicating guy, but, I'm not fully closed to the proposition.
Any other person interested ?

People able to speak about namecoin : at least phelix & midnightmagic, and surely others

[edit]: matching thread here : https://bitcointalk.org/index.php?topic=209152.0 ?
Why need 2 different conferences ? Not possible to speak about several aspects (social & economic & etc) at the same conference ?
[/edit]

Wow, a lot of work ! Need to be backported to namecoind too...
For info, last time I tested namecoin-qt, it was displaying the small starting window and then crash (but it compiles :p, debian 7, 64bits).
I'll update and test again.

For info to other people, I've done a quick review of all the code changes in namecoin-qt (about 2000 lines for qt without transalctions + changes to namecoind) up to 2 days ago and didn't see something suspicious.

Yes, size of tx for client and also size of the future block for miners.


Currently, only by compiling it. But it can be added as command line options like in bitcoin.


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

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 ?
[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]


Indeed, more work...

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


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.


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

A new update has been released : v3.0.4.

Some bugs fixed :p

Source :
https://github.com/khalahan/NamecoinToBind/archive/v3.0.4.zip

*Sic* We severely lack of communication...

I've checked the applied fees on existing tx, and here is the result (i didn't include small tx than can be free [with 2 txIn and 2 txOut for exemple]) :

Small tx, 7 txOut dust (8x0.005)

Small tx but lot of dust (~30 outputs < 0.01NMC) (31x0.005)

Big tx (41x0.005)

Big tx (98×0,005)

Big tx, 1 dust output (this tx does not follow client fees of 35x0.005=0.175)

Small tx, no dust (3x0.005)

Small tx, no dust (2x0.005)


As you can see, fees are not so small (and if NMC value increase, it'll be expensive), if the tx follow the default fee mechanism with a base fee of 0.005 in the client.
The default client fee of 0.005 has been changed in version 3.5 (if I'm right), to adjust to something more reasonable and coupled with dust spam filter it seems to generate correct fees.
But, to avoid a hard fork, the relay fee is still set to 0.0001 (50 times lower), so it's possible to pay 50 times less.

So, to resume problems :
- the dust filter is a bit "raw" (for each output below 0.01NMC, add the default fee) and not suited for tx like 1c30f791638ce5dfd9dcd48b0a17bcd86f30df673659b91fdd56adeaaba956a7 & f519d0eef901e9920bbb532239f55304f66ae05f8e2f01b112d02a4d88699bb4.
- relay fees are too low
- if we both changes the way to calculate fees & relay fees, default fees will be too high.

Maybe we can :
- update the dust filter to use 0.001 as limit (instead of 0.01NMC) and add 10xFees when dust
- complete by "add fee for each txOut above the second one" (too much split penalized)
- change the relay fee to 0.0002
- change the client fee to 0.0020

About name_* transactions, we can choose to add fees in any case (so, 0.002NMC for client / 0.0002NMC for relay)
About locked coins in name_new, we can change the value to 0.0001NMC, but we'll raise the anti-dust feature (it may be a way to force fees), so, 0.001NMC ?
With those 2 changes, people have an incentive to update to this new version (0.005NMC instead of 0.01NMC for name_new + name_firstupdate) and each name_update will cost at least 0.002NMC

Result on TXs above (currentFee => new ClientFee / new RelayFee) :

As I don't understand very well what it means :p

You can also propose him to "rescan" the blockchain to check if all those tx are in the blockchain.

Welcome to new users :p

how to pay fees without a tx in the blockchain ? :p
At least there must be one tx in and one tx out for the change, unspent part is the fee for miners. Out of the chain, a msg is broadcasted, like a tx/block/addr/etc, with the hash of the tx and auto-signed with the key used by the tx.

Another possibility is to spend the tx with the fee (std tx with its hash) + a second hash of the tx + the data, and only the first part is stored in the bc.

Avoidind several msg to be sent for one tx would be a pain for something that should not be stored :p

See http://dot-bit.org/Network_Rules_Upgrade :
- We need to fix the bug which limit the value to 520B => hard fork required, so we can upgrade to 9k instead.
- Fees are not adapted (coins are split & data storage is very cheap) => spam

See http://dot-bit.org/UpgradeNamecoinCode :
- Current namecoin is not efficient => switch to recent bitcoin code

We must not wait too long too, otherwise they will really all stop mining :p


It seems it is not the case indeed... Oops


Wouldn't it be simplier to improve the fee per kB ? Plus, as it seems the locked fee can be anything...
A name_update costs fees if you renew it before some combinaison of parameters :


:p

I'm not against this idea, but not for it either. Other opinions on this ?


It may be a bit complex to do that (allow the coin to be included in a tx without including it in the total amount from txIn. Algo of coin selection need to be modified + this adds another specific case).
Even the possibility to give it back to the last name owner should be analyzed carefully (I've verified, coin selection algo is also concerned...).


Standard transaction fees should be changed for this reason :p


Indeed, it shouldn't be too expensive, and we must plan for it to be not too much expensive even if the NMC value do x10 (that also why there is relay_fees AND client_fees).
If some people plan to register thousands of names for "specific" usages, maybe using something else than names, like "messages" (I've done a PoC in the branch message_send [rapid hack, usable, but not for prod :p]) may be more suited. Those messages would require 1 tx instead of 2 for names. Maybe using a PoW like BitMessage would be a good idea. And, to go further, we could also do messages that won't be recorded in the blockchain (maybe both would be needed, or the blockchain one is not really needed)


---
Another thing we didn't speak about yet is free transactions (no fees).
Should we allow them ? (I would like to)
Only for standard tx or also for name_tx ?

Current algo allow them depending on
- space left in block currently created (so, those tx may be delayed to future blocks)
- age * amount of coins / tx size (using the amount in this formula allow any big amount to be split into small ones for free. Using the tx size limit this behavior)
-> currently: small tx (< 1kB) + old and/or big coins (dPriority) + no dust = free tx

---
I've another idea that may not be appreciated by everybody : use lost coins to fund namecoin bounties & a giveaway.
An opinion ?


---
Some update on the proposal :
+ x nmc per kb (could be non linear, a bit exponential)
+ y nmc per txout (avoid too much splitting)
- z nmc per tx in (txout size will reduce, but cpu is used to verify signatures)

X > Y > Z: a kB cost more than a new txOut, that cost more than a txIn spent (to make thing simple in the code, Y = X / const and Z = Y / const, that way we declare 1 value : X, like now)
Y - Z >= 0 : can't be negative, even if UTXO is reduced

Here is a simple proposal based on resourse usage :
+ x nmc per kb
+ y nmc per txout (avoid too much splitting)
- z nmc per tx in (txout size will reduce, but cpu is used to verify signatures)

Y - Z can't be below 0 or x for exemple

Size added on the explorer : http://explorer.dot-bit.org/nbb=100/fromb=0
1 or 2 cents of fee for 15k per tx is cheap for a world distributed and permanent storage system.
Namecoin can meet a great success :p

391k block : http://explorer.dot-bit.org/b/24a0f711c42787d22a9228399d3bddc9096181bc32fa430198362c7fb390bd3c

1 tx hash :  http://explorer.dot-bit.org/tx/b11ae7d2cc8a4ac606e4b9aa8aec3347e8d1b0559174a5e86bd47c6097cb23af
nb input tx: 495
nb output tx: 2
size: 32k
fee:  0.045NMC

This tx has reduced number of unspent tx a lot, for exemple. Should we really penalize that ? :p

One original tx that splitted amounts : http://explorer.dot-bit.org/tx/e5d13d2a2d695b4cf6e9ed07c93aaff5abcdf5a3041c754b82519659093d47e8
input : 1
ouput : 40
fees : 0.13NMC
size: 1,5k

However, there are things to do about fees.

But I don't know how to fix an arbitrary amount that have a different value in 2 years ?
I like simple solutions and using an arbitrary amount based on current bitcoin & fiat value is not good one, but maybe the simpliest.

Any simple idea ?






Indeed, that's a hard limit on number of names and with money that don't go to miners (to avoid free names I guess)
It is a sufficiently high number to make it evolve (being dynamic or not) long before we need more room.

Same thing happened to me. After verification, it is the anti-dust mecanism :p
Do not send less than 0.01NMC to avoid it (another thing to update ?).



No coins are lost anymore since a long time.

A name_new is composed like that :
- 1 tx with the remainder of your coin (the change)
- 1 tx with an amount of 0.01NMC sent to you + a hash of (randomValue + yourName)

To create a name_firstupdate with the previous name, you must provide the random value and spend the previous 0.01 coins in this transaction (in bitcoin words : you sign the previous coins to prove you own it and then, you are able to spend it) and spend it to yourself again.

To create a name_update, you do exactly the same thing, except you can give an address you don't own on the command line to transfer the name to another person, which will be able to sign the received tx to update the name.

So, a name HAS a value of 0.01NMC at least.

When a name expire, the 0.01NMC stay there, locked.
There is currently no code able to read that name tx and spend it to a standard bitcoin tx (the network doesn't support). Not sure if it would be interesting or not ?

Hum, I tested sendtoalias (which is another command, only in my branch), so it may not have helped you...
But I confirm that sendtoname works for me too.

Ok, will try to test it a bit, but will try to compile it first :p

I tested it again on my computer (linux) and it was ok.
Command used: ./namecoind sendtoalias khal 0.0001
Result: 0.0001NMC sent to N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
Namecoin record: ./namecoind name_show id/khal
{
    "name" : "id/khal",
    "value" : "{ \"email\" : \"khal@dot-bit.org\", \"bitcoin\" : \"1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T\", \"namecoin\" : \"N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9\" }",
}

We shouldn't make more changes than those already present in the 0.8 version, to facilitate the beta phase and limit the cause of potential bugs and to find them faster.

So, all this should go in the v3.50 and we will publish a new release.

Those changes require a hard fork, so we need to decide a block number after which they will take effect (how much time you think is needed to wake up all namecoin users ? :p).

Concerning the fees, what is the best model to choose for :
- default fees of the client for standard transactions
- required minimum fees for standard transactions
- default fees of the client for name transactions
- required minimum fees for name transactions

For infos :  https://dot-bit.org/forum/viewtopic.php?f=2&t=503


Should it work with mingw (cross-compiling for windows under linux) and linux ? (I didn't try and I don't have required lib/tools yet)



Edit: my opinion on fees : simplier = better => Force normal fees on all name_* tx (no free tx) + keep the 0.01 locked NMC on name_new.

=> 1NMC = near 1$. Parity soon :p (http://dot-bit.org/tools/domainCost.php?unit=USD&cost=1)

The 0.8 version "disconnect" from a node as soon as it receives an invalid block. As merged mined blocks are transmited with other blocks while you bootstrap the network, I didn't get all blocks I could've download.

After restarting namecoind several times, here are the last blocks accepted :
- mainnet : 19199 (19120 is a merged mined block with a non standard hash : d8a7c3e01e1e95bcee015e6fcc7583a2ca60b79e5a3aa0a171eddd344ada903d
- testnet : 4031 (4032 has not the required difficulty. Maybe another testnet rule has been changed)

I've updated checkpoints in the code to go further in block downloads.

Last blocks validated by my 2 nodes :
- mainnet : 11610 (block rejected with bad PoW)
- testnet : 1045  (block rejected with bad PoW)

Some coders here to give their opinion ? :p

Code is available in my tree in the namecoin_v0.8.2rc2 branch :
https://github.com/khalahan/namecoin/tree/namecoin_v0.8.2rc2

Good :p
I'm interested on the way you did that mix on namecoin 3.5 and boitcoin-qt 0.8

Interesting extension of the ID namespace usage :p

I added both your use cases on the wiki : https://dot-bit.org/Use_cases