path: root/27/eb1a36f55b7490ccf41b455c75d08d969ad910

Return-Path: <eric@voskuil.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 38445C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 May 2022 02:59:03 +0000 (UTC)
Received: by mail-pl1-x629.google.com with SMTP id a13so361502plh.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <eric@voskuil.org>
To: "'Anthony Towns'" <aj@erisian.com.au>,
 "'Bitcoin Protocol Discussion'" <bitcoin-dev@lists.linuxfoundation.org>,
 "'Gloria Zhao'" <gloriajzhao@gmail.com>
References: <CAFXO6=JROe_9ih2h+_CCH-UbxehsM5RQ6YyNnPesEpveBEtdow@mail.gmail.com>
 <20220518003531.GA4402@erisian.com.au>
 <CAFXO6=LWM4eHM=zJhejw5981+8h7QHTbwpz0jEbWkrLOX0037Q@mail.gmail.com>
 <20220523213416.GA6151@erisian.com.au>
 <CAFXO6=KXToP2MFWQ1JVKX6jV++utw8E4Z13T4cH+mfgtyeUx_A@mail.gmail.com>
 <2B3D1901-901C-4000-A2B9-F6857FCE2847@erisian.com.au>
 <CAFXO6=K6FXNFwOZ3VyT6_RZY2F2BX+iTy+MyOshRBfNnn9Hqyg@mail.gmail.com>
 <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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <eric@voskuil.org>
> Sent: Wednesday, May 25, 2022 1:52 PM
> To: 'Anthony Towns' <aj@erisian.com.au>; 'Bitcoin Protocol Discussion'
> <bitcoin-dev@lists.linuxfoundation.org>; 'Gloria Zhao'
> <gloriajzhao@gmail.com>
> Subject: RE: [bitcoin-dev] Package Relay Proposal
> 
> > From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> 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