📅 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>;
darosior [ARCHIVE] /
npub1pj…x22xp
2023-06-07 23:00:12
in reply to nevent1q…as9s
Author Public Key
npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xpPublished at
2023-06-07 23:00:12Event JSON
{
"id": "86617fc8119320190ac2a8ed5af628d4b75e310404c7a3d9fe663793ae80fda2",
"pubkey": "0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2",
"created_at": 1686178812,
"kind": 1,
"tags": [
[
"e",
"c6197d719c6e8f2208fdb0c137a6038950438a9f266ee649b31fce33a47730cb",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2021-10-14\n📝 Original message:Hi Gloria,\n\n\u003e In summary, it seems that the decisions that might still need attention/input from devs on this mailing list are:\n\u003e 1. Whether we should start with multiple-parent-1-child or 1-parent-1-child.\n\u003e 2. Whether it's ok to require that the child not have conflicts with mempool transactions.\n\nI 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.\nTake 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.\nSo for a 3 utxos it'd be:\ncoin1 -----\u003e pres. tx1 ----- |\ncoin2 -----\u003e pres. tx2 ----- | - - - spending transaction\ncoin3 -----\u003e pres. tx3 ----- |\n\nNow 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.\nThis 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.\n\nRegarding 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.\n\nThanks for the effort put into requesting feedback,\nAntoine\n\n[0] https://github.com/revault/practical-revault/blob/master/transactions.md#unvault_tx\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211014/9782650f/attachment.html\u003e",
"sig": "cdc437d5fbe7843042734f8e98e4094e7a466323bb2d1708677cd03528e84a7c8e5d42fed3ee01d588cc4a440d170fe44af055ed66064c56b4225df135ffa5db"
}