š
Original date posted:2022-05-25
š Original message:> From: bitcoin-dev <bitcoin-dev-bounces at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
eric at voskuil.org [ARCHIVE] /
npub1r3ā¦6s8vu
2023-06-07 23:09:51
in reply to nevent1qā¦t2yw
Author Public Key
npub1r34khxrz9w39zpzezymqz04dcel95adfxf6qpjul9wdv2qn5vtps06s8vuSeen on
wss://relay.noswhere.comPublished at
2023-06-07 23:09:51Event JSON
{
"id": "ca99f40a53c3db28c53f2002784abff375645862e56f8c212e5d1b633798fa9d",
"pubkey": "1c6b6b98622ba25104591136013eadc67e5a75a9327400cb9f2b9ac5027462c3",
"created_at": 1686179391,
"kind": 1,
"tags": [
[
"e",
"2ff757999827be6e4e537a444aad80562c1001e4e555376a251ff2ee7be09c2d",
"",
"root"
],
[
"e",
"b4f03a0ccaa7fbe0e87458a45e3e125350db7a84ddf46a79a57144584e41bddd",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "š
Original date posted:2022-05-25\nš Original message:\u003e From: bitcoin-dev \u003cbitcoin-dev-bounces at lists.linuxfoundation.org\u003e On\nBehalf\n\u003e Of Anthony Towns via bitcoin-dev\n\u003e Sent: Wednesday, May 25, 2022 11:56 AM\n\n\u003e So the other thing is what happens if the peer announcing packages to us\nis\n\u003e dishonest?\n\u003e \n\u003e They announce pkg X, say X has parents A B C and the fee rate is garbage.\nBut\n\u003e actually X has parent D and the fee rate is excellent. Do we request the\n\u003e package from another peer, or every peer, to double check? Otherwise we're\n\u003e allowing the first peer we ask about a package to censor that tx from us?\n\u003e \n\u003e I think the fix for that is just to provide the fee and weight when\nannouncing\n\u003e the package rather than only being asked for its info? Then if one peer\nmakes\n\u003e it sound like a good deal you ask for the parent txids from them, dedupe,\n\u003e request, and verify they were honest about the parents.\n\nSingle tx broadcasts do not carry an advertised fee rate, however the'\nfeefilter' message (BIP133) provides this distinction. This should be\ninterpreted as applicable to packages. Given this message there is no reason\nto send a (potentially bogus) fee rate with every package. It can only be\nvalidated by obtaining the full set of txs, and the only recourse is\ndropping (etc.) the peer, as is the case with single txs. Relying on the\nexisting message is simpler, more consistent, and more efficient.\n\n\u003e \u003e\u003e Is it plausible to add the graph in?\n\u003e \n\u003e Likewise, I think you'd have to have the graph info from many nodes if\nyou're\n\u003e going to make decisions based on it and don't want hostile peers to be\nable to\n\u003e trick you into ignoring txs.\n\u003e \n\u003e Other idea: what if you encode the parent txs as a short hash of the wtxid\n\u003e (something like bip152 short ids? perhaps seeded per peer so collisions\nwill\n\u003e be different per peer?) and include that in the inv announcement? Would\n\u003e that work to avoid a round trip almost all of the time, while still giving\nyou\n\u003e enough info to save bw by deduping parents?\n\nAs I suggested earlier, a package is fundamentally a compact block (or\nblock) announcement without the header. Compact block (BIP152) announcement\nis already well-defined and widely implemented. A node should never be\nrequired to retain an orphan, and BIP152 ensures this is not required.\n\nOnce a validated set of txs within the package has been obtained with\nsufficient fee, a fee-optimal node would accept the largest subgraph of the\npackage that conforms to fee constraints and drop any peer that provides a\npackage for which the full graph does not.\n\nLet us not reinvent the wheel and/or introduce accidental complexity. I see\nno reason why packaging is not simply BIP152 without the 'header' field, an\nupdated protocol version, and the following sort of changes to names:\n\nsendpkg\nMSG_CMPCT_PKG\ncmpctpkg\ngetpkgtxn\npkgtxn\n\n\u003e \u003e For a maximum 25 transactions,\n\u003e \u003e23*24/2 = 276, seems like 36 bytes for a child-with-parents package.\n\u003e \n\u003e If you're doing short ids that's maybe 25*4B=100B already, then the above\nis\n\u003e up to 36% overhead, I guess. Might be worth thinking more about, but maybe\n\u003e more interesting with ancestors than just parents.\n\u003e \n\u003e \u003eAlso side note, since there are no size/count params,\n\nSize is restricted in the same manner as block and transaction broadcasts,\nby consensus. If the fee rate is sufficient there would be no reason to\npreclude any valid size up to what can be mined in one block (packaging\nacross blocks is not economically rational under the assumption that one\nminer cannot expect to mine multiple blocks in a row). Count is incorporated\ninto BIP152 as 'shortids_length'.\n\n\u003e \u003e wondering if we\n\u003e \u003eshould just have \"version\" in \"sendpackages\" be a bit field instead of\n\u003e \u003esending a message for each version. 32 versions should be enough right?\n\nAdding versioning to individual protocols is just a reflection of the\ninsufficiency of the initial protocol versioning design, and that of the\nvarious ad-hoc changes to it (including yet another approach in this\nproposal) that have been introduced to compensate for it, though I'll\naddress this in an independent post at some point.\n\nBest,\ne\n\n\u003e Maybe but a couple of messages per connection doesn't really seem worth\n\u003e arguing about?\n\u003e \n\u003e Cheers,\n\u003e aj\n\u003e \n\u003e \n\u003e --\n\u003e Sent from my phone.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "50d70307468f7413333261308602d54853d83130809f5ae7fbcbabd9723a6d8001308fa76502381f4b7f4e5106651dc639cd873279d4408be387d0d93028d682"
}