Ephemeral Anchors #29001
Ephemeral Anchors #29001
Conversation
At this point it's not expected that there are any such transactions, except from reorgs.
…o use Txid It's preferable to use type-safe transaction identifiers to avoid confusing txid and wtxid. The next commit will add a reference to this set; we use this opportunity to change it to Txid ahead of time instead of adding new uses of uint256.
As long as they are otherwise paid for, i.e. through package CPFP. If a v3 transaction loses its sponsor, we can evict them with no trouble because it will not have other descendants or ancestors to make the feerate assessment more complicated.
The behavior is not new, but this rule exits earlier than before. Previously, a carve out could have been granted in PreChecks() but then nullified in PackageMempoolChecks() when CheckPackageLimits() is called with the default limits.
No change in behavior. For single transaction acceptance, this is a simple refactor: Workspace::m_all_conflicting -> MemPoolAccept::m_all_conflicts Workspace::m_conflicting_fees -> MemPoolAccept::m_conflicting_fees Workspace::m_conflicting_size -> MemPoolAccept::m_conflicting_size Workspace::m_replaced_transactions -> MemPoolAccept::m_replaced_transactions And local variables m_total_vsize and m_total_modified_fees are now MemPoolAccept members so they can be accessed from PackageMempoolChecks. We want these to be package-wide variables because - Transactions could conflict with the same tx (just not the same prevout), or their conflicts could share descendants. - We want to compare conflicts with the package fee rather than individual transaction fee. We reset these MemPoolAccept-wide fields for each subpackage evaluation to not cause state leaking, similar to temporary coins.
…tible Avoid accepting replacements that are not more incentive compatible to mine. For now, as a somewhat conservative estimate, require that the minimum between the transaction's individual feerate and ancestor feerate is higher than the individual feerates of directly conflicting transactions and the ancestor feerates of all original transactions. Note that a package/transaction's ancestor feerate is not perfectly representative of its incentive compatibility; it may overestimate (some subset of the ancestors could be included by itself if it has other high-feerate descendants or are themselves higher feerate than this package/transaction). Co-authored-by: Suhas Daftuar <sdaftuar@chaincode.com>
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process. 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. |
instagibbs
force-pushed
the
2023-12-ephemeral-anchors
branch
from
aedda98
to
cab9b9a
Compare
instagibbs
force-pushed
the
2023-12-ephemeral-anchors
branch
from
cab9b9a
to
d1d7a94
Compare
This will be used in following commits as the flag for ephemeral anchors, allowing dust values, but also requiring the output to be spend in the same relay package.
Anchor outputs are not yet required to be spent in same mempool package.
Either in the same relay package, or by transactions RBFing the CPFP.
"Be 0-fee” This is uncertain to me how this rule works with trimmed HTLCs on LN commitment transactions making their fees non-zero, even assuming anchor outputs where second-stage txn are signed with 0-feerate. Beyond, I think it should add an information section at destination of use-cases developers discouraging the usage of anyone-can-spend ephemeral anchor. Otherwise a time-sensitive package can be tampered by third-parties entering into replacement cycling games, without being a direct off-chain counterparty to the target transaction traffic. |
|
@ariard I'd rather talk downstream details over here bitcoin/bips#1524 |
|
🐙 This pull request conflicts with the target branch and needs rebase. |
Node policy is not a subject matter for standardization in itself. It's the transaction format that the BIP (if there is one) should focus on, not speculative behaviour of individual nodes. |
Thanks good to me - Answered strong conceptual issues there. |
This Proposed BIP brings a set of concepts that allows the community to communicate using a coherent language regarding what "Ephemeral Anchors" are. By defining this term in context of how it could work, the community can reason about them in a clear and coherent manner, (no matter if they individuality choose to use them in their node policy or not). It is my opinion that such a BIP proposal is perfectly applicable and beneficial toward the community communication goals:
|
|
I have another branch I'm going to likely pursue once 1p1c relay is further along: instagibbs@fe67ffd With v3 + sibling eviction, it makes sense to me to first open up the feature with current supported scriptpubkeys for when the output is considered dust. This allows people to pick anyone can spend or shared keyed anchors. It also means any outputs can be dust, as long as they get spent. Future updates can include:
|
|
closing this in favor of #30239 |
Depends on #28948 and #28984
Replaces #26403 to refresh the conversation.
BIP text here: https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki
Example usage:
https://github.com/instagibbs/bolts/commits/zero_fee_commitment
https://github.com/instagibbs/lightning/commits/commit_zero_fees
TODO: