Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8B8FD927 for ; Thu, 7 Dec 2017 06:34:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255069.outbound.protection.outlook.com [40.92.255.69]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 01149A3 for ; Thu, 7 Dec 2017 06:34:42 +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=wxj5PUvLUgY4M68PEr3emNy0WIrCbpfs1b7XYqLpUjU=; b=rTEUV6fBhAaFsBm9f7cZRf5XKMepvXxuU23Gq0clmxdCf7hBEIIxS+Hl9n2hw8f+Zu5eHIbeVzsC+QBKhldQLP2j5NkfjHdqgVVaykJaYx4rZoNKvkViK+t9RYoFIOhFAtyNczG9uUwLbuRSg7NHMgelBK/jAiWnQhfV/DKyCeMMOLMDaYgh11fFMhWssLyKNdoW/sFHqbb9AgDhqaHbeA/WnaADLC0XVYO39CGYoHfzen/GqP54PxXZUcwMpHV4eTbCUosXolfzvWQOqBtn0x53d33v/YdHuMsb9tA/vJUJDgbk6dsqysr4U/1ShlNvegwA6j5fEhENJim1dQpEDQ== Received: from PU1APC01FT038.eop-APC01.prod.protection.outlook.com (10.152.252.60) by PU1APC01HT219.eop-APC01.prod.protection.outlook.com (10.152.252.246) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.282.5; Thu, 7 Dec 2017 06:34:40 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.52) by PU1APC01FT038.mail.protection.outlook.com (10.152.253.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.282.5 via Frontend Transport; Thu, 7 Dec 2017 06:34:40 +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; Thu, 7 Dec 2017 06:34:40 +0000 From: Damian Williamson To: Jim Renkel , Bitcoin Protocol Discussion Thread-Topic: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks Thread-Index: AQHTa+TfjIfbrac6DkW4WL8VVZ5YaaM1y22AgAGl2xg= Date: Thu, 7 Dec 2017 06:34:39 +0000 Message-ID: References: , <52700305-585d-4239-134e-ac8c5b6c4165@comcast.net> In-Reply-To: <52700305-585d-4239-134e-ac8c5b6c4165@comcast.net> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:C0E4AA6D7C411CCA13F05FA556F1C9912952CD1DD6B330373CCA20FFC3537DC2; UpperCasedChecksum:2BBBEEDF98B2439C87B19BD546FACC607E6ABB98229E0EFF07044A36F535095B; SizeAsReceived:7233; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [7C7ju4tnZr+34gUZ9QlSGng8Im8wxzXb] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT219; 6:sVtwABNuqdSEZC+TCP7MYYMsKCaZJT8cXvaCwmjaDUm+Apt+/wCCk/Eb0lPMGJidXu4t2MyeSOTlyvN1xiQmmXsBO1iHQ4i/aB+I8ljJ740jDeGeeiw3R5PusfZ2lDmdH5MLXc2moAFftnGPUmF39g5Y+mDb8joIfDFrNNLn4JlNGlX0EJLnWu2CH3eaa6O8J5kPl1W3Jzgqmp2gSACoypb9uysvB66XGHz/u2F0QXqIqlqhS/v6plPRo6xkf8QP9eRk/wck6H+0hDSDhf05tMtIvemtsVky5/rMLPOcMLBH/kn6H7zvomV+SCnjnpgEBZf6JlYRXb0JNJHu6S/hXQa6X2WA2xUe49OcXZqqUqw=; 5:/4j9ZidS6u0mDozf28qWCR+0kd6pj4qAWMTzRWi1x+ZeKOrL+96RMYD1RUQ7wmACTWnuR7RHBPrVX1RgYneifpv9+C6luIs2+N9EXkbUCWiQ7CcpAxjb2fdSrwPpHv+bC8/RlvfHuhDaDmlICI2VpVh3m35Eu81JyzpG6GE7uak=; 24:U/HUOY9N4fsBrjiDYVEgRyxWhCLr+Z2tMWnCszlKgXvcT/sYK3FdKTyFvwJbAZWpoSNpZnrjNRz0rAko7FCx7tIITfjsy9sXDrB9HgrN6WQ=; 7:NnERPq48bcpBxTS9bBZKF+vhDvEYsnYwAlQLxa/fmhP1LEjWvm3342NuPcif5pDNRBYr0qy+CLKi8cYhjnjuvL4eGtb4SlN9lhqn6cKHf3+sIICoPWm+aSQHvwbMFn0DZa4kwSLILWc+ibr04ORvsqelEp1lB2Lgylykj9v+RFxjoKGge7fsjKE+kMFDRNEFbqYxZxFmbvOeBdqvh/hNWIxZGDPk1GfgttjCtStIMQ0BYMo71u6ktjxPuRrJlDXz x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:PU1APC01HT219; x-ms-traffictypediagnostic: PU1APC01HT219: x-ms-office365-filtering-correlation-id: 25301a40-ebd3-44cb-c055-08d53d3c984b x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT219; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:PU1APC01HT219; x-forefront-prvs: 05143A8241 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT219; H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_PS2P216MB0179FC2174F0F9BFAA324F169D330PS2P216MB0179KORP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 25301a40-ebd3-44cb-c055-08d53d3c984b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2017 06:34:39.8351 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT219 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: Thu, 07 Dec 2017 13:49:33 +0000 Subject: Re: [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: Thu, 07 Dec 2017 06:34:44 -0000 --_000_PS2P216MB0179FC2174F0F9BFAA324F169D330PS2P216MB0179KORP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jim, The variable block sizes would not, as I understand it, be easily implement= ed by a solo miner. You are right, there is presently nothing stopping a miner from ordering th= e 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 c= onform to a probability distribution curve, if that is necessary and, *if*= the individual transaction priority can be recreated. I am not that deep i= nto the mathematics, however, it may also be possible to use a similar meth= od 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 wro= ng group. (sic) Regards, Damian Williamson ________________________________ From: bitcoin-dev-bounces@lists.linuxfoundation.org on behalf of Jim Renkel via bitcoin-dev 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 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --_000_PS2P216MB0179FC2174F0F9BFAA324F169D330PS2P216MB0179KORP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Jim,


The variable block sizes would no= t, 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 prio= rity that is not entirely based on the fee.


It may be possible to verif= y blocks conform to the proposal by showing that the probability for all tr= ansactions included in the block statistically conform to a probability dis= tribution 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 us= e a similar method to do this just based on the fee, that statistically, th= e 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-bounces@l= ists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org&= gt; on behalf of Jim Renkel via bitcoin-dev <bitcoin-dev@lists.linuxfoun= dation.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 entir= ely 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 min= er to follow it?

Jim Renkel
On 12/2/2017 10:07 PM, Damian Williamson v= ia bitcoin-dev wrote:

# BIP Proposal: UTWFOTIB - Use T= ransaction 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 wa= nt to maximize revenue from fees. Consumers want transaction reliability an= d, (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=3D3= 0 ?); 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 t= he 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 vi= ew of the operation. If I have this wrong, please correct it back to the li= st.


1. The protocol determines the target block size.

2. Assign each transaction in th= e pool a transaction weight based on fee and time waiting in the transactio= n 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

--_000_PS2P216MB0179FC2174F0F9BFAA324F169D330PS2P216MB0179KORP_--