Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8ED87BAA for ; Wed, 6 Dec 2017 09:27:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253095.outbound.protection.outlook.com [40.92.253.95]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 775AE1B4 for ; Wed, 6 Dec 2017 09:27:33 +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=RWEJ/yEYUttejwOmFz0VQ2TMhpsw6TxFKj7t2DWV0fM=; b=RIzfkvTXn9EBIYpWF5m61w8d152C6L9Vfh4RT5F2lbatTpavTFTS4EFXP+xLw+O+aZY5rXiPYmWNhF3wXLuyIU28bBr4zw3l3dVCFAdBSoVDDamXWvMz5CuJZ1E5JkhwQWstjnvA0k4X3FBTvCdxRjYDWolgNqGlIkatxw/kNnhphU5+PDMlIYBShUBD2AEXj1oGueSjOcKN6sqOMxPHRItHEK40DXUZ485SlRoOweCEeGYncgi2boJ2w4RV3zWpAzfzX5nBGwp7LmCNh+RG99d4C1GS8ibpmMbNiHLb/D76VlWuMmslu0Pjmew3fULF19qBTWbJWB3Wc9MPR500Ig== Received: from PU1APC01FT020.eop-APC01.prod.protection.outlook.com (10.152.252.57) by PU1APC01HT085.eop-APC01.prod.protection.outlook.com (10.152.253.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Wed, 6 Dec 2017 09:27:31 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.53) by PU1APC01FT020.mail.protection.outlook.com (10.152.252.217) 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; Wed, 6 Dec 2017 09:27:30 +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; Wed, 6 Dec 2017 09:27:30 +0000 From: Damian Williamson CC: "bitcoin-dev@lists.linuxfoundation.org" Thread-Topic: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks Thread-Index: AQHTa+TfjIfbrac6DkW4WL8VVZ5YaaM102mAgAA9mEY= Date: Wed, 6 Dec 2017 09:27:30 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:D5A11834DD5DC81BCD44F9DB366C8816CFFA61E1EA001C0AF03443B70DB73453; UpperCasedChecksum:B96FC165A3BCA4176D17CC31B620DAB8D089F7BF1626FE04E1A84FA2D609BC78; SizeAsReceived:7373; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [/DNQeZW5jH/RMpzxfK3+XMrheoDGr+Uk] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT085; 6:fuursmESKTUhA29rFJspJciWsGMDmszH9UlBrPqcX8QHuT4RGGKi8pl0N8snCvwIi9G7siMsIWn0qNYkCUS/Xof5HaOrm03m1sb98rST9MhmhPqI6mOvbn0SZSDhWVFUonBb6gspN2L9KavGeHPvFER/3KYFBNDkpWFD/sY0UQjxNRYTqivk2XEY1JLBONVfNnCy2sBx3zHZhFbhEiKhvxWmYA1pHKdm7LCpqVNgNv1mpZiALQBdccZkytAxrx196agpwu7z5HynOkNu1FSWuRmEW/7ZwOfFfQcE/ayyN3cHsat6qO+mGfmoruDNK2CS69Ah80jWim55mYTapSobsqJ+YMlzgKEwCbzgRQNc1pw=; 5:zVAqxTscgOgSx5k6BNjuFA4r0x4/iNW5oKryx4IHnCIebqGkahzcN9xzyQ4whAbQfoL0vcJOYtqFoFZdSlaTPaKe+KldYyaj3HKMFufeOK7KgQ9MfhKMZC85EezfZIazI6hrMBa+no8lXSxccIpygjpaa7WZdUDTk8+hVHWCDmY=; 24:CCB6QYJfixprGCZxL4JxiwWhFHxMuSaZo+MxpGX2qAKBsRQDoEjdQbrkyZrxjUpmrMu30gC+xWb88iNl/dyMeaXYD7nxFbM6RFjHDgY0zMk=; 7:VzzHCuVMzcqYRiNFxHZzDYA95MbqO9Z1sT8bP6Z1VfDxTazCu7FviX11nsSexuAOJDnrbPYqIDO3/0xTYVjtv2hUuDzrAWnCD40qnJNb9QrC0UfART5gFYxYdd2QLaN7HBvIMHfx4yJd6bcUMkzyRj9MXiMKyRX7GeezYwlJpGga1pTY4WPYFuTsL7E57I4riDAh4L7QYKx3Itxxpfzf62ZnunJkxhGmGcnIg51336sear/qZbKIacYhZeaS2CsN 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:PU1APC01HT085; x-ms-traffictypediagnostic: PU1APC01HT085: x-ms-office365-filtering-correlation-id: 7f38f3ab-2c3b-4d74-c4ef-08d53c8b9323 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT085; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:PU1APC01HT085; x-forefront-prvs: 05134F8B4F x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT085; H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_PS2P216MB0179BC1CDE30F00D73DAA10F9D320PS2P216MB0179KORP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f38f3ab-2c3b-4d74-c4ef-08d53c8b9323 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 09:27:30.7165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT085 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, MISSING_HEADERS, RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 06 Dec 2017 14:51:12 +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: Wed, 06 Dec 2017 09:27:35 -0000 --_000_PS2P216MB0179BC1CDE30F00D73DAA10F9D320PS2P216MB0179KORP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good afternoon ZmnSCPxj, I have posted some discussion on the need for this proposal and, some refin= ements to the proposal explanation (not changes to the intended operation) = to the bitcoin-discuss list. I didn't exactly mean to double post but thoug= ht it could use the discussion and, not to post it again, I will link to it= when (if) it turns up, or will post it back here as an update on request. = Currently, that post is awaiting moderator approval. I have also rewritten = the solution operation section a bit in that post, not the idea that is bei= ng conveyed. I have added an additional step, reject blocks that do not mee= t the target block size for the current block. I suggest it still should be added to the solution operation, to broadcast = the next target block size with the current block when it is solved. Using = that method may answer a part of your concern. As I understand it, each node would be aware independently of x transaction= s waiting for confirmation, the transaction pool. Each node would no doubt = have its own idea about how many waiting transactions there are and which p= articular transactions exist. I do not see why each node could not just wor= k with the information at hand, it is my understanding that is what happens= now, even with solved blocks vs the longest chain. I have not followed why= you foresee from my proposal the need for fullnodes to back confirm the pr= evious blocks in that manner. If next blocksize is broadcast with the completed block it would be a simpl= e matter to back confirm that. With transaction weight (transaction priorit= y) I am suggesting that value gives the likelihood of a transaction being i= ncluded, presuming an element of randomness as to whether any particular tr= ansaction is then included or not. Back confirmations on a transaction basi= s would be impossible anyway, all that could be confirmed is that a particu= lar block has transactions that conform to a probability curve, if the vari= ables are known, fee amount and time waiting in the pool, then the transact= ion priority can be recreated to establish that the probability of a partic= ular block conforms. I certainly do not foresee including the full transact= ion pool in each block. I am also presuming blocksize as a number of transactions rather than KB. My suggestion, if adopted, is to directly make the operation of transaction= priority a part of the operational standard - even without verification th= at it is being followed. The result of full transactional reliability is ac= tually in the interests of miners as much as anyone. The benefit of the proposal, not directly stated, is variable sized blocks = (uncapped block size). Yes, I have learned not to recycle terminology. My apologies, I had not bee= n made aware that terminology already had use. Perhaps it would be simpler = to call the proposal that I am putting forward here Transaction Priority. Regards, Damian Williamson ________________________________ From: ZmnSCPxj Sent: Wednesday, 6 December 2017 4:46:45 PM To: Damian Williamson Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight = For Ordering Transactions In Blocks Good morning Damian, The primary problem in your proposal, as I understand it, is that the "tran= saction pool" is never committed to and is not part of consensus currently.= It is unlikely that the transaction pool will ever be part of consensus, = as putting the transaction pool into consensus is effectively lifting the b= lock size to include the entire transaction pool into each block. The issu= e is that the transaction pool is transient and future fullnodes cannot fin= d the contents of the transaction pool at the time blocks were made and can= not verify the correctness of historical blocks. Also, fullnodes using -bl= ocksonly mode have no transaction pool and cannot verify incoming blocks fo= r these new rules. Applying a patch that follows this policy into Bitcoin Core without enforci= ng it in all fullnodes will simply lead to miners removing the patch in sof= tware they run, making it an exercise in futility to write, review, and tes= t this code in the first place. In addition, you reuse the term "weight" for something different than its c= urrent use. Current use, is that the "weight" of a transaction, is the com= puted weight from the SegWit weight equation, measured in virtual units cal= led "sipa", using the equation (4sipa / non-witness byte + 1sipa/witness by= te). Regards, ZmnSCPxj Sent with ProtonMail Secure Email. -------- Original Message -------- Subject: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For = Ordering Transactions In Blocks Local Time: December 6, 2017 3:38 AM UTC Time: December 5, 2017 7:38 PM From: bitcoin-dev@lists.linuxfoundation.org To: bitcoin-dev@lists.linuxfoundation.org # 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_PS2P216MB0179BC1CDE30F00D73DAA10F9D320PS2P216MB0179KORP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good afternoon ZmnSCPxj,

 
I have posted some discussion on the need for this proposal and, some = refinements to the proposal explanation (not changes to the intended operat= ion) to the bitcoin-discuss list. I didn't exactly mean to double post but = thought it could use the discussion and, not to post it again, I will link to it when (if) it turns up, or wil= l post it back here as an update on request. Currently, that post is awaiti= ng moderator approval. I have also rewritten the solution operation section= a bit in that post, not the idea that is being conveyed. I have added an additional step, reject blocks tha= t do not meet the target block size for the current block.

I suggest it still should be added to the solution operation, to broadcast = the next target block size with the current block when it is solved. Using = that method may answer a part of your concern.

As I understand it, each node would be aware independently of x transaction= s waiting for confirmation, the transaction pool. Each node would no doubt = have its own idea about how many waiting transactions there are and which p= articular transactions exist. I do not see why each node could not just work with the information at hand,= it is my understanding that is what happens now, even with solved blocks v= s the longest chain. I have not followed why you foresee from my proposal t= he need for fullnodes to back confirm the previous blocks in that manner.

If next blocksize is broadcast with the completed block it would be a simpl= e matter to back confirm that. With transaction weight (transaction priorit= y) I am suggesting that value gives the likelihood of a transaction being i= ncluded, presuming an element of randomness as to whether any particular transaction is then included or no= t. Back confirmations on a transaction basis would be impossible anyway, al= l that could be confirmed is that a particular block has transactions that = conform to a probability curve, if the variables are known, fee amount and time waiting in the pool, then = the transaction priority can be recreated to establish that the probability= of a particular block conforms. I certainly do not foresee including the f= ull transaction pool in each block.

I am also presuming blocksize as a number of transactions rather than KB.
My suggestion, if adopted, is to directly make the operation of transaction= priority a part of the operational standard - even without verification th= at it is being followed. The result of full transactional reliability is ac= tually in the interests of miners as much as anyone.

The benefit of the proposal, not directly stated, is variable sized blocks = (uncapped block size).

Yes, I have learned not to recycle terminology. My apologies, I had not bee= n made aware that terminology already had use. Perhaps it would be simpler = to call the proposal that I am putting forward here Transaction Priority.
Regards,
Damian Williamson

From: ZmnSCPxj <ZmnSCPxj= @protonmail.com>
Sent: Wednesday, 6 December 2017 4:46:45 PM
To: Damian Williamson
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction = Weight For Ordering Transactions In Blocks
 
Good morning Damian,

The primary problem in your proposal, as I understand it, is that the = "transaction pool" is never committed to and is not part of conse= nsus currently.  It is unlikely that the transaction pool will ever be= part of consensus, as putting the transaction pool into consensus is effectively lifting the block size to include the e= ntire transaction pool into each block.  The issue is that the transac= tion pool is transient and future fullnodes cannot find the contents of the= transaction pool at the time blocks were made and cannot verify the correctness of historical blocks.  Al= so, fullnodes using -blocksonly mode have no transaction pool and cannot ve= rify incoming blocks for these new rules.

Applying a patch that follows this policy into Bitcoin Core without en= forcing it in all fullnodes will simply lead to miners removing the patch i= n software they run, making it an exercise in futility to write, review, an= d test this code in the first place.

In addition, you reuse the term "weight" for something diffe= rent than its current use.  Current use, is that the "weight"= ; of a transaction, is the computed weight from the SegWit weight equation,= measured in virtual units called "sipa", using the equation (4sipa / non-witness byte + 1sipa/witness byte).

Regards,
ZmnSCPxj




Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight= For Ordering Transactions In Blocks
Local Time: December 6, 2017 3:38 AM
UTC Time: December 5, 2017 7:38 PM
From: bitcoin-dev@lists.linuxfoundation.org
To: bitcoin-dev@lists.linuxfoundation.org <bitcoin-dev@lists.linuxf= oundation.org>


# 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 section entitled 'Solution operation' may not be entirely correct but y= ou will get the idea. If I have it wrong, please correct it back to the lis= t.


## 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 h= andled by having the protocol determine the target size for the current blo= ck using; current transaction pool size x ( 1 / (144 x n days ) ) =3D trans= actions to be included in the current block.

The curves used for the weight of transactions would have to be approp= riate.


## Pros:


* Maximizes transaction reliability.
* Maximizes possibility for consumer and business uptake.
* Maximizes total fees paid per block without reducing reliability; be= cause of reliability, confidence and uptake are greater; therefore, more tr= ansactions 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 i= s less 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


--_000_PS2P216MB0179BC1CDE30F00D73DAA10F9D320PS2P216MB0179KORP_--