Topic: Charging rent on the bitcoin network, is that a bad idea? - page 2. (Read 404 times)

Where are they?

Exactly, and they would be the ones that pay for the data.

Anyway, I agree with you to some extent. The incredible bounty that has been provided to the world by open source software developers is greatly under-appreciated. But, where would we be if they had charged for their work?

But, the reality is that nobody can dictate how any issue will be resolved in a decentralized environment. So, fee or no fee -- we will just have to wait and see.

But we can't consider SPV clients part of the network in first place, the network consists of full nodes and everything else is a leach not a peer.

But, everyone is not an equal peer. Lite wallets, SPV wallets, and surveillance companies use the data that nodes provide, but contribute nothing.

And as you note, the charges would balance out anyway for those who are equal peers. Last month, my node downloaded 1GB but uploaded 10 GB.

It goes against the nature of the peer to peer network where everyone is a peer at equal level which means any money charged would be negated (peer A charges $1 to answer peer B and peer B charges $1 to respond).

There is no reason why nodes can't collect money in exchange for providing data to others. Furthermore, it can be done without any changes to consensus rules.

I dont necessarily like the idea of paying an involuntary rent, but if your balance is over a certain amount it's "rent exempt" and that amount is not too large it didn't sound like. So basically what rent is doing is taking very small accounts and getting rid of them over time if they go unused and keep a small balance. What is troublesome is the fact that once an account would get to zero on solana i think they delete all the accounts data including any nfts that were owned. how to get those back? not sure if it is possible.

anyhow, for bitcoin, paying rent for small balances could provide an extra income to miners i suppose to help offset the decreasing block rewards. not saying i'm for it though.


#2 does seem like a reasonable objection. i just realized that implementing rent on a utxo based system like bitcoin is not so straightforward as it is in an account based model like solana because you don't know what addresses make up an account. so you would have to treat each address as its own account...but if you did that, it helps get rid of small utxos that take up the same space in the utxo set as larger utxos i guess it would encourage people to consolidate their utxos at the very least 

I'll skip my comments and focus on this:

Wait a sec, isn't this an absurd idea? Why should I require money to get self-sovereignty and privacy? Aren't those enough to cover my disk's and memory's expenditures? It sounds like they want to expand their network in the wrong way.

I would say it's not good idea/not necessary for following reason,
1. Most people deemed current node amount is still sufficient. At time of writing this post, Bitnodes report there are 15113 reachable nodes[1] while Luke Jr stats (which include node which doesn't enable incoming connection) report there are about 50K nodes[2].
2. Increasing complexity of Bitcoin protocol.
3. Add more burden for Bitcoin contributor (whether it's on protocol or implementation level).

[1] https://bitnodes.io/dashboard/
[2] https://luke.dashjr.org/programs/bitcoin/files/charts/software.html

Short answer: we don't need it. But even if you want to do that on Bitcoin, you still can.

What is the purpose here? To have some data pushed to the blockchain? If so, then you can use OP_RETURN and pay for every pushed byte. You can also place your OP_RETURN in some unused TapScript branch, tweak your Taproot address, and then pay no fees, but keep the proof that your commitment is connected with your address.

It seems that case (2) can be handled by case (1) if you use Lightning Network, then things are much simpler. You can just create some channel and create channel closing transactions upfront, so that one side will get more and more coins, just by waiting and publishing a transaction with some higher locktime.

No problem with that, the latest closing transaction can move all coins to the one party, then that person would "collect rents from stale accounts" (simply because another party did nothing for the whole time since channel creation to the locktime in the last channel closing transaction).

In Bitcoin, you don't need "the whole scan of accounts", you only need to check accounts that voluntarily joined your system, for example by forming channels with you (or joining your channel factory, N-of-N multisig with Taproot is cheaper than it was with other address types).

Is it user-destroyed or miner-destroyed? Because using any user-destroyed method is going to leave a trace in the blockchain. On the other hand, miner-destroyed way is much cleaner, because then such miner is just taking less coinbase reward, so there is no additional UTXO at all (and this can be enforced in a no-fork way, where only a group of miners will burn their coins, while still being part of the network).

Wait, there are "validators"? So why this altcoin is not directly connected with Bitcoin by a two-way peg-in? And why this altcoin needs any new coins at all and not reuse Bitcoins? If you have some fixed group of "validators" that are allowed to mine, then you don't need any new coins, you can run everything directly on Bitcoin blockchain, by creating a signet sidechain, pegged into the mainnet! Even more: if that group of "validators" can evolve over time (so that introducing new "validators" or changing existing ones is possible), then it can be easily handled, just by changing keys and signing that! So, that kind of staking model can be running on Bitcoin today, without any forks!

At that point, I stopped reading, because now I am convinced that this system can run directly on Bitcoin, so we don't need to change anything to allow rent.

Solana does it. Didn't know they did it when I first started using it:

https://docs.solana.com/implemented-proposals/rent