Re: [Lightning-dev] A Note on Public Communication
Hi Tony, > 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. As I think you're referring to my post of March 21th and as the author of this post, I'll politely refuse the qualification of "off-topic". I had and I still have the concerns of "frivolous legal claims" being used between bitcoin developers/organizations provoking a distortion of the neutrality of the development and a chilling effect of the technical discussions (i.e code we compile and spec we implement). For those reasons, it was my legal right and moral duty to inform the community of what is happening between Chaincode and myself. And here I'm following the recommendation of one of the moderators of the Lightning mailing list himself "If this worries you too, let's make sure we keep each other honest, OK?" [0]. When you think a group of people with open-source responsibilities are in a situation of conflict of interests or "moral hazards", or even the appearance of them, you have the right to expose the wrongdoing, including the _proportional_ revelation of private elements. People have done the "free choice" to conduct a career in open-source, for some even declaring in some context to maintain integrity and accept their actions to be submitted to external accountability [1]. While the exposure of private elements of public personalities might break common courtesy, it's a morally valid practice if you're familiar with the public institutions of US and Europe, and I think this practice has found validity in the history of open-source commons or IETF's protocol development [1]. Beyond, the Bitcoin and Lightning development communication channels constitute a public forum, where by nature the participants are exchanging ideas and defending competing interests. In consequence, the participants' rights and capabilities to contribute and speak their minds in those communication channels should be protected. Those communication channels are not your usual corporate workplace, and in case of conflicting principles, the maintainers of those communication channels should ensure a balance of rights and a proportionality in any restraining measure. And this new post is not to exonerate myself of any legal responsibility for personal matters that could be recognized as the outcome of a judicial process, respective of both rights of the accusation and rights of the defense. Rather to enlighten the Bitcoin community that the formal separation between private matters and open-source responsibilities, and the adequate check-and-balances to guarantee this separation is somehow what are the underlying stakes for this feud between Chaincode and myself, from my perspective. I can say missing an open-source engineering meeting or being revoked a few Github permissions matters far less than the clear affirmation and respect of the freedom of expression, the presumption of innocence and due process in the Bitcoin common space, all proportions conserved. I don't blame any party involved in this issue, nor assign "bad intentions''. One position is really a function of your life experiences, knowledge of the legal and cultural framework and access to the factual elements. As all human conflicts it is not binary rather "grey". People can be top executives at a billion-dollar company, having successful ventures with hundreds of folks under management, or have a lot of responsibilities for their relative young age, and still disagree on the set of legal and moral principles to apply in the present case. Finally, thanks to the Bitcoin friends who have reached out to call for level-headedness and cool-mindness in the public discussion of this complex topic. Like I said to them, in the lack of more suspected wrongdoing from the other side, I won't communicate further on this subject on the Bitcoin and Lightning technical channels. However I still firmly believe the discussion on the principles, abstract in the maximum from its private elements, should still be pursued on other channels. Independently, there is a legal channel opened between Chaincode and myself and good progress is made to find a serene and long-standing resolution to this issue. Best, Antoine [0] https://rusty-lightning.medium.com/the-corrosion-of-ethics-in-cryptocurrencies-f7ba77e9dfc3 [1] https://github.com/btrustteam/board-book/blob/main/vision/genesis_principles.md [2] https://www.ietf.org/about/administration/policies-procedures/conflict-interest/ Le lun. 8 mai 2023 à 21:26, Tony Giorgio via Lightning-dev < lightning-dev@lists.linuxfoundation.org> a écrit : > 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
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi Christian, Thanks for your comments! We will discuss this further in the upcoming call on the 15th, would be great to see you there! > 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). > In the Lightning Network, fees are a native way to put a price on having a good reputation (see details here [0]). In the design that we suggest, the reputation gained today cannot be used in the distant future, and funds need to be invested continuously to keep a good reputation. Good reputation is also a function of the general environment, and so if there is a fee spike, reputation will change. It is true that nodes can go rogue, but this is why we aim for the price of a good reputation to be similar to the amount of damage they can create. > 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. > Notice that we are not gossiping about our peer's reputation. The only thing that a node communicates to its neighbor is whether they see an HTLC as endorsed or just neutral, that is, should this HTLC be granted access to all of the resources or just the restricted part. > 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. > This is something we hope to learn once we'll start collecting data from our brave volunteers :) Cheers, Clara ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
From my perspective it really comes down to whether you want security *guarantees* or data to assist you in making probabilistic judgments about future behavior. Reputation data or reputation systems will never give you guarantees for the reasons Christian explains. But reputation data is better than nothing and depending on the quality and granularity of the data could be considerably better than nothing. In the most basic case of deciding on a potential channel counterparty I would much rather choose a counterparty who has demonstrated competence and reliability over a number of years than a channel counterparty who has just joined the network and who I know nothing about. Similarly a Lightning node that hasn't carried a jamming attack for multiple years despite having the opportunity to is a much better bet than a Lightning node of which I know nothing. Now where it sits on the software stack assuming a user opts into such a reputation "service" (plugin maybe or more likely an API) is I think what in essence this discussion is about. As I've already stated previously and which I agree with Christian on is that it isn't/shouldn't be a protocol or a P2P gossiping issue. In the same way as we have multiple Lightning explorers (1ML, Amboss etc) that aren't part of the Lightning protocol or part of the "core" of a Lightning node you can expect there would be competing reputation data providers and services. Also many users for privacy and/or other reasons won't be interested in using or participating in (to the extent they can opt out if the data is public) a reputation service. So yeah I think I'm somewhere in between Christian's and Antoine's perspectives here. I do think there are interesting projects, services or even businesses in this area of reputation but it isn't a protocol/P2P gossiping issue or a "core" of a Lightning node issue. Thanks Michael [0]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003766.html -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Wednesday, May 10th, 2023 at 12:57, Christian Decker wrote: > Hi Antoine, > > this is an intrinsic issue with reputation systems, and the main > reason I'm sceptical w.r.t. their usefulness in lightning. > Fundamentally any reputation system bases their expectations for the > future on experiences they made in the past, and they are thus always > susceptible to sudden behavioral changes (going rogue from a prior > clean record) and whitewashing attacks (switching identity, abusing > any builtin bootstrapping method for new users to gain a good or > neutral reputation before turning rogue repeatedly). > > This gets compounded as soon as we start gossiping about reputations, > since now our decisions are no longer based just on information we can > witness ourselves, or at least verify its correctness, and as such an > attacker can most likely "earn" a positive reputation in some other > part of the world, and then turn around and attack the nodes that > trusted the reputation shared from those other parts. > > I'd be very interested in how many repeat interactions nodes get from > individual senders, since that also tells us how much use we can get > out of local-only reputation based systems, and I wouldn't be > surprised if, for large routing nodes, we have sufficient data for > them to make an informed decision, while the edges may be more > vulnerable, but they'd also be used by way fewer senders, and the > impact of an attack would also be proportionally smaller. > > Cheers, > Christian > > On Mon, May 8, 2023 at 10:26 PM Antoine Riard antoine.ri...@gmail.com wrote: > > > Hi *, > > > > > Our suggestion is to start simple with a binary endorsement field. As > > > we learn more, we will be better equipped to understand whether a > > > more expressive value is required. > > > > I think the HTLC endorsement scheme as proposed is still suffering from a > > vulnerability as local reputation can be built up during periods of low > > routing fees, endorsement gained and then abused during periods of high > > routing fees. Therefore, it sounds to me this scheme should aim for some > > reputational transitivity between incoming traffic and outgoing traffic. > > Namely, the acquisition cost of the local reputation should be equal to the > > max timevalue damage that one can inflict on a routing node channel > > accessible from its local counterparty granting this high-level of > > reputation. > > > > I don't know if this can be fixed by ensuring permanent link-level "gossip" > > where counterparties along a payment path expose their reputation > > heuristics to guarantee this transitivity, or it's a fundamental issue with > > a point-to-point approach like HTLC endorsement. > > > > Opened an issue on the repository to
Re: [Lightning-dev] Fixing a griefing attack on JIT Channels using PTLCs
Good morning mailing list, et al., Let me explain the various possible mitigations and their drawbacks. Many of these are either "LSP trusts client" or "client trusts LSP", in the sense that it is possible for the second mover (client in "LSP trusts client"; LSP in "client trusts LSP") to impose costs on, or outright steal from, the first mover. If you want a trust-minimized solution, you need some kind of third party that both LSP and client agree will actually enforce that the second mover does not cheat or otherwise impose costs on the first mover. This "third party" SHOULD really be the blockchain, meaning you should really be using at least 1-conf and probably 3-conf to avoid reorgs, but *shrug*. (You *could* use Liquid as a third party --- but Liquid is custodial, it just has a federation as a custodian instead of a single entity, you have to trust that the federation does not collude to steal all your funds, or that Blockstream has not installed Something Else (TM) in the HSMs they sold to the federation members.) Without a trusted third party (with the blockchain, being a decentralized open-source project with strong incentives against censorship, being your standard for trustworthiness), your choices are: * LSP issues a promise --- a signature committing to a funding output on a funding transaction --- that it will definitely make a 0-conf funding transaction get confirmed before some future target blockheight. https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/24 If the funding transaction is not confirmed by then, or the output is not the correct `scriptPubKey` and amount, the client reports it publicly and starts a boycott of the LSP. * The client refuses to send `channel_ready` (and therefore the HTLC cannot reach the client) until after the LSP issues this promise. "LSP trusts client". * How often have boycotts actually worked anyway? * Client waits for the funding transaction to appear on its local mempool before sending `channel_ready`. * "LSP trusts client", somewhat, but far weaker than the above; you can argue this is actually "client trusts LSP" and I would agree with you. * The LSP can still double-spend the funding transaction with coordination with a miner, as I noted in my critique of benthecarman proposal. Mere broadcast is not an assurance of confirmation, we have been saying that about 0-conf for a long time. * Not all clients naturally have access to a mempool --- BIP157/158 clients do not necessarily maintain their own mempool, though an Electrum SPV client can query the mempool of the Electrum server. * benthecarman proposal, as noted in previous post. * "client trusts LSP". * LSP waits for the client to hand over the preimage before broadcasting the funding tx. * "client trusts LSP". * LSP can skip actual funding tx broadcast once the client has handed over the preimage. * Can be implemented in multiple ways that are all equivalent: * Outright give the preimage in some bespoke API call. * LSP sends the `open_channel` blah blah dance until `channel_ready` exchange, does `update_add_htlc` and irrevocably committed dance, then waits until `update_fulfill_htlc` before broadcasting the funding tx. * A client can implement the "client waits for funding tx in its own mempool before preimage" while the LSP implements this "LSP waits for preimage before funding tx broadcast", and both of them will stall waiting for each other LOL ^.^ wahahahahaha deadlock is fun. This is why LSPS has to pick one or the other, otherwise we will get incompatibilities between LSPs and clients. LSPS (Open LSP Specifications group) participants have indicated a desire to prefer "LSP trusts client", because the LSP is a big target for various kinds of out-of-LSPS attacks. For example, a hacker could potentially modify the behavior of an LSP so that the LSP attacks the client, if the "client trusts LSP" model is used. Worse, somebody can ***accuse*** the LSP of actually attacking *some* client, and it can be hard for the LSP to provide substantial evidence that it is NOT attacking the client. (This is why the "promise" scheme I listed first above is valuable --- it is definite proof that the LSP is not attacking the client, if the client is unable to provide the promise as a proof-of-misbehaviour, then the client is just bullshitting and its claim of being cheated can be ignored, assuming of course that people actually believe in the strong cryptographic provisions of the signature scheme (which I might add is the same signature scheme used to secure Bitcoin itself, so... but humans are stupid, which is why AI should replace humans with something better). By the way have I mentioned I am human today?) However, the only truly "LSP trusts client" scheme that I have figured out is that first scheme where the LSP issues a cryptographically third-party-verifiable promise to get the funding tx confirmed by some
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
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 wrote: > > Hi *, > > > Our suggestion is to start simple with a binary endorsement field. As > > we learn more, we will be better equipped to understand whether a > > more expressive value is required. > > I think the HTLC endorsement scheme as proposed is still suffering from a > vulnerability as local reputation can be built up during periods of low > routing fees, endorsement gained and then abused during periods of high > routing fees. Therefore, it sounds to me this scheme should aim for some > reputational transitivity between incoming traffic and outgoing traffic. > Namely, the acquisition cost of the local reputation should be equal to the > max timevalue damage that one can inflict on a routing node channel > accessible from its local counterparty granting this high-level of reputation. > > I don't know if this can be fixed by ensuring permanent link-level "gossip" > where counterparties along a payment path expose their reputation heuristics > to guarantee this transitivity, or it's a fundamental issue with a > point-to-point approach like HTLC endorsement. > > Opened an issue on the repository to converge on a threat model: > https://github.com/ClaraShk/LNJamming/pull/13 > > I still think building data gathering infrastructure for Lightning is > valuable as ultimately any jamming mitigation will have to adapt its upfront > fees or reputation acquisition cost in function of HTLC traffic and market > forces. > > Looking forward to giving an update on Staking Credentials [0], an end-to-end > approach to mitigate channel jamming. > > Best, > Antoine > > [0] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html > > Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen a écrit > : >> >> Hi list, >> >> Some updates on channel jamming! >> >> # Next Call >> - Monday 01 May @ 15:00 UTC >> - https://meet.jit.si/UnjammingLN >> - Agenda: https://github.com/ClaraShk/LNJamming/issues/12 >> >> # Data Gathering >> During these weekly calls, we've come to agreement that we would like >> to gather data about the use of HTLC endorsement and local reputation >> tracking for jamming mitigation. A reminder of the full scheme is >> included at the end of this email, and covered more verbosely in [1]. >> >> We have a few goals in mind: >> - Observe the effect of endorsement in the steady state with >> logging-only implementation. >> - Gather real-world data for use in future simulation work. >> - Experiment with different algorithms for tracking local reputation. >> >> The minimal changes required to add HTLC endorsement are outlined in [2]. >> 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. >> >> With this infrastructure in place, we can start to experiment with >> various local reputation schemes and data gathering, possibly even >> externally to LN implementations in projects like circuitbreaker [3]. >> We'd be interested to hear whether there's any appetite to deploy using >> an experimental TLV value? >> >> # Reputation Scheme >> - Each node locally tracks the reputation of its direct neighbors. >> - Each node allocates, per its risk tolerance: >> - A number of slots reserved for endorsed HTLCs from high reputation >> peers. >> - A portion of liquidity reserved for endorsed HTLCs from high >> reputation peers. >> - Forwarding of HTLCs: >> - If a HTLC is endorsed by a high reputation peer, it is forwarded >>
Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs
Hey Matt, Zman, > I propose that we DO lock our UTXOs after tx_completes have been > exchanged IF we are the only contributor. We don't have to worry > about liquidity griefing in this case, since the peer has no > tx_signatures to withhold from us. While this is true for dual funding, this isn't true for splicing, where we need the remote `tx_signatures` to spend the channel's current funding output. But it's not an issue, the untrusted peer will send their `tx_signatures` first (since they're not contributing to the transaction) and we can `TryLock()` once we receive that. > Your proposal basically means "do not dual-fund 0-conf". > You might as well use the much simpler openv1 flow in that case, just > because it is simpler. I also thought that this was the easy way out, but I was hoping we could do better. The issue with that option (using v1 with locks for 0-conf, and v2 with soft locks for non 0-conf) is that we need to implement that soft lock mechanism (we cannot simply rely on bitcoin core, which only supports hard locks) or use separate bitcoin core wallets for 0-conf and non 0-conf. But there is probably no free lunch here! And anyway, this post was also made to raise awareness for implementers to make sure they don't end up accidentally double-spending 0-conf channels when implementing dual funding. Thanks, Bastien Le mer. 10 mai 2023 à 02:07, ZmnSCPxj a écrit : > Good morning Matt, and t-bast, > > Your proposal basically means "do not dual-fund 0-conf". > You might as well use the much simpler openv1 flow in that case, just > because it is simpler. > > Regards, > ZmnSCPxj > > > > > Sent with Proton Mail secure email. > > --- Original Message --- > On Tuesday, May 9th, 2023 at 5:38 PM, Matt Morehouse < > mattmoreho...@gmail.com> wrote: > > > > Hi Bastien, > > > > In general, 0-conf is only safe when WE are the only contributor to > > the channel, otherwise the peer could double spend us. > > > > The problem you seem to be describing is that we might double-spend > > ourselves if we don't lock our 0-conf UTXOs at some point. I propose > > that we DO lock our UTXOs after tx_completes have been exchanged IF we > > are the only contributor. We don't have to worry about liquidity > > griefing in this case, since the peer has no tx_signatures to withhold > > from us. Of course, the opportunistic upgrade of a regular channel to > > 0-conf won't work -- we need a way to differentiate 0-conf channels > > prior to UTXO selection, so that we don't reuse soft-locked UTXOs. > > > > All together, what I propose is: > > > > 1) If the channel type has option_zeroconf, select UTXOs that are not > > soft locked. > > 2) If the peer adds any inputs to the funding transaction, abort > > (0-conf is unsafe for us in this case). > > 3) After tx_complete exchange, TryLock() our UTXO inputs and abort if > > already locked. > > 4) Broadcast funding transaction and begin using the 0-conf channel. > > > > I think this at least enables the common use case for 0-conf: LSPs can > > use their own funds to open 0-conf channels for clients. > > > > - Matt > > > > > > > > > > On Sat, May 6, 2023 at 3:16 AM Bastien TEINTURIER bast...@acinq.fr > wrote: > > > > > Good morning list, > > > > > > One of the challenges created by the introduction of dual funded > > > transactions [1] in lightning is how to protect against liquidity > > > griefing attacks from malicious peers [2]. > > > > > > Let's start by reviewing this liquidity griefing issue. The dual > funding > > > protocol starts by exchanging data about the utxos each peer adds to > the > > > shared transaction, then exchange signatures and broadcast the > resulting > > > transaction. If peers lock their utxos as soon as they've decided to > add > > > them to the shared transaction, the remote node may go silent. If that > > > happens, the honest node has some liquidity that is locked and > unusable. > > > > > > This cannot easily be fixed by simply unlocking utxos after detecting > > > that the remote node is fishy, because the remote node would still have > > > succeeded at locking your liquidity for a (small) duration, and could > > > start other instances of that attack with different node_ids. > > > > > > An elegant solution to this issue is to never lock utxos used in dual > > > funded transactions. If a remote node goes silent in the middle of an > > > instance of the protocol, your utxos will automatically be re-used in > > > another instance of the protocol. The only drawback with that approach > > > is that when you have multiple concurrent instances of dual funding > with > > > honest peers, some of them may fail because they are double-spent by > one > > > of the concurrent instances. This is acceptable, since the protocol > > > should complete fairly quickly when peers are honest, and at worst, it > > > can simply be restarted when failure is detected. > > > > > > But that solution falls short when using 0-conf, because accidentally > > >
