Topic: Blocksize limit method (Read 908 times)

While it is true that such a miner would have zero cost to perform that attack, he does have the opportunity cost of the fact that he makes no profit on tx's that he used to pad the block.  So it can't be said that his attack is free and even though he is making mining less profitable for small miners he is also making mining less profitable for himself.  As long as the blocksize limit isn't allowed to fluctuate wildly he would be in for a very long arduous battle with few detrimental effects early on giving others plenty of time to recognize the attack.

Also, if the code can determine that such an attack is being made we can use some unpredictable value (such as the block hash) to sometimes increase the block size using the method I mentioned and sometimes shrink the block size by some percent of what it was increased by in the previous block.  Even a very rough estimate of how many transactions were padded would probably be enough to make the attack too weak to implement.
For example:
If the hash for block [n] is even we use the method above (or similar) to come up with the limit for block [n+1].  The amount it is increased by is K.
If the hash for block [n] is odd we subtract some % of K from block [n+1...n+m]'s (when we have multiple odd hashes) limit.
K is determined in his padded blocks so the attacker can't pad only odd ones.

We wouldn't neccesarily have to use the hash.  Any value that is unpredictable, but agreed upon by the network and converges to a stable value can be used.

No, it is not true.

The mining farm does not need to broadcast their own transactions to the network.  They can simply pad out their own blocks with the transactions, and the first time any other node will hear about the transactions is when they receive the block.  Therefore, the other 60% of the network will never receive the fees from the transactions that the mining farm is using to pad their blocks.

I was not suggesting doing this to create new blocks.

From a block already confirmed with C confirmations we calculate a new max block size from its list of tx's (which is agreed on) according to the method I mentioned. This new max block size will be thrown into the hash the miner has to complete to create the new block so the information keeps getting updated - Every miner knows what the max block size limit is for the current block.

I envisioned the spamming with large fees to approximate the 51% percent attack on network hashing power.  If the hostile miner (or group) has only 40% of the hashing power the attack still costs 60% of his fees.  Is this not true?

There is no consensus on the number of ignored transactions so this factor cannot be used as part of a protocol rule.

An intelligent sibyl attack is possible.

My example was an extreme case within the constraints of the proposed system, but any modification that you make to the system would simply result in the large mining farm adjusting their behavior to look like a legitimate increase in transactions to increase the block size over time.  If you choose to ignore blocks based on some criteria, then you risk ignoring legitimate blocks from other miners.  The side effects of miners no longer choosing the largest proof-of-work are likely to be very messy, and open many avenues of attack.

Assuming such a strategy, could it be significantly weakened by only deriving the limit from block fees within 1 standard deviation from the mean? So a miner padding blocks with large fees to himself might find all, or nearly all, of his blocks unused for the calculation? Unless, of course the miner is somewhere near 50%, but such behavior would be spotted a long way off, and if a pool, would soon be hit by defections.

But what if there is NO cost, and a significant incentive?

Specifically, a large mining farm with very high internet bandwidth can pad every block that they mine with transactions paying a high fee until the block is completely full.  This padding will increase the SMA with high fee transactions, but it won't cost the mining farm anything since they'd be paying those fees to themselves.  (There's the zero cost).

By significantly increasing the block size over time, the mining farm can drive out smaller miners that have slower internet connections and less resources available.  Less miners means they have a larger percentage of the total mining hashpower, which means they solve more blocks over time, which increases their profits. (There's the significant incentive).

-Optimal block size limit seems to be the smallest size that does not cause a backlog of transactions and does not send fees to zero.

-Assuming no malicious intent we can simply take the simple moving average (SMA) of the total size of transactions (S) in the last N blocks and divide it by the target utilization of the current block limit to get the new block limit.

-To stop malicious intent simply take S, but ignore zero-fee/byte transactions as well as the lowest 50% of fee/byte tx's as the input for the SMA.  After calculating the SMA simply divide it by one minus the percent of transactions ignored.


for N=1 blocks, using 50% of the blocksize limit, and a block like this:
*assuming all TX's are equal in size

TX#      Fee/byte   bytes
TX1      0      250
TX2      0      250
TX3      .5      250
TX4      1      250
TX5      2      250
TX6      3      250


The naive method gives us a limit of (250*6/1block)/.5 = 3kb.

For the hardened method we first ignore the zero-fee tx's and then average the remaining ones.
(.5+1+2+3)/4=1.625 average fee/byte.
We use the size of tx's with fees greater than 1.625fee/byte for the SMA and then divide by one minus the percent of transactions ignored.
[(250*2/1block)/(1-.666)]/.5=3kb

Not complex
Spamming zero-fee tx's has no effect
Spamming fee/byte tx's lower than average does not benefit the spammer if his goal is to manipulate block-size limit.  This increases miner rewards.
Spamming fee/byte tx's higher than average increases miner rewards, but could have an effect on the block size limit.
The target utilization rate is a simple way to chose a balance among the trade-offs inherent in any blocksize limit.

Risks
If an attacker spammed many high-fee tx's he could alter the block size limit.  I believe this is unlikely do to the limited incentive and the high fee cost.  Furthermore, an additional variable could be added to limit the rate at which the block size limit can be changed thus prolonging the length of time it takes for the attack to succeed and therefore the cost for the attack to be successful.  As bitcoin gains more and more honest users the cost of this attack also increases dramatically.

I am relatively new to bitcoin, so pardon my ignorance if I've misunderstood something.