Namecoin Forum

domob wrote:Another thing we should do: Get rid of using nVersion of transactions for determining whether a tx is a name operation or not. BIP68 will change the nVersion of transactions, which will (somewhat) break this. Should we use one of the bits in nVersion as a flag instead? Is there any reason why we cannot simply get rid of that information at all and decide this by looking at the scripts? The only one I can think of for now is performance.

Can't we ask the bitcoin developers to just reserve a bit or something in the nversion, for name operations or non-standard tx? (non-monetary tx?)

I think performance-wise it could be useful to have, because, then money-only-wallets can discard this tx info.

In any case: whatever it's easier to re-base namecoin later. The less changes in the code in respect to bitcoin, the better.

domob wrote:Another thing we should do: Get rid of using nVersion of transactions for determining whether a tx is a name operation or not. BIP68 will change the nVersion of transactions, which will (somewhat) break this. Should we use one of the bits in nVersion as a flag instead? Is there any reason why we cannot simply get rid of that information at all and decide this by looking at the scripts? The only one I can think of for now is performance.

I've always thought it was kind of odd that the transaction nVersion was used to enable name opcodes, since the way the name opcodes are designed makes their use equivalent to a NOP under Bitcoin rules, so there should be no conflicts against Bitcoin semantics if we apply the Namecoin rules to all transactions.

I don't know what the performance impact of such a change would be, so I won't speculate on whether performance is a reason not to change this. If we can follow Bitcoin more closely by removing the nVersion Namecoin check, I think that's useful, all other things being equal.

johnc wrote:Can't we ask the bitcoin developers to just reserve a bit or something in the nversion, for name operations or non-standard tx? (non-monetary tx?)

Although previous conversations with Bitcoin devs suggests that this kind of thing may be an option, I would very much prefer not to ask the Bitcoin devs to do anything solely for the benefit of non-Bitcoin currencies.

johnc wrote:I think performance-wise it could be useful to have, because, then money-only-wallets can discard this tx info.

What optimizations are you thinking of? Why would those optimizations not be able to discard outputs that begin with a name opcode sequence?

Okey, now that i think again it's not useful to have nameoperations flagged as they also involve monetary operations. So it won't save disk space anyway.

So how about consensus for increasing the domain registration length to 1 year? and the size to 1kb? Does anyone still oppose that ? It's a compromise...

johnc wrote:So how about consensus for increasing the domain registration length to 1 year? and the size to 1kb? Does anyone still oppose that ? It's a compromise...

I (weakly) oppose those changes, as I think we should only do completely uncontroversial changes in this "kind-of-emergency" hard fork. Political changes should be done in a seperate fork (whatever the compromise / actual change is).

I'm not sure why I still bother replying to posts from someone with a near 100% track record of posting junk, but anyway... (Fair warning, I might stop doing so soon.)

johnc wrote:So how about consensus for increasing the domain registration length to 1 year?

I suppose actually looking through the thread to see if I ever implied that I had stopped opposing this would be too much cognitive load....

johnc wrote:and the size to 1kb? Does anyone still oppose that ?

Ditto....

johnc wrote:It's a compromise...

So what? Your argument would be great if the Namecoin project were run by politicians, but I'm happy to report that that is not the case.

domob wrote:I think we should only do completely uncontroversial changes in this "kind-of-emergency" hard fork. Political changes should be done in a seperate fork (whatever the compromise / actual change is).

Yep. It is critical that all users accept this hardfork without disputes. That means that it must be limited to changes which no one objects to. I don't think we have enough of a userbase for hostile forks of Namecoin Core to be likely, but let's not give people a reason to try it. (That doesn't count the dumbass on Reddit who NACKed Brandon's GUI pull request because he thinks it entails empowering Blockstream to kill Bitcoin. I don't care if he objects to anything we do.)

I don't post junk, i just speak my mind, if you are going to criticize every single user than comes along this forum and speaks their mind you are going to end up alone.

You could try empathy, it starts by not thinking that everyone is against you. Try thinking that everyone wants to help but not everyone is a programming engineer.

You are right in many technical points but to be a community manager means something else. It's not a matter of who is right or who is wrong. The costumer is always right, even if he is wrong. That's public relations 101.

Obviously my requests are a wishlist, since this is a wishlist thread, and i agree that changes could be left for another hardfork.

TL,DR: Any namecoin user expects your answer to be in the line of "I'm afraid we can only include a minimum amount of changes this time, but your suggestions will be taken into account for the next hard fork."

You cannot just determine that i'm a troll because my english is bad and you couldn't make sense from my posts. (or something like that)