t-bast / lightning-docs Goto Github PK
View Code? Open in Web Editor NEWSome in-depth articles about the Lightning Network
License: Apache License 2.0
Some in-depth articles about the Lightning Network
License: Apache License 2.0
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.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.