Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from Nov 13, 2019
Merged

Conversation

harding
Copy link
Contributor

@harding harding commented Nov 11, 2019

No description provided.

{% endcomment %}

- **Bitcoin Core 0.19.0 released:** featuring over 1,000 commits from
contributors using more than 120 different names or pseudonyms, the
Copy link
Contributor

@moneyball moneyball Nov 11, 2019

Choose a reason for hiding this comment

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

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"?

Copy link
Contributor Author

@harding harding Nov 11, 2019

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@moneyball moneyball Nov 11, 2019

Choose a reason for hiding this comment

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

I don't feel that strongly about it

Copy link
Collaborator

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

perhaps "more than a hundred contributors"

Copy link
Contributor

@jnewbery jnewbery Nov 11, 2019

Choose a reason for hiding this comment

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

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.

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]
Copy link
Contributor

@moneyball moneyball Nov 11, 2019

Choose a reason for hiding this comment

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

a partial

Copy link
Collaborator

@jonatack jonatack left a comment

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.

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

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

perhaps s/and links to/, warns of/

## Action items

- **Upgrade Bitcoin Core:** users are encouraged to upgrade to the
latest [release][bitcoin core 0.19.0], which contains new features and
Copy link
Collaborator

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

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.

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
Copy link
Collaborator

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

nano-nit: can omit hyphen

{% endcomment %}

- **Bitcoin Core 0.19.0 released:** featuring over 1,000 commits from
contributors using more than 120 different names or pseudonyms, the
Copy link
Collaborator

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

perhaps "more than a hundred contributors"

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
Copy link
Collaborator

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

s/such/such as/

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
Copy link
Collaborator

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

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

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
Copy link
Collaborator

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

nit: can omit "was about"

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
Copy link
Collaborator

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

s/the/to/

longer v1 scriptPubKeys will be spendable by anyone (as they are
today).

This started a discussion among experts about a recently-discovered
Copy link
Collaborator

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

nit: omit hyphen

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.
Copy link
Collaborator

@jonatack jonatack Nov 11, 2019

Choose a reason for hiding this comment

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

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

Choose a reason for hiding this comment

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

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 Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-11-13-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-11-13-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-11-13-newsletter.md Outdated Show resolved Hide resolved
_posts/en/newsletters/2019-11-13-newsletter.md Outdated Show resolved Hide resolved
Copy link
Collaborator

@jonatack jonatack left a comment

Second pass. Cheers.

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
Copy link
Collaborator

@jonatack jonatack Nov 12, 2019

Choose a reason for hiding this comment

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

s/mailing/mailing list/

- [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.
Copy link
Collaborator

@jonatack jonatack Nov 12, 2019

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

@harding harding Nov 12, 2019

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@jnewbery jnewbery left a comment

ACK cc255c2 except for one bad link.

[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
Copy link
Contributor

@jnewbery jnewbery Nov 12, 2019

Choose a reason for hiding this comment

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

bad link. Drop the #

@jnewbery
Copy link
Contributor

@jnewbery jnewbery commented Nov 12, 2019

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

ACK 2f93b93

@jnewbery
Copy link
Contributor

@jnewbery jnewbery commented Nov 12, 2019

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 harding force-pushed the 2019-11-13-newsletter branch 2 times, most recently from 51ca695 to 08021c2 Compare Nov 12, 2019
@harding
Copy link
Contributor Author

@harding harding commented Nov 12, 2019

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.

@harding harding force-pushed the 2019-11-13-newsletter branch from 08021c2 to 48efca9 Compare Nov 12, 2019
@jnewbery
Copy link
Contributor

@jnewbery jnewbery commented Nov 13, 2019

ACK 48efca9

Thanks @harding !

@bitschmidty
Copy link
Contributor

@bitschmidty bitschmidty commented Nov 13, 2019

Pushed a couple small changes I just noticed and then squashed

@bitschmidty bitschmidty merged commit 301d4a0 into bitcoinops:master Nov 13, 2019
2 checks passed
@bitschmidty
Copy link
Contributor

@bitschmidty bitschmidty commented Nov 13, 2019

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

@jnewbery jnewbery added the newsletters label Dec 12, 2019
@harding harding mentioned this pull request Dec 15, 2019
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
newsletters
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants