Skip to content

Conversation

harding
Copy link
Collaborator

@harding harding commented Sep 18, 2024

Comment on lines 40 to 146
- [Bitcoin Core 28.0rc1][] is a release candidate for the next major
version of the predominant full node implementation. A [testing
guide][bcc testing] is available.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

v28.0rc2 was tagged yesterday.

@Gustavojfe
Copy link
Contributor

just added merge summaries

situation (see [Newsletter #271][news271 noderc]).

- **DNS seeding for non-IP addresses:** FIXME:virtu [posted][virtu seed]
to Delving Bitcoin a survey of the availability of seed nodes for
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe

Suggested change
to Delving Bitcoin a survey of the availability of seed nodes for
to Delving Bitcoin a survey of the availability of seed nodes on
Suggested change
to Delving Bitcoin a survey of the availability of seed nodes for
to Delving Bitcoin a survey of the availability of seed nodes for

She can provide the authentication token to Bob using [NFC][] or
another widely available data transfer protocol that doesn't require
Alice to access the internet, keeping the protocol simple enough to
implement even on devices with limited computing resources, like smart
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
implement even on devices with limited computing resources, like smart
implement, even on devices with limited computing resources, like smart
Suggested change
implement even on devices with limited computing resources, like smart
implement even on devices with limited computing resources, like smart

limit was no longer sufficient to complete an Initial Block Download (IBD)
without flushing the UTXO set from RAM to disk. It was decided to remove the
limit altogether, rather than raise it, because there was no optimal value
that would be future-proof, and to give users complete flexibility.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be interesting for readers, the research Lopp did that found 25% improvement w/ no flush: bitcoin/bitcoin#28358 (comment)

[zmn lnoff]: https://delvingbitcoin.org/t/privately-sending-payments-while-offline-with-bolt12/1134/2
[t-bast lnoff]: https://delvingbitcoin.org/t/privately-sending-payments-while-offline-with-bolt12/1134/4
[news271 noderc]: /en/newsletters/2023/10/04/#secure-remote-control-of-ln-nodes
[delving cluster]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[delving cluster]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303
[delving cluster]: https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303#h-2-finding-high-feerate-subsets-5

mempool][topic cluster mempool] project. See Newsletter [#315][news315
cluster].

- [Bitcoin Core #30807][] changes the signaling of a [assumeUTXO][topic
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [Bitcoin Core #30807][] changes the signaling of a [assumeUTXO][topic
- [Bitcoin Core #30807][] changes the signaling of an [assumeUTXO][topic


- [Bitcoin Core #30807][] changes the signaling of a [assumeUTXO][topic
assumeutxo] node that is syncing the background chain from `NODE_NETWORK` to
`NODE_NETWORK_LIMITED` so that peer nodes don’t request a block from it. This
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe

Suggested change
`NODE_NETWORK_LIMITED` so that peer nodes don’t request a block from it. This
`NODE_NETWORK_LIMITED` so that peer nodes don’t request a historical block from it. This

fixes a bug where a peer would request a historical block and get no response,
causing it to disconnect from the assumeUTXO node.

- [LND #8981][] refactors the `paymentDescriptor` type to quarantine it within
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be good to note briefly what quarantining the type means

development branch, so those changes will likely not be released until
about six months after the release of the upcoming version 28._

- [Bitcoin Core #28358][] drops the `dbcache` limit because the previous 16GB
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [Bitcoin Core #28358][] drops the `dbcache` limit because the previous 16GB
- [Bitcoin Core #28358][] drops the `dbcache` limit because the previous 16 GB

- [Bitcoin Core #28358][] drops the `dbcache` limit because the previous 16GB
limit was no longer sufficient to complete an Initial Block Download (IBD)
without flushing the UTXO set from RAM to disk. It was decided to remove the
limit altogether, rather than raise it, because there was no optimal value
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
limit altogether, rather than raise it, because there was no optimal value
limit altogether rather than raise it, because there was no optimal value

that would be future-proof, and to give users complete flexibility.

- [Bitcoin Core #30286][] optimizes the candidate search algorithm used in
cluster linearizations, based on the framework laid out in the Section 2 of
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
cluster linearizations, based on the framework laid out in the Section 2 of
cluster linearizations, based on the framework laid out in Section 2 of

payments, and summarizes research about DNS seeding for non-IP network
addresses. Also included are our regular sections describing changes to
clients and services, announcing new releases and release candidates,
and summarizing notable changes to popular Bitcoin infrastruture
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
and summarizing notable changes to popular Bitcoin infrastruture
and summarizing notable changes to popular Bitcoin infrastructure

@harding
Copy link
Collaborator Author

harding commented Sep 20, 2024

Made edits for all feedback; added lede; updated releases/RCs; and reviewed other contributions. Also updated topic entries for this newsletter and also newsletters 319 and 320, which I ran out of time to do. Thanks everyone (and apologies for my tardiness)!

@bitschmidty
Copy link
Contributor

Pushed a small change to the news section. ACK topics from 321, 320, 319. Squashed. Thank you @harding @Gustavojfe @azuchi @vostrnad for contributing this week!

@bitschmidty bitschmidty merged commit ae4fee4 into bitcoinops:master Sep 20, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants