# Last edited on 2016-07-04 10:38:29 by stolfilocal # For reddit /r/bitcoin_uncensored # NOT POSTED YET On 2010-09-30, Satoshi posted to bitcointalk [a proposal for a tiered fee structure](https://bitcointalk.org/index.php?topic=1314.msg14732#msg14732): It ramps up the fee requirement as the block fills up: <50KB free 50KB 0.01 250KB 0.02 333KB 0.03 375KB 0.04 etc. It's a typical pricing mechanism. After the first 50KB sells out, the price is raised to 0.01. After 250KB is sold, it goes up to 0.02. At some price, you can pretty much always get in if you're willing to outbid the other customers. Just including the minimum 0.01 goes a long way. (Thanks to /u/pb1x for pointing this out.) To put things in context, that post was in a thread about the new "-paytxfee" wallet option that he had just implemented, that let users specify the transaction fee; and other developers were asking what that option was for, and whether it was a good idea. It is also worth remembering that the average block size at the time was less than 10 kB (maybe [less than 1 kB](https://bitcointalk.org/index.php?topic=994.msg12237#msg12237)), the price at MtGOX was ~0.06 USD/BTC, and Satoshi was still assuming that zero-fee transactions would always be guaranteed passage. Still, it seems useful to analyze his proposal and compare it with the "fee market" that the Core devs are implementing (by refusing to increase the 1 MB block size limit). As usual, Satoshi's post is quite terse and a bit cryptical. Here is my best understanding of is proposal: + There are a number of fee levels or *tiers* numbered 0, 1, 2, ... (the rows of Satoshi's table) + A transaction is in tier k if it includes a fee of at least (k-1) x F but no more than k x F, where F = 0.01 BTC (the second column of the table) + Each tier k has a guaranteed space allocation in each block, with S[k] bytes (the numbers in the first column of the table); for example, S[0] = 20 kB, S[1] = 50 kB, S2 = 250 kB, etc. These allocations are nested, so that S[k] is actually the space for all transactions from 0 to k. + Each miner keeps a set of unconfirmed transaction queues, Q[0], Q[1], ..., one for each tier, with each queue sorted in chronological order. **When a miner receives a transaction** that pays the fee of tier k, he adds it to the queue Q[k]. Then, he may want to rebuild the candidate block that he is mining, as follows. If the total size of all trasactions in all queues is still less than 1 MB, he puts all those transactions in the new block. Otherwise, he scans the tiers in increasing order, and adds to the new block the first transactions from each queue Q[k], in chronological order, while the block size does not exceed S[k]. **When a miner succeeds in mining a block**, he of course removes from the queues Q[k] all transactions that were included in that block. **When a user needs to issue a transaction**, he chooses the fee as follows. He gets from miners the total byte size |Q[k]| of the transactions in each queue Q[k]. By simulating the miners' algorithm, he can predict fairly accurately how many blocks he would have to wait if he paid the fee of tier k, for each k. Then he chooses the tier that fits his preferences for delay and cost. For comparison, in the "fee market" model, each miner is supposed to keep a single queue Q of all unconfirmed transations, sorted by their fee (in BTC/kB). Whenever a new transaction arrives, the miner ads it to Q. Then he may decide to reassemble the candidate block he is mining, by taking transactions from the top of Q, until filling the block. The typical client would get the Notes: + Satoshi did not suggest an explicit value for S[0], except that it was to be something less than 50 kB. + In [his very next post](https://bitcointalk.org/index.php?topic=1314.msg14734#msg14734), he considers that the fees and tiers shoudl be BTC/kB instead of BTC/tx. (But it does not seem to make an essential difference to the method). **Compared to the current idea of the "fee market"**, that tiered schema has some significant advantages. Suppose that a client issues a transaction T of fee tier k. Let tQ be the time when the client fetched the queue sizes |Q[0]|, |Q[1]|, .... from the miners. Let tM be time when his transaction reaches the miners, and tC the time when it is confirmed. In Satoshi's schema, as interpreted above, the confirmation time tC predicted by the client, when he issued T, can be delayed only by transactions with tiers between 0 and k that are issued by other clients in the short window between tQ and tM. Moreover, among those transactions, those of tiers from 0 to k-1 s have only a limited efect, since transactions of tier k have a minimum bandwidth of S[k] - S[k-1] bytes per block reserved for them. In contrast, in the "fee market" model, the delay predicted by that client may be increased by transactions that pay more than T pays, an are issued anytime between tQ and **tC**. In fact tC can be repeatedly postponed for hous or days, by transactions issued well after tM. There is no formula that the client can use to determine a proper fee to ensure some wait. Under the "fee market", a client can bump the priority of his stuck transaction after tM with RBF or CPFP. However, the client must get online to do that. He also must guess again a suitable fee; but, even so, his transaction may get delayed by hours or days. Neither system works well if the incoming demand is larger than the total capacity of the network (1 MB every 10 minutes) for an extended period. In that case, the queues will grow without bound, until users abandon bitcoin and the demand subsides to be lower than the capacity. Let D(F,T) be the average traffic (in bytes per block) that users would issue if they had to pay a fee F per byte and wait T blocks. The demand has variations on daily, weekly, and random patterns. With the fee market, users will leave the system until the demand, averaged on a weekly basis, will be eventually settle to be somewhat less than capaciy. Let's ignore the fluctuations of demand for now. With the fee market, the traffic would be limited to 1 MB/block, and the fees would be F1 such that D(F1) = 1 MB. Users will drop out partly because of fees, partly because of delays. With Satoshi's tiered schema,