public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2017-12-06  5:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-03  4:07 [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks Damian Williamson
2017-12-06  5:18 ` Jim Renkel [this message]
2017-12-07  6:34   ` Damian Williamson
2017-12-06  5:46 ` ZmnSCPxj
2017-12-06  9:27   ` Damian Williamson
2017-12-07  6:46     ` ZmnSCPxj
2017-12-07  8:13       ` Damian Williamson
2017-12-07 20:49         ` Damian Williamson
2017-12-07 21:39           ` Erik Aronesty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52700305-585d-4239-134e-ac8c5b6c4165@comcast.net \
    --to=jim.renkel@comcast.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox