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.
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)..?