Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id CD492C002D for ; Thu, 16 Jun 2022 12:47:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id AEAC48149E for ; Thu, 16 Jun 2022 12:47:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com 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 ZyLkSptJLUiQ for ; Thu, 16 Jun 2022 12:47:23 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) by smtp1.osuosl.org (Postfix) with ESMTPS id A7D8981494 for ; Thu, 16 Jun 2022 12:47:23 +0000 (UTC) Date: Thu, 16 Jun 2022 12:47:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1655383641; x=1655642841; bh=ux5XPmomy2wpUhNpg0vyBZ+l6N3gwb1rdVIBDoT8sZ4=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=HDWDwPgfibsfGIrjbJNmv4SN3zytF3EKUE9iISVl6qAUteg7phu54qsHFpGrgKetx gS2+pwfrS8nfCoijfYDD4N/ixg4M5azECFhpshe8uKmIgQBF6aKoy7YsN5kD4DRmrI TPc9eglSmlPRN1npFjL+WkzrEgKq6U/r/kf8zBSGgYjdQIHbM98gTqrHaJYgKZ5wMz Yoz3sTP+7D6AgmuHjjMbzAePjrWfZj4DHH/0H3mm7f8qQVrC2gWAsiEur9upWFtMqq zh+6Fclgteky+S23QXIF9XBAfpf8HpfWob5w8pQgMBl6KbALdVd9d4GeNReNLuseWU NdhZXMLWgVXdg== To: linuxfoundation.cndm1@dralias.com From: alicexbt Reply-To: alicexbt Message-ID: In-Reply-To: <165535822613.7.2651335771202625212.47284609@dralias.com> References: <7aP7ve-x6uMLSY2a9ZvpkyEc7uOdWmCGOs-S2ly1klRKzm5kVT4zjC9i0V6k1R0Cr9Xloq6Z4zmZ0LfquOxFtyhrA0RgsfG4qq760T4dfZM=@protonmail.com> <165535822613.7.2651335771202625212.47284609@dralias.com> Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 16 Jun 2022 13:11:21 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security 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: Thu, 16 Jun 2022 12:47:24 -0000 Hi cndm1, > If you see a "lack of basic options" and no one has opened a pull request= for it, it may be for two reasons. The basic option to disable all RBF policies in a node's mempool if require= d was removed in [PR #16171][1]. No one has opened a pull request to revert= this because most of the maintainers and a few reviewers agreed with this = change. It wasn't required, PR had weak rationale, 2 NACKS and was reopened= to merge because some reviewers/maintainers believe its a policy that cann= ot be maintained. One of the reviewers who NACKed it already maintains the = config option to disable all RBF policies in Bitcoin Knots which is a deriv= ative of Bitcoin Core. > However, repeatedly demanding others to do it for you is not helpful in o= pen source software development. I am not demanding anyone to add a few lines of code and open a pull reques= t. I am _reviewing_ a pull request in an open source project and sharing my= feedback. Even Antoine and Luke agreed to add it if other reviewers have n= o issues or I can do it. This option in context with another being added fo= r a new RBF policy was being discussed in [PR #25353][2] and my earlier ema= ils in this thread. Other 'basic options' will be easier to accommodate with `-mempoolreplaceme= nt` used in [PR #25373] which is unlikely to be merged. [1]: https://github.com/bitcoin/bitcoin/pull/16171 [2]: https://github.com/bitcoin/bitcoin/pull/25353 [3]: https://github.com/bitcoin/bitcoin/pull/25373 /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Thursday, June 16th, 2022 at 11:13 AM, linuxfoundation.cndm1--- via bitc= oin-dev bitcoin-dev@lists.linuxfoundation.org wrote: > alicexbt wrote: > > > I do not have issues with multiple RBF policies being tried out and ful= l-rbf being one of them. My disagreements are with rationale, lack of basic= options in Bitcoin Core to employ/disable different RBF policies and a few= arguments made in support for full-rbf. Whether it appears strawman or off= topic on github, there should be a place to share these disagreements. > > Bitcoin Core is open source software, where developers open pull > requests to try to get them merged after review. If you see a "lack of > basic options" and no one has opened a pull request for it, it may be > for two reasons. First, it could be that it just doesn't make sense, > so no one sees a point in implementing it. Secondly, it may be that it > isn't on anyone's list of priorities. In the second case, you are > welcome to share your preference once. Moreover, no one is holding you > back to implement it yourself and suggest a pull request. However, > repeatedly demanding others to do it for you is not helpful in open > source software development. > > cndm1 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev