[Discussion] Variable Block Size

[Nagalim]

https://wiki.peercointalk.org/index.php?title=Preventing_Network_Spam

1. Allow network to vote on blocksize.

2. Pick a target filling factor that gives a good amount of head room, like 25%.

3. Use the current fee vote to instead vote on x, which is the dust size, the minimum fee amount, and the fee step.

4. Implement a smoothed step fee using NewFee = OldFee + x * ( FillingFactor / TargetFillingFactor - 1)

Thereby, the network will seek to keep blocks 25% full at all times and will respond quickly to a Type 1 Spam attempt (DOS) with up to 3x/block speed. In my opinion, this would fully solve the problems the bitcoin community is facing right now concerning block size.

[masterOfDisaster]

I’m a bit sorry that the discussion starved in the Peercoin community, but I think it’s utterly important to have such a feature - both at Peercoin and at Nu.

While I think the danger is (in terms of blockchain size) bigger for Peercoin, because its blockchain is really small and it has to lose more (so far) saved blockchain space than Nu, Nu has a different development speed and is after all a business that needs to create countermeasures against abuse. Nu needs to care for it’s business (the blockchain is already quite big compared to Peercoin)

The goal must be (for both) to effectively limit spam.
Regular customers mustn’t be affected from the usability of the network caused by (cheap!) spam.

Voting on the tx fee directly is rather slow and I doubt it can effectively limit cheap spam.
Your proposal for automatic adjustment seems to improve that immensely, as far as I understand it.

One thing, I want to point out:

• if FillingFactor is smaller than TargetFillingFactor, NewFee will be reduced instead of increased. In edge cases that could lead to negative fees, right? There might be the need for a floor.

[Nagalim]

fixed the typo

Yes, this formula brings the fee back down after a DOS attempt as well as spiking it. The voted fee is not only the step but also the dust size (min output size) and the minimum fee (if NewFee < x, then NewFee = x).

[masterOfDisaster]

Sounds simple and effective.
I want to have it!

What about a permanent reduction of the fee? Nothing limits it from becoming negative, right?
If there’s a positive x, continuously 0 size consumed (FillingFactor=0) and the TargetFillingFactor is bigger than 0, the formula gets reduced to

NewFee = OldFee + x * ( 0 / TargetFillingFactor - 1)
= OldFee + x * ( 0 - 1)
= OldFee + x * (-1)
= OldFee - x

Each block the fee gets reduced by x.
It’s only a matter of time until the fee is negative and you earn money by sending transactions.
There needs to be a floor through a simple case distinction.

if NewFee < x; then
NewFee = OldFee

[Nagalim]

For clarification, think of the equilibrium case: the network continually has 25% full blocks. If we assume the shareholders have come to consensus on block size based off hardware requirements (funny enough, implementing a continuous vote means this is necessarily true) then the appropriate network fee will be found regardless of x, as long as x is smaller than the appropriate fee. Note that we are not necessarily aiming for 25% full blocks if we think we need a certain x value to have good DOS reaction time. For instance, in the current network I would expect an x of 0.01 and a blocksize of 1 MB would cause the network to be mostly unchanged because we are currently under the 25% threshold, and we would stay that way. If shareholders started lowering the max block size, I think it would be similarly interesting to boast a small block size as a large one to the greater crypto community.

[Nagalim]

if NewFee < x; thenNewFee = OldFee

(if NewFee < x, then NewFee = x).

We want it to go to x as the minimum, not get stuck somewhere weird.

[masterOfDisaster]

We want it to go to x as the minimum, not get stuck somewhere weird.

Makes sense!

[Nagalim]

Let’s pretend the network gets DOSd, filling every block. Let’s say our window of average is 10 blocks with 1 MB blocks, x=0.01 NBT/KB. Let’s assume no other transactions other than the spammer, who begins filling up every block. Also, MB is ~1000 KB. So that’s $10/block for the first block. The second block is also $10/block, as is the third. The fourth, however, is at a fee of 0.01+0.01*(0.3/0.25-1)=$12.
5th block costs $18
6th block costs $28
7th block costs $42
8th block costs $70
9th block costs $92
10th block costs $118
11th block and thereafter add $30 each time.
So after only 10 minutes, the spammer is paying over $100/minute and counting. After the spammer ceases, the network fee is still only like 10 cents, though it’s slow about going back down to the previous 1 cent levels (takes maybe an hour depending on how long the attack persists).

By the way, a lag of like 5 blocks on the averaging window would increase the ramp up time by like 5 minutes but would give clients a chance to react and would overcome most of the reasoning behind RBF without us having to go down that road because the fees are predictable as long as you get picked up by the majority of nodes within those 5 blocks.

[masterOfDisaster]

That means a tx, that is sent by a regular user, with a tx fee that is below the minimum fee (that was raised due to the spam), is delayed until everything is normal?
If that’s the case, it doesn’t sound too bad.
And if users just pay double the minimum fee, they have a good chance to have the tx put into a block before the required fee is too high, right?
I’m not sure whether that’s the standard behaviour of a minting Nu wallet application. But it would make sense to prefer those tx for including them into blocks, which have more fee than necessary. Destroyed fees are final revenue. That’S good for the minters!

Maybe it’s because I’m really tired:
why does it take 5 blocks (for an average window of 10 blocks) to effectively start raising the fee in your scenario (with target 25%)?
Wouldn’t it start from the third block on?
If there are no tx, but those from the spammer and all blocks before had 0 size, then from the third block on, the rolling window of 10 blocks is at average 30%, which is above 25%.

[Nagalim]

The 5 blocks mentioned in your second paragraph is the solution to the concerns in your first paragraph. It should not take 5 blocks for a txn to propagate to the network, so if we put a 5 block buffer the fee will be predictable by the client, even in times of type 1 spam.

[masterOfDisaster]

times of type 1 spam

In which coinage plays a role for the incentive to include a tx in a block?
Yah, that would prefer regular users to spammers who recently bought the coins.
What to do with spammers, who plan that spam for some time, buy coins and wait until they have some age?

[Nagalim]

The really scary spam is the one where the spammer starts paying $100/block right off the bat. So for like 15 blocks no txn can go through as the automatic fee catches up to the spammer. So if the fee never goes back down, or if x increases during this time, what happens to the txns that never went through back when the spam attack started at a low fee? Do we send back the 0-conf txns after too many blocks of being too low a fee? Do we do some kind of RBF? How can 0-conf txns be trusted in that case unless they are sent with an exhorbitant fee?

Edit: the solution to this type of attack is cpfp (child pays for parent). There will only be a few blocks of txns from the beginning of the DOS attempt, no need to bring down all of 0-conf to get them processed.