t-bast / lightning-docs Goto Github PK

Hi @t-bast,

I am sure that your pages about lightning are a great learning resource for many lightning devs and enthusiats.
It would be great to see a document in this repo about mempool replacement cycling attacks that everyone got aware of now through this post, maybe in a similar fashion as you describe pinning attacks.

All the best.

I read the Spamming the Lightning Network and it's very well written, thanks for the summary!

But I have some confusions about the section on Bidirectional upfront payment. The design mentions that the time lock for Reverse upfront payment is in seconds (90 seconds, for example). This doesn't seem to be directly implementable in the blockchain script?

The implementation I have in mind is something like this: the time lock between A and B expires and A asks B to make a payment. If B chooses to refuse, A can't enforce it. But maybe A would deduct B's reputation or just choose to close the channel due to B's dishonest behaviour.

I'm curious if this is an accurate description, or is there a better implementation currently available?

Thank you!

I think a new dependency in the way routing nodes are accounting, advertising and verifying their fees must be underscored better before consider Bidirectional as "balance-safe" for intermediary hops.

Type 2 Loop Attacks are usually defined as long-held HTLCs by the final recipient or an intermediary hops thus freezing liquidity across all the links used by the payment path. This attack is made possible due to a fundamental building block of LN, a safety CLTV delta, deduced at each hop to allow in-order settlement of incoming/outgoing HTLCs. And thus avoiding a routing node to severe a balance disequilibrium across its relay links.

This liquidity timevalue is a resource like another and to prevent its abuse, its usage should be accounted as part of a relay cost structure. Along a payment-path, CLTV timelocks are higher on the topologically first links and thus routing fees required by those nodes will be higher.

Within context of Bidirectional, we should expect new hodl_fees to bind to the above routing fees computation, which may hinder a routing node's balance equilibrium.

E.g, with the following topology:

Alice ---> Bob ---> Caroll

Alice-Bob's HTLC nLocktime is superior to Bob-Caroll's one. H.a , "Alice's hodl_fee" required from Bob is superior to H.b "Bob's hodl_fee" required from Caroll.

Bob must correct this fee difference by a) advertise an unconditional fee F such as F - H.a > H.b and b) enforce that any payment routed through him commits to a F satisfying the equation.

It sounds like mitigating against Type 2 with Bidirectional will come with some change in the routing requirements. Routing fees for a given hop must integrate both incoming/outgoing channels' channel_update rather than only the incoming channel_update.

I don't see this as a blocker, but maybe a bit tricky to get it right.

The document here: https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md talks about a threat model but does not talk about the goal of the adversary specifically. Is the theory that sending spam HTLCs might be more profitable than just using the coins to create new valuable channels supported by any research?

This seems to be a crucial question and the document would benefit from at asking it or leaving it as an open question.

Thanks!

I was just catching up on this topic. Thanks for the write up. In it there is this paragraph:

This ensures that there are only two outputs that can be used for CPFP: the newly added anchors. One of them can be used by us, the other by the remote participant. This ensures that whatever a malicious participant may do to prevent the commitment transaction from confirming in time, the honest participant always has an opportunity to leverage the CPFP carve-out rule to bump the fee at least once.

Why would an honest participant "not always have an opportunity to leverage CPFP carve-out rule" if there are more than two outputs that don't have a CSV?

It's mentioned in the mailing list https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html but it isn't explicitly stated why this is true.

I am trying to understand why the order of elements in the scriptSig of the HTLC success transaction is the following(remotePub|localPub|preimage):

although the HTLC output locking script expects the order remotePub|preimage|localPub:

What am I missing?

from https://github.com/t-bast/lightning-docs/blob/master/taproot-updates.md:

claiming successful PTLCs from the remote peer's commitment now requires using RBF and sighash flags similar to anchor outputs HTLC transactions (sighash_single | sighash_anyonecanpay trick)

in the case where the funds from a ptlc success/timeout are not sent to the local delayed pubkey (claiming from the remote commitment), a sighash none | anyone can pay can be used on the adaptor, of course the local signature will use sighash all to prevent malleability
with this, all n ptlcs can be swept in one transaction with n inputs and 1 output

is this right or am i missing something?