public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Damian Williamson <willtech@live•com.au>
To: "bitcoin-dev@lists•linuxfoundation.org"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks
Date: Sun, 3 Dec 2017 04:07:16 +0000	[thread overview]
Message-ID: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM> (raw)

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

# 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

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

             reply	other threads:[~2017-12-03  4:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-03  4:07 Damian Williamson [this message]
2017-12-06  5:18 ` Jim Renkel
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=PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM \
    --to=willtech@live$(echo .)com.au \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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