> Hi Eric,
>
>
> This email wasn't answered by anyone on mailing list however I did some
> research about packages yesterday including this email and below are my
> observations, questions etc.
Hello, thanks for the reply.
> > The sole objective, as expressed in the OP proposal, is to:
> >
> >
Hi Eric,
This email wasn't answered by anyone on mailing list however I did some
research about packages yesterday including this email and below are my
observations, questions etc.
> The sole objective, as expressed in the OP proposal, is to:
>
> "Propagate transactions that are
Hi Greg, Antoine, Bastien,
Thanks very much for the feedback! I interpret most of the discussion
around limitations as ideas for future improvements rather than criticisms
of the proposal (please correct me if I'm wrong). I'll try to respond to as
much as possible.
Also I realize that I didn't
Bastien,
> This may be already covered by the current package RBF logic, in that
scenario we are simply replacing [ParentTx, ChildTx1] with
[ParentTx, ChildTx2] that pays more fees, right?
For clarification, package RBF is ParentTx*s*(plural), and
ChildTx(singular), so it might be a bit more
Thanks Gloria for this great post.
This is very valuable work for L2 contracts, and will greatly improve
their security model.
> "Only 1 anchor output? What if I need to bump counterparty's commitment
tx in mempool?"
> You won't need to fee-bump a counterparty's commitment tx using CPFP.
> You
Following discussion with several wallet developers, I have come to the
conclusion that the secondary goal of managing labels in non-specialized
applications must be sacrificed in order to achieve the primary goal of
wide implementation across different wallets. While this tradeoff was
perhaps
