[RFC] Package-relay: sender-initiated #19621
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Accepting a single transaction to the mempool only succeeds if (among other things) the feerate of the transaction is greater than both the min relay fee and the mempool min fee. Consequently, a transaction below the minimum fee may not be accepted to the mempool, even if we later learn of a transaction with a high relay fee that depends on it. This commit adds a function that will accept a package of transactions to the mempool, with the following restrictions: - All package transactions must be direct parents of the final transaction. This is a simple heuristic for ensuring that a candidate list of transactions is in fact a package (we wouldn't want arbitrary transactions to be paying for random low feerate transactions) - The feerate of the package, as a whole, exceeds the mempool min fee and the min relay fee. - No transactions in the mempool conflict with any transactions in the package. This is a simplification that makes the logic easier to write. Without this requirement, we would need to do additional checks to ensure that no parent transaction would evict a transaction from the mempool that some other child depends on. - The ancestor/descendant size limits are calculated assuming that any mempool ancestor of any candidate transaction is an ancestor of all the candidate transactions. This allows for doing simpler calculations to ensure that we're staying within the mempool's package limits. If we eliminated this, we would need to do much more careful package calculations for each candidate transaction and each in-mempool ancestor. This commit does not include any accessor function for utilizing this logic (eg by exposing this function at the p2p or rpc layer).
In next commit, we relax restriction on conflict replacement at package acceptance. Package transactions may depend on conflicted ones replaced by other package elements, thus making its evaluation expensive. To avoid DoS risk while allowing feerate-increasing packages limit theirs composition to 2 transactions, the latter only dependent on the former.
… checks A package may bundle a newer CPFP with an already-in subgraph. To evaluate replacement correctly, collect older fees of each conflicted transactions while omitting per-transaction fee/feerate checks in PreChecks(). For now, we don't evict conflicting duplicate, as a transaction might be in conflict with multiple package elements. XXX: refactor PreChecks() to dedup in AcceptMultipleTransactions ?
To reduce bandwidth consumption due to package announcement, only announce a 32-byte package_id, sha256 of all package transactions. To avoid this cache being a DoS risk, allocate a number of package announcements to each upstream peer. To guarantee flush, prune old entries after a delay (PACKAGE_CACHE_DELAY), thus requiring downstream package round-trip to achieve before.
This new p2p message contains a serialized list of transactions, which upon receipt feerate of the whole must determine mempool acceptance.
The hash being referenced is a package_id.
At INV sending, announce packages unknown to the processed downstream peer. Any transaction part of a mapped package, won't be announced redundantly.
Disallow getdata reply if this peer isn't assumed to have been announced this package yet.
XXX: add byte flag to signal package policy enforced
This command let caller submit a bundle of transactions to the local mempool and p2p network, ensuring their summed feerate is going to be evaluated as a package.
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
This was referenced Jul 29, 2020
This was referenced Jul 30, 2020
|
🐙 This pull request conflicts with the target branch and needs rebase. Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft". |
There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
1 similar comment
There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
|
Closing for now. You can open a new pull request if you are working on this again, since this one doesn't have any discussion. |
|
I confirm, this work has been superseded by the advances with package acceptance (https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a). For the p2p part, the sender-initiated approach and the package ids caching might be of interest for the conceptual discussion when we introduce p2p packages. I don't have interest to keep working on that version of package relay but I'm staying interested to review any work or draft in that area. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is demo code for a sender-initiated version of package-relay. This is not proposed for merging, only to illustrate package relay design with trade-offs compared to #16401. See my update on #14895 to advance discussions on package-relay.
Few design choices of interest:
sendpackages,MSG_PACKAGE,packageand newpackage_ididentifier incorporated to the INV/GETDATA control logic : https://gist.github.com/ariard/10924249b3b7f6e239d80895372839b8sendpackagerpc to let a higher-application signals a chain of transactions and such start a propagation on the p2p networkPackageCacheto internally cache the mapping package_id -> txids/wtxids, as they need to be persistent across a round-trip between upstream/downstream peers, it must be DoS resistantAcceptMultipleTransactionswith a package policy restriction to 2-tx only, make it easier to reason on for replacement