Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-18 📝 Original message: Hi all, Within our team, ...
📅 Original date posted:2020-02-18
📝 Original message:
Hi all,
Within our team, we've been discussing the subject of preventing
liquidity-consuming spam (aka channel jamming) further. One idea came up
that I think is worth sharing.
Previous prepay ideas were based on the sender paying something up-front in
case the htlc causes grief on the network. This however leaves the sender
vulnerable to nodes stealing that up-front payment.
Consider what is probably the worst known channel jamming attack: an
attacker sends minimum sized htlcs to fill up the limited number of
commitment slots of channels along the route. Those htlcs will be held as
long as possible by the receiving node (that is also controlled by the
attacker). The hold time per htlc doesn't even need to be very long,
because a fresh htlc can be launched to immediately re-occupy a slot after
it opens up again.
The cost to the network of this attack is mostly dependent on the capacity
of the channels used. The bigger the capacity, the more funds are locked up
if a sufficient number of minimum sized htlcs are pending. The size of the
up-front payment likely needs to be proportional to this cost.
This means that for small htlcs, the up-front payment requirements may very
well be exceeding the htlc amount and routing fees paid by far. At that
point, a routing node may decide to steal the up-front payment rather than
earn the routing fee in an honest way.
A different way of mitigating this is to reverse the direction in which the
bond is paid. So instead of paying to offer an htlc, nodes need to pay to
receive an htlc. This sounds counterintuitive, but for the described
jamming attack there is also an attacker node at the end of the route. The
attacker still pays. The advantage is that for legitimate senders, there is
no up-front payment that can be stolen.
How this would work is that channel peers charge each other for the time
that the other party holds an htlc. So if node A extends an htlc to node B,
node B will pay node A amount x per minute of hold time. If node B doesn't
pay (doesn't hold up the contract), A will close the channel. It can be a
running balance between A and B that materializes as a single htlc per
channel on the commitment transaction.
As long as node B forwards the htlc swiftly to node C, the dfiference (the
actual cost) between what B needs to pay A and what B receives from C will
be tiny. Only when the htlc reaches the attacker node, or any other node on
the network that is (unintentionally) mishaving for some reason, the delta
starts to increase quickly for that node. The cost is borne by the node
that should bear it.
This would also fix concerns that have been voiced around hodl invoices.
With the reverse bond payment as described above, hodling nodes will pay
for the cost of their actions.
Many details skipped over, but interested to hear opinions on the viability
of this variation of up-front payments.
Joost
On Tue, Nov 5, 2019 at 3:25 AM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> It's been widely known that we're going to have to have up-front
> payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
> link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
> spam).
>
> Since both Offers and Joost's WhatSat are looking at sending
> messages, it's time to float actual proposals. I've been trying to come
> up with something for several years now, so thought I'd present the best
> I've got in the hope that others can improve on it.
>
> 1. New feature bit, extended messages, etc.
> 2. Adding an HTLC causes a *push* of a number of msat on
> commitment_signed (new field), and a hash.
> 3. Failing/succeeding an HTLC returns some of those msat, and a count
> and preimage (new fields).
>
> How many msat can you take for forwarding? That depends on you
> presenting a series of preimages (which chain into a final hash given in
> the HTLC add), which you get by decoding the onion. You get to keep 50
> msat[1] per preimage you present[2].
>
> So, how many preimages does the user have to give to have you forward
> the payment? That depends. The base rate is 16 preimages, but subtract
> one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the
> onion. The blockhash is the hash of the block specified in the onion:
> reject if it's not in the last 3 blocks[3].
>
> This simply adds some payment noise, while allowing a hashcash style
> tradeoff of sats for work.
>
> The final node gets some variable number of preimages, which adds noise.
> It should take all and subtract from the minimum required invoice amount
> on success, or take some random number on failure.
>
> This leaks some forward information, and makes an explicit tradeoff for
> the sender between amount spent and privacy, but it's the best I've been
> able to come up with.
>
> Thoughts?
> Rusty.
>
> [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about
> 655msat per message. Flat pricing for simplicity; we're trying to
> prevent spam, not create a spam market.
> [2] Actually, a number and a single preimage; you can check this is
> indeed the n'th preimage.
> [3] This reduces incentive to grind the damn things in advance, though
> maybe that's dumb? We can also use a shorter hash (siphash?), or
> even truncated SHA256 (128 bits).
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200218/59b4ba73/attachment.html>;
📝 Original message:
Hi all,
Within our team, we've been discussing the subject of preventing
liquidity-consuming spam (aka channel jamming) further. One idea came up
that I think is worth sharing.
Previous prepay ideas were based on the sender paying something up-front in
case the htlc causes grief on the network. This however leaves the sender
vulnerable to nodes stealing that up-front payment.
Consider what is probably the worst known channel jamming attack: an
attacker sends minimum sized htlcs to fill up the limited number of
commitment slots of channels along the route. Those htlcs will be held as
long as possible by the receiving node (that is also controlled by the
attacker). The hold time per htlc doesn't even need to be very long,
because a fresh htlc can be launched to immediately re-occupy a slot after
it opens up again.
The cost to the network of this attack is mostly dependent on the capacity
of the channels used. The bigger the capacity, the more funds are locked up
if a sufficient number of minimum sized htlcs are pending. The size of the
up-front payment likely needs to be proportional to this cost.
This means that for small htlcs, the up-front payment requirements may very
well be exceeding the htlc amount and routing fees paid by far. At that
point, a routing node may decide to steal the up-front payment rather than
earn the routing fee in an honest way.
A different way of mitigating this is to reverse the direction in which the
bond is paid. So instead of paying to offer an htlc, nodes need to pay to
receive an htlc. This sounds counterintuitive, but for the described
jamming attack there is also an attacker node at the end of the route. The
attacker still pays. The advantage is that for legitimate senders, there is
no up-front payment that can be stolen.
How this would work is that channel peers charge each other for the time
that the other party holds an htlc. So if node A extends an htlc to node B,
node B will pay node A amount x per minute of hold time. If node B doesn't
pay (doesn't hold up the contract), A will close the channel. It can be a
running balance between A and B that materializes as a single htlc per
channel on the commitment transaction.
As long as node B forwards the htlc swiftly to node C, the dfiference (the
actual cost) between what B needs to pay A and what B receives from C will
be tiny. Only when the htlc reaches the attacker node, or any other node on
the network that is (unintentionally) mishaving for some reason, the delta
starts to increase quickly for that node. The cost is borne by the node
that should bear it.
This would also fix concerns that have been voiced around hodl invoices.
With the reverse bond payment as described above, hodling nodes will pay
for the cost of their actions.
Many details skipped over, but interested to hear opinions on the viability
of this variation of up-front payments.
Joost
On Tue, Nov 5, 2019 at 3:25 AM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> It's been widely known that we're going to have to have up-front
> payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
> link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
> spam).
>
> Since both Offers and Joost's WhatSat are looking at sending
> messages, it's time to float actual proposals. I've been trying to come
> up with something for several years now, so thought I'd present the best
> I've got in the hope that others can improve on it.
>
> 1. New feature bit, extended messages, etc.
> 2. Adding an HTLC causes a *push* of a number of msat on
> commitment_signed (new field), and a hash.
> 3. Failing/succeeding an HTLC returns some of those msat, and a count
> and preimage (new fields).
>
> How many msat can you take for forwarding? That depends on you
> presenting a series of preimages (which chain into a final hash given in
> the HTLC add), which you get by decoding the onion. You get to keep 50
> msat[1] per preimage you present[2].
>
> So, how many preimages does the user have to give to have you forward
> the payment? That depends. The base rate is 16 preimages, but subtract
> one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the
> onion. The blockhash is the hash of the block specified in the onion:
> reject if it's not in the last 3 blocks[3].
>
> This simply adds some payment noise, while allowing a hashcash style
> tradeoff of sats for work.
>
> The final node gets some variable number of preimages, which adds noise.
> It should take all and subtract from the minimum required invoice amount
> on success, or take some random number on failure.
>
> This leaks some forward information, and makes an explicit tradeoff for
> the sender between amount spent and privacy, but it's the best I've been
> able to come up with.
>
> Thoughts?
> Rusty.
>
> [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about
> 655msat per message. Flat pricing for simplicity; we're trying to
> prevent spam, not create a spam market.
> [2] Actually, a number and a single preimage; you can check this is
> indeed the n'th preimage.
> [3] This reduces incentive to grind the damn things in advance, though
> maybe that's dumb? We can also use a shorter hash (siphash?), or
> even truncated SHA256 (128 bits).
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200218/59b4ba73/attachment.html>;