So I have built one, I'am using couchbase p2p to distribute an encrypted nosql database that can be shared even over bluetooth and all torrent files are stored in the couchbase attachments so its not even magnet link based but you can distribute those essential torrent files. The webtorrent protocol is used to scale to platforms such as ios and web where no torrent client is available as of yet.
join me at starpy dot me
Topic: Blockchain-based torrent tracker? (Read 4772 times)
combine with this: https://bitcointalksearch.org/topic/m.1495784 and you have a decentralized facebook kind of thing
Each Nym could have however many links fit into allowed data size (and historic linkages using name_history), and Nyms get reputation rating with upvoting via namecoin sendtoname function. Any user could command control if as many reputable Nyms they like.
Right, that's the approach I've been suggesting. I think it should work. 
Code:
namecoind name_new fs/somecoolmovie
Code:
namecoind name_firstupdate fs/somecoolmovie ''
Hmm, yeah you're right about that ... so maybe have the user put there PseudoNym in the name field so it can gain trusted-rep for posting authentic links and have one of the fields in value describe the file content in human-recognizable, searchable form?
Code:
namecoind name_new fs/filesharedude
Code:
namecoind name_firstupdate fs/filesharedude '{.... "vd": "some_cool_video" ... "ad":"some_cool_audio" ...}'
(plus map to hash value/link)
Each Nym could have however many links fit into allowed data size (and historic linkages using name_history), and Nyms get reputation rating with upvoting via namecoin sendtoname function. Any user could command control if as many reputable Nyms they like.
Code:
namecoind name_new fs/somecoolmovie
Code:
namecoind name_firstupdate fs/somecoolmovie ''
Quote
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.
Namecoin can provide the unique ID look-up to the DHT and the sendtoname facilities that are the most crucial and subject to censhorship ...
this is a great idea and application for namecoin btw.
Edit: also suggest use general namespace id "fs" (fileshare)
e.g.
Code:
namecoind name_new fs/somecoolmovie
Code:
namecoind name_firstupdate fs/somecoolmovie ''
and etc.
a website? I thought the whole point was doing it without a website. what about a beautiful command line tool? or a simple gui app?
Yeah, command line tool/gui would be good. A website with a read only view would be good for initial uptake though for those not wanting to install namecoin just to see what it's all about. Isn't this the kind of thing namecoin should work well for?
-MarkM-
-MarkM-
Given that the blockchain is compatible with btc it is not a question which one could but which one should. Great idea if you ask me but I can see a lot of hate coming from purists vetoing use of btc blockchain for storage - makes sense. With that in mind it'd be really cool to see someone try this with namecoin chain or testnet.
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:
You can list the "btm/" namespace with:
hehe I got it.Code:
namecoind name_history btm/testing
You can list the "btm/" namespace with:
Code:
namecoind name_filter "^btm/.+"
You have set up something like a youtube channel.
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.
I didn't know about BTdigg, indeed that sounds like the've already solved the question we were asking. Although perhaps the namecoin blockchain- being merge mined with Bitcoin is more robust?
one advantage I see with this besides being totally nerdy is that you can build some reputation for your "channel".
There are some other threads/links about this subject, please check out:
http://dot-bit.org/forum/viewtopic.php?f=5&t=613
https://bitcointalksearch.org/topic/the-pirate-bay-as-blockchain-127980
rgds
http://dot-bit.org/forum/viewtopic.php?f=5&t=613
https://bitcointalksearch.org/topic/the-pirate-bay-as-blockchain-127980
rgds
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.
I didn't know about BTdigg, indeed that sounds like the've already solved the question we were asking. Although perhaps the namecoin blockchain- being merge mined with Bitcoin is more robust?
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.
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. :-)
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"]}
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:
You can list the "btm/" namespace with:
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.
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?
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:
You can list the "btm/" namespace with:
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.
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.
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.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
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?
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.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
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.
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. 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
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.
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.
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:Put the IP address and port number for your torrent, or for a datafile about the torrent, into the namecoin dataspace?
- 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.
then everyone who has the blockchain on their hard drive would be considered criminal (where torrents are illegal)
not if it was encryped/encoded.
then everyone who has the blockchain on their hard drive would be considered criminal (where torrents are illegal)
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-
Put the IP address and port number for your torrent, or for a datafile about the torrent, into the namecoin dataspace?
-MarkM-
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.
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?
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.
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).
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.
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?
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.
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.
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?
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.
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.
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?
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.
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?
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 Would anyone be interested in something like this? Seems like a pretty cool idea to me.
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.
Would anyone be interested in something like this? Seems like a pretty cool idea to me.
Jump to: