📅 Original date posted:2020-06-22
📝 Original message:
Good morning Bastien,
> Thanks for the detailed write-up on how it affects incentives and centralization,
> these are good points. I need to spend more time thinking about them.
>
> > This is one reason I suggested using independent pay-to-preimage
> > transactions[1]
>
> While this works as a technical solution, I think it has some incentives issues too.
> In this attack, I believe the miners that hide the preimage tx in their mempool have
> to be accomplice with the attacker, otherwise they would share that tx with some of
> their peers, and some non-miner nodes would get that preimage tx and be able to
> gossip them off-chain (and even relay them to other mempools).
I believe this is technically possible with current mempool rules, without miners cooperating with the attacker.
Basically, the attacker releases two transactions with near-equal fees, so that neither can RBF the other.
It releases the preimage tx near miners, and the timelock tx near non-miners.
Nodes at the boundaries between those that receive the preimage tx and the timelock tx will receive both.
However, they will receive one or the other first.
Which one they receive first will be what they keep, and they will reject the other (and *not* propagate the other), because the difference in fees is not enough to get past the RBF rules (which requires not just a feerate increase, but also an increase in absolute fee, of at least the minimum relay feerate times transaction size).
Because they reject the other tx, they do not propagate the other tx, so the boundary between the two txes is inviolate, neither can get past that boundary, this occurs even if everyone is running 100% unmodified Bitcoin Core code.
I am not a mempool expert and my understanding may be incorrect.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 13:00:31
in reply to nevent1q…agls
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:00:31Event JSON
{
"id": "610e9799f9716e6df1f16f598ef7434a75f2bca1d10d4c9be675cbaccc00c3bb",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315631,
"kind": 1,
"tags": [
[
"e",
"4ca42899fa8de714a727dbf98bf2ddb3daa5c45e423147e099276bcf1b70702d",
"",
"root"
],
[
"e",
"98d64eda6968014ee31655e55145468ae2f21593f0af400c614da588dcede6c5",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2020-06-22\n📝 Original message:\nGood morning Bastien,\n\n\u003e Thanks for the detailed write-up on how it affects incentives and centralization,\n\u003e these are good points. I need to spend more time thinking about them.\n\u003e\n\u003e \u003e This is one reason I suggested using independent pay-to-preimage\n\u003e \u003e transactions[1]\n\u003e\n\u003e While this works as a technical solution, I think it has some incentives issues too.\n\u003e In this attack, I believe the miners that hide the preimage tx in their mempool have\n\u003e to be accomplice with the attacker, otherwise they would share that tx with some of\n\u003e their peers, and some non-miner nodes would get that preimage tx and be able to\n\u003e gossip them off-chain (and even relay them to other mempools).\n\nI believe this is technically possible with current mempool rules, without miners cooperating with the attacker.\n\nBasically, the attacker releases two transactions with near-equal fees, so that neither can RBF the other.\nIt releases the preimage tx near miners, and the timelock tx near non-miners.\n\nNodes at the boundaries between those that receive the preimage tx and the timelock tx will receive both.\nHowever, they will receive one or the other first.\nWhich one they receive first will be what they keep, and they will reject the other (and *not* propagate the other), because the difference in fees is not enough to get past the RBF rules (which requires not just a feerate increase, but also an increase in absolute fee, of at least the minimum relay feerate times transaction size).\n\nBecause they reject the other tx, they do not propagate the other tx, so the boundary between the two txes is inviolate, neither can get past that boundary, this occurs even if everyone is running 100% unmodified Bitcoin Core code.\n\nI am not a mempool expert and my understanding may be incorrect.\n\nRegards,\nZmnSCPxj",
"sig": "7db881526149e9a07e1c0c1004d2dcb71b9e6fbef2948ebcce878bc1a9fa97e020ea12d8ede984258e7627216f522f73f238e8ff7164a6b4a5788224357abdea"
}