e646ebe4ed30605d804991df4b5412d645c0c1
1 Return-Path: <spartacusrex99@gmail.com> 2 Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org 3 [172.17.192.35]) 4 by mail.linuxfoundation.org (Postfix) with ESMTPS id DB3F9516 5 for <bitcoin-dev@lists.linuxfoundation.org>; 6 Fri, 22 Dec 2017 18:07:55 +0000 (UTC) 7 X-Greylist: whitelisted by SQLgrey-1.7.6 8 Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com 9 [209.85.128.177]) 10 by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4C43352B 11 for <bitcoin-dev@lists.linuxfoundation.org>; 12 Fri, 22 Dec 2017 18:07:52 +0000 (UTC) 13 Received: by mail-wr0-f177.google.com with SMTP id v21so17867407wrc.0 14 for <bitcoin-dev@lists.linuxfoundation.org>; 15 Fri, 22 Dec 2017 10:07:52 -0800 (PST) 16 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 17 h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 18 bh=7PgTTLf1sqoqzbJfGJMc6no2Z4zp6SndMhnsg9t8qow=; 19 b=Bk0rQcBguVlYGE7JXQngwgPpehDxy/TpGY0upT33xkYxqkQ9F8ZYkmg9N22Vr+11he 20 VJft761JvQEjJN4lnvMpw80WOm1C2C/GsPufAy5LPhegzgkSO4Gda9V0CWXDRB9+cObU 21 KZ5H9+yl5fzEpXKpeWxxWRTb7zSLh6Z9eWW9JAz+ithf0RVLK7iKxE4pTc/x6N0jl6wB 22 BKeXWFIISJYEu9KG22kjhu258H/3NFEM2rMCtpIjO5Wm385fDfSkRpMV/dgO0c4BgUVW 23 0RShJLrw+XeZGGpaMCKK07wfquVrNE9PxLPfUOkOyd19U2zV5irUgW3XKkuUwR/N8Wdd 24 KmjA== 25 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 26 d=1e100.net; s=20161025; 27 h=x-gm-message-state:mime-version:in-reply-to:references:from:date 28 :message-id:subject:to; 29 bh=7PgTTLf1sqoqzbJfGJMc6no2Z4zp6SndMhnsg9t8qow=; 30 b=epRID7fi5kCY67v8x0SbirLlrhTyxEmGR5rp12BKaQ7/rViFuiBi09Swa8IUNalYwT 31 M5Y1axIaGg2a2WPZHxxbdv+9gi7CerWL1hNFaAQuAPUzuLTHsxieUKwATt/v6bqrBhPi 32 l3uLkqT4Et9pL10Ht+77CoPlkuzqzL/u7Mh490hGQgKsdDYvBMKRkKWY7QH0W5tEiFZb 33 lGX4pd4Lm19O+00SMcEf5gP2vKei9ef4xF6rx1Tmg6ZvWVOF3JvHS1zSu3wzahpL5KeL 34 3rqgiOmLOy7RPdoZiOgpJv2sY2ay1W/gHaW1yB5BGLQ8p/jHbedTiS3Cz6vICye9Ihsr 35 8A1A== 36 X-Gm-Message-State: AKGB3mIrhVZo/gCY29TKuj6fcBirBSowc8+NzNvZF88QdNKWazbpXg7F 37 VpWp9uyZLWeqzWfLrVPAcoEbh7ndASxkJItp8II= 38 X-Google-Smtp-Source: ACJfBosUYkB1PLBdWc+ZXnCAMm0yszOLsp1yadia0Aat+hdnC7ZZYlcvS+fbMVbeRFTnCNUUuy3L4qsCOHsZ9fX19jw= 39 X-Received: by 10.223.134.76 with SMTP id 12mr17056507wrw.137.1513966070693; 40 Fri, 22 Dec 2017 10:07:50 -0800 (PST) 41 MIME-Version: 1.0 42 Received: by 10.28.210.209 with HTTP; Fri, 22 Dec 2017 10:07:49 -0800 (PST) 43 Received: by 10.28.210.209 with HTTP; Fri, 22 Dec 2017 10:07:49 -0800 (PST) 44 In-Reply-To: <PS2P216MB0179FC39F4A63A43BB70011A9D020@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM> 45 References: <PS2P216MB01794ABD544248B27BF0DFD99D330@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM> 46 <PS2P216MB01795BFC05612E021CCEDD7C9D0B0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM> 47 <5upGmF0IhXUWhcikhdV-e9Pqg-kXfUuXe0kOpGxumie_TO2jLvCgTZ5c6vgBRtaqkL6DmOJb1YftK0osufB5RkhW7YhAhhCI0zBTH3YcORY=@protonmail.com> 48 <PS2P216MB0179544A6503C2992190CEB69D0B0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM> 49 <PS2P216MB0179D6A5965D0CFFEFB2880A9D090@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM> 50 <AB6BF756-29F1-4442-85A9-B81228E829EC@friedenbach.org> 51 <PS2P216MB017991D78147E2B1EC14C3059D0F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM> 52 <PS2P216MB0179FC39F4A63A43BB70011A9D020@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM> 53 From: Spartacus Rex <spartacusrex99@gmail.com> 54 Date: Fri, 22 Dec 2017 18:07:49 +0000 55 Message-ID: <CA+Cf5AaX5a5yuLcnkk=7boiqrSrZf4KG_RjSOF1-2qJtB9ds+Q@mail.gmail.com> 56 To: Damian Williamson <willtech@live.com.au>, 57 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 58 Content-Type: multipart/alternative; boundary="001a11491a40d8868f0560f1b1a4" 59 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, 60 DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, 61 HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 62 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 63 smtp1.linux-foundation.org 64 X-Mailman-Approved-At: Fri, 22 Dec 2017 18:36:58 +0000 65 Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction 66 Priority For Ordering Transactions In Blocks 67 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 68 X-Mailman-Version: 2.1.12 69 Precedence: list 70 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 71 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 72 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 73 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 74 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 75 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 76 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 77 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 78 X-List-Received-Date: Fri, 22 Dec 2017 18:07:56 -0000 79 80 --001a11491a40d8868f0560f1b1a4 81 Content-Type: text/plain; charset="UTF-8" 82 Content-Transfer-Encoding: quoted-printable 83 84 Hi Damian, 85 86 Thought I'd chip in. This is a hard fork scenario. This system has flaws, 87 they all do. 88 89 If you had a fixed fee per block, so that every txn in that block paid the 90 same fee, that might make it easier to include all txns eventually, as you 91 envisage. 92 93 The fee could be calculated as the average of the amount txns are prepared 94 to pay in the last 1000 blocks. 95 96 A txn would say ' I'll pay up to X bitcoins ' and as long as that is more 97 than the value required for the block your txn can be added. This is to 98 ensure you don't pay more than you are willing. It also ensures that 99 putting an enormous fee will not ensure your txn is processed quickly.. 100 101 Calculating what the outputs are given a variable fee needs a new mechanism 102 all of it's own, but I'm sure it's possible. 103 104 The simple fact is that there is currently no known system that works as 105 well as the current system.. 106 107 But there are other systems. 108 109 110 On Dec 22, 2017 15:09, "Damian Williamson via bitcoin-dev" < 111 bitcoin-dev@lists.linuxfoundation.org> wrote: 112 113 > If the cash value of Bitcoin was high enough and zero fee transactions 114 > were never accepted and not counted when calculating the transaction pool 115 > size then I do not think it would be such an issue. Why is it even possib= 116 le 117 > to create zero fee transactions? 118 > 119 > 120 > Regards, 121 > 122 > Damian Williamson 123 > 124 > ------------------------------ 125 > *From:* bitcoin-dev-bounces@lists.linuxfoundation.org < 126 > bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Damian 127 > Williamson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 128 > *Sent:* Tuesday, 19 December 2017 6:51 PM 129 > *To:* Mark Friedenbach 130 > *Cc:* bitcoin-dev@lists.linuxfoundation.org 131 > *Subject:* [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use 132 > Transaction Priority For Ordering Transactions In Blocks 133 > 134 > 135 > Thank you for your constructive feedback. I now see that the proposal 136 > introduces a potential issue. 137 > 138 > 139 > >Finally in terms of the broad goal, having block size based on the numbe= 140 r 141 > of transactions is NOT something desirable in the first place, even if it 142 > did work. That=E2=80=99s effectively the same as an infinite block size s= 143 ince 144 > anyone anywhere can create transactions in the mempool at no cost. 145 > 146 > 147 > Do you have any critical suggestion as to how transaction bandwidth limit 148 > could be addressed, it will eventually become an issue if nothing is 149 > changed regardless of how high fees go? 150 > 151 > 152 > Regards, 153 > Damian Williamson 154 > 155 > 156 > 157 > ------------------------------ 158 > *From:* Mark Friedenbach <mark@friedenbach.org> 159 > *Sent:* Tuesday, 19 December 2017 3:08 AM 160 > *To:* Damian Williamson 161 > *Subject:* Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use 162 > Transaction Priority For Ordering Transactions In Blocks 163 > 164 > Damian, you seem to be misunderstanding that either 165 > 166 > (1) the strong form of your proposal requires validating the commitment t= 167 o 168 > the mempool properties, in which case the mempool becomes consensus 169 > critical (an impossible requirement); or 170 > 171 > (2) in the weak form where the current block is dependent on the 172 > commitment in the last block only it is becomes a miner-selected field th= 173 ey 174 > can freely parameterize with no repercussions for setting values totally 175 > independent of the actual mempool. 176 > 177 > If you want to make the block size dependent on the properties of the 178 > mempool in a consensus critical way, flex cap achieves this. If you want = 179 to 180 > make the contents or properties of the mempool known to well-connected 181 > nodes, weak blocks achieves that. But you can=E2=80=99t stick the mempool= 182 in 183 > consensus because it fundamentally is not something the nodes have 184 > consensus over. That=E2=80=99s a chicken-and-the-egg assumption. 185 > 186 > Finally in terms of the broad goal, having block size based on the number 187 > of transactions is NOT something desirable in the first place, even if it 188 > did work. That=E2=80=99s effectively the same as an infinite block size s= 189 ince 190 > anyone anywhere can create transactions in the mempool at no cost. 191 > 192 > On Dec 16, 2017, at 8:14 PM, Damian Williamson via bitcoin-dev < 193 > bitcoin-dev@lists.linuxfoundation.org> wrote: 194 > 195 > I do not know why people make the leap that the proposal requires a 196 > consensus on the transaction pool. It does not. 197 > 198 > It may be helpful to have the discussion from the previous thread linked 199 > here. 200 > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ 201 > 2017-December/015370.html 202 > 203 > Where I speak of validating that a block conforms to the broadcast next 204 > block size, I do not propose validating the number broadcast for the next 205 > block size itself, only that the next generated block is that size. 206 > 207 > Regards, 208 > Damian Williamson 209 > 210 > 211 > ------------------------------ 212 > *From:* Damian Williamson <willtech@live.com.au> 213 > *Sent:* Saturday, 16 December 2017 7:59 AM 214 > *To:* Rhavar 215 > *Cc:* Bitcoin Protocol Discussion 216 > *Subject:* Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use 217 > Transaction Priority For Ordering Transactions In Blocks 218 > 219 > There are really two separate problems to solve. 220 > 221 > 222 > 1. How does Bitcoin scale with fixed block size? 223 > 2. How do we ensure that all valid transactions are eventually 224 > included in the blockchain? 225 > 226 > 227 > Those are the two issues that the proposal attempts to address. It makes 228 > sense to resolve these two problems together. Using the proposed system f= 229 or 230 > variable block sizes would solve the first problem but there would still = 231 be 232 > a whole bunch of never confirming transactions. I am not sure how to 233 > reliably solve the second problem at scale without first solving the firs= 234 t. 235 > 236 > >* Every node has a (potentially) different mempool, you can't use it to 237 > decide consensus values like the max block size. 238 > 239 > I do not suggest a consensus. Depending on which node solves a block the 240 > value for next block size will be different. The consensus would be that 241 > blocks will adhere to the next block size value transmitted with the 242 > current block. It is easy to verify that the consensus is being adhered t= 243 o 244 > once in place. 245 > 246 > >* Increasing the entropy in a block to make it more unpredictable doesn'= 247 t 248 > really make sense. 249 > 250 > Not a necessary function, just an effect of using a probability-based 251 > distribution. 252 > 253 > >* Bitcoin should be roughly incentive compatible. Your proposal explicit= 254 s 255 > asks miners to ignore their best interests, and confirm transactions by 256 > "priority". What are you going to do if a "malicious" miner decides to g= 257 o 258 > after their profits and order by what makes them the most money. Add 259 > "ordered by priority" as a consensus requirement? And even if you miners 260 > can still sort their mempool by fee, and then order the top 1MB by priori= 261 ty. 262 > 263 > I entirely agree with your sentiment that Bitcoin must be incentive 264 > compatible. It is necessary. 265 > 266 > It is in only miners immediate interest to make the most profitable block 267 > from the available transaction pool. As with so many other things, it is 268 > necessary to partially ignore short-term gain for long-term benefit. It i= 269 s 270 > in miners and everybody's long-term interest to have a reliable transacti= 271 on 272 > service. A busy transaction service that confirms lots of transactions pe= 273 r 274 > hour will become more profitable as demand increases and more users are 275 > prepared to pay for priority. As it is there is currently no way to fully 276 > scale because of the transaction bandwidth limit and that is problematic. 277 > If all valid transactions must eventually confirm then there must be a wa= 278 y 279 > to resolve that problem. 280 > 281 > Bitcoin deliberately removes traditional scale by ensuring blocks take te= 282 n 283 > minutes on average to solve, an ingenious idea and, incentive compatible 284 > but, fixed block sizes leaves us with a problem to solve when we want to 285 > scale. 286 > 287 > >If you could find a good solution that would allow you to know if miners 288 > were following your rule or not (and thus ignore it if it doesn't) then y= 289 ou 290 > wouldn't even need bitcoin in the first place. 291 > 292 > I am confident that the math to verify blocks based on the proposal can b= 293 e 294 > developed (and I think it will not be too complex for a mathematician wit= 295 h 296 > the relevant experience), however, I am nowhere near experienced enough 297 > with probability and statistical analysis to do it. Yes, if Bitcoin doesn= 298 't 299 > then it might make another great opportunity for an altcoin but I am not 300 > even nearly interested in promoting any altcoins. 301 > 302 > 303 > If not the proposal that I have put forward, then, hopefully, someone can 304 > come up with a better solution. The important thing is that the issues ar= 305 e 306 > resolved. 307 > 308 > Regards, 309 > Damian Williamson 310 > 311 > 312 > ------------------------------ 313 > *From:* Rhavar <rhavar@protonmail.com> 314 > *Sent:* Saturday, 16 December 2017 3:38 AM 315 > *To:* Damian Williamson 316 > *Cc:* Bitcoin Protocol Discussion 317 > *Subject:* Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use 318 > Transaction Priority For Ordering Transactions In Blocks 319 > 320 > > I understand that there would be technical issues to resolve in 321 > implementation, but, are there no fundamental errors? 322 > 323 > Unfortunately your proposal is really fundamentally broken, on a few 324 > levels. I think you might need to do a bit more research into how bitcoin 325 > works before coming up with such improvements =3D) 326 > 327 > But just some quick notes: 328 > 329 > * Every node has a (potentially) different mempool, you can't use it to 330 > decide consensus values like the max block size. 331 > 332 > * Increasing the entropy in a block to make it more unpredictable doesn't 333 > really make sense. 334 > 335 > * Bitcoin should be roughly incentive compatible. Your proposal explicits 336 > asks miners to ignore their best interests, and confirm transactions by 337 > "priority". What are you going to do if a "malicious" miner decides to g= 338 o 339 > after their profits and order by what makes them the most money. Add 340 > "ordered by priority" as a consensus requirement? And even if you miners 341 > can still sort their mempool by fee, and then order the top 1MB by priori= 342 ty. 343 > 344 > If you could find a good solution that would allow you to know if miners 345 > were following your rule or not (and thus ignore it if it doesn't) then y= 346 ou 347 > wouldn't even need bitcoin in the first place. 348 > 349 > 350 > 351 > 352 > -Ryan 353 > 354 > 355 > -------- Original Message -------- 356 > Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction 357 > Priority For Ordering Transactions In Blocks 358 > Local Time: December 15, 2017 3:42 AM 359 > UTC Time: December 15, 2017 9:42 AM 360 > From: bitcoin-dev@lists.linuxfoundation.org 361 > To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 362 > 363 > 364 > 365 > I should not take it that the lack of critical feedback to this revised 366 > proposal is a glowing endorsement. I understand that there would be 367 > technical issues to resolve in implementation, but, are there no 368 > fundamental errors? 369 > 370 > I suppose that it if is difficult to determine how long a transaction has 371 > been waiting in the pool then, each node could simply keep track of when = 372 a 373 > transaction was first seen. This may have implications for a verify 374 > routine, however, for example, if a node was offline, how should it 375 > differentiate how long each transaction was waiting in that case? If a no= 376 de 377 > was restarted daily would it always think that all transactions had been 378 > waiting in the pool less than one day If each node keeps the current 379 > transaction pool in a file and updates it, as transactions are included i= 380 n 381 > blocks and, as new transactions appear in the pool, then that would go so= 382 me 383 > way to alleviate the issue, apart from entirely new nodes. There should b= 384 e 385 > no reason the contents of a transaction pool files cannot be shared witho= 386 ut 387 > agreement as to the transaction pool between nodes, just as nodes 388 > transmit new transactions freely. 389 > 390 > It has been questioned why miners could not cheat. For the question of ho= 391 w 392 > many transactions to include in a block, I say it is a standoff and miner= 393 s 394 > will conform to the proposal, not wanting to leave transactions with vali= 395 d 396 > fees standing, and, not wanting to shrink the transaction pool. In any 397 > case, if miners shrink the transaction pool then I am not immediately 398 > concerned since it provides a more efficient service. For the question of 399 > including transactions according to the proposal, I say if it is possible 400 > to keep track of how long transactions are waiting in the pool so that th= 401 ey 402 > can be included on a probability curve then it is possible to verify that 403 > blocks conform to the proposal, since the input is a probability, the 404 > output should conform to a probability curve. 405 > 406 > 407 > If someone has the necessary skill, would anyone be willing to develop th= 408 e 409 > math necessary for the proposal? 410 > 411 > Regards, 412 > Damian Williamson 413 > 414 > 415 > ------------------------------ 416 > 417 > *From:* bitcoin-dev-bounces@lists.linuxfoundation.org <bit 418 > coin-dev-bounces@lists.linuxfoundation.org> on behalf of Damian 419 > Williamson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 420 > *Sent:* Friday, 8 December 2017 8:01 AM 421 > *To:* bitcoin-dev@lists.linuxfoundation.org 422 > *Subject:* [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use 423 > Transaction Priority For Ordering Transactions In Blocks 424 > 425 > 426 > Good afternoon, 427 > 428 > The need for this proposal: 429 > 430 > We all must learn to admit that transaction bandwidth is still lurking as 431 > a serious issue for the operation, reliability, safety, consumer 432 > acceptance, uptake and, for the value of Bitcoin. 433 > 434 > I recently sent a payment which was not urgent so; I chose three-day 435 > target confirmation from the fee recommendation. That transaction has sti= 436 ll 437 > not confirmed after now more than six days - even waiting twice as long 438 > seems quite reasonable to me. That transaction is a valid transaction; it 439 > is not rubbish, junk or, spam. Under the current model with transaction 440 > bandwidth limitation, the longer a transaction waits, the less likely it = 441 is 442 > ever to confirm due to rising transaction numbers and being pushed back b= 443 y 444 > transactions with rising fees. 445 > 446 > I argue that no transactions are rubbish or junk, only some zero fee 447 > transactions might be spam. Having an ever-increasing number of valid 448 > transactions that do not confirm as more new transactions with higher fee= 449 s 450 > are created is the opposite of operating a robust, reliable transaction 451 > system. 452 > 453 > Business cannot operate with a model where transactions may or may not 454 > confirm. Even a business choosing a modest fee has no guarantee that thei= 455 r 456 > valid transaction will not be shuffled down by new transactions to the 457 > realm of never confirming after it is created. Consumers also will not 458 > accept this model as Bitcoin expands. If Bitcoin cannot be a reliable 459 > payment system for confirmed transactions then consumers, by and large, 460 > will simply not accept the model once they understand. Bitcoin will be a 461 > dirty payment system, and this will kill the value of Bitcoin. 462 > 463 > Under the current system, a minority of transactions will eventually be 464 > the lucky few who have fees high enough to escape being pushed down the 465 > list. 466 > 467 > Once there are more than x transactions (transaction bandwidth limit) 468 > every ten minutes, only those choosing twenty-minute confirmation (2 469 > blocks) will have initially at most a fifty percent chance of ever having 470 > their payment confirm. Presently, not even using fee recommendations can 471 > ensure a sufficiently high fee is paid to ensure transaction confirmation= 472 . 473 > 474 > I also argue that the current auction model for limited transaction 475 > bandwidth is wrong, is not suitable for a reliable transaction system and= 476 , 477 > is wrong for Bitcoin. All transactions must confirm in due time. Currentl= 478 y, 479 > Bitcoin is not a safe way to send payments. 480 > 481 > I do not believe that consumers and business are against paying fees, eve= 482 n 483 > high fees. What is required is operational reliability. 484 > 485 > This great issue needs to be resolved for the safety and reliability of 486 > Bitcoin. The time to resolve issues in commerce is before they become gre= 487 at 488 > big issues. The time to resolve this issue is now. We must have the 489 > foresight to identify and resolve problems before they trip us over. 490 > Simply doubling block sizes every so often is reactionary and is not a 491 > reliable permanent solution. I have written a BIP proposal for a technica= 492 l 493 > solution but, need your help to write it up to an acceptable standard to = 494 be 495 > a full BIP. 496 > 497 > I have formatted the following with markdown which is human readable so, = 498 I 499 > hope nobody minds. I have done as much with this proposal as I feel that = 500 I 501 > am able so far but continue to take your feedback. 502 > 503 > # BIP Proposal: UTPFOTIB - Use Transaction Priority For Ordering 504 > Transactions In Blocks 505 > 506 > ## The problem: 507 > Everybody wants value. Miners want to maximize revenue from fees (and we 508 > presume, to minimize block size). Consumers need transaction reliability 509 > and, (we presume) want low fees. 510 > 511 > The current transaction bandwidth limit is a limiting factor for both. As 512 > the operational safety of transactions is limited, so is consumer 513 > confidence as they realize the issue and, accordingly, uptake is limited. 514 > Fees are artificially inflated due to bandwidth limitations while failing 515 > to provide a full confirmation service for all transactions. 516 > 517 > Current fee recommendations provide no satisfaction for transaction 518 > reliability and, as Bitcoin scales, this will worsen. 519 > 520 > Bitcoin must be a fully scalable and reliable service, providing full 521 > transaction confirmation for every valid transaction. 522 > 523 > The possibility to send a transaction with a fee lower than one that is 524 > acceptable to allow eventual transaction confirmation should be removed 525 > from the protocol and also from the user interface. 526 > 527 > ## Solution summary: 528 > Provide each transaction with an individual transaction priority each tim= 529 e 530 > before choosing transactions to include in the current block, the priorit= 531 y 532 > being a function of the fee paid (on a curve), and the time waiting in th= 533 e 534 > transaction pool (also on a curve) out to n days (n=3D60 ?). The transact= 535 ion 536 > priority to serve as the likelihood of a transaction being included in th= 537 e 538 > current block, and for determining the order in which transactions are 539 > tried to see if they will be included. 540 > 541 > Use a target block size. Determine the target block size using; current 542 > transaction pool size x ( 1 / (144 x n days ) ) =3D number of transaction= 543 s to 544 > be included in the current block. Broadcast the next target block size wi= 545 th 546 > the current block when it is solved so that nodes know the next target 547 > block size for the block that they are building on. 548 > 549 > The curves used for the priority of transactions would have to be 550 > appropriate. Perhaps a mathematician with experience in probability can 551 > develop the right formulae. My thinking is a steep curve. I suppose that 552 > the probability of all transactions should probably account for a 553 > sufficient number of inclusions that the target block size is met althoug= 554 h, 555 > it may not always be. As a suggestion, consider including some zero fee 556 > transactions to pad, highest BTC value first? 557 > 558 > **Explanation of the operation of priority:** 559 > > If transaction priority is, for example, a number between one (low) and 560 > one-hundred (high) it can be directly understood as the percentage chance 561 > in one-hundred of a transaction being included in the block. Using 562 > probability or likelihood infers that there is some function of random. I= 563 f 564 > random (100) < transaction priority then the transaction is included. 565 > 566 > >To break it down further, if both the fee on a curve value and the time 567 > waiting on a curve value are each a number between one and one-hundred, a 568 > rudimentary method may be to simply multiply those two numbers, to find t= 569 he 570 > priority number. For example, a middle fee transaction waiting thirty day= 571 s 572 > (if n =3D 60 days) may have a value of five for each part (yes, just fiv= 573 e, 574 > the values are on a curve). When multiplied that will give a priority val= 575 ue 576 > of twenty-five, or, a twenty-five percent chance at that moment of being 577 > included in the block; it will likely be included in one of the next four 578 > blocks, getting more likely each chance. If it is still not included then 579 > the value of time waiting will be higher, making for more probability. A 580 > very low fee transaction would have a value for the fee of one. It would 581 > not be until near sixty-days that the particular low fee transaction has = 582 a 583 > high likelihood of being included in the block. 584 > 585 > I am not concerned with low (or high) transaction fees, the primary reaso= 586 n 587 > for addressing the issue is to ensure transactional reliability and 588 > scalability while having each transaction confirm in due time. 589 > 590 > ## Pros: 591 > * Maximizes transaction reliability. 592 > * Fully scalable. 593 > * Maximizes possibility for consumer and business uptake. 594 > * Maximizes total fees paid per block without reducing reliability; 595 > because of reliability, in time confidence and overall uptake are greater= 596 ; 597 > therefore, more transactions. 598 > * Market determines fee paid for transaction priority. 599 > * Fee recommendations work all the way out to 30 days or greater. 600 > * Provides additional block entropy; greater security since there is less 601 > probability of predicting the next block. 602 > 603 > ## Cons: 604 > * Could initially lower total transaction fees per block. 605 > * Must be first be programmed. 606 > 607 > ## Solution operation: 608 > This is a simplistic view of the operation. The actual operation will nee= 609 d 610 > to be determined in a spec for the programmer. 611 > 612 > 1. Determine the target block size for the current block. 613 > 2. Assign a transaction priority to each transaction in the pool. 614 > 3. Select transactions to include in the current block using probability 615 > in transaction priority order until the target block size is met. 616 > 5. Solve block. 617 > 6. Broadcast the next target block size with the current block when it is 618 > solved. 619 > 7. Block is received. 620 > 8. Block verification process. 621 > 9. Accept/reject block based on verification result. 622 > 10. Repeat. 623 > 624 > ## Closing comments: 625 > It may be possible to verify blocks conform to the proposal by showing 626 > that the probability for all transactions included in the block 627 > statistically conforms to a probability distribution curve, *if* the 628 > individual transaction priority can be recreated. I am not that deep into 629 > the mathematics; however, it may also be possible to use a similar method 630 > to do this just based on the fee, that statistically, the blocks conform = 631 to 632 > a fee distribution. Any zero fee transactions would have to be ignored. 633 > This solution needs a clever mathematician. 634 > 635 > I implore, at the very least, that we use some method that validates full 636 > transaction reliability and enables scalability of block sizes. If not th= 637 is 638 > proposal, an alternative. 639 > 640 > Regards, 641 > Damian Williamson 642 > 643 > 644 > _______________________________________________ 645 > bitcoin-dev mailing list 646 > bitcoin-dev@lists.linuxfoundation.org 647 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 648 > 649 > 650 > 651 > _______________________________________________ 652 > bitcoin-dev mailing list 653 > bitcoin-dev@lists.linuxfoundation.org 654 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 655 > 656 > 657 658 --001a11491a40d8868f0560f1b1a4 659 Content-Type: text/html; charset="UTF-8" 660 Content-Transfer-Encoding: quoted-printable 661 662 <div dir=3D"auto">Hi Damian,<div dir=3D"auto"><br></div><div dir=3D"auto">T= 663 hought I'd chip in.=C2=A0 This is a hard fork scenario. This system has= 664 flaws, they all do.</div><div dir=3D"auto"><br></div><div dir=3D"auto">If = 665 you had a fixed fee per block, so that every txn in that block paid the sam= 666 e fee, that might make it easier to include all txns eventually, as you env= 667 isage.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The fee could be = 668 calculated as the average of the amount txns are prepared to pay in the las= 669 t 1000 blocks.</div><div dir=3D"auto"><br></div><div dir=3D"auto">A txn wou= 670 ld say ' I'll pay up to X bitcoins ' and as long as that is mor= 671 e than the value required for the block your txn can be added. This is to e= 672 nsure you don't pay more than you are willing.=C2=A0 It also ensures th= 673 at putting an enormous fee will not ensure your txn is processed quickly..<= 674 /div><div dir=3D"auto"><br></div><div dir=3D"auto">Calculating what the out= 675 puts are given a variable fee needs a new mechanism all of it's own, bu= 676 t I'm sure it's possible.</div><div dir=3D"auto"><br></div><div dir= 677 =3D"auto">The simple fact is that there is currently no known system that w= 678 orks as well as the current system..=C2=A0</div><div dir=3D"auto"><br></div= 679 ><div dir=3D"auto">But there are other systems.=C2=A0</div><div dir=3D"auto= 680 "><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"= 681 >On Dec 22, 2017 15:09, "Damian Williamson via bitcoin-dev" <<= 682 a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= 683 itcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br type=3D"attribu= 684 tion"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= 685 eft:1px #ccc solid;padding-left:1ex"> 686 687 688 689 690 <div dir=3D"ltr"> 691 <div id=3D"m_4574273483018812099divtagdefaultwrapper" style=3D"font-size:12= 692 pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,"EmojiFon= 693 t","Apple Color Emoji","Segoe UI Emoji",NotoColorE= 694 moji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" di= 695 r=3D"ltr"> 696 <p style=3D"margin-top:0;margin-bottom:0"><span>If the cash value of Bitcoi= 697 n was high enough and zero fee transactions were never accepted and not cou= 698 nted when calculating the transaction pool size then I do not think it woul= 699 d be such an issue. Why is it even 700 possible to create zero fee transactions?</span></p> 701 <p style=3D"margin-top:0;margin-bottom:0"><span><br> 702 </span></p> 703 <p style=3D"margin-top:0;margin-bottom:0"><span>Regards,</span></p> 704 <p style=3D"margin-top:0;margin-bottom:0"><span>Damian Williamson</span><br= 705 > 706 </p> 707 <br> 708 <div style=3D"color:rgb(0,0,0)"> 709 <hr style=3D"display:inline-block;width:98%"> 710 <div id=3D"m_4574273483018812099divRplyFwdMsg" dir=3D"ltr"><font style=3D"f= 711 ont-size:11pt" face=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> = 712 <a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"= 713 _blank">bitcoin-dev-bounces@lists.<wbr>linuxfoundation.org</a> <<a href= 714 =3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"_blank"= 715 >bitcoin-dev-bounces@lists.<wbr>linuxfoundation.org</a>> on behalf of Da= 716 mian Williamson via bitcoin-dev 717 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= 718 ank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>><br> 719 <b>Sent:</b> Tuesday, 19 December 2017 6:51 PM<br> 720 <b>To:</b> Mark Friedenbach<br> 721 <b>Cc:</b> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= 722 =3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br> 723 <b>Subject:</b> [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transac= 724 tion Priority For Ordering Transactions In Blocks</font> 725 <div>=C2=A0</div> 726 </div> 727 <div dir=3D"ltr"> 728 <div id=3D"m_4574273483018812099x_divtagdefaultwrapper" dir=3D"ltr" style= 729 =3D"font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-seri= 730 f,"EmojiFont","Apple Color Emoji","Segoe UI Emoji&= 731 quot;,NotoColorEmoji,"Segoe UI Symbol","Android Emoji",= 732 EmojiSymbols"> 733 <p style=3D"margin-top:0;margin-bottom:0"></p> 734 <div> 735 <p style=3D"margin-top:0;margin-bottom:0">Thank you for your constructive f= 736 eedback. I now see that the proposal introduces a potential issue.</p> 737 <p style=3D"margin-top:0;margin-bottom:0"><br> 738 </p> 739 <p style=3D"margin-top:0;margin-bottom:0"><span>>Finally in terms of the= 740 broad goal, having block size based on the number of transactions is NOT s= 741 omething desirable in the first place, even if it did work. That=E2=80=99s = 742 effectively the same as an infinite block size 743 since anyone anywhere can create transactions in the mempool at no cost.</= 744 span></p> 745 <p style=3D"margin-top:0;margin-bottom:0"><br> 746 </p> 747 <p style=3D"margin-top:0;margin-bottom:0">Do you have any critical suggesti= 748 on as to how transaction bandwidth limit could be addressed, it will eventu= 749 ally become an issue if nothing is changed regardless of how high fees go?<= 750 br> 751 </p> 752 <p style=3D"margin-top:0;margin-bottom:0"><br> 753 </p> 754 <p style=3D"margin-top:0;margin-bottom:0">Regards,</p> 755 Damian Williamson</div> 756 <br> 757 <p></p> 758 <br> 759 <br> 760 <div style=3D"color:rgb(0,0,0)"> 761 <hr style=3D"display:inline-block;width:98%"> 762 <div id=3D"m_4574273483018812099x_divRplyFwdMsg" dir=3D"ltr"><font style=3D= 763 "font-size:11pt" face=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b= 764 > Mark Friedenbach <<a href=3D"mailto:mark@friedenbach.org" target=3D"_b= 765 lank">mark@friedenbach.org</a>><br> 766 <b>Sent:</b> Tuesday, 19 December 2017 3:08 AM<br> 767 <b>To:</b> Damian Williamson<br> 768 <b>Subject:</b> Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Tra= 769 nsaction Priority For Ordering Transactions In Blocks</font> 770 <div>=C2=A0</div> 771 </div> 772 <div style=3D"word-wrap:break-word;line-break:after-white-space">Damian, yo= 773 u seem to be misunderstanding that either 774 <div><br> 775 </div> 776 <div>(1) the strong form of your proposal requires validating the commitmen= 777 t to the mempool properties, in which case the mempool becomes consensus cr= 778 itical (an impossible requirement); or</div> 779 <div><br> 780 </div> 781 <div>(2) in the weak form where the current block is dependent on the commi= 782 tment in the last block only it is becomes a miner-selected field they can = 783 freely parameterize with no repercussions for setting values totally indepe= 784 ndent of the actual mempool.</div> 785 <div><br> 786 </div> 787 <div>If you want to make the block size dependent on the properties of the = 788 mempool in a consensus critical way, flex cap achieves this. If you want to= 789 make the contents or properties of the mempool known to well-connected nod= 790 es, weak blocks achieves 791 that. But you can=E2=80=99t stick the mempool in consensus because it fund= 792 amentally is not something the nodes have consensus over. That=E2=80=99s a = 793 chicken-and-the-egg assumption.</div> 794 <div><br> 795 </div> 796 <div>Finally in terms of the broad goal, having block size based on the num= 797 ber of transactions is NOT something desirable in the first place, even if = 798 it did work. That=E2=80=99s effectively the same as an infinite block size = 799 since anyone anywhere can create 800 transactions in the mempool at no cost.<br> 801 <div> 802 <div><br> 803 <blockquote type=3D"cite"> 804 <div>On Dec 16, 2017, at 8:14 PM, Damian Williamson via bitcoin-dev <<a = 805 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit= 806 coin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:</div> 807 <br class=3D"m_4574273483018812099x_x_Apple-interchange-newline"> 808 <div> 809 <div id=3D"m_4574273483018812099x_x_divtagdefaultwrapper" dir=3D"ltr" style= 810 =3D"font-style:normal;font-weight:normal;letter-spacing:normal;text-align:s= 811 tart;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p= 812 x;font-size:12pt;font-family:Calibri,Helvetica,sans-serif,EmojiFont,"A= 813 pple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Sego= 814 e UI Symbol","Android Emoji",EmojiSymbols"> 815 <div style=3D"margin-top:0px;margin-bottom:0px">I do not know why people ma= 816 ke the leap that the proposal requires a consensus on the transaction pool.= 817 It does not.<br> 818 </div> 819 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 820 </div> 821 <div style=3D"margin-top:0px;margin-bottom:0px">It may be helpful to have t= 822 he discussion from the previous thread linked here.</div> 823 <div style=3D"margin-top:0px;margin-bottom:0px"><a href=3D"https://lists.li= 824 nuxfoundation.org/pipermail/bitcoin-dev/2017-December/015370.html" class=3D= 825 "m_4574273483018812099x_x_OWAAutoLink" id=3D"m_4574273483018812099LPlnk7414= 826 90" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/pipermail/bitc= 827 oin-dev/<wbr>2017-December/015370.html</a><br> 828 </div> 829 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 830 </div> 831 <div style=3D"margin-top:0px;margin-bottom:0px">Where I speak of validating= 832 that a block conforms to the broadcast next block size, I do not propose v= 833 alidating the number broadcast for the next block size itself, only that th= 834 e next generated block is 835 that size.<br> 836 </div> 837 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 838 </div> 839 <div style=3D"margin-top:0px;margin-bottom:0px">Regards,</div> 840 <div style=3D"margin-top:0px;margin-bottom:0px">Damian Williamson<br> 841 </div> 842 <br> 843 <br> 844 <div> 845 <hr style=3D"display:inline-block;width:654.625px"> 846 <div id=3D"m_4574273483018812099x_x_divRplyFwdMsg" dir=3D"ltr"><font style= 847 =3D"font-size:11pt" face=3D"Calibri, sans-serif"><b>From:</b><span class=3D= 848 "m_4574273483018812099x_x_Apple-converted-space">=C2=A0</span>Damian Willia= 849 mson <<a href=3D"mailto:willtech@live.com.au" target=3D"_blank">willtech= 850 @live.com.au</a>><br> 851 <b>Sent:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-space">= 852 =C2=A0</span>Saturday, 16 December 2017 7:59 AM<br> 853 <b>To:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-space">= 854 =C2=A0</span>Rhavar<br> 855 <b>Cc:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-space">= 856 =C2=A0</span>Bitcoin Protocol Discussion<br> 857 <b>Subject:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-spac= 858 e">=C2=A0</span>Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Tra= 859 nsaction Priority For Ordering Transactions In Blocks</font> 860 <div>=C2=A0</div> 861 </div> 862 <div dir=3D"ltr"> 863 <div id=3D"m_4574273483018812099x_x_x_divtagdefaultwrapper" dir=3D"ltr" sty= 864 le=3D"font-size:12pt;font-family:Calibri,Helvetica,sans-serif,EmojiFont,&qu= 865 ot;Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"= 866 Segoe UI Symbol","Android Emoji",EmojiSymbols"> 867 <div style=3D"margin-top:0px;margin-bottom:0px">There are really two separa= 868 te problems to solve.</div> 869 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 870 </div> 871 <ol style=3D"margin-bottom:0px;margin-top:0px"> 872 <li>How does Bitcoin scale with fixed block size?</li><li>How do we ensure = 873 that all valid transactions are eventually included in the blockchain?</li>= 874 </ol> 875 <br> 876 <div style=3D"margin-top:0px;margin-bottom:0px">Those are the two issues th= 877 at the proposal attempts to address. It makes sense to resolve these two pr= 878 oblems together. Using the proposed system for variable block sizes would s= 879 olve the first problem but 880 there would still be a whole bunch of never confirming transactions. I am = 881 not sure how to reliably solve the second problem at scale without first so= 882 lving the first.<br> 883 </div> 884 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 885 </div> 886 <div style=3D"margin-top:0px;margin-bottom:0px">>* Every node has a (pot= 887 entially) different mempool, you can't use it to decide consensus value= 888 s like the max block size.=C2=A0<br> 889 </div> 890 <div><br> 891 I do not suggest a consensus. Depending on which node solves a block the va= 892 lue for next block size will be different. The consensus would be that bloc= 893 ks will adhere to the next block size value transmitted with the current bl= 894 ock. It is easy to verify that the 895 consensus is being adhered to once in place.<br> 896 =C2=A0<br> 897 </div> 898 <div>>* Increasing the entropy in a block to make it more unpredictable = 899 doesn't really make sense.=C2=A0</div> 900 <div><br> 901 Not a necessary function, just an effect of using a probability-based distr= 902 ibution.<span class=3D"m_4574273483018812099x_x_Apple-converted-space">=C2= 903 =A0</span><br> 904 <br> 905 </div> 906 <div>>* Bitcoin should be roughly incentive compatible. Your proposal ex= 907 plicits asks miners to ignore their best interests, and confirm transaction= 908 s by "priority".=C2=A0 What are you going to do if a "malici= 909 ous" miner decides to go after their profits and 910 order by what makes them the most money. Add "ordered by priority&quo= 911 t; as a consensus requirement? And even if you miners can still sort their = 912 mempool by fee, and then order the top 1MB by priority.<br> 913 <br> 914 I entirely agree with your sentiment that Bitcoin must be incentive compati= 915 ble. It is necessary.<br> 916 <br> 917 It is in only miners immediate interest to make the most profitable block f= 918 rom the available transaction pool. As with so many other things, it is nec= 919 essary to partially ignore short-term gain for long-term benefit. It is in = 920 miners and everybody's long-term 921 interest to have a reliable transaction service. A busy transaction servic= 922 e that confirms lots of transactions per hour will become more profitable a= 923 s demand increases and more users are prepared to pay for priority. As it i= 924 s there is currently no way to fully 925 scale because of the transaction bandwidth limit and that is problematic. = 926 If all valid transactions must eventually confirm then there must be a way = 927 to resolve that problem.<br> 928 <br> 929 Bitcoin deliberately removes traditional scale by ensuring blocks take ten = 930 minutes on average to solve, an ingenious idea and, incentive compatible bu= 931 t, fixed block sizes leaves us with a problem to solve when we want to scal= 932 e.<br> 933 <br> 934 </div> 935 <div>>If you could find a good solution that would allow you to know if = 936 miners were following your rule or not (and thus ignore it if it doesn'= 937 t) then you wouldn't even need bitcoin in the first place.<br> 938 <br> 939 I am confident that the math to verify blocks based on the proposal can be = 940 developed (and I think it will not be too complex for a mathematician with = 941 the relevant experience), however, I am nowhere near experienced enough wit= 942 h probability and statistical analysis 943 to do it. Yes, if Bitcoin doesn't then it might make another great opp= 944 ortunity for an altcoin but I am not even nearly interested in promoting an= 945 y altcoins.<br> 946 </div> 947 <p style=3D"margin-top:0px;margin-bottom:0px"></p> 948 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 949 </div> 950 <div style=3D"margin-top:0px;margin-bottom:0px">If not the proposal that I = 951 have put forward, then, hopefully, someone can come up with a better soluti= 952 on. The important thing is that the issues are resolved.<br> 953 </div> 954 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 955 </div> 956 <div style=3D"margin-top:0px;margin-bottom:0px">Regards,</div> 957 <div style=3D"margin-top:0px;margin-bottom:0px">Damian Williamson<br> 958 </div> 959 <br> 960 <br> 961 <div> 962 <hr style=3D"display:inline-block;width:654.625px"> 963 <div id=3D"m_4574273483018812099x_x_x_divRplyFwdMsg" dir=3D"ltr"><font styl= 964 e=3D"font-size:11pt" face=3D"Calibri, sans-serif"><b>From:</b><span class= 965 =3D"m_4574273483018812099x_x_Apple-converted-space">=C2=A0</span>Rhavar <= 966 ;<a href=3D"mailto:rhavar@protonmail.com" target=3D"_blank">rhavar@protonma= 967 il.com</a>><br> 968 <b>Sent:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-space">= 969 =C2=A0</span>Saturday, 16 December 2017 3:38 AM<br> 970 <b>To:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-space">= 971 =C2=A0</span>Damian Williamson<br> 972 <b>Cc:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-space">= 973 =C2=A0</span>Bitcoin Protocol Discussion<br> 974 <b>Subject:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-spac= 975 e">=C2=A0</span>Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Tra= 976 nsaction Priority For Ordering Transactions In Blocks</font> 977 <div>=C2=A0</div> 978 </div> 979 <div> 980 <div>>=C2=A0I understand that there would be technical issues to resolve= 981 in implementation, but, are there no fundamental errors?<br> 982 </div> 983 <div><br> 984 </div> 985 <div>Unfortunately your proposal is really fundamentally broken, on a few l= 986 evels. I think you might need to do a bit more research into how bitcoin wo= 987 rks before coming up with such improvements =3D)<br> 988 </div> 989 <div><br> 990 </div> 991 <div>But just some quick notes:<br> 992 </div> 993 <div><br> 994 </div> 995 <div>* Every node has a (potentially) different mempool, you can't use = 996 it to decide consensus values like the max block size.=C2=A0<br> 997 </div> 998 <div><br> 999 </div> 1000 <div>* Increasing the entropy in a block to make it more unpredictable does= 1001 n't really make sense.=C2=A0</div> 1002 <div><br> 1003 </div> 1004 <div>* Bitcoin should be roughly incentive compatible. Your proposal explic= 1005 its asks miners to ignore their best interests, and confirm transactions by= 1006 "priority".=C2=A0 What are you going to do if a "malicious&= 1007 quot; miner decides to go after their profits and 1008 order by what makes them the most money. Add "ordered by priority&quo= 1009 t; as a consensus requirement? And even if you miners can still sort their = 1010 mempool by fee, and then order the top 1MB by priority.<br> 1011 </div> 1012 <div><br> 1013 </div> 1014 <div>If you could find a good solution that would allow you to know if mine= 1015 rs were following your rule or not (and thus ignore it if it doesn't) t= 1016 hen you wouldn't even need bitcoin in the first place.</div> 1017 <div><br> 1018 </div> 1019 <div><br> 1020 </div> 1021 <div><br> 1022 </div> 1023 <div><br> 1024 </div> 1025 <div class=3D"m_4574273483018812099x_x_x_x_protonmail_signature_block"> 1026 <div class=3D"m_4574273483018812099x_x_x_x_protonmail_signature_block-user"= 1027 > 1028 <div>-Ryan<br> 1029 </div> 1030 </div> 1031 <div class=3D"m_4574273483018812099x_x_x_x_protonmail_signature_block-proto= 1032 n m_4574273483018812099x_x_x_x_protonmail_signature_block-empty"> 1033 <br> 1034 </div> 1035 </div> 1036 <div><br> 1037 </div> 1038 <blockquote class=3D"m_4574273483018812099x_x_x_x_protonmail_quote" type=3D= 1039 "cite"> 1040 <div>-------- Original Message --------<br> 1041 </div> 1042 <div>Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transacti= 1043 on Priority For Ordering Transactions In Blocks<br> 1044 </div> 1045 <div>Local Time: December 15, 2017 3:42 AM<br> 1046 </div> 1047 <div>UTC Time: December 15, 2017 9:42 AM<br> 1048 </div> 1049 <div>From:<span class=3D"m_4574273483018812099x_x_Apple-converted-space">= 1050 =C2=A0</span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe= 1051 t=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br> 1052 </div> 1053 <div>To: Bitcoin Protocol Discussion <<a href=3D"mailto:bitcoin-dev@list= 1054 s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfounda= 1055 tion.org</a>><br> 1056 </div> 1057 <div><br> 1058 </div> 1059 <div><br> 1060 </div> 1061 <div dir=3D"ltr" style=3D"font-size:12pt;font-family:Calibri,Helvetica,sans= 1062 -serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",N= 1063 otoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSy= 1064 mbols"> 1065 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 1066 </div> 1067 <div> 1068 <div>I should not take it that the lack of critical feedback to this revise= 1069 d proposal is a glowing endorsement. I understand that there would be techn= 1070 ical issues to resolve in implementation, but, are there no fundamental err= 1071 ors?<br> 1072 </div> 1073 <div><br> 1074 </div> 1075 <div>I suppose that it if is difficult to determine how long a transaction = 1076 has been waiting in the pool then, each node could simply keep track of whe= 1077 n a transaction was first seen. This may have implications for a verify rou= 1078 tine, however, for example, 1079 if a node was offline, how should it differentiate how long each transacti= 1080 on was waiting in that case? If a node was restarted daily would it always = 1081 think that all transactions had been waiting in the pool less than one day = 1082 If each node keeps the current transaction 1083 pool in a file and updates it, as transactions are included in blocks and,= 1084 as new transactions appear in the pool, then that would go some way to all= 1085 eviate the issue, apart from entirely new nodes. There should be no reason = 1086 the contents of a transaction pool 1087 files cannot be shared without agreement as to the transaction pool<span c= 1088 lass=3D"m_4574273483018812099x_x_Apple-converted-space">=C2=A0</span><span>= 1089 between nodes</span>, just as nodes transmit new transactions freely.<br> 1090 </div> 1091 <div><br> 1092 </div> 1093 <div>It has been questioned why miners could not cheat. For the question of= 1094 how many transactions to include in a block, I say it is a standoff and mi= 1095 ners will conform to the proposal, not wanting to leave transactions with v= 1096 alid fees standing, and, 1097 not wanting to shrink the transaction pool. In any case, if miners shrink = 1098 the transaction pool then I am not immediately concerned since it provides = 1099 a more efficient service. For the question of including transactions accord= 1100 ing to the proposal, I say if it 1101 is possible to keep track of how long transactions are waiting in the pool= 1102 so that they can be included on a probability curve then it is possible to= 1103 verify that blocks conform to the proposal, since the input is a probabili= 1104 ty, the output should conform to 1105 a probability curve.<br> 1106 </div> 1107 </div> 1108 <div><br> 1109 </div> 1110 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 1111 </div> 1112 <div>If someone has the necessary skill, would anyone be willing to develop= 1113 the math necessary for the proposal?<br> 1114 </div> 1115 <div><br> 1116 </div> 1117 <div>Regards,<br> 1118 </div> 1119 <div>Damian Williamson<br> 1120 </div> 1121 <div><br> 1122 </div> 1123 <div><br> 1124 </div> 1125 <div> 1126 <div> 1127 <hr style=3D"display:inline-block;width:644.828125px"> 1128 <span class=3D"m_4574273483018812099x_x_Apple-converted-space">=C2=A0</span= 1129 ><br> 1130 </div> 1131 <div dir=3D"ltr"> 1132 <div><span class=3D"m_4574273483018812099x_x_x_x_font" style=3D"font-family= 1133 :Calibri,sans-serif"><span class=3D"m_4574273483018812099x_x_x_x_colour"><b= 1134 >From:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-space">= 1135 =C2=A0</span><a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.or= 1136 g" target=3D"_blank">bitcoin-dev-bounces@<wbr>lists.linuxfoundation.org</a>= 1137 <span class=3D"m_4574273483018812099x_x_Apple-converted-space">=C2=A0</span= 1138 ><<a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" targe= 1139 t=3D"_blank">bit<wbr>coin-dev-bounces@lists.<wbr>linuxfoundation.org</a>>= 1140 ; 1141 on behalf of Damian Williamson via bitcoin-dev <<a href=3D"mailto:bitco= 1142 in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>= 1143 linuxfoundation.org</a>><br> 1144 <b>Sent:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-space">= 1145 =C2=A0</span>Friday, 8 December 2017 8:01 AM<br> 1146 <b>To:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-space">= 1147 =C2=A0</span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe= 1148 t=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br> 1149 <b>Subject:</b><span class=3D"m_4574273483018812099x_x_Apple-converted-spac= 1150 e">=C2=A0</span>[bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transac= 1151 tion Priority For Ordering Transactions In Blocks</span></span></div> 1152 <div>=C2=A0<br> 1153 </div> 1154 </div> 1155 <div dir=3D"ltr"> 1156 <div dir=3D"ltr" style=3D"font-size:12pt;font-family:Calibri,Helvetica,sans= 1157 -serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",N= 1158 otoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSy= 1159 mbols"> 1160 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 1161 </div> 1162 <div> 1163 <div>Good afternoon,<br> 1164 </div> 1165 <div><br> 1166 </div> 1167 <div>The need for this proposal:<br> 1168 </div> 1169 <div><br> 1170 </div> 1171 <div>We all must learn to admit that transaction bandwidth is still lurking= 1172 as a serious issue for the operation, reliability, safety, consumer accept= 1173 ance, uptake and, for the value of Bitcoin.<br> 1174 </div> 1175 <div><br> 1176 </div> 1177 <div>I recently sent a payment which was not urgent so; I chose three-day t= 1178 arget confirmation from the fee recommendation. That transaction has still = 1179 not confirmed after now more than six days - even waiting twice as long see= 1180 ms quite reasonable to 1181 me. That transaction is a valid transaction; it is not rubbish, junk or, s= 1182 pam. Under the current model with transaction bandwidth limitation, the lon= 1183 ger a transaction waits, the less likely it is ever to confirm due to risin= 1184 g transaction numbers and being 1185 pushed back by transactions with rising fees.<br> 1186 </div> 1187 <div><br> 1188 </div> 1189 <div>I argue that no transactions are rubbish or junk, only some zero fee t= 1190 ransactions might be spam. Having an ever-increasing number of valid transa= 1191 ctions that do not confirm as more new transactions with higher fees are cr= 1192 eated is the opposite of 1193 operating a robust, reliable transaction system.<br> 1194 </div> 1195 <div><br> 1196 </div> 1197 <div>Business cannot operate with a model where transactions may or may not= 1198 confirm. Even a business choosing a modest fee has no guarantee that their= 1199 valid transaction will not be shuffled down by new transactions to the rea= 1200 lm of never confirming 1201 after it is created. Consumers also will not accept this model as Bitcoin = 1202 expands. If Bitcoin cannot be a reliable payment system for confirmed trans= 1203 actions then consumers, by and large, will simply not accept the model once= 1204 they understand. Bitcoin will be 1205 a dirty payment system, and this will kill the value of Bitcoin.<br> 1206 </div> 1207 <div><br> 1208 </div> 1209 <div>Under the current system, a minority of transactions will eventually b= 1210 e the lucky few who have fees high enough to escape being pushed down the l= 1211 ist.<br> 1212 </div> 1213 <div><br> 1214 </div> 1215 <div>Once there are more than x transactions (transaction bandwidth limit) = 1216 every ten minutes, only those choosing twenty-minute confirmation (2 blocks= 1217 ) will have initially at most a fifty percent chance of ever having their p= 1218 ayment confirm. Presently, 1219 not even using fee recommendations can ensure a sufficiently high fee is p= 1220 aid to ensure transaction confirmation.<br> 1221 </div> 1222 <div><br> 1223 </div> 1224 <div>I also argue that the current auction model for limited transaction ba= 1225 ndwidth is wrong, is not suitable for a reliable transaction system and, is= 1226 wrong for Bitcoin. All transactions must confirm in due time. Currently, B= 1227 itcoin is not a safe way 1228 to send payments.<br> 1229 </div> 1230 <div><br> 1231 </div> 1232 <div>I do not believe that consumers and business are against paying fees, = 1233 even high fees. What is required is operational reliability.<br> 1234 </div> 1235 <div><br> 1236 </div> 1237 <div>This great issue needs to be resolved for the safety and reliability o= 1238 f Bitcoin. The time to resolve issues in commerce is before they become gre= 1239 at big issues. The time to resolve this issue is now. We must have the fore= 1240 sight to identify and resolve 1241 problems before they trip us over.=C2=A0 Simply doubling block sizes every= 1242 so often is reactionary and is not a reliable permanent solution. I have w= 1243 ritten a BIP proposal for a technical solution but, need your help to write= 1244 it up to an acceptable standard to be 1245 a full BIP.<br> 1246 </div> 1247 <div><br> 1248 </div> 1249 <div>I have formatted the following with markdown which is human readable s= 1250 o, I hope nobody minds. I have done as much with this proposal as I feel th= 1251 at I am able so far but continue to take your feedback.<br> 1252 </div> 1253 <div><br> 1254 </div> 1255 <div># BIP Proposal: UTPFOTIB - Use Transaction Priority For Ordering Trans= 1256 actions In Blocks<br> 1257 </div> 1258 <div><br> 1259 </div> 1260 <div>## The problem:<br> 1261 </div> 1262 <div>Everybody wants value. Miners want to maximize revenue from fees (and = 1263 we presume, to minimize block size). Consumers need transaction reliability= 1264 and, (we presume) want low fees.<br> 1265 </div> 1266 <div><br> 1267 </div> 1268 <div>The current transaction bandwidth limit is a limiting factor for both.= 1269 As the operational safety of transactions is limited, so is consumer confi= 1270 dence as they realize the issue and, accordingly, uptake is limited. Fees a= 1271 re artificially inflated 1272 due to bandwidth limitations while failing to provide a full confirmation = 1273 service for all transactions.<br> 1274 </div> 1275 <div><br> 1276 </div> 1277 <div>Current fee recommendations provide no satisfaction for transaction re= 1278 liability and, as Bitcoin scales, this will worsen.<br> 1279 </div> 1280 <div><br> 1281 </div> 1282 <div>Bitcoin must be a fully scalable and reliable service, providing full = 1283 transaction confirmation for every valid transaction.<br> 1284 </div> 1285 <div><br> 1286 </div> 1287 <div>The possibility to send a transaction with a fee lower than one that i= 1288 s acceptable to allow eventual transaction confirmation should be removed f= 1289 rom the protocol and also from the user interface.<br> 1290 </div> 1291 <div><br> 1292 </div> 1293 <div>## Solution summary:<br> 1294 </div> 1295 <div>Provide each transaction with an individual transaction priority each = 1296 time before choosing transactions to include in the current block, the prio= 1297 rity being a function of the fee paid (on a curve), and the time waiting in= 1298 the transaction pool (also 1299 on a curve) out to n days (n=3D60 ?). The transaction priority to serve as= 1300 the likelihood of a transaction being included in the current block, and f= 1301 or determining the order in which transactions are tried to see if they wil= 1302 l be included.<span class=3D"m_4574273483018812099x_x_Apple-converted-space= 1303 ">=C2=A0</span><br> 1304 </div> 1305 <div><br> 1306 </div> 1307 <div>Use a target block size. Determine the target block size using; curren= 1308 t transaction pool size x ( 1 / (144 x n days ) ) =3D number of transaction= 1309 s to be included in the current block. Broadcast the next target block size= 1310 with the current block when 1311 it is solved so that nodes know the next target block size for the block t= 1312 hat they are building on.<br> 1313 </div> 1314 <div><br> 1315 </div> 1316 <div>The curves used for the priority of transactions would have to be appr= 1317 opriate. Perhaps a mathematician with experience in probability can develop= 1318 the right formulae. My thinking is a steep curve. I suppose that the proba= 1319 bility of all transactions 1320 should probably account for a sufficient number of inclusions that the tar= 1321 get block size is met although, it may not always be. As a suggestion, cons= 1322 ider including some zero fee transactions to pad, highest BTC value first?<= 1323 br> 1324 </div> 1325 <div><br> 1326 </div> 1327 <div>**Explanation of the operation of priority:**<br> 1328 </div> 1329 <div>> If transaction priority is, for example, a number between one (lo= 1330 w) and one-hundred (high) it can be directly understood as the percentage c= 1331 hance in one-hundred of a transaction being included in the block. Using pr= 1332 obability or likelihood infers 1333 that there is some function of random. If random (100) < transaction pr= 1334 iority then the transaction is included.<br> 1335 </div> 1336 <div><br> 1337 </div> 1338 <div>>To break it down further, if both the fee on a curve value and the= 1339 time waiting on a curve value are each a number between one and one-hundre= 1340 d, a rudimentary method may be to simply multiply those two numbers, to fin= 1341 d the priority number. For 1342 example, a middle fee transaction waiting thirty days (if n =3D 60 days) m= 1343 ay have a value of five for each part=C2=A0 (yes, just five, the values are= 1344 on a curve). When multiplied that will give a priority value of twenty-fiv= 1345 e, or,=C2=A0 a twenty-five percent chance at 1346 that moment of being included in the block; it will likely be included in = 1347 one of the next four blocks, getting more likely each chance. If it is stil= 1348 l not included then the value of time waiting will be higher, making for mo= 1349 re probability. A very low fee transaction 1350 would have a value for the fee of one. It would not be until near sixty-da= 1351 ys that the particular low fee transaction has a high likelihood of being i= 1352 ncluded in the block.<br> 1353 </div> 1354 <div><br> 1355 </div> 1356 <div>I am not concerned with low (or high) transaction fees, the primary re= 1357 ason for addressing the issue is to ensure transactional reliability and sc= 1358 alability while having each transaction confirm in due time.<br> 1359 </div> 1360 <div><br> 1361 </div> 1362 <div>## Pros:<br> 1363 </div> 1364 <div>* Maximizes transaction reliability.<br> 1365 </div> 1366 <div>* Fully scalable.<br> 1367 </div> 1368 <div>* Maximizes possibility for consumer and business uptake.<br> 1369 </div> 1370 <div>* Maximizes total fees paid per block without reducing reliability; be= 1371 cause of reliability, in time confidence and overall uptake are greater; th= 1372 erefore, more transactions.<br> 1373 </div> 1374 <div>* Market determines fee paid for transaction priority.<br> 1375 </div> 1376 <div>* Fee recommendations work all the way out to 30 days or greater.<br> 1377 </div> 1378 <div>* Provides additional block entropy; greater security since there is l= 1379 ess probability of predicting the next block.<br> 1380 </div> 1381 <div><br> 1382 </div> 1383 <div>## Cons:<br> 1384 </div> 1385 <div>* Could initially lower total transaction fees per block.<br> 1386 </div> 1387 <div>* Must be first be programmed.<br> 1388 </div> 1389 <div><br> 1390 </div> 1391 <div>## Solution operation:<br> 1392 </div> 1393 <div>This is a simplistic view of the operation. The actual operation will = 1394 need to be determined in a spec for the programmer.<br> 1395 </div> 1396 <div><br> 1397 </div> 1398 <div>1. Determine the target block size for the current block.<br> 1399 </div> 1400 <div>2. Assign a transaction priority to each transaction in the pool.<br> 1401 </div> 1402 <div>3. Select transactions to include in the current block using probabili= 1403 ty in transaction priority order until the target block size is met.<br> 1404 </div> 1405 <div>5. Solve block.<br> 1406 </div> 1407 <div>6. Broadcast the next target block size with the current block when it= 1408 is solved.<br> 1409 </div> 1410 <div>7. Block is received.<br> 1411 </div> 1412 <div>8. Block verification process.<br> 1413 </div> 1414 <div>9. Accept/reject block based on verification result.<br> 1415 </div> 1416 <div>10. Repeat.<br> 1417 </div> 1418 <div><br> 1419 </div> 1420 <div>## Closing comments:<br> 1421 </div> 1422 <div>It may be possible to verify blocks conform to the proposal by showing= 1423 that the probability for all transactions included in the block statistica= 1424 lly conforms to a probability distribution curve, *if* the individual trans= 1425 action priority can be 1426 recreated. I am not that deep into the mathematics; however, it may also b= 1427 e possible to use a similar method to do this just based on the fee, that s= 1428 tatistically, the blocks conform to a fee distribution. Any zero fee transa= 1429 ctions would have to be ignored. 1430 This solution needs a clever mathematician.<br> 1431 </div> 1432 <div><br> 1433 </div> 1434 <div>I implore, at the very least, that we use some method that validates f= 1435 ull transaction reliability and enables scalability of block sizes. If not = 1436 this proposal, an alternative.<br> 1437 </div> 1438 <div><br> 1439 </div> 1440 <div>Regards,<br> 1441 </div> 1442 <div>Damian Williamson<br> 1443 </div> 1444 </div> 1445 <div style=3D"margin-top:0px;margin-bottom:0px"><br> 1446 </div> 1447 </div> 1448 </div> 1449 </div> 1450 </div> 1451 </blockquote> 1452 <div><br> 1453 </div> 1454 </div> 1455 </div> 1456 </div> 1457 </div> 1458 </div> 1459 </div> 1460 <span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-= 1461 weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-t= 1462 ransform:none;white-space:normal;word-spacing:0px;float:none;display:inline= 1463 !important">______________________________<wbr>_________________</span><br = 1464 style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-weight= 1465 :normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transfo= 1466 rm:none;white-space:normal;word-spacing:0px"> 1467 <span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-= 1468 weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-t= 1469 ransform:none;white-space:normal;word-spacing:0px;float:none;display:inline= 1470 !important">bitcoin-dev 1471 mailing list</span><br style=3D"font-family:Helvetica;font-size:12px;font-= 1472 style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text= 1473 -indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> 1474 <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" style=3D"font-fami= 1475 ly:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spa= 1476 cing:normal;text-align:start;text-indent:0px;text-transform:none;white-spac= 1477 e:normal;word-spacing:0px" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfo= 1478 undation.org</a><br style=3D"font-family:Helvetica;font-size:12px;font-styl= 1479 e:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-ind= 1480 ent:0px;text-transform:none;white-space:normal;word-spacing:0px"> 1481 <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = 1482 style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-weight= 1483 :normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transfo= 1484 rm:none;white-space:normal;word-spacing:0px" target=3D"_blank">https://list= 1485 s.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a></div> 1486 </blockquote> 1487 </div> 1488 <br> 1489 </div> 1490 </div> 1491 </div> 1492 </div> 1493 </div> 1494 </div> 1495 </div> 1496 </div> 1497 </div> 1498 1499 <br>______________________________<wbr>_________________<br> 1500 bitcoin-dev mailing list<br> 1501 <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= 1502 <wbr>linuxfoundation.org</a><br> 1503 <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = 1504 rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= 1505 /mailman/listinfo/bitcoin-<wbr>dev</a><br> 1506 <br></blockquote></div></div> 1507 1508 --001a11491a40d8868f0560f1b1a4-- 1509