diff options
| author | eric <eric@voskuil.org> | 2022-05-25 19:59:01 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-05-26 02:59:05 +0000 |
| commit | 5f9dfd79fdb43426359ce8f7e56eb5312c738d0c (patch) | |
| tree | c0b48286462dff4b92b578c3f7c29e0797b1d755 | |
| parent | f58468f2c97f0a2c74f5a191ddd5e3b4e24f409b (diff) | |
| download | pi-bitcoindev-5f9dfd79fdb43426359ce8f7e56eb5312c738d0c.tar.gz pi-bitcoindev-5f9dfd79fdb43426359ce8f7e56eb5312c738d0c.zip | |
Re: [bitcoin-dev] Package Relay Proposal
| -rw-r--r-- | 27/eb1a36f55b7490ccf41b455c75d08d969ad910 | 245 |
1 files changed, 245 insertions, 0 deletions
diff --git a/27/eb1a36f55b7490ccf41b455c75d08d969ad910 b/27/eb1a36f55b7490ccf41b455c75d08d969ad910 new file mode 100644 index 000000000..952a7fe81 --- /dev/null +++ b/27/eb1a36f55b7490ccf41b455c75d08d969ad910 @@ -0,0 +1,245 @@ +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 + + + |