📅 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