From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5DAB3C002D for ; 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 ; 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 ; 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 ; 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 To: Gloria Zhao , Bitcoin Protocol Discussion User-Agent: K-9 Mail for Android In-Reply-To: References: <20220518003531.GA4402@erisian.com.au> <20220523213416.GA6151@erisian.com.au> <2B3D1901-901C-4000-A2B9-F6857FCE2847@erisian.com.au> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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