You can feel free to write this version and try to get miners to use it. That's the nice thing about Bitcoin.
On Thu, Dec 7, 2017 at 3:49 PM, Damian Williamson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > ------------------------------ > *From:* Damian Williamson <willt...@live.com.au> > *Sent:* Thursday, 7 December 2017 7:13:14 PM > *To:* ZmnSCPxj > > *Cc:* bitcoin-dev@lists.linuxfoundation.org > *Subject:* Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction > Weight For Ordering Transactions In Blocks > > > 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 <zmnsc...@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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
