Soft Hard Name Fork

[JeremyRand]

As we all know, softforks are safer and less disruptive than hardforks, meaning that:

1. Changes should be implemented as softforks when feasible.
2. Hardforks should be avoided unless necessary.
3. When hardforks are necessary, it's wise to roll as many uncontroversial changes into a single fork event as possible.

I've been looking at the fork wishlist. That wishlist was compiled from grepping the forum and GitHub for "hardfork" and "softfork". I think it's close to complete.

I notice that most of the hardforks on the list only involve name transactions. Luke-Jr told me recently about a "soft hardfork", in which clients who haven't upgraded see a valid blockchain with full hashrate, but the blocks have no transactions. I was thinking about whether we can do something similar to do arbitrary changes to the name system such that old clients don't get kicked off the chain.

So let's say that we wanted to change the behavior of the name opcodes in some way. This could be any of the following:

1. Changing expiration behavior.
2. Making a name field be a hash of a name rather than the cleartext name.
3. Allowing operations for multiple names per transaction.
4. Changing name pricing rules.
5. Anything else that only occurs as a result of the presence of a name opcode.

And let's say that we wanted this to be a softfork. Consider this mechanism, which becomes enforced at softfork activation:

1. NAME_NEW outputs are now considered invalid.
2. All NAME_FIRSTUPDATE and NAME_UPDATE outputs must have an address script of OP_RETURN.
3. A new opcode is defined: OP_NAME_MIGRATE_2.
4. OP_NAME_MIGRATE_2's semantics are identical to the pre-fork behavior of OP_NAME_UPDATE (except as specified herein).
5. OP_NAME_MIGRATE_2 is invalid unless it appears in a transaction that also includes an OP_NAME_FIRSTUPDATE or OP_NAME_UPDATE for the same name. (As a correlary, OP_NAME_MIGRATE_2 appearing in the same transaction as a pre-fork name opcode is not invalid.)
6. 3 new opcodes are defined: OP_NAME_NEW_2, OP_NAME_FIRSTUPDATE_2, and OP_NAME_UPDATE_2; herein referred to as "v2 name opcodes"
7. v2 name opcodes have identical semantics to their corresponding pre-fork name opcodes (except as specified herein).
8. OP_NAME_FIRSTUPDATE_2 must spend OP_NAME_NEW_2, not the v1 OP_NAME_NEW.
9. OP_NAME_UPDATE_2 must spend OP_NAME_FIRSTUPDATE_2, OP_NAME_UPDATE_2, or OP_NAME_MIGRATE_2, not the v1 OP_NAME_FIRSTUPDATE or OP_NAME_UPDATE.
10. The behavior of the naming system (i.e. the conditions under which name opcodes cause a transaction to be invalid, and the results returned by the name_show RPC call) is redefined according to arbitrary new rules.

Pre-fork clients don't consider the new opcodes to be name opcodes; they therefore consider scriptPubKeys that contain them to be currency transactions (with some useless data pushed to the stack and then immediately dropped). As a result, pre-fork clients will see the following as a result of the softfork:

1. Existing names slowly become unspendable as they are transferred to OP_RETURN addresses.
2. Name transactions (other than transactions that transfer a name to OP_RETURN) never are relayed or confirmed (except by nodes and miners who have failed to upgrade; any blocks mined by such miners will be orphaned).

Critically, the existing naming semantics are not enforced by old clients against name transactions issued after the softfork, because the post-softfork name transactions look like currency transactions to old clients. That means the softfork can change basically anything about the behavior of the naming system.

Why is this better than a traditional hardfork?

1. Currency users do not need to upgrade if they're okay with semi-SPV security.
2. Pre-fork users can't be fed a malicious chain by someone with low hashpower, because the post-fork chain is still considered valid.

Is this concerning?

1. Maybe it should be extremely difficult to change the behavior of the naming system, and maybe this is easier than it should be?
2. I don't think that's really an issue. If end users wanted to actively reject blocks with the changed name semantics, they could implement their own softfork that rejects any transaction with any of the new opcodes.
3. Miners are unlikely to mine blocks according to rules that the end users are against.

Thoughts on this? Are there attacks here that I'm not thinking of?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/37161012-soft-hard-name-fork?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github).

[domob1812]

I've not yet read through all the details, but this sounds to me like the same thing that segwit is doing for being a softfork rather than hardfork. Sounds like a nifty idea, but I wonder if the supposed benefit is really worth the complexity all of that adds. Given that I'm basically the only maintainer of the core consensus code and I'm not even working fulltime on this (far from it), I think that this is also something we should keep in mind - and something that clearly shifts our situation with respect to decisions made for Bitcoin, which has at least some fulltime developers working on it.

[JeremyRand]

I've not yet read through all the details, but this sounds to me like the same thing that segwit is doing for being a softfork rather than hardfork.

Quite similar in concept, which is probably because both the SegWit softfork and the Soft Hard Fork were created by Luke-Jr -- this is sort of his signature style, I just adapted it to name transactions.

Sounds like a nifty idea, but I wonder if the supposed benefit is really worth the complexity all of that adds. Given that I'm basically the only maintainer of the core consensus code and I'm not even working fulltime on this (far from it), I think that this is also something we should keep in mind - and something that clearly shifts our situation with respect to decisions made for Bitcoin, which has at least some fulltime developers working on it.

My main motivation for thinking about this is that a lot of the proposed name improvements are hardforks, and it seems preferable to avoid hardforks when feasible. Particularly given that I'd rather not roll a lot of stuff into AAA, and it's unclear that we'll have another chance to hardfork for a while. So basically, the 2 options I was pondering were (1) try to roll more into AAA, or (2) not roll more into AAA, and instead do this method later when we're ready, on our own schedule. :) This basically gives us a way out so that we don't need to choose between delaying AAA and scheduling another disruptive hardfork.

It occurs to me that the script versioning system in SegWit, or the hardfork signaling in Luke's merged mining BIP, could plausibly be hijacked in order to do something vaguely equivalent to this, but it's unclear to me if that's a good idea, since script versioning isn't usually supposed to touch a global state that affects multiple script versions, and hardfork signaling would usually result in currency transactions being invisible too. (We could hack around that, I suppose, but defining new name opcodes seems simpler and less risky at that point.)

[xochipilli]

I think HF bitcoin and HF namecoin is a completely different matter. The difference is about 1:2000. Such a small coin can afford to HF and use this advantage to create a better design than hacking a workaround on top of the current protocol.

[JeremyRand]

xochipilli:

I think HF bitcoin and HF namecoin is a completely different matter. The difference is about 1:2000. Such a small coin can afford to HF and use this advantage to create a better design than hacking a workaround on top of the current protocol.

I don't think that Namecoin's smaller status necessarily implies that it's safe to hardfork. On one hand, there are fewer stakeholders who need to be convinced to upgrade, which probably makes hardforks easier to do safely. On the other hand, many Namecoin users probably have less self-perceived stake in Namecoin, and it may be more difficult to convince them to upgrade. The largest NMC holder is believed to be the btc-e cold wallet, and last time we tried to contact btc-e about a fairly high-priority issue, crickets. Not to mention that many users haven't had any luck contacting squatters to negotiate buying a name.

I've talked to a number of Bitcoin people who are much more knowledgeable about this stuff than I am, and while they're basically in agreement that AAA needs a hardfork, they also think that for non-critical things, softforks are still substantially safer for Namecoin than hardforks are.

Cheers.