Newsletters: add 309 (2024-06-28)

[harding]

• Lede, releases/RCs, topic entries @harding
• Stack Exchange @bitschmidty
• Notable merges @Gustavojfe

[stefanwouldgo]

The last paragraph about the comparison to min cost flow probabilities is misleading IMHO (because the OP is): the min cost flow probabilities and the feasibility probabilities are over different and incompatible probability spaces, so comparing them doesn’t really make sense. I think it’s best to just scrap that paragraph.

[bitschmidty]

lgtm so far

[renepickhardt]

I disagree with @stefanwouldgo: While the probability that a payment is feasible (blue curve) is indeed not the same as the success probability of a single round of MPP attempts (green curve) I think the comparison of these two still makes some sense.

For example the likelihood that the payment is feasible was for all amounts larger than the likelihood for a single round of attempt to be successful (thus the MCF curve lies below the other one). For me this was meainly meant as a sanity check that the provided approach is not obviously stupid. Maybe I should have stated this a bit more clearly

I would not scratch that paragraph, because indeed the likelihood of feasibility gives a useful baseline (also for the usecases that David suggested on delving e.g. knowing if one can receive money)

[harding]

@stefanwouldgo

The last paragraph about the comparison to min cost flow probabilities is misleading IMHO (because the OP is): the min cost flow probabilities and the feasibility probabilities are over different and incompatible probability spaces, so comparing them doesn’t really make sense. I think it’s best to just scrap that paragraph.

@renepickhardt

I disagree with @stefanwouldgo: While the probability that a payment is feasible (blue curve) is indeed not the same as the success probability of a single round of MPP attempts (green curve) I think the comparison of these two still makes some sense.

I'll be deleting the clause "Pickhardt [...] compares the likelihood of feasibility to the likelihood of a minimum cost flow solver making a successful payment" but I'm keeping (with some revision) "It also provides a useful basis for comparison." That removes mention of the specific comparison that seems debatable while still mentioning that it can be useful for making some sort of comparisons, which seems unquestionably true to me. It also addresses Rene's line comments.

   The likelihood of feasibility makes it clear that many LN payments
   that naively seem possible will not succeed in practice.  It also
-  provides a useful basis for comparison: Pickhardt provides a graph for
-  a simulated network that compares the likelihood of feasibility to the
-  likelihood of a minimum cost flow solver making a successful payment,
-  showing the solver succeeding most of the time a payment is possible.
-  In a [reply][pickhardt feasible2], he also describes how the
+  provides a useful basis for making comparisons.
+  In a [reply][pickhardt feasible2], Pickhardt describes how the
   likelihood metric could be used by wallets and business software to
   automatically make some intelligent decisions on behalf of its users.

[stefanwouldgo]

Thank you. This seems like a good solution to me. I have added a counterexample to the original discussion (https://delvingbitcoin.org/t/estimating-likelihood-for-lightning-payments-to-be-in-feasible/973/5).

[renepickhardt]

Thank you. This seems like a good solution to me. I have added a counterexample to the original discussion (https://delvingbitcoin.org/t/estimating-likelihood-for-lightning-payments-to-be-in-feasible/973/5).

As laid out in my reply I don't think you provided a counter example:
https://delvingbitcoin.org/t/estimating-likelihood-for-lightning-payments-to-be-in-feasible/973/6

[LarryRuane]

This is within a quote so may not be fixable?

Suggested change

	broadcasting transactions if a btcd backend with an older version
	broadcast transactions if a btcd backend with an older version

[harding]

Made the edit. I think it's fine. I don't like editing if it's the quoted author's style choice or if there's any risk of changing the meaning, but small edits to fix clear typos are ok.

[Gustavojfe]

just pushed all the merge summaries for this week's newsletter, left a comment on the 2nd one, Bitcoin Core #28984.

[harding]

Just a few FYIs for the future for @Gustavojfe

[harding]

@Gustavojfe Making a small edit here: "package replace-by-fee" is the correct term and linking to our topic pages on those separate topics is also good, but we have a previously unwritten rule about avoiding two links in sequence because they look like one link. I'll add that rule to the style guide now.

[harding]

It looks to me like it doesn't enforce the TRUC size restrictions, but it is limited to 1-parent-1-child. Your description looks correct to me, so I'm going to delete the comment. Thanks for checking!

[harding]

@Gustavojfe FYI: we don't need to expand abbreviations for which we have a topic page; it's ok to just link to them instead (e.g. [HTLC][topic htlc]). TRUC, used above, is still a bit new, so I'm leaving that in, but I think we can stop expanding that in future newsletters.

[harding]

Made edits for all feedback, thanks @LarryRuane @stefanwouldgo @renepickhardt @bitschmidty @azuchi ! Added lede, releases/RCs, and topic entries. Reviewed contributions by @bitschmidty and @Gustavojfe (thanks so much!). Thanks everyone!

[bitschmidty]

ACK lede, topics, and style guide updates