I agree. There is no perfect solution in this aspect.biolizard89 wrote: I said this via PM, but I'll say it here for anyone who didn't receive that. If encryption is added, I think collision detection should be made optional. d/ and id/ names will typically be queried with collision detection turned on (so that any duplicate d/ names which were registered don't have any effect on .bit). Torrent tracking would have collision detection disabled. This basically is equivalent to a Bitmessage chan (anyone who knows the chan name can access all content within that chan), except with the persistence and editing capabilities of Namecoin. Here's how I view that being used in practice: a torrent community of some kind can choose a shared name, which could be anything from a name of a group "torrent/wikileaks" to an interest area "torrent/movies". Anyone with the name can access all content within that name (much like anyone who knows the URL of The Pirate Bay can access all of its content). The key is that the miners and the users who don't use a particular name aren't able to see its contents, which gives them plausible deniability with respect to "knowingly facilitating infringement".
It occurs to me that collision detection may be useful even in these cases to avoid impostor torrents. So, how about this proposal: the portion of a name which appears after the 2nd forward slash will be encrypted using the rest of the name as the key, and values are also encrypted with that key. Collisions are still prevented as currently. Example:
Full name: "torrent/wikileaks/insurance2010"
Full value: "magnet:xyz"
Stored in blockchain as:
Name: hash("torrent/wikileaks/") CONCAT encrypt(data="insurance2010", key="torrent/wikileaks/")
Value: encrypt(data="magnet:xyz", key="torrent/wikileaks/")
This allows only anyone who knows the name portion "torrent/wikileaks/" to see all the names which start with that, while maintaining name collision detection. This is basically as private or public as people want, in that you can choose a guessable or nonguessable 2nd-level namespace (what I'm calling the portion before the 2nd forward slash). But it allows miners and other entities handling the blockchain to legitimately argue that they don't know what's in their blocks.
But law is based on formalities. The deputies are voting a law to show they took measures and they have done their work(even if sometimes it doesn't bring anything).
We can do also the best what is possible. Than we can show that we have done our best. The users and miners will also have additional protection with the encrypted values.
The network should be protected if comply with legal requirements.
If values are encrypted it is a plausible deniability argument for not involved users.
The responsibility should be completely on the those who are making the name entries.
Hiding value fields from search engines is also useful in this aspect.(Khal)
Making such small changes (which apparently doesn't bring very much) could be the difference between legal and illegal.
I think this should be the basic idea. But encryption shouldn't make Namecoin unusable or hamper it.
This is also a good idea.moa wrote:It has been discussed several times on IRC is only place I know of.
Several features ;
- storage of magnet links http://en.wikipedia.org/wiki/Magnet_URI_scheme in the blockhain making direct verifable look-ups possible, since file hash is the link
- magnet links provided by a specific NMC_ADDRESS could incorporate some kind of financial reward (donations) scheme using nmc payments to the link providing address ... and reputation of known good NMC_ADDRESS in providing reliable magnet links can be accrued
- other more complex variations on above points
Combining value field encryption with the possibility to request reward/payment for the revealing value fields (for ex. magnet links) based on id/ reputations would not only protect the network but would also strengthen the internal NMC based economy. Such deals inside of the network could have a network fee.
