This is not new information, but it may be worth a reminder.

**Traffic, capacity, and bloat**

The "capacity" of the network is the maximum rate C at which transactions can be confirmed.

The "incoming traffic" or "input" is the rate T at which transactions issued by the clients reach the miners. It counts only valid transactions that pay at least the minimum fee.

The "blockchain growth rate" or just "bloat" is the rate V at which the size of the blockchain grows.

For this post, these quantities are most conveniently expressed in bytes of transactions per decaminute (B/Dm); where 1 decaminute is the target interval of 10 minutes between successive mined blocks.  

Thus, with the 1 MB block size limit, the difficulty adjustments should maintain the capacity C close to 1 MB/Dm, when averaged over a sufficiently long period (a month or two).  

However, temporary fluctuations in the block rate will cause corresponding variations in C.  Indeed, recently the [the block rate](https://www.smartbit.com.au/charts/blocks?day_average=28&from=2015-2-1&to=2017-2-1), averaged over a 4-week window, has been over 155 blocks per day, instead of the nominal 144, so C has been about 1.08 MB/Dm.  

(There are also occasional empty blocks due to the way mining pools operate, which keep C somewhat below 1 MB/Dm.  But those empty blocks are now rare, and SegWit would have no effect on them; so we can ignore them.) 

Another relevant quantity is the "queue volume" Q, the amount of unconfirmed transactions in the queue ("mempool") of each miner, waiting to be confirmed.  For this post, it is best measured in bytes.

**Spam, normal traffic, and effective capacity**

Let's define "spam" as any transactions issued by users only for the purpose of sabotaging or stressing the network, or distorting its statistics.

The "normal" incoming traffic Tn is the part of the input T that is not spam. 

The "effective capacity" Cn is the maximum rate at which *normal* input can be confirmed.  

In the absence of spam, Tn is equal to T and Cn is equal to C.  In the presence of spam, Cn may or may not be less than the total capacity C. 

The "normal queue volume" Qn is the part of Q consisting of normal transactons. 

There is no way to tell whether a given transaction is spam or normal, without knowing the intentions of the author.  Thus Tn cannot be objectively measured.  However the distinction is relevant for analyzing the impact of hypothetical spam on Cn (the capacity that matters).

**Backlogs and the standard regime**

For reasons that have been explained elsewhere, the normal incoming traffic Tn should stabilize at a very large fraction of the effective capacity Cn (always in the long-range average sense).

Indeed, currently [the block size](https://blockchain.info/charts/avg-block-size?daysAverageString=28&timespan=2years), averaged over a month, seems to have stabilized at 930 kB, which gives T = 93% of C.  There are allegations that some of that incoming traffic is actually spam; but, in the absence of proof, let's assume Tn = 93% of Cn.  Let's call this codition the "standard regime".

Since Tn and Cn have fairly large variations, however, even in the standard regime there will be periods or hours or days when Tn is quite a bit less than Cn, and periods when Tn will be greater than Cn.  

As a consequence, there will be recurring "backlogs": periods of hours or days when the effective capacity Cn is completely used up, and the mempool holds enough normal transactions to fill all the effectively available space in the next mined blocks.

On the other hand, there will be periods of hours or days of "no backlog" -- when the normal transactions in the mempool plus the normal incoming traffic Tn are not enough to completely use the effective capacity Cn; that is, are not enough to completely fill the space effectively available in the nxt mined blocks. 

A backlog will start to form whenever Tn exceeds Cn for more than a few block periods (say, an hour or more).  During backlogs, the excess normal input Tn-Cn will pile up in the mempool, and Qn will keep growing at that rate.  

The normal queue volume Qn will begin to clear, at the rate Cn-Tn,  only when Tn drops below Cn.  If this condition persists long enough, Qn will eventually be practically zeroed by the next block. Only then the system will enter the "no backlog" situation.  

We can assume that, in spite of backlogs, every valid transaction that pays the minimum fee will eventually be confirmed.  So, in the long run, one will have V = T; although V will be less than T (and equal to C) at certain periods.

**Transaction weight**

Under SegWit, for the computation of transaction priority and block capacity, the size is replaced by the concept of "weight".

The "weight" of a transaction or block is defined as the size of the segregated signatures, plus 4 times the size of the main data (all the other data excluding segregated signatures).  

In particular, if the transaction is in the old format, the weight is just 4 times its size.  If the transaction has little main data but huge segregated signatures, its weight is only a little more than its size.

Let's use "wyte" (W) for the unit of weight, instead of "byte" (B).  Thus, for example, the weight of a transaction with 200 bytes of main data and 150 bytes of segregated signatures is 4*200 + 150 = 950 W.

Under SegWit, the priority of a transaction in the queue would be proportional to its total fee divided by the weight, in satoshis per wyte (instead of satoshis per byte).  The block size limit of 1 MB would be replaced by a block weight limit of 4 MW.

**SegWit effect without spam**

Let's analyze in this section the impact of SegWit in the absence of spam (i.e. Tn = T)

In normal traffic, the size of signatures is claimed (and expected) to be about 55% of the size of the transaction,  on average.  

So, after SegWit has been activated and generally adopted, blocks filled with normal traffic will have about 767 kB of main data and 933 kB of segregated signatures, whose weight will be 4*767 + 933 = 4000 kW.  The actual size of such a block would be 767 + 933 = 1700 kB.   

That is the argument for why SegWit is claimed to give a 70% increase in the effective capacity Cn.

As for blockchain bloat: while SegWit is not activated, the blockchain growth rate will be V = 1 MB/Dm during backlogs, and somewhat less than that when there is no backlog.

After SegWit is fully working the blockchain growth rate V should be 1.7 MB/Dm during backlogs, and somewhat less than that when there is no-backlog.

**Benign spammers**

A "benign" spammer is a user whose goal is only to increase the blockchain growth rate V, but without crowding out much normal traffic -- that is, preserving Cn = C. 

A benign spammer will issue spam transactions with minimum fee.  During backlogs, the spam will just wait in the queue.   Only when there is no backlog will miners put that spam into their blocks.  

So, the effect of the benign spammer will be to raise the confirmed transaction volume V to be equal to the network's maximum capacity C (in the long average sense).

Before SegWit, in the absence of spam we have V = Tn = T, and Tn = 93% of Cn = C. The benign spammer will raise V from T to be equal to C; which means an increase of 7.5% in V (all in the long average sense).

Now suppose SegWit is active and adopted, and the standard regime Tn = 0.93 x Cn has been restored.  The effective capacity Cn for normal transactions, as said above, is expected to be 1.7 MB/Dm, which in terms of weight would be 4 MW/Dm.  But transactions that have a larger proportion of segregated signatures will have bigger size for the same weight.  

Thus the maximum capacity C is actually close to 4 MB/Dm.  It would be achieved, for example, if every input transaction had the minimum main data (1 input, 1 output), and almost 4 MB of segregated signatures; so that its weight would be 4 MW. 

The benign spammer can explot this discrepancy between Cn and C to maximize the bloat V.  Namely, he issues spam transactions with minimum main data and (say) 20 kB of segregated signatures.  

During backlogs, that has no effect every block will be "full" of normal transactions, with about 1.7 MB in size and 4 MW of weight.  

But, when there is no backlog, a block that would have been only half-full -- with 383 + 467 = 850 kB of normal traffic, weight 2 MW -- could be completed with another 2 MW of spam, whose size would be almost 2 MB.  The resulting block would be 2850 kB in size: the 850 kB of effective capacity that were not filled with normal traffic were replaced by almost 2 MB of spam.

Thus, by filling the 7.5% gap from Tn to Cn with signature-heavy spam, the benign spammer can increase the bloat V by 17% 

T and C should be measured in units of *weight*.  Lthe benign spammer can issue spam transactions that have 1 input, 1 output, and (say) 20 kB of segregated signatures, paying the minimum fee.  As in the non-S


That transaction will have about 3 MB of weight, about 3 MB of size, and will pay some fee F1 per kB of weight.  

The remaining 1 MB of block weight would be filled with normal traffic, namely 192 kB of main data and 233 kB of segregated signatures, so that the block size would be 3.425 kB.  

That arrangement is advantageous for a "benign" spammer