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
Subject: Re: [bitcoin-dev] Package Relay Proposal
Precedence: list

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