News: add 72 (2019-11-13) #266

harding · 2019-11-11T04:12:41Z

No description provided.

moneyball · 2019-11-11T06:28:53Z

_posts/en/newsletters/2019-11-13-newsletter.md

+{% endcomment %}
+
+- **Bitcoin Core 0.19.0 released:** featuring over 1,000 commits from
+  contributors using more than 120 different names or pseudonyms, the


seems like we go out of our way to insinuate that there aren't actually 120 distinct contributors. however, we know the vast majority so it seems like at most a single digit % of these 120 are represented by 2 names. why not simply say "from 120 contributors"?

I don't think anyone is currently trying to inflate our contributor count, but I can't rule out the possibility, so I think it's good to be conservative in our language. Also, I just counted myself and there are only 29 people on that list who I've met in person or interacted with online enough to be willing to swear in court that they're separate from the other 28 people on my list (and one of those named contributors is myself). You're much more outgoing than I am, but I wonder if even you could account for the individuality of more than about half the people on the list.

(Also, I'm highly confident at least one of the names on the list is an accidental duplicate.)

If you want, I can just drop the mention of how many contributors were named.

I don't feel that strongly about it

perhaps "more than a hundred contributors"

Running git log --pretty="format:%an" upstream/0.18..upstream/0.19 | sort | uniq gives me 119 unique author names. Some are obvious duplicates (eg Samuel Dobson/meshcolloider, Glenn Willen/gwillen). I've met >40 of them in person and interacted with quite a few more online.

I think that "more than a hundred" is fairly safe. As is something like "with contributions from 120 github user accounts". The current wording "from contributors using more than 120 different names or pseudonyms" is distracting from the point we're trying to make.

moneyball · 2019-11-11T06:53:49Z

_posts/en/newsletters/2019-11-13-newsletter.md

+    Russell proposed a mechanism that combines fees and hashcash-style
+    proof-of-work to try to prevent nodes from using using the extra
+    up-front payment information to guess the length of the route.
+    Anthony Towns proposed an partial [alternative][towns up-front]


jonatack

Whew, what a newsletter! I didn't make it all the way through on this pass. Apologies for all the suggestions below. Some are errata, like rpc setwalletflag. Cheers.

jonatack · 2019-11-11T12:08:46Z

_posts/en/newsletters/2019-11-13-newsletter.md

+lang: en
+---
+This week's newsletter announces the latest major release of Bitcoin
+Core and links to a security disclosure affecting some older releases,


perhaps s/and links to/, warns of/

jonatack · 2019-11-11T12:10:53Z

_posts/en/newsletters/2019-11-13-newsletter.md

+## Action items
+
+- **Upgrade Bitcoin Core:** users are encouraged to upgrade to the
+  latest [release][bitcoin core 0.19.0], which contains new features and


Possibly mention the version number here, or in the first mention above, to situate the reader from the start. IDK if good to require the reader make it to the third mention of the release below to know which one it is.

jonatack · 2019-11-11T12:12:12Z

_posts/en/newsletters/2019-11-13-newsletter.md

+  list.  The vulnerability only affects users who have configured a
+  SOCKS proxy to use either an untrusted server or to connect over an
+  untrusted network.  Almost all affected versions of Bitcoin Core are
+  also affected by previously-disclosed vulnerabilities, such as


nano-nit: can omit hyphen

jonatack · 2019-11-11T12:19:27Z

_posts/en/newsletters/2019-11-13-newsletter.md

+{% endcomment %}
+
+- **Bitcoin Core 0.19.0 released:** featuring over 1,000 commits from
+  contributors using more than 120 different names or pseudonyms, the


perhaps "more than a hundred contributors"

jonatack · 2019-11-11T12:19:58Z

_posts/en/newsletters/2019-11-13-newsletter.md

+  contributors using more than 120 different names or pseudonyms, the
+  [latest Bitcoin Core release][bitcoin core 0.19.0] offers several new
+  user-visible features, numerous bug fixes, and multiple improvements
+  to internal systems such P2P network handling.  Some changes which


s/such/such as/

jonatack · 2019-11-11T12:56:07Z

_posts/en/newsletters/2019-11-13-newsletter.md

+    operators, please see the Bitcoin Core project's [release notes][notes
+    0.19.0].
+
+    Note, that (as of this writing) both released versions and the


nit: omit comma, or: "For LND users: please note that, as of this writing, both..."

jonatack · 2019-11-11T12:59:04Z

_posts/en/newsletters/2019-11-13-newsletter.md

+  participating in question and answer sessions with Bitcoin experts who
+  previously contributed to the taproot design.
+
+    One [question][why v1 flex] asked was about why taproot allows v1


nit: can omit "was about"

jonatack · 2019-11-11T12:59:39Z

_posts/en/newsletters/2019-11-13-newsletter.md

+    One [question][why v1 flex] asked was about why taproot allows v1
+    segwit scriptPubKeys to use fewer or more than 34 bytes---the amount
+    needed for a Pay-to-Taproot (P2TR) scriptPubKey.  This seems odd
+    since [BIP141][] v0 segwit scriptPubKeys are only allowed the use


jonatack · 2019-11-11T13:00:08Z

_posts/en/newsletters/2019-11-13-newsletter.md

+    longer v1 scriptPubKeys will be spendable by anyone (as they are
+    today).
+
+    This started a discussion among experts about a recently-discovered


nit: omit hyphen

jonatack · 2019-11-11T13:04:17Z

_posts/en/newsletters/2019-11-13-newsletter.md

+    blog post][x-only pubkeys] about a recent major change to
+    [bip-schnorr][] and [bip-taproot][] that reduced the size of
+    serialized public keys from 33 bytes to 32 bytes without reducing
+    security.


James Chiang's idea suggested to Pieter Wuille on IRC 🥇

Thanks @jonatack! It was originally a conversation with John, who later expanded it to include Pieter. John did give me credit for reducing to 32B public keys here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016943.html

_posts/en/newsletters/2019-11-13-newsletter.md

jonatack

Second pass. Cheers.

jonatack · 2019-11-12T12:12:51Z

_posts/en/newsletters/2019-11-13-newsletter.md

+    scriptPubKeys, then it would be possible for a user to make a
+    single-character mistake and lose all of the money they intended to
+    spend.  Author of both BIP173 and the taproot proposal Pieter Wuille
+    [posted][wuille bech32 workaround] to the Bitcoin-Dev mailing some


s/mailing/mailing list/

jonatack · 2019-11-12T12:32:34Z

_posts/en/newsletters/2019-11-13-newsletter.md

+- [BIPs #857][] edits [BIP157][] to increase the maximum number of
+  compact block filters that can be requested at once from 100 to 1,000.
+  This reverts a [PR from last year][BIPs #699] that lowered it from
+  1,000 to 100.


It seems this entry is missing an explanation of why this PR was reverted/why this change... e.g. to improve nodes' sync speed via better batching requests for filters, IIUC

I do like to include explanations in merge descriptions, but the justification for this as offered in the PR doesn't make sense to me. It talks about round trips, but I don't know of any reason why you have to wait for the response to one getcfilters request in order to send a second request. I wonder if it was just easier to change the BIP than it was to change all the software using the 1,000-filter value.

In any case, I don't think this is an important-enough change to really need a justification. It's just an arbitrary number change.

jnewbery

ACK cc255c2 except for one bad link.

jnewbery · 2019-11-12T22:27:34Z

_posts/en/newsletters/2019-11-13-newsletter.md

+[news59 proposed 32B pubkeys]: /en/newsletters/2019/08/14/#proposed-change-to-schnorr-pubkeys
+[news68 taproot update]: /en/newsletters/2019/10/16/#taproot-update
+[news60 16248]: /en/newsletters/2019/08/21/#bitcoin-core-16248
+[bse bech32 extension]: {{bse}}#91602


bad link. Drop the #

jnewbery · 2019-11-12T22:30:27Z

Pushed a fix for the bad link. Please squash when merging.

ACK 2f93b93

jnewbery · 2019-11-12T22:31:14Z

Oh wait, Bitcoin Core release has been delayed, so I think we need to pull that section (and update the summary) before merging.

EDIT: and add an announcement of the topics index.

harding · 2019-11-12T23:16:13Z

Added a commit for the topics announcement, and a separate commit (easy to revert) dropping the Bitcoin Core release announcement. I also had to rebase on master to allow linking to the topics announcement; you can find the pre-rebase branch here: https://github.com/harding/bitcoinops.github.io/tree/2019-11-13-newsletter-pre-rebase1

Everything can be squashed at merge time as I have a backup of the Bitcoin Core release content for (hopefully) next week.

jnewbery · 2019-11-13T00:18:29Z

ACK 48efca9

Thanks @harding !

bitschmidty · 2019-11-13T12:53:10Z

Pushed a couple small changes I just noticed and then squashed

bitschmidty · 2019-11-13T13:08:24Z

With so many changes this week to discover
This weeks theme is: Oh the PRs youll cover!

You'll look up and down code. Look it over with care.
About some you will say, "I don't choose to merge there."
With your head full of brains and avoidance of fork,
you're too smart to go pursue any code that could bork.

@harding Congrats on getting the Topic Index live while also cranking out a Lorax-sized newsletter!
Thanks to Things 1 (@moneyball), 2 (@jonatack), 3 (@jnewbery), and 4 (@jachiang) for your reviews

moneyball reviewed Nov 11, 2019

View reviewed changes

jonatack reviewed Nov 11, 2019

View reviewed changes

jnewbery reviewed Nov 11, 2019

View reviewed changes

jonatack reviewed Nov 12, 2019

View reviewed changes

jnewbery reviewed Nov 12, 2019

View reviewed changes

harding force-pushed the 2019-11-13-newsletter branch 2 times, most recently from 51ca695 to 08021c2 Compare November 12, 2019 23:14

harding force-pushed the 2019-11-13-newsletter branch from 08021c2 to 48efca9 Compare November 12, 2019 23:21

News: add 72 (2019-11-13)

5849320

bitschmidty force-pushed the 2019-11-13-newsletter branch from 208a3f7 to 5849320 Compare November 13, 2019 12:47

bitschmidty merged commit 301d4a0 into bitcoinops:master Nov 13, 2019

jnewbery added the newsletters Publishing/translating/editing newsletters label Dec 12, 2019

harding mentioned this pull request Dec 15, 2019

Newsletters: add 77 (2019-12-18) #296

Merged

1 task

Copinmalin mentioned this pull request Sep 5, 2023

Newsletters: add 267 (2023-09-06) #1278

Merged

3 tasks

News: add 72 (2019-11-13) #266

News: add 72 (2019-11-13) #266

Uh oh!

Conversation

harding commented Nov 11, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonatack left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jonatack left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonatack Nov 12, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jnewbery left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jnewbery commented Nov 12, 2019

Uh oh!

jnewbery commented Nov 12, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

harding commented Nov 12, 2019

Uh oh!

jnewbery commented Nov 13, 2019

Uh oh!

bitschmidty commented Nov 13, 2019

Uh oh!

bitschmidty commented Nov 13, 2019

Uh oh!

jonatack Nov 12, 2019 •

edited

Loading

jnewbery commented Nov 12, 2019 •

edited

Loading