Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

2023-05-08 Thread Antoine Riard
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

Re: [Lightning-dev] A Note on Public Communication

2023-05-08 Thread Tony Giorgio via Lightning-dev
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

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

2023-05-08 Thread Clara Shikhelman
Hi, 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

Re: [Lightning-dev] A Note on Public Communication

2023-05-08 Thread Bryan Bishop
Well, you could always send to bitcoin-...@lists.linuxfoundation.org -- we are usually pretty fast with email modqueue. On Mon, May 8, 2023 at 3:26 PM Tony Giorgio via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Is there a better place to have public communication?

Re: [Lightning-dev] A Note on Public Communication

2023-05-08 Thread Vincenzo Palazzo
> 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

Re: [Lightning-dev] A Note on Public Communication

2023-05-08 Thread Michael Folkson via Lightning-dev
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

Re: [Lightning-dev] Call For Review - LSPSpec LSPS1 LSPS2

2023-05-08 Thread ZmnSCPxj via Lightning-dev
Good morning list, I would like to point out that one of the main issues with LSPs is that most of them are designed to lock in their customers to their platform. Hopefully, with a common open specification like this, it becomes significantly more feasible for Lightning end-user clients to

Re: [Lightning-dev] A new Bitcoin implementation integrated with Core Lightning

2023-05-08 Thread Matt Corallo
Hi Michael,While I don’t think forks of Core with an intent to drive consensus rule changes (or lack thereof) benefits the bitcoin system as the Bitcoin Core project stands today, if you want to build a nice full node wallet with lightning based on a fork of Core, there was code written to do this

Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs

2023-05-08 Thread ZmnSCPxj via Lightning-dev
Good morning t-bast, and list, Dual-funded 0-conf can be made safe in the following case: * If the initiator uses swap-in-potentiam addresses (with initiator as Alice, acceptor as Bob). If the initiator stalls, then the acceptor can retaliate by refusing to sign the swap-in-potentiam UTXOs