From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 414F9C000E for ; 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 ; 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 ; 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 ; 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 To: "bitcoin-dev@lists.linuxfoundation.org" , lisa neigut 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: References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 on behalf= of lisa neigut via bitcoin-dev Sent: Tuesday, 26 October 2021 1:56 PM To: bitcoin-dev@lists.linuxfoundation.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
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 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.

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 <bit= coin-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.linu= xfoundation.org>
Subject: [bitcoin-dev] death to the mempool, long live the mempool
 
Hi all,

In a recent conversation with @glozow, I had the realizat= ion that the mempool is obsolete and should be eliminated.

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)

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.

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. 

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.

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.

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.

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.

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.


~niftynei
--_000_PS2P216MB1089038AABE45CE8FF36E32F9D859PS2P216MB1089KORP_--