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?
Jeremy Rand, Lead Namecoin Application Engineer
NameID:
id/jeremy
DyName: Dynamic DNS update client for .bit domains.
Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5