Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 38445C002D for ; Thu, 26 May 2022 02:59:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 13836613F7 for ; Thu, 26 May 2022 02:59:05 +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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmXhMey7SUEt for ; Thu, 26 May 2022 02:59:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by smtp3.osuosl.org (Postfix) with ESMTPS id DCEFC613E4 for ; Thu, 26 May 2022 02:59:03 +0000 (UTC) Received: by mail-pl1-x629.google.com with SMTP id a13so361502plh.6 for ; Wed, 25 May 2022 19:59:03 -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:thread-index:content-language; bh=ViYF9hs1Eos0tSo+47BqLjslQfazXNG8lI3jBnmPlUI=; b=KKtvcrBMnWfEgL2WUS5pWXf5tphPTrPTrM+gxx9rfsmKCTAG5X8kNw76+pc76FseyF 7rcrEc6Bv7dTwyiRXTZemKLO9hJkUrAFcIKDQ1kkr6wkiR71eSScwkqSqWO6tsh7dYg6 6YrxWicF+gzO38qrOxj5sISyVlgO3i6auDNkT2hluzzAl2uLzUXXRJTVMNem5DFc/98D b5lmYQNMAY3iOaii1LaiNmqQzsI/Ss/hbNvBu9P2CB2+h//pI8chdvyXWsXNxKGrEEND KnmiqGSSzbmzDTDr5MjDPZxU4zuj7H9Ej6s6FtS7wxlaL8m4mKpNRyfapuhWavpc4cTA DWqQ== 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:thread-index :content-language; bh=ViYF9hs1Eos0tSo+47BqLjslQfazXNG8lI3jBnmPlUI=; b=pp9tUm9NfJ4yNKRAyJ/5uI3uGHomDbpDQnQfS+N7ltP9nOD2cVVrTpATdyjl4nNGtY t+0HRtzHBBYVw+8mV5JR4j9sgrnwaLL3JTXtKDuuS8cIlmdu/qo5OV8Q65sMgGDAsKt7 Ir/2vLCTchai5S1wf9DtAeTwkreJuPBY+dKawqYkduVzFx4q5AdMQOyJEhEkK5Wq9tZ1 3lcDCe7DV8bd7eVeX07Vsj9Jd2qs6oT5awYqcqV28viav/QOBTy4op050TdZzTQZOXSR qUaaWynXNRcI4n9jQKVRCopNOhHaxcbqc1+MGBlqN697/ckXRRGdmN16XeCDuX7atVzm u7hw== X-Gm-Message-State: AOAM531SGjZb2Kmn39D//QDlpAfBn9ouu4LwPOb4a1my4FHhJHCB5t43 U2cPCNPVQO46aB+SWUQqUvamCA== X-Google-Smtp-Source: ABdhPJwsGn2Qt1s2eNm9QjBVVIVIU1ka9uAi+9shYTlc/LnBasv8F2+K7t/lNUfZ9dZCDXfbwK8/dg== X-Received: by 2002:a17:903:1cd:b0:163:6697:e6e with SMTP id e13-20020a17090301cd00b0016366970e6emr4204989plh.21.1653533943217; Wed, 25 May 2022 19:59:03 -0700 (PDT) Received: from ERICDESKTOP ([50.35.67.197]) by smtp.gmail.com with ESMTPSA id d26-20020aa797ba000000b0050dc762816csm136674pfq.70.2022.05.25.19.59.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 May 2022 19:59:01 -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> <017501d87079$4c08f9c0$e41aed40$@voskuil.org> In-Reply-To: <017501d87079$4c08f9c0$e41aed40$@voskuil.org> Date: Wed, 25 May 2022 19:59:01 -0700 Message-ID: <001201d870ac$8d7a06a0$a86e13e0$@voskuil.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIovTqWCntex56Gpr5DNDTNBglPqgKABWBKAZhodHoBKe+mXgGXgGG4Af/QDV4BmL8ksgJ05ADzAbE0K02sGxW7UA== Content-Language: en-us 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: Thu, 26 May 2022 02:59:05 -0000 Given that packages have no header, the package requires identity in a BIP152 scheme. For example 'header' and 'blockhash' fields can be replaced with a Merkle root (e.g. "identity" field) for the package, uniquely identifying the partially-ordered set of txs. And use of 'getdata' (to obtain a package by hash) can be eliminated (not a use case). e > -----Original Message----- > From: eric@voskuil.org > Sent: Wednesday, May 25, 2022 1:52 PM > To: 'Anthony Towns' ; 'Bitcoin Protocol Discussion' > ; 'Gloria Zhao' > > Subject: RE: [bitcoin-dev] Package Relay Proposal > > > 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