diff options
author | Anthony Towns <aj@erisian.com.au> | 2022-05-25 14:55:35 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-05-25 18:55:46 +0000 |
commit | bb2cc33733ef58392836812ce6482381fa88428b (patch) | |
tree | 58f3ba44b0004f6360a4dcd799658069e61bbc3a | |
parent | 84b69d49091f45c8ad89df59a111f0da78c1dd25 (diff) | |
download | pi-bitcoindev-bb2cc33733ef58392836812ce6482381fa88428b.tar.gz pi-bitcoindev-bb2cc33733ef58392836812ce6482381fa88428b.zip |
Re: [bitcoin-dev] Package Relay Proposal
-rw-r--r-- | 10/bf07536f1a6ace28774adbb65e88cfbb307543 | 140 |
1 files changed, 140 insertions, 0 deletions
diff --git a/10/bf07536f1a6ace28774adbb65e88cfbb307543 b/10/bf07536f1a6ace28774adbb65e88cfbb307543 new file mode 100644 index 000000000..0a61733ac --- /dev/null +++ b/10/bf07536f1a6ace28774adbb65e88cfbb307543 @@ -0,0 +1,140 @@ +Return-Path: <aj@erisian.com.au> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 5DAB3C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 May 2022 18:55:46 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 374006136B + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 May 2022 18:55:46 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.902 +X-Spam-Level: +X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +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 Ls40MwATBaNr + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 May 2022 18:55:45 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) + by smtp3.osuosl.org (Postfix) with ESMTPS id 66FC66136A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 May 2022 18:55:45 +0000 (UTC) +Received: from aj@azure.erisian.com.au (helo=[127.0.0.1]) + by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) + id 1ntwAX-00057v-CN; Thu, 26 May 2022 04:55:42 +1000 +Date: Wed, 25 May 2022 14:55:35 -0400 +From: Anthony Towns <aj@erisian.com.au> +To: Gloria Zhao <gloriajzhao@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +User-Agent: K-9 Mail for Android +In-Reply-To: <CAFXO6=K6FXNFwOZ3VyT6_RZY2F2BX+iTy+MyOshRBfNnn9Hqyg@mail.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> +Message-ID: <8FFE048D-854F-4D34-85DA-CE523C16EEB0@erisian.com.au> +MIME-Version: 1.0 +Content-Type: text/plain; + charset=utf-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Score-int: -28 +X-Spam-Bar: -- +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: Wed, 25 May 2022 18:55:46 -0000 + +On 24 May 2022 5:05:35 pm GMT-04:00, Gloria Zhao via bitcoin-dev <bitcoin-d= +ev@lists=2Elinuxfoundation=2Eorg> wrote: +>To clarify, in this situation, I'm imagining something like +>A: 0 sat, 100vB +>B: 1500 sat, 100vB +>C: 0 sat, 100vB +>X: 500 sat, 100vB +>feerate floor is 3sat/vB +> +>With the algo: +>> * is X alone above my fee rate? no, then forget it +>> * otherwise, s :=3D X=2Esize, f :=3D X=2Efees, R :=3D [X] +>> * for P =3D P1=2E=2EPn: +>> * do I already have P? then skip to the next parent +>> * s +=3D P=2Esize, f +=3D P=2Efees, R +=3D [P] +>> * if f/s above my fee rate floor? if so, request all the txs in R +> +>We'd erroneously ask for A+B+C+X, but really we should only take A+B=2E +>But wouldn't A+B also be a package that was announced for B? + +In theory, yes, but maybe it was announced earlier (while our node was dow= +n?) or had dropped from our mempool or similar, either way we don't have th= +ose txs yet=2E + +>Please lmk if you were imagining something different=2E I think I may be +>missing something=2E + +That's what I was thinking, yes=2E + +So the other thing is what happens if the peer announcing packages to us i= +s dishonest? + +They announce pkg X, say X has parents A B C and the fee rate is garbage= +=2E But actually X has parent D and the fee rate is excellent=2E Do we requ= +est the package from another peer, or every peer, to double check? Otherwis= +e we're allowing the first peer we ask about a package to censor that tx fr= +om us? + +I think the fix for that is just to provide the fee and weight when announ= +cing the package rather than only being asked for its info? Then if one pee= +r makes it sound like a good deal you ask for the parent txids from them, d= +edupe, request, and verify they were honest about the parents=2E + +>> 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=2E + +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 wi= +ll 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? + + +> For a maximum 25 transactions, +>23*24/2 =3D 276, seems like 36 bytes for a child-with-parents package=2E + +If you're doing short ids that's maybe 25*4B=3D100B already, then the abov= +e is up to 36% overhead, I guess=2E Might be worth thinking more about, but= + maybe more interesting with ancestors than just parents=2E + +>Also side note, since there are no size/count params, wondering if we +>should just have "version" in "sendpackages" be a bit field instead of +>sending a message for each version=2E 32 versions should be enough right? + +Maybe but a couple of messages per connection doesn't really seem worth ar= +guing about? + +Cheers, +aj + + +--=20 +Sent from my phone=2E + |