I also am for the idea of removing blocksize limits if it is workable, however, would propose an alternative method for selecting transactions to be included in a block.

Some of the issues discussed in other replies to this thread are valid.

Alternative proposal:

Provide each transaction with a transaction weight, being a function of the fee paid (on a curve), and the time waiting in the pool (also on a curve) out to n days (n=30 ?), the transaction weight serving as the likelihood of a transaction being included in the current block, and then use an uncapped block size. The curve allows that the higher a fee allows a transaction to be much more likely to be included, the highest fee gets 100%, and, transactions at the n days limit get near 100%. Would need protocol enforcement since, as I understand, no miner would mine more transactions than are necessary to meet min blocksize. Other than that it should function fine. Non-urgent transactions pay a lower fee, people choose fees from fee recommendation based on how many days before a tx begins confirmation, all transactions are eventually included in the blockchain.

Regards,

Damian Williamson

Comrades,

Long term, tx fees must support hash power by themselves. The following is an economic approach to maximize total fee collection, and therefore hashpower.

Goals

Maximize total transaction fees

Reduce pending transaction time

Reduce individual transaction fees

Challenges

Validators must agree on the maximum block size, else miners can cheat and include extra transactions.

Allowing too many transactions per block will increase the cost of the mining without collecting much income for the network.

Problem

In the transaction market, users are the demand curve, because they will transact less when fees are higher, and prefer altcoins. The block size is the supply curve, because it represents miners' willingness to accept transactions.

Currently, the supply curve is inelastic:

Increasing the block size will not affect the inelasticity for any fixed block size. The downsides of a fixed block size limit are well-known:

- Unpredictable transaction settlement time

- Variable transaction fees depending on network congestion

- Frequent overpay

Proposal

1. Miners implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block. Excess transaction fees are refunded to the inputs.

2. Remove the block size limit, which is no longer necessary.

Benefits

- Dynamic block size limit regulated by profit motive

- Transaction fees maximized for every block

- No overpay; all fees are fair

Miners individually will make decisions to maximize their block-reward profit.

Miners are incentivized to ignore low-fee transactions because they would shave the profits of their other transactions and increase their hash time.

Users and services are free to bid higher transaction fees in order to reach the next block, since their excess bid will be refunded.

The block size limit was added as a spam-prevention measure, but in order for an attacker to spam the network with low-fee transactions, they would have to offset the marginal cost of reducing the price with their own transaction fees. Anti-spam is thus built into the marginal system without the need for an explicit limit.

Rarely, sections of the backlog would become large enough to be profitable. This means every so many blocks, lower-fee transactions would be included en masse after having been ignored long enough. Low-fee transactions thus gain a liveness property not previously enjoyed: low-fee transactions will eventually confirm. Miners targeting these transactions would be at a noteworthy disadvantage because they would be hashing a larger block. I predict that this scheme would result in two markets: a backlog market and a real-time market. Users targeting the backlog market would match the price of the largest backlog section in order to be included in the next backlog block.

Examples

Scenario 1

Sat/byte	Bytes	Reward
400	500000	200000000
300	700000	210000000
200	1000000	200000000
100	1500000	150000000
50	5000000	250000000
20	10000000	200000000

A miner would create a 5MB block and receive 0.25 BTC

Scenario 2

Sat/byte	Bytes	Reward
400	600000	240000000
300	700000	210000000
200	1000000	200000000
100	1800000	180000000
50	4000000	200000000
20	10000000	200000000

A miner would create a 600KB block and receive 0.24 BTC

Thanks,

William Morriss