On 24 May 2022 5:05:35 pm GMT-04:00, Gloria Zhao via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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 := X.size, f := X.fees, R := [X] >> * for P = P1..Pn: >> * do I already have P? then skip to the next parent >> * s += P.size, f += P.fees, R += [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. >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 down?) or had dropped from our mempool or similar, either way we don't have those txs yet. >Please lmk if you were imagining something different. I think I may be >missing something. That's what I was thinking, yes. 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. >> 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? > 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, 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? 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
