darosior [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-14 📝 Original message:Hi Gloria, > In summary, ...
📅 Original date posted:2021-10-14
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211014/9782650f/attachment.html>;
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211014/9782650f/attachment.html>;