From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D930FC000E for ; Tue, 26 Oct 2021 16:38:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id BAF07608CE for ; Tue, 26 Oct 2021 16:38:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4H8qc5xLOgo for ; Tue, 26 Oct 2021 16:38:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) by smtp3.osuosl.org (Postfix) with ESMTPS id E284A60774 for ; Tue, 26 Oct 2021 16:38:38 +0000 (UTC) Date: Tue, 26 Oct 2021 16:38:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1635266316; bh=B1+ao6L5t2tGYGGNmmwW8HMZHglIHrAKDK9oX1yUQmk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=kpNPdRUDoENTqPcOJ4dUpzLVN4tBxwfrDoTZ53mv8ZjdYZOugu+zyS7nx42mB7AOC e/04CYdkAkH9h0DjFaPD1/F4XccU2myVu2jdyu6TcOF774ZR4r6xgqH+x+O71pQ8BG e+ZD1LRgCwU0+Cx131OxJSct63uC9g1iOKNv9cPU= To: darosior , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <9_2myR-nlP12e_UV4y5HTY8vLzvFirBNZSnNh4kiYP9BTvvHaByALKV1D5kl2BqTyexYYtmVbBZ1xLPYgtbTp-nNsfXEzc1ZlNN8wMGeiVg=@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: lisa neigut 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: Tue, 26 Oct 2021 16:38:39 -0000 Good morning Antoine, > However, as we discussed recently, i do believe their is a failure mode h= ere. On one hand, directly connecting to pools is already possible today an= d pretty effective given the current mining centralization. On the other ha= nd, it's not possible for most pre-signed txs protocols to reliably (secure= ly) use the Bitcoin tx relay network today to propagate time-sensitive tran= sactions. Furthermore, even if these are fixed (eg via package-relay for (t= oday's) Lightning Network) it seems like there is a stark contrast between = what "L2 [0] protocols" need and what regular node operators can reasonably= offer. A node operator is incentivized to relay transactions to: > - have more privacy *if* they use their node to broadcast transactions (m= ake it less distinguishable which relayed transaction comes from the wallet= ) > - provide fee estimates *if* they need them > - avoid bandwidth spikes on block connection (compact block relay) To be clear: it is possible to design L2 protocols such that various counte= rparties (whose incentives may not align perfectly) can bid to put their vi= ews of the L2 state on the blockchain. For instance, in Lightning, you may wish to close a channel at a high feera= te in order to use your onchain funds quickly, yet your channel counterpart= y has no similar time pressure to get their onchain funds in a usable state= . Solutions such as anchor outputs have been devised to allow each counterpar= ty to pay fees as they see fit, however, for instance for anchor outputs th= e commitment transaction has to be at the minimum relay feerate. At times of high blockchain congestion, node operators may raise the minimu= m feerate they are willing to relay (in order to alleviate bandwidth use), = which may prevent commitment transactions from being relayed; even if a CPF= P were relayed later, since the parent transaction is not propagated in the= first place, the CPFP transaction spending the anchor outputs cannot propa= gate too. I believe that is what you are referring to here as an example of how an L2= protocol cannot rely on the current L1 network for timely confirmation? > L2s would ideally need the tx relaying nodes to do more computation and l= ift their DOS mitigations for all miner-incentive-compatible transactions t= o eventually be relayed to most of the miners. One obvious instance of such= a dilemma is the RBF rules. > Such protocols getting increasingly developed and used create a strong in= centive for their users/stakeholders to directly connect to mining pools [1= ], with all the consequences for the network mentioned in the replies to yo= ur mail and elsewhere. > Before we get to this, i think there is a strong case for an opt-in and p= ublicly accessible "overlay" network to relay miner-incentive compatible tr= ansactions with higher DOS limits. This way the cost is not imposed to L1 n= ode runners, and L2s can operate with more safety assumptions without (enti= rely) falling for centralization. Let us imagine how such a network would operate. It seems to me that an issue here is that *relay is free*. And: "you get what you pay for". Since mere relay is free (i.e. nodes do not charge any fee to merely *relay= * transactions) the quality of that relay is low. Thus, L1 node operators may insist on policies that do not support well min= er-incentive transaction packages. So the question is: who should pay for relay? Ultimately of course the transactor pays, but it seems to me that the direc= t payer should be miners; transactors would offer higher fees, and miners w= ould then pay part of those fees to relayers to get those transactions. So, perhaps, let us consider a sketch (which is probably impossible, but ma= y trigger other ideas): Ideally, a relayer system (whether a single node, or some cooperating/compe= ting overlay network of nodes) would gather a bunch of transactions in a pr= oposed package of high-paying transactions. Miners then offer to pay the relayer contingent on learning such a package. The miner wants: * To be given proof, before paying, that the package: * Pays some certain value in fees. * Consist of valid transactions. * To atomically get the actual package once they pay. The relayer wants: * To be paid when it reveals such a package of transaction. Transactors want: * Fees to the relayer to be included as part of the mining fees in their tr= ansaction. The flow would be something like this: * A transactor has a group of transactions it wants confirmed. * It goes to some relayer and feeds the transactions to them. * The relayer figures out the most lucrative package (a task that may be NP= -hard? Knapsack problem equivalent?). * Miners look for relayers who have figured out the most lucrative next pac= kage. * Miners pick the best package and pay for the package. * Miners compete on mining. The issues are: * We need some way to prove that a bunch of transactions are valid, without= showing the actual transactions. * Maybe part of Utreexo or similar concepts can be used? * We need some way to prove that a bunch of transactions pays some fee. * Again, Utreexo? Maybe? Probably not? * Fees =3D inputs - outputs, so the delta between the input UTXO set and = the output UTXO set should be the fee, how do we prove that? * We need some way to actually get the actual transaction data contingent o= n some PTLC or HTLC. Hmm. Thoughts? Regards, ZmnSCPxj