Topic: [announce] Namecoin - a distributed naming system based on Bitcoin - page 74. (Read 597064 times)

Any coin you can find somebody in his right mind to represent for is boring  

Tried contacting vinced, nothing yet, trying to get a hold of any and all namecoin developers. There is an "alt currency" panel at the 2013 Bitcoin Conference in Amsterdam, Netherlands this September 27th~29th (http://theconference.eu). I am looking to see who would be able to attend and represent namecoin there. Who aside from vinced works on or has knowledge of the project enough to represent it?

Thanks!

Me too, namecoin means a lot to me.

I like namecoin a lot

recapping issues...

Hard fork
Consensus: hf is necessary. (increase value size too 9kb, increase relay fee, ...)

Tx fees
@khal: You certainly have the most insight on the code and on what is possible/worth the effort and what is not. I like the XYZ size/input/output based tx fee, if I understand correctly today only size is considered?

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?

Does the dust filter have an influence on relaying?

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?

What about something more exotic like deriving the base tx fee / base relay fee from half the average of the lowest tx fee in the last 50 blocks? See https://bitcointalksearch.org/topic/m.1627011 (also length staggered name_op fees could be based on this!). Ok, it's more work but I like the idea 

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.

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.

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?

I think he meant locking of some NMC as in name_new until the name expires. In contrast to destroying / coinbasing.

Messaging system
Cool but may be too much for now. Also there is bitmessage already.

Lol there's no human change log

*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

We could test this new domain without registration fee but with a namecoin binding to stop spam. I guess binding 1 namecoin would be OK and that would return to the domain owner after releasing the domain. So he would loose nothing and probably win when the namecoin prices will increase.

Thanks finally switched from bitcoin.conf to namecoin.conf

we need as many people as possible, like your self to voice opinions to get this right..

name_new was eventually going to be free.. but spam would be a problem atm..

i think it should just keep going down in increments.. based on the exponential growth of storage space increase... something like that..

Already switched.


Centralising a fund for development from fees will create many problems and imho is a terribly misguided idea, any/all fees should go to the coinbase transaction. Let the market take care of it ...we are getting development now.

namecoin.conf .. but i believe bitcoin.conf should "still" work... not sure which has priority..

should be easy to test

I never really have been a fan of NMC destruction it just like seems a crude waste. The eloquent idea seems to be the domain Binding, possibly with this value being released to the miners when the domain registration expires. I also like the idea of sponsoring a namecoin development fund through Tx fee, although I wonder if this needs to be done as a fixed % from within transactions?  Surely the need for a Fund is V. important now, but will decrease significantly with time. (Possibly it could be related to Block reward halving?)

Hard forks my vote is sooner rather than later with some very nice PR to the mining pools before hand.

There is a lot of good work coming out here guys keep it up.  

Have we or will switch from bitcoin.conf to namecoin.conf?

Using, hope I trust you

The Namecoin fee is also voluntary if you are sending namecoins from one address to another like you use with bitcoins. The fee is for a Namecoin specific service, the domain registration., which you cannot compare with bitcoin. This service requires additional work from the miners and from the DNS servers. However some people are opposing coin destruction and I proposed in this thread other alternative methods to protect the network against spam. Each of them has some advantages and disadvantages.
Some other choices could be namecoin binding or donation for a Namecoin Development Found(for those who prefer instead of coin destruction).

Yeah but the bitcoin fees are voluntary, the minimum fee is just a default of the official client. As far as I can tell the name_firstupdate fee is network-enforced, so it will become way harder to change if namecoin becomes widely used. Anyway, still would like to know the reason why vinced decided to put that 0.01 NC minimum since the only purpose of that fee is to reduce domain squatting early on. If the fee is left there then the money supply will begin to contract at some point when the block reward becomes less than the rate of destruction.

RPC command walletpassphrase added (and extras)
Progress bar added (does the job)

Please test and give any errors when compiling on Linux.

In essence this should now be a fully working client.. all name commands usable from debug window... with Encryption working.

as new commands have been added, we have set version to 3.55
You can compile the namecoind...

see commit

https://github.com/namecoin-qt/namecoin-qt/commit/a85e46773654a19e4964fba026e1d928ebd76cd8

https://github.com/namecoin-qt/namecoin-qt

Windows binaries - Namecoin-qt + Namecoind
http://www.mediafire.com/folder/3aa8ukj7v6m5d/Namecoin-qt


we are working on Nelisky's RPC commands next

Good work Khal.
Unfortunately I cannot help you by coding the client because I started just recently to study deeper technical details in Bitcoin/Namecoin.
But I am improving step by step my small project of merged bitcoin/namecoin wallet. Now I will add signature for a message with a namecoin address.