Return-Path: <willtech@live.com.au> Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 414F9C000E for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 27 Oct 2021 08:44:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 23D4180D0F for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 27 Oct 2021 08:44:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zhOYdH8KKQy for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 27 Oct 2021 08:44:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from KOR01-SL2-obe.outbound.protection.outlook.com (mail-sl2kor01olkn0163.outbound.protection.outlook.com [104.47.108.163]) by smtp1.osuosl.org (Postfix) with ESMTPS id D4F4080CF8 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 27 Oct 2021 08:44:46 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ICxm9epQlw6UcqojG8oQ6YAXB8hkhJuAuHQ6V+zGv5BIOmZuuJYRKskrlDxZ3EyBlG7FkpbhWQMTzYt2V8Hndz2xB0BxfjtihgQgsZ9nNmqw4K8SHSMc1eT4QTcfKuJFWaRivKoITiyqQCDxAL2TmYR2Ff1lwkKiAvodYD2RfppXyuX2uuX8AUIL7Qfy45Kc4xcf1+HebJxLxixfj1MwBZ1lRud0iXgWivD0yD0CDdgNczjvankrzO0YaG/xCOO2ieKaDFPAC6Q3Etow+UXFaPWyV34eVlklMOnQLQ8Q/+EzDMXCoyWKt8izkfQJn75eR4BiDntplqcBFGhaiDzh2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gdlcDVPHXia/UfqiVz6rcevqaRqU4vfhF4aBk8dlLQY=; b=mYcIYClerqB1/8/1yFeVXa993Iggu4o579sPPv3jxVDfkWAQpzJn3Vg6YSESzbyoNpzVWKx6QNbJV7T6NxAwqUsM9HpT+zzco6J2m6FSkq5KqBOlBSoeCVkpXiO1ggd+HxBqI0At5Bq+UHLWNLS7anoSaepayK+nHv6P0G35sBRoxXNZTuiWp3C1nVXyu5ImbzcxCUuNVVwGAWkfC6JKpel1ZGyYBdnfGFcQEFoLr7br7fYdip73NiGHew06vfPA6JIY+gatdfcIXkADEs49Yw2Vc6gejKN/uc5PyWWb6sk1pUlckqeN0j3QXFkzcmaTAC1mROuI2GXfmrpJhkJ+eg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from PS2P216MB1089.KORP216.PROD.OUTLOOK.COM (2603:1096:301:52::11) by PU4P216MB1370.KORP216.PROD.OUTLOOK.COM (2603:1096:301:a2::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.14; Wed, 27 Oct 2021 08:44:42 +0000 Received: from PS2P216MB1089.KORP216.PROD.OUTLOOK.COM ([fe80::4c6c:a1dc:c8c0:fed2]) by PS2P216MB1089.KORP216.PROD.OUTLOOK.COM ([fe80::4c6c:a1dc:c8c0:fed2%3]) with mapi id 15.20.4649.014; Wed, 27 Oct 2021 08:44:42 +0000 From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au> To: "bitcoin-dev@lists.linuxfoundation.org" <bitcoin-dev@lists.linuxfoundation.org>, lisa neigut <niftynei@gmail.com> Thread-Topic: [bitcoin-dev] death to the mempool, long live the mempool Thread-Index: AQHXyjxhpu8HKywNhEGV4U0LSP0Vl6vmiFrX Date: Wed, 27 Oct 2021 08:44:42 +0000 Message-ID: <PS2P216MB1089038AABE45CE8FF36E32F9D859@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM> References: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com> In-Reply-To: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: c2c5f273-1199-66da-c4d9-333ab4ac67fd x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [WdnSLaLNV7adFgu3HE+eRQnbObqMeSaa] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f3f1743-e768-4ea3-1248-08d999260551 x-ms-traffictypediagnostic: PU4P216MB1370: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fdmJkLduRR2b9FA9M788JXALVeciQJObJur8Qpuhn672HV0LsnCA+GehuPS3HjI4zbU+e9yUGptN7W/X9+Dggm3LlSMVJCrTNrMJPuZAR/cwb4mEFKkECdZ7xQcuZFlzbhlE9/2jqBEET9QSmZFD2u/kk7ujZII232p3VbiuHoHLxw19qfSj6wtVsK9FfyrGayF3Ia8laqzlQO+9SXOmcv636fwhOHD+yZxi/m2cV8GbbIKltB4fdmp+B8OmPE/nupuN5vSHNqLAxOtHDDOgCLwxD196CZsCQdiuCYGxTG1LBMT0EMojhvHAJP5Yc5W2rg8xCyUkMzAJYlICjyi2KWnJFTbsHyRYk2FV3zkuw2qoXUdRG7VES6yNW+FUwK67fHjHvt0p22HgG+3EycYZTY574BzWHfPkoCeXocZzu0g8v5taayAko/0ECBf4EHsG2Is6ql4K26Y5rCEFOFnZl6OCGp38jSq5MdOX78e68hHQMF2VSLx4b7eXaKjvrGk2r5hOD5TX41bDhQza+uLF8ibM1oU8Cq7nKjHJ9/UJf6n6TWZb/9+COxF7ERq9zNNW3VXDqUFS68FhOegqgnk79w== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: WAxXNMvr7asfNGxtO6OdHOu6UaU5zuDiCQ5nutnGnJsQO81hAVWrbJW5V2l7S0iKk6XsOF/P48RQLsfpQcocwowvRCwlL3FLFCsfTSpVo7G6ep1kDVZ+G5uiQ5rrULUTqzhk4bBcyI+5yvWoLe1SmmWa1IYOaPzrkVuZJ+OBNJmsjhMo5QZ3tcQNENeust5+nBTEzGEZuJUBA3Ojaz8PW5TDsj/h70FAEa3R75BiNZNUFDg2H/EOt19qVL87N6Xv8WkBzJAl1k82La6P7zq8h+lF1Dqio7FgSGsO/4qSTj++x+QVMrEQVfLdK3KvlPydEXqpq1sCpqxw1IBsS71InTJLr6LXo2LK9FXOsD+J27TmbDZ+BobtGsmT6I9O76Q11MjjQLxsYcReyF0rtqx29j6OWEiSpPWLSF1yWtPuQrWlK9twGSZlLZLKLUpN/bz0L+rcbb28PN19LEHmQyoH0FLrKcoraysiCrRfXmGBVGMm3JnDSnR3gxhCnwgFtwhN0EzyoAWd26b4HxPKTRdZd0SibHhbPh+P1fw6pT+AvECehGG8cdZAxPVdiaOcN2afeMiGdRZJT0qDkeAb2r4+mh/xhxLXVLRoNxDcILClHXvsC80mbdALh0+gkcCtjNYqUfKCe+SqAAQ+B3rtwRHMFrw2w+I8byqLUdevVOJ3nQhRgevHfvtBbKlhjzR8bqhPmlhcdbl8gTqLpBwSpKvFkA== Content-Type: multipart/alternative; boundary="_000_PS2P216MB1089038AABE45CE8FF36E32F9D859PS2P216MB1089KORP_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-af45a.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PS2P216MB1089.KORP216.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 6f3f1743-e768-4ea3-1248-08d999260551 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2021 08:44:42.5865 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU4P216MB1370 X-Mailman-Approved-At: Wed, 27 Oct 2021 16:52:43 +0000 Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Wed, 27 Oct 2021 08:44:49 -0000 --_000_PS2P216MB1089038AABE45CE8FF36E32F9D859PS2P216MB1089KORP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good Afternoon, No. This has been discussed previously and eliminated as there is no proof = that the transaction can exist without population through the mempool. As a= method of payment not hearing about a transaction until it is possibly min= ed three months later as I have experienced is non-functional, there were d= iscussions in this mailing list. The purpose of the mempool is not gossip i= t is gossip and any node technically can mine if they do. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this emai= l if misdelivered. ________________________________ From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf= of lisa neigut via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> Sent: Tuesday, 26 October 2021 1:56 PM To: bitcoin-dev@lists.linuxfoundation.org <bitcoin-dev@lists.linuxfoundatio= n.org> Subject: [bitcoin-dev] death to the mempool, long live the mempool Hi all, In a recent conversation with @glozow, I had the realization that the mempo= ol is obsolete and should be eliminated. Instead, users should submit their transactions directly to mining pools, p= referably over an anonymous communication network such as tor. This can eas= ily be achieved by mining pools running a tor onion node for this express p= urpose (or via a lightning network extension etc) Mempools make sense in a world where mining is done by a large number of pa= rticipating nodes, eg where the block template is constructed by a majority= of the participants on the network. In this case, it is necessary to socia= lize pending transaction data to all participants, as you don=92t know whic= h participant will be constructing the winning block template. In reality however, mempool relay is unnecessary where the majority of hash= power and thus block template creation is concentrated in a semi-restricted= set. Removing the mempool would greatly reduce the bandwidth requirement for run= ning a node, keep intentionality of transactions private until confirmed/ir= revocable, and naturally resolve all current issues inherent in package rel= ay and rbf rules. It also resolves the recent minimum relay questions, as r= elay is no longer a concern for unmined transactions. Provided the number of block template producing actors remains beneath, say= 1000, it=92d be quite feasible to publish a list of tor endpoints that nod= es can independently + directly submit their transactions to. In fact, mer= ely allowing users to select their own list of endpoints to use alternative= ly to the mempool would be a low effort starting point for the eventual rep= lacement. On the other hand, removing the mempool would greatly complicate solo minin= g and would also make BetterHash proposals, which move the block template c= onstruction away from a centralized mining pool back to the individual mine= r, much more difficult. It also makes explicit the target for DoS attacks. A direct communication channel between block template construction venues a= nd transaction proposers also provides a venue for direct feedback wrt acce= ptable feerates at the time, which both makes transaction confirmation time= lines less variable as well as provides block producers a mechanism for (in= dependently) enforcing their own minimum security budget. In other words, e= xpressing a minimum acceptable feerate for continued operation. Initial feerate estimation would need to be based on published blocks, not = pending transactions (as this information would no longer be available), or= from direct interactions with block producers. ~niftynei --_000_PS2P216MB1089038AABE45CE8FF36E32F9D859PS2P216MB1089KORP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> Good Afternoon,</div> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> <br> </div> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> No. This has been discussed previously and eliminated as there is no proof = that the transaction can exist without population through the mempool. As a= method of payment not hearing about a transaction until it is possibly min= ed three months later as I have experienced is non-functional, there were discussions in this mailing list= . The purpose of the mempool is not gossip it is gossip and any node techni= cally can mine if they do.</div> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> <br> </div> <div> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> </div> <div id=3D"Signature"> <div> <div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col= or:rgb(0,0,0)"> <div>KING JAMES HRMH <div>Great British Empire</div> <div><br> </div> <div>Regards,</div> <div>The Australian</div> <div>LORD HIS EXCELLENCY JAMES HRMH (& HMRH)</div> <div>of Hougun Manor & Glencoe & British Empire</div> <div>MR. Damian A. James Williamson</div> <div>Wills</div> <div><br> </div> <div>et al.</div> <div><br> </div> <div> </div> <div>Willtech</div> <div>www.willtech.com.au</div> <div>www.go-overt.com</div> <div>duigco.org DUIGCO API</div> <div>and other projects</div> <div> </div> <div><br> </div> <div>m. 0487135719</div> <div>f. +61261470192</div> <div><br> </div> <div><br> </div> This email does not constitute a general advice. Please disregard this emai= l if misdelivered.<br> </div> </div> </div> </div> </div> <div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face= =3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> bitcoin-dev <bit= coin-dev-bounces@lists.linuxfoundation.org> on behalf of lisa neigut via= bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org><br> <b>Sent:</b> Tuesday, 26 October 2021 1:56 PM<br> <b>To:</b> bitcoin-dev@lists.linuxfoundation.org <bitcoin-dev@lists.linu= xfoundation.org><br> <b>Subject:</b> [bitcoin-dev] death to the mempool, long live the mempool</= font> <div> </div> </div> <div> <div> <div dir=3D"auto">Hi all,</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">In a recent conversation with @glozow, I had the realizat= ion that the mempool is obsolete and should be eliminated.</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">Instead, users should submit their transactions directly = to mining pools, preferably over an anonymous communication network such as= tor. This can easily be achieved by mining pools running a tor onion node = for this express purpose (or via a lightning network extension etc)</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">Mempools make sense in a world where mining is done by a = large number of participating nodes, eg where the block template is constru= cted by a majority of the participants on the network. In this case, it is = necessary to socialize pending transaction data to all participants, as you don=92t know which participant will be co= nstructing the winning block template.</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">In reality however, mempool relay is unnecessary where th= e majority of hashpower and thus block template creation is concentrated in= a semi-restricted set. </div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">Removing the mempool would greatly reduce the bandwidth r= equirement for running a node, keep intentionality of transactions private = until confirmed/irrevocable, and naturally resolve all current issues inher= ent in package relay and rbf rules. It also resolves the recent minimum relay questions, as relay is no longer= a concern for unmined transactions.</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">Provided the number of block template producing actors re= mains beneath, say 1000, it=92d be quite feasible to publish a list of tor = endpoints that nodes can independently + directly submit their transa= ctions to. In fact, merely allowing users to select their own list of endpoints to use alternatively to the mempool = would be a low effort starting point for the eventual replacement.</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">On the other hand, removing the mempool would greatly com= plicate solo mining and would also make BetterHash proposals, which move th= e block template construction away from a centralized mining pool back to t= he individual miner, much more difficult. It also makes explicit the target for DoS attacks.</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">A direct communication channel between block template con= struction venues and transaction proposers also provides a venue for direct= feedback wrt acceptable feerates at the time, which both makes transaction= confirmation timelines less variable as well as provides block producers a mechanism for (independently) enforc= ing their own minimum security budget. In other words, expressing a minimum= acceptable feerate for continued operation.</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">Initial feerate estimation would need to be based on publ= ished blocks, not pending transactions (as this information would no longer= be available), or from direct interactions with block producers.</div> <div dir=3D"auto"><br> </div> <div dir=3D"auto"><br> </div> <div dir=3D"auto">~niftynei</div> </div> </div> </div> </body> </html> --_000_PS2P216MB1089038AABE45CE8FF36E32F9D859PS2P216MB1089KORP_--