The paradox of small block size

[beyonce bingo]

Help me out here, many say block size for bitcoin should be small for the little guy so he can afford to run a full node and not buy extra space but that same little guy has to spend over $10 to send a transaction in a reasonable amount of time, when $10 is days worth of labor in poor countries.

[NotATether]

The block size has absolutely nothing to do with the USD value of transaction fees. A larger block size only lets more transactions fit in, which would not decrease the amount each individual transaction pays in fees. There is no extra collective fee paid for batching a few transactions together in a block.

Turning down the sat/byte rate to a third will still confirm your transactions reasonably fast, in a couple of hours, while paying just the BTC equivalent of $3 in fees.

[ranochigo]

A larger block size only lets more transactions fit in, which would not decrease the amount each individual transaction pays in fees. There is no extra collective fee paid for batching a few transactions together in a block.

Which given the current transaction volume, would result in a partial decrease in the fees/size right? It's a free market after all, an increase in block space will result in a decrease in the transaction fees.

Block size was increased in a backwards compatible manner with segwit. Increasing block space excessively is doable, just won't garner enough support and could pose some issues with the propagation and the blockchain size as well. A better solution would be a second layer solution to accommodate larger transaction volumes without those tradeoffs which is what Lightning network does. Current Bitcoin isn't suitable for smaller transactions but lightning network certainly is.

[Xavofat]

The block size has absolutely nothing to do with the USD value of transaction fees.

As recently as 2012, a large proportion of Bitcoin transaction used zero fees.  If the block size was large enough to accommodate the number of transactions that people freely wish to send over the network, there would be no fees or almost no fees.  It is understandable that as the amount of users increases and the block reward halves, the transaction fees would increase somewhat to incentivise miners to keep the Bitcoin network secure, but not to the extent that it has.  That is a trade off we have decided to make to avoid centralisation from increasing the storage required to run full nodes.

Really where the dilemma comes in is the fact that the amount of storage required to run a full node can only increase.  The only way that this will not cause a problem is if the typical amount of storage people have on their PCs increases at a faster rate than the amount of data on the blockchain, which so far it has.

I agree with the OP.  Many people who need Bitcoin the most are in poor countries paying extortionate fees.

[pawanjain]

Help me out here, many say block size for bitcoin should be small for the little guy so he can afford to run a full node and not buy extra space but that same little guy has to spend over $10 to send a transaction in a reasonable amount of time, when $10 is days worth of labor in poor countries.

Bitcoin is designed in such a way that the blockchain size can only increase every day. So we would need drives with more storage space to run a full node for a longer period of time.
But we do have other options such as running a pruned node where the very old blocks are not needed to be validated and only the recent blocks are validated. This requires a lower amount of storage than the full node.

Transaction fees can be customized and need not necessarily be $10 every time. If you are short on transaction fees then you can always put a lower fee but you will have to wait for a longer time for the transaction to be confirmed. But yeah, increased transaction fees can certainly be a huge problem when the network is congested. If we put a lower transaction fee when the network is congested then it will probably take a very long time to be confirmed or until the network congestion is resolved and the transaction is mined.

[DaveF]

...and could pose some issues with the propagation and the blockchain size as well. ...

Drives are cheap enough, and if you are running a node that is doing processing for yourself / business then you should have good enough bandwidth to handle a few meg burst here and there. With compression it's getting even better.
I have a client running a eth node AND a BTC & Lightning node on a 768/128 DSL line with no issues. Needs many TBs of SSD to run it because of the ETH but don't tell me you need massive bandwidth to do it after the initial sync, I can drive you out to his office in Islip and point to proof that you don't.

Current Bitcoin isn't suitable for smaller transactions but lightning network certainly is.

And yet here I sit running 2 of my own lightning nodes for my own use, so I can fill them when fees are low and slowly spend them. But I still have to do on chain transactions because a lot of places still don't take lightning payments.

-Dave

[philipma1957]

LTC and Doge are well backed asics and do a lot to lower the issue.

for every block of btc there are 2 blocks of ltc
for every block of btc there are 10 blocks of doge.

I have sent 1,000,000 doge for 2 doge fee.

Problem stated by op only exists for a BTC maximumialist .

[ranochigo]

Drives are cheap enough, and if you are running a node that is doing processing for yourself / business then you should have good enough bandwidth to handle a few meg burst here and there. With compression it's getting even better.
I have a client running a eth node AND a BTC & Lightning node on a 768/128 DSL line with no issues. Needs many TBs of SSD to run it because of the ETH but don't tell me you need massive bandwidth to do it after the initial sync, I can drive you out to his office in Islip and point to proof that you don't.

Drives are cheap, yes. Not everyone can upgrade or have space for upgrades. Laptops are fairly limited in disk size and it can be a hassle to upgrade to a bigger drive and there are plenty of heavy users who just needs that disk space. Bandwidth isn't the main problem. The time it takes to propagate and validate the blocks will be the main problem. Having a long propagation time introduces the problem of forks and they would have a lower security when getting any confirmations.

As to how much block size should the increment be, I'm not too sure. Segwit is a block size increase, it's not right to say that the block size hasn't been increased before. Though with the current mempool, perhaps 4MB blocks wouldn't be enough.

And yet here I sit running 2 of my own lightning nodes for my own use, so I can fill them when fees are low and slowly spend them. But I still have to do on chain transactions because a lot of places still don't take lightning payments.

Unfortunate. I find that a common issue as well.

[ranochigo]

Most laptop aren't designed to run 24/7 and people who run Bitcoin Core on their laptop usually just need wallet functionally where they could use pruned mode or SPV wallet.
Besides, most laptop i've seen have storage size between 0.5-1.0TB where blockchain size surpass laptop storage size in few years.

I think it's more of an anecdotal statement for me, I've been using my laptop to run Bitcoin Core for a while now and my use case is not always only for the wallet functionality. I think of SPV wallets as a (partial) substitute but not a full replacement for full clients. I was coming from the POV that any reasonable increase in block size to counter the current high fees would result in exponential growth of the blockchain. For which, most users wouldn't really consider purchasing additional disks for that or bother opening up their computer to upgrade.

[NotATether]

I've been using my laptop to run Bitcoin Core for a while now and my use case is not always only for the wallet functionality.

Wait. Im going a bit off topic, but does Core detect and handle a laptop sleep or hibernation event, or not? I suspect it doesn't get any grace period to clean up normally because there is no signal for these events (ditto for VM pauses and suspensions), and the time Core takes to flush it's dbcache to disk is longer than the time between sleek initiation and programs actually being paused.

I'm sure that when it resumes, Core's state isn't going to be modified but messages to and from peers that were half-sent or half-received will be aborted. I don't think either of those are particularly serious so maybe it'll be OK if it doesn't do anything when the system's about to go into sleep state.