>
> 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 Rule #2 ?
>
I think constraining package acceptance to only confirmed inputs
is very limiting and quite dangerous for L2 protocols.
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 utxos just for fee bumping, which is inefficient...
Bastien
Le lun. 27 sept. 2021 à 00:27, Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :
> 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 conflicts with
> > mempool transactions.
>
> Yes 1) it would be good to have inputs of more potential users of package
> acceptance . And 2) I think it's more a matter of clearer wording of the
> proposal.
>
> However, see my final point on the relaxation around "unconfirmed inputs"
> which might in fact alter our current block construction strategy.
>
> > Right, the fact that we essentially always choose the first-seen witness
> is
> > an unfortunate limitation that exists already. Adding package mempool
> > accept doesn't worsen this, but the procedure in the future is to replace
> > the witness when it makes sense economically. We can also add logic to
> > allow package feerate to pay for witness replacements as well. This is
> > pretty far into the future, though.
>
> Yes I agree package mempool doesn't worsen this. And it's not an issue for
> current LN as you can't significantly inflate a spending witness for the
> 2-of-2 funding output.
> However, it might be an issue for multi-party protocol where the spending
> script has alternative branches with asymmetric valid witness weights.
> Taproot should ease that kind of script so hopefully we would deploy
> wtxid-replacement not too far in the future.
>
> > I could be misunderstanding, but an attacker wouldn't be able to
> > batch-attack like this. Alice's package only conflicts with A' + D', not
> A'
> > + B' + C' + D'. She only needs to pay for evicting 2 transactions.
>
> Yeah I can be clearer, I think you have 2 pinning attacks scenarios to
> consider.
>
> In LN, if you're trying to confirm a commitment transaction to time-out or
> claim on-chain a HTLC and the timelock is near-expiration, you should be
> ready to pay in commitment+2nd-stage HTLC transaction fees as much as the
> value offered by the HTLC.
>
> Following this security assumption, an attacker can exploit it by
> targeting together commitment transactions from different channels by
> blocking them under a high-fee child, of which the fee value
> is equal to the top-value HTLC + 1. Victims's fee-bumping logics won't
> overbid as it's not worthy to offer fees beyond their competed HTLCs. Apart
> from observing mempools state, victims can't learn they're targeted by the
> same attacker.
>
> To draw from the aforementioned topology, Mallory broadcasts A' + B' + C'
> + D', where A' conflicts with Alice's P1, B' conflicts with Bob's P2, C'
> conflicts with Caroll's P3. Let's assume P1 is confirming the top-value
> HTLC of the set. If D' fees is higher than P1 + 1, it won't be rational for
> Alice or Bob or Caroll to keep offering competing feerates. Mallory will be
> at loss on stealing P1, as she has paid more in fees but will realize a
> gain on P2+P3.
>
> In this model, Alice is allowed to evict those 2 transactions (A' + D')
> but as she is economically-bounded she won't succeed.
>
> Mallory is maliciously exploiting RBF rule 3 on absolute fee. I think this
> 1st pinning scenario is correct and "lucractive" when you sum the global
> gain/loss.
>
> There is a 2nd attack scenario where A + B + C + D, where D is the child
> of A,B,C. All those transactions are honestly issued by Alice. Once A + B +
> C + D are propagated in network mempools, Mallory is able to replace A + D
> with A' + D' where D' is paying a higher fee. This package A' + D' will
> confirm soon if D feerate was compelling but Mallory succeeds in delaying
> the confirmation
> of B + C for one or more blocks. As B + C are pre-signed commitments with
> a low-fee rate they won't confirm without Alice issuing a new child E.
> Mallory can repeat the same trick by broadcasting
> B' + E' and delay again the confirmation of C.
>
> If the remaining package pending HTLC has a higher-value than all the
> malicious fees over-bid, Mallory should realize a gain
