Newsletters: add 359 (2025-06-20) #2385
Conversation
renepickhardt
left a comment
renepickhardt
left a comment
There was a problem hiding this comment.
I added a small subtlety about the definition of a feasible payment. Recall the following definition:
A payment from
srctodestof amountxis feasible if and only if the liquidity in the network is distributed in a way that thesrc-dest-mincut is larger or equal thanx.
Due to conservation of flow any circulation does not change any min cut in the network. Thus circulations (aka offchain rebalancing) cannot change the feasibility of payments.
|
|
||
| - **Channel rebalancing research:** Rene Pickhardt [posted][pickhardt | ||
| rebalance] to Delving Bitcoin an idea for rebalancing channels across | ||
| LN that attempts to maximize the rate of payment feasibility across |
There was a problem hiding this comment.
I thik I was operationally a bit blind while writing my post and thus I didn't make the following subtlety clear:
Offchain- rebalancing does not and cannot change the feasibility of payments - as it was discussed on lightning-dev back in 2018. What it does is to make feasible payments more reliable and thus help nodes to more quickly decide if a payment might be infeasible.
There was a problem hiding this comment.
Mayebe this would be more precise:
Rene Pickhardt posted to Delving Bitcoin an idea for rebalancing channels across LN that attempts to maximizes the reliabilty of feasible of payments across the whole network.
Meta comment: It's btw less an idea how to do it and more a limit on what would be possible in optimal circumstances.
| - **Proposal to restrict access to Bitcoin Core Project discussion:** | ||
| Bryan Bishop [posted][bishop priv] to the Bitcoin-Dev mailing list to | ||
| suggest that the Bitcoin Core Project limit public access to | ||
| discussions among its members in order to reduce the amount of |
There was a problem hiding this comment.
| discussions among its members in order to reduce the amount of | |
| discussions among its members to reduce the amount of |
There was a problem hiding this comment.
Keeping as-is. There's a lot of "to"s in this sentence, adding the extra words here makes that a bit jarring. (Rewriting might be better, but this paragraph has already been revised twice so let's stick with what we have.)
| discussions among its members in order to reduce the amount of | ||
| disruption caused by non-members. He analogized this to | ||
| "privatizing Bitcoin Core" the way private companies rarely publicly | ||
| share internal team discussions, shielding their individual employees |
There was a problem hiding this comment.
| share internal team discussions, shielding their individual employees | |
| share internal team discussions, shielding their employees |
|
|
||
| Bishop's post suggests a method for implementing the policy, but | ||
| Antoine Poinsot [questioned][poinsot priv] whether that method would | ||
| actually achieve the goal. Poinsot also suggested that many private |
There was a problem hiding this comment.
| actually achieve the goal. Poinsot also suggested that many private | |
| achieve the goal. Poinsot also suggested that many private |
| Antoine Poinsot [questioned][poinsot priv] whether that method would | ||
| actually achieve the goal. Poinsot also suggested that many private | ||
| office discussions might occur not out of fear of public reproach but | ||
| because of "the natural advantages of in-persion discussions". |
There was a problem hiding this comment.
| because of "the natural advantages of in-persion discussions". | |
| because of "the natural advantages of in-person discussions." |
| office discussions might occur not out of fear of public reproach but | ||
| because of "the natural advantages of in-persion discussions". | ||
|
|
||
| Several replies suggested, in essence, that making major changes is |
There was a problem hiding this comment.
| Several replies suggested, in essence, that making major changes is | |
| Several replies suggested that making major changes is |
|
|
||
| Several replies suggested, in essence, that making major changes is | ||
| probably not warranted at this time but that stronger moderation of | ||
| comments on the repository would probably alleviate the most |
There was a problem hiding this comment.
| comments on the repository would probably alleviate the most | |
| comments on the repository would alleviate the most |
|
|
||
| Pickhardt notes that there are several challenges to this approach and | ||
| asks interested parties to answer a few questions, such as whether | ||
| this is an approach worth pursuing and how to address certain |
There was a problem hiding this comment.
| this is an approach worth pursuing and how to address certain | |
| this approach is worth pursuing and how to address certain |
| rebalance] to Delving Bitcoin an idea for rebalancing channels across | ||
| LN that attempts to maximize the rate of payment feasibility across |
There was a problem hiding this comment.
maybe
| rebalance] to Delving Bitcoin an idea for rebalancing channels across | |
| LN that attempts to maximize the rate of payment feasibility across | |
| rebalance] to Delving Bitcoin an idea for rebalancing channels across | |
| the LN that attempts to maximize the rate of payment feasibility across |
bitschmidty
left a comment
bitschmidty
left a comment
There was a problem hiding this comment.
Couple suggestions for @Gustavojfe
| repo], and [BINANAs][binana repo]._ | ||
|
|
||
| - [Eclair #3110][] raises the delay for marking a channel as closed after its | ||
| funding output is spent from 12 (see Newsletter [#337][news337 delay]) to 72 |
There was a problem hiding this comment.
might be worth noting this change is based on lightning/bolts#1270
|
|
||
| - LDK #3623 extends [peer storage][topic peer storage] (see Newsletter | ||
| [#342][news342 peer]) to provide automatic, encrypted peer backups. Each | ||
| block, `ChainMonitor` packages a versioned, timestamped, and serialized |
There was a problem hiding this comment.
maybe?
| block, `ChainMonitor` packages a versioned, timestamped, and serialized | |
| block, `ChainMonitor` packages versioned, timestamped, and serialized |
| Both Poinsot and Sebastian "The Charlatan" Kung, the only two highly | ||
| active Bitcoin Core contributors to reply to the thread as of the time | ||
| of writing, [indicated][kung priv] that they don't think a major | ||
| change is necessary. |
There was a problem hiding this comment.
Well, in addition to those two replies, also @ryanofsky posted a reply, although I can't speak to his level of activity lately (I literally don't know): bitcoin-core/meta#19 (comment)
Yes, I love all your suggestions including your "case for privatizing" the core repo. I feel like you are playing chess and thinking several moves ahead while others including myself are focusing on more immediate and incremental responses. I do think the more hierarchical and closed solutions you propose will inevitably develop and start to become more prevalent in the future (for better and worse). But I think even if we were all fully on board with implementing these defenses, probably we would want to do it in an incremental way. So I’m not sure what clear next steps you might recommend. I am also often not sure when reading your posts what your goals are on a practical level. Like it is unclear if your main concern is developers getting burned out, or spending too much time reading spam, or something else.
| - **Proposal to restrict access to Bitcoin Core Project discussion:** | ||
| Bryan Bishop [posted][bishop priv] to the Bitcoin-Dev mailing list to | ||
| suggest that the Bitcoin Core Project limit the public's ability to | ||
| participate in project discussions in order to reduce the amount of | ||
| disruption caused by non-contributors. He analogized this to | ||
| "privatizing Bitcoin Core" the way private companies rarely publicly | ||
| share internal team discussions, shielding their individual employees | ||
| from public reproach that drains their time and emotional energy. He | ||
| points to examples of this privatization already happening on an ad | ||
| hoc basis in private offices with multiple Bitcoin Core contributors, | ||
| but warns that leaves out many contributors who work remotely. |
There was a problem hiding this comment.
He analogized this to "privatizing Bitcoin Core"
Well, only in the title of the post. Elsewhere, I describe what my proposal is, and to me it does not seem like what private companies tend to do..
the way private companies rarely publicly share internal team discussions, shielding their individual employees from public reproach that drains their time and emotional energy.
I don't see how my email proposes a mechanism to shield or prevent public reproach (public criticism). To be fair you do call it an analogy, so perhaps if you squint hard enough then the analogy might hold...? But at the same time, the email specifically mentions options like instantaneously mirroring or synchronizing internal comments and PR code review (etc) to public access sites or other mirrors. Such mirroring activity is, I believe, fundamentally incompatible with "shielding .. from public reproach [criticism]".
The core contribution of my "case for privatizing Bitcoin Core" was an insight into how developer attention and resources are drained, and how brigading works. It starts, for example, when a link is posted to GitHub on social media. Anyone who clicks the link is able to sign up and post a comment in a developer-focused site that appears without moderation, without delay, without agreeing to any community norms, with very minimal friction, which naturally leads many people to post irrelevant, confused, misleading, sometimes spammy comments, although sometimes also valuable comments. The insight though is that we can choose to use or configure our tools to create an online space specifically reserved for developers to collaborate together. Doing that does not also restrict our ability to synchronize or mirror comments, code review, issues, or other posts to other sites that offer universal public write access.
From my email:
In practice, the way that this would roll out is that the GitHub would continue to be the GitHub and would not really change. There would be a separate private area for some developers to work together. Then they would throw it over the wall or have some sort of (possibly real-time) synchronization protocol to synchronize pull requests to the public GitHub repository. If you want a public link on X.com then link to that, but a link to the membership-required site won't work for non-members.
and:
... would likely push changes out to various public access githubs or other locations on an hourly, daily or regular basis. Bitcoin Core, as it exists today, could do the same for pull requests, code review comments, etc, and post them publicly on a website. Anyone would be free to make a website where any person, including non-developers and including non-contributors, could freely post code review or comments. This could even happen on the current GH bitcoin/bitcoin repository. For example, any of the private code review comments can be posted directly into the PR on GH. PGP signatures can be used for verifiable comment attribution. Or another website can be linked from a GH PR to display the private-originated review history. ...
To be very fair to the literal reader, I did not explicitly say that besides PRs being posted and synchronized, that issues and issue comments could also be mirrored to different sites. However, these are definitely options that are feasible for software to implement, while meeting the original intent of my email.
Important disclaimer. I do not claim to be a clear writer and I am sure my posts could use improvement. If the literal reading demands that I was arguing in favor of placing development beyond reproach (or something like that), then perhaps I need to send another email clarifying that was not my intent? Although possibly my other existing replies on the mailing list already do this sufficiently... if I need to be flogged in public for poor writing ability, so be it, just call it a flogging though :-)
There was a problem hiding this comment.
If the literal reading demands that I was arguing in favor of placing development beyond reproach [...]
I wrote "shielding from public reproach", which seems quite different than "placing beyond reproach". In any case, I dropped the analogy. I'm sorry you didn't feel that it accurately reflected your writing. I may have been projecting: there are days when I wish I still worked for a private organization where nobody outside the organization knew who I was or cared what I did. I could just do my work and collect a paycheck.
There was a problem hiding this comment.
It's fine. We got somewhere better. I was projecting a little due to other misinterpretation, not yours, that I have noticed or received.
More broadly, the community definitely needs to spend some more time thinking about what boundaries makes sense for our volunteers, promoting healthy boundaries, and promoting healthy ways of interfacing with the general public that don't involve everyone being individually responsible for receiving every misunderstanding (or worse) from the general public.
|
Pushed edits for @renepickhardt and @kanzure feedback. Will address grammar feedback and add remaining content later. |
|
I think that is an improvement. Thank you. |
|
|
||
| - [Eclair #3110][] raises the delay for marking a channel as closed after its | ||
| funding output is spent from 12 (see Newsletter [#337][news337 delay]) to 72 | ||
| blocks as specified in [BOLTs #1270][], to allow for the propagation of a |
There was a problem hiding this comment.
| blocks as specified in [BOLTs #1270][], to allow for the propagation of a | |
| blocks, as specified in [BOLTs #1270][], to allow for the propagation of a |
| to work properly. | ||
|
|
||
| - [LDK #3623][] extends [peer storage][topic peer storage] (see Newsletter | ||
| [#342][news342 peer]) to provide automatic, encrypted peer backups. Each |
There was a problem hiding this comment.
| [#342][news342 peer]) to provide automatic, encrypted peer backups. Each | |
| [#342][news342 peer]) to provide automatic, encrypted peer backups. For each |
| is updated to handle `peer_storage_retrieval` requests by triggering a new | ||
| blob send. | ||
|
|
||
| - [BTCPay Server #6755][] enhances the [coin selection][topic coin selection] |
There was a problem hiding this comment.
@Gustavojfe FYI, although BTCPay server calls this "coin selection", I think it's more of a "coin control" interface. The distinction between the two can be fuzzy, but coin selection is usually an automated process that attempts to choose the best inputs to include in a transaction (where "best" can be defined based on cost metrics, privacy, or other criteria). "Coin control" is a manual process where users override the coin selection algorithm based on their knowledge of what they want (e.g. more privacy or a more consolidated wallet).
I'm going to drop the link and change the term.
bitschmidty
force-pushed
the
2025-06-20-newsletter
branch
from
17071f6 to
e08086d
Compare
6 participants
Note: I added a description of an Rust Libsecp256k1 merge to the notable merge section by request.