Topic: Block size limit automatic adjustment - page 4. (Read 14572 times)

Well, I do think that there must be some blocks with enough free space to fit all almost-free transactions once in a while.. the adjustment shouldn't be so that all blocks are filled up.
I suppose transfers don't happen homogeneously during the 24h of a day, 7 days of a week. So, if the limit is "just", there will be blocks filled, and there will be blocks with free space where even free transactions could enter if the generator doesn't mind.

Possibly not. But what about very low fee transactions?

Not quite. A max block size that grows to accommodate all transactions won't impose scarcity even without flooding. And, unrelated, a single attacker could cheaply do a massive flooding attack; not for profit but out of malice.

In the rule scheme without a max block size the problem is that a generator could trick the rule to allow more transactions into the block for each individual block generated if the generator is allowed to include unpublished transactions to itself.

Regarding free transactions, I don't see why would somebody accept them as long as the client gives users the option to add fees to the transactions.
A generator could add free or dummy transactions to his own blocks in the intend to push the limit up, but then, one person only wouldn't be that effective in increasing the limit, as s/he wouldn't be able to generate enough blocks. If periods of adjustment are short, one person only wouldn't even be able to generate one block per period, so in the end s/he would be inoffensive, as the limit would fall back.
Only an attacker with strong computing power could push up the limit considerably. And I don't see much incentives in using a strong computing power like this... do you?

I see, you think people could push up the limit to be sure that it would be big enough to always fit every transaction in it, therefore collecting more fees. On the long run that would be bad for generators themselves though, as the fee values would fall.
I'm not even sure this is interesting to the generator in the short run itself. He wouldn't collect more fees in the "flooded" blocks he generates.. and he doesn't have a real guarantee of being able to do so in the future blocks either.

Definitely; the worry wasn't flooding but circumventing the artificial scarcity keeping transaction fees above zero.


Again the worry wasn't flooding but keeping the block size small enough to support transaction fees. But anyway, under that scheme, wouldn't it take just one person that fills every block with free transactions to make the block size grow exponentially?

Not to mention that, the larger the block, the longer it takes to propagates it to the network, what I suppose can slightly increase the chance that another block generated by somebody else propagates faster. Really tiny chance, but anyway, it's another counter-incentive to flooding...

There is no economic incentive in flooding. Actually, you can only do it on the blocks you create, otherwise you have to pay fees for it.
So, flooding would be done just by silly people trying to attack the system. They would hardly be sufficiently numerous to make what you say here:


That would only happens if flooders are numerous, what I would doubt. Not to mention that, if the block max size is "just", there will always be quite a good number of paying transactions to be added. Maybe there is enough to fill the block with. There is an incentive not to flood if we think this way.

IIRC, the legitimate chain overtook the "contaminated" chain within the 100-block maturation time, so all transactions were ported to the new chain (except for the illegal ones).

Chain forks are not inherently bad. If the network disagrees about a policy, then a split is good. The better policy will win. If block forks start happening a lot, it would be simple to consider a transaction unconfirmed if it relies on a generation that isn't 500 blocks deep or whatever.

If some "normal user" happened to get a transaction adopted into one of these forks, they'd sure notice.

What decides which part of the chain split is accepted is the 51% of the CPU processing.  This isn't even a theoretical speculation, as there have been similar chain splits in the network already, most notably when the clients upgraded from 0.3.9 to 0.3.10.  The "bad" transactions were thrown into "good" blocks and the block rejected as falling out of the rules by some of the generators but accepted by others.  Yes, it created a mess, but what I'm saying is that the network as already dealt with this situation and it passed with flying colors.

Of course warning messages had to be passed around for everybody to "know" which chain was more likely to be permanently accepted by the network, as it did take place with the upgrade of the clients + generators.  This is also why there is still a warning not to use clients prior to 0.3.10 right now because they are missing some of the rules which stopped what appears to be an attack on the network.

BTW, otherwise "valid" blocks were dropped because they were included in the "wrong" chain, and unfortunately this did include a few legitimate transactions.  Not many transactions were lost, as the warning messages were sent out that it was a problem at the time.


Agreed, but that doesn't imply that the rules to the network must always stay the same either.  The main point is that most of the network must agree to the same rules, and if the rules change it must be something seen to be implicitly necessary to keep the network running... usually to stop spaming or some attack on the network would be the most logical reasons for adding rules.  This is similar to other networking protocols that do changes from time to time, sometimes because of malicious attacks on the network.

The reason to deal with this issue now, rather than later, is that we can talk objectively regarding what solutions or algorithms we might want to implement to resolve this issue.  If there is huge pressure because the transactions are starting to pile up and transaction fees are escalating as a result, any changes in the algorithm and network protocols are going to be seen as being a huge advantage to one group or another and it will become a political process instead.

Politics and computer programming don't mix very well.

Yes, but these particular splits would be very small and unnoticeable for the normal user.

Then you have created a new rule that will split the network.  Part of the point on agreeing in advance on a common set of network rules is to avoid regularly spitting the chain.

Sure there is. Just ignore it and continue building the chain from the previous block.

There is no 'dropping' a valid block, spamming or not.

Which could be prevented if other generators ignore new blocks with lots of unpublished transactions. But that feels a little messy.

Too expensive. But it doesn't matter. This made me realize the whole idea won't work anyway. Generators could just pad their blocks with transactions to themselves with fees set so that they can include as many transactions as they want, i.e. all of them.

The blocks would quickly grow too large.

Hmm, okay outrageous blocks containing only junk would be easy to spot. But what of badly sized say 100k when average is 10k that contain mostly junk, but also the legit transactions that had been received. Maybe now some will reject and some will not? If there is no uniform rule it will be splits all over the place. And even normal users will be affected. If their transaction is in a very oversize block do they just hope it will stay? Or hope it will not be accepted and send again? I think there must be a max block size to avoid this.

Also the "public good of difficulty" comment made me realize that block size may need to be "artificially" limited in some way. But I think updating it along with difficulty to be slightly more than the average size of the previous 2016 blocks, but never decreasing, is a resonable way to do it.

It seems to me that the spam issue and the txfee issue are related. Some want to limit the block size to stop spam and some want to limit it to create an artifical scarcity to drive up txfees.

The problem, as I see it, is that there is NO incentive to NOT accept a fee paying transaction, unless it's ridiculously small. Once a generator has established his infrastructure, It costs a negligible amount to process a transaction. If you can impose some sort of protocol rule on blocks that makes smaller fee transactions less desirable, this would solve both problems.

Automatically adjusting the block size is a solution, if you can find an algorithm that scales appropriately with economic activity. If set too high, there will be too much spam and transactions will be too cheap; generators will leave. If set too low, transactions will become very expensive and people will stop using bitcoin.

Also, there is the idea of restricting the distribution of transactions fees in each block. Like mandating that a frequency distribution of fees fit a linear scale. I don't know if this is workable, I'm just throwing ideas around.

So, I think that we need an incentive for generators to NOT accept fee paying transactions as they get smaller. I particular, build in some sort of fixed cost to processing a transaction, that adjusts with the market.

Nothing, but it stops attackers from drowning legitimate transactions in junk inside the normal blocks. Are gargantuan phony entire blocks really a problem? They will be expensive to produce and won't be long lived as they are extremely hard not to spot and no generators in their right mind would continue building the chain from one of them. They would lose the income from any subsequent blocks when everyone else ditches the offending block. So that should take care of itself through generator self interest.

Wait, so what stops an attacker from generating a block with one million or more spam transactions?