📅 Original date posted:2020-04-23
📝 Original message:
Good morning Matt,
> > - C directly contacts miners with an out-of-band proposal to replace its transaction with an alternative that is much smaller and has a low fee, but much better feerate.
>
> Or they can just wait. For example in today’s mempool it would not be strange for a transaction at 1 sat/vbyte to wait a day but eventually confirm.
That introduces the possibility that the entire tree (with high total fee, remember) gets confirmed, so it would be better for C to replace it with an alternative to a different address C still controls, with a slightly better fee rate but smaller (no child transactions) and lower total fee, so an economically-rational C will make that effort (and if there are still other transactions in the mempool, an economically-rational miner will accept this proposal).
But in any case this is a minor detail and the attack will work either way.
>
> > - 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?
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:59:50
in reply to nevent1q…k63r
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:59:50Event JSON
{
"id": "cba6f250a432d8f38ac71811e80fcd3e225b1b9feb2ba7c3bd0203ad1b2d42de",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315590,
"kind": 1,
"tags": [
[
"e",
"ee435bc1a0c788f72e8a81b7b60de4f1b61098c601fe4125e1e3cc7e4c34ee87",
"",
"root"
],
[
"e",
"685e13e598dc919ba31154d0ca55268eb6c3314b44aad7661a7773ce019b575c",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2020-04-23\n📝 Original message:\nGood morning Matt,\n\n\u003e \u003e - C directly contacts miners with an out-of-band proposal to replace its transaction with an alternative that is much smaller and has a low fee, but much better feerate.\n\u003e\n\u003e Or they can just wait. For example in today’s mempool it would not be strange for a transaction at 1 sat/vbyte to wait a day but eventually confirm.\n\nThat introduces the possibility that the entire tree (with high total fee, remember) gets confirmed, so it would be better for C to replace it with an alternative to a different address C still controls, with a slightly better fee rate but smaller (no child transactions) and lower total fee, so an economically-rational C will make that effort (and if there are still other transactions in the mempool, an economically-rational miner will accept this proposal).\n\nBut in any case this is a minor detail and the attack will work either way.\n\n\u003e\n\u003e \u003e - Miners, being economically rational, accept this proposal and include this in a block.\n\u003e \u003e\n\u003e \u003e The proposal by Matt is then:\n\u003e \u003e\n\u003e \u003e - The hashlock branch should instead be:\n\u003e \u003e - B and C must agree, and show the preimage of some hash H (hashlock branch).\n\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 - Normal payment to C.\n\u003e \u003e - Hook output to B, which B can use to CPFP this transaction.\n\u003e \u003e - Hook output to C, which C can use to CPFP this transaction.\n\u003e \u003e - B can still (somehow) not maintain a mempool, by:\n\u003e \u003e - B broadcasts its timelock transaction.\n\u003e \u003e - B tries to CPFP the above hashlock transaction.\n\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\n\u003e Note that no query is required. The problem has been solved and the preimage-containing transaction should now confirm just fine.\n\nAh, right, so it gets confirmed and the `blocksonly` B sees it in a block.\n\nEven 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\nRegards,\nZmnSCPxj",
"sig": "e56bb8620ef6220560875f7178b5d5580cb91b80ddd95bc5d1f2632ee0d6274192add8120ca997a8054762a3160bb04303a3e037be3b18c6ffd885b96ad1aba0"
}