Hi Gloria,
> In summary, it seems that the decisions that might still need attention/input
> from devs on this mailing list are:
> 1. Whether we should start with multiple-parent-1-child or 1-parent-1-child.
> 2. Whether it's ok to require that the child not have conflicts with mempool
> transac
Hi Bastien
> In the case of LN, an attacker can game this and heavily restrict
your RBF attempts if you're only allowed to use confirmed inputs
and have many channels (and a limited number of confirmed inputs).
Otherwise you'll need node operators to pre-emptively split their
utxos into many small
>
> I think we could restrain package acceptance to only confirmed inputs for
> now and revisit later this point ? For LN-anchor, you can assume that the
> fee-bumping UTXO feeding the CPFP is already
> confirmed. Or are there currently-deployed use-cases which would benefit
> from your proposed Ru
Hi Gloria,
Thanks for your answers,
> In summary, it seems that the decisions that might still need
> attention/input from devs on this mailing list are:
> 1. Whether we should start with multiple-parent-1-child or
1-parent-1-child.
> 2. Whether it's ok to require that the child not have conflict
Hi Antoine,
Thanks as always for your input. I'm glad we agree on so much!
In summary, it seems that the decisions that might still need
attention/input from devs on this mailing list are:
1. Whether we should start with multiple-parent-1-child or 1-parent-1-child.
2. Whether it's ok to require t
> Correct, if B+C is too low feerate to be accepted, we will reject it. I
> prefer this because it is incentive compatible: A can be mined by itself,
> so there's no reason to prefer A+B+C instead of A.
> As another way of looking at this, consider the case where we do accept
> A+B+C and it sits at
Hi Bastien,
> A package A + C will be able to replace A' + B regardless of
> the weight of A' + B?
Correct, the weight of A' + B will not prevent A+C from replacing it (as
long as A+C pays enough fees). In example 2C, we would be able to replace A
with a package.
Best,
Gloria
On Wed, Sep 22, 20
Great, thanks for this clarification!
Can you confirm that this won't be an issue either with your
example 2C (in your first set of diagrams)? If I understand it
correctly it shouldn't, but I'd rather be 100% sure.
A package A + C will be able to replace A' + B regardless of
the weight of A' + B?
Hi Bastien,
Excellent diagram :D
> Here the issue is that a revoked commitment tx A' is pinned in other
> mempools, with a long chain of descendants (or descendants that reach
> the maximum replaceable size).
> We would really like A + C to be able to replace this pinned A'.
> We can't submit ind
Hi Gloria,
> I believe this attack is mitigated as long as we attempt to submit
transactions individually
Unfortunately not, as there exists a pinning scenario in LN where a
different commit tx is pinned, but you actually can't know which one.
Since I really like your diagrams, I made one as wel
Hi Bastien,
Thank you for your feedback!
> In your example we have a parent transaction A already in the mempool
> and an unrelated child B. We submit a package C + D where C spends
> another of A's inputs. You're highlighting that this package may be
> rejected because of the unrelated transacti
Hi Antoine,
First of all, thank you for the thorough review. I appreciate your insight
on LN requirements.
> IIUC, you have a package A+B+C submitted for acceptance and A is already
in your mempool. You trim out A from the package and then evaluate B+C.
> I think this might be an issue if A is t
Hi Gloria,
Thanks for this detailed post!
The illustrations you provided are very useful for this kind of graph
topology problems.
The rules you lay out for package RBF look good to me at first glance
as there are some subtle improvements compared to BIP 125.
> 1. A package cannot exceed `MAX_P
Hi Gloria,
> A package may contain transactions that are already in the mempool. We
> remove
> ("deduplicate") those transactions from the package for the purposes of
> package
> mempool acceptance. If a package is empty after deduplication, we do
> nothing.
IIUC, you have a package A+B+C submitt
Hi there,
I'm writing to propose a set of mempool policy changes to enable package
validation (in preparation for package relay) in Bitcoin Core. These would
not
be consensus or P2P protocol changes. However, since mempool policy
significantly affects transaction propagation, I believe this is rel
15 matches
Mail list logo
