[ANN][VTR] vTorrent - Share with freedom | 2FA | HD | @Bittrex

[NextTrade]

Dear all,


We are in the process of designing the way seeders should earn their token (transferable to VTR) from seeding, as torrent file seeding normally divided into pieces, in the beginning we will implement static piece size (most likely 512Kb pieces) and have user settable demand price per piece.

For example, 700mb file, if user pre-defined price at 0.5 VTR per piece

700*1024/512 = 1400 pieces

Then users would earn roughly around 700 VTR for 700mb file, AND only if he is the only user seeding this torrent at that given moment.

In real-life scenarios, users only earn from the pieces they contributed or seeded to the network, and seeders are earning from leachers not VTR network.

If anybody have any suggestions or ideas about how we should reward the seeders, please PM me or reply in thread.


Regards,

vTorrent

Sorry is this for tokens or for actual VTR?

If its for VTR and not tokens then the entire currency would currently only hold 10TB of data which is smaller than a drop in the ocean.

Or are users able to set a price (in which case 0.5mb/VTR would be extremely high).

No chance of an increase in prices? lol

Looks like some $ or BTC pricing mechanism is needed.

I think it is just an example, dev put out for us to understand calculation easily 

[1713526337]

1713526337

[1713526337]

1713526337

[1713526337]

1713526337

[1713526337]

1713526337

[1713526337]

1713526337

[ik_do]

Dear all,


We are in the process of designing the way seeders should earn their token (transferable to VTR) from seeding, as torrent file seeding normally divided into pieces, in the beginning we will implement static piece size (most likely 512Kb pieces) and have user settable demand price per piece.

For example, 700mb file, if user pre-defined price at 0.5 VTR per piece

700*1024/512 = 1400 pieces

Then users would earn roughly around 700 VTR for 700mb file, AND only if he is the only user seeding this torrent at that given moment.

In real-life scenarios, users only earn from the pieces they contributed or seeded to the network, and seeders are earning from leachers not VTR network.

If anybody have any suggestions or ideas about how we should reward the seeders, please PM me or reply in thread.


Regards,

vTorrent

Sorry is this for tokens or for actual VTR?

If its for VTR and not tokens then the entire currency would currently only hold 10TB of data which is smaller than a drop in the ocean.

Or are users able to set a price (in which case 0.5mb/VTR would be extremely high).

No chance of an increase in prices? lol

Looks like some $ or BTC pricing mechanism is needed.

I think it is just an example, dev put out for us to understand calculation easily 

I guess it may have more been about the 512kb "blocks".

Is each "block" a separate transaction on the blockchain? Or how does it work?

I suppose we need to look at what the average filesize of a torrent is and what the current maximum/minimum is.

I'd say for minimum we're looking at 1MB (2 "blocks") and as a maximum probably 1TB (1,953,125 "blocks")

I don't think the minimum size would ever really change (i.e. for distribution of certain text files/PDF documents which are never going to go anywhere) whereas the maximum could conceivably increase over the next few years.

[coins101]

Let me just check what's going on...

Data is not going to be stored on the VTR network? The BitTorrent network is going to carry on doing what it does. This pricing structure is just a way to quantify the charge / bandwidth, not charge / storage space on the chain.

[ik_do]

Let me just check what's going on...

Data is not going to be stored on the VTR network? The BitTorrent network is going to carry on doing what it does. This pricing structure is just a way to quantify the charge / bandwidth, not charge / storage space on the chain.

Yes I think it should be fairly known that it would be impossible to store actual 'data' on the VTR network, rather only a record of it.

My point is that if a transaction is made every time a 512KB "piece size" is sent then if, say, 100TB is transferred within a day (in the scope of the larger picture of the torrent network this is nothing) then it would result in 195,312,500 "piece sizes". I'd say we set our eyes towards 100TB/day as the gold standard at this moment in development (or even 10TB/day) and if things progressed beyond that then adapt accordingly.

How exactly that equates to VTR's blockchain is unknown at this point, but if it indeed resulted in that many transactions that would be a whole lot of bloat/data for the VTR blockchain to handle.

I just want to imagine a project in which we are not envisioning 1TB/day (1.3 million "piece sizes") but rather looking far beyond that.

Is there a set of options that vtorrent (dev) would like us to consider as opposed to 512 kb "piece sizes" (as per your post)?
i.e.

• 512kb
• 1mb
• 2.5mb
• 5mb
• 10mb
• 25mb

I think the reality is that any torrent with a file size of ~1-100MB is a unique scenario where seeding probably isn't a big deal, but for your bigger torrents what should this so-called "piece size" be determined as?

[coins101]

The payment needs to be flexible. Buyer / seller market.

I can watch unlimited HD movies on Netflix for a set price:

1. Netflix monthly price (HD and 4k)
2. ISP monthly price (uncapped)

~$30/month

If my broadband is a fixed price, then I'd be happy to earn the cost of my monthly broadband, plus a little extra. But my costs are capped, so at some point I would consider reducing the cost of seeding bandwidth.

[drays]

Let me just check what's going on...

Data is not going to be stored on the VTR network? The BitTorrent network is going to carry on doing what it does. This pricing structure is just a way to quantify the charge / bandwidth, not charge / storage space on the chain.

Yes I think it should be fairly known that it would be impossible to store actual 'data' on the VTR network, rather only a record of it.

My point is that if a transaction is made every time a 512KB "piece size" is sent then if, say, 100TB is transferred within a day (in the scope of the larger picture of the torrent network this is nothing) then it would result in 195,312,500 "piece sizes". I'd say we set our eyes towards 100TB/day as the gold standard at this moment in development (or even 10TB/day) and if things progressed beyond that then adapt accordingly.

How exactly that equates to VTR's blockchain is unknown at this point, but if it indeed resulted in that many transactions that would be a whole lot of bloat/data for the VTR blockchain to handle.

I just want to imagine a project in which we are not envisioning 1TB/day (1.3 million "piece sizes") but rather looking far beyond that.

Is there a set of options that vtorrent (dev) would like us to consider as opposed to 512 kb "piece sizes" (as per your post)?
i.e.

• 512kb
• 1mb
• 2.5mb
• 5mb
• 10mb
• 25mb

I think the reality is that any torrent with a file size of ~1-100MB is a unique scenario where seeding probably isn't a big deal, but for your bigger torrents what should this so-called "piece size" be determined as?

Having a transaction on VTR network everytime when a block of 512K is transferred is indeed a big load on the network, and also the size of a VTR blocks will be really big (as each block should contain too many transactions in this case).

Maybe those "pieces" should not be fixed in size, but be of different sizes depending on the size of the specific shared content (fixed for every torrent file - bigger for big torrents, smaller for small torrents)..?

[coins101]

The payment needs to be flexible. Buyer / seller market.

I can watch unlimited HD movies on Netflix for a set price:

1. Netflix monthly price (HD and 4k)
2. ISP monthly price (uncapped)

~$30/month

If my broadband is a fixed price, then I'd be happy to earn the cost of my monthly broadband, plus a little extra. But my costs are capped, so at some point I would consider reducing the cost of seeding bandwidth.

Maybe something like DarkGravityWave for difficulty re-target:

Charge cost per size; until $x income is reached within a 30 day period; then discount of x% applied?

This means that fees are shared more equally around the network, as your earnings can be capped to encourage more people to seed and allow more people to share in profits.

I'm still keen on first 100 seeders get a share from everyone else's fees (provided they are also still seeding) in order to start a race to seed new files  

[vtorrent]

Let me just check what's going on...

Data is not going to be stored on the VTR network? The BitTorrent network is going to carry on doing what it does. This pricing structure is just a way to quantify the charge / bandwidth, not charge / storage space on the chain.

Yes I think it should be fairly known that it would be impossible to store actual 'data' on the VTR network, rather only a record of it.

My point is that if a transaction is made every time a 512KB "piece size" is sent then if, say, 100TB is transferred within a day (in the scope of the larger picture of the torrent network this is nothing) then it would result in 195,312,500 "piece sizes". I'd say we set our eyes towards 100TB/day as the gold standard at this moment in development (or even 10TB/day) and if things progressed beyond that then adapt accordingly.

How exactly that equates to VTR's blockchain is unknown at this point, but if it indeed resulted in that many transactions that would be a whole lot of bloat/data for the VTR blockchain to handle.

I just want to imagine a project in which we are not envisioning 1TB/day (1.3 million "piece sizes") but rather looking far beyond that.

Is there a set of options that vtorrent (dev) would like us to consider as opposed to 512 kb "piece sizes" (as per your post)?
i.e.

• 512kb
• 1mb
• 2.5mb
• 5mb
• 10mb
• 25mb

I think the reality is that any torrent with a file size of ~1-100MB is a unique scenario where seeding probably isn't a big deal, but for your bigger torrents what should this so-called "piece size" be determined as?

Having a transaction on VTR network everytime when a block of 512K is transferred is indeed a big load on the network, and also the size of a VTR blocks will be really big (as each block should contain too many transactions in this case).

Maybe those "pieces" should not be fixed in size, but be of different sizes depending on the size of the specific shared content (fixed for every torrent file - bigger for big torrents, smaller for small torrents)..?

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

[Edward50]

looks interesting. Following

[vtorrent]

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

Code:

“encryptwallet <passphrase> [otaenable]”

$ vTorrentd encryptwallet SuPer$tr0ngPa$$phra$E true

{
    "The wallet encryption succesfully changed." : "Authenticator secret: KRNEORSRKNIE2N2Y"
}

To Fully Unlock Client

Code:

"walletpassphrase <passphrase> <otpcode> <timeout> [stakingonly]”

$ vTorrentd walletpassphrase SuPer$tr0ngPa$$phra$E 381342 9999999 false

To Unlock Client only for Staking

Code:

"walletpassphrase <passphrase> <otpcode> <timeout> [stakingonly]”

$ vTorrentd walletpassphrase SuPer$tr0ngPa$$phra$E ANY 9999999 true

To Change Passphrase and to Enable/Disable 2FA

Code:

“walletpassphrasechange <oldpassphrase> <newpassphrase> <oldotpcode> [otaenable]”

$ vTorrentd walletpassphrasechange SuPer$tr0ngPa$$phra$E SuPer$tr0ngPa$$phra$EnEW 453609 true
{
    "The wallet encryption succesfully changed." : "Authenticator secret: HFIVASKHG5AUSQSG"
}

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


Troubleshooting

Code:

$ vTorrentd walletpassphrase SuPer$tr0ngPa$$phra$E 112494 9999999 false
error: {"code":-14,"message":"Error: The wallet passphrase or authenticator code entered was incorrect."}

** 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:

Code:

vTorrent-0.8.1.1-Win.zip - cb71216854d3c7e3385463f32078bff2

vTorrent-0.8.1.1-OSX.dmg - edd9bca9c41cbcb3242e00287ccd14b3

vTorrentd-0.8.1.1-OSX.zip - 6518e0edcb42c7a76c4ec237af54f2e4

Download:

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


Regards,

vTorrent

[coins101]

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.

[ik_do]

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.

Agreed.

[coins101]

@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?

[Listent]

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.

Agreed.

Nice work

[leigh2k14]

Looks like we have a new top wallet  

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

[coins101]

Looks like we have a new top wallet  

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

Never mind all that.

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

[ik_do]

Looks like we have a new top wallet  

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

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

[ik_do]

@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?

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.

[ik_do]

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.

[leigh2k14]

Looks like we have a new top wallet  

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

Never mind all that.

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

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.