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

This comment has been minimized.

Copy link
@moneyball

moneyball Nov 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@harding

harding Nov 11, 2019

Author Contributor

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.

This comment has been minimized.

Copy link
@moneyball

moneyball Nov 11, 2019

Contributor

I don't feel that strongly about it

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

perhaps "more than a hundred contributors"

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 11, 2019

Contributor

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]

This comment has been minimized.

Copy link
@moneyball

moneyball Nov 11, 2019

Contributor

a partial

Copy link
Contributor

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,

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

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.

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jachiang

jachiang Nov 11, 2019

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

Copy link
Contributor

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

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 12, 2019

Contributor

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.

This comment has been minimized.

Copy link
@jonatack

jonatack Nov 12, 2019

Contributor

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

This comment has been minimized.

Copy link
@harding

harding Nov 12, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 12, 2019

Contributor

bad link. Drop the #

@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented Nov 12, 2019

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

ACK 2f93b93

@jnewbery

This comment has been minimized.

Copy link
Contributor

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 harding:2019-11-13-newsletter branch 2 times, most recently from 51ca695 to 08021c2 Nov 12, 2019
@harding

This comment has been minimized.

Copy link
Contributor Author

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 harding:2019-11-13-newsletter branch from 08021c2 to 48efca9 Nov 12, 2019
@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented Nov 13, 2019

ACK 48efca9

Thanks @harding !

@bitschmidty bitschmidty force-pushed the harding:2019-11-13-newsletter branch from 208a3f7 to 5849320 Nov 13, 2019
@bitschmidty

This comment has been minimized.

Copy link
Contributor

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
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
netlify/bitcoinops/deploy-preview Deploy preview ready!
Details
@bitschmidty

This comment has been minimized.

Copy link
Contributor

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

@harding harding mentioned this pull request Dec 15, 2019
1 of 1 task complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.