Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3479AC0001 for ; 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 ; 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 ; 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 ; 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 To: Bitcoin Dev Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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



------=_Part_309630_1379337001.1620986724589--