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

Newsletters: add 50 (2019-06-12) #153

Merged
merged 1 commit into from Jun 12, 2019

Conversation

@harding
Copy link
Contributor

@harding harding commented Jun 7, 2019

  • Replace "FIXME" with final link for @moneyball's talk video
Copy link
Contributor

@jnewbery jnewbery left a comment

I've reviewed the 'Bech32 sending support' section.

I'd suggest putting the schnorr/taproot exec briefing video blurb directly in 2019-06-12-newsletter.md for this PR, and then we pull them out into includes files as a PR later this week.

separates the two uses of native segwit so you can compare bech32 P2WSH
use to its rough equivalent P2SH.

![P2SH adoption speed versus native segwit. Separate lines for P2WPKH and P2WSH](/img/posts/2019-06-p2sh-vs-segwit-separate.png)
Copy link
Contributor

@jnewbery jnewbery Jun 9, 2019

Choose a reason for hiding this comment

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

It's very difficult to see the distinction between P2SH and P2WSH in this graph. Can you zoom in to just the first 700 days so the y-axis only needs to go up to 10%. Alternatively use a log scale for the y-axis.

end of February 2018, we have no satisfactory explanation for that.
You can see the event in detail on either the [P2SH.info
dashboard][p2sh.info p2wpkh spike] or [Optech dashboard][dashboard
p2wpkh spike]. In a possible accidental coincidence, that February
Copy link
Contributor

@jnewbery jnewbery Jun 9, 2019

Choose a reason for hiding this comment

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

I'd suggest we don't give this reason that we don't think is the reason.

I'm sure one of the men who stare at mempools have a good theory for this bump in P2WSH usage. Sertgej Kotliar, LaurentMT and Antoine Le Calvez are good candidates.

Copy link
Contributor

@jnewbery jnewbery Jun 9, 2019

Choose a reason for hiding this comment

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

Copy link
Contributor Author

@harding harding Jun 9, 2019

Choose a reason for hiding this comment

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

Yeah, @moneyball figured it out in IRC earlier; I just haven't updated yet. :-)

[libsecp256k1][libsecp256k1 repo], and [Bitcoin Improvement Proposals
(BIPs)][bips repo].*

- [LND #2802][] allows LND to calculate the probability that a
Copy link
Contributor

@jnewbery jnewbery Jun 9, 2019

Choose a reason for hiding this comment

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

Joost talked about this in his Breaking Bitcoin presentation. Perhaps we could link to the transcript here: http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/lightning-network-routing-security/

@harding harding changed the title [WIP] Newsletters: add 50 (2019-06-12) Newsletters: add 50 (2019-06-12) Jun 10, 2019
@harding
Copy link
Contributor Author

@harding harding commented Jun 10, 2019

Main content is uploaded and ready for review; I haven't yet addressed the previously-provided feedback.

Optech contributors liked it, so a few details were worked out and
regular weekly publication of this newsletter began.

Fifty issues later, the newsletter now has 2,480 email subscribers
Copy link
Contributor

@jnewbery jnewbery Jun 10, 2019

Choose a reason for hiding this comment

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

*now has more than 2,500 email subscribers 😁

anyone interested in Bitcoin Core development. All the discussions
were great, so we felt compelled to give each a small introduction:

- June 5th: a session on [code review][xs review] discussed results
Copy link
Contributor

@jnewbery jnewbery Jun 10, 2019

Choose a reason for hiding this comment

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

I think we should shorten this section to around 5 talks. The internal Bitcoin Core project discussions about code review, wallet architecture, maintainership, etc are interesting for Bitcoin Core geeks like ourselves, but most of our readers are probably more interested in the proposals that affect the network and third party software. My picks would be taproot, utreexo, consensus cleanup, signet, p2p encryption and noinput.

Copy link
Contributor Author

@harding harding Jun 11, 2019

Choose a reason for hiding this comment

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

I really did like all of these transcripts, so I would like to mention each of them if possible. As a possible compromise to address your concerns about length, I've pushed 6feb4ee that halves the word count of this item, from 747 words to 373 (source code words, including link identifiers).

I think you have a point about internal Bitcoin Core project discussions not being of network-wide importance (unless things go horribly wrong), but I suspect that they're more popular than you suspect. People are always interested in how successful projects are run and how they deal with the same problems every large-scale group effort has. Although particular details like IsMine() are irrelevant to anyone not hip-deep in bitcoind internals, I think we've mentioned things like descriptors positively enough times that some readers might be interested in getting a glimpse of how much work it might actually require to convert an assumed-script wallet to a descriptor wallet.


- June 6th: the [consensus cleanup soft fork][xs cleanup sf]
proposed three months ago was discussed. Topics included
whether that fork should be done before, after, or in parallel
Copy link
Contributor

@jnewbery jnewbery Jun 10, 2019

Choose a reason for hiding this comment

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

s/that fork should be done/an activation date for the fork should be proposed/

[maintainers][xs maint] about what they thought could be improved
in the project, including what contributors could do to make the
maintainers' work easier. During the meeting, long-time
contributor Michael Ford was made a maintainer and there was
Copy link
Contributor

@jnewbery jnewbery Jun 10, 2019

Choose a reason for hiding this comment

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

I've suggested we remove this paragraph, but I think we should keep this detail (Michael Ford made a maintainer), perhaps as a final bullet point.

merkle tree instead of an accumulator and risks related to fast
quantum computers. ([More background][bg taproot])

A question and answer session about the [Utreexo][xs utreexo]
Copy link
Contributor

@jnewbery jnewbery Jun 10, 2019

Choose a reason for hiding this comment

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

Could link to the paper (https://eprint.iacr.org/2019/611) which was updated last week.

opt-in Replace-By-Fee (RBF) only allows replacing a transaction with a
higher-feerate alternative if the replacement increases the total
amount of transaction fee paid in the entire mempool by a certain
amount (the incremental feerate). This stops a cheap
Copy link
Contributor

@jnewbery jnewbery Jun 10, 2019

Choose a reason for hiding this comment

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

This isn't quite how I understand the BIP125 rules. Rule 3 only states that the replacement transaction pays strictly more than the original transactions. The incremental feerate is applicable for rule 4.

If the replacement transaction is much smaller than the original transactions, then the absolute incremental fee could be very small relative to the size of the original transactions.

Addressing both the public key interactivity and the signature
auditing concerns, Lee shows an alternative construction possible
using a combination of Taproot's key-path and script-path spending.
Three [MuSig][]-style n-of-n aggregated pubkeys are created---one
Copy link
Contributor

@jnewbery jnewbery Jun 10, 2019

Choose a reason for hiding this comment

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

2-of-2 instead of n-of-n here?

to excessively waste node bandwidth. Several people replied to the
proposal asking questions and offering analysis about these risks.

- **Presentation: The Next Softfork:** Bitcoin Optech contributor Steve
Copy link
Contributor

@jnewbery jnewbery Jun 10, 2019

Choose a reason for hiding this comment

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

I think this section could be shortened slightly, perhaps by giving less details about the 2-of-3 MAST construction. It'd be a shame if people skipped watching the video because your summary was too good :)

Copy link
Contributor

@moneyball moneyball Jun 11, 2019

Choose a reason for hiding this comment

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

I am comfortable with the current text or a shortened version, whatever you feel is best.

Copy link
Contributor Author

@harding harding Jun 11, 2019

Choose a reason for hiding this comment

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

I added some words pointing out that @moneyball's slides are easier to follow than the condensed summary of his walkthrough. Please let me know if that doesn't adequately address the concern.

Copy link
Contributor

@jnewbery jnewbery Jun 11, 2019

Choose a reason for hiding this comment

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

Looks good to me, especially with the shortened coredev section. Thanks Dave.

@harding
Copy link
Contributor Author

@harding harding commented Jun 11, 2019

Pushed a commit that I think addresses all concerns to date. Thanks for the reviews, @jnewbery!

suggestions for streamlining reviews.

Participants discussed changing the [wallet architecture][xs
wallet arch] to using [output script descriptors][] for tracking
Copy link
Contributor

@jnewbery jnewbery Jun 11, 2019

Choose a reason for hiding this comment

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

s/for tracking payments to the wallet/for the wallet's key management (tracking payments to the wallet, generating new addresses, and signing for transactions)./ or similar.

The idea is that descriptors will be used for all key management in the wallet - that includes tracking payments to the wallet ("IsMine") like you say, but also address generation and signing.

added. ([More background][bg consensus cleanup])

The group asked what they could do to make the [maintainers'][xs
maint] work easier. Suggestions included making new maintainer
Copy link
Contributor

@jnewbery jnewbery Jun 11, 2019

Choose a reason for hiding this comment

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

I'd distinguish here between Michael Ford being made a maintainer (which was agreed upon and has now happened) and some vague wish for a future P2P maintainer.

Optech contributors liked it, so a few details were worked out and
regular weekly publication of this newsletter began.

Fifty issues later, the newsletter now over 2,500 email subscribers
Copy link
Contributor

@jnewbery jnewbery Jun 11, 2019

Choose a reason for hiding this comment

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

s/newsletter now over/newsletter now has over/


## Bech32 sending support

*Week 13 of 24 in a [series][bech32 easy] about allowing the people
Copy link
Contributor

@jnewbery jnewbery Jun 11, 2019

Choose a reason for hiding this comment

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

Should these "series" links now link to the blog post instead of newsletter 38?

outputs. Indeed, when we consider that all LN deposit transactions (and
at least some other onchain LN transaction) are using native P2WSH
outputs, it appears as if almost none of the late-2017 P2SH activity has
converted to P2WSH.
Copy link
Contributor

@jnewbery jnewbery Jun 11, 2019

Choose a reason for hiding this comment

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

s/has converted/has yet converted/ if we want to be optimistic?

possible using either P2SH-wrapped segwit addresses or native P2WSH
addresses. P2SH-wrapped segwit addresses are backwards compatible and
can [significantly reduce transaction fees][bech32 fees] whereas bech32
addresses aren't backwards compatible with older wallets and only save a
Copy link
Contributor

@jnewbery jnewbery Jun 11, 2019

Choose a reason for hiding this comment

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

s/and only save a small fixed amount of extra fees per spent output/and the additional fee savings over P2SH-wrapped segwit are relatively small/ to make it even more clear that moving to native is an additional saving over P2SH-wrapped.


{% include specials/bech32/13-adoption-speed.md %}

## Notable code and documentation changes
Copy link
Contributor

@jnewbery jnewbery Jun 11, 2019

Choose a reason for hiding this comment

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

Is the plan now for this section to cover the previous week (up to friday when you produce the first draft) or do you plan to update it when you give your final draft?

Copy link
Contributor Author

@harding harding Jun 11, 2019

Choose a reason for hiding this comment

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

So the way I've been doing it for a while is that I have a script I run each day that shows me all the commits I haven't see on each project's master branch and I document the notable changes into a file. When I start drafting the newsletter, I copy those into the draft.

Then, when I finish the draft a day or two later, I look at how long the newsletter is and decide whether or not to add any of the merges that came in during the intervening time. Last week and this week we had long newsletters, so I haven't added anything. In the future we may have short newsletters were I will add anything.

For the devs like you who know when stuff was merged, I suppose that inconsistency around the dating can be annoying (sorry). For readers, I think it's better to do what we can to try to balance out the slow weeks with the busy weeks.

Copy link
Contributor

@jnewbery jnewbery Jun 11, 2019

Choose a reason for hiding this comment

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

Sounds very reasonable. Thanks for the explanation!

to excessively waste node bandwidth. Several people replied to the
proposal asking questions and offering analysis about these risks.

- **Presentation: The Next Softfork:** Bitcoin Optech contributor Steve
Copy link
Contributor

@jnewbery jnewbery Jun 11, 2019

Choose a reason for hiding this comment

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

Looks good to me, especially with the shortened coredev section. Thanks Dave.

@harding
Copy link
Contributor Author

@harding harding commented Jun 11, 2019

Commit pushed for @jnewbery feedback, round 2 (thanks!). Also a second commit that redirects previous links in the introduction to each Bech32 Sending Support section to the overview blog post (something John suggested above, but in a separate commit because it affects old content [I think it's still reasonable to squash with everything else]).

@jnewbery
Copy link
Contributor

@jnewbery jnewbery commented Jun 12, 2019

Pushed a commit to add the youtube link.

ACK d828eba

@bitschmidty - please squash, merge and send!

@bitschmidty
Copy link
Contributor

@bitschmidty bitschmidty commented Jun 12, 2019

Pushed a commit to remove extra trailing slashes from the internal newsletter urls. While the links still worked with the trailing "//", it can cause "duplicate content" issues wrt search engines.

@bitschmidty bitschmidty force-pushed the 2019-06-12-newsletter branch from 9b1547b to 6558f16 Jun 12, 2019
@bitschmidty
Copy link
Contributor

@bitschmidty bitschmidty commented Jun 12, 2019

reverted the trailing slash fix as it caused issues elsewhere in jekyll.

squashed commits to a single commit and force-pushed

@bitschmidty bitschmidty merged commit 2036b17 into bitcoinops:master Jun 12, 2019
2 checks passed
@bitschmidty
Copy link
Contributor

@bitschmidty bitschmidty commented Jun 12, 2019

congrats on #50, @harding !

@jnewbery and @moneyball thank you guys as always for the reviews!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants