📅 Original date posted:2020-06-22
📝 Original message:
Hey ZmnSCPxj,
I agree that in theory this looks possible, but doing it in practice with
accurate control
of what parts of the network get what tx feels impractical to me (but maybe
I'm wrong!).
It feels to me that an attacker who would be able to do this would break
*any* off-chain
construction that relies on absolute timeouts, so I'm hoping this is
insanely hard to
achieve without cooperation from a miners subset. Let me know if I'm too
optimistic on
this!
Cheers,
Bastien
Le lun. 22 juin 2020 à 10:15, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200622/67840048/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:00:32
in reply to nevent1q…jk7c
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:00:32Event JSON
{
"id": "5f7355173806de6aae0e058de7cde16839626f53e715c88ed20dadbb635612ee",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315632,
"kind": 1,
"tags": [
[
"e",
"4ca42899fa8de714a727dbf98bf2ddb3daa5c45e423147e099276bcf1b70702d",
"",
"root"
],
[
"e",
"610e9799f9716e6df1f16f598ef7434a75f2bca1d10d4c9be675cbaccc00c3bb",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-06-22\n📝 Original message:\nHey ZmnSCPxj,\n\nI agree that in theory this looks possible, but doing it in practice with\naccurate control\nof what parts of the network get what tx feels impractical to me (but maybe\nI'm wrong!).\n\nIt feels to me that an attacker who would be able to do this would break\n*any* off-chain\nconstruction that relies on absolute timeouts, so I'm hoping this is\ninsanely hard to\nachieve without cooperation from a miners subset. Let me know if I'm too\noptimistic on\nthis!\n\nCheers,\nBastien\n\nLe lun. 22 juin 2020 à 10:15, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning Bastien,\n\u003e\n\u003e \u003e Thanks for the detailed write-up on how it affects incentives and\n\u003e centralization,\n\u003e \u003e these are good points. I need to spend more time thinking about them.\n\u003e \u003e\n\u003e \u003e \u003e This is one reason I suggested using independent pay-to-preimage\n\u003e \u003e \u003e transactions[1]\n\u003e \u003e\n\u003e \u003e While this works as a technical solution, I think it has some incentives\n\u003e issues too.\n\u003e \u003e In this attack, I believe the miners that hide the preimage tx in their\n\u003e mempool have\n\u003e \u003e to be accomplice with the attacker, otherwise they would share that tx\n\u003e with some of\n\u003e \u003e their peers, and some non-miner nodes would get that preimage tx and be\n\u003e able to\n\u003e \u003e gossip them off-chain (and even relay them to other mempools).\n\u003e\n\u003e I believe this is technically possible with current mempool rules, without\n\u003e miners cooperating with the attacker.\n\u003e\n\u003e Basically, the attacker releases two transactions with near-equal fees, so\n\u003e that neither can RBF the other.\n\u003e It releases the preimage tx near miners, and the timelock tx near\n\u003e non-miners.\n\u003e\n\u003e Nodes at the boundaries between those that receive the preimage tx and the\n\u003e timelock tx will receive both.\n\u003e However, they will receive one or the other first.\n\u003e Which one they receive first will be what they keep, and they will reject\n\u003e the other (and *not* propagate the other), because the difference in fees\n\u003e is not enough to get past the RBF rules (which requires not just a feerate\n\u003e increase, but also an increase in absolute fee, of at least the minimum\n\u003e relay feerate times transaction size).\n\u003e\n\u003e Because they reject the other tx, they do not propagate the other tx, so\n\u003e the boundary between the two txes is inviolate, neither can get past that\n\u003e boundary, this occurs even if everyone is running 100% unmodified Bitcoin\n\u003e Core code.\n\u003e\n\u003e I am not a mempool expert and my understanding may be incorrect.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200622/67840048/attachment.html\u003e",
"sig": "abb1a642ac17c26ee0c15b53ffd69ec5142172a5f5ad522d6674ca459fd7e5fa1a4b695bc533056f66179a63c6aaf46abe855222df0a4035f7a9e2cb1bec030c"
}