From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5937C6C for ; Sun, 3 Dec 2017 04:07:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254046.outbound.protection.outlook.com [40.92.254.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1D6313FB for ; Sun, 3 Dec 2017 04:07:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yAgG2aYJKy/62cwNjKMcRLqdwGi6KuFcMPVjWBJXCrs=; b=JnynaNVkteQ6jC4enzEPgyYAJlwhatw5TO6/0QsO6LzvkK6vsbXuvap/72uT0H/k3mwlS7K0M7uZOFfaoarvyLY4zMTgnybYt8z+cLetLcXPqyuOdZQshWTrEq22qA5xuXBnU8rbyPv0QnQnvqGXJ2N2GPUKDth8QPTzWqz4D79IKY1I7icTif7Z8qB7yFCtzM5+wYgDe0JQbosct4p+p6QVUIQPK6lad8R6pTo8ao+P1ZVgDOS6J+bU63Syc6HHOJpvTccEqV70bCPjzF5JBdsUxBKHVnumwtOteUWfYbHHYYK3WRr+MeS903hXHIB//rCAE6Dxw/IHJ2OeFmns+A== Received: from PU1APC01FT026.eop-APC01.prod.protection.outlook.com (10.152.252.51) by PU1APC01HT024.eop-APC01.prod.protection.outlook.com (10.152.253.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Sun, 3 Dec 2017 04:07:16 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.55) by PU1APC01FT026.mail.protection.outlook.com (10.152.252.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4 via Frontend Transport; Sun, 3 Dec 2017 04:07:16 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) by PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) with mapi id 15.20.0282.007; Sun, 3 Dec 2017 04:07:16 +0000 From: Damian Williamson To: "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: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:68EDE8FD7509A5038831F8946FED13A3EED08C72FD7D5462661F644FA66FC2DD; UpperCasedChecksum:31ACB29332E5D2E8DF6A61C6E4145338A9B712FB726F6C34E8C821764DD01A1D; SizeAsReceived:6977; Count:44 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

# BIP Proposal: UTWFOTIB - Use Tr= ansaction 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 wan= t 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 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.


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 th= e 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 vie= w of the operation. If I have this wrong, please correct it back to the lis= t.


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 t= o include in the current block using transaction weight as the likelihood o= f inclusion until target block size is met.

4. Solve block.

Regards,

Damian Williamson

--_000_PS2P216MB01791F54380CD03B3936399E9D3F0PS2P216MB0179KORP_--