Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks

[Erik Aronesty <erik@q32.com>]

[-- Attachment #1: Type: text/plain, Size: 5656 bytes --]

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 <willtech@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 <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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 8704 bytes --]