Topic: Block reward <1 btc re-orgs vector viable? Eg Binance (Read 550 times)

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.

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

Exactly, the incentive model works well. And it will continue to do so even if...
.

You are right that there must be a certain "average transaction fee level" per block (which you mention as g(x) ) to maintain the security of the chain when block rewards continue to descend. But your conclusion...
is flawed. The amount of transaction fees and maximum block size are not directly related, and their relation is pretty complex.

In late 2017, for example, Bitcoin had less block capacity than now because the percentage of Segwit transactions (which have less weight) was lower, but transaction fees were much higher than now, because blocks were fuller - that means, people were panicking to get their transactions included, and thus offered to pay high fees.

If the transaction block limit is too high, then - as was already written by others in this thread - the average fees per transaction stay low. In BCH, in theory I can send transactions for the absolute minimum because blocks are almost never full.

Now imagine the block size limit stays low at 4MB, and most transactions are carried out on sidechains, the Lightning Network, and other off-chain mechanisms (even centralized ones, like via Coinbase). The transaction fees on these "second layers" would be low, but their "wellbeing" depends on transactions on the main chain (be it via atomic swaps from and to sidechains, or channel opening/settlement transactions on LN). So in a world with high Bitcoin adoption the second layers would provide enough demand to ensure the transaction fees on the base layer stay high enough.

I agree however that at some point in the future block size should be increased, but this is not a priority issue now. Schnorr signatures and friends are much more promising in the near future. It would become a priority if the working of second layers cannot be ensured anymore with the current block size, e.g. if the demand for LN channel opening/settlement transactions is as high (or almost as high) as the block capacity.

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




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.




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.

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.

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



No it doesn't.

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