[Lightning-dev] Setting to_self_delay and cltv_expiry prior to channel opening
Hi list With the current hullabaloo on default policy, custom policy rules on the base layer I started thinking about the process for negotiating configuration options for a channel open with a potential channel counterparty, what it currently is and what should optimally be part of the Lightning P2P protocol and what should be communicated out of band. I'm not familiar with the codebases of all the Lightning implementations so although I can scratch around and find out some of the answers myself I'm sure there are people on this list who are much better informed than I am. One particular area I'm interested in is the setting of timelocks [0] (to_self_delay, cltv_expiry) as defaults in Lightning implementations, the ability of Lightning node operators to change from those defaults and to what extent they can/should be able to negotiate on what these are prior to agreeing to open a channel together. My understanding with the setting of both of these timelocks is that it is a direct trade-off between giving you as a Lightning node operator as much time to respond to cheat attempts / untimely revealing of the HTLC prehash and risking your capital being locked up for longer when a channel counterparty or a participant in a route misbehaves. The higher the timelocks are the more "secure" it is but also the longer your capital will be locked up for in "unhappy" cases. When onchain fees are low no one really cares what these timelocks are and as long as the Lightning implementations set reasonable defaults Lightning node operators are happy to run them. But when onchain fees are higher and the ability to get a transaction confirmed onchain becomes more challenging/expensive these timelocks will be a lot more relevant. As a result this trade-off and the individual Lightning node operators' preferences will also be in greater focus. So a few questions (which are also covered in the linked StackExchange post [0]). What are the defaults for these timelocks today in all the Lightning implementations? How easy it is for Lightning node operators to change them? Is it possible (should it be possible?) for Lightning node operators to negotiate the setting of these timelocks prior to opening a channel? Or should this be done in out of band communication prior to agreeing to use the Lightning protocol to open a channel? If both potential channel counterparties have different preferences on setting these timelocks is it (should it?) be clear that the reason the potential channel counterparty rejected the channel open was because the preferred timelocks were slightly different? Thanks Michael [0]: https://bitcoin.stackexchange.com/questions/121673/what-are-the-default-timelocks-in-lightning-implementations-today-how-are-they -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Hi Peter Interesting post. By implicitly committing in advance to the fee paid by the spending transaction CTV is certainly nailing its colors to the CPFP mast rather than operating in a RBF world. And in a future high fee environment (ignoring whatever is driving those high fees, monetary or non-monetary use cases) as you state paying for an additional CPFP transaction is suboptimal rather than just replacing an existing unconfirmed transaction. I did a cursory search to look for an in depth technical comparison of CPFP and RBF and I found this from Antoine (Poinsot) on Bitcoin StackExchange [0]. In that he states his view that: "If most nodes didn't enforce mandatory BIP125 signalling, RBF would be superior in all aspects to CPFP from the perspective of the emitter of transaction. CPFP is much less efficient, and not always possible: you need the transaction to have a change output and (at least at the time of writing [0]) the parent to pass policy checks on its own, for instance if it's below the minimum feerate of most mempools on the network you won't be able to CPFP it at the moment." I assume that a CTV based LN-Symmetry also has this drawback when compared to an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry could change the fees in every channel update based on what the current market fee rate was at the time of the update. In today's pre LN-Symmetry world you are always going to have justice transactions for revoked states that were constructed when the market fee rate was very different from the present day's market fee rate. Thanks Michael [0]: https://bitcoin.stackexchange.com/questions/117703/comparison-between-cpfp-and-bip125-for-fee-bumping -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Wednesday, 24 January 2024 at 19:31, Peter Todd via bitcoin-dev wrote: > CheckTemplateVerify(1) is a proposed covenant opcode that commits to the > transaction that can spend an output. Namely, # of inputs, # of outputs, > outputs hash, etc. In practice, in many if not most CTV use-cases intended to > allow multiple parties to share a single UTXO, it is difficult to impossible > to > allow for sufficient CTV variants to cover all possible fee-rates. It is > expected that CTV would be usually used with anchor outputs to pay fees; by > creating an input of the correct size in a separate transaction and including > it in the CTV-committed transaction; or possibly, via a transaction sponsor > soft-fork. > > This poses a scalability problem: to be genuinely self-sovereign in a protocol > with reactive security, such as Lightning, you must be able to get > transactions > mined within certain deadlines. To do that, you must pay fees. All of the > intended exogenous fee-payment mechanisms for CTV require users to have at > least one UTXO of suitable size to pay for those fees. > > This requirement for all users to have a UTXO to pay fees negates the > efficiency of CTV-using UTXO sharing schemes, as in an effort to share a UTXO, > CTV requires each user to have an extra UTXO. The only realistic alternative > is > to use a third party to pay for the UTXO, eg via a LN payment, but at that > point it would be more efficient to pay an out-of-band mining fee. That of > course is highly undesirable from a mining centralization perspective.(2) > > Recommendations: CTV in its current form be abandoned as design foot-gun. > Other > convenant schemes should be designed to work well with replace-by-fee, to > avoid > requirements for extra UTXOs, and to maximize on-chain efficiency. > > 1) > https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6d7e7605/bip-0119.mediawiki > 2) > https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a-danger-to-mining-decentralization > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ > bitcoin-dev mailing list > bitcoin-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
From my perspective it really comes down to whether you want security *guarantees* or data to assist you in making probabilistic judgments about future behavior. Reputation data or reputation systems will never give you guarantees for the reasons Christian explains. But reputation data is better than nothing and depending on the quality and granularity of the data could be considerably better than nothing. In the most basic case of deciding on a potential channel counterparty I would much rather choose a counterparty who has demonstrated competence and reliability over a number of years than a channel counterparty who has just joined the network and who I know nothing about. Similarly a Lightning node that hasn't carried a jamming attack for multiple years despite having the opportunity to is a much better bet than a Lightning node of which I know nothing. Now where it sits on the software stack assuming a user opts into such a reputation "service" (plugin maybe or more likely an API) is I think what in essence this discussion is about. As I've already stated previously and which I agree with Christian on is that it isn't/shouldn't be a protocol or a P2P gossiping issue. In the same way as we have multiple Lightning explorers (1ML, Amboss etc) that aren't part of the Lightning protocol or part of the "core" of a Lightning node you can expect there would be competing reputation data providers and services. Also many users for privacy and/or other reasons won't be interested in using or participating in (to the extent they can opt out if the data is public) a reputation service. So yeah I think I'm somewhere in between Christian's and Antoine's perspectives here. I do think there are interesting projects, services or even businesses in this area of reputation but it isn't a protocol/P2P gossiping issue or a "core" of a Lightning node issue. Thanks Michael [0]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003766.html -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Wednesday, May 10th, 2023 at 12:57, Christian Decker wrote: > Hi Antoine, > > this is an intrinsic issue with reputation systems, and the main > reason I'm sceptical w.r.t. their usefulness in lightning. > Fundamentally any reputation system bases their expectations for the > future on experiences they made in the past, and they are thus always > susceptible to sudden behavioral changes (going rogue from a prior > clean record) and whitewashing attacks (switching identity, abusing > any builtin bootstrapping method for new users to gain a good or > neutral reputation before turning rogue repeatedly). > > This gets compounded as soon as we start gossiping about reputations, > since now our decisions are no longer based just on information we can > witness ourselves, or at least verify its correctness, and as such an > attacker can most likely "earn" a positive reputation in some other > part of the world, and then turn around and attack the nodes that > trusted the reputation shared from those other parts. > > I'd be very interested in how many repeat interactions nodes get from > individual senders, since that also tells us how much use we can get > out of local-only reputation based systems, and I wouldn't be > surprised if, for large routing nodes, we have sufficient data for > them to make an informed decision, while the edges may be more > vulnerable, but they'd also be used by way fewer senders, and the > impact of an attack would also be proportionally smaller. > > Cheers, > Christian > > On Mon, May 8, 2023 at 10:26 PM Antoine Riard antoine.ri...@gmail.com wrote: > > > Hi *, > > > > > Our suggestion is to start simple with a binary endorsement field. As > > > we learn more, we will be better equipped to understand whether a > > > more expressive value is required. > > > > I think the HTLC endorsement scheme as proposed is still suffering from a > > vulnerability as local reputation can be built up during periods of low > > routing fees, endorsement gained and then abused during periods of high > > routing fees. Therefore, it sounds to me this scheme should aim for some > > reputational transitivity between incoming traffic and outgoing traffic. > > Namely, the acquisition cost of the local reputation should be equal to the > > max timevalue damage that one can inflict on a routing node channel > > accessible from its local counterparty granting this high-level of > > reputation. > > > > I don't know if this can be fixed by ensuring permanent link-level "gossip" > > where counterparties along a payment path expose their reputation > > heuristics to guarantee this transitivity, or it's a fundamental issue with > > a point-to-point approach like HTLC endorsement. > > > > Opened an issue on the repository to
Re: [Lightning-dev] A Note on Public Communication
Perhaps we need another moderator or two for the lightning-dev mailing list? There are already a lot of emails on the bitcoin-dev mailing list and so despite my views on the trend of Bitcoin and Lightning discussion becoming increasingly intertwined it probably makes sense to keep both bitcoin-dev and lightning-dev lists and just bump the number of moderators on lightning-dev. Thanks Michael -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Monday, May 8th, 2023 at 22:07, Vincenzo Palazzo wrote: > > Is there a better place to have public communication? Unfortunately since > > one off topic email was sent here, it's been a ghost town. It appears that > > there's many emails being held and only one moderator that checks them once > > a week. > > > > Would hate to see this list die but wondering if there's a better place for > > discussions? > > > I think currently the list is the most accessible way that we have. > > I am not aware of any other tools that are as accessible as the list archive > to search for some history, and also to allow people in 10 years from now to > implement some of the ideas proposed these days. > > But I would agree to change communication tools if we do not lose these > two properties. > > Cheers. > > Vincent. > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning
Hi Kostas > Could you please point me to a resource that describes the default policy > changes (that are happening for lightning)? I have seen discussions here and > there but it would help if they are aggregated somewhere for reviewing. It is hard to follow because most of the discussions aren't on public channels, a number of the devs working on these proposed default policy changes aren't taking the BIP process seriously and no one is willing to discuss the criteria for merging default policy changes (and consensus changes for that matter) into bitcoin-inquisition (default signet). In addition the work (to the extent that it is public) is scattered all over the place. So yeah it seems like a mess to me from the perspective of someone is seeking to follow, review and monitor it. This Bitcoin StackExchange post [0] is my first attempt to do what you're looking for and these Bitcoin Core PR review clubs [1], [2] were really good from Gloria. But yeah the BIP process (as I've said a thousand times and been ignored) is the place to hammer out specifications for complex things like default policy proposals and when people don't care about formalizing specifications it becomes very hard for people like you and me to follow. > Separation of concerns always makes sense to manage complexity. One would > need to have really strong incentives to counter the complexity argument. >> I might be missing some context here but what would the actual benefit of >> integrating them be? Not having to install lightning node separately and >> maybe a more intuitive UX? As I say in the original email having two separate P2P networks and two separate P2P protocols (perhaps) doesn't make much sense if all (or most of the nodes) are both full nodes and Lightning nodes. A testing framework that integrates both base layer and Lightning tests could potentially be easier to track edge cases which fall in the grey area between base layer and Lightning but are critically important for Lightning. A Core wallet that doesn't support Lightning doesn't make much sense in a world where transaction fees are really high and you have to use Lightning unless you are transferring huge amounts. I agree with you that these arguments have to be strong to counter the separation of concerns angle and maybe it is too early to consider it. But if moving in the direction of more widely used consensus compatible forks of Core then having Lightning integrated could make it an attractive option. > PS. Besides, the amount of effort would be significant. Wouldn't that effort > be better spent on, say, separating the consensus logic (i.e. a second > libbitcoinkernel attempt)? libbitcoinkernel can achieve smaller (and still important) goals but I'm skeptical that the more ambitious goal of having lots of different implementations in different languages with libbitcoinkernel at its core and not having to worry about consensus bugs will be reached in the medium term. As we saw with the recent btcd/lnd bugs [3] consensus bugs can crop up in places you might not expect. In that case it was a wire parsing library that you wouldn't expect to be part of a libbitcoinkernel. So if you're still going to encounter consensus bugs outside of libbitcoinkernel there isn't much point (in my view) in using it for alternative implementations. Thanks Michael [0]: https://bitcoin.stackexchange.com/questions/117315/what-and-where-are-the-current-status-of-the-bip-125-replacement-the-v3-policy [1]: https://bitcoincore.reviews/25038 [2]: https://bitcoincore.reviews/25038-2 [3]: https://bitcoin.stackexchange.com/questions/115527/what-is-the-october-2022-bug-in-lnd-what-caused-it-and-what-would-prevent-a-sim -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Wednesday, April 19th, 2023 at 10:05, Kostas Karasavvas wrote: > Hi Michael, > > On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson via bitcoin-dev > wrote: > >> Any thoughts on this from the Core Lightning contributors? The way I see it >> with upcoming proposed changes to default policy (primarily though not >> exclusively for Lightning) and a soft fork activation attempt of APO/APOAS >> (primarily though not > > Could you please point me to a resource that describes the default policy > changes (that are happening for lightning)? I have seen discussions here and > there but it would help if they are aggregated somewhere for reviewing. > >> exclusively for Lightning) that a tighter coupling between the full node and >> the Lightning node could eventually make sense. In a world where transaction >> fees were much higher you'd think almost every full node would also want to >> be a Lightning node and so the separation of concerns would make less sense. > > Separation of concerns always makes sense to manage complexity. One
Re: [Lightning-dev] A new Bitcoin implementation integrated with Core Lightning
Any thoughts on this from the Core Lightning contributors? The way I see it with upcoming proposed changes to default policy (primarily though not exclusively for Lightning) and a soft fork activation attempt of APO/APOAS (primarily though not exclusively for Lightning) that a tighter coupling between the full node and the Lightning node could eventually make sense. In a world where transaction fees were much higher you'd think almost every full node would also want to be a Lightning node and so the separation of concerns would make less sense. Having two separate P2P networks and two separate P2P protocols also wouldn't make much sense in this scenario. You could obviously still opt out of Lightning P2P messages if you weren't interested in Lightning. The alternative would be just to focus on Knots style consensus compatible forks of Core with limited additional functionality. But I think we've reached the point of no return on Core dominance and not having widely used "distros". As the ecosystem scales systems and processes should be constantly evolving and improving and to me if anything Core's seem to be going backwards. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, January 14th, 2023 at 20:26, Michael Folkson wrote: > I tweeted this [0] back in November 2022. > > "With the btcd bugs and the analysis paralysis on a RBF policy option in Core > increasingly thinking @BitcoinKnots and consensus compatible forks of Core > are the future. Gonna chalk that one up to another thing @LukeDashjr was > right about all along." > > A new bare bones Knots style Bitcoin implementation (in C++/C) integrated > with Core Lightning was a long term idea I had (and presumably many others > have had) but the dysfunction on the Bitcoin Core project this week (if > anything it has been getting worse over time, not better) has made me start > to take the idea more seriously. It is clear to me that the current way the > Bitcoin Core project is being managed is not how I would like an open source > project to be managed. Very little discussion is public anymore and decisions > seem to be increasingly made behind closed doors or in private IRC channels > (to the extent that decisions are made at all). Core Lightning seems to have > the opposite problem. It is managed effectively in the open (admittedly with > fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin > Core does. Regardless, selfishly I at some point would like a bare bones > Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin > Core codebase has collected a lot of cruft over time and the ultra > conservatism that is needed when treating (potential) consensus code seems to > permeate into parts of the codebase that no one is using, definitely isn't > consensus code and should probably just be removed. > > The libbitcoinkernel project was (is?) an attempt to extract the consensus > engine out of Core but it seems like it won't achieve that as consensus is > just too slippery a concept and Knots style consensus compatible codebase > forks of Bitcoin Core seem to still the model. To what extent you can safely > chop off this cruft and effectively maintain this less crufty fork of Bitcoin > Core also isn't clear to me yet. > > Then there is the question of whether it makes sense to mix C and C++ code > that people have different views on. C++ is obviously a superset of C but > assuming this merging of Bitcoin Core and Core Lightning is/was the optimal > final destination it surely would have been better if Core Lightning was > written in the same language (i.e. with classes) as Bitcoin Core. > > I'm just floating the idea to (hopefully) hear from people who are much more > familiar with the entirety of the Bitcoin Core and Core Lightning codebases. > It would be an ambitious long term project but it would be nice to focus on > some ambitious project(s) (even if just conceptually) for a while given > (thankfully) there seems to be a lull in soft fork activation chaos. > > Thanks > Michael > > [0]: > https://twitter.com/michaelfolkson/status/1589220155006910464?s=20=GbPm7w5BqS7rS3kiVFTNcw > > -- > Michael Folkson > Email: michaelfolkson at [protonmail.com](http://protonmail.com/) > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A new Bitcoin implementation integrated with Core Lightning
I saw it was announced, yes. The author is brilliant, he has now managed two alternative implementations of Core in two different languages :) The problem though and why I and many others think the Knots style fork of Core is the better option is because you avoid reimplementing consensus code in a different language. If you're ultra conservative about consensus code you either want to run Core in parallel with your alternative implementation to check they don't go out of consensus or you want to run the same consensus code as Core in a Knots like fork. Hence a Knots like fork of Core in C++ integrated with Core Lightning in C seems like the better option to me for serious running in production like use cases. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, January 14th, 2023 at 20:34, Fabian wrote: > Hi Michael, > > have you seen Mako? It might at least be a good start for what you would like > to achieve: https://github.com/chjj/mako > > Best, > Fabian > --- Original Message --- > On Saturday, January 14th, 2023 at 9:26 PM, Michael Folkson via Lightning-dev > wrote: > >> I tweeted this [0] back in November 2022. >> >> "With the btcd bugs and the analysis paralysis on a RBF policy option in >> Core increasingly thinking @BitcoinKnots and consensus compatible forks of >> Core are the future. Gonna chalk that one up to another thing @LukeDashjr >> was right about all along." >> >> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated >> with Core Lightning was a long term idea I had (and presumably many others >> have had) but the dysfunction on the Bitcoin Core project this week (if >> anything it has been getting worse over time, not better) has made me start >> to take the idea more seriously. It is clear to me that the current way the >> Bitcoin Core project is being managed is not how I would like an open source >> project to be managed. Very little discussion is public anymore and >> decisions seem to be increasingly made behind closed doors or in private IRC >> channels (to the extent that decisions are made at all). Core Lightning >> seems to have the opposite problem. It is managed effectively in the open >> (admittedly with fewer contributors) but doesn't have the eyeballs or the >> usage that Bitcoin Core does. Regardless, selfishly I at some point would >> like a bare bones Bitcoin and Lightning implementation integrated in one >> codebase. The Bitcoin Core codebase has collected a lot of cruft over time >> and the ultra conservatism that is needed when treating (potential) >> consensus code seems to permeate into parts of the codebase that no one is >> using, definitely isn't consensus code and should probably just be removed. >> >> The libbitcoinkernel project was (is?) an attempt to extract the consensus >> engine out of Core but it seems like it won't achieve that as consensus is >> just too slippery a concept and Knots style consensus compatible codebase >> forks of Bitcoin Core seem to still the model. To what extent you can safely >> chop off this cruft and effectively maintain this less crufty fork of >> Bitcoin Core also isn't clear to me yet. >> >> Then there is the question of whether it makes sense to mix C and C++ code >> that people have different views on. C++ is obviously a superset of C but >> assuming this merging of Bitcoin Core and Core Lightning is/was the optimal >> final destination it surely would have been better if Core Lightning was >> written in the same language (i.e. with classes) as Bitcoin Core. >> >> I'm just floating the idea to (hopefully) hear from people who are much more >> familiar with the entirety of the Bitcoin Core and Core Lightning codebases. >> It would be an ambitious long term project but it would be nice to focus on >> some ambitious project(s) (even if just conceptually) for a while given >> (thankfully) there seems to be a lull in soft fork activation chaos. >> >> Thanks >> Michael >> >> [0]: >> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20=GbPm7w5BqS7rS3kiVFTNcw >> >> -- >> Michael Folkson >> Email: michaelfolkson at [protonmail.com](http://protonmail.com/) >> Keybase: michaelfolkson >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] A new Bitcoin implementation integrated with Core Lightning
I tweeted this [0] back in November 2022. "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along." A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed. The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet. Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core. I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos. Thanks Michael [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20=GbPm7w5BqS7rS3kiVFTNcw -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Unjamming lightning (new research paper)
> I don't think so - today there are at least three different routing goals to > maximize - (a) privacy, > (b) fees, (c) success rate. For "live" payment, you probably want to lean > towards optimizing for > success rate, and many nodes do today by default. But that isn't the full > story - many nodes do > background rebalancing and they prefer to take paths which optimize for fees, > trying many paths they > think are likely to fail to see if they can rebalance with lower fees. I > don't think we should tell > those users/use-cases that they aren't allowed to do that or they're doing > something "wrong" - I > think choosing to optimize for fees (or, in the future, privacy) is an > important thing to allow, and > ideally make as reliable as possible, without charging extra for it. Right, the trade-offs here are really tricky to navigate and to whatever extent this is possible the choice of what trade-offs to make should be pushed to the user. For example, not knowing the real time channel balances clearly hurts routing success. If this degraded routing success from 95 percent to say 90 percent the network as a whole would probably be willing to pay that routing success "cost" to ensure better balance privacy. But if it degraded routing success from 95 percent to say 50 percent I expect much of the network wouldn't be willing to put up with that terrible routing success percentage and routing nodes would probably seek to broadcast their channel balances either in gossip or out of band. Similarly a routing node not knowing the source of the payment and the intermediate nodes on the route is fine (it is clearly *much* better for privacy) assuming jamming attacks occur rarely. But if the network is being paralyzed regularly by jamming attacks a routing node is going to show a lot more interest in which Lightning node it is routing payments for and which other Lightning nodes are also part of the route. You aren't going to want to continue to be subject to jamming attacks by the same Lightning node. Hence I stick by this from a protocol developer perspective. "Decisions protocol developers make will impact what data can be collected and how easy that data is to collect (there are already some tricky trade-offs with regards to privacy, routing success and transparency for when things go wrong) but beyond that protocol developers should leave it to others." A protocol developer (and individual implementation developer I guess) is going to have to wrestle with these trade-offs and to what extent options can be pushed to the user. But protocol reputation tokens that can be sold or transferred to an attacker or worse collected through gaming the system, ouch. The protocol developer has taken a problem (jamming attacks) that already exists and added an additional problem (reputation) which no doubt will be addressed by adding an additional problem on top of that and another on top of that etc etc. -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, December 4th, 2022 at 02:03, Matt Corallo wrote: > > On 11/15/22 12:09 PM, Clara Shikhelman wrote: > > > Matt – I don't know that I agree with "... upfront payments kinda kill the > > lightning UX ...". I > > think that upfront fees are almost essential, even outside the context of > > jamming. This also helps > > with probing, general spam, and other aspects. Furthermore, I think that > > the UX is very explainable, > > > Indeed, it may be explainable, but its still somewhat painful, I think. I do > wonder if we can enable > probing via a non-HTLC message and do immediate pre-send-probing to avoid > paying upfront fees on > paths that will fail. > > > and in general nodes shouldn't be motivated to send a lot of failed > > payments, and should adopt > > better routing strategies. > > > I don't think so - today there are at least three different routing goals to > maximize - (a) privacy, > (b) fees, (c) success rate. For "live" payment, you probably want to lean > towards optimizing for > success rate, and many nodes do today by default. But that isn't the full > story - many nodes do > background rebalancing and they prefer to take paths which optimize for fees, > trying many paths they > think are likely to fail to see if they can rebalance with lower fees. I > don't think we should tell > those users/use-cases that they aren't allowed to do that or they're doing > something "wrong" - I > think choosing to optimize for fees (or, in the future, privacy) is an > important thing to allow, and > ideally make as reliable as possible, without charging extra for it. > > Matt > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch
> Therefore, in case of loopholes in the system damages are effectively borne > by the routing hops, without throwing the whole system down. I'm not sure why harming routing nodes is any less of a concern than harming the experience of say edge nodes when introducing game-able systems with uncertainty over the edge cases. Especially when iteration of that system might never lead to a solution we are happy with. A whack-a-mole type thing where plugging one hole creates another hole. > On the second point, we already have today's reputation systems in Lightning, > namely the routing algorithms keeping track of the performance of the routing > hops, and their liquidity. I was under the impression that routing algorithms weren't part of the Lightning protocol spec (BOLTs)? Each Lightning implementation could ship with totally different default routing algorithms (perhaps already do?) and it wouldn't matter. There is no cross implementation compatibility issue with how each Lightning node selects channel counterparties, how it selects routes for payments and tracks which routes did and didn't work. > On the third point, the protocol defer to the node operators all the > decisions on the credential acquisition costs, expiration height, binding > with liquidity units, or even allow additional routing policy checks. I guess we're back into the world of setting defaults and options here that we've just been through with mempoolfullrbf :) If say a LDK user wants to opt into using this reputation system then that's their prerogative assuming it is merged into say a LDK release. Personally I would want to opt out of this reputation system and do my own assessments of reputations of Lightning nodes and risks I was taking. At least until a point when I was comfortable with it which I may never be. > I hope you'll take time to browse the proposal as detailed more in depth > here:https://github.com/lightning/bolts/pull/1043 Sure I'll take a look. But recall I am worried about edge cases and ways for an attacker to game a reputation system which requires me to get to your level of understanding of channel jamming attacks (which will take me a while given you've written a book [0] about them with Gleb). And I suspect even you and Gleb wouldn't be confident saying that you understand all the edge cases of jamming attacks let alone the edge cases of gaming a reputation layer on top. As I said in my previous post I think this is an interesting area and I can see why you are exploring reputation. Just very skeptical that this is a thing that is ever part of the protocol, is used by all of the major Lightning implementations, is on by default in all those Lightning implementations etc. And even if it was I would want to opt out of it. Thanks Michael [0]: https://jamming-dev.github.io/book/ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Monday, November 28th, 2022 at 23:34, Antoine Riard wrote: > Hi Michael, > > Thanks for the feedback, > > On the first point, I think it should be underscored how much this proposed > credential system, while labeled a reputational one, belongs more to a > monetary strategy (after the fact should be called "staking" credentials). > Indeed, there is a direct link between the credentials and a cost expressed > in satoshis. Therefore, in case of loopholes in the system damages are > effectively borne by the routing hops, without throwing the whole system > down. Note, the default policy should be some 0-risk HTLC forward acceptance. > > On the second point, we already have today's reputation systems in Lightning, > namely the routing algorithms keeping track of the performance of the routing > hops, and their liquidity. That information is used in a continuous fashion > to improve payment-path building. And while those algorithms are doing > probabilistic estimation of the balance distribution, the proposed credential > system is not all relying on past statistics for its effectiveness (as long > as the node operators are requiring credentials of worthiness equivalent to > routing fees). > > On the third point, the protocol defer to the node operators all the > decisions on the credential acquisition costs, expiration height, binding > with liquidity units, or even allow additional routing policy checks. > Flexibility is offered to the node operators, without the protocol developers > trying to do any "centralized" decision on the cost of the credentials or > whatever. > > From my understanding, the critics you're raising, while potentially correct > for the reputation systems links you're including, does not bind to any > concrete point of my proposal. I hope you'll take time to browse the proposal > as detailed more in depth here: https://github.com/lightning/bolts/pull/1043 > >
Re: [Lightning-dev] Mitigating Channel Jamming with Reputation Credentials: a Protocol Sketch
Hi Antoine I've got a lot to catch up on re channel jamming but just to say I'm deeply skeptical about attempting to embed a reputation layer or reputation credentials into the Lightning protocol. Admittedly I'm somewhat of a curious amateur in the field of reputation systems but a number of people (me included) have had to look into reputation systems in the past for projects/startups they were working on and centralized reputation systems are absolute minefields to manage effectively though some corporations do manage it. Decentralized reputation systems baked into a protocol is just a step too far. All you need is one edge case where the attacker can ensure an innocent party is blamed and the reputation system falls apart. The protocol developer is in the position of assessing who is telling the truth out of two opposing viewpoints on Reddit etc. I do think reputation systems will play a key part in a future Lightning Network (to some extent they already are with sites like 1ML and Amboss) but they won't be managed by protocol devs, they will be managed by multiple flavors of companies and projects (hopefully open source but most likely closed source too, for profit, non-profit etc) who are free to use whatever metrics and weigh those metrics however they like. The protocol just can't afford to expand into areas where there is case by case judgment and statistical analysis required. It will become bloated, ineffective and put protocol developers in the position of deciding who ultimately receives routing fees rather than just enabling payments can get from A to B. Identity is easier, you either control a private key or you don't. Reputation is much more difficult, there will be some attacks where a probabilistic assessment will need to be made on who the perpetrator of the attack was. You don't add that to the (already long) list of protocol developers' responsibilities. So feel free to continue to explore reputation and reputation systems but a strong warning that this is likely not solved at the protocol level. Decisions protocol developers make will impact what data can be collected and how easy that data is to collect (there are already some tricky trade-offs with regards to privacy, routing success and transparency for when things go wrong) but beyond that protocol developers should leave it to others. I've included some links to some additional reading on reputation systems in case you are interested. Thanks Michael [0]: https://www.amazon.com/Building-Reputation-Systems-Randy-Farmer/dp/059615979X/ [1]: https://medium.com/openbazaarproject/decentralized-reputation-in-openbazaar-1a577fac5175 [2]: https://www.bitrated.com/faq -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Monday, November 21st, 2022 at 06:01, Antoine Riard wrote: > Hi LN Devs, > > tl;dr A formalization of a reputation-based scheme to solve channel jamming > is proposed. The system relies on "credentials" issued by routing hops and > requested to be attached to each HTLC forward request. The "credentials" can > be used by a reputation algorithm to reward/punish payment senders and > allocate channel liquidity resources efficiently. The "credentials" initial > distribution can be bootstrapped leveraging one-time upfront fees paid toward > the routing hops. Afterwards, the "credentials" subsequent distribution can > rely on previous HTLC traffic. > > A protocol description can be found here, with few extensions already to the > BOLTs: > > https://github.com/lightning/bolts/pull/1043 > > There is also a work-in-progress proof-of-concept in LDK (on top of our > coming soon^TM HTLC intercepting API): > > https://github.com/lightningdevkit/rust-lightning/pull/1848 > > This work builds on previous reputation-scheme research [0] [1]. It also > integrates the more recent proposals of upfront fees as a straightforward > mechanism to bootstrap the reputation system. Bootstrapping the system with > more economically cost-effective privacy-preserving UTXO ownership proofs not > only add another layer of engineering complexity, there is still a proof size > vs proof generation/validation trade-off to arbiter between ZKP cryptosystems. > > Rather to seek for a game-theory equilibrium defined as a breakeven point as > in the latest unconditional fee research [2], this proposal aims to use > reputation credentials to allow HTLC traffic-shaping. This not only should > protect against jamming situations (either malicious > or spontaneous) but also allow active HTLC traffic-shaping, where a routing > hop can allow extended channel liquidity lockups based on accumulated > reputation (e.g for hold-invoices). This is also a reduced overhead cost, as > upfront fees are only paid at bootstrap, or when the HTLC forward behavior > can be
Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation
Awesome, thanks Alex. Just one follow up. > Running the numbers, I currently see 15,761 public nodes on the network and > 148,295 half channels. Those each need refreshed gossip every two weeks. By > default that would result in 90% channel updates. And the rationale for each channel needing refreshed gossip every 2 weeks is to inform the network that the channel is still active (i.e. not disabled) and its parameters haven't changed? (I did look it up in BOLT 7 [0] but it wasn't clear to me that a channel would be assumed to be inactive/disabled if there wasn't a channel_update for 2 weeks.) That seems a lot of gossip to me if the recommended behavior of routing nodes is to maintain ~100 percent uptime and only when absolutely necessary change the parameters of the channel. I guess the alternative of significantly less gossip messages and a potential uptick in failed routes would be worse though. [0]: https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#rationale-4 -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Wednesday, June 29th, 2022 at 7:07 PM, Alex Myers wrote: > Hi Michael, > > Thanks for the transcript and the questions, especially those you asked in > Gleb's original Erlay presentation. > > I tried to cover a lot of ground in only 30 minutes and the finer points may > have suffered. The most significant difference in concern between bitcoin > transaction relay and lightning gossip may be one of privacy: Source nodes of > Bitcoin transactions have an interest in privacy (avoid trivially > triangulating the source.) Lightning gossip is already signed by and linked > to a node ID - the source is completely transparent by nature. The lack of a > timing concern would allow for a global sketch where it would have been > infeasible for Erlay (among other reasons such as DoS.) > >> Why are hash collisions a concern for Lightning gossip and not for Erlay? Is >> it not a DoS vector for both? > > If lightning gossip were encoded for minisketch entries with the > short_channel_id, it would create a unique fingerprint by default thanks to > referencing the unique funding transaction on chain - no hashing required. > This was Rusty's original concept and what I had been proceeding with. > However, given the ongoing privacy discussion and desire to eventually > decouple lightning channels from their layer one funding transaction (gossip > v2), I think we should prepare for a future in which channels are not > explicitly linked to a SCID. That means hashing just as in Erlay and the same > DoS vector would be present. Salting with a per-peer shared secret works > here, but the solution is driven back toward inventory sets. > >> It seems you are leaning towards per-peer sketches with inventory sets (like >> Erlay) rather than global sketches. > > > Yes. There are pros and cons to each method, but most critically, this would > be compatible with eventual removal of the SCID. > >> Erlay falls back to flooding if the set reconciliation algorithm doesn't >> work which I'm assuming you'll do with Lightning gossip. > > Fallback will take some consideration (Erlay's bisect is an elegant feature), > but yes, flooding is still the ultimate fallback. > >> I was also surprised to hear that channel_update made up 97 percent of >> gossip messages. Isn't it recommended that you don't make too changes to >> your channel as it is likely to result in failed routed payments and being >> dropped as a routing node for future payments? It seems that this advice >> isn't being followed if there are so many channel_update messages being sent >> around. I almost wonder if Lightning implementations should include user >> prompts like "Are you sure you want to update your channel given this may >> affect your routing success?" :) > > Running the numbers, I currently see 15,761 public nodes on the network and > 148,295 half channels. Those each need refreshed gossip every two weeks. By > default that would result in 90% channel updates. That we're seeing roughly > three times as many channel updates vs node announcements compared to what's > strictly required is maybe not that surprising. I agree, there would be a > benefit to nodes taking a more active role in tracking calls to broadcast > gossip. > > Thanks, > Alex > > --- Original Message --- > On Wednesday, June 29th, 2022 at 6:09 AM, Michael Folkson > wrote: > >> Thanks for this Alex. >> >> Here's a transcript of your recent presentation at Bitcoin++ on Minisketch >> and Lightning gossip: >> >> https://btctranscripts.com/bitcoinplusplus/2022/2022-06-07-alex-myers-minisketch-lightning-gossip/ >> >> Having followed Gleb's work on using Minisketch for Erlay in Bitcoin Core >> [0] for a while now I was especially interested in how the challenges of >>
Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation
Thanks for this Alex. Here's a transcript of your recent presentation at Bitcoin++ on Minisketch and Lightning gossip: https://btctranscripts.com/bitcoinplusplus/2022/2022-06-07-alex-myers-minisketch-lightning-gossip/ Having followed Gleb's work on using Minisketch for Erlay in Bitcoin Core [0] for a while now I was especially interested in how the challenges of using Minisketch for Lightning gossip (node_announcement, channel_announcement, channel_update messages) would differ to the challenges of using Minisketch for transaction relay on the base layer. I guess one of the major differences is full nodes are trying to verify a block every 10 minutes (on average) and so there is a sense of urgency to get the transactions of the next block to be mined. With Lightning gossip unless you are planning to send a payment (or route a payment) across a certain route you are less concerned about learning about the current state of the network urgently. If a new channel pops up you might choose not to route through it regardless given its "newness" and its lack of track record of successfully routing payments. There are parts of the network you care less about (if they can't help you get to your regular destinations say) whereas with transaction relay you have to care about all transactions (paying a sufficient fee rate). "The problem that Bitcoin faced with transaction relay was pretty similar but there are a few differences.For one, any time you introduce that short hash function that produces a 64 bit fingerprint you have to be concerned with collisions between hash functions. Someone could potentially take advantage of that and grind out a hash that would resolve to the same fingerprint." Could you elaborate on this? Why are hash collisions a concern for Lightning gossip and not for Erlay? Is it not a DoS vector for both? It seems you are leaning towards per-peer sketches with inventory sets (like Erlay) rather than global sketches. This makes sense to me and seems to be moving in a direction where your peer connections are more stable as you are storing data on what your peer's understanding of the network is. There could even be centralized APIs which allow you to compare your current understanding of the network to the centralized service's understanding. (Of course we don't want to have to rely on centralized services or bake them into the protocol if you don't want to use them.) Erlay falls back to flooding if the set reconciliation algorithm doesn't work which I'm assuming you'll do with Lightning gossip. I was also surprised to hear that channel_update made up 97 percent of gossip messages. Isn't it recommended that you don't make too changes to your channel as it is likely to result in failed routed payments and being dropped as a routing node for future payments? It seems that this advice isn't being followed if there are so many channel_update messages being sent around. I almost wonder if Lightning implementations should include user prompts like "Are you sure you want to update your channel given this may affect your routing success?" :) Thanks Michael P.S. Are we referring to "routing nodes" as "forwarding nodes" now? I've noticed "forwarding nodes" being used more recently on this list. [0]: https://github.com/bitcoin/bitcoin/pull/21515 -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Thursday, April 14th, 2022 at 22:00, Alex Myers wrote: > Hello lightning developers, > > I’ve been investigating set reconciliation as a means to reduce bandwidth and > redundancy of gossip message propagation. This builds on some earlier work > from Rusty using the minisketch library [1]. The idea is that each node will > build a sketch representing it’s own gossip set. Alice’s node will encode and > transmit this sketch to Bob’s node, where it will be merged with his own > sketch, and the differences produced. These differences should ideally be > exactly the latest missing gossip of both nodes. Due to size constraints, the > set differences will necessarily be encoded, but Bob’s node will be able to > identify which gossip Alice is missing, and may then transmit exactly those > messages. > > This process is relatively straightforward, with the caveat that the sets > must otherwise match very closely (each sketch has a maximum capacity for > differences.) The difficulty here is that each node and lightning > implementation may have its own rules for gossip acceptance and propagation. > Depending on their gossip partners, not all gossip may propagate to the > entire network. > > Core-lightning implements rate limiting for incoming channel updates and node > announcements. The default rate limit is 1 per day, with a burst of 4. I > analyzed my node’s gossip over a 14 day period, and found that, of all >
Re: [Lightning-dev] Three Strategies for Lightning Forwarding Nodes
Hey ZmnSCPxj It is an interesting topic. Alex Bosworth did a presentation at the Lightning Hack Day last year with a similar attempt at categorizing the different strategies for a routing/forwarding node (Ping Pong, Liquidity Battery, Inbound Sourcing, Liquidity Trader, Last Mile, Swap etc) https://btctranscripts.com/lightning-hack-day/2021-03-27-alex-bosworth-lightning-routing/ It seems like your attempt is a little more granular and unstructured (based on individual responses) but perhaps it fits into the broad categories Alex suggested maybe with some additional ones? Thanks Michael -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Tuesday, June 28th, 2022 at 03:34, ZmnSCPxj via Lightning-dev wrote: > Good morning list, > > This is a short (relative to my typical crap) writeup on some strategies that > Lightning forwarding nodes might utilize. > > I have been thinking of various strategies that actual node operators (as I > understood from discussing with a few of them) use: > > * Passive rebalance / feerate by balance > * Set feerates according to balance: increase feerates when our side has low > balance, reduce feerates when our side has high balance. > * "passive rebalance" because we are basically encouraging payments via our > channel if the balance is in our favor, and discouraging payments if the > balance is against us, thus typical payments will "normally" rebalance our > node naturally without us spending anything. > * Low fee > * Just fix the fee to a low fee, e.g. base 1 proportional 1 or even the > @zerofeerouting guy of base 0 proportional 0. > * Ridiculously simple, no active management, no scripts, no nothing. > * Wall > * Set to a constant (or mostly constant) high feerate. > * Actively rebalance, targeting low-fee routes (i.e. less than our earnings), > and constantly probe the network for the rare low-fee routes that we can use > to rebalance. > * Basically, buy cheap liquidity and resell it at higher prices. > > > The interesting thing is how the three interact. > > Suppose we have a mixed network composed ONLY of passive rebalancers and > walls. > In that case, the passive rebalancers might occasionally set channels to low > fees, in which case the walls buy up their liquidity, but eventually the > liquidity of the passive rebalancer is purchased and the passive rebalancer > raises their price point. > The network then settles with every forwarding node having roughly equal > balance on their channels, but note that it was the walls who paid to the > passive rebalancers to get the channels into a nice balance. > In particular, if there were only a single wall node, it can stop rebalancing > once the price to rebalance costs more than 49% of its earnings, so it paid > 49% of its earnings to the passive rebalancers and keeps 51% of its earnings, > thus earning more than the passive rebalancers earn. > However, once multiple wall nodes exist, they will start bidding for the > available liquidity from the passive rebalancers and the may find it > difficult to compete once the passive rebalancers set their feerates to more > than 50% of the wall feerate, at which point the passive rebalancers now end > up earning more than the wall nodes (because the wall nodes now pay more to > the passive rebalancers than what they keep). > > Thus, it seems to me that passive rebalancers would outcompete wall > strategies, if they were the only strategies on the network. > > However, the network as-is contains a LOT of tiny nodes with low feerates. > > In such an environment, walls can pick up liquidity for really, really cheap, > leaving the low-feerate nodes with no liquidity in the correct direction. > And thus, it seems plausible that they can resell the liquidity later at much > higher feerates, possibly outcompeting the passive rebalancers. > > Unfortunately: > > * Low feerate nodes are notoriously unreliable for payments; their channels > are usually saturated in one side or another. since walls keep taking their > liquidity. > * Because of this known unreliability, some payer strategies filter them out > via some heuristics (e.g. payment unreliability information). > Thus, even in the rare case where payment flows change on the network, they > are not used by payers --- instead, walls exploit them since walls do not > care if rebalancing fails, they will always just retry later. > * One argument FOR using low-feerate nodes is that it "supports the network". > * However, it seems to me that the low-feerate nodes are actually being > exploited by the wall nodes instead, and the low-feerate nodes have too > little payment reliability to actually support payers instead of large-scale > forwarders. > * Both low-feerates and walls do not leak their channel balances, whereas > passive rebalancers do leak their channel balance.
Re: [Lightning-dev] LN Summit 2022 Notes & Summary/Commentary
Thanks for the summary Laolu, very informative. > One other cool topic that came up is the concept of leveraging recursive > musig2 (so musig2 within musig2) to make channels even _more_ multi-sigy. A minor point but terminology can get frustratingly sticky if it isn't agreed on early. Can we refer to it as nested MuSig2 going forward rather than recursive MuSig2? It is a more accurate description in my opinion and going through some old transcripts the MuSig2 authors [0] also refer it to nested MuSig2 (as far as I can make out). Rene Pickhardt brought up the issue of latency with regards to nested/recursive MuSig2 (or nested FROST for threshold) on Bitcoin StackExchange [1]. Was this discussed at the LN Summit? I don't know how all the Lightning implementations treat latency currently (how long a channel counterparty has to provide a needed signature before moving to a unhappy path) but Rene's concern is delays in the regular completions of a nested MuSig2 or FROST scheme could make them unviable for the Lightning channel use case depending on the exact setup and physical location of signers etc. MuSig2 obviously generates an aggregated Schnorr signature and so even nested MuSig2 require the Lightning protocol to recognize and verify Schnorr signatures which it currently doesn't right? So is the current thinking that Schnorr signatures will be supported first with a Schnorr 2-of-2 on the funding output (using OP_CHECKSIGADD and enabling the nested schemes) before potentially supporting non-nested MuSig2 between the channel counterparties on the funding output later? Or is this still in the process of being discussed? [0]: https://btctranscripts.com/london-bitcoin-devs/2020-06-17-tim-ruffing-schnorr-multisig/ [1]: https://bitcoin.stackexchange.com/questions/114159/how-do-the-various-lightning-implementations-treat-latency-how-long-do-they-wai -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Wednesday, June 8th, 2022 at 03:38, Olaoluwa Osuntokun wrote: > Hi y'all, > > Last week nearly 30 (!) Lightning developers and researchers gathered in > Oakland, California for three day to discuss a number of matters related to > the current state and evolution of the protocol. This time around, we had > much better representation for all the major Lightning Node implementations > compared to the last LN Dev Summit (Zurich, Oct 2021). > > Similar to the prior LN Dev Summit, notes were kept throughout the day that > attempted on a best effort basis to capture the relevant discussions, > decisions, and new relevant research or follow up areas to circle back on. > Last time around, I sent out an email that summarized some key takeaways > (from my PoV) of the last multi-day dev summit [1]. What follows in this > email is a similar summary/recap of the three day summit. Just like last > time: if you attended and felt I missed out on a key point, or inadvertently > misrepresented a statement/idea, please feel free to reply, correcting or > adding additional detail. > > The meeting notes in full can be found here: > https://docs.google.com/document/d/1KHocBjlvg-XOFH5oG_HwWdvNBIvQgxwAok3ZQ6bnCW0/edit?usp=sharing > > # Simple Taproot Channels > > During the last summit, Taproot was a major discussion topic as though the > soft fork had been deployed, we we're all still watching the 's stack up > on the road to ultimately activation. Fast forward several months later and > Taproot has now been fully activated, with ecosystem starting to > progressively deploy more and more advanced systems/applications that take > advantage of the new features. > > One key deployment model that came out of the last LN Dev summit was the > concept of an iterative roadmap that progressively revamped the system to > use more taprooty features, instead of a "big bang" approach that would > attempt to package up as many things as possible into one larger update. At > a high level the iterative roadmap proposed that we unroll an existing > larger proposal [2] into more bite sized pieces that can be incrementally > reviewed, implemented, and ultimately deployed (see my post on the LN Dev > Summit 2021 for more details). > > ## Extension BOLTs > > Riiight before we started on the first day, I wrote up a minimal proposal > that attempted to tackle the first two items of the Taproot iterative > deployment schedule (musig2 funding outputs and simple tapscript mapping) > [3]. I called the proposal "Simple Taproot Channels" as it set out to do a > mechanical mapping of the current commitment and script structure to a more > taprooty domain. Rather than edit 4 or 5 different BOLTs with a series of > "if this feature bit applies" nested clauses, I instead opted to create a > new standalone "extension bolt" that defines _new_ behavior on top of the > existing BOLTs, referring
[Lightning-dev] Transcript: Lightning Network in 2022 panel
Hi I thought I'd start posting transcripts that may be of interest to this mailing list. We had a panel discussion on various topics in London before Advancing Bitcoin with Christian Decker (c-lightning), Bastien Teinturier (eclair) and Oliver Gugger (LND). The transcript is here: https://github.com/bitcointranscripts/bitcointranscripts/blob/master/london-bitcoin-devs/2022-03-01-lightning-panel.md It will eventually make it onto the btctranscripts.com website and there will be a video up at some point too. Christian did a demo of and discussed Greenlight (onboarding new Lightning nodes that run on external infrastructure whilst retaining control of keys), we contrasted the different approaches of running a Lightning node with the different Lightning implementations, discussed priorities of the individual implementations in the coming year and covered recent tensions in the spec (BOLT) process. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies
> This is the assumption which I don't agree with and hence asked some > questions in my email. A new RBF policy used by default in Core will not > improve the security of projects that are vulnerable to multiple RBF policies > or rely on these policies in a way that affects their security. Right, not immediately. If and when new policy rules are included in a Bitcoin Core release it would take a while before a significant majority of the network were running those new policy rules (barring some kind of urgency, an attacker exploiting a systemic security flaw etc). That's not an argument not to do it though if you take a longer term perspective on building the strongest possible foundation for Lightning or other Layer 2 projects. The security benefit would just be delayed until a significant majority of Bitcoin Core users upgraded to a version including those new policy rules. > Bitcoin Core with different versions are used at any point and not sure if > this will ever change. Sure there will always be some stray full nodes running extremely old versions but the general direction of travel is more and more full nodes upgrading to newer versions. A network where *all* full nodes are running the same policy rules is clearly not an option available to us without making policy rules effective consensus rules and forking/kicking those old versions off the network. > Maybe some experiments on signet might help in knowing more issues associated > with multiple RBF policies. Definitely agree. It is a really interesting research area and lots of opportunities for simulations and experiments on the default or custom signet networks. Especially if we fill blocks with auto-generated transactions and/or reduce block sizes and create an artificial fee market. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Monday, February 14th, 2022 at 5:18 AM, Prayank wrote: >> I suspect as with defaults generally most users will run whatever the >> defaults are as they won't care to change them (or even be capable of >> changing them if they are very non-technical). > > 30% nodes are using 0.21.1 right now whereas latest version was 22.0 and some > are even running lower versions. Different versions in future with defaults > might be running RBF v1 and RBF v2. > >> But users who have a stake in the security of Lightning (or other Layer 2 >> projects) will clearly want to run whatever policy rules are beneficial to >> those protocols. > > Agree and attackers will want to run the nodes with policy that helps them > exploit bitcoin projects. Miners can run nodes with policy that helps them > get more fees. > >> As you know the vast majority of the full nodes on the network currently run >> Bitcoin Core. Whether that will change in future and whether this a good >> thing or not is a whole other discussion. But the reality is that with such >> strong dominance there is the option to set defaults that are widely used. > > Bitcoin Core with different versions are used at any point and not sure if > this will ever change. > > https://luke.dashjr.org/programs/bitcoin/files/charts/security.html > > https://www.shodan.io/search/facet.png?query=User-Agent%3A%2FSatoshi%2F+port%3A%228333%22=product > >> I think if certain defaults can bolster the security of Lightning (and >> possibly other Layer 2 projects) at no cost to full node users with no >> interest in those protocols we should discuss what those defaults should be. > > This is the assumption which I don't agree with and hence asked some > questions in my email. A new RBF policy used by default in Core will not > improve the security of projects that are vulnerable to multiple RBF policies > or rely on these policies in a way that affects their security. > > Maybe some experiments on signet might help in knowing more issues associated > with multiple RBF policies. > > -- > Prayank > > A3B1 E430 2298 178F > > Feb 13, 2022, 21:16 by michaelfolk...@protonmail.com: > >> Hi Prayank >> >>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to >>> multiple RBF policies being used? >> >> Clearly the security of the Lightning Network and some other Layer 2 >> projects are at least impacted or partly dependent on policy rules in a way >> that the base blockchain/network isn't. As I (and others) have said on many >> occasions ideally this wouldn't be the case but it is best we can do with >> current designs. I (and others) take the view that this is not a reason to >> abandon those designs in the absence of an alternative that offers a >> strictly superior security model. Going back to a model where *all* activity >> is onchain (or even in less trust minimized protocols than Lightning) >> doesn't seem like the right approach to me. >> >>> 2.With recent discussion to change things
Re: [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies
Hi Prayank > 1.Is Lightning Network and a few other layer 2 projects vulnerable to > multiple RBF policies being used? Clearly the security of the Lightning Network and some other Layer 2 projects are at least impacted or partly dependent on policy rules in a way that the base blockchain/network isn't. As I (and others) have said on many occasions ideally this wouldn't be the case but it is best we can do with current designs. I (and others) take the view that this is not a reason to abandon those designs in the absence of an alternative that offers a strictly superior security model. Going back to a model where *all* activity is onchain (or even in less trust minimized protocols than Lightning) doesn't seem like the right approach to me. > 2.With recent discussion to change things in default RBF policy used by Core, > will we have multiple versions using different policies? Are users and > especially miners incentivized to use different versions and policies? Do > they have freedom to use different RBF policy? Without making policy rules effective consensus rules users (including miners) are free to run different policy rules. I think it is too early to say what the final incentives will be to run the same or differing policies. Research into Lightning security is still nascent and we have no idea whether alternative Layer 2 projects will thrive and whether they will have the same or conflicting security considerations to Lightning. I suspect as with defaults generally most users will run whatever the defaults are as they won't care to change them (or even be capable of changing them if they are very non-technical). But users who have a stake in the security of Lightning (or other Layer 2 projects) will clearly want to run whatever policy rules are beneficial to those protocols. As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used. I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be. > 3.Are the recent improvements suggested for RBF policy only focused on > Lightning Network and its security which will anyway remain same or become > worse with multiple RBF policies? I think by nature of the Lightning Network being the most widely adopted Layer 2 project most of the focus has been on Lightning security. But contributors to other Layer 2 projects are free to flag and discuss security considerations that aren't Lightning specific. > Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can > readily choose whatever policy *they* want. The maintainer(s) and contributors to Bitcoin Knots are free to determine what default policy rules they want to implement (and make it easier for users to change those defaults) in the absence of those policy rules being made effective consensus rules. I suspect there would be strong opposition to making some policy rules effective consensus rules but we are now venturing again into future speculation and none of us have a crystal ball. Certainly if you take the view that these policy rules should never be made effective consensus rules then the fact there is at least one implementation taking a contrasting approach to Core is a good thing. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev wrote: > Hello World, > > There was a discussion about improving fee estimation in Bitcoin Core last > year in which 'instagibbs' mentioned that we cannot consider mempool as an > orderbook in which which everyone is bidding for block space because nodes > can use different relay policies: > https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294; > > Although I still don't consider fee rates used in last few blocks relevant > for fee estimation, it is possible that we have nodes with different relay > policies. > > Similarly if we have different RBF policies being used by nodes in future, > how would this affect the security of lightning network implementations and > other layer 2 projects? > > Based on the things shared by 'aj' in > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html > it is possible for an attacker to use a different RBF policy with some > nodes, 10% hash power and affect the security of different projects that rely > on default RBF policy in latest Bitcoin Core. > > There was even a CVE in which RBF policy not being documented
