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
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
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
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
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
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
ge ---
> 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 thi
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
> 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 -
> 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
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
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
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
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)
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
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:
> 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.
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
18 matches
Mail list logo
