Hardfork Wishlist

johnc
Posts: 89
Joined: Sun Dec 28, 2014 10:03 am

Hardfork Wishlist

Post by johnc »

How about a hardfork wishlist.

I will start...
make domain names last a year instead of 36000 blocks, make it 52596 blocks that's 365 days and 6 hours (to take into account leap years that happen every 4years)

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: merged mining v2, MM2

Post by domob »

johnc wrote:How about a hardfork wishlist.

I will start...
make domain names last a year instead of 36000 blocks, make it 52596 blocks that's 365 days and 6 hours (to take into account leap years that happen every 4years)
Well, I'd say this is an atleast somewhat controversial change. But I suggest to do these changes in addition:
  • Enable BIP16 and possibly also BIP30 (although that is mostly irrelevant now BIP34 is active).
  • Remove the temporary lock limit put into place to avoid the BDB-lock-issue that forked Bitcoin in March 2013. This is a hardfork but not really problematic in any case.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Hardfork Wishlist

Post by phelix »

Fix the value size bug (1024 bytes) or even increase the value size to 2,5k as discussed earlier (this does not really make flooding any easier but will simplify some legit use).
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Hardfork Wishlist

Post by biolizard89 »

Changing the name registration period is certain to be controversial, because I NACK that particular new period (my inclination is 13 months to renew but 12 months to resolve, but more discussion is needed before I will be confident that that is optimal). Daniel has suggested using block timestamps instead of block height for this; again, this needs more discussion before I will be confident in such a proposal.

Changing the value size is also certain to be controversial, as I am not convinced that it will be a net benefit (possibly bad for scalability, also possibly bad in terms of making harmful use cases easier). Again, I'd like to see more discussion, and more hard data, before making such a decision.

BIP 16 and BIP 30 seem uncontroversial. ACK on those from me.

The BDB lock limit was effectively a block size limit, correct? Removing it would raise our block size limit to the same as what Bitcoin Core now has. It is not immediately clear to me what the implications of this would be. Chinese miners seem to be having no trouble with 1 MB Bitcoin blocks (but we should probably ask wangchun if 1 MB Namecoin blocks will be problematic, just to make sure). Right now our blocks are not congested as far as I know. If transaction volume increases, then the existence (or lack thereof) of the lock limit may have an effect on the fee market. Anyone else have opinions on this?

It's worth pointing out that the BIP 9 hardfork should not have anything that any users will consider controversial, because we want everyone to adopt it without delay. Any controversial changes should be rolled out on a later schedule without risking the BIP 9 hardfork's quick adoption.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

johnc
Posts: 89
Joined: Sun Dec 28, 2014 10:03 am

Re: Hardfork Wishlist

Post by johnc »

We can discuss 365 or 366 days with a week grace period after that to renew the domain like most domain registrars do. I think everyone is open to that.

About increasing the size, i guess fees/kb could pay for that, but it's not so important. We really don't want people storing data onchain apart from server ip, email, btc address and PGP keys. It is my opinion than id data should be hashed and stored offchain by the user directly on bittorrent, this is not facebook, it shouldn't be so difficult to make a url that opens your bittorrent client when you click it on a blocksplorer like magnet:ASDFG .

About the blocksize limit... what a wonderful problem to have, if we ever have it.
As merged mined becomes mandatory, we are basically running on top of bitcoin. Namecoin data is actually being stored in a hash form on the bitcoin chain. Again, IMHO i would like an algorithm to decide that but i know that may not scalate and it is a problem of updating the whole block-storage system.

Bitcoin will always have a bigger problem with the blocksize than NMC, so the solution will be the same. It is possible than in the future bitcoin data will be stored on the blockchain in the same way that NMC is, by merkle trees but instead of altcoins made of sub-blocks of tx.

Last, about the fees, it is the same problem than BTC with the blocksize again, we need either an algorithm to decide it or a benevolent dictator to change it.

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Hardfork Wishlist

Post by phelix »

biolizard89 wrote: Changing the value size is also certain to be controversial, as I am not convinced that it will be a net benefit (possibly bad for scalability, also possibly bad in terms of making harmful use cases easier). Again, I'd like to see more discussion, and more hard data, before making such a decision.
The limit was never meant to be 520 bytes. It is a bug and we should take this opportunity to at fix it. There is an optimum value size to balance scattering entries through a lot of "import"s and currently we are below it. Half of what was planned up front. The onename people said so, too, they struggled with their "next" construct. Fixing the limit is virtually no effort but if it helps the project a tiny bit to gain traction by simplifying existing and maybe allow new use cases it will well be worth it.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Hardfork Wishlist

Post by biolizard89 »

phelix wrote:
biolizard89 wrote: Changing the value size is also certain to be controversial, as I am not convinced that it will be a net benefit (possibly bad for scalability, also possibly bad in terms of making harmful use cases easier). Again, I'd like to see more discussion, and more hard data, before making such a decision.
The limit was never meant to be 520 bytes. It is a bug and we should take this opportunity to at fix it. There is an optimum value size to balance scattering entries through a lot of "import"s and currently we are below it. Half of what was planned up front. The onename people said so, too, they struggled with their "next" construct. Fixing the limit is virtually no effort but if it helps the project a tiny bit to gain traction by simplifying existing and maybe allow new use cases it will well be worth it.
The fact that the 1023 is greater than 520 is a bug in Vince's implementation. That has nothing to do with whether the fix is to change 1023 to 520 or vice verse.

The fact that Vince made up the number 1023 doesn't imply that it's optimal, nor that it's better than 520. Vince never documented why he made it that size. He's not around to explain it now. The fact that Vince made up 1023 has zero weight in determining what an optimal value size is.

Figuring out an optimal value size is a complex problem which is likely to require significant discussion and analysis. That discussion and analysis have not happened at this point. Therefore it is completely inappropriate to shove such a fork in with the BIP 9 fork, which we want to be straightforward and uncontroversial.

If you want to start that analysis, make a thread about it.

Also as an aside, I have heard at least one community member criticize Onename for storing as much data in the chain as they did. Onename's i/ namespace is AFAIK just a crappier implementation of the import field. import is not hard to implement if all you want is more storage. The complexity of import is in its security delegation properties, which are irrelevant to this discussion, incompletely specified, and inconsistently implemented.

*fires the on-topic cannon*
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Hardfork Wishlist

Post by phelix »

biolizard89 wrote:
phelix wrote:
biolizard89 wrote: Changing the value size is also certain to be controversial, as I am not convinced that it will be a net benefit (possibly bad for scalability, also possibly bad in terms of making harmful use cases easier). Again, I'd like to see more discussion, and more hard data, before making such a decision.
The limit was never meant to be 520 bytes. It is a bug and we should take this opportunity to at fix it. There is an optimum value size to balance scattering entries through a lot of "import"s and currently we are below it. Half of what was planned up front. The onename people said so, too, they struggled with their "next" construct. Fixing the limit is virtually no effort but if it helps the project a tiny bit to gain traction by simplifying existing and maybe allow new use cases it will well be worth it.
The fact that the 1023 is greater than 520 is a bug in Vince's implementation. That has nothing to do with whether the fix is to change 1023 to 520 or vice verse.
Huh? Cleary the intended value size was 1023. It is quite obvious, it was also in documentation. Just look at Khal's post where he first wrote about it on the forum. BTW he suggests a value size of 9000 bytes in that post.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Hardfork Wishlist

Post by biolizard89 »

Phelix, if you want me to seriously reply to your post, please read mine past the first paragraph. Literally the sentence after you cut off your quote directly answers what you just said. Also, the bottom of my post (which I guess you didn't get to) says this is off-topic for this thread. Thanks.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Hardfork Wishlist

Post by domob »

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.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

Post Reply