Topic: [ANN][VTR] vTorrent - Share with freedom | 2FA | HD | @Bittrex - page 157. (Read 436160 times)

I'm not sure this is something for VTR to solve, but there are plenty of articles about finding torrents

http://www.techsupportalert.com/best-free-torrent-search-engines.htm

Yes, ratings were something that Kazaa/Limewire used inefficiently back in the day; popular torrent sites also have "verified" users who are known to provide "good content".

I think another breakthrough may be to have the client able to ascertain information from its content; i.e. rather than relying upon the creator labeling something well it'd be nice to have some form of searching for a particular standard (i.e. 1080p MKV w/ English subtitles).

Though it's never possible to account for converted content it would be premiering to have a client that can search for actual content's information.

Ratings?

Also, I keep finding myself going back to the multi-level marketing fees sharing approach. I think I need to get some fresh air. Stuck in a loop with that idea.

Yes first movers are important but its also important to mention that there exists many hundreds of thousands of perfect torrent files out there which are impecibly produced yet lack enough seeds--I suppose these are the last movers?

What is the cost/incentive to the end user to try and make these hard to find torrents available?

I like flexible payments too. A market driven approach.

This could be a leader board of fees for any given file. This would, likely, drive down the price until some don't bother to seed.

The way transaction fees are calculated by some wallets is interesting also. That is based on a market drive approach, too.

I'm still keen on creating a race to be first to seed by giving extra incentives to first movers. Multi-level marketing pricing mechanism is such a bad ass idea. Those first to seed could earn a fortune, driving up demand for running VTR.

Also a question to vtorrent--how do seeders/leechers identify each other? Will they need to run a specific client etc?

On top of it being flexible I think its important that it should also be obvious to any user--what are they paying for, what are they getting. Just putting a textbox with "bid price" isn't enough in this day and age and doesn't form a good standard in showing users they have the power to choose a price that actually makes sense than rather just looks good (i.e. why not 0.1899756 per KB rather than 0.1000000 per KB--the price doesn't need to be some preset/idealized value but rather something that is flexible in the users mind).

Its also worth noting that the price should be in accordance to scarcity of the torrent someone is after--if it has thousands of seeds then it should be worth a very base amount, if its a file several years old or in the initial phases of seeding then its value should be intrinsic in nature (i.e. it should be worth far more to a leecher and someone who wants to seed the file than any well-seeded file)

The pricing and mechanism should be focused upon delivering 100.00% of the file to paying leechers rather than copping out at 86% because no full copies are available via known seeds.

for instance the following imaginary examples (whereby 0.3/0.01/1 doesn't represent 1:1 to VTR but rather can be just used as a potential idea)
2000 MB torrent
600 seeders and 900 leechers (0.3 per KB)

2000 MB torrent
600 seeders and 32 leechers (0.01 per KB)

2000 MB torrent
2 seeders and 32 leechers (1 per KB)

It'd also be interesting to see a bidding market whereby different content has different bidding standards (i.e. files vs audio vs video vs programs vs etc) as well as the age of a torrent (i.e. is a torrent that is 6 years old worth more/less than the same content that is newer?)

For some content the age of the torrent is irrespective of its quality, whereas in other instances a poorly made/notated torrent is of less value than a well made/notated torrent)

Perhaps in summation there should be a few contributing factors to let a user know whether their bid for a file is acceptable or not (if that is indeed how the system will function)

The bandwith and pricing should be flexible like ik_do said, it seems the most reasonable way forward.
That being said let's see what the devs come up with.

Also, this link, if it hasn't been posted before is something that could be very, very, very interesting for vTorrent to consider adding at some point.

https://torrentfreak.com/mutable-torrents-proposal-makes-bittorrent-resilient-160813/

If the client somehow stored something like this on its own blockchain, then you would really have something quite interesting.

The pricing mechanism should be flexible tbh, so that it is purely governed by supply/demand. I guess it'd be a good idea for the client to clearly show what the current "average" price of bandwidth is but I am mostly concerned with these few factors:

-ease of use (whereby eventually vTr is implemented in third party clients such as rTorrent etc)
-ease of search (I want it to be really really like P2P software of yesteryear so people can actually search for content EASILY--perhaps a ZeroNet implementation at some point would be really interesting)
-WoT (web of trust--how do we know what a user has posted is worthwhile, how do we know they are reputable etc? Even if its just a 5 star rating system, there has to be something eventually that allows people to know they're not going to be wasting their time in downloading a file)
-chatrooms (I want communal, encrypted chatrooms just like IRC--I want to see people to be discussing things in-client and not have to add other users via their public key or some bullshit which no one will likely use. I want Joe Nobody to install the program and instantly be able to chat with people in General #1 or similar. This is a key factor in getting people to USE the client. Correct me if I'm wrong but I've never seen IRC via blockchain.)
-adoption incentives (I want to see people using the client for what its intended and not just bagholding or whatever bullshit is currently accepted/practiced in the cryptospace; I want to see people saying "I have XYZ content and I am going to share this because within 10 minutes I know I'll get 10 downloads)

Now its impossible to imagine all these features coming in the client anytime soon (even with/without torrent implementation yet) but I would gladly support financially the development of these ideas.

Damn I got moved down a place within the top 5 ):

Never mind all that.

What's your view on pricing for VTR and bandwidth for BitTorrent files.

Looks like we have a new top wallet  

http://cryptoguru.tk/RichList/index.php?Currency=VTR

Nice work

@ik_do

I like the analysis you provide.  

Now the dev has given some clarification around the payment channels and relationship to torrent file sizes, any further views on pricing mechanisms?

Agreed.

Thanks @dev

At last, a decent dev that provides good release notes. Obviously works with good IT products and knows what customers like to see during an upgrade process.

Very professional.

Dear all,


vTorrent 0.8.1.1 released has been updated with instructions for 2FA in RPC calls


What's New

This release brings an update to daemon side of 2FA, as well as some other minor fixes.

-Version bumped to 0.8.1.1 to indicate a new minor release
-2FA fully implemented in daemon


Instructions:


To Encrypt Client



To Fully Unlock Client



To Unlock Client only for Staking



To Change Passphrase and to Enable/Disable 2FA


** 2FA Authenticator secret will be renewed every time there are changes to the client encryption.


Troubleshooting


** If you are unable to unlock your client with correct passphrase, please check your time to make sure it is synced up.



Scheduled hard-fork:
-Posv2 at Block 1200000
-Posv3 at Block 1300000



Bug fixes:
-Messages crashes problems



MD5 Checksum:



Download:

https://github.com/vtorrent/vTorrent-Client/releases/0.8.1.1


Regards,

vTorrent

looks interesting. Following

Dear all,


Actually, the size of piece I stated here is only related to the way BitTorrent protocol works, by slicing up different size of torrent file in pieces and have each pieces verified by leacher's client using the SHA1 algorithm against the seeder's piece after each pieces is transferred, for example with 512kb piece size, 700mb would be divided into 1,400 pieces, piece size is the key that can make a torrent seeded on a slow connection scale well.

There is actually no theoretical limit for the bandwidth or file size that our network can handle at any given moment.

Moreover, each pieces of torrent file is unrelated to each transaction on VTR network, all of the transactions made to each seeders will be in micropayment channels which most of the transaction will be off-chain, and hence there should be no bloat issue for the VTR blockchain to handle.


Regards,

vTorrent