Quote from: Lauda on March 08, 2016, 07:57:21 PM

Quote from: David Rabahy on March 08, 2016, 07:49:29 PM

Thank you Lauda: https://en.wikipedia.org/wiki/Quadratic_growth ... ouchie; so if a 1MB block with y transactions in it takes x seconds to validate then 32 similar 1MB blocks will take about 32x seconds but a 32MB block can be expected to take about (32y)²x seconds. Or is the quadratic growth on something other than transaction count?

It can be a bit tough to understand (I feel you). The number of transactions is irrelevant from what I understand. it is possible to construct a single transaction that would fill up a block. From the Core roadmap:

Quote

In 2MB blocks, a 2MB transaction can be constructed that may take over 10 minutes to validate which opens up dangerous denial-of-service attack vectors.

The validation time of the block itself is what has quadratic scaling. From one of the workshops last year (might help understand the problem):

Quote

So how bad is it? There was a block consisting of one transaction in the coinbase, it was broadcasted about one month ago. It was f2pool that was clearing up a bunch of spam on the blockchain. The problem is that this block takes 30 seconds to validate. It's a 990 kilobyte transaction. It contains about 500,000 signature operations, which each time serializes the entire 1 MB transaction out, moves buffers around, then serializes it, then hashes it, it creates 1.25 GB. The bitcoin serializer is not fast, it's about where 60% of the validation time was. So 30 seconds to validate and that's on a beefy computer, I don't know what that is on a raspberrypi, it's not linear it's quadratic scaling... If you are doing 8 MB, then it's 2 hours and 8 minutes. There are some ways that gavinandresen has proposed that this can be fixed. This transaction would be considered non-standard on the network now, but miners can still generate these transactions.

Sincerely, thank you Lauda: I really do try hard to understand and your patience is much appreciated. It did seem unreasonable for the scaling to hinge on transaction count. Serialization is a classic scaling killer. So, one very large transaction with numerous sigops leads to the quadratic growth. Hmm, so blindly increasing the block size is asking for trouble. How many of these troublesome transactions are launched against us recently? Or is it an unexploited vulnerability?

Perhaps we could increase the block size *and* constrain sigops/transaction until we get SegWit out the door?