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 88FC171F for ; Tue, 19 Dec 2017 07:51:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255044.outbound.protection.outlook.com [40.92.255.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F299487 for ; Tue, 19 Dec 2017 07:51:41 +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=Hsn4UU3Ln2+iHi7BRLcBcpTKOeh1bxC04ySN/yU5ClE=; b=gMMhDYerWi/ZMTq8mlw1LpKmoJEbuozcjP+P0jX33RYrPrnBRPnX1Jp4sdYWJFVCNKBufWS+9pLKJyBtUWLAQPzYem8K/1TTi84elRWDffiNutiqgWp6FSo/gTaXvpi215kH6k69DiseUaablKVfMLs43+sOhMFJ1oEx0aFyx2facJogyylivNXWJpN8M93mFShrxLgsI+UWSYCMj70JTsuVR0yamUktBtszf691rnVZng7OHkHAgYLIzSnNUlYR6vA2/mW/p3K9zhQ+ORTeMkaY6sm4uGySebQhXj+yXF0n6/y8Zg+6SwwpJVOu5OJne8/R2VsnRiJ7iPt/+0Z45g== Received: from HK2APC01FT062.eop-APC01.prod.protection.outlook.com (10.152.248.60) by HK2APC01HT134.eop-APC01.prod.protection.outlook.com (10.152.248.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.302.6; Tue, 19 Dec 2017 07:51:39 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.248.58) by HK2APC01FT062.mail.protection.outlook.com (10.152.249.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.302.6 via Frontend Transport; Tue, 19 Dec 2017 07:51:39 +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.0323.018; Tue, 19 Dec 2017 07:51:39 +0000 From: Damian Williamson To: Mark Friedenbach Thread-Topic: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks Thread-Index: AQHTb5z9LKaNJrfjBkOvllhZtrqBGqNEL2DvgAB3wACAAD9wXoACEoTMgAJcmACAAQbApg== Date: Tue, 19 Dec 2017 07:51:39 +0000 Message-ID: References: <5upGmF0IhXUWhcikhdV-e9Pqg-kXfUuXe0kOpGxumie_TO2jLvCgTZ5c6vgBRtaqkL6DmOJb1YftK0osufB5RkhW7YhAhhCI0zBTH3YcORY=@protonmail.com> , In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:C06B383C466231568D6CD297D6DEFB724D81D76E1384C6822E159F510855C725; UpperCasedChecksum:170F305EEC370169B14984A69DEDDEC50C16FE6AB8D5F7484BF94EFFA16E1A58; SizeAsReceived:7697; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [JX3aB5p+2ChHFsYpHAGCpiX36JRCbCqZ] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK2APC01HT134; 6:qc+E78PbPhc/lT/BU1PXx1g1vu00SuiSX+2BvoCLMZFcwrQc0zb592wOJ2VpAb/e5UnI3pdj79OyZs3b7V+q1rXSG/1RZT2sA/bfzft9LkmKYhvgff0foIGMbr5WSJbs6dVGoCfo1V7wQVAygB0m9cp3KUZvisbuIwDmveJ9KJ+BoQdrliAyNa26K/HCRns8L1LDm9ZximMFi5vxQwDs1Uz+FRCEdyvHrilq/ixC12Oug0wHMM32ZW9cIhE9pcR5EpkHsRQ+vLKJn05tc2q4vJ02aKG/swSr6279MzbhmSuFsWGyit0FYJXlvR3jpX/lihRIIreTPkyDWcUBJcxZ4bnoQQjX2InRY7l3TIqu1Yw=; 5:iLPP9I3TQLj4SswU2WXUftSojhI7mcd96dsH3lTW2Xswr/N3r+SQVFO54Ace076gIi1s6n5x8sw0PwQW/Pdm66t0On/FMP1/whrEHVDrUTfzsUqS0sVIIZLsUegKyvcS6NCwHT5qlputXpx6EpDT/RyzOpR5DQ3J31+HhuRuMpI=; 24:ZlRegRj0QhhHY33NSNgwxuwn/Zm9R/zudfSnF7DfL+AmETvodUQo8PL4axZJ/TrYnVny5O4uXQIKsg285ScOI6jp7RGo/9lvgSDhSSXZcGo=; 7:UGheoyv+IqREmfdfRluyBDmOkzN5evfvadL/UVD4UUHrOgL4bL10jhpswmAMhauF6Q/i+6LMrlT5P7pxVaKQwCxKtqarUK8aHK8eYRjoT37IDM+LTNCW6LmnWMIt/eAaSoD+1/FbLXkEmGiK6qY0UK7F/B7loarpHM6PVNTLQJbkcLEW4Mq7q3ZJngX7vZGY1QSmVdQgPiGRY+PyKbUL69q9x698DsR9QRdn2x5+caZyrbrg5era8QCHmU1E7kW0 x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:HK2APC01HT134; x-ms-traffictypediagnostic: HK2APC01HT134: x-ms-office365-filtering-correlation-id: ded008a1-a2c1-4188-81cb-08d546b55667 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HK2APC01HT134; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HK2APC01HT134; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT134; H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_PS2P216MB017991D78147E2B1EC14C3059D0F0PS2P216MB0179KORP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ded008a1-a2c1-4188-81cb-08d546b55667 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 07:51:39.4973 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT134 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, 19 Dec 2017 12:49:47 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority 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: Tue, 19 Dec 2017 07:51:45 -0000 --_000_PS2P216MB017991D78147E2B1EC14C3059D0F0PS2P216MB0179KORP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you for your constructive feedback. I now see that the proposal intro= duces a potential issue. >Finally in terms of the broad goal, having block size based on the number = of transactions is NOT something desirable in the first place, even if it d= id work. That=92s effectively the same as an infinite block size since anyo= ne anywhere can create transactions in the mempool at no cost. Do you have any critical suggestion as to how transaction bandwidth limit c= ould be addressed, it will eventually become an issue if nothing is changed= regardless of how high fees go? Regards, Damian Williamson ________________________________ From: Mark Friedenbach Sent: Tuesday, 19 December 2017 3:08 AM To: Damian Williamson Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transactio= n Priority For Ordering Transactions In Blocks Damian, you seem to be misunderstanding that either (1) the strong form of your proposal requires validating the commitment to = the mempool properties, in which case the mempool becomes consensus critica= l (an impossible requirement); or (2) in the weak form where the current block is dependent on the commitment= in the last block only it is becomes a miner-selected field they can freel= y parameterize with no repercussions for setting values totally independent= of the actual mempool. If you want to make the block size dependent on the properties of the mempo= ol in a consensus critical way, flex cap achieves this. If you want to make= the contents or properties of the mempool known to well-connected nodes, w= eak blocks achieves that. But you can=92t stick the mempool in consensus be= cause it fundamentally is not something the nodes have consensus over. That= =92s a chicken-and-the-egg assumption. Finally in terms of the broad goal, having block size based on the number o= f transactions is NOT something desirable in the first place, even if it di= d work. That=92s effectively the same as an infinite block size since anyon= e anywhere can create transactions in the mempool at no cost. On Dec 16, 2017, at 8:14 PM, Damian Williamson via bitcoin-dev > w= rote: I do not know why people make the leap that the proposal requires a consens= us on the transaction pool. It does not. It may be helpful to have the discussion from the previous thread linked he= re. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/01537= 0.html Where I speak of validating that a block conforms to the broadcast next blo= ck size, I do not propose validating the number broadcast for the next bloc= k size itself, only that the next generated block is that size. Regards, Damian Williamson ________________________________ From: Damian Williamson > Sent: Saturday, 16 December 2017 7:59 AM To: Rhavar Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transactio= n Priority For Ordering Transactions In Blocks There are really two separate problems to solve. 1. How does Bitcoin scale with fixed block size? 2. How do we ensure that all valid transactions are eventually included = in the blockchain? Those are the two issues that the proposal attempts to address. It makes se= nse to resolve these two problems together. Using the proposed system for v= ariable block sizes would solve the first problem but there would still be = a whole bunch of never confirming transactions. I am not sure how to reliab= ly solve the second problem at scale without first solving the first. >* Every node has a (potentially) different mempool, you can't use it to de= cide consensus values like the max block size. I do not suggest a consensus. Depending on which node solves a block the va= lue for next block size will be different. The consensus would be that bloc= ks will adhere to the next block size value transmitted with the current bl= ock. It is easy to verify that the consensus is being adhered to once in pl= ace. >* Increasing the entropy in a block to make it more unpredictable doesn't = really make sense. Not a necessary function, just an effect of using a probability-based distr= ibution. >* Bitcoin should be roughly incentive compatible. Your proposal explicits = asks miners to ignore their best interests, and confirm transactions by "pr= iority". What are you going to do if a "malicious" miner decides to go aft= er their profits and order by what makes them the most money. Add "ordered = by priority" as a consensus requirement? And even if you miners can still s= ort their mempool by fee, and then order the top 1MB by priority. I entirely agree with your sentiment that Bitcoin must be incentive compati= ble. It is necessary. It is in only miners immediate interest to make the most profitable block f= rom the available transaction pool. As with so many other things, it is nec= essary to partially ignore short-term gain for long-term benefit. It is in = miners and everybody's long-term interest to have a reliable transaction se= rvice. A busy transaction service that confirms lots of transactions per ho= ur will become more profitable as demand increases and more users are prepa= red to pay for priority. As it is there is currently no way to fully scale = because of the transaction bandwidth limit and that is problematic. If all = valid transactions must eventually confirm then there must be a way to reso= lve that problem. Bitcoin deliberately removes traditional scale by ensuring blocks take ten = minutes on average to solve, an ingenious idea and, incentive compatible bu= t, fixed block sizes leaves us with a problem to solve when we want to scal= e. >If you could find a good solution that would allow you to know if miners w= ere following your rule or not (and thus ignore it if it doesn't) then you = wouldn't even need bitcoin in the first place. I am confident that the math to verify blocks based on the proposal can be = developed (and I think it will not be too complex for a mathematician with = the relevant experience), however, I am nowhere near experienced enough wit= h probability and statistical analysis to do it. Yes, if Bitcoin doesn't th= en it might make another great opportunity for an altcoin but I am not even= nearly interested in promoting any altcoins. If not the proposal that I have put forward, then, hopefully, someone can c= ome up with a better solution. The important thing is that the issues are r= esolved. Regards, Damian Williamson ________________________________ From: Rhavar > Sent: Saturday, 16 December 2017 3:38 AM To: Damian Williamson Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transactio= n Priority For Ordering Transactions In Blocks > I understand that there would be technical issues to resolve in implement= ation, but, are there no fundamental errors? Unfortunately your proposal is really fundamentally broken, on a few levels= . I think you might need to do a bit more research into how bitcoin works b= efore coming up with such improvements =3D) But just some quick notes: * Every node has a (potentially) different mempool, you can't use it to dec= ide consensus values like the max block size. * Increasing the entropy in a block to make it more unpredictable doesn't r= eally make sense. * Bitcoin should be roughly incentive compatible. Your proposal explicits a= sks miners to ignore their best interests, and confirm transactions by "pri= ority". What are you going to do if a "malicious" miner decides to go afte= r their profits and order by what makes them the most money. Add "ordered b= y priority" as a consensus requirement? And even if you miners can still so= rt their mempool by fee, and then order the top 1MB by priority. If you could find a good solution that would allow you to know if miners we= re following your rule or not (and thus ignore it if it doesn't) then you w= ouldn't even need bitcoin in the first place. -Ryan -------- Original Message -------- Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Pr= iority For Ordering Transactions In Blocks Local Time: December 15, 2017 3:42 AM UTC Time: December 15, 2017 9:42 AM From: bitcoin-dev@lists.linuxfoundation.org To: Bitcoin Protocol Discussion > I should not take it that the lack of critical feedback to this revised pro= posal is a glowing endorsement. I understand that there would be technical = issues to resolve in implementation, but, are there no fundamental errors? I suppose that it if is difficult to determine how long a transaction has b= een waiting in the pool then, each node could simply keep track of when a t= ransaction was first seen. This may have implications for a verify routine,= however, for example, if a node was offline, how should it differentiate h= ow long each transaction was waiting in that case? If a node was restarted = daily would it always think that all transactions had been waiting in the p= ool less than one day If each node keeps the current transaction pool in a = file and updates it, as transactions are included in blocks and, as new tra= nsactions appear in the pool, then that would go some way to alleviate the = issue, apart from entirely new nodes. There should be no reason the content= s of a transaction pool files cannot be shared without agreement as to the = transaction pool between nodes, just as nodes transmit new transactions fre= ely. It has been questioned why miners could not cheat. For the question of how = many transactions to include in a block, I say it is a standoff and miners = will conform to the proposal, not wanting to leave transactions with valid = fees standing, and, not wanting to shrink the transaction pool. In any case= , if miners shrink the transaction pool then I am not immediately concerned= since it provides a more efficient service. For the question of including = transactions according to the proposal, I say if it is possible to keep tra= ck of how long transactions are waiting in the pool so that they can be inc= luded on a probability curve then it is possible to verify that blocks conf= orm to the proposal, since the input is a probability, the output should co= nform to a probability curve. If someone has the necessary skill, would anyone be willing to develop the = math necessary for the proposal? Regards, Damian Williamson ________________________________ From: bitcoin-dev-bounces@lists.linuxfoundation.org > on behalf of Dami= an Williamson via bitcoin-dev > Sent: Friday, 8 December 2017 8:01 AM To: bitcoin-dev@lists.linuxfoundation.org Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Pr= iority For Ordering Transactions In Blocks Good afternoon, The need for this proposal: We all must learn to admit that transaction bandwidth is still lurking as a= serious issue for the operation, reliability, safety, consumer acceptance,= uptake and, for the value of Bitcoin. I recently sent a payment which was not urgent so; I chose three-day target= confirmation from the fee recommendation. That transaction has still not c= onfirmed after now more than six days - even waiting twice as long seems qu= ite reasonable to me. That transaction is a valid transaction; it is not ru= bbish, junk or, spam. Under the current model with transaction bandwidth li= mitation, the longer a transaction waits, the less likely it is ever to con= firm due to rising transaction numbers and being pushed back by transaction= s with rising fees. I argue that no transactions are rubbish or junk, only some zero fee transa= ctions might be spam. Having an ever-increasing number of valid transaction= s that do not confirm as more new transactions with higher fees are created= is the opposite of operating a robust, reliable transaction system. Business cannot operate with a model where transactions may or may not conf= irm. Even a business choosing a modest fee has no guarantee that their vali= d transaction will not be shuffled down by new transactions to the realm of= never confirming after it is created. Consumers also will not accept this = model as Bitcoin expands. If Bitcoin cannot be a reliable payment system fo= r confirmed transactions then consumers, by and large, will simply not acce= pt the model once they understand. Bitcoin will be a dirty payment system, = and this will kill the value of Bitcoin. Under the current system, a minority of transactions will eventually be the= lucky few who have fees high enough to escape being pushed down the list. Once there are more than x transactions (transaction bandwidth limit) every= ten minutes, only those choosing twenty-minute confirmation (2 blocks) wil= l have initially at most a fifty percent chance of ever having their paymen= t confirm. Presently, not even using fee recommendations can ensure a suffi= ciently high fee is paid to ensure transaction confirmation. I also argue that the current auction model for limited transaction bandwid= th is wrong, is not suitable for a reliable transaction system and, is wron= g for Bitcoin. All transactions must confirm in due time. Currently, Bitcoi= n is not a safe way to send payments. I do not believe that consumers and business are against paying fees, even = high fees. What is required is operational reliability. This great issue needs to be resolved for the safety and reliability of Bit= coin. The time to resolve issues in commerce is before they become great bi= g issues. The time to resolve this issue is now. We must have the foresight= to identify and resolve problems before they trip us over. Simply doublin= g block sizes every so often is reactionary and is not a reliable permanent= solution. I have written a BIP proposal for a technical solution but, need= your help to write it up to an acceptable standard to be a full BIP. I have formatted the following with markdown which is human readable so, I = hope nobody minds. I have done as much with this proposal as I feel that I = am able so far but continue to take your feedback. # BIP Proposal: UTPFOTIB - Use Transaction Priority For Ordering Transactio= ns In Blocks ## The problem: Everybody wants value. Miners want to maximize revenue from fees (and we pr= esume, to minimize block size). Consumers need transaction reliability and,= (we presume) want low fees. The current transaction bandwidth limit is a limiting factor for both. As t= he operational safety of transactions is limited, so is consumer confidence= as they realize the issue and, accordingly, uptake is limited. Fees are ar= tificially inflated due to bandwidth limitations while failing to provide a= full confirmation service for all transactions. Current fee recommendations provide no satisfaction for transaction reliabi= lity and, as Bitcoin scales, this will worsen. Bitcoin must be a fully scalable and reliable service, providing full trans= action confirmation for every valid transaction. The possibility to send a transaction with a fee lower than one that is acc= eptable to allow eventual transaction confirmation should be removed from t= he protocol and also from the user interface. ## Solution summary: Provide each transaction with an individual transaction priority each time = before choosing transactions to include in the current block, the priority = 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=3D60 ?). The transactio= n priority to serve as the likelihood of a transaction being included in th= e current block, and for determining the order in which transactions are tr= ied to see if they will be included. Use a target block size. Determine the target block size using; current tra= nsaction pool size x ( 1 / (144 x n days ) ) =3D number of transactions to = be included in the current block. Broadcast the next target block size with= the current block when it is solved so that nodes know the next target blo= ck size for the block that they are building on. The curves used for the priority of transactions would have to be appropria= te. Perhaps a mathematician with experience in probability can develop the = right formulae. My thinking is a steep curve. I suppose that the probabilit= y of all transactions should probably account for a sufficient number of in= clusions that the target block size is met although, it may not always be. = As a suggestion, consider including some zero fee transactions to pad, high= est BTC value first? **Explanation of the operation of priority:** > If transaction priority is, for example, a number between one (low) and o= ne-hundred (high) it can be directly understood as the percentage chance in= one-hundred of a transaction being included in the block. Using probabilit= y or likelihood infers that there is some function of random. If random (10= 0) < transaction priority then the transaction is included. >To break it down further, if both the fee on a curve value and the time wa= iting on a curve value are each a number between one and one-hundred, a rud= imentary method may be to simply multiply those two numbers, to find the pr= iority number. For example, a middle fee transaction waiting thirty days (i= f n =3D 60 days) may have a value of five for each part (yes, just five, t= he values are on a curve). When multiplied that will give a priority value = of twenty-five, or, a twenty-five percent chance at that moment of being i= ncluded in the block; it will likely be included in one of the next four bl= ocks, getting more likely each chance. If it is still not included then the= value of time waiting will be higher, making for more probability. A very = low fee transaction would have a value for the fee of one. It would not be = until near sixty-days that the particular low fee transaction has a high li= kelihood of being included in the block. I am not concerned with low (or high) transaction fees, the primary reason = for addressing the issue is to ensure transactional reliability and scalabi= lity while having each transaction confirm in due time. ## Pros: * Maximizes transaction reliability. * Fully scalable. * Maximizes possibility for consumer and business uptake. * Maximizes total fees paid per block without reducing reliability; because= of reliability, in time confidence and overall uptake are greater; therefo= re, more transactions. * Market determines fee paid for transaction priority. * Fee recommendations work all the way out to 30 days or greater. * Provides additional block entropy; greater security since there is less p= robability of predicting the next block. ## Cons: * Could initially lower total transaction fees per block. * Must be first be programmed. ## Solution operation: This is a simplistic view of the operation. The actual operation will need = to be determined in a spec for the programmer. 1. Determine the target block size for the current block. 2. Assign a transaction priority to each transaction in the pool. 3. Select transactions to include in the current block using probability in= transaction priority order until the target block size is met. 5. Solve block. 6. Broadcast the next target block size with the current block when it is s= olved. 7. Block is received. 8. Block verification process. 9. Accept/reject block based on verification result. 10. Repeat. ## Closing comments: 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= onforms to a probability distribution curve, *if* the individual transactio= n priority can be recreated. I am not that deep into the mathematics; howev= er, it may also be possible to use a similar method to do this just based o= n the fee, that statistically, the blocks conform to a fee distribution. An= y zero fee transactions would have to be ignored. This solution needs a cle= ver mathematician. I implore, at the very least, that we use some method that validates full t= ransaction reliability and enables scalability of block sizes. If not this = proposal, an alternative. Regards, Damian Williamson _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --_000_PS2P216MB017991D78147E2B1EC14C3059D0F0PS2P216MB0179KORP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thank you for your constructive f= eedback. I now see that the proposal introduces a potential issue.


>Finally in terms of the= broad goal, having block size based on the number of transactions is NOT s= omething desirable in the first place, even if it did work. That=92s effect= ively the same as an infinite block size since anyone anywhere can create transactions in the mempool at no cost.


Do you have any critical suggesti= on as to how transaction bandwidth limit could be addressed, it will eventu= ally become an issue if nothing is changed regardless of how high fees go?<= br>


Regards,

Damian Williamson



From: Mark Friedenbach &l= t;mark@friedenbach.org>
Sent: Tuesday, 19 December 2017 3:08 AM
To: Damian Williamson
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Tra= nsaction Priority For Ordering Transactions In Blocks
 

(1) the strong form of your proposal requires validating th= e commitment to the mempool properties, in which case the mempool becomes c= onsensus critical (an impossible requirement); or

(2) in the weak form where the current block is dependent o= n the commitment in the last block only it is becomes a miner-selected fiel= d they can freely parameterize with no repercussions for setting values tot= ally independent of the actual mempool.

If you want to make the block size dependent on the propert= ies of the mempool in a consensus critical way, flex cap achieves this. If = you want to make the contents or properties of the mempool known to well-co= nnected nodes, weak blocks achieves that. But you can=92t stick the mempool in consensus because it fundamenta= lly is not something the nodes have consensus over. That=92s a chicken-and-= the-egg assumption.

Finally in terms of the broad goal, having block size based= on the number of transactions is NOT something desirable in the first plac= e, even if it did work. That=92s effectively the same as an infinite block = size since anyone anywhere can create transactions in the mempool at no cost.

On Dec 16, 2017, at 8:14 PM, Damian Williamson via bitcoin-= dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

I do not know w= hy people make the leap that the proposal requires a consensus on the trans= action pool. It does not.

It may be helpf= ul to have the discussion from the previous thread linked here.
http= s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015370.ht= ml

Where I speak o= f validating that a block conforms to the broadcast next block size, I do n= ot propose validating the number broadcast for the next block size itself, = only that the next generated block is that size.

Regards,
Damian Williams= on


From: Damian Williamson <willtech@live.com.au>= ;
Sent: Saturday, 16 December 2017 7:59 AM
To: R= havar
Cc: B= itcoin Protocol Discussion
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Pri= ority For Ordering Transactions In Blocks
 
There are reall= y two separate problems to solve.

  1. How does Bitcoin scale with fixed block size?
  2. How do we ensure that all valid transactions are eventually included = in the blockchain?

Those are the t= wo issues that the proposal attempts to address. It makes sense to resolve = these two problems together. Using the proposed system for variable block s= izes would solve the first problem but there would still be a whole bunch of never confirming transactions. I am = not sure how to reliably solve the second problem at scale without first so= lving the first.

>* Every nod= e has a (potentially) different mempool, you can't use it to decide consens= us values like the max block size. 

I do not suggest a consensus. Depending on which node solves a block the va= lue for next block size will be different. The consensus would be that bloc= ks will adhere to the next block size value transmitted with the current bl= ock. It is easy to verify that the consensus is being adhered to once in place.
 
>* Increasing the entropy in a block to make it more unp= redictable doesn't really make sense. 

Not a necessary function, just an effect of using a probability-based distr= ibution. 

>* Bitcoin should be roughly incentive compatible. Your = proposal explicits asks miners to ignore their best interests, and confirm = transactions by "priority".  What are you going to do if a &= quot;malicious" miner decides to go after their profits and order by what makes them the most money. Add "ordered by priority&quo= t; as a consensus requirement? And even if you miners can still sort their = mempool by fee, and then order the top 1MB by priority.

I entirely agree with your sentiment that Bitcoin must be incentive compati= ble. It is necessary.

It is in only miners immediate interest to make the most profitable block f= rom the available transaction pool. As with so many other things, it is nec= essary to partially ignore short-term gain for long-term benefit. It is in = miners and everybody's long-term interest to have a reliable transaction service. A busy transaction servic= e that confirms lots of transactions per hour will become more profitable a= s demand increases and more users are prepared to pay for priority. As it i= s there is currently no way to fully scale because of the transaction bandwidth limit and that is problematic. = If all valid transactions must eventually confirm then there must be a way = to resolve that problem.

Bitcoin deliberately removes traditional scale by ensuring blocks take ten = minutes on average to solve, an ingenious idea and, incentive compatible bu= t, fixed block sizes leaves us with a problem to solve when we want to scal= e.

>If you could find a good solution that would allow you = to know if miners were following your rule or not (and thus ignore it if it= doesn't) then you wouldn't even need bitcoin in the first place.

I am confident that the math to verify blocks based on the proposal can be = developed (and I think it will not be too complex for a mathematician with = the relevant experience), however, I am nowhere near experienced enough wit= h probability and statistical analysis to do it. Yes, if Bitcoin doesn't then it might make another great opportu= nity for an altcoin but I am not even nearly interested in promoting any al= tcoins.


If not the prop= osal that I have put forward, then, hopefully, someone can come up with a b= etter solution. The important thing is that the issues are resolved.

Regards,
Damian Williams= on


From: Rhavar <rhavar@protonmail.com>
Sent: Saturday, 16 December 2017 3:38 AM
To: D= amian Williamson
Cc: B= itcoin Protocol Discussion
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Pri= ority For Ordering Transactions In Blocks
 
> I understand that there would be technical issues= to resolve in implementation, but, are there no fundamental errors?

Unfortunately your proposal is really fundamentally broken,= on a few levels. I think you might need to do a bit more research into how= bitcoin works before coming up with such improvements =3D)

But just some quick notes:

* Every node has a (potentially) different mempool, you can= 't use it to decide consensus values like the max block size. 

* Increasing the entropy in a block to make it more unpredi= ctable doesn't really make sense. 

* Bitcoin should be roughly incentive compatible. Your prop= osal explicits asks miners to ignore their best interests, and confirm tran= sactions by "priority".  What are you going to do if a "= ;malicious" miner decides to go after their profits and order by what makes them the most money. Add "ordered by priority&quo= t; as a consensus requirement? And even if you miners can still sort their = mempool by fee, and then order the top 1MB by priority.

If you could find a good solution that would allow you to k= now if miners were following your rule or not (and thus ignore it if it doe= sn't) then you wouldn't even need bitcoin in the first place.




-Ryan


-------- Original Message --------
Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Us= e Transaction Priority For Ordering Transactions In Blocks
Local Time: December 15, 2017 3:42 AM
UTC Time: December 15, 2017 9:42 AM
From: <= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"">bitcoin-= dev@lists.linuxfoundation.org
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundat= ion.org>



I should not take it that the lack of critical feedback to = this revised proposal is a glowing endorsement. I understand that there wou= ld be technical issues to resolve in implementation, but, are there no fund= amental errors?

I suppose that it if is difficult to determine how long a t= ransaction has been waiting in the pool then, each node could simply keep t= rack of when a transaction was first seen. This may have implications for a= verify routine, however, for example, if a node was offline, how should it differentiate how long each transacti= on was waiting in that case? If a node was restarted daily would it always = think that all transactions had been waiting in the pool less than one day = If each node keeps the current transaction pool in a file and updates it, as transactions are included in blocks and,= as new transactions appear in the pool, then that would go some way to all= eviate the issue, apart from entirely new nodes. There should be no reason = the contents of a transaction pool files cannot be shared without agreement as to the transaction pool between node= s, just as nodes transmit new transactions freely.

It has been questioned why miners could not cheat. For the = question of how many transactions to include in a block, I say it is a stan= doff and miners will conform to the proposal, not wanting to leave transact= ions with valid fees standing, and, not wanting to shrink the transaction pool. In any case, if miners shrink = the transaction pool then I am not immediately concerned since it provides = a more efficient service. For the question of including transactions accord= ing to the proposal, I say if it is possible to keep track of how long transactions are waiting in the pool= so that they can be included on a probability curve then it is possible to= verify that blocks conform to the proposal, since the input is a probabili= ty, the output should conform to a probability curve.


If someone has the necessary skill, would anyone be willing= to develop the math necessary for the proposal?

Regards,
Damian Williamson


 
From: bitcoin-dev-bounces@list= s.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Damian Williamson via bitcoin-dev <bitcoin-dev@lists.linuxfoundat= ion.org>
Sent: Friday, 8 December 2017 8:01 AM
To: <= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"">bitcoin-= dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priorit= y For Ordering Transactions In Blocks
 

Good afternoon,

The need for this proposal:

We all must learn to admit that transaction bandwidth is st= ill lurking as a serious issue for the operation, reliability, safety, cons= umer acceptance, uptake and, for the value of Bitcoin.

I recently sent a payment which was not urgent so; I chose = three-day target confirmation from the fee recommendation. That transaction= has still not confirmed after now more than six days - even waiting twice = as long seems quite reasonable to me. That transaction is a valid transaction; it is not rubbish, junk or, s= pam. Under the current model with transaction bandwidth limitation, the lon= ger a transaction waits, the less likely it is ever to confirm due to risin= g transaction numbers and being pushed back by transactions with rising fees.

I argue that no transactions are rubbish or junk, only some= zero fee transactions might be spam. Having an ever-increasing number of v= alid transactions that do not confirm as more new transactions with higher = fees are created is the opposite of operating a robust, reliable transaction system.

Business cannot operate with a model where transactions may= or may not confirm. Even a business choosing a modest fee has no guarantee= that their valid transaction will not be shuffled down by new transactions= to the realm of never confirming after it is created. Consumers also will not accept this model as Bitcoin = expands. If Bitcoin cannot be a reliable payment system for confirmed trans= actions then consumers, by and large, will simply not accept the model once= they understand. Bitcoin will be a dirty payment system, and this will kill the value of Bitcoin.

Under the current system, a minority of transactions will e= ventually be the lucky few who have fees high enough to escape being pushed= down the list.

Once there are more than x transactions (transaction bandwi= dth limit) every ten minutes, only those choosing twenty-minute confirmatio= n (2 blocks) will have initially at most a fifty percent chance of ever hav= ing their payment confirm. Presently, not even using fee recommendations can ensure a sufficiently high fee is p= aid to ensure transaction confirmation.

I also argue that the current auction model for limited tra= nsaction bandwidth is wrong, is not suitable for a reliable transaction sys= tem and, is wrong for Bitcoin. All transactions must confirm in due time. C= urrently, Bitcoin is not a safe way to send payments.

I do not believe that consumers and business are against pa= ying fees, even high fees. What is required is operational reliability.

This great issue needs to be resolved for the safety and re= liability of Bitcoin. The time to resolve issues in commerce is before they= become great big issues. The time to resolve this issue is now. We must ha= ve the foresight to identify and resolve problems before they trip us over.  Simply doubling block sizes every= so often is reactionary and is not a reliable permanent solution. I have w= ritten a BIP proposal for a technical solution but, need your help to write= it up to an acceptable standard to be a full BIP.

I have formatted the following with markdown which is human= readable so, I hope nobody minds. I have done as much with this proposal a= s I feel that I am able so far but continue to take your feedback.

# BIP Proposal: UTPFOTIB - Use Transaction Priority For Ord= ering Transactions In Blocks

## The problem:
Everybody wants value. Miners want to maximize revenue from= fees (and we presume, to minimize block size). Consumers need transaction = reliability and, (we presume) want low fees.

The current transaction bandwidth limit is a limiting facto= r for both. As the operational safety of transactions is limited, so is con= sumer confidence as they realize the issue and, accordingly, uptake is limi= ted. Fees are artificially inflated due to bandwidth limitations while failing to provide a full confirmation = service for all transactions.

Current fee recommendations provide no satisfaction for tra= nsaction reliability and, as Bitcoin scales, this will worsen.

Bitcoin must be a fully scalable and reliable service, prov= iding full transaction confirmation for every valid transaction.

The possibility to send a transaction with a fee lower than= one that is acceptable to allow eventual transaction confirmation should b= e removed from the protocol and also from the user interface.

## Solution summary:
Provide each transaction with an individual transaction pri= ority each time before choosing transactions to include in the current bloc= k, the priority 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=3D60 ?). The transaction priority to serve as= the likelihood of a transaction being included in the current block, and f= or determining the order in which transactions are tried to see if they wil= l be included. 

Use a target block size. Determine the target block size us= ing; current transaction pool size x ( 1 / (144 x n days ) ) =3D number of = transactions to be included in the current block. Broadcast the next target= block size with the current block when it is solved so that nodes know the next target block size for the block t= hat they are building on.

The curves used for the priority of transactions would have= to be appropriate. Perhaps a mathematician with experience in probability = can develop the right formulae. My thinking is a steep curve. I suppose tha= t the probability of all transactions should probably account for a sufficient number of inclusions that the tar= get block size is met although, it may not always be. As a suggestion, cons= ider including some zero fee transactions to pad, highest BTC value first?<= br class=3D"">

**Explanation of the operation of priority:**
> If transaction priority is, for example, a number betw= een one (low) and one-hundred (high) it can be directly understood as the p= ercentage chance in one-hundred of a transaction being included in the bloc= k. Using probability or likelihood infers that there is some function of random. If random (100) < transaction pr= iority then the transaction is included.

>To break it down further, if both the fee on a curve va= lue and the time waiting on a curve value are each a number between one and= one-hundred, a rudimentary method may be to simply multiply those two numb= ers, to find the priority number. For example, a middle fee transaction waiting thirty days (if n =3D 60 days) m= ay have a value of five for each part  (yes, just five, the values are= on a curve). When multiplied that will give a priority value of twenty-fiv= e, or,  a twenty-five percent chance at that moment of being included in the block; it will likely be included in = one of the next four blocks, getting more likely each chance. If it is stil= l not included then the value of time waiting will be higher, making for mo= re probability. A very low fee transaction would have a value for the fee of one. It would not be until near sixty-da= ys that the particular low fee transaction has a high likelihood of being i= ncluded in the block.

I am not concerned with low (or high) transaction fees, the= primary reason for addressing the issue is to ensure transactional reliabi= lity and scalability while having each transaction confirm in due time.

## Pros:
* Maximizes transaction reliability.
* Fully scalable.
* Maximizes possibility for consumer and business uptake.
* Maximizes total fees paid per block without reducing reli= ability; because of reliability, in time confidence and overall uptake are = greater; therefore, more transactions.
* Market determines fee paid for transaction priority.
* Fee recommendations work all the way out to 30 days or gr= eater.
* Provides additional block entropy; greater security since= there is less probability of predicting the next block.

## Cons:
* Could initially lower total transaction fees per block.
* Must be first be programmed.

## Solution operation:
This is a simplistic view of the operation. The actual oper= ation will need to be determined in a spec for the programmer.

1. Determine the target block size for the current block.
2. Assign a transaction priority to each transaction in the= pool.
3. Select transactions to include in the current block usin= g probability in transaction priority order until the target block size is = met.
5. Solve block.
6. Broadcast the next target block size with the current bl= ock when it is solved.
7. Block is received.
8. Block verification process.
9. Accept/reject block based on verification result.
10. Repeat.

## Closing comments:
It may be possible to verify blocks conform to the proposal= by showing that the probability for all transactions included in the block= statistically conforms to a probability distribution curve, *if* the indiv= idual transaction priority can be recreated. I am not that deep into the mathematics; however, it may also b= e possible to use a similar method to do this just based on the fee, that s= tatistically, the blocks conform to a fee distribution. Any zero fee transa= ctions would have to be ignored. This solution needs a clever mathematician.

I implore, at the very least, that we use some method that = validates full transaction reliability and enables scalability of block siz= es. If not this proposal, an alternative.

Regards,
Damian Williamson


_________________________________________= ______
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin= -dev

--_000_PS2P216MB017991D78147E2B1EC14C3059D0F0PS2P216MB0179KORP_--