Hello Jim,

The variable block sizes would not, as I understand it, be easily implemented 
by a solo miner.


You are right, there is presently nothing stopping a miner from ordering the 
transactions included by a priority that is not entirely based on the fee.


It may be possible to verify blocks conform to the proposal by showing that the 
probability for all transactions included in the block statistically conform to 
a probability distribution curve, if that is necessary and,  *if* the 
individual transaction priority can be recreated. I am not that deep into the 
mathematics, however, it may also be possible to use a similar method to do 
this just based on the fee, that statistically, the blocks conform to a fee 
distribution. Needs a clever mathematician.


It is certainly possible to verify that blocks conform to the expected size.


Honour is why people follow policy without enforcement. I may be in the wrong 
group. (sic)


Regards,

Damian Williamson

________________________________
From: bitcoin-dev-boun...@lists.linuxfoundation.org 
<bitcoin-dev-boun...@lists.linuxfoundation.org> on behalf of Jim Renkel via 
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Wednesday, 6 December 2017 4:18:11 PM
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For 
Ordering Transactions In Blocks


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<mailto: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

Reply via email to