Skip to content

Commit 3a49859

Browse files
hardingbitschmidty
harding
authored and
bitschmidty
committed
Newsletters: add 261 (2023-07-26)
1 parent 4dd60a5 commit 3a49859

10 files changed

+473
-0
lines changed

‎_posts/en/newsletters/2023-07-26-newsletter.md‎

Lines changed: 215 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,215 @@
1+
---
2+
title: 'Bitcoin Optech Newsletter #261'
3+
permalink: /en/newsletters/2023/07/26/
4+
name: 2023-07-26-newsletter
5+
slug: 2023-07-26-newsletter
6+
type: newsletter
7+
layout: newsletter
8+
lang: en
9+
---
10+
This week's newsletter describes a protocol for simplifying the
11+
communication related to mutual closing of LN channels and summarizes
12+
notes from a recent meeting of LN developers. Also included are our
13+
regular sections with popular questions and answers from the Bitcoin
14+
Stack Exchange, announcements of new releases and release candidates, and
15+
descriptions of notable changes to popular Bitcoin infrastructure
16+
projects.
17+
18+
## News
19+
20+
- **Simplified LN closing protocol:** Rusty Russell [posted][russell
21+
closing] to the Lightning-Dev mailing list a proposal that simplifies
22+
the process of two LN nodes mutually closing a channel they share.
23+
With the new closing protocol, one of the nodes tells its peer that it
24+
wants to close the channel and indicates the amount of transaction fee
25+
it will pay. That closing initiator will be responsible for the entire fee,
26+
although both outputs of a typical mutual close transaction will be
27+
immediately spendable so either party will be able to use [CPFP fee
28+
bumping][topic cpfp] in the normal case. The new protocol is also
29+
compatible with exchanging information for [MuSig2][topic musig]-based
30+
[scriptless multisignatures][topic multisignature], which are part of
31+
in-development upgrades to LN that will increase privacy and lower
32+
onchain fee costs.
33+
34+
No comments on Russell's proposal had been posted to the mailing
35+
list as of this writing but some initial comments had been posted to
36+
his [pull request][bolts #1096] with the complete proposal.
37+
38+
- **LN Summit notes:** Carla Kirk-Cohen [posted][kc notes] to the
39+
Lightning-Dev mailing list a summary of several discussions from the
40+
recent meeting of LN developers in New York City. Some of the topics
41+
discussed included:
42+
43+
- *Reliable transaction confirmation:* [package relay][topic package
44+
relay], [v3 transaction relay][topic v3 transaction relay],
45+
[ephemeral anchors][topic ephemeral anchors], [cluster
46+
mempool][topic cluster mempool], and other topics related to
47+
transaction relay and mining were discussed in the context of how
48+
they will provide a clearer path to allowing LN onchain
49+
transactions confirm more reliably, without the threat of [transaction
50+
pinning][topic transaction pinning] or needing to overpay fees
51+
when using [CPFP][topic cpfp] or [RBF][topic rbf] fee bumping. We
52+
strongly recommend readers with an interest in transaction relay
53+
policy, which affects almost all second-layer protocols, read the
54+
notes for the insightful feedback provided by LN developers on
55+
several ongoing initiatives.
56+
57+
- *Taproot and MuSig2 channels:* a brief discussion about the progress of
58+
channels that use [P2TR][topic taproot] outputs and [MuSig2][topic
59+
musig] for signatures. A significant portion of the notes for this
60+
discussion was about a simplified mutual close protocol; see the previous
61+
news item for one of the results of that discussion.
62+
63+
- *Updated channel announcements:* the LN gossip protocol currently only
64+
relays announcements of new or updated channels if those channels were
65+
funded using a P2WSH output that committed to a 2-of-2
66+
`OP_CHECKMULTISIG` script. For moving to [P2TR][topic taproot]
67+
outputs with [MuSig2][topic musig]-based [scriptless
68+
multisignature][topic multisignature] commitments, the gossip
69+
protocol will need to be updated. A [topic][topic channel
70+
announcements] also discussed during the previous in-person
71+
meeting of LN developers (see [Newsletter #204][news204 gossip])
72+
has been whether to make a minimal update to the protocol (called
73+
v1.5 gossip) that just adds support for P2TR outputs or a more
74+
general update to the protocol (called v2.0) that more broadly
75+
allows a valid signature for any UTXO of any type to be used for
76+
announcements. Allowing any output to be used means that the
77+
output used to announce the channel is less likely than it is
78+
today to be the output actually being used to operate the channel,
79+
breaking the public link between outputs and channel funding.
80+
81+
An additional consideration discussed was whether a UTXO with a value of
82+
_n_ should be allowed to announce a channel with a capacity greater than
83+
_n_. This could allow channel participants to keep some of their funding
84+
transactions private. For example, Alice and Bob could open two separate
85+
channels with each other; they could use one channel to create an
86+
announcement for greater than the value of the channel, making it clear
87+
that they could forward LN payments greater than the capacity of that
88+
channel using their other channel which had not been associated with a
89+
UTXO and so were more private. This would help increase the plausibility
90+
that any output on the network, even one that had never been gossiped
91+
about in LN, was being used for an LN channel.
92+
93+
The notes indicate a compromise decision, "v1.75 gossip", which
94+
seemed to allow using any script but with no available value
95+
multiplier.
96+
97+
- *PTLCs and redundant overpayment:* from the notes, adding support for
98+
[PTLCs][topic ptlc] to the protocol was briefly discussed, mostly in
99+
relation to [signature adaptors][topic adaptor signatures]. More text in
100+
the notes was devoted to an improvement that would affect similar
101+
parts of the protocol: the ability to [redundantly overpay][topic
102+
redundant overpayments] an invoice and receive a refund for most
103+
or all of the overpayment. For example, Alice wants to ultimately
104+
pay Bob 1 BTC. She initially sends Bob 20 [multipath
105+
payments][topic multipath payments] each worth 0.1 BTC. Using
106+
either math (via a technique called _Boomerang_, see [Newsletter
107+
#86][news86 boomerang]) or layered commitments and an extra
108+
communication round (called _Spear_), Bob is only able to claim a
109+
maximum of 10 of the payments; any others that arrive at his node
110+
are rejected. The advantage of this approach is that up to 10 of
111+
Alice's MPP shards can fail to reach Bob without delaying the
112+
payment. The downsides appear to be extra complexity and possibly
113+
(in the case of Spear) slower speed than today in the best case
114+
where every shard reaches Bob. The participants discussed whether
115+
any changes that would help support redundant overpayments could
116+
be made at the same time as the changes necessary for PTLCs.
117+
118+
- *Channel jamming mitigation proposals:* a substantial portion of
119+
the notes summarized discussion about proposals to mitigate
120+
[channel jamming attacks][topic channel jamming attacks]. The
121+
discussion started with a claim that no known single solution
122+
(such as reputation or upfront fees) can satisfactorily address
123+
the problem by itself without producing unacceptable downside.
124+
Reputation by itself must make allowances for new nodes without
125+
reputation and for the natural rate of failed HTLCs---provisions
126+
which an attacker can use to cause some level of harm, even if
127+
less than they could today. Upfront fees by themselves must
128+
be set high enough to discourage attackers, but that might be high
129+
enough to also discourage honest users and to create a perverse
130+
incentive for nodes to deliberately fail to forward a payment.
131+
Instead, it was proposed that using several methods together might
132+
obtain the benefits without producing the worst-case costs.
133+
134+
After examining the current understanding, the discussion notes
135+
focused on details about testing the local reputation scheme
136+
described in [Newsletter #226][news226 jamming] and setting the
137+
stage for a later implementation of low upfront fees to go along
138+
with it. From the notes, it seemed like the participants
139+
supported seeing the proposal tested.
140+
141+
- *Simplified commitments:* participants discussed the simplified
142+
commitments protocol idea (see [Newsletter #120][news120 commitments]),
143+
that defines which peer is responsible for proposing
144+
the next change to the commitment transaction rather than allowing
145+
either peer to propose a new commitment transaction at any time.
146+
Putting one peer in charge eliminates the complexity of two
147+
proposals being sent at roughly the same time, such as both Alice
148+
and Bob wanting to add an [HTLC][topic htlc] simultaneously. A
149+
particular complication discussed in the notes were cases where
150+
one of the peers didn't want to accept the other's peer's
151+
proposal---a situation that's complicated to address in
152+
the current protocol. A downside of the simplified commitment
153+
approach is that it may increase latency in some cases, as the
154+
peer who is not currently responsible for proposing the next
155+
change will need to request that privilege from its counterparty
156+
before proceeding. The notes did not indicate a clear resolution
157+
to this discussion.
158+
159+
- *The specification process:* the participants discussed various
160+
ideas for improving the specification process and the documents it
161+
manages, including the current BOLTs and BLIPs plus other ideas
162+
for documentation. The discussion appeared highly varied and no
163+
clear conclusions were apparent from the notes.
164+
165+
## Selected Q&A from Bitcoin Stack Exchange
166+
167+
*[Bitcoin Stack Exchange][bitcoin.se] is one of the first places Optech
168+
contributors look for answers to their questions---or when we have a
169+
few spare moments to help curious or confused users. In
170+
this monthly feature, we highlight some of the top-voted questions and
171+
answers posted since our last update.*
172+
173+
{% comment %}<!-- https://bitcoin.stackexchange.com/search?tab=votes&q=created%3a1m..%20is%3aanswer -->{% endcomment %}
174+
{% assign bse = "https://bitcoin.stackexchange.com/a/" %}
175+
176+
FIXME:bitschmidty
177+
178+
## Releases and release candidates
179+
180+
*New releases and release candidates for popular Bitcoin infrastructure
181+
projects. Please consider upgrading to new releases or helping to test release candidates.*
182+
183+
- [HWI 2.3.0][] is a release of this middleware that allows software
184+
wallets to communicate with hardware signing devices. It adds support
185+
for DIY Jade devices and a binary for running the main `hwi` program
186+
on Apple Silicon hardware with MacOS 12.0+.
187+
188+
- [LDK 0.0.116][] is a release of this library for creating LN-enabled
189+
software. It includes support for [anchor outputs][topic anchor
190+
outputs] and [multipath payments][topic multipath payments] with
191+
[keysend][topic spontaneous payments].
192+
193+
## Notable code and documentation changes
194+
195+
*Notable changes this week in [Bitcoin Core][bitcoin core repo], [Core
196+
Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo],
197+
[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet
198+
Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay
199+
Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement
200+
Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], and
201+
[Bitcoin Inquisition][bitcoin inquisition repo].*
202+
203+
- [Bitcoin Core GUI #740][] Show own outputs on PSBT signing window FIXME:Murchandamus
204+
205+
{% include references.md %}
206+
{% include linkers/issues.md v=2 issues="740,1096" %}
207+
[russell closing]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004013.html
208+
[kc notes]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-July/004014.html
209+
[news193 gossip]: /en/newsletters/2022/03/30/#continued-discussion-about-updated-ln-gossip-protocol
210+
[news204 gossip]: /en/newsletters/2022/06/15/#gossip-network-updates
211+
[news86 boomerang]: /en/newsletters/2020/02/26/#boomerang-redundancy-improves-latency-and-throughput-in-payment-channel-networks
212+
[news226 jamming]: /en/newsletters/2022/11/16/#paper-about-channel-jamming-attacks
213+
[news120 commitments]: /en/newsletters/2020/10/21/#simplified-htlc-negotiation
214+
[hwi 2.3.0]: https://github.com/bitcoin-core/HWI/releases/tag/2.3.0
215+
[ldk 0.0.116]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.116

‎_topics/en/channel-announcements.md‎

Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
---
2+
title: Channel announcements
3+
4+
## Optional. Shorter name to use for reference style links e.g., "foo"
5+
## will allow using the link [topic foo][]. Not case sensitive
6+
# shortname: foo
7+
8+
## Optional. An entry will be added to the topics index for each alias
9+
#aliases:
10+
# - Foo
11+
12+
## Required. At least one category to which this topic belongs. See
13+
## schema for options
14+
categories:
15+
- Lightning Network
16+
17+
## Optional. Produces a Markdown link with either "[title][]" or
18+
## "[title](link)"
19+
primary_sources:
20+
- title: "BOLT7: P2P node and channel discovery"
21+
link: bolt7
22+
23+
## Optional. Each entry requires "title" and "url". May also use "feature:
24+
## true" to bold entry and "date"
25+
optech_mentions:
26+
- title: Gossip update proposed
27+
url: /en/newsletters/2019/07/17/#gossip-update-proposal
28+
29+
- title: Updated gossip proposal
30+
url: /en/newsletters/2022/02/23/#updated-ln-gossip-proposal
31+
32+
- title: Continued discussion about updated gossip proposal
33+
url: /en/newsletters/2022/03/30/#continued-discussion-about-updated-ln-gossip-protocol
34+
35+
- title: LN developer meeting discussion about gossip updates
36+
url: /en/newsletters/2022/06/15/#gossip-network-updates
37+
38+
- title: LN developer discussion about updated channel announcements
39+
url: /en/newsletters/2023/07/26/#updated-channel-announcements
40+
41+
## Optional. Same format as "primary_sources" above
42+
# see_also:
43+
# - title:
44+
# link:
45+
46+
## Optional. Force the display (true) or non-display (false) of stub
47+
## topic notice. Default is to display if the page.content is below a
48+
## threshold word count
49+
#stub: false
50+
51+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
52+
## Should be less than 500 characters
53+
excerpt: >
54+
**Channel announcements** are advertisements that a channel is
55+
available to forward payments. The advertisements are relayed through
56+
the LN gossip network.
57+
---
58+
Version 1 announcements require the nodes that want to advertise a
59+
channel prove that they control a UTXO for
60+
a P2WSH output for a 2-of-2 multisig script. Proposed upgrades to the
61+
announcements may allow UTXOs for other scripts to be used, making it
62+
possible to advertise channels that use [P2TR][topic taproot],
63+
[MuSig2][topic musig], and other technologies. Other improvements have
64+
been discussed that may break the link between UTXOs and specific
65+
channels.
66+
67+
{% include references.md %}
68+
{% include linkers/issues.md issues="" %}

‎_topics/en/channel-jamming-attacks.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -103,6 +103,9 @@ optech_mentions:
103103
- title: "LND #7710 allows retrieving extra data about an HTLC in support of jamming countermeasures"
104104
url: /en/newsletters/2023/06/28/#lnd-7710
105105

106+
- title: "LN developer discussion about channel jamming attacks"
107+
url: /en/newsletters/2023/07/26/#ptlcs-and-redundant-overpayment
108+
106109
## Optional. Same format as "primary_sources" above
107110
# see_also:
108111
# - title:

‎_topics/en/cluster-mempool.md‎

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
---
2+
title: Cluster mempool
3+
4+
## Optional. Shorter name to use for reference style links e.g., "foo"
5+
## will allow using the link [topic foo][]. Not case sensitive
6+
# shortname: foo
7+
8+
## Optional. An entry will be added to the topics index for each alias
9+
#aliases:
10+
# - Foo
11+
12+
## Required. At least one category to which this topic belongs. See
13+
## schema for options
14+
categories:
15+
- Transaction Relay Policy
16+
- Mining
17+
18+
## Optional. Produces a Markdown link with either "[title][]" or
19+
## "[title](link)"
20+
primary_sources:
21+
- title: "Bitcoin Core #27677: new mempool design"
22+
link: https://github.com/bitcoin/bitcoin/issues/27677
23+
24+
## Optional. Each entry requires "title" and "url". May also use "feature:
25+
## true" to bold entry and "date"
26+
optech_mentions:
27+
- title: "Bitcoin Core meeting transcript about mempool redesign"
28+
url: /en/newsletters/2023/05/17/#mempool-clustering
29+
30+
- title: "Mempool proposals, including cluster mempool"
31+
url: /en/blog/waiting-for-confirmation/#policy-proposals
32+
date: 2023-07-12
33+
34+
- title: "LN developer discussion about multiple relay policy topics, including cluster mempool"
35+
url: /en/newsletters/2023/07/26/#reliable-transaction-confirmation
36+
37+
## Optional. Same format as "primary_sources" above
38+
see_also:
39+
- title: Package relay
40+
link: topic package relay
41+
42+
- title: Replace-by-Fee
43+
link: topic rbf
44+
45+
## Optional. Force the display (true) or non-display (false) of stub
46+
## topic notice. Default is to display if the page.content is below a
47+
## threshold word count
48+
#stub: false
49+
50+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
51+
## Should be less than 500 characters
52+
excerpt: >
53+
**Cluster mempool** is a proposal to associate each unconfirmed
54+
transaction in a mempool with related transactions, creating a
55+
cluster. Each cluster of transactions, whether it be a single
56+
transaction or several transactions, can be ordered from most
57+
desirable to mine to least desirable, allowing operations for adding
58+
or removing new clusters to complete fast enough to use them in P2P
59+
network code.
60+
61+
---
62+
If P2P network code can determine whether a new unconfirmed transaction
63+
(or cluster of transactions) will improve the profitability of the
64+
mempool for miners in the near term, that criteria can be used instead
65+
of other heuristics for determining when a transaction [package][topic
66+
package relay] or [replacement][topic rbf] should be accepted. It is
67+
hoped that this will allow transaction relay to provide more flexible
68+
policy without exposing relay nodes to new resource-wasting attacks.
69+
70+
{% include references.md %}
71+
{% include linkers/issues.md issues="" %}

‎_topics/en/ephemeral-anchors.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -41,6 +41,9 @@ optech_mentions:
4141
- title: "Bitcoin Inquisition #23 adds part of the support for ephemeral anchors"
4242
url: /en/newsletters/2023/04/26/#bitcoin-inquisition-23
4343

44+
- title: "LN developer discussion about multiple relay policy topics, including ephemeral anchors"
45+
url: /en/newsletters/2023/07/26/#reliable-transaction-confirmation
46+
4447
## Optional. Same format as "primary_sources" above
4548
see_also:
4649
- title: V3 Transaction Relay

‎_topics/en/musig.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -114,6 +114,9 @@ optech_mentions:
114114
- title: "Lightning Lab's Loop now uses MuSig2 by default for lower fees and improved privacy"
115115
url: /en/newsletters/2023/05/24/#lightning-loop-defaults-to-musig2
116116

117+
- title: "Taproot and MuSig2 LN channels"
118+
url: /en/newsletters/2023/07/26/#taproot-and-musig2-channels
119+
117120
## Optional. Same format as "primary_sources" above
118121
see_also:
119122
- title: Multisignatures

‎_topics/en/package-relay.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -107,6 +107,9 @@ optech_mentions:
107107
- title: Suggestion to perform package relay using Nostr protocol
108108
url: /en/newsletters/2023/05/31/#transaction-relay-over-nostr
109109

110+
- title: "LN developer discussion about multiple relay policy topics, including package relay"
111+
url: /en/newsletters/2023/07/26/#reliable-transaction-confirmation
112+
110113
## Optional. Same format as "primary_sources" above
111114
see_also:
112115
- title: CPFP fee bumping

0 commit comments

Comments
 (0)