Namecoin Torrent tracking

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Namecoin Torrent tracking

Post by virtual_master »

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.
I agree. There is no perfect solution in this aspect.
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.
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
This is also a good idea.
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.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Namecoin Torrent tracking

Post by virtual_master »

I was thinking about some encryption/hashing ideas of the value field but they look to be to complicated, may be only for me.
(Khals idea to scramble the output for search engines with javascript and make only human-readable was simple - I would use this as second layer to the next idea for cases where no search engine entries required)
It came to me a simple idea how to protect innocent users and miners from potentially illegal entries of a 'crazy user'.
By every name entry registration or renewal the client should generate a random number(for each name entry) which will be used to encrypt all value fields of that name entry. for ex d/example
After the name entry is included in a block then the client automatically sends an entry request with fixed size(for ex 20byte) where only the password will be stored. d_/example(in this case d_ entries will be reserved and not usable alone)

The miner when he includes the name entry values in the block doesn't have the password(which will be introduced in a later time), so there is a plausible deniability.
The user is also protected because he doesn't have any plaintext value in his local blockchain and eventually no software which can search the entry-password pairs and decrypt them..
Resolving the names the domain resolver will decrypt it searching the d and d_ pairs and send the browser to the intended page - also not so much risk.

Showing undefined namespace values or known namespaces with undefined specification will be eventually some responsibility of the provider.
The full responsibility will be on side of the user who introduces the value fields.

There is a backside also:
- delayed registration with 1 block(client must wait password entry registration/update)
- services which are running based on name entries could have blackout for the renewal a when namespace entry was renewed but password entry still not updated
This could be eventually avoided if standard value entries with fixed size(for ex IP for .bit domain resolving) is not encrypted.

What do you think about ?
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Namecoin Torrent tracking

Post by biolizard89 »

virtual_master wrote:I was thinking about some encryption/hashing ideas of the value field but they look to be to complicated, may be only for me.
(Khals idea to scramble the output for search engines with javascript and make only human-readable was simple - I would use this as second layer to the next idea for cases where no search engine entries required)
It came to me a simple idea how to protect innocent users and miners from potentially illegal entries of a 'crazy user'.
By every name entry registration or renewal the client should generate a random number(for each name entry) which will be used to encrypt all value fields of that name entry. for ex d/example
After the name entry is included in a block then the client automatically sends an entry request with fixed size(for ex 20byte) where only the password will be stored. d_/example(in this case d_ entries will be reserved and not usable alone)

The miner when he includes the name entry values in the block doesn't have the password(which will be introduced in a later time), so there is a plausible deniability.
The user is also protected because he doesn't have any plaintext value in his local blockchain and eventually no software which can search the entry-password pairs and decrypt them..
Resolving the names the domain resolver will decrypt it searching the d and d_ pairs and send the browser to the intended page - also not so much risk.

Showing undefined namespace values or known namespaces with undefined specification will be eventually some responsibility of the provider.
The full responsibility will be on side of the user who introduces the value fields.

There is a backside also:
- delayed registration with 1 block(client must wait password entry registration/update)
- services which are running based on name entries could have blackout for the renewal a when namespace entry was renewed but password entry still not updated
This could be eventually avoided if standard value entries with fixed size(for ex IP for .bit domain resolving) is not encrypted.

What do you think about ?
I'm in the middle of studying for finals but I'll get back to you on this proposal.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

indolering
Posts: 800
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: Namecoin Torrent tracking

Post by indolering »

I too am dodging a final at the moment but I'd like to get in my two cents. For one, torrents on NMC doesn't make a whole lot of sense. As someone said earlier, this would be a "directory" not a tracker: a tracker coordinates peers in the swarm which means live updating of the information. I know that TPB still has a tracker that comes online when no-one in the DHT swarm is still active, but I can't remember why - it might be for users which don't have access to the DHT.

Regardless, this means that NMC would be a directory, a very expensive and difficult to access directory of torrents that would require spending real, track able money to insert into the block chain. It's a 1% use-case that would most likely draw only the least savory parts of the internet and taint our reputation. There are so many things that need to be done, why anyone focus on this?

However, there is a more legitimate concern here: child porn being stored in the blockchain. This is some tricky legal stuff and I'm trying to pull in real lawyers to answer help us out here but I totally agree with what others have said, we need strict formatting requirements for all fields and any general purpose fields (such as txt) should be definitely be encrypted by default and take up a maximum of 512bytes decrypted so that storing any viable amounts of information in them would be prohibitively expensive to split across entries.
DNS is much more than a key->value datastore.

snailbrain
Posts: 309
Joined: Tue Jul 19, 2011 9:33 pm

Re: Namecoin Torrent tracking

Post by snailbrain »

indolering wrote:I too am dodging a final at the moment but I'd like to get in my two cents. For one, torrents on NMC doesn't make a whole lot of sense. As someone said earlier, this would be a "directory" not a tracker: a tracker coordinates peers in the swarm which means live updating of the information. I know that TPB still has a tracker that comes online when no-one in the DHT swarm is still active, but I can't remember why - it might be for users which don't have access to the DHT.

Regardless, this means that NMC would be a directory, a very expensive and difficult to access directory of torrents that would require spending real, track able money to insert into the block chain. It's a 1% use-case that would most likely draw only the least savory parts of the internet and taint our reputation. There are so many things that need to be done, why anyone focus on this?

However, there is a more legitimate concern here: child porn being stored in the blockchain. This is some tricky legal stuff and I'm trying to pull in real lawyers to answer help us out here but I totally agree with what others have said, we need strict formatting requirements for all fields and any general purpose fields (such as txt) should be definitely be encrypted by default and take up a maximum of 512bytes decrypted so that storing any viable amounts of information in them would be prohibitively expensive to split across entries.
good points.

there are probably a lot of dodgy websites/forums which post or link dodgy material?
Some dodgy data can be stored like it was in bitcoin? (can't remember the story)
I think we are limited in what we can do if people start putting in dodgy data, hopefully it will at least help those sort of people get caught, somehow..
also, what would be the difference between a dodgy torrent and a dodgy .bit domain?

Torrent Tracker-
it would probably be more like eMule?

with pruning, short duration expiry (maybe a lower fee), tipping (increases expiry and tips the address), i think it would be interesting.

but definitely needs more discussion (maybe need to think more on encryption),..

indolering
Posts: 800
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: Namecoin Torrent tracking

Post by indolering »

Some dodgy data can be stored like it was in bitcoin? (can't remember the story)
This is definitely one of the positives we have going for us: the IP address and account information for any Namecoin transaction is publicly available. It's there for anyone to investigate.
I think we are limited in what we can do if people start putting in dodgy data, hopefully it will at least help those sort of people get caught, somehow..
also, what would be the difference between a dodgy torrent and a dodgy .bit domain?
That's just linking information to the domain, not the actual material itself. One of Freenet's (many) problems is the creep factor of holding potentially disgusting things on your hard drive. But you are right, linking can be construed as "assisting" and we have to work hard to stay on the non-assisting side of the line.

Like you said, there will always be bad stuff on the web but I'm hopeful that we can reach a high enough ratio good/bad ratio to have a positive impact on the world.
Torrent Tracker-
it would probably be more like eMule?
I don't know much about eMule's architecture.
with pruning, short duration expiry (maybe a lower fee), tipping (increases expiry and tips the address), i think it would be interesting.
I'm hopeful.
DNS is much more than a key->value datastore.

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Namecoin Torrent tracking

Post by phelix »

indolering wrote:
Some dodgy data can be stored like it was in bitcoin? (can't remember the story)
This is definitely one of the positives we have going for us: the IP address and account information for any Namecoin transaction is publicly available. It's there for anyone to investigate.
No, most of the time you will only get the IP address of a relaying node and you can never know if you got the right one.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

indolering
Posts: 800
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: Namecoin Torrent tracking

Post by indolering »

phelix wrote: No, most of the time you will only get the IP address of a relaying node and you can never know if you got the right one.
That's what I get for hastily reading industry "white papers"!
DNS is much more than a key->value datastore.

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Namecoin Torrent tracking

Post by phelix »

namecoind name_show btm/testing
{
"name" : "btm/testing",
"value" : "magnet:?xt=urn:btih:e940a7a57294e4c98f62514b32611e38181b6cae&dn=archlinux-2013.01.04-dual.iso&tr=udp://tr
acker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce",
"txid" : "ace635278ee4220a5cfa6229109749ffc5056160692553ddf620171daa8fbf35",
"address" : "N8XjcwMM5UU1UCSACYfbERgMuHkSpJB9eU",
"expires_in" : -44196,
"expired" : 1
}

Back then I could download the file via that link. Not sure whether all of it is necessary at all.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

domob
Posts: 1127
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Namecoin Torrent tracking

Post by domob »

phelix wrote:namecoind name_show btm/testing
{
"name" : "btm/testing",
"value" : "magnet:?xt=urn:btih:e940a7a57294e4c98f62514b32611e38181b6cae&dn=archlinux-2013.01.04-dual.iso&tr=udp://tr
acker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce",
"txid" : "ace635278ee4220a5cfa6229109749ffc5056160692553ddf620171daa8fbf35",
"address" : "N8XjcwMM5UU1UCSACYfbERgMuHkSpJB9eU",
"expires_in" : -44196,
"expired" : 1
}

Back then I could download the file via that link. Not sure whether all of it is necessary at all.
I think the more important aspects are searching for keywords and listing available Torrents. This is the main use of TPB, IMHO.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

Post Reply