bitcoin-like protocol change, solution for two problems

[hosseinamin]

I'm not just talking about bitcoin as currency.

Here are two problems.

- Lack of Intrinsic value
- High fees due to block-size limit

Okay here's how i think it can achieve that.
 
1. All tx should burn some coin depending on tx size, (One(satoshi) coin will be equal to one byte) to put the tx in blockchain (cost of usage).
2. Subsidy should be inflationary due to burn of coins at usage. also it will define limit of blockchain size

Also this kind of bitcoin can also be used as public and open data store (what cool boys call it public cloud).

Then delivery of data can be a tool for earning revenue from consumer (ISP are doing it, but it will be cheaper for them) or the other way around.

What do you think?

[1714896527]

1714896527

[1714896527]

1714896527

[1714896527]

1714896527

[HeRetiK]

I'm not just talking about bitcoin as currency.

Here are two problems.

- Lack of Intrinsic value
- High fees due to block-size limit

Okay here's how i think it can achieve that.
 
1. All tx should burn some coin depending on tx size, (One(satoshi) coin will be equal to one byte) to put the tx in blockchain (cost of usage).
2. Subsidy should be inflationary due to burn of coins at usage. also it will define limit of blockchain size

Also this kind of bitcoin can also be used as public and open data store (what cool boys call it public cloud).

Then delivery of data can be a tool for earning revenue from consumer (ISP are doing it, but it will be cheaper for them) or the other way around.

What do you think?

1) How is burning coins for transactions on one side, while releasing an equal amount of subsidy on the other side different from simply paying a transaction fee? If you burn 100 Satoshis per transaction, but inflate the subsidy by... say... 100 Satoshis per transaction, you just added extra steps without achieving anything.

2) How does this affect blockchain size?

3) How does this add the intrinsic value that you perceive as missing?

4) How would this enable Bitcoin to become some sort of decentralized cloud provider? (assuming you even want this from Bitcoin in the first place)


Regarding 4) you should probably look into IPFS / Filecoin, Storj and MaidSafe, they might be of interest for you.

[cr1776]

I'm not just talking about bitcoin as currency.

Here are two problems.

- Lack of Intrinsic value
- High fees due to block-size limit

Okay here's how i think it can achieve that.
 
1. All tx should burn some coin depending on tx size, (One(satoshi) coin will be equal to one byte) to put the tx in blockchain (cost of usage).
2. Subsidy should be inflationary due to burn of coins at usage. also it will define limit of blockchain size

Also this kind of bitcoin can also be used as public and open data store (what cool boys call it public cloud).

Then delivery of data can be a tool for earning revenue from consumer (ISP are doing it, but it will be cheaper for them) or the other way around.

What do you think?

First, you are assuming a lot that both of those are problems.  Regarding intrinsic value, if you get right down to it, nothing has intrinsic value unless there are living beings who value it.  Gold, water, air, or anything else, nothing has value without people (or other sentient being) using it for something.   And just as fiat, gold, silver or precious gems, are valued by demand, bitcoin is valued by demand.  If gold or water or air or bitcoin is useful to someone, it has value.  Whether that use is as a transfer of value mechanism, a store of value mechanism, protection from authoritarian socialists, communists or fascists, a trading vehicle, or something else doesn't matter.  The concept of "intrinsic value" in the abstract is a fine one, but not when it is misused to claim that something like gold has "intrinsic value" while something else that clearly does have intrinsic value, doesn't.

Second, subsidies and fees right now provide network security.  As time passes the fee component will take over so if the fees go to low, you will lose some security.

You are welcome to fork bitcoin's code and the block chain and implement these rules and try convince enough people of the benefits of using this fork.  If you convince everyone (or nearly so) then those will be the new consensus rules.

[hosseinamin]

Hi everybody, Thanks for responding.

First of all i figured I'm terrible at explaining things

1. I'm not trying to change the bitcoin rules. (fork was the original idea, Not like bcash)
2. Regarding "Intrinsic value" i wasn't trying to oppose to bitcoin. I agree with you. I'll explain why i said that.

1) How is burning coins for transactions on one side, while releasing an equal amount of subsidy on the other side different from simply paying a transaction fee? If you burn 100 Satoshis per transaction, but inflate the subsidy by... say... 100 Satoshis per transaction, you just added extra steps without achieving anything.

2) How does this affect blockchain size?

1. First reason i would say It's good thing. We can make sure how much storage is needed for blockchain. Thus there's no need to put limit in blocksize.
2. subsidy will be fixed but inflationary instead of halving so more data can be written in blockchain over time.
3. Though it may not be a good idea for being currency.

3) How does this add the intrinsic value that you perceive as missing?

I meant if the coin's value becomes zero in respect to others. You can put some data to the blockchain. It might be a silly discussion. So i take it back.

4) How would this enable Bitcoin to become some sort of decentralized cloud provider? (assuming you even want this from Bitcoin in the first place)

So i figured if there's specific format for pubkey-script. For example, p2sh + original host + checksum-of-file

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.

Regarding 4) you should probably look into IPFS / Filecoin, Storj and MaidSafe, they might be of interest for you.

I didn't look at those in depth. I guess they didn't do it this way. (Filecoin, Storj for sure)


I may be wrong. Please tell me what you think. So i won't spend my time for nothing....

[HeRetiK]

1) How is burning coins for transactions on one side, while releasing an equal amount of subsidy on the other side different from simply paying a transaction fee? If you burn 100 Satoshis per transaction, but inflate the subsidy by... say... 100 Satoshis per transaction, you just added extra steps without achieving anything.

2) How does this affect blockchain size?

1. First reason i would say It's good thing. We can make sure how much storage is needed for blockchain. Thus there's no need to put limit in blocksize.
2. subsidy will be fixed but inflationary instead of halving so more data can be written in blockchain over time.
3. Though it may not be a good idea for being currency.

Once again... how would this solve the blocksize issue? I probably misunderstand you, but the way you put it, it seems to me like you assume that burning coins would free up blockchain space?

4) How would this enable Bitcoin to become some sort of decentralized cloud provider? (assuming you even want this from Bitcoin in the first place)

So i figured if there's specific format for pubkey-script. For example, p2sh + original host + checksum-of-file

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)

[hosseinamin]

1) How is burning coins for transactions on one side, while releasing an equal amount of subsidy on the other side different from simply paying a transaction fee? If you burn 100 Satoshis per transaction, but inflate the subsidy by... say... 100 Satoshis per transaction, you just added extra steps without achieving anything.

2) How does this affect blockchain size?

1. First reason i would say It's good thing. We can make sure how much storage is needed for blockchain. Thus there's no need to put limit in blocksize.
2. subsidy will be fixed but inflationary instead of halving so more data can be written in blockchain over time.
3. Though it may not be a good idea for being currency.

Once again... how would this solve the blocksize issue? I probably misunderstand you, but the way you put it, it seems to me like you assume that burning coins would free up blockchain space?

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

4) How would this enable Bitcoin to become some sort of decentralized cloud provider? (assuming you even want this from Bitcoin in the first place)

So i figured if there's specific format for pubkey-script. For example, p2sh + original host + checksum-of-file

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)

[freebutcaged]

Mate what you saying is not possible, if you don't pay enough fees miners will just mine empty blocks, Bitcoin network can function without any

Transactions, paying a fixed fee will force miners to mine small blocks.  Lack of intrinsic value> you can either have contractual value or intrinsic value

Can't have them both mate.

[hosseinamin]

Mate what you saying is not possible, if you don't pay enough fees miners will just mine empty blocks, Bitcoin network can function without any

Transactions, paying a fixed fee will force miners to mine small blocks.  Lack of intrinsic value> you can either have contractual value or intrinsic value

Can't have them both mate.

There's a way to force miners accepting all txs by determining best chain, as longest and with most lost coins relative to subsidy at that point.

[HeRetiK]

Once again... how would this solve the blocksize issue? I probably misunderstand you, but the way you put it, it seems to me like you assume that burning coins would free up blockchain space?

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.

So i figured if there's specific format for pubkey-script. For example, p2sh + original host + checksum-of-file

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.

[hosseinamin]

HeRetiK, Thanks for replying.

Once again... how would this solve the blocksize issue? I probably misunderstand you, but the way you put it, it seems to me like you assume that burning coins would free up blockchain space?

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.

So i figured if there's specific format for pubkey-script. For example, p2sh + original host + checksum-of-file

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.