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: e...@voskuil.org <e...@voskuil.org> > Sent: Wednesday, May 25, 2022 1:52 PM > To: 'Anthony Towns' <a...@erisian.com.au>; 'Bitcoin Protocol Discussion' > <bitcoin-dev@lists.linuxfoundation.org>; 'Gloria Zhao' > <gloriajz...@gmail.com> > Subject: RE: [bitcoin-dev] Package Relay Proposal > > > From: bitcoin-dev <bitcoin-dev-boun...@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
