Good morning Damian,
The primary problem in your proposal, as I understand it, is that the
"transaction pool" is never committed to and is not part of consensus
currently. It is unlikely that the transaction pool will ever be part of
consensus, as putting the transaction pool into consensus is effectively
lifting the block size to include the entire transaction pool into each block.
The issue is that the transaction pool is transient and future fullnodes cannot
find the contents of the transaction pool at the time blocks were made and
cannot verify the correctness of historical blocks. Also, fullnodes using
-blocksonly mode have no transaction pool and cannot verify incoming blocks for
these new rules.
Applying a patch that follows this policy into Bitcoin Core without enforcing
it in all fullnodes will simply lead to miners removing the patch in software
they run, making it an exercise in futility to write, review, and test this
code in the first place.
In addition, you reuse the term "weight" for something different than its
current use. Current use, is that the "weight" of a transaction, is the
computed weight from the SegWit weight equation, measured in virtual units
called "sipa", using the equation (4sipa / non-witness byte + 1sipa/witness
byte).
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> -------- Original Message --------
> Subject: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For
> Ordering Transactions In Blocks
> Local Time: December 6, 2017 3:38 AM
> UTC Time: December 5, 2017 7:38 PM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: bitcoin-dev@lists.linuxfoundation.org
> <bitcoin-dev@lists.linuxfoundation.org>
>
> # BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions
> In Blocks
>
> I admit, with my limited experience in the operation of the protocol, the
> section entitled 'Solution operation' may not be entirely correct but you
> will get the idea. If I have it wrong, please correct it back to the list.
>
> ## The problem:
>
> Everybody wants value. Miners want to maximize revenue from fees. Consumers
> want transaction reliability and, (we presume) low fees.
>
> Current transaction bandwidth limit is a limiting factor for both.
>
> ## Solution summary:
>
> Provide each transaction with a transaction weight, being a function of the
> fee paid (on a curve), and the time waiting in the transaction 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
> a target block size.
>
> Protocol enforcement to prevent high or low blocksize cheating to be handled
> by having the protocol determine the target size for the current block using;
> current transaction pool size x ( 1 / (144 x n days ) ) = transactions to be
> included in the current block.
>
> The curves used for the weight of transactions would have to be appropriate.
>
> ## Pros:
>
> * Maximizes transaction reliability.
> * Maximizes possibility for consumer and business uptake.
> * Maximizes total fees paid per block without reducing reliability; because
> of reliability, confidence and uptake are greater; therefore, more
> transactions and more transactions total at priority fees.
> * Market determines fee paid for transaction priority.
>
> * Fee recommendations work all the way out to 30 days or greater.
>
> * Provides additional block entropy and greater security since there is less
> probability of predicting the next block.
>
> ## Cons:
>
> * ?
> * Must be first be programmed.
> * Anything else?
>
> ## Solution operation:
>
> As I have said, my simplistic view of the operation. If I have this wrong,
> please correct it back to the list.
>
> 1. The protocol determines the target block size.
>
> 2. Assign each transaction in the pool a transaction weight based on fee and
> time waiting in the transaction pool.
>
> 3. Begin selecting transactions to include in the current block using
> transaction weight as the likelihood of inclusion until target block size is
> met.
>
> 4. Solve block.
>
> Regards,
>
> Damian Williamson
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
