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
> transactions.
I would like to point out that package relay is not only useful in Lightning's
adversarial scenarii but also for a better user experience of CPFP.
Take for instance a wallet managing coins it can only spend using pre-signed
transactions. It may batch these coins into a single transaction, but only
after broadcasting the pre-signed tx for each of these coins.
So for a 3 utxos it'd be:
coin1 -----> pres. tx1 ----- |
coin2 -----> pres. tx2 ----- | - - - spending transaction
coin3 -----> pres. tx3 ----- |
Now all these pre-signed transactions are pre-signed with a fixed feerate,
which might be below the mempool minimum fee at the time of broadcast.
This is a usecase for multiple-parents-1-child packages. This is also something
we do for Revault: you have pre-signed Unvault transactions, each have a CPFP
output [0]. Since their confirmation is not security critical, you'd really
want to batch the child-fee-paying tx.
Regarding 2. i did not come up with a reason for dropping this rule (yet?)
since if you need to replace the child you can use individual submission, and
if you need to replace the parent the child itself does not conflict anymore.
Thanks for the effort put into requesting feedback,
Antoine
[0]
https://github.com/revault/practical-revault/blob/master/transactions.md#unvault_tx
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
