Block reward <1 btc re-orgs vector viable? Eg Binance

[jubalix]

Ok my error in so far as the whole history, the 1MB a temp measure if I recall.

also I hold there can be no spam on a blockchain as the "spammer" as long as they can pay is as valid as anyone else. Your just calling them a spammer, but a larger blocksize make it much more expensive to "spam"

This is not to prevent block chain spam, it was to prevent a DOS vector which would allow an attacker to create big blocks and flood the network.

Ok if that is the reason then what is the max block permissible to avoid this as hardware gets better?

[1713486542]

1713486542

[1713486542]

1713486542

[jubalix]

The argument  I make is when the block subsidy is very low versus the value of the fees and the value of BTC is high, the block size will have an impact on how secure the chain is.

That's just an assumption you make.
There is nothing to prove that point of view.

No, there must be limits.

why not have a 1kb block why not have a 10 terabyte block. There must be a maximum utility in there some where

How is this related to your statement that a higher blocksize increases the security (which i replied to) ?

You indicated 1MB was ok. I put why and used absurdo reducto, to show no its not necessarily ok. I proved my pint of view by pointing out 1KB is too small and 10TB is to big.

why is 1MB the most "secure". Because you assert it?

So in there somewhere is a best maxima, and why would ut be 1MB and even if it was then it must scale up with hardware capacity increase.

[jubalix]

Sure you can scale off chain but that does not mean you can have a different type of scaling onchain.

Never said that.
I said you don't need to increase the blocksize.

Never said that you shouldn't under any circumstances. Neither did i said that purely off-chain is the best solution.
On-chain scaling solutions are good, as long as it's not about purely increasing the blocksize.

My point was at you made a false equivalence.

you said and I quote

Segwit is necessary for further scaling, yes. But bigger blocks are not.

There are way better scaling options available than just increasing the blocksize, therefore it is not necessary (not saying slightly increased blocksize would hurt BTC).

You failed to address there are different types of scaling. You made the false equivalence of segwit LN scaling and On chain scaling, which are completely different things.

Then you went without any reason to say because you have LN you don't really need the onchain scaling.

They are very different things and their purposes somewhat orthogonal.

You now try and resile from that.

I agree though there must be some increase in blocksize.

[Wind_FURY]

How will Re-orgs be stopped by financial incentive when the on-chain blocksize is to small even when full and your only geting 1 or say 1/4 of a btc per block rewards?

Without onchain blocksize increase the network becomes more vulnerable to re - orgs by financial insentive.

Eg

hack of $300M or some such large number.

miners only getting 0.25 btc a block and fees which will be limited in number by blocksize

So if you get
[1] a "HACK"
[2] BTC price drops a lot
[3] Block reward is very low

then you have removed large barrier's to an actors ability to bribe miners to re-org and thus destroy credibility of the BTC network.


Does this not force you to have larger blocks to get enough fees to defend this case?

But the fees are not "limited" by the block size. There's a fee market, that goes up and down, depending on user demand of having their transactions included in the blocks.

What am I missing?

[jubalix]

How will Re-orgs be stopped by financial incentive when the on-chain blocksize is to small even when full and your only geting 1 or say 1/4 of a btc per block rewards?

Without onchain blocksize increase the network becomes more vulnerable to re - orgs by financial insentive.

Eg

hack of $300M or some such large number.

miners only getting 0.25 btc a block and fees which will be limited in number by blocksize

So if you get
[1] a "HACK"
[2] BTC price drops a lot
[3] Block reward is very low

then you have removed large barrier's to an actors ability to bribe miners to re-org and thus destroy credibility of the BTC network.


Does this not force you to have larger blocks to get enough fees to defend this case?

But the fees are not "limited" by the block size. There's a fee market, that goes up and down, depending on user demand of having their transactions included in the blocks.

What am I missing?

How big is your market is what your missing....

is it big enough to fill the void of the block subsidy?

How do attract enough people to your market

give them a utility with low enough friction....

[Wind_FURY]

But the fees are not "limited" by the block size. There's a fee market, that goes up and down, depending on user demand of having their transactions included in the blocks.

What am I missing?

Don't forget :
1. Minimum fees allowed by the protocol (which is 0BTC)
2. Common/default minrelayfee value on most nodes/client (which is 0.00001BTC/kB)
3. Cryptocurrency price, which affect cost to launch re-org attack
4. Whether blocks are full or there are many pending transaction, which incentive user to user higher fees

But that doesn't account for demand of having your transaction included in a block.

How will Re-orgs be stopped by financial incentive when the on-chain blocksize is to small even when full and your only geting 1 or say 1/4 of a btc per block rewards?

Without onchain blocksize increase the network becomes more vulnerable to re - orgs by financial insentive.

Eg

hack of $300M or some such large number.

miners only getting 0.25 btc a block and fees which will be limited in number by blocksize

So if you get
[1] a "HACK"
[2] BTC price drops a lot
[3] Block reward is very low

then you have removed large barrier's to an actors ability to bribe miners to re-org and thus destroy credibility of the BTC network.


Does this not force you to have larger blocks to get enough fees to defend this case?

But the fees are not "limited" by the block size. There's a fee market, that goes up and down, depending on user demand of having their transactions included in the blocks.

What am I missing?

How big is your market is what your missing....

is it big enough to fill the void of the block subsidy?

How do attract enough people to your market

give them a utility with low enough friction....

Ok, there will be a halving for Bitcoin and Bitcoin Cash ABC next year. Let's observe which network is more affected by it, the one with the smaller blocks, or the one with the bigger blocks.

In your own theory, the one with bigger blocks should have no problems because it could fit many more transactions than the one with smaller blocks, correct?

[jubalix]

Ok, there will be a halving for Bitcoin and Bitcoin Cash ABC next year. Let's observe which network is more affected by it, the one with the smaller blocks, or the one with the bigger blocks.

In your own theory, the one with bigger blocks should have no problems because it could fit many more transactions than the one with smaller blocks, correct?

No I say there is a optimum blocksize and 1MB is not it.

there is no reason or theory or maths or anything behind 1MB except just temp hold

I thinks it bigger than that.

But I am not saying bigger blocks are always better. 16 mb may not be better than 8mb

I am saying that somewhere in there there is a band of optimal blocksize that is a function of hardware, market friction, decentralisation, and I think it seems to be in the form of  g(x) = scurve + c. at least in the forseable or near  future.

Satoshi, it seems said do not care about larger blks in the future as the need arises.

[Wind_FURY]

But what is the "optimal block size"? That's the mystery that all cryptocurrency developers wants to know. But the point is, I believe "it depends" on the demand, and the capability of the network to scale out.

[mda]

But what is the "optimal block size"? That's the mystery that all cryptocurrency developers wants to know.

I'll try to uncover this mystery for you and the rest of cryptocurrency developers. The optimal block size is ~25% of the average residential line throughput divided in 10 minute chunks.

[jubalix]

Not really.

Imagine a blocksize of 1000 MB.
Imagine the blocks are filled with 1MB regular transactions (without spam).

Now an attacker can fill the remaining 999MB of the block with 1 sat/B transactions.

He couldn't create 999MB traffic with 1sat/B transactions with a block size limit of 1MB. This would require him to have 999 blocks completely filled with his 1sat/B transactions.
A much higher fee (actually highest paying fee relative to all other transactions) would be necessary to generate 999MB traffic in this case.

It is cheaper to fill large blocks, than to fill small blocks.

You assume a static demand of just one user, where it cheaper many more people can use so harder to fill and mor fees for miner, and more security.

thats win, win and win.

[bob123]

You indicated 1MB was ok. I put why and used absurdo reducto, to show no its not necessarily ok. I proved my pint of view by pointing out 1KB is too small and 10TB is to big.

why is 1MB the most "secure". Because you assert it?

No, what you did was claiming that bigger blocks are more secure.
You still didn't give a single valid argument for that claim. You made a (stupid) assumption without any proof / argument.

My point was at you made a false equivalence.

you said and I quote

Segwit is necessary for further scaling, yes. But bigger blocks are not.
There are way better scaling options available than just increasing the blocksize, therefore it is not necessary (not saying slightly increased blocksize would hurt BTC).

You failed to address there are different types of scaling. You made the false equivalence of segwit LN scaling and On chain scaling, which are completely different things.

Then you went without any reason to say because you have LN you don't really need the onchain scaling.

Did you even read the post you have replied to ?

I said you don't need to increase the blocksize.

Never said that you shouldn't under any circumstances. Neither did i said that purely off-chain is the best solution.
On-chain scaling solutions are good, as long as it's not about purely increasing the blocksize.

I don't know whether you simply overlooked it, or maybe didn't understand it. But there are other on-chain scaling solutions than increasing the blocksize (which btw has nothing to do with scaling, blocksize increase is just postponing the problem and creating new ones).

I agree though there must be some increase in blocksize.

Must? No.
Can? Small increase maybe, but not necessary at all..

[Wind_FURY]

But what is the "optimal block size"? That's the mystery that all cryptocurrency developers wants to know.

I'll try to uncover this mystery for you and the rest of cryptocurrency developers. The optimal block size is ~25% of the average residential line throughput divided in 10 minute chunks.

Sorry. I suck in math. How large is that?

But I believe that simple formula did not account for bandwidth, latency, block propagation, node centralization, and externality costs.

[mda]

Sorry. I suck in math. How large is that?

Three years ago it was 2.8MB.
https://bitcointalk.org/index.php?topic=1878214.msg18685789#msg18685789

[Wind_FURY]

Sorry. I suck in math. How large is that?

Three years ago it was 2.8MB.
https://bitcointalk.org/index.php?topic=1878214.msg18685789#msg18685789

But today? Maybe double the 2.8mb? Scaling simply by doubling, tripling the block size is deficient. On the surface it would look to be a simple solution. But it scales the network in. The solution? Maybe build like an "organized mempool" on top.