Return-Path: <prayank@tutanota.de> Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3479AC0001 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 14 May 2021 10:05:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 303E740539 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 14 May 2021 10:05:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDfO5W1Kl9I7 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 14 May 2021 10:05:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) by smtp4.osuosl.org (Postfix) with ESMTPS id AA0E340531 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 14 May 2021 10:05:32 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 955BEFA0004; Fri, 14 May 2021 10:05:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1620986723; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=vxZSJ8G5WzzTthFgkQvHUR+w5EZ/zSeigr9U7VmjWRg=; b=V8N635H5fWf003946uCuf/s9eXPwYuBhrfN7ldLYkuOUgEa3Rd97aIdGUSFMnpvt ZjxuFQRvZtHS67fTnvuojWLRNA26UGZUFoPkI5Vt5hmv4kwkqyhgrZQDRuSQ9in0D2l luMPkXaiDvmrLdzKJlEguxM8lJVDUZX03SqlA90lb1qivMY4dX+4Wycc8+OdoNRvm+Q IGOebVStBKFNW56Y3Fj+QEI1ao+iL48yOZr5WgNWNbD8jC+1IidpnpM6a+Y2cBv7N3q I3YKDVWjEAeFvRcJBNC3d/njGLNa0niTbo2mKF8w4E84tmBGDTL49LHR6h6yM+TgYFc 7CYcNmLufg== Date: Fri, 14 May 2021 12:05:23 +0200 (CEST) From: Prayank <prayank@tutanota.de> To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> Message-ID: <M_eKbLz--N-2@tutanota.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_309630_1379337001.1620986724589" X-Mailman-Approved-At: Fri, 14 May 2021 11:14:45 +0000 Subject: Re: [bitcoin-dev] Fee estimates and RBF 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: Fri, 14 May 2021 10:05:34 -0000 ------=_Part_309630_1379337001.1620986724589 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have shared response by Jeremy and ZmnSCPxj in an answer to=C2=A0https://= bitcoin.stackexchange.com/questions/105860/what-are-we-trying-to-predict-in= -fee-estimation-and-why Also find the recent CVE related to RBF by Antoine Riard and implementation= of RBF in Bitcoin Core compared to btcd interesting. Even though I am not = sure why inherited signalling is not implemented in Bitcoin Core. RBF, CPFP and their combinations are something that is less explored IMO. F= or example: I had discussed one usecase of CPFP with Harding in IRC once in= which a project uses maker-taker model. Maker broadcasts transaction with = 1 sat/vByte and taker has to confirm this transaction by creating a child t= ransaction with an effective fee rate according to mempool stats. Basically= , the idea of receiver paying for the transaction instead of sender. But it= will involve lot of exception handling. --=20 Prayank ------=_Part_309630_1379337001.1620986724589 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8= "> </head> <body> <div>I have shared response by Jeremy and ZmnSCPxj in an answer to <a = href=3D"https://bitcoin.stackexchange.com/questions/105860/what-are-we-tryi= ng-to-predict-in-fee-estimation-and-why">https://bitcoin.stackexchange.com/= questions/105860/what-are-we-trying-to-predict-in-fee-estimation-and-why</a= ><br></div><div><br></div><div>Also find the recent CVE related to RBF by A= ntoine Riard and implementation of RBF in Bitcoin Core compared to btcd int= eresting. Even though I am not sure why inherited signalling is not impleme= nted in Bitcoin Core.</div><div><br></div><div>RBF, CPFP and their combinat= ions are something that is less explored IMO. For example: I had discussed = one usecase of CPFP with Harding in IRC once in which a project uses maker-= taker model. Maker broadcasts transaction with 1 sat/vByte and taker has to= confirm this transaction by creating a child transaction with an effective= fee rate according to mempool stats. Basically, the idea of receiver payin= g for the transaction instead of sender. But it will involve lot of excepti= on handling.</div><div><br></div><div>-- <br></div><div>Prayank</div> </bo= dy> </html> ------=_Part_309630_1379337001.1620986724589--