Blockchain-based torrent tracker?

[Blazr]

I'm wondering if this would be possible, an alt-currency that stored torrent magnet links in the blockchain?

Would anyone be interested in something like this? Seems like a pretty cool idea to me.

[K1773R]

I'm wondering if this would be possible, an alt-currency that stored torrent magnet links in the blockchain?

Would anyone be interested in something like this? Seems like a pretty cool idea to me.

there was already somewhere a similiar post (TPB as blockchain) and yes thats a nice idea

[crazy_rabbit]

I'm wondering if this would be possible, an alt-currency that stored torrent magnet links in the blockchain?

Would anyone be interested in something like this? Seems like a pretty cool idea to me.

Seems like the only trick would be to encode magnet links- they are quite long. Perhaps you could break it across several transactions? TRC would be perfect to try this out on- especially since BTCers would cry holy hell about abusing the blockchain for this. It's a great idea though- how would you do the encoding?

[K1773R]

I'm wondering if this would be possible, an alt-currency that stored torrent magnet links in the blockchain?

Would anyone be interested in something like this? Seems like a pretty cool idea to me.

Seems like the only trick would be to encode magnet links- they are quite long. Perhaps you could break it across several transactions? TRC would be perfect to try this out on- especially since BTCers would cry holy hell about abusing the blockchain for this. It's a great idea though- how would you do the encoding?

why not testing it in a testnet? or abuse IOC (very low diff)

[crazy_rabbit]

I'm wondering if this would be possible, an alt-currency that stored torrent magnet links in the blockchain?

Would anyone be interested in something like this? Seems like a pretty cool idea to me.

Seems like the only trick would be to encode magnet links- they are quite long. Perhaps you could break it across several transactions? TRC would be perfect to try this out on- especially since BTCers would cry holy hell about abusing the blockchain for this. It's a great idea though- how would you do the encoding?

why not testing it in a testnet? or abuse IOC (very low diff)

Sure- but aren't alt-coins just psuedo-testnets of bitcoin anyway? It's not like we're talking about actually changing the protocol, just finding a way to embed trackers into It. Shouldn't break anything. I mean, TRC would be perfect because why not? People are mining it, people are kinda useing it, and it's based on bitcoin. Not much is done on the test network, and you certainly wouldn't get the same level of involvement as using it on a live network.

[K1773R]

I'm wondering if this would be possible, an alt-currency that stored torrent magnet links in the blockchain?

Would anyone be interested in something like this? Seems like a pretty cool idea to me.

Seems like the only trick would be to encode magnet links- they are quite long. Perhaps you could break it across several transactions? TRC would be perfect to try this out on- especially since BTCers would cry holy hell about abusing the blockchain for this. It's a great idea though- how would you do the encoding?

why not testing it in a testnet? or abuse IOC (very low diff)

Sure- but aren't alt-coins just psuedo-testnets of bitcoin anyway? It's not like we're talking about actually changing the protocol, just finding a way to embed trackers into It. Shouldn't break anything. I mean, TRC would be perfect because why not? People are mining it, people are kinda useing it, and it's based on bitcoin. Not much is done on the test network, and you certainly wouldn't get the same level of involvement as using it on a live network.

dunno how TRC reacts to non standart TX's, but i guess same as BTC, u would have to mine the blocks with these TX's urself, and I0C with a diff of 24 atm is much better (less hashing power needed). altough I0C is mostly dead so nobody would care if it would break something internally.

[crazy_rabbit]

I'm wondering if this would be possible, an alt-currency that stored torrent magnet links in the blockchain?

Would anyone be interested in something like this? Seems like a pretty cool idea to me.

Seems like the only trick would be to encode magnet links- they are quite long. Perhaps you could break it across several transactions? TRC would be perfect to try this out on- especially since BTCers would cry holy hell about abusing the blockchain for this. It's a great idea though- how would you do the encoding?

why not testing it in a testnet? or abuse IOC (very low diff)

Sure- but aren't alt-coins just psuedo-testnets of bitcoin anyway? It's not like we're talking about actually changing the protocol, just finding a way to embed trackers into It. Shouldn't break anything. I mean, TRC would be perfect because why not? People are mining it, people are kinda useing it, and it's based on bitcoin. Not much is done on the test network, and you certainly wouldn't get the same level of involvement as using it on a live network.

dunno how TRC reacts to non standart TX's, but i guess same as BTC, u would have to mine the blocks with these TX's urself, and I0C with a diff of 24 atm is much better (less hashing power needed). altough I0C is mostly dead so nobody would care if it would break something internally.

I think it depends on how you do it. I don't see why you couldn't find a way to make standard transactions that do include magnent links somehow (or strings of transactions that combine to embed links).

[markm]

Isn't this the kind of thing namecoin should work well for?

Put the IP address and port number for your torrent, or for a datafile about the torrent, into the namecoin dataspace?

-MarkM-

[nethead]

then everyone who has the blockchain on their hard drive would be considered criminal (where torrents are illegal)

[crazy_rabbit]

then everyone who has the blockchain on their hard drive would be considered criminal (where torrents are illegal)

not if it was encryped/encoded.

[doublec]

Isn't this the kind of thing namecoin should work well for?

Put the IP address and port number for your torrent, or for a datafile about the torrent, into the namecoin dataspace?

I agree that namecoin would be a good start for experimenting with this. There's a number of approaches that could be taken. Some ideas:

• The namecoin 'key' is a torrent name with the value being the magnet link. This is simple but has a few disadvantages. The owner of the key has to update it every 36,000 blocks for it to remain alive. Only that owner can modify the magnet link if it changes. Multiple people will store information for the same file with slightly different key names. Spammers can create fake magnet links easily for popular filenames, or squat on filenames (eg. future episodes of tv shows or movies about to be released).
• The key is a username of a person publishing links. The value is a datastructure (JSON?) that holds the link type (magnet, mega, freenet, http, etc), the URN (magnet link, freenet address, etc), a title, tags and maybe other things. A user can then filter by the namecoin key if they find a user that publishes torrents they like. Spammers would need to register their own username and people will learn which are bad and ignore them. Adding links is done via a name_update command. You can get a list of all links for a user by doing a "name_history" on their username. This can sit under a namecoin prefix like "fileshare/". I registered a fileshare name to show an example. Downsides are that a name_update can only have one pending for a given key per block. This could help cut down on spam updates though. Another downside is that it requires a name_history to get all entries and isn't as simple or efficient as iterating over a namecoin prefix to get all keys.

As an example of the second option, running this namecoind command will show an example entry:

Code:

namecoind name_filter "^fileshare/.+"

That example adds a "command" entry which I though could be used to add/delete/modify items but I'm not sure of the utility. It also might be worth encrypting or obfuscating the entries. Maybe an option to add an address to the value for users to send namecoins to as a means of voting.

[phelix]

not quite sure yet but my gut says the second variant is more likely to succeed

I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}

>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip


length of the value field is currently limited to 520 characters because of a bug in name_update. It is planned to increase the possible value length to 9000bytes or so.

[doublec]

not quite sure yet but my gut says the second variant is more likely to succeed

I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}

>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip

Good point about 'sendtoname'. Using a separate protocol per namespace is also a good idea. Given magnet url's have a "dn" key for giving the full name I'm wondering if it's even worth having JSON as the value. Just having the magnet link gives all that's needed.

[phelix]

not quite sure yet but my gut says the second variant is more likely to succeed

I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}

>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip

Good point about 'sendtoname'. Using a separate protocol per namespace is also a good idea. Given magnet url's have a "dn" key for giving the full name I'm wondering if it's even worth having JSON as the value. Just having the magnet link gives all that's needed.

aaaand we're done. with namecoin everything is a peace of cake.  

If it were not for hen and egg...


edit: I guess the length limit of 520 characters might be an issue with magnet links. maybe we should finally fix this bug to at least have a 1000 characters available.

[crazy_rabbit]

not quite sure yet but my gut says the second variant is more likely to succeed

I would keep it simple, though, and start with one protocol per namespace. btm/satoshi : {bit torrent magnet}

>Maybe an option to add an address to the value for users to send namecoins to as a means of voting.
no need for that, you can simply use sendtoname for a tip

Good point about 'sendtoname'. Using a separate protocol per namespace is also a good idea. Given magnet url's have a "dn" key for giving the full name I'm wondering if it's even worth having JSON as the value. Just having the magnet link gives all that's needed.

aaaand we're done. with namecoin everything is a peace of cake. 

If it were not for hen and egg...


edit: I guess the length limit of 520 characters might be an issue with magnet links. maybe we should finally fix this bug to at least have a 1000 characters available.

What about base128 encoding?

Or splitting the tracker over multiple payments?

[doublec]

I've created a "btm/testing" name for testing. It should show in about block 93985 where you can see it the magnet links it has posted with:

Code:

namecoind name_history btm/testing

You can list the "btm/" namespace with:

Code:

namecoind name_filter "^btm/.+"

Now there needs to be a website that scans that namespace, does a name history on the names, and provides it in a pretty format.

[crazy_rabbit]

I've created a "btm/testing" name for testing. It should show in about block 93985 where you can see it the magnet links it has posted with:

Code:

namecoind name_history btm/testing

You can list the "btm/" namespace with:

Code:

namecoind name_filter "^btm/.+"

Now there needs to be a website that scans that namespace, does a name history on the names, and provides it in a pretty format.

interesting, how would the tracker work in this case? Considering how long magnet links are?

[doublec]

interesting, how would the tracker work in this case? Considering how long magnet links are?

Can you give an example of a long link? Here's an example of the archlinux distro:

Code:

magnet:?xt=urn:btih:e940a7a57294e4c98f62514b32611e38181b6cae&dn=archlinux-2013.01.04-dual.iso&tr=udp://tracker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce

This is 176 characters. Are the "tr" keys actually needed?

Edit: The only mandatory parameter= required is the 'xt' according to BEP 009. So magnet links can be quite short. A website can scan namecoin for the magnet links then retrieve the metadata via the Bittorrent DHT. I still think it might be good to include metadata in namecoind though to make searching faster/easier. Something like:

Code:

{"hash":"btih:e940a7a57294e4c98f62514b32611e38181b6cae","description":"archlinux-2013.01.04 iso","tags":["linux","iso"]}

[crazy_rabbit]

interesting, how would the tracker work in this case? Considering how long magnet links are?

Can you give an example of a long link? Here's an example of the archlinux distro:

Code:

magnet:?xt=urn:btih:e940a7a57294e4c98f62514b32611e38181b6cae&dn=archlinux-2013.01.04-dual.iso&tr=udp://tracker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce

This is 176 characters. Are the "tr" keys actually needed?

Edit: The only mandatory parameter= required is the 'xt' according to BEP 009. So magnet links can be quite short. A website can scan namecoin for the magnet links then retrieve the metadata via the Bittorrent DHT. I still think it might be good to include metadata in namecoind though to make searching faster/easier. Something like:

Code:

{"hash":"btih:e940a7a57294e4c98f62514b32611e38181b6cae","description":"archlinux-2013.01.04 iso","tags":["linux","iso"]}

That is quite short- magnet links for example, for movies at popular torrent sites however are many times longer then that. I'd post here an example except for obvious reasons. :-)

[doublec]

That is quite short- magnet links for example, for movies at popular torrent sites however are many times longer then that. I'd post here an example except for obvious reasons. :-)

As I test I found a long magnet link from a movie site. I took just the hash from that link (the string of hex digits after '?xt=urn:btih:') and searched for that in the DHT network via btdigg.org. This pulled up the correct file information, including a shorter magnet link (without the 'tr' tracker links). This seems to imply that just requiring the hash is fine. I did the same for searching for the archlinux iso (hash e940a7a57294e4c98f62514b32611e38181b6cae) and it came up.

This does seem to indicate however that namecoin isn't needed for storing information since the DHT already has it. Maybe the namecoin provides the "unique identity that can be followed to provide files I'm interested in" aspect.