Quote from: thecodebear on Today at 05:07:51 PM

I think the main two technological reasons to not increase block size are storage space, as you mentioned, and propagation time through the network.

Yes, propagation is more important than storage space - I would even argue that storage is almost irrelevant. Miners' requirements are also irrelevant becauses miners in today's times are not longer the laptop miners from 2010/11 or even the home ASIC miners from 2012/13 but mostly highly optimized server farms. There may be still some small miners but they have already to dedicate a lot of organizational work if they don't want to mine at a loss, so storage and bandwidth are minor problems for them.

So the reason we see no higher block size is actually "domestic" full nodes, not miners.

I think the main factor besides block propagation are CPU and memory requirements. 4 MB blocks (the current maximum) needs, according to a Bitfury study, about 16 MB of memory. So on a state-of-the art PC with 16MB+ RAM, you can still run a full Bitcoin node in the background, even if it would already affect your other activities a bit probably. But if the block size was significantly higher, you would need a dedicated device for that purpose, and not exactly a cheap one.

Quote from: vjudeu link=topic=5498790.msg64167860#msg64167860 date=1717482901
[quote

What do you think is a possible solution to this problem?.

Transaction joining, batching, and having more than one person on a single UTXO in a decentralized way.
[/quote]
[/quote]
I think the "buzzwords" related to these methods should be mentioned and explained as the OP is clearly not an expert.

Transaction joining and batching - this can be achieved with Lightning, Sidechains, and Rollups.

While many know some basics about these concepts, I'll try to describe them "from the main chain's point of view":

- On Lightning, basically, you create a simple special transaction which enables you to set rules to transact off-chain (without storing the transaction in a block) until a double spend conflict arises (where LN provides a mechanism to penalize the cheater and get the coins back) or you need on-chain Bitcoins. LN is basically almost mature with some flaws remaining.
- Sidechains are quite similar: you create a "peg-out" transaction enabling to transact off-chain from the mainchain point of view. You set some rules in the peg-out transaction, but the main security depends on the rules of an alternate chain, and conflicts are solved mostly on this alternate chain so it depends on both Bitcoin's and the altchain's security. You can "unlock" the coins ("peg-in") obeying a complex ruleset involving both chains. The big problems are still security and peg-in rules, there are currently several approaches being experimented with and none can be considered mature.
- Rollups are like sidechains, you also peg-out and peg-in, but the transaction data of the off-chain transactions is compressed in some way and a proof that everything was fine (or nothing was wrong) is stored on the main chain. Rollups are already widespread on Ethereum so they are entering maturity stage. Some approaches exist for Bitcoin, most I've seen however have serious flaws.

See the Sidechain Observer thread for some comments on existing sidechain/rollup solutions.

So in all three cases, with a single on-chain transaction you can potentially create an almost infinite number of "value transfers", on rollups there is a limitation however due to their higher on-chain requirements.

"Having more than one person on a single UTXO in a decentralized way" - there are concepts like Statechains and Ark (not to be confused with a similarly named altcoin). You do a special multisig transaction with a ruleset like on Lightning with a counterparty (the "Operator") you have to trust, and then a special derivation of the private key can be given along the "payment chain", e.g. the UTXO is "re-used" several times.