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

From: Jim Renkel <jim.renkel@comcast•net>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks
Date: Tue, 5 Dec 2017 23:18:11 -0600	[thread overview]
Message-ID: <52700305-585d-4239-134e-ac8c5b6c4165@comcast.net> (raw)
In-Reply-To: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>

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

As i understand it, the transactions to be included in a block are 
entirely up to the miner of that block.

What prevents a miner from implementing the proposal on their own?

If this is adopted as some kind of "policy", what forces a miner to 
follow it?

Jim Renkel

On 12/2/2017 10:07 PM, Damian Williamson via bitcoin-dev wrote:
>
> # 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

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