Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2023-07-26 🗒️ Summary of this message: Carla thanks ...

📅 Original date posted:2023-07-26
🗒️ Summary of this message: Carla thanks everyone for their participation in the meeting and acknowledges Wolf for hosting in NYC and Michael Levin for providing notes.
📝 Original message:
On Wed, Jul 19, 2023 at 09:56:11AM -0400, Carla Kirk-Cohen wrote:
> Thanks to everyone who traveled far, Wolf for hosting us in style in
> NYC and to Michael Levin for helping out with notes <3

Thanks for the notes!

Couple of comments:

> - What is the “top of mempool” assumption?

FWIW, I think this makes much more sense if you think about this as a
few related, but separate goals:

* transactors want their proposed txs to go to miners
* pools/miners want to see the most profitable txs asap
* node operators want to support bitcoin users/businesses
* node operators also want to avoid wasting too much bandwidth/cpu/etc
relaying txs that aren't going to be mined, both their own and that
of other nodes'
* people who care about decentralisation want miners to get near-optimal
tx selection with a default bitcoind setup, so there's no secret
sauce or moats that could encourage a mining monopoly to develop

Special casing lightning unilateral closes [0] probably wouldn't be
horrible. It's obviously good for the first three goals. As far as the
fourth, if it was lightning nodes doing the relaying, they could limit
each unilateral close to one rbf attempt (based on to_local/to_remote
outputs changing). And for the fifth, provided unilateral closes remain
rare, the special config isn't likely to cause much of a profit difference
between big pools and small ones (and maybe that's only a short term
issue, and a more general solution will be found and implemented, where
stuff that would be in the next block gets relayed much more aggressively,
even if it replaces a lot of transactions).

[0] eg, by having lightning nodes relay the txs even when bitcoind
doesn't relay them, and having some miners run special configurations
to pull those txs in.

> - Is there a future where miners don’t care about policy at all?

Thinking about the different goals above seems like it gives a clear
answer to this: as far as mining goes, no there's no need to care
about policy restricitions -- policy is just there to meet other goals:
making it possible to run a node without wasting bandwidth, and to help
decentralisation by letting miners just buy hardware and deploy it,
without needing to do a bunch of protocol level trade secret/black magic
stuff in order to be competitive.

> - It must be zero fee so that it will be evicted.

The point of making a tx with ephemeral outputs be zero fee is to
prevent it from being mined in non-attack scenarios, which in turn avoids
generating a dust utxo. (An attacking miner can just create arbitrary
dust utxos already, of course)

> - Should we add trimmed HTLCs to the ephemeral anchor?
> - You can’t keep things in OP_TRUE because they’ll be taken.
> - You can also just put it in fees as before.

The only way value in an OP_TRUE output can be taken is by confirming
the parent tx that created the OP_TRUE output, exactly the same as if
the value had been spent to fees instead.

Putting the value to fees directly would violate the "tx must be zero
fee if it creates ephemeral outputs" constraint above.

> ### Hybrid Approach to Channel Jamming
> - Generally when we think about jamming, there are three “classes” of
> mitigations:
> - Monetary: unconditional fees, implemented in various ways.
> - The problem is that none of these solutions work in isolation.
> - Monetary: the cost that will deter an attacker is unreasonable for an
> honest user, and the cost that is reasonable for an honest user is too low
> for an attacker.

A different way of thinking about the monetary approach is in terms of
scaling rather than deterrance: that is, try to make the cost that the
attacker pays sufficient to scale up your node/the network so that you
continue to have excess capacity to serve regular users.

In that case, if people are suddenly routing their netflix data and
nostr photo libraries over lightning onion packets, that's fine: you
make them pay amazon ec2 prices plus 50% for the resources they use,
and when they do , you deploy more servers. ie, turn your attackers and
spammers into a profit centre.

I've had an email about this sitting in my drafts for a few years now,
but I think this could work something like:

- message spam (ie, onion traffic costs): when you send a message
to a peer, pay for its bandwidth and compute. Perhaps something
like 20c/GB is reasonable, which is something like 1msat per onion
packet, so perhaps 20msat per onion packet if you're forwarding it
over 20 hops.

- liquidity DoS prevention: if you're in receipt of a HTLC/PTLC and
aren't cancelling or confirming it, you pay your peer a fee for
holding their funds. (if you're forwarding the HTLC, then whoever you
forwarded to pays you a slightly higher fee, while they hold your
funds) Something like 1ppm per hour matches a 1% pa return, so if
you're an LSP holding on to a $20 payment waiting for the recipient to
come online and claim it, then you might be paying out $0.0004 per hour
(1.4sat) in order for 20 intermediate hops to each be making 20%
pa interest on their held up funds.

- actual payment incentives: eg, a $20 payment paying 0.05% fees
(phoenix's minimum) costs $0.01 (33sat). Obviously you want this
number to be a lot higher than all the DoS prevention fees.

If you get too much message spam, you fire up more amazon compute
and take maybe 10c/GB in profit; if all your liquidity gets used up,
congrats you've just gotten 20%+ APY on your bitcoin without third party
risk and you can either reinvest your profits or increase your fees; and
all of those numbers are just noise compared to actual payment traffic,
which is 30x or 1500x more profitable.

> - How do you know that these fees will be small? The market could decide
> otherwise.

If the liquidity or message fees on the network are high it's easy to
spin up new lightning nodes at slightly lower fees and steal all that
traffic while still being hugely profitable.

> - The problem here is that there’s no way to prove time when things go
> wrong, and any solution without a universal clock will fall back on
> cooperation which breaks down in the case of an attack.

The amounts here are all very low, so I don't think you really need much
more precision than "hourly". I think you could even do it "per block"
and convert "1% pa" as actually "0.2 parts per million per block", since
the only thing time is relevant for is turning liquidity DoS into an APY
figure. Presumably that needs some tweaking to deal with the possibility
of reorgs or stale blocks.

> - No honest user will be willing to pay the price for the worst case,
> which gets us back to the pricing issue.
> - There’s also an incentives issue when the “rent” we pay for these two
> weeks worst case is more than the forwarding fee, so a router may be
> incentivized to just hang on to that amount and bank it.

I think the worst case for that scenario is if you have a route

A1 -> A2 -> .. -> A19 -> B -> A20

then B closes the {B,A20} channel and at the end of the timeout A20 claims
the funds. At that point B will have paid liquidity fees to A1..A19 for
the full two week period, but will have only received a fixed payout
from A20 due to the channel close.

At 10% APY, with a $1000 payment, B will have paid ~$73 to A (7.3%). If
the close channel transaction costs, say, $5, then either you end up with
B wanting to close the channel early in non-attack scenarios (they collect
$73 from A20, but only pay perhaps 4c back to A1..A19, and perhaps $6 to
open and close the channel), or you end up with A holding up the funds
and leaching off B (B only collects, say, $20 from A20, but then A20
claims the funds after two weeks so is either up $75 if B didn't claim
the funds from A19, or is up $53 after B paid liquidity fees for 2 weeks).

_But_ I think this is an unreasonable scenario: the only reason for B to
forward a HTLC with a 2 week expiry is if they're early in the route,
but the only reason to accept a large liquidity fee is if they're late
in the route. So I think you can solve that by only forwarding a payment
if the liquidity fee rate multiplied by the expiry is below a cap, eg:

A19 -> B : wants 36ppm per block; cap/ppm = 500/36 = 13.8
B -> A20 : expiry is in 13 blocks; wants 38ppm per block

(2ppm per block ~= 10% APY)

For comparison, at the start of the chain, things look like:

A2 -> A3 : wants 2ppm per block; cap/ppm = 500/2 = 250
A3 -> A4 : expiry is in 250 blocks; wants 4ppm per block

In each case, the commitment tx would look like:

$1000 HTLC paying Y refunding to X
$0.50 liquidity fee bonus to X's balance (500ppm cap)

> - They’re not large enough to be enforceable, so somebody always has
> to give the money back off chain.

If the cap is 500ppm per block, then the liquidity fees for a 2000sat
payment ($0.60) are redeemable onchain.

> - Does everybody feel resolved on the statement that we need to take this
> hybrid approach to clamp down on jamming? Are there any “what about
> solution X” questions left for anyone? Nothing came up.

(Actually implementing the above is obviously a tonne of work --
in particular it requires every node in the route to support paying
liquidity fees eg -- assuming it doesn't turn out to be impossible, so
please don't take any of the above as an objection to using reputation
to reduce DoS vectors)

Cheers,
aj