Multiple name_update outputs per transaction

[JeremyRand]

As referenced in https://github.com/namecoin/namecoin/issues/182#issuecomment-56476817 , I think we should allow multiple name_update outputs per transaction. The major use case I see here is atomic trading of more than one name, although it also grants slightly better efficiency. @domob1812 says this would be a hardfork.

[JeremyRand]

It's also worth pointing out that this can be a privacy leak, since it establishes that two names have a common owner. I don't see a problem with this, but I don't think this behavior should be the default.

[phelixbtc]

I suggest we push this principally good idea back on the stack as has limited benefit but complicates things and costs resources.

[JeremyRand]

@phelixbtc It would be a good idea to implement this next time we're doing a hardfork, since the fewer hardforks the better. Other than that, I have no objection to delaying this.

[domob1812]

I also think this is a useful feature, but nothing of high priority. It is not exactly trivial to implement, either, since the existing code assumes that we can find a single name output for each name transaction in quite some places (IndexOfNameOutput). But still easily doable if we want it.

[JeremyRand]

One other use case that occurs to me. If a name has two JSON fields which are dependent (i.e. changing one will cause undesired effects in the other), and the name is split in two using "import" (e.g. for cold storage or permissions reasons), then it is safer to update them both atomically. The privacy leak isn't really a problem in this use case, since it is already public knowledge that they are owned by the same entity.

Being able to assume that related names can be updated atomically would simplify the fingerprint proposal that I'm working on.

[JeremyRand]

I think this discussion should be continued in the meta repo since it's a protocol issue rather than specific to the namecoind/Namecoin-Qt code. Is that okay with everyone?

[JeremyRand]

Actually this might belong in the Namecore repo now that it exists. Except that the Namecore repo doesn't have issue tracking enabled. @domob1812 @phelixbtc is it intentional that Namecore doesn't have issues?

Also, another use case -- this would allow CoinJoin for names. While it wouldn't break links between name coins (since the name would still be the same), it would produce extra linkage that would potentially hide atomic name trades.