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 commented Jun 7, 2019

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

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)

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 9, 2019

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 9, 2019

Contributor

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.

This comment has been minimized.

Copy link
@jnewbery

This comment has been minimized.

Copy link
@harding

harding Jun 9, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 9, 2019

Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 10, 2019

Contributor

*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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 10, 2019

Contributor

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.

This comment has been minimized.

Copy link
@harding

harding Jun 11, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 10, 2019

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 10, 2019

Contributor

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]

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 10, 2019

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 10, 2019

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 10, 2019

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 10, 2019

Contributor

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

This comment has been minimized.

Copy link
@moneyball

moneyball Jun 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@harding

harding Jun 11, 2019

Author Contributor

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.

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 11, 2019

Contributor

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

@harding

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 11, 2019

Contributor

s/newsletter now over/newsletter now has over/


## Bech32 sending support

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 11, 2019

Contributor

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.

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 11, 2019

Contributor

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?

This comment has been minimized.

Copy link
@harding

harding Jun 11, 2019

Author Contributor

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.

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 11, 2019

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Jun 11, 2019

Contributor

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

@harding

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

jnewbery commented Jun 12, 2019

Pushed a commit to add the youtube link.

ACK d828eba

@bitschmidty - please squash, merge and send!

@bitschmidty

This comment has been minimized.

Copy link
Contributor

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.

Happy 50th!
@bitschmidty bitschmidty force-pushed the harding:2019-06-12-newsletter branch from 9b1547b to 6558f16 Jun 12, 2019
@bitschmidty

This comment has been minimized.

Copy link
Contributor

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
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 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
Projects
None yet
4 participants
You can’t perform that action at this time.