I mean there's no need to put a fixed amount of block-size limit since blockchain is inherently limited. Then at the time of peak usage network should handle more txs. Amount for increasing subsidy can estimate how much network can handle in future....
I think you are mixing up monetary supply and block size limit.
monetary supply = capped at 21,000,000 BTC which get issued on a fixed rate per block and act as a miner subsidiary. This is merely an accounting value and has nothing to do with block size.
block size = "physical" filesize of the ledger entry that contains the transaction itself. Dependent on the amount of inputs and outputs, each transaction takes up a certain amount of "physical" space on the blockchain, independent of the amount that is transacted, paid as a fee or burned. The block size is limited in that the collection of transactions that make up a block can not exceed a certain filesize, as to keep blockchain growth -- the collection of files, not the accounting values -- on a viable scale.
Yes. I'm trying to mix them together. I didn't write a good initial-post. I'm not looking for re-creating the same rules or accounting system as bitcoin.
I understand more/less how bitcoin works. So i agree with what you say.
1. Then user can edit/remove the file by spending the p2sh.
2. end-user can verify the file, So receiving it from any host will be fine.
3. Hmm, with HTTPS, caching files for ISP is no longer an option.
4. Each cloud user should have a server for doing fancy stuff. and making sure the integrity of files. It will reduce load on that server.
At that point you're not creating a decentralized cloud hosting provider but rather a file timestamping service... for which already multiple solutions exist, all of which are based on the Bitcoin blockchain:
https://opentimestamps.org/
https://app.originstamp.org/home
https://bitsig.io/howitworks/
(Disclaimer: I have no personal experience with any of these services so I can't speak for their legitimacy)
You are right there's a need for another network providing public cloud. But the issue it solves is agreeing on what exists at present. So it will trigger CREATE/UPDATE/DELETE commands. (Bitcoin has a secure network to solve a piece this puzzle)
Ah... got it. I don't think there's any protocol changes needed for that. You might actually be able to hack something together with Bitcoin's current scripting capabilities. After all this would be just sending meta-data over the Bitcoin blockchain, with some specialized client listening for specific commands. I don't see the benefit of using the Bitcoin blockchain as a command and control server for a filemanagement system though.
I did check bitcoin's code regarding to add some data to p2sh UTXO's, The network is rejecting it. It might be accepted by protocol.
Only way to add data is by. OP_RETURN, Which makes that UXTXO UN-spendable.
The thing I'm trying to achieve is let users have ability to UPDATE/DELETE or verify ownership by providing a signature for that p2sh which is bundled to it.