Decrease SegWit weight limit compared to Bitcoin

[JeremyRand]

SegWit increases the effective block size limit of Bitcoin by setting a weight limit of 4 MB. For the reasons outlined in https://github.com/namecoin/meta/issues/45, I don't think this is a good idea for Namecoin short-term. I suggest that we set the SegWit weight limit to 1 MB when we softfork for SegWit, and specify a sunset date (let's say 1 year after the softfork date) at which point the weight limit increases to 4 MB. If needed, the 1 MB weight limit can be renewed by an additional softfork prior to the sunset date.

A 1 MB weight limit means that the block size will usually be under 500 kB, assuming typical Bitcoin-like transaction usage. Name transactions have a larger fraction of non-witness data, so the average block size will end up a little bit lower. Therefore it's a slight decrease compared to the typical size currently imposed by the BDB lock limit, but is still much, much larger than the real-world block size that we're seeing in Namecoin today.

[JeremyRand]

@domob1812 Thoughts on this?

[domob1812]

In principle (as stated on #45), I'm fine with lowering the block size. What exactly are you proposing here - to set the max block weight to 1,000,000 rather than 4,000,000? I.e. also decrease the block size during the softfork? I think we can do that; it would still be a softfork, and it won't really matter for Namecoin anyway.

[JeremyRand]

What exactly are you proposing here - to set the max block weight to 1,000,000 rather than 4,000,000? I.e. also decrease the block size during the softfork?

Yes, that's correct.

[JeremyRand]

(But also, as part of the softfork, set a date when the max block weight increases to 4,000,000. I'd suggest 1 year after the softfork activation date.)

[domob1812]

Automatically increasing the block weight back to 4,000,000 at a later date would still make it a hard fork. (Although one that would not break clients that never updated in between.) I would suggest to just lower the weight to 1,000,000 in the soft fork and leave it there for now - that is after all still much more than actually necessary and won't have any impact in practice.

If we then want to increase the size again, we can do it together with the AAA hard fork. But at the moment, I think even just keeping the max weight at 1,000,000 is probably fine for Namecoin.

[JeremyRand]

Automatically increasing the block weight back to 4,000,000 at a later date would still make it a hard fork. (Although one that would not break clients that never updated in between.)

I'm not sure I follow. A weight limit of 4,000,000 is a softfork relative to the current rules, as is a weight limit of 1,000,000. As long as 100% of clients that are aware of the 1,000,000 limit softfork (which applies for 1 year) are also aware of the 4,000,000 limit softfork (which applies starting 1 year later), I don't see how any hardfork is occurring. The only prerequisite is that the Namecoin Core release that introduces the 1,000,000 limit softfork also needs to automatically change the limit to 4,000,000 one year after the 1,00,000 limit is activated.

[domob1812]

Ah yes, good point, that is true. Anyway, I don't quite get your original motivation for this "sunsetting": If you believe that 4,000,000 is too large as a weight limit, then why do you think it would no longer be too large a year later?

I fully agree with your point that Namecoin blocks are almost empty and actually have a smaller limit right now due to the BDB lock limit - so if you feel uncomfortable with 4,000,000 as a weight limit, we should just go to 1,000,000 without the planned increase. If it turns out that we do get full blocks at some point in the future, we can always evaluate an increase back to previous levels with the proper care.

[JeremyRand]

Anyway, I don't quite get your original motivation for this "sunsetting": If you believe that 4,000,000 is too large as a weight limit, then why do you think it would no longer be too large a year later?

The main reason is that softforks are a lot easier and less disruptive to pull off than hardforks. My expectation is that we would renew the 1,000,000 weight limit with another softfork (before the 4,000,000 limit would be scheduled to take effect), and that we would probably renew the 1,000,000 limit for at least several years. The sunset is basically an "escape valve" in case Namecoin becomes wildly popular and we run into issues with blocks being full and fees being way above 10 USD per update. I don't think we're going to run into that situation for a long time, but if/when we do, it's much easier to deal with it by choosing not to renew the 1,000,000 weight limit and letting the sunset take effect, rather than having to deploy a hardfork.

[domob1812]

To be honest, I don't think that a repeated series of soft forks is "a lot easier and less disruptive" than one hard fork in the unlikely event that we need it. We've been planning forks now for years, and not pulled of either a soft fork or a hard fork.

I believe that a hard fork is not too bad if we really need it in an unlikely case; Namecoin is much smaller than Bitcoin, and if the case is really clear, there won't be much controversy. (Of course, things would be different if we would expect to need the larger size in the future - but as the most likely situation is that we won't need it, I don't think we should create a series of soft forks just to avoid that one, unlikely hard fork. Especially as the general plan is to decrease block size rather than increase it.)

[domob1812]

Now that https://github.com/namecoin/namecoin-core/issues/258 is fixed, this is the only remaining issue for enabling segwit as far as I can tell. @JeremyRand, what is your current take on this? I believe that this is likely irrelevant in practice and mostly making things more complicated. Do you still think we really need to do this before enabling segwit?

[domob1812]

@JeremyRand: Any update here? As stated before, I think we should't really do such a "timed change" to the block weight. IMHO, we should just stick to Bitcoin - the size limit there is conservative, so it would be fine for Namecoin as well; even though it is likely not going to be used for the time being anyway.

But if you think that 1 MB + Segwit is too large, then we should just reduce the size to whatever you think is a good one. However, I don't think reducing the size now and letting it go back up later is a good idea - why would 1 MB + Segwit be too big right now but fine in a year? Either it is fine now or it isn't, IMHO.

[JeremyRand]

@domob1812 Sorry for the delayed reply on this, I was checking with Luke to see what his take is. Luke thinks hardforks are sufficiently difficult and disruptive to pull off that it's generally preferable to leave the option to restore the 4M weight limit without doing a hardfork. He suggests putting a Unix timestamp in the chain params (signifying a sunset date for the lower weight limit), and bumping it periodically. He points out that this bump could be done by default every time a release is tagged, which works fine as long as the miners are willing to upgrade to the new tag before the previous tag's subset date is reached. AFAIK the Namecoin miners have expressed a willingness to upgrade within 3 months, so a 1-year sunset period should work fine here. (Luke says a 2-year sunset period is what he'd usually go with for Bitcoin. I don't feel particularly strongly on whether a 1-year or 2-year sunset period is preferable; feel free to give feedback on that detail.)

I continue to believe that we should drop the weight limit to 1M (down from Bitcoin's 4M) when activating SegWit, for the reasons I've stated earlier. I also think that it should sunset, because the lower weight limit has tradeoffs, and the effect of those tradeoffs can vary over time. At the present-day usage levels, it's pretty clear that a 1M weight limit (or even a 256k weight limit) won't cause problems. However, if usage levels of Namecoin increase significantly, we could end up with a situation where blocks get full and transaction fees get a lot higher than they are now. If renewing a Namecoin name costs a lot more than, say, a few USD (which was a transaction fee that was seen in the wild in Bitcoin for a few months prior to Bitcoin raising the effective block size limit via SegWit), then that presents a UX issue that I think would merit a discussion about whether the weight limit should be raised. My preference would be to adopt other scaling mechanisms first, such as switching from JSON to CBOR (similarly to how Bitcoin adopted various scaling mechanisms that decreased IBD time before SegWit was activated), but that won't be sufficient on its own if usage levels get high enough. The fact this this situation would arise due to increased usage levels means that it's exactly the type of scenario in which a hardfork is a lot more disruptive/difficult than it is now -- more users of a blockchain means a hardfork is much more difficult and disruptive.

That's the summary of my take, let me know if I should elaborate on something or if something doesn't make sense.

[domob1812]

Thanks for the reply! To me, that still seems very hypothetical, to be honest. If you are worried about increased usage in the future, then we can just stick to Bitcoin's limit instead. Bitcoin has proven that it is fine even with full blocks, so the network won't just break down. And unless something changes drastically, it is unlikely to be exercised anyway. (Since we are currently far from full blocks at the non-segwit limit, there is no reason to believe that the higher segwit limit will be reached either.)

But if you really prefer to go for the more complex sunsetting and bumping the cutoff time every release, we can do it. Just note that this is effectively a softfork on every release (although an uncontroversial) one - and we've been going on for years now for doing a softfork.

Do we have any other opinions here? @cassiniNMC, @brandonrobertz, @phelixbtc, @xaya

[xaya]

Hi. I'm not entirely sure I understand.

are we concerned that in the future blocks might get full? (but they might not?)

if they are getting full in the future then i guess everything is doing good and we could organise a fork then? (miners and everyone are probably more interested in listening?)

If there is some 2 year wait (pre-coded) for a block size increase - will that then be an issue if they start getting full in 6 months so we need to do another change?

or the 2 year wait a "sort of" giving everyone a chance to upgrade during that time?

or did i misunderstand it

[domob1812]

Let's try to get this done for 0.18; else it will be going on forever.

I'm still not in favour of changing the weight limit, especially not with the sunsetting thing. The two main reasons why I don't like it:

1. It complicates the code. Currently, we have a simple constant MAX_BLOCK_WEIGHT. That would have to be replaced by a function depending on the block context, introducing extra diffs to Bitcoin (especially also in the various regtests).
2. Having a sunsetting period and shifting it forward basically means that we do a softfork on every release.

The first point is just minor, but 2) is a big thing, IMHO. We've not managed to do the segwit softfork for years. With the sunsetting built in (and meant to be shifted forward over time), we would need to make sure that miners and (ideally) exchanges update twice a year (or how often we do a release / shift the sunsetting). That seems like a big cost to me.

For these drawbacks, I also simply do not see the advantage. Blocks are not full now, and most likely won't be in the forseeable future. So any weight limit is just a theoretical thing. And even if somehow magically blocks became filled up, then Bitcoin's limit is still good enough to prevent a network collapse. I can run Bitcoin Core on my six-year-old laptop just fine with full blocks.

And even if we really want to reduce the block size (which I'm not totally against), then the reason for having the extra complication of the sunsetting is even more hypothetical. Should blocks fill up and should we need to increase the block size, then I'm sure we can do a hardfork once to solve that. In case that fork would be controversial in the community, then also the sunsetting won't help - because if someone wanted to keep small blocks while someone else decided to let the sunsetting run out, then those people could simply implement a hard fork on their own to stick to their agendas; the sunsetting can't prevent that.

All that said, I'm voting for just keeping the block weight as it is in Bitcoin Core.

[JeremyRand]

@domob1812 It's definitely true that our release workflow has been subpar in the "pushing out release binaries regularly" department for the last few years. What would you think about the following routes:

1. Decrease the weight limit, make the limit sunset 2 years later (without any further extensions of the sunset), and figure out what to do longer-term later (maybe 2 years from now we'll have a better release workflow that makes it easier to extend a sunset, or maybe there will be other considerations that affect what we should do).
2. Leave the weight limit at the Bitcoin level for the SegWit activation softfork date, spend some Namecoin resources (e.g. NMDF funds) on improving the Namecoin Core release workflow (possibly including getting the name tab merged to master -- the reason I haven't touched that code lately is that no funding is allocated to it), and then once the release workflow is at a point where we actually push out releases on a regular basis (ideally synced with Bitcoin Core's release schedule), then look into decreasing the weight limit and figuring out whether sunsetting is feasible.

There is currently at least one user who is abusing the Namecoin blockchain as a microblogging service, so I definitely want to decrease the weight limit in order to make that kind of abuse more expensive. But, at the same time, I think spending too much time worrying about the weight limit and sunsetting is a bad idea if it's actively competing with spending effort on merging SegWit (which is important to do in order to keep the code maintainable) and merging the name tab (which is also important for the same reason). So, I'm okay with deferring the weight limit discussion until after the release workflow and name tab are properly in order, as long as everyone involved understands that this doesn't mean I'm agreeing with keeping the weight limit at Bitcoin levels long-term.

[domob1812]

Thanks for your input! My personal preference is 2), i.e. just keeping the weight limit at Bitcoin's for now. With that, we can simply schedule segwit right away by setting the fork height. I can't speak for allocating NMDF resources towards the name-tab work, but I think that's good use for them so I won't NACK it.

But I'm also fine with decreasing the weight limit without sunsetting if you and others think that's needed.

[JeremyRand]

Okay, let's keep the Bitcoin weight limit for the initial SegWit softfork, and we'll return to the discussion about possibly lowering the weight limit (and possibly sunsetting it) after the Namecoin Core release workflow is in better shape. If for some reason the weight of real-world Namecoin blocks climbs too high, I might want to revisit this sooner, but my prediction is that that isn't likely to happen.

[domob1812]

Sounds good. As stated, I'm definitely happy to decrease the weight limit, especially if it turns out to be relevant in practice soon (which I personally doubt, but we will see).