This is not really correct, for several reasons.hla wrote:The lock limit is a bug and should be fixed. The block size limit for Namecoin, as for Bitcoin is 1M. The lock limit is a bug in one implementation of Namecoin, causing it not to comply with the parameters of the network. It should be fixed. If you think the block size limit for Namecoin should be reduced, that should be argued for and effected in its own right.
The lock limit is an artefact of a bug in a specific implementation and its precise behaviour is as such characterised by the innards of that implementation. It is highly inappropriate to use it as a defined limitation on a cryptocurrency. If you want to make it a formal limit, how are other Namecoin node implementations, which do not necessarily use BDB, supposed to effect it? Presumably they would have to calculate the exact number of database operations which a BDB-based node, no, a specifically Core-based node, would have done in order to effect that limit. That's absurd, and a design disaster. It's certainly not something that should be effected deliberately, even temporarily.
First off, in decentralized consensus systems, bug-for-bug compatibility is a security requirement. It doesn't matter which implementations match a spec; any implementation that doesn't match the exact bugs in the primarily-in-use implementations is considered to be wrong.
Second, Namecoin Core doesn't use BDB; it uses LevelDB. (BDB is used for the wallet, but that's not related to this.)
Third, what is referred to (for origin reasons) as the BDB lock limit is actually a quite simple function. It's the sum of transactions, namecoin version transactions, and transaction inputs, and it can at most be 4500 for the block to validate. See the code here: https://github.com/namecoin/namecoin-co ... .cpp#L3390 . It's trivially easy for non-BDB codebases to implement (Namecoin Core does it despite using LevelDB).
Anyway -- the BDB lock limit does change the transaction fee incentives compared to a block size limit. For example, the BDB lock limit increases the fees for aggregating transactions, and also increases the fees for name transactions, compared to a block size limit.
Is that good or bad? Well, that's debatable. Increased fees for aggregating transactions could be good for the DoS reasons that Cassini suggested, or it could be bad because it incentivizes bloating the UTXO set. Increased fees for name transactions could be good because it disincentivizes squatting, or it could be bad because it means currency transactions have an advantage over name transactions even though we're aiming to be used for name transactions.
It is definitely true that anti-DoS and anti-squatting policies should ideally be enforced by policies other than the BDB lock limit. The lock limit isn't a clean way to handle this. However, given that we do not have clear information or consensus at this time for exactly what the block size limit, anti-DoS, and anti-squatting policies should be, I do not think it is a good idea to change this consensus rule at this time, particularly given that the current rule is not hurting anything and the lock limit is not anywhere near being reached.
Another issue occurs to me here. The BDB lock limit checks for the Namecoin transaction version. This behavior changes in the AlwaysAuxpowActive hardfork because the Namecoin transaction version is no longer required. It's unclear to me how to deal with that for the purposes of the BDB lock limit. Maybe check the scriptPubKey of each output for a valid name opcode instead of checking the transaction version. Unfortunately, this becomes increasingly complex, which is problematic because the intention of my suggestion to leave the BDB lock limit in place was partially to decrease the complexity of the needed changes.