@@ -125,7 +125,7 @@ describing notable changes to popular Bitcoin infrastructure software.
125
125
the attack is prevented using a soft fork.
126
126
127
127
At the time of writing, the tradeoffs between proposed solutions were
128
- being discussed.
128
+ being discussed. {% assign timestamp="1:05" %}
129
129
130
130
- ** Onion message DoS risk discussion:** Gijs van Dam [ posted] [ vandam
131
131
onion] to Delving Bitcoin to discuss a recent [ paper] [ bk onion ] by
@@ -141,7 +141,7 @@ describing notable changes to popular Bitcoin infrastructure software.
141
141
Matt Corallo suggested first trying a previously proposed idea (see
142
142
[ Newsletter #207 ] [ news207 onion ] ) to provide back pressure on nodes
143
143
sending too many onion messages before working on anything more
144
- complicated.
144
+ complicated. {% assign timestamp="14:20" %}
145
145
146
146
- ** Optional identification and authentication of LN payers:** Bastien
147
147
Teinturier [ posted] [ teinturier auth ] to Delving Bitcoin to propose
@@ -167,7 +167,7 @@ describing notable changes to popular Bitcoin infrastructure software.
167
167
168
168
Feedback on which cryptographic methods to use is requested, with
169
169
Teinturier planning to release [ BLIP42] [ blips #42 ] with a
170
- specification for the methods selected.
170
+ specification for the methods selected. {% assign timestamp="28:04" %}
171
171
172
172
- ** Bitcoin Core switch to CMake build system:** Cory Fields
173
173
[ posted] [ fields cmake ] to the Bitcoin-Dev mailing list to announce
@@ -188,7 +188,7 @@ describing notable changes to popular Bitcoin infrastructure software.
188
188
(anticipated about 7 months from now). The earlier you test, the more
189
189
time Bitcoin Core developers will have to fix problems before the
190
190
release of version 29---increasing the chance that they can prevent
191
- problems in the released code from affecting your configuration.
191
+ problems in the released code from affecting your configuration. {% assign timestamp="36:15" %}
192
192
193
193
## Releases and release candidates
194
194
@@ -201,13 +201,13 @@ release candidates.*
201
201
` bdk ` Rust crate has been renamed to ` bdk_wallet ` and lower layer
202
202
modules have been extracted into their own crates, including
203
203
` bdk_chain ` , ` bdk_electrum ` , ` bdk_esplora ` , and ` bdk_bitcoind_rpc ` .
204
- The ` bdk_wallet ` crate "is the first version to offer a stable 1.0.0 API."
204
+ The ` bdk_wallet ` crate "is the first version to offer a stable 1.0.0 API." {% assign timestamp="53:55" %}
205
205
206
206
- [ Core Lightning 24.08rc2] [ ] is a release candidate for the next major
207
- version of this popular LN node implementation.
207
+ version of this popular LN node implementation. {% assign timestamp="54:10" %}
208
208
209
209
- [ LND v0.18.3-beta.rc1] [ ] is a release candidate for a minor bug fix
210
- release of this popular LN node implementation.
210
+ release of this popular LN node implementation. {% assign timestamp="54:29" %}
211
211
212
212
## Notable code and documentation changes
213
213
@@ -227,12 +227,12 @@ repo], and [BINANAs][binana repo]._
227
227
loading the snapshot and start downloading blocks from that much-older block.
228
228
Although older blocks still need to be downloaded for assumeUTXO's
229
229
background validation, newer blocks should receive priority so that
230
- users can see whether their recent transactions have been confirmed.
230
+ users can see whether their recent transactions have been confirmed. {% assign timestamp="55:01" %}
231
231
232
232
- [ Bitcoin Core #30598 ] [ ] removes block height from the [ assumeUTXO] [ topic
233
233
assumeutxo] snapshot file metadata as it is not a unique identifier in a
234
234
pre-sanitized untrusted file compared to the block hash that is kept. A node
235
- can still obtain block height from many other internal sources.
235
+ can still obtain block height from many other internal sources. {% assign timestamp="59:29" %}
236
236
237
237
- [ Bitcoin Core #28280 ] [ ] optimizes Initial Block Download (IBD) performance for
238
238
pruned nodes by not emptying the UTXO cache during pruning flushes. It does
@@ -241,27 +241,27 @@ repo], and [BINANAs][binana repo]._
241
241
unnecessarily scanning the entire cache during prune flushes and instead focus
242
242
on the dirty entries. The optimization results in up to 32% faster IBD for
243
243
pruned nodes with high ` dbcache ` settings, and about 9% improvement with
244
- default settings. See Newsletter [ #304 ] [ news304 cache ] .
244
+ default settings. See Newsletter [ #304 ] [ news304 cache ] . {% assign timestamp="1:02:18" %}
245
245
246
246
- [ Bitcoin Core #28052 ] [ ] adds [ XOR] [ ] encoding to ` blocksdir *.dat ` files on
247
247
creation as a preventative mechanism against unintentional and accidental data
248
248
corruption by anti-virus or similar software. This can be
249
249
optionally disabled and doesn't protect against intentional data corruption
250
250
attacks. This was implemented for the ` chainstate ` files in [ Bitcoin Core
251
251
#6650 ] [ ] in September 2015 and the mempool in [ #28207 ] [ bitcoin core
252
- #28207 ] in November 2023 (see [ Newsletter #277 ] [ news277 bcc28207 ] ).
252
+ #28207 ] in November 2023 (see [ Newsletter #277 ] [ news277 bcc28207 ] ). {% assign timestamp="1:04:47" %}
253
253
254
254
- [ Core Lightning #7528 ] [ ] adjusts the [ fee rate estimation] [ topic fee
255
255
estimation] for sweeps of non-time-sensitive unilateral channel closures to an
256
256
absolute deadline of 2016 blocks (approximately 2 weeks). Previously, the fee
257
257
rate was set to target confirmation within 300 blocks, which sometimes caused
258
258
transactions to be stuck at the [ minimum relay fee limit] [ topic default
259
- minimum transaction relay feerates] , resulting in indefinite delays.
259
+ minimum transaction relay feerates] , resulting in indefinite delays. {% assign timestamp="1:08:01" %}
260
260
261
261
- [ Core Lightning #7533 ] [ ] updates the internal coin movement notifications and
262
262
the transaction bookkeeper to properly account for the spending of funding
263
263
outputs for [ splicing] [ topic splicing ] transactions. Previously, there was no
264
- logging or tracking of this.
264
+ logging or tracking of this. {% assign timestamp="1:10:11" %}
265
265
266
266
- [ Core Lightning #7517 ] [ ] introduces ` askrene ` , a new experimental plugin and
267
267
API infrastructure for minimum-cost pathfinding based on the ` renepay ` plugin
@@ -272,40 +272,40 @@ repo], and [BINANAs][binana repo]._
272
272
along with their estimated probability of success. Several other RPC commands
273
273
are added to manage routing data in layers by adding channels, manipulating
274
274
channel data, excluding nodes from routing, inspecting layer data, and
275
- managing ongoing payment attempts.
275
+ managing ongoing payment attempts. {% assign timestamp="1:11:19" %}
276
276
277
277
- [ LND #8955 ] [ ] adds an optional ` utxo ` field on the ` sendcoins ` command (and
278
278
` Outpoints ` for the corresponding ` SendCoinsRequest ` RPC command) to simplify
279
279
the [ coin selection] [ topic coin selection ] user experience to a single step.
280
280
Previously, a user had to go through a multi-step command process that
281
281
included coin selection, fee estimation, [ PSBT] [ topic psbt ] funding, PSBT
282
- completion, and transaction broadcasting.
282
+ completion, and transaction broadcasting. {% assign timestamp="1:13:08" %}
283
283
284
284
- [ LND #8886 ] [ ] updates the ` BuildRoute ` function to support [ inbound forwarding
285
285
fees] [ topic inbound forwarding fees ] by reversing the pathfinding process, now
286
286
working from receiver to sender, allowing for more accurate fee calculations
287
287
over multiple hops. See Newsletter [ #297 ] [ news297 inboundfees ] for more on
288
- inbound fees.
288
+ inbound fees. {% assign timestamp="1:14:39" %}
289
289
290
290
- [ LND #8967 ] [ ] adds a new wire message type ` Stfu ` (SomeThing Fundamental is
291
291
Underway) designed to lock the channel state before initiating [ protocol
292
292
upgrades] [ topic channel commitment upgrades ] . The ` Stfu ` message type includes
293
293
fields for the channel id, an initiator flag, and additional data for
294
294
potential future extensions. This is part of the Quiescence protocol
295
- implementation (see Newsletter [ #309 ] [ news309 quiescence ] ).
295
+ implementation (see Newsletter [ #309 ] [ news309 quiescence ] ). {% assign timestamp="1:19:45" %}
296
296
297
297
- [ LDK #3215 ] [ ] checks that a transaction is at least 65 bytes long to protect
298
298
against an [ unlikely and costly attack] [ spv attack ] against a light client SPV
299
299
wallet where a valid SPV proof can be created for a fake 64-byte transaction
300
300
by matching the hash of an inner merkle node. See [ merkle tree
301
- vulnerabilities] [ topic merkle tree vulnerabilities ] .
301
+ vulnerabilities] [ topic merkle tree vulnerabilities ] . {% assign timestamp="1:22:13" %}
302
302
303
303
- [ BLIPs #27 ] [ ] adds BLIP04 for an experimental [ HTLC endorsement] [ topic htlc
304
304
endorsement] signaling protocol proposal to partially mitigate [ channel
305
305
jamming attacks] [ topic channel jamming attacks ] on the network. It outlines
306
306
the experimental endorsement TLV values, the deployment approach, and the
307
307
eventual deprecation of the experimental phase when HTLC endorsements are
308
- merged into the BOLTs.
308
+ merged into the BOLTs. {% assign timestamp="1:26:27" %}
309
309
310
310
{% assign four_days_after_posting = page.date | date: "%s" | plus: 345600 | date: "%Y-%m-%d 14:30" %}
311
311
{% include snippets/recap-ad.md when=four_days_after_posting %}
0 commit comments