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 C962EC002D for ; Wed, 25 May 2022 20:52:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B1DC0410BD for ; Wed, 25 May 2022 20:52:12 +0000 (UTC) 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 Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com 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 FLgWKRdU10zA for ; Wed, 25 May 2022 20:52:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by smtp4.osuosl.org (Postfix) with ESMTPS id CF46940761 for ; Wed, 25 May 2022 20:52:08 +0000 (UTC) Received: by mail-pf1-x42f.google.com with SMTP id j6so20225688pfe.13 for ; Wed, 25 May 2022 13:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20210112.gappssmtp.com; s=20210112; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=PNZQ9+Ai2bh346c27Byk4TEhOPos7BrszswLDpxsvXg=; b=VqmWKOFbSqywTRnSLGdA752ZwqGONnKoWtPzmOPlipImb+fkGTaVNc/ddyAi2UtzbB qp4uJfCN33GtPCi3XAZ/CBg/7HMaJrH6VAEK4BWNGxlrI7YrI+/dJUZw70ZhpRvDtkoa acGXMae8sIoLYFqKDSjs50KNOzFEDFZ9UM+CSujZ0IQMX1ISTF70LoNUbXHn6vd5/WJD EnPGIPPRGYdPJsUA89JwG2eTSA9VpGz/8Lf0qcLCURQlGUHhDa0N7LUQIbCC1m6dSaJh xfQHXyhk/ueBnsDynK+H3Ecmk+REr6gIrVhtlGMmdOxf+NfTHP1wnQYxuQSNiXqld1Y0 IA9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=PNZQ9+Ai2bh346c27Byk4TEhOPos7BrszswLDpxsvXg=; b=oK9Hi5fsDUVV8PcUUCsIxNB6rvaOBAtl+A/PuLsv/em0ihwf0N6QH6dk+7xJvuHvOK VzUqje58eabhXx3SzenD8Vv94+hAeHMHflCRZfHy3KNXHxBNGi6KPZ+YIXrTcjUfIQAA ijD5VcVybh7aKGIhADgA9aM4ibEF61jq9SdACmcKtNjDl/NVI5d1M7RAqpqn48/4iBxE m+UP4UIUDT34Y8Gobg6UDtMZHbtatY1QDbZ/AP/3hqy+/pU0Zn/xyjmPskag3+j1VRi+ MLynDRgtkai94Fw9n5gXaxscYy/gqB9T6scWTYu0hGugqgiZpu2RRyfwLNn2Xe744Zlj WQ0A== X-Gm-Message-State: AOAM530GTJcUsyQTTN/KXfiiHkBpAEB9BSrFHlijsjVgBQlNGu8/e7uZ yKos6GYSHa7CcKu/HT8nYLYnig== X-Google-Smtp-Source: ABdhPJwyC7luDrtnajXW1V1XE1ldVQDIneb4V2QUJvLnq7/hwQGaLAAaT/LzmThno6Q447neMb3R0g== X-Received: by 2002:a63:6987:0:b0:3db:1c36:13aa with SMTP id e129-20020a636987000000b003db1c3613aamr30365034pgc.119.1653511928127; Wed, 25 May 2022 13:52:08 -0700 (PDT) Received: from ERICDESKTOP ([50.35.67.197]) by smtp.gmail.com with ESMTPSA id m10-20020a637d4a000000b003c14af505fcsm8778605pgn.20.2022.05.25.13.52.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 May 2022 13:52:07 -0700 (PDT) From: To: "'Anthony Towns'" , "'Bitcoin Protocol Discussion'" , "'Gloria Zhao'" References: <20220518003531.GA4402@erisian.com.au> <20220523213416.GA6151@erisian.com.au> <2B3D1901-901C-4000-A2B9-F6857FCE2847@erisian.com.au> <8FFE048D-854F-4D34-85DA-CE523C16EEB0@erisian.com.au> In-Reply-To: <8FFE048D-854F-4D34-85DA-CE523C16EEB0@erisian.com.au> Date: Wed, 25 May 2022 13:52:07 -0700 Message-ID: <017501d87079$4c08f9c0$e41aed40$@voskuil.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIovTqWCntex56Gpr5DNDTNBglPqgKABWBKAZhodHoBKe+mXgGXgGG4Af/QDV4BmL8ksgJ05ADzrCgkFgA= Subject: Re: [bitcoin-dev] Package Relay Proposal 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: Wed, 25 May 2022 20:52:12 -0000 > From: bitcoin-dev On Behalf > Of Anthony Towns via bitcoin-dev > Sent: Wednesday, May 25, 2022 11:56 AM > So the other thing is what happens if the peer announcing packages to us is > dishonest? > > They announce pkg X, say X has parents A B C and the fee rate is garbage. But > actually X has parent D and the fee rate is excellent. Do we request the > package from another peer, or every peer, to double check? Otherwise we're > allowing the first peer we ask about a package to censor that tx from us? > > I think the fix for that is just to provide the fee and weight when announcing > the package rather than only being asked for its info? Then if one peer makes > it sound like a good deal you ask for the parent txids from them, dedupe, > request, and verify they were honest about the parents. Single tx broadcasts do not carry an advertised fee rate, however the' feefilter' message (BIP133) provides this distinction. This should be interpreted as applicable to packages. Given this message there is no reason to send a (potentially bogus) fee rate with every package. It can only be validated by obtaining the full set of txs, and the only recourse is dropping (etc.) the peer, as is the case with single txs. Relying on the existing message is simpler, more consistent, and more efficient. > >> Is it plausible to add the graph in? > > Likewise, I think you'd have to have the graph info from many nodes if you're > going to make decisions based on it and don't want hostile peers to be able to > trick you into ignoring txs. > > Other idea: what if you encode the parent txs as a short hash of the wtxid > (something like bip152 short ids? perhaps seeded per peer so collisions will > be different per peer?) and include that in the inv announcement? Would > that work to avoid a round trip almost all of the time, while still giving you > enough info to save bw by deduping parents? As I suggested earlier, a package is fundamentally a compact block (or block) announcement without the header. Compact block (BIP152) announcement is already well-defined and widely implemented. A node should never be required to retain an orphan, and BIP152 ensures this is not required. Once a validated set of txs within the package has been obtained with sufficient fee, a fee-optimal node would accept the largest subgraph of the package that conforms to fee constraints and drop any peer that provides a package for which the full graph does not. Let us not reinvent the wheel and/or introduce accidental complexity. I see no reason why packaging is not simply BIP152 without the 'header' field, an updated protocol version, and the following sort of changes to names: sendpkg MSG_CMPCT_PKG cmpctpkg getpkgtxn pkgtxn > > For a maximum 25 transactions, > >23*24/2 = 276, seems like 36 bytes for a child-with-parents package. > > If you're doing short ids that's maybe 25*4B=100B already, then the above is > up to 36% overhead, I guess. Might be worth thinking more about, but maybe > more interesting with ancestors than just parents. > > >Also side note, since there are no size/count params, Size is restricted in the same manner as block and transaction broadcasts, by consensus. If the fee rate is sufficient there would be no reason to preclude any valid size up to what can be mined in one block (packaging across blocks is not economically rational under the assumption that one miner cannot expect to mine multiple blocks in a row). Count is incorporated into BIP152 as 'shortids_length'. > > wondering if we > >should just have "version" in "sendpackages" be a bit field instead of > >sending a message for each version. 32 versions should be enough right? Adding versioning to individual protocols is just a reflection of the insufficiency of the initial protocol versioning design, and that of the various ad-hoc changes to it (including yet another approach in this proposal) that have been introduced to compensate for it, though I'll address this in an independent post at some point. Best, e > Maybe but a couple of messages per connection doesn't really seem worth > arguing about? > > Cheers, > aj > > > -- > Sent from my phone. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev