Newsletters: add 50 (2019-06-12) #153
Conversation
harding
commented
Jun 7, 2019
•
harding
commented
- Replace "FIXME" with final link for @moneyball's talk video
| separates the two uses of native segwit so you can compare bech32 P2WSH | ||
| use to its rough equivalent P2SH. | ||
|
|
||
|  |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I've paged them https://twitter.com/jfnewbery/status/1137751870938722304
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
changed the title
|
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 |
There was a problem hiding this comment.
*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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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] |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
I am comfortable with the current text or a shortened version, whatever you feel is best.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Looks good to me, especially with the shortened coredev section. Thanks Dave.
|
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
s/newsletter now over/newsletter now has over/
|
|
||
| ## Bech32 sending support | ||
|
|
||
| *Week 13 of 24 in a [series][bech32 easy] about allowing the people |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Looks good to me, especially with the shortened coredev section. Thanks Dave.
|
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]). |
|
Pushed a commit to add the youtube link. ACK d828eba @bitschmidty - please squash, merge and send! |
|
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
force-pushed
the
2019-06-12-newsletter
branch
from
9b1547b
to
6558f16
Compare
|
reverted the trailing slash fix as it caused issues elsewhere in jekyll. squashed commits to a single commit and force-pushed |
|
@jnewbery and @moneyball thank you guys as always for the reviews! |
