Good morning ZmnSCPxj,

Actually, there is no incentive to cheat target block size by providing a next block size that is higher or lower than the proposal would give. Under the proposal the transaction pool can grow quite large. A low next block size just defers collecting transaction fees, while a high next block size shrinks the transaction pool and thereby lowers fees. It seems like a standoff. This is especially true if the curve for time waiting in the transaction pool is extended beyond n days, since it is a curve, after waiting longer than 60 days (if n = 60 days) a transaction would have a priority greater than one-hundred and would therfore be the first transaction included with no possibility of failing the likelihood, so, even low fee paying transactions would be included first if the pool size is growing through incorrectly providing the next block size.

As it is now, I presume, a miner could include exactly one transaction in a block and pad?

Regards,

Damian Williamson

Good morning ZmnSCPxj, it must be where you are,

I suppose that we are each missing each other's point some.

I understand that nodes would not be expected to agree on the transaction pool and do not propose validating that the correct transactions are included in a block. I speak of probability and likelihood of a transaction being included in a block, implying a random element. I do not propose rejecting blocks on the basis that the next block size is stated too large or too small for the transaction pool, only that the block received conforms to the next block size given on the previous block. Yes, it could be cheated. Also, various nodes may have at times wildly different amounts of transactions waiting in the transaction pool compared to each other and there could be a great disparity between them. It would not be possible in any case I can think of to validate the next block size is correct for the current transaction pool. Even as it is now, nodes may include transactions in a block that no other nodes have even heard of, nodes have no way to validate that either. If the block is built on sufficiently, it is the blockchain.

I will post back the revised proposal to the list. I have fleshed parts of it out more, given more explanation and, tried this time not to recycle terminology.

Regards,

Damian Williamson

From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Thursday, 7 December 2017 5:46:08 PM
To: Damian Williamson
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks

Good morning Damian,

>As I understand it, each node would be aware independently of x transactions waiting for confirmation, the transaction pool.

Each long-running node would have a view that is roughly the same as the view of every other long-running node.

However, suppose a node, Sleeping Beauty, was temporarily stopped for a day (for various reasons) then is started again. That node cannot verify what the "consensus" transaction pool was during the time it was stopped -- it has no view of that. It can only trust that the longest chain is valid -- but that means it is SPV for this particular rule.

>If next blocksize is broadcast with the completed block it would be a simple matter to back confirm that.

It would not. Suppose Sleeping Beauty slept at block height 500,000. On awakening, some node provides some purported block at height 500,001. This block indicates some "next blocksize" for the block at height 500,002. How does Sleeping Beauty know that the transaction pool at block 500,001 was of the correct size to provide the given "next blocksize"? The only way, would be to look if there is some other chain with greater height that includes or does not include that block: that is, SPV confirmation.

How does Sleeping Beauty know it has caught up, and that its transaction pool is similar to that of its neighbors (who might be lying to it, for that matter), and that it should therefore stop using SPV confirmation and switch to strict fullnode rejection of blocks that indicate a "next blocksize" that is too large or too small according to your equation? OR will it simply follow the longest chain always, in which case, it trusts miners to be honest about how loaded (or unloaded) the transaction pool is?

-------

As a general rule, consensus rules should restrict themselves to:

1. The characteristics of the block.

2. The characteristics of the transactions within the block.

The transaction pool is specifically those transaction that are NOT in any block, and thus, are not safe to depend on for any consensus rules.

Regards,

ZmnSCPxj