From: Damian Williamson <willtech@live.com.au>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering
	Transactions In Blocks
Thread-Index: AQHTa+TfjIfbrac6DkW4WL8VVZ5YaQ==
Date: Sun, 3 Dec 2017 04:07:16 +0000
Message-ID: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
Accept-Language: en-AU, en-US
Content-Language: en-AU
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [X8xwGJ2R6hkD61xn51gWX0d0aZjHwWfU]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT024;
	6:YtiZHmZUs4ErAUroIfiZAaGWsGfyqCPbx72sbEPszzRY1PbZD274sKnHiFFDEAQI15fJjMuzyObCzDjq9CLc0CjcQIaF/fixnt7iMEwga7My81KSXI6HLajCjD5LrvpebzqFefBzLHyKFPiiupDeoqmJTEzdku23IV/XKoZdKmJzWyz4myqVGUdOidCVopeE2nfc8DjRuD7JjlZP3QVXCdW5Ouh87RLH6uRinkS2qYYUELIyQrUBKpi821cnL7G/57D5XaMiOC65beNsOZSenSHJM9qw53LbHuyTOKVIdMeCtNCNWdMfFx/mSz6MhmfsH0qjrDtqTypLRp2qGpK/xL7SPwgzhk58R7mV8KrwvlY=;
	5:zksfLIrQTrU8fluDowr9otFPsRqRWXlewoL5fBBrlTlmEm8dkTc1ts9wsmjuTCfJPR6TQ8crz5Rc/fPx3V++HtBMcWOXymA/4Jf9vZZi9KHCxMt2B7NW4DmnD72wNKtLufc24OWNqIdpLa5x0Ept3+Rl5pkSdXCAVPPVyQ4wOTg=;
	24:nCh/DUCM6keWJSW8KvpVj3UaMH4N0UtkfCJRbmX7P2y5fgT25WVNeRDcXpC+N3dZRGSio8WIEYKwPrfC1L+VNvDHEqJDkC4lRN8jilC6U4Y=;
	7:408Y9gOjDvIryCe1vI5wACWViZ6XVeDbLAwmb0D1E+cQ9tIx8JvmXg/1JM5vI34VGGvjPNa+oZJ1dVJaobEVaBx0IS18fK3kYthW9RBbDGLmA2I5NLKlKTTA62AKJsuW3PHaMZtqBOQltEsCJypbkYad+Z5kolG6ImIqZeEuVyWDAAPuPJwCy3BHolGbuuJa/9rrIijCB+4Wj6/Gf7zV+FnEjUrxh5SiTKV55dH52O6HioUK3rrmPyEWSbyc0Tks
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045);
	SRVR:PU1APC01HT024; 
x-ms-traffictypediagnostic: PU1APC01HT024:
x-ms-office365-filtering-correlation-id: 5e382148-da76-4fe1-d17f-08d53a035761
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:PU1APC01HT024; BCL:0; PCL:0;
	RULEID:(100000803101)(100110400095); SRVR:PU1APC01HT024; 
x-forefront-prvs: 05102978A2
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT;
	SFP:1901; SCL:1; SRVR:PU1APC01HT024;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB01791F54380CD03B3936399E9D3F0PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e382148-da76-4fe1-d17f-08d53a035761
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2017 04:07:16.5165 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT024
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 05 Dec 2017 19:35:09 +0000
Subject: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For
 Ordering Transactions In Blocks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Dec 2017 04:07:20 -0000

--_000_PS2P216MB01791F54380CD03B3936399E9D3F0PS2P216MB0179KORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

# BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions=
 In Blocks

I admit, with my limited experience in the operation of the protocol, the s=
ection entitled 'Solution operation' may not be entirely correct but you wi=
ll 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=3D30 ?); 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 handle=
d by having the protocol determine the target size for the current block us=
ing; current transaction pool size x ( 1 / (144 x n days ) ) =3D transactio=
ns 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 transac=
tions 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 les=
s 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 an=
d time waiting in the transaction pool.

3. Begin selecting transactions to include in the current block using trans=
action weight as the likelihood of inclusion until target block size is met=
.

4. Solve block.


Regards,

Damian Williamson

--_000_PS2P216MB01791F54380CD03B3936399E9D3F0PS2P216MB0179KORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0"># BIP Proposal: UTWFOTIB - Use Tr=
ansaction Weight For Ordering Transactions In Blocks<br>
</p>
<br>
I admit, with my limited experience in the operation of the protocol, the s=
ection entitled 'Solution operation' may not be entirely correct but you wi=
ll get the idea. If I have it wrong, please correct it back to the list.<br=
>
<br>
<p style=3D"margin-top:0;margin-bottom:0">## The problem:<br>
</p>
<br>
<p style=3D"margin-top:0;margin-bottom:0">Everybody wants value. Miners wan=
t to maximize revenue from fees. Consumers want transaction reliability and=
, (we presume) low fees.<br>
</p>
<br>
Current transaction bandwidth limit is a limiting factor for both.<br>
<br>
<p style=3D"margin-top:0;margin-bottom:0">## Solution summary:<br>
</p>
<br>
<p style=3D"margin-top:0;margin-bottom:0">Provide each transaction with a t=
ransaction weight, being a function of the fee paid (on a curve), and the t=
ime waiting in the transaction pool (also on a curve) out to n days (n=3D30=
 ?); the transaction weight serving
 as the likelihood of a transaction being included in the current block, an=
d then use a target block size.
<br>
</p>
<br>
Protocol enforcement to prevent high or low blocksize cheating to be handle=
d by having the protocol determine the target size for the current block us=
ing; current transaction pool size x ( 1 / (144 x n days ) ) =3D transactio=
ns to be included in the current block.<br>
<br>
The curves used for the weight of transactions would have to be appropriate=
.<br>
<br>
<p style=3D"margin-top:0;margin-bottom:0">## Pros:<br>
</p>
<br>
* Maximizes transaction reliability.<br>
* Maximizes possibility for consumer and business uptake.<br>
* Maximizes total fees paid per block without reducing reliability; because=
 of reliability, confidence and uptake are greater; therefore, more transac=
tions and more transactions total at priority fees.<br>
* Market determines fee paid for transaction priority.<br>
<p style=3D"margin-top:0;margin-bottom:0">* Fee recommendations work all th=
e way out to 30 days or greater.<br>
</p>
* Provides additional block entropy and greater security since there is les=
s probability of predicting the next block.<br>
<br>
<p style=3D"margin-top:0;margin-bottom:0">## Cons:<br>
</p>
<br>
* ?<br>
* Must be first be programmed.<br>
* Anything else?<br>
<br>
<p style=3D"margin-top:0;margin-bottom:0">## Solution operation:<br>
</p>
<br>
<p style=3D"margin-top:0;margin-bottom:0">As I have said, my simplistic vie=
w of the operation. If I have this wrong, please correct it back to the lis=
t.<br>
</p>
<br>
1. The protocol determines the target block size.<br>
<p style=3D"margin-top:0;margin-bottom:0">2. Assign each transaction in the=
 pool a transaction weight based on fee and time waiting in the transaction=
 pool.<br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">3. Begin selecting transactions t=
o include in the current block using transaction weight as the likelihood o=
f inclusion until target block size is met.<br>
</p>
4. Solve block.<br>
<br>
<p style=3D"margin-top:0;margin-bottom:0">Regards,</p>
<p style=3D"margin-top:0;margin-bottom:0">Damian Williamson<br>
</p>
</div>
</body>
</html>

--_000_PS2P216MB01791F54380CD03B3936399E9D3F0PS2P216MB0179KORP_--