[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&
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 t
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
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
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
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 >>
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 d
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-
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 > "i
[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 a
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
Re: [Lightning-dev] v0.10.1: "eltoo: Ethereum Layer Too"
Just a joke. Previous release names have been "Federal Qualitative Strengthening", "(Still) Scaling the Ethereum Blockchain", "Blockchain Good, Orange Coin Bad", "Bitcoin's Proof of Stake" etc https://github.com/ElementsProject/lightning/releases I can assure you the c-lightning team isn't planning to introduce proof of stake to Bitcoin or change its monetary policy. Though I'm sure they're open to new name suggestions for the next release if you can think of one. On Thu, Aug 12, 2021 at 4:15 AM Prayank via Lightning-dev wrote: > > Hi Lisa, > > > lisa neigut Mon, 09 Aug 2021 18:04:51 -0700 > > > We're pleased to announce the 0.10.1 release of c-lightning > > <https://github.com/ElementsProject/lightning/releases/tag/v0.10.1>, named > > by @nalinbhardwaj. > > I am confused about the subject of this email. Is this an Ethereum project? > What exactly is Ethereum layer and how is it related to this release? > > -- > Prayank > > A3B1 E430 2298 178F > > > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -- Michael Folkson Email: michaelfolk...@gmail.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] Last week's second IRC workshop on L2 onchain support and wrap up
There was some additional discussion on L2 onchain support at the
recent online Sydney Socratic Seminar. It wasn't recorded but a
transcript is below.
Transcript:
https://btctranscripts.com/sydney-bitcoin-meetup/2021-07-06-socratic-seminar/
The discussion focused partly on the rules [1] of BIP 125 RBF and the
rationale for these rules (which isn't clear from the BIP). Proposed
ideas such as SIGHASH_IOMAP, fee sponsorship and transaction mutation
were also discussed that weren't covered during the IRC workshops.
[1]
https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details
On Tue, Jun 29, 2021 at 10:44 AM Michael Folkson
wrote:
>
> A summary of the first workshop is here:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.html
>
> The focus for this second workshop was fee bumping and package relay.
> For more details on package relay see:
> https://github.com/ariard/L2-zoology/blob/master/workshops/package-relay-and-friends.md
>
> The conversation log for the second workshop is here:
> https://gist.github.com/ariard/32b51ecceccc5c6f647bae86d083c442
>
> Package relay background
>
> Package relay is potentially useful for L2 protocols to address the
> inherent unpredictability of future fees. CPFP (child-pays-for-parent)
> seeks to ensure say a justice transaction, in Lightning’s case, with a
> lower fee, gets confirmed in a more timely manner because miners are
> incentivized to include the child transaction in a block. To do so
> they must include the parent transaction in that block or a preceding
> block. By “packaging” the parent and the child the initiator of the
> transaction(s) can ensure the miner’s mempool doesn’t initially reject
> the parent transaction for having a too low fee.
>
> There has been prior work done in previous years on package relay,
> mainly by Suhas Daftuar.
>
> Draft BIP: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
>
> Package relay design questions:
> https://github.com/bitcoin/bitcoin/issues/14895
>
> Recently Gloria Zhao has been advancing package relay in Bitcoin Core:
> https://gist.github.com/glozow/7064717e727a3eb27fad4f8504513add
>
> Package relay implementation
>
> Attendees seemed in agreement that enabling 2 transaction packages
> would be sufficient (at least for now) for Lightning and DLCs. A L2
> protocol should always be able to design a two step process where the
> first transaction has an effective zero fee rate and the second
> transaction sets the fee. Restricting the size of the package to 2 may
> have the cost of slightly longer confirmation times and/or slightly
> higher fees (t-bast) but it compares well to the increased
> implementation complexity of larger package sizes. Two generation:
> multi parent, single child shouldn’t introduce material implementation
> complexity over two generation: single parent, single child (glozow).
>
> Package RBF (replace-by-fee) is possible where there are two competing
> packages with competing Lightning commitment transactions in them and
> the second package is given a higher fee to attempt to get it
> confirmed before the first package. However, supporting RBF within a
> package (ie replacing a transaction in a package with a higher fee
> transaction) increases implementation complexity and makes it harder
> to reason about (glozow).
>
> rgrant raised the possibility of using two packages {A,B} and {B,C} if
> three transaction packages e.g. {A,B,C} weren’t supported but it was
> suggested it is perhaps better to just broadcast a high fee CPFP
> transaction for the {A,B} package rather than creating two packages.
> If the first package has been evicted from the mempool the {B,C}
> package wouldn’t propagate because it would be an orphan package
> (t-bast).
>
> glozow suggested that only hints (wtxids of transactions you think
> should be package validated) could be communicated rather than
> relaying the transaction themselves but there were concerns from
> others on whether these hints would successfully propagate across the
> network. Instead fee rate hints could be sent to inform a peer’s
> decision on whether it makes sense to fetch the rest of the package
> (t-bast).
>
> darosior suggested the idea of a package based CBlockPolicyEstimator
> in Bitcoin Core if CPFP is going to be increasingly used on the
> network.
>
> Witness replacement and Taproot
>
> Tapscripts can be unlimited in size so with current Taproot rules you
> could in theory go from a 100,000 vbyte witness to an empty witness.
> L2 protocols may have a UTXO shared by two parties where Alice’s
> witness for her branch is say 1,000 vbytes and Bob’s witness is only
> say 250 vbytes. Replacing Alice’s larger witness with B
Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization
equiv of improvement proposals: BOLTs. >>>> >> > Historically >>>> >> >>>> >> > new standardization documents are proposed initially as issues or >>>> >> > PR's when >>>> >> >>>> >> > ultimately accepted. Why do we need another repo? >>>> >> >>>> >> >>>> >> As far as I can tell there was always some form of (invisible?) barrier >>>> >> to participate in the BOLTs but there are also new BOLTs being offered: >>>> >> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798 >>>> >> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780 >>>> >> and topics to be included like: >>>> >> * dual funding >>>> >> * splicing >>>> >> * the examples given by Ryan >>>> >> >>>> >> I don't see how a new repo would reduce that barrier - Actually I think >>>> >> it would even create more confusion as I for example would not know >>>> >> where something belongs. That being said I think all the points that >>>> >> are addressed in Ryan's mail could very well be formalized into BOLTs >>>> >> but maybe we just need to rethink the current process of the BOLTs to >>>> >> make it more accessible for new ideas to find their way into the BOLTs? >>>> >> One thing that I can say from answering lightning-network questions on >>>> >> stackexchange is that it would certainly help if the BOLTs where >>>> >> referenced on lightning.network web page and in the whitepaper as the >>>> >> place to be if one wants to learn about the Lightning Network >>>> >> >>>> >> with kind regards Rene >>>> >> >>>> >> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev >>>> >> wrote: >>>> >>> >>>> >>> Hi all, >>>> >>> >>>> >>> >>>> >>> The recent thread around zero-conf channels [1] provides an >>>> >>> opportunity to discuss how the BOLT process handles features and best >>>> >>> practices that arise in the wild vs. originating within the process >>>> >>> itself. Zero-conf channels are one of many LN innovations on the app >>>> >>> layer that have struggled to make their way into the spec. John >>>> >>> Carvalho and Bitrefill launched Turbo channels in April 2019 [2], >>>> >>> Breez posted their solution to the mailing list for feedback in August >>>> >>> 2020 [3], and we know at least ACINQ and Muun (amongst others) have >>>> >>> their own implementations. In an ideal world there would be a >>>> >>> descriptive design document that the app layer implementers had >>>> >>> collaborated on over the years that the spec group could then pick up >>>> >>> and merge into the BOLTs now that the feature is deemed spec-worthy. >>>> >>> >>>> >>> >>>> >>> Over the last couple of months, we have discussed the idea of adding a >>>> >>> BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with >>>> >>> various members of the community, and have received positive feedback >>>> >>> from both app layer and protocol devs. This would not affect the >>>> >>> existing BOLT process at all, but simply add a place for app layer >>>> >>> best practices to be succinctly described and organized, especially >>>> >>> those that require coordination. These features are being built >>>> >>> outside of the BOLT process today anyways, so ideally a bLIP process >>>> >>> would bring them into the fold instead of leaving them buried in old >>>> >>> ML posts or not documented at all. >>>> >>> >>>> >>> >>>> >>> Some potential bLIP ideas that people have mentioned include: each >>>> >>> lnurl variant, on-the-fly channel opens, AMP, dynamic commitments, >>>> >>> podcast payment metadata, p2p messaging formats, new pathfinding >>>> >>> heuristics, remote node connection standards, etc. >>>> >>> >>>> >>> >>>> >>> If the community is interested in moving forward, we've started a >>>> >>> branch [5] describing such a process. It's based on BIP-0002, so not >>>> >>> trying to reinvent any wheels. It would be great to have developers >>>> >>> from various implementations and from the broader app layer ecosystem >>>> >>> volunteer to be listed as editors (basically the same role as in the >>>> >>> BIPs). >>>> >>> >>>> >>> >>>> >>> Looking forward to hearing your thoughts! >>>> >>> >>>> >>> >>>> >>> Best, >>>> >>> Ryan >>>> >>> >>>> >>> >>>> >>> [1] >>>> >>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html >>>> >>> >>>> >>> [2] >>>> >>> https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster >>>> >>> >>>> >>> [3] >>>> >>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html >>>> >>> >>>> >>> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = >>>> >>> Standardization of Protocols at the Request of the Kommunity (h/t >>>> >>> fiatjaf) >>>> >>> >>>> >>> [5] >>>> >>> https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki >>>> >>> >>>> >>> ___ >>>> >>> Lightning-dev mailing list >>>> >>> Lightning-dev@lists.linuxfoundation.org >>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> https://www.rene-pickhardt.de >>>> >> ___ >>>> >> 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 >>>> ___ >>>> 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 > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -- Michael Folkson Email: michaelfolk...@gmail.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] Last week's second IRC workshop on L2 onchain support and wrap up
protocols 2) There are ongoing discussions in the ecosystem regarding deprecation of opt in RBF and implementation of full RBF: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html 3) Generally status quo and ad hoc security incident response policy in the case of cross-layer security issues 4) Generally status quo on L2 security philosophy design. L2 protocol designers should seek to minimize assumptions on the base layer. -- Michael Folkson Email: michaelfolk...@gmail.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] Waiting SIGHASH_ANYPREVOUT and Packing Packages
ol based on presigned transactions can magically >> allow dynamically adding inputs and modifying outputs for fees, and we >> also have a magic perfect transaction replacement protocol, package >> relay is still fundamentally useful for CPFP fee bumping very low >> feerate transactions received from an external party. E.g. Alice pays >> Bob, mempool min feerates increase and Alice's transaction is dropped, >> Bob still wants the money, so he submits a package with Alice's >> transaction plus his own high feerate spend of it. >> >> Package relay is a clear improvement now, and one I expect to be >> permanent for as long as we're using anything like the current protocol. >> >> > # Deployment timeline >> > >> > So what I believe as a rough deployment timeline. >> >> I don't think it's appropriate to be creating timelines like this that >> depend on the work of a large number of contributors who I don't believe >> you've consulted. For details on this point of view, please see >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.html >> >> Stuff will get done when it gets done. >> >> -Dave > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -- Michael Folkson Email: michaelfolk...@gmail.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] Tuesday’s IRC workshop on L2 onchain support
The workshop was previously announced by ariard on the bitcoin-dev mailing list here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html A reminder was posted to the bitcoin-dev mailing list here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html The conversation log for the workshop is here: https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 I’ll summarize what was discussed during the meeting but please refer to the L2 zoology repo ariard has set up for background context and additional notes: https://github.com/ariard/L2-zoology General considerations I think it is worth first reiterating the obvious that there will never be perfect security guarantees on network transaction fee rates or transaction relay. Network fee rates can in theory go up to anything (upper limit of infinity) and will always to some degree be inherently unpredictable. In addition transaction acceptance can never be guaranteed even if you attempt a direct connection to a miner. At the same time L2 protocols (e.g. Lightning and DLCs) elevate transaction propagation and inclusion in a time sensitive mined block to a security assumption from what used to just be a usability assumption (BlueMatt). Within those confines these workshops are attempting to strengthen that security assumption knowing that guaranteeing it is out of reach. There are considerations that blocked transaction propagation isn’t necessarily a problem for the victim if it is also blocked for the attacker. In addition some successful attacks present an opportunity for the victim to divert their funds to miner fees (e.g. scorched earth) ensuring the attacker doesn’t financially benefit from the attack (harding). Personally I would argue neither of these present much assurance to the victim. Out of conservatism one should assume that the attacker has greater resources than the victim (e.g. a direct line to a miner) and knowing a victim’s lost funds went to the miner instead of the attacker isn’t of much comfort to the victim (other than potentially presenting a disincentive for the attack in the first place). This is obviously further complicated if the miner is the attacker. In addition any incentive for miners to not mine transactions to wait for a potential pay-all-to-fee are troubling (t-bast). New(ish) ideas RubenSomsen brought up the idea of fee sensitive timelocks, they would need a soft fork. ariard briefly discussed the idea of a transaction relay overlay network. harding stated his opinion that we should be leaning more on miners’ profit incentive rather than attempting to normalize mempool policy (e.g. https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html). t-bast raised the prospect of mining pools exposing public APIs to push them transactions directly. The impact of changes to Bitcoin Core on L2 protocols Some changes to Core (e.g. some privacy improvements) can conflict with the goal of minimizing transaction propagation times. Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L2 developers a way to write regression tests against the latest builds of bitcoind. He added that L2 devs should write automated regression test suites against bitcoind exposed RPC commands. t-bast would like a bitcoind “evicttx” RPC to remove a transaction from the mempool on regtest. Full RBF In advance of the workshop ariard posted to the mailing list a proposal for full RBF in a future version of Bitcoin Core: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html Progress in this direction has been attempted in the past (e.g. https://github.com/bitcoin/bitcoin/pull/10823) BlueMatt pointed out that even with full RBF it is trivial to create mempool partitions. As long as RBF has a fee rate increase minimum an attacker can trivially split the mempool by broadcasting two conflicting transactions with the same fee. ariard plans to contact businesses (e.g. Lightning onboarding services relying on zero confirmations) to check that this possible eventual move to full RBF doesn’t present a problem for them. There could well be engineering work required in advance of the possible change being made. Next week’s meeting Next week’s meeting (Tuesday 22nd June, 19:00 UTC, #l2-onchain-support, Libera) will be on fee bumping and package relay that glozow has recently been working to advance in Bitcoin Core. -- Michael Folkson Email: michaelfolk...@gmail.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
