From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B1756C002D for ; Tue, 27 Sep 2022 19:21:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 7D6E74088C for ; Tue, 27 Sep 2022 19:21:38 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7D6E74088C Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=voskuil-org.20210112.gappssmtp.com header.i=@voskuil-org.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=lqi64jdm X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 qR0S1z2FRKRH for ; Tue, 27 Sep 2022 19:21:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 28AAB40425 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by smtp4.osuosl.org (Postfix) with ESMTPS id 28AAB40425 for ; Tue, 27 Sep 2022 19:21:37 +0000 (UTC) Received: by mail-pl1-x636.google.com with SMTP id jm5so9919428plb.13 for ; Tue, 27 Sep 2022 12:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20210112.gappssmtp.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date; bh=KeXG22/0hqjFXPm9pgFGVlK4jbkZVnyBtj/dtPy9hxc=; b=lqi64jdmC7vApznDwVMFgQVX52k2iCcUqH1t2NXhdL7osr+Yxand+5FnBvqUlmjWra MMg2D0Kdj7iC/LUjrqElYFAyTnKZ+flTz5fEqtgEU07ZyZ0nyaa8PYs5NKv0mhUaO00i rpF/M9YgjmfCsCL3lOlkHLStDlKg9ljqCqbja2qj5hYM8eXJx6FQNW9zzoLT1fE6j/xw nBb6mdf/SwpAbmNDToFvCtok0j7OF9RVt7ItpGtnDGJdQZrp5ygI5P2WOytouIiQ4Mlf 3zBbWrJCz7T5qKeaqdDUfhq3ptgH4+YIzMbIAK3kJAVPUs3Ygb/JMZm/4wmu/AMbMJmk Dpxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date; bh=KeXG22/0hqjFXPm9pgFGVlK4jbkZVnyBtj/dtPy9hxc=; b=jiqNZuCRoe7WcrUgOzqV4i0wEc/qutXdlW4U1K86ZEC+xU0R/QltLHpMQkuz9dUOub MJLIjk4t0FcZi7ah1mqENVBWJuMFqtFYmAAgqlLzRX1BftxSvJqjlGrBLrRpPyleN/lZ pDptrISV3j8S05E8I+oZtFfp1hztef7uaP+HY7xFzrv7BInhKxq/lXnpIH6LPefI9tO6 /PV98y8eFSZTh28Rj8vjldDI+Y7dwyNtfG/5w4eZoh9M8v+D9nm6KrNBNV8KxXBJPRZ5 Q8mk9Q8DaBzvcYGShMZ7ok/j8pP9NzdajRsxEcjdvsJafSS6pfBGz8tHEZGrkc/KxNiH 4mmQ== X-Gm-Message-State: ACrzQf1yiidGfepNRn1Q2MaJCjbOBLKR/619R+1bMHVvJMs7HXdSXTSV WsI0H/FjPy+daeWb8bGc2kdj0xfjgUmHZw== X-Google-Smtp-Source: AMsMyM4d+rde+HcIqNsK3QvXYmONWLLYErf8/nA0xSOZDCQKZoSpsxIj/4Q48E30XPDGlQPN/Mlciw== X-Received: by 2002:a17:903:228c:b0:178:3bc7:8a3f with SMTP id b12-20020a170903228c00b001783bc78a3fmr28288851plh.88.1664306496447; Tue, 27 Sep 2022 12:21:36 -0700 (PDT) Received: from smtpclient.apple ([50.35.67.197]) by smtp.gmail.com with ESMTPSA id 30-20020a63155e000000b0043c268a8911sm1915470pgv.4.2022.09.27.12.21.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Sep 2022 12:21:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Tue, 27 Sep 2022 12:21:35 -0700 Message-Id: References: In-Reply-To: To: alicexbt X-Mailer: iPhone Mail (19G82) Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Packaged Transaction Relay 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, 27 Sep 2022 19:21:38 -0000 Thanks again for the feedback. Comments inline. > On Sep 27, 2022, at 02:29, alicexbt wrote: >=20 > =EF=BB=BFHi Eric, >=20 >=20 >> If by "range" you mean a connected tx subgraph, I don't see why not. But n= ote that nodes only operate over signed txs. PSBT is a wallet workflow. >=20 > Matt Corallo mentioned that pre-signed transactions created with low fee r= ate become an issue when they are broadcasted after a long time and there is= a high demand for block space at that moment. Yes, I understood this. There are many ways that a fee may be created which i= s too low for propagation. > Example:=20 >=20 > Bob created PSBT1 in a multi party contract with fee rate 5 sat/vbyte howe= ver its taking hours/days to confirm the transaction with such low fee rate.= >=20 > Carol created PSBT1 (5 sat/vbyte), PSBT2 (10 sat/vbyte) and PSBT3 (20 sat/= vbyte) for spending same inputs. She broadcasted PSBT3 which got confirmed i= n a few minutes.=20 >=20 >=20 >> Always. Only signed transactions are accepted. But assuming you are refer= ring to a transaction that has been produced by a pre-signing workflow, I'm n= ot sure how this would be distinct from any other tx. >=20 >=20 > `minfeefilter` for all peers of my node was 0.00001000 at the time of writ= ing this email. I am assuming nobody creates pre-signed transaction with fee= rate below 1 sat/vbyte. How often does it happen that `minfeefilter` is abo= ve this default value? I don=E2=80=99t consider node configuration relevant, regardless of its appa= rent consistency. >> I'm not sure I follow this, maybe you could reword it. But it seems that y= ou are saying that CPFP fee-bumping is a problem scenario and the complexity= of the proposed solutions are not justified by such scenarios. >=20 >=20 > Sorry that sentence was confusing. Yes complexity isn't justified for CPFP= fee-bumping txs below minimum fee rate. >=20 >=20 >> There are many node implementations used presently. And of course these a= re protocol proposals, which presumes more than one implementation. >=20 >=20 > Yes, a few implementations exist (knots, libbitcoin, btcd, bcoin etc.) how= ever they aren't used by lot of nodes. Based on this [chart][1] 98% nodes us= e bitcoin core. Lot of bitcoin protocol proposals are influenced by bitcoin c= ore contributors and things could be different if even 30% nodes used other i= mplementations. I don=E2=80=99t consider such a measure relevant. This is a protocol conside= ration. Also consider that many nodes are not visible, and aspects of nodes,= such as for p2p communication, are embedded into applications such as walle= ts - which could easily exceed the number of visible nodes. >> I don't consider this relevant to any protocol considerations. Miners sho= uld always be expected to select the most optimal set of txs available in th= e time available to do so. >=20 >=20 > Agree, miners should be expected to select most optimal set of txs. Howeve= r, according to one [comment][2] by Pieter Wuille, miners could affect the s= ecurity of some bitcoin projects with MEV. This would be a deficiency in such projects, by assuming economic irrational= ity. The fact that fees will become a greater percentage of the block reward= is a surprise to no one. >> Over time we are likely to see that the only policies that remain in wide= spread application are those that are necessary for DOS protection (fee rate= ), as other restrictions are not economically rational and cannot be enforce= d. We've seen recent debate regarding dust policy, and op_return policy. "no= n-standard" txs are perfectly valid but get stuck very easily. I'll reiterat= e, any policy beyond what is published via the protocol will cause the above= problems. >=20 > I completely agree with this. >=20 >=20 > [1]: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html > [2]: https://bitcoin.stackexchange.com/questions/107787/front-running-in-b= itcoin#comment123441_107796 >=20 >=20 > /dev/fd0