search

namecoin / namecoin-legacy

Legacy client. New version here: https://github.com/namecoin/namecoin-core Note the release branch! - Official website:
https://namecoin.org
MIT License
448 stars 177 forks source link

Multiple name_update outputs per transaction #183

Open JeremyRand opened 10 years ago

JeremyRand commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

JeremyRand commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 9 years ago

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.