📅 Original date posted:2020-04-23
📝 Original message:
On 4/23/20 8:46 AM, ZmnSCPxj wrote:
>>> - Miners, being economically rational, accept this proposal and include this in a block.
>>>
>>> The proposal by Matt is then:
>>>
>>> - The hashlock branch should instead be:
>>> - B and C must agree, and show the preimage of some hash H (hashlock branch).
>>> - Then B and C agree that B provides a signature spending the hashlock branch, to a transaction with the outputs:
>>> - Normal payment to C.
>>> - Hook output to B, which B can use to CPFP this transaction.
>>> - Hook output to C, which C can use to CPFP this transaction.
>>> - B can still (somehow) not maintain a mempool, by:
>>> - B broadcasts its timelock transaction.
>>> - B tries to CPFP the above hashlock transaction.
>>> - If CPFP succeeds, it means the above hashlock transaction exists and B queries the peer for this transaction, extracting the preimage and claiming the A->B HTLC.
>>
>> Note that no query is required. The problem has been solved and the preimage-containing transaction should now confirm just fine.
>
> Ah, right, so it gets confirmed and the `blocksonly` B sees it in a block.
>
> Even if C hooks a tree of low-fee transactions on its hook output or normal payment, miners will still be willing to confirm this and the B hook CPFP transaction without, right?
Correct, once it makes it into the mempool we can CPFP it and all the regular sub-package CPFP calculation will pick it
and its descendants up. Of course this relies on it not spending any other unconfirmed inputs.
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-09 12:59:51
in reply to nevent1q…7vdn
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-09 12:59:51Event JSON
{
"id": "47f9a5017cc9738b85a64d3a27666bd48f036067d5c214f2ab6a29e71f57b846",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686315591,
"kind": 1,
"tags": [
[
"e",
"ee435bc1a0c788f72e8a81b7b60de4f1b61098c601fe4125e1e3cc7e4c34ee87",
"",
"root"
],
[
"e",
"cba6f250a432d8f38ac71811e80fcd3e225b1b9feb2ba7c3bd0203ad1b2d42de",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-04-23\n📝 Original message:\nOn 4/23/20 8:46 AM, ZmnSCPxj wrote:\n\u003e\u003e\u003e - Miners, being economically rational, accept this proposal and include this in a block.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The proposal by Matt is then:\n\u003e\u003e\u003e\n\u003e\u003e\u003e - The hashlock branch should instead be:\n\u003e\u003e\u003e - B and C must agree, and show the preimage of some hash H (hashlock branch).\n\u003e\u003e\u003e - Then B and C agree that B provides a signature spending the hashlock branch, to a transaction with the outputs:\n\u003e\u003e\u003e - Normal payment to C.\n\u003e\u003e\u003e - Hook output to B, which B can use to CPFP this transaction.\n\u003e\u003e\u003e - Hook output to C, which C can use to CPFP this transaction.\n\u003e\u003e\u003e - B can still (somehow) not maintain a mempool, by:\n\u003e\u003e\u003e - B broadcasts its timelock transaction.\n\u003e\u003e\u003e - B tries to CPFP the above hashlock transaction.\n\u003e\u003e\u003e - If CPFP succeeds, it means the above hashlock transaction exists and B queries the peer for this transaction, extracting the preimage and claiming the A-\u003eB HTLC.\n\u003e\u003e\n\u003e\u003e Note that no query is required. The problem has been solved and the preimage-containing transaction should now confirm just fine.\n\u003e \n\u003e Ah, right, so it gets confirmed and the `blocksonly` B sees it in a block.\n\u003e \n\u003e Even if C hooks a tree of low-fee transactions on its hook output or normal payment, miners will still be willing to confirm this and the B hook CPFP transaction without, right?\n\nCorrect, once it makes it into the mempool we can CPFP it and all the regular sub-package CPFP calculation will pick it\nand its descendants up. Of course this relies on it not spending any other unconfirmed inputs.",
"sig": "998fa6edc0c790fd78e36724c3a64c4aa39b7d5f6adf19cffe78b79774338910fd88979d9e2e3cd91cbc0994ef63e0692ddc41e7210b9e8f1285c7dbd14c5061"
}